Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

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

On Mon, Oct 31, 2016 at 10:32:47AM -0600, Jan Beulich wrote:
> >>> On 29.10.16 at 10:59, <roger.pau@xxxxxxxxxx> wrote:
> > PVHv2 guests, unlike HVM guests, won't have the option to route interrupts
> > from physical or emulated devices over event channels using PIRQs. This
> > applies to both DomU and Dom0 PVHv2 guests.
> > 
> > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
> > route physical interrupts (even from emulated devices) over event channels,
> > and is thus allowed to use some of the PHYSDEV ops.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> The patch looks fine now for its purpose, but I'm hesitant to ack it
> without us having settled on whether we indeed mean to hide all
> those physdev ops from Dom0. In particular I don't recall this (and
> the reasoning behind it) having got written down somewhere.

I'm planning to add the following doc update together with this commit:

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 946908e..4fc757f 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,38 @@ info structure that's passed at boot time (field rsdp_paddr).
 
 Description of paravirtualized devices will come from XenStore, just as it's
 done for HVM guests.
+
+## Interrupts ##
+
+### Interrupts from physical devices ###
+
+Interrupts from physical devices are delivered using native methods, this is
+done in order to take advantage of new hardware assisted virtualization
+functions, like posted interrupts. This implies that PVHv2 guests with physical
+devices will also have the necessary interrupt controllers in order to manage
+the delivery of interrupts from those devices, using the same interfaces that
+are available on native hardware.
+
+### Interrupts from paravirtualized devices ###
+
+Interrupts from paravirtualized devices are delivered using event channels, see
+[Event Channel Internals][event_channels] for more detailed information about
+event channels. In order to inject interrupts into the guest an IDT vector is
+used. This is the same mechanism used on PVHVM guests, and allows having
+per-cpu interrupts that can be also used to deliver timers or IPIs if desired.
+
+In order to register the callback IDT vector the `HVMOP_set_param` hypercall
+is used with the following values:
+
+    domid = DOMID_SELF
+    index = HVM_PARAM_CALLBACK_IRQ
+    value = (0x2 << 56) | vector_value
+
+The OS has to program the IDT for the `vector_value` using the baremetal
+mechanism.
+
+In order to know which event channel has fired, we need to look into the
+information provided in the `shared_info` structure. The `evtchn_pending`
+array is used as a bitmap in order to find out which event channel has
+fired. Event channels can also be masked by setting it's port value in the
+`shared_info->evtchn_mask` bitmap.


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