[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v9 10/14] hw/arm/smmuv3: Abort on vfio or vhost
From: |
Auger Eric |
Subject: |
Re: [Qemu-devel] [PATCH v9 10/14] hw/arm/smmuv3: Abort on vfio or vhost case |
Date: |
Mon, 12 Mar 2018 16:01:30 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
Hi Peter,
On 12/03/18 12:10, Peter Maydell wrote:
> On 12 March 2018 at 10:53, Eric Auger <address@hidden> wrote:
>> Hi Peter,
>>
>> On 09/03/18 18:59, Peter Maydell wrote:
>>> On 9 March 2018 at 17:53, Auger Eric <address@hidden> wrote:
>>>> Hi Peter,
>>>> On 08/03/18 20:06, Peter Maydell wrote:
>>>>> On 17 February 2018 at 18:46, Eric Auger <address@hidden> 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
>