On Thu, Mar 16, 2023 at 09:51:20AM +0100, Jan Beulich wrote:
> On 16.03.2023 01:26, 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.c...@amd.com>
> >>> 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.)
>
> Ah, but that wasn't said anywhere, was it? In which case ...
>
> > So technically, this is not breaking the PVH IRQ model.
>
> ... I of course agree here. But then I guess we may want to reject
> attempts for a domain to do any of this to itself.
For PCI passthrough we strictly need the PHYSDEVOP_{un,}map_pirq
because that's the only way QEMU currently has to allocate MSI(-X)
vectors from physical devices in order to assign to guests. We could
see about moving those to DM ops maybe in the future, as I think it
would be clearer, but that shouldn't block the work here.
If we start allowing PVH domains to use PIRQs we must enforce that
PIRQ cannot be mapped to event channels, IOW, block
EVTCHNOP_bind_pirq.
Thanks, Roger.
