Re: [Xen-devel] Current PVH/HVMlite work and planning (was :Re: Discussion about virtual iommu support for Xen guest)

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Fri, Jun 03, 2016 at 11:21:20AM +0000, Tian, Kevin wrote:
> > From: Roger Pau Monne [mailto:roger.pau@xxxxxxxxxx]
> > Sent: Friday, June 03, 2016 7:02 PM
> > 
> > On Thu, Jun 02, 2016 at 07:58:48PM +0100, Andrew Cooper wrote:
> > > On 02/06/16 16:03, Lan, Tianyu wrote:
> > > > On 5/27/2016 4:19 PM, Lan Tianyu wrote:
> > > >> On 2016年05月26日 19:35, Andrew Cooper wrote:
> > > >>> On 26/05/16 09:29, Lan Tianyu wrote:
> > > >>>
> > > >>> To be viable going forwards, any solution must work with PVH/HVMLite 
> > > >>> as
> > > >>> much as HVM.  This alone negates qemu as a viable option.
> > > >>>
> > > >>> From a design point of view, having Xen needing to delegate to qemu to
> > > >>> inject an interrupt into a guest seems backwards.
> > > >>>
> > > >>
> > > >> Sorry, I am not familiar with HVMlite. HVMlite doesn't use Qemu and
> > > >> the qemu virtual iommu can't work for it. We have to rewrite virtual
> > > >> iommu in the Xen, right?
> > > >>
> > > >>>
> > > >>> A whole lot of this would be easier to reason about if/when we get a
> > > >>> basic root port implementation in Xen, which is necessary for HVMLite,
> > > >>> and which will make the interaction with qemu rather more clean.  It 
> > > >>> is
> > > >>> probably worth coordinating work in this area.
> > > >>
> > > >> The virtual iommu also should be under basic root port in Xen, right?
> > > >>
> > [...]
> > > > What's progress of PCI host bridge in Xen? From your opinion, we should
> > > > do that first, right? Thanks.
> > >
> > > Very sorry for the delay.
> > >
> > > There are multiple interacting issues here.  On the one side, it would
> > > be useful if we could have a central point of coordination on
> > > PVH/HVMLite work.  Roger - as the person who last did HVMLite work,
> > > would you mind organising that?
> > 
> > Sure. Adding Boris and Konrad.
> > 
> > AFAIK, the current status is that Boris posted a RFC to provide some basic
> > ACPI tables to PVH/HVMlite guests, and I'm currently working on rebasing my
> > half-backed HVMlite Dom0 series on top of that. None of those two projects
> > require the presence of an emulated PCI root complex inside of Xen, so
> > there's nobody working on it ATM that I'm aware of.
> > 
> > Speaking about the PVH/HVMlite roadmap, after those two items are done we
> > had plans to work on having full PCI root complex emulation inside of Xen,
> > so that we could do passthrough of PCI devices to PVH/HVMlite guests without
> > QEMU (and of course without pcifront inside of the guest). I don't foresee
> > any of us working on it for at least the next 6 months, so I think there's a
> > good chance that this can be done in parallel to the work that Boris and I
> > are doing, without any clashes. Is anyone at Intel interested in picking
> > this up?
> 
> How stable is the HVMLite today? Is it already in production usage?
> 
> Wonder whether you have some detail thought how full PCI root complex
> emulation will be done in Xen (including how to interact with Qemu)...

I haven't looked into much detail regarding all this, since as I said, it's 
still a little bit far away in the PVH/HVMlite roadmap, we have more 
pressing issues to solve before getting to the point of implementing 
PCI-passthrough. I expect Xen is going to intercept all PCI accesses and is 
then going to forward them to the ioreq servers that have been registered 
for that specific config space, but this of course needs much more thought 
and a proper design document.

> As I just wrote in another mail, if we just hit for HVM first, will it work if
> we implement vIOMMU in Xen but still relies on Qemu root complex to
> report to the guest? 

This seems quite inefficient IMHO (but I don't know that much about all this 
vIOMMU stuff). If you implement vIOMMU inside of Xen, but the PCI root 
complex is inside of Qemu aren't you going to perform quite a lot of jumps 
between Xen and QEMU just to access the vIOMMU?

I expect something like:

Xen traps PCI access -> QEMU -> Xen vIOMMU implementation

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel