[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v4 0/3] Add Mediated device support[was: Add
From: |
Jike Song |
Subject: |
Re: [Qemu-devel] [RFC PATCH v4 0/3] Add Mediated device support[was: Add vGPU support] |
Date: |
Thu, 2 Jun 2016 10:11:36 +0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 |
On 05/31/2016 10:29 PM, Alex Williamson wrote:
> On Tue, 31 May 2016 10:29:10 +0800
> Jike Song <address@hidden> wrote:
>
>> On 05/28/2016 10:56 PM, Alex Williamson wrote:
>>> On Fri, 27 May 2016 22:43:54 +0000
>>> "Tian, Kevin" <address@hidden> wrote:
>>>
>>>>
>>>> My impression was that you don't like hypervisor specific thing in VFIO,
>>>> which makes it a bit tricky to accomplish those tasks in kernel. If we
>>>> can add Xen specific logic directly in VFIO (like vfio-iommu-xen you
>>>> mentioned), the whole thing would be easier.
>>>
>>> If vfio is hosted in dom0, then Xen is the platform and we need to
>>> interact with the hypervisor to manage the iommu. That said, there are
>>> aspects of vfio that do not seem to map well to a hypervisor managed
>>> iommu or a Xen-like hypervisor. For instance, how does dom0 manage
>>> iommu groups and what's the distinction of using vfio to manage a
>>> userspace driver in dom0 versus managing a device for another domain.
>>> In the case of kvm, vfio has no dependency on kvm, there is some minor
>>> interaction, but we're not running on kvm and it's not appropriate to
>>> use vfio as a gateway to interact with a hypervisor that may or may not
>>> exist. Thanks,
>>
>> Hi Alex,
>>
>> Beyond iommu, there are other aspects vfio need to interact with Xen?
>> e.g. to pass-through MMIO, one have to call hypercalls to establish EPT
>> mappings.
>
> If it's part of running on a Xen platform and not trying to interact
> with a VM in ways that are out of scope for vfio, I might be open to
> it, I'd need to see a proposal. This also goes back to my question of
> how does vfio know whether it's configuring a device for a guest driver
> or a guest VM, with kvm these are one and the same. Thanks,
Yes, this brings us back to Kevin suggestion,
> I'm not sure whether VFIO can support this usage today. It is somehow
> similar to channel io passthru in s390, where we also rely on Qemu to
> mediate ccw commands to ensure isolation. Maybe just some slight
> extension is required (e.g. not assume some API must be invoked). Of
> course Qemu side vfio code also need some change. If this can work,
> at least we can first put it as the enumeration interface for mediated
> device in Xen. In the future it may be extended to cover normal Xen
> PCI assignment as well instead of using sysfs to read PCI resource
> today.
>
> If above works, then we have a sound plan to enable mediated devices
> based on VFIO first for KVM, and then extend to Xen with reasonable
> effort.
We'll work on the proposal, thanks!
--
Thanks,
Jike
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [RFC PATCH v4 0/3] Add Mediated device support[was: Add vGPU support],
Jike Song <=