Re: [Qemu-arm] [Qemu-devel] [PATCH v9 10/14] hw/arm/smmuv3: Abort on vfio or vhost case

[Auger Eric <eric.auger@redhat.com>]

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
>