[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC XEN PATCH 4/6] x86/pvh: PVH dom0 also need PHYSDEVOP_setup_gsi call



On Wed, 15 Mar 2023, Stefano Stabellini wrote:
> On Wed, 15 Mar 2023, Andrew Cooper wrote:
> > On 14/03/2023 4:30 pm, Jan Beulich wrote:
> > > On 12.03.2023 08:54, Huang Rui wrote:
> > >> From: Chen Jiqian <Jiqian.Chen@xxxxxxx>
> > > An empty description won't do here. First of all you need to address the 
> > > Why?
> > > As already hinted at in the reply to the earlier patch, it looks like 
> > > you're
> > > breaking the intended IRQ model for PVH.
> > 
> > I think this is rather unfair.
> > 
> > Until you can point to the document which describes how IRQs are
> > intended to work in PVH, I'd say this series is pretty damn good attempt
> > to make something that functions, in the absence of any guidance.
> 
> And to make things more confusing those calls are not needed for PVH
> itself, those calls are needed so that we can run QEMU to support
> regular HVM guests on PVH Dom0 (I'll let Ray confirm.)
> 
> So technically, this is not breaking the PVH IRQ model.

To add more info:

QEMU (hw/xen/xen_pt.c) calls xc_physdev_map_pirq and
xc_domain_bind_pt_pci_irq. Note that xc_domain_bind_pt_pci_irq is the
key hypercall here and it takes a pirq as parameter.

That is why QEMU calls xc_physdev_map_pirq, so that we can get the pirq
and use the pirq as parameter for xc_domain_bind_pt_pci_irq.

We need to get the above to work also with Dom0 PVH.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.