Re: HVMlite ABI specification DRAFT A

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 05/02/16 10:40, Jan Beulich wrote:
>>>> On 05.02.16 at 10:50, <roger.pau@citrix.com> wrote:
>> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
>> to properly setup the lines/overwrites and inject the interrupts that
>> are not handled by Xen straight into the hardware domain. This will
>> require us to be able to emulate the same topology as what is found in
>> native (eg: if there are two IO APICs in the hardware we should also
>> provide two emulated ones to the hw domain).
> I don't think MADT contains all the needed information, or else we
> wouldn't need PHYSDEVOP_setup_gsi.
>
>> As for PCI config space accesses, don't we already do that? We trap on
>> access to the 0xcf8 io port.
> We intercept that, but iirc we do no translation (and for DomU
> these get forwarded to qemu anyway).

This is one aspect which will change with the proposed plans to have a
small host bridge/root complex in Xen.

Currently, cf8/cf8 handling is already done partly in Xen because of
multiple ioreq server handling.  However, the current setup completely
fails if the guest attempts to renumber the PCI Buses, and requires each
ioreq server to coordinate with their introduced topology.

A small host bridge and root complex in Xen solves all of these problems
for us, reduces the number of broadcast ioreqs Xen needs to make, and
allows multiple ioreq servers to function completely without any
self-coordination.

>
>>>>>  * `eflags`: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared.
>>>>>    Bit 8 (TF) must be cleared. Other bits are all unspecified.
>>>> I would also specify that the direction flag shall be clear, to prevent
>>>> all kernels needing to `cld` on entry.
>>> In which case IOPL and AC state should perhaps also be nailed down?
>>> Possibly even all of the control ones (leaving only the status flags
>>> unspecified)?
>> Status flag? Why don't we just say that all user-settable bits in the
>> status register will be set to 0 (or cleared)?
> Would be an option too.

What about the ID bit, which probably ought to be set?

~Andrew