| Message ID | 1518893216-9983-11-git-send-email-eric.auger@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | ARM SMMUv3 Emulation Support | expand |
On 17 February 2018 at 18:46, Eric Auger <eric.auger@redhat.com> wrote: > At the moment, the SMMUv3 does not support notification on > TLB invalidation. So let's abort as soon as such notifier gets > enabled. > > Signed-off-by: Eric Auger <eric.auger@redhat.com> > --- > hw/arm/smmuv3.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c > index 384393f..5efe933 100644 > --- a/hw/arm/smmuv3.c > +++ b/hw/arm/smmuv3.c > @@ -1074,12 +1074,23 @@ static void smmuv3_class_init(ObjectClass *klass, void *data) > dc->realize = smmu_realize; > } > > +static void smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu, > + IOMMUNotifierFlag old, > + IOMMUNotifierFlag new) > +{ > + if (old == IOMMU_NOTIFIER_NONE) { > + error_setg(&error_fatal, > + "SMMUV3: vhost and vfio notifiers not yet supported"); > + } > +} Is this triggerable by the guest, or by the user on the command line, or only by a bug in the board or other QEMU code? thanks -- PMM
Hi Peter, On 08/03/18 20:06, Peter Maydell wrote: > On 17 February 2018 at 18:46, Eric Auger <eric.auger@redhat.com> wrote: >> At the moment, the SMMUv3 does not support notification on >> TLB invalidation. So let's abort as soon as such notifier gets >> enabled. >> >> Signed-off-by: Eric Auger <eric.auger@redhat.com> >> --- >> hw/arm/smmuv3.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c >> index 384393f..5efe933 100644 >> --- a/hw/arm/smmuv3.c >> +++ b/hw/arm/smmuv3.c >> @@ -1074,12 +1074,23 @@ static void smmuv3_class_init(ObjectClass *klass, void *data) >> dc->realize = smmu_realize; >> } >> >> +static void smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu, >> + IOMMUNotifierFlag old, >> + IOMMUNotifierFlag new) >> +{ >> + if (old == IOMMU_NOTIFIER_NONE) { >> + error_setg(&error_fatal, >> + "SMMUV3: vhost and vfio notifiers not yet supported"); >> + } >> +} > > Is this triggerable by the guest, or by the user on the command > line, or only by a bug in the board or other QEMU code? by the user on the command line. Thanks Eric > > thanks > -- PMM >
On 9 March 2018 at 17:53, Auger Eric <eric.auger@redhat.com> wrote: > Hi Peter, > On 08/03/18 20:06, Peter Maydell wrote: >> On 17 February 2018 at 18:46, Eric Auger <eric.auger@redhat.com> wrote: >>> At the moment, the SMMUv3 does not support notification on >>> TLB invalidation. So let's abort as soon as such notifier gets >>> enabled. >>> >>> Signed-off-by: Eric Auger <eric.auger@redhat.com> >>> --- >>> hw/arm/smmuv3.c | 11 +++++++++++ >>> 1 file changed, 11 insertions(+) >>> >>> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c >>> index 384393f..5efe933 100644 >>> --- a/hw/arm/smmuv3.c >>> +++ b/hw/arm/smmuv3.c >>> @@ -1074,12 +1074,23 @@ static void smmuv3_class_init(ObjectClass *klass, void *data) >>> dc->realize = smmu_realize; >>> } >>> >>> +static void smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu, >>> + IOMMUNotifierFlag old, >>> + IOMMUNotifierFlag new) >>> +{ >>> + if (old == IOMMU_NOTIFIER_NONE) { >>> + error_setg(&error_fatal, >>> + "SMMUV3: vhost and vfio notifiers not yet supported"); >>> + } >>> +} >> >> Is this triggerable by the guest, or by the user on the command >> line, or only by a bug in the board or other QEMU code? > by the user on the command line. OK. Do they get this error immediately on startup, or only later in execution? (If the latter, is it possible to make the error happen earlier?) thanks -- PMM
Hi Peter, On 09/03/18 18:59, Peter Maydell wrote: > On 9 March 2018 at 17:53, Auger Eric <eric.auger@redhat.com> wrote: >> Hi Peter, >> On 08/03/18 20:06, Peter Maydell wrote: >>> On 17 February 2018 at 18:46, Eric Auger <eric.auger@redhat.com> wrote: >>>> At the moment, the SMMUv3 does not support notification on >>>> TLB invalidation. So let's abort as soon as such notifier gets >>>> enabled. >>>> >>>> Signed-off-by: Eric Auger <eric.auger@redhat.com> >>>> --- >>>> hw/arm/smmuv3.c | 11 +++++++++++ >>>> 1 file changed, 11 insertions(+) >>>> >>>> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c >>>> index 384393f..5efe933 100644 >>>> --- a/hw/arm/smmuv3.c >>>> +++ b/hw/arm/smmuv3.c >>>> @@ -1074,12 +1074,23 @@ static void smmuv3_class_init(ObjectClass *klass, void *data) >>>> dc->realize = smmu_realize; >>>> } >>>> >>>> +static void smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu, >>>> + IOMMUNotifierFlag old, >>>> + IOMMUNotifierFlag new) >>>> +{ >>>> + if (old == IOMMU_NOTIFIER_NONE) { >>>> + error_setg(&error_fatal, >>>> + "SMMUV3: vhost and vfio notifiers not yet supported"); >>>> + } >>>> +} >>> >>> Is this triggerable by the guest, or by the user on the command >>> line, or only by a bug in the board or other QEMU code? >> by the user on the command line. > > OK. Do they get this error immediately on startup, or only later > in execution? (If the latter, is it possible to make the error > happen earlier?) later in execution. We also have to handle the case where such device is hot-plugged. At best if could be done on smmu_find_add_as() by checking the type of attached device but this wouldn't happen much earlier. By the way we will soon support vhost and we will just rule out vfio integration by detecting map notifiers. Thanks Eric > > thanks > -- PMM >
On 12 March 2018 at 10:53, Eric Auger <eric.auger.pro@gmail.com> wrote: > Hi Peter, > > On 09/03/18 18:59, Peter Maydell wrote: >> On 9 March 2018 at 17:53, Auger Eric <eric.auger@redhat.com> wrote: >>> Hi Peter, >>> On 08/03/18 20:06, Peter Maydell wrote: >>>> On 17 February 2018 at 18:46, Eric Auger <eric.auger@redhat.com> wrote: >>>>> +static void smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu, >>>>> + IOMMUNotifierFlag old, >>>>> + IOMMUNotifierFlag new) >>>>> +{ >>>>> + if (old == IOMMU_NOTIFIER_NONE) { >>>>> + error_setg(&error_fatal, >>>>> + "SMMUV3: vhost and vfio notifiers not yet supported"); >>>>> + } >>>>> +} >>>> >>>> Is this triggerable by the guest, or by the user on the command >>>> line, or only by a bug in the board or other QEMU code? >>> by the user on the command line. >> >> OK. Do they get this error immediately on startup, or only later >> in execution? (If the latter, is it possible to make the error >> happen earlier?) > later in execution. We also have to handle the case where such device is > hot-plugged. At best if could be done on smmu_find_add_as() by checking > the type of attached device but this wouldn't happen much earlier. By > the way we will soon support vhost and we will just rule out vfio > integration by detecting map notifiers. Hmm. error_fatal is a bit unfortunate for a hotplug event -- ideally you would want to cause the hotplug to cleanly fail without aborting the running QEMU session. thanks -- PMM
Hi Peter, On 12/03/18 12:10, Peter Maydell wrote: > On 12 March 2018 at 10:53, Eric Auger <eric.auger.pro@gmail.com> wrote: >> Hi Peter, >> >> On 09/03/18 18:59, Peter Maydell wrote: >>> On 9 March 2018 at 17:53, Auger Eric <eric.auger@redhat.com> wrote: >>>> Hi Peter, >>>> On 08/03/18 20:06, Peter Maydell wrote: >>>>> On 17 February 2018 at 18:46, Eric Auger <eric.auger@redhat.com> wrote: >>>>>> +static void smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu, >>>>>> + IOMMUNotifierFlag old, >>>>>> + IOMMUNotifierFlag new) >>>>>> +{ >>>>>> + if (old == IOMMU_NOTIFIER_NONE) { >>>>>> + error_setg(&error_fatal, >>>>>> + "SMMUV3: vhost and vfio notifiers not yet supported"); >>>>>> + } >>>>>> +} >>>>> >>>>> Is this triggerable by the guest, or by the user on the command >>>>> line, or only by a bug in the board or other QEMU code? >>>> by the user on the command line. >>> >>> OK. Do they get this error immediately on startup, or only later >>> in execution? (If the latter, is it possible to make the error >>> happen earlier?) > >> later in execution. We also have to handle the case where such device is >> hot-plugged. At best if could be done on smmu_find_add_as() by checking >> the type of attached device but this wouldn't happen much earlier. By >> the way we will soon support vhost and we will just rule out vfio >> integration by detecting map notifiers. > > Hmm. error_fatal is a bit unfortunate for a hotplug event -- ideally > you would want to cause the hotplug to cleanly fail without aborting > the running QEMU session. At the moment I suggest I replace the assert by a warn_report saying vhost/vfio devices will not function properly. Normally in short term the restriction will only apply to VFIO devices. Having something more elegant would imply some modifications in the pci subsystem I think: pci_init_bus_master -> pci_device_iommu_address_space ->iommu_fn = smmu_find_add_as pci_init_bus_master is called in pcibus_machine_done and pci_qdev_realize/do_pci_register_device. But it is a void at the moment. in smmu_find_add_as I could check whether the device is a VFIO In case of a VFIO device smmu_find_add_as could return NULL; test this in pci_init_bus_master and propagate the error upstream? Thanks Eric > > thanks > -- PMM >
diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index 384393f..5efe933 100644 --- a/hw/arm/smmuv3.c +++ b/hw/arm/smmuv3.c @@ -1074,12 +1074,23 @@ static void smmuv3_class_init(ObjectClass *klass, void *data) dc->realize = smmu_realize; } +static void smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu, + IOMMUNotifierFlag old, + IOMMUNotifierFlag new) +{ + if (old == IOMMU_NOTIFIER_NONE) { + error_setg(&error_fatal, + "SMMUV3: vhost and vfio notifiers not yet supported"); + } +} + static void smmuv3_iommu_memory_region_class_init(ObjectClass *klass, void *data) { IOMMUMemoryRegionClass *imrc = IOMMU_MEMORY_REGION_CLASS(klass); imrc->translate = smmuv3_translate; + imrc->notify_flag_changed = smmuv3_notify_flag_changed; } static const TypeInfo smmuv3_type_info = {
At the moment, the SMMUv3 does not support notification on TLB invalidation. So let's abort as soon as such notifier gets enabled. Signed-off-by: Eric Auger <eric.auger@redhat.com> --- hw/arm/smmuv3.c | 11 +++++++++++ 1 file changed, 11 insertions(+)