Re: HVMlite ABI specification DRAFT A

["Roger Pau Monné" <roger.pau@citrix.com>]

El 5/2/16 a les 10:12, Jan Beulich ha escrit:
>>>> On 04.02.16 at 19:22, <andrew.cooper3@citrix.com> wrote:
>> On 04/02/16 17:48, Roger Pau Monné wrote:
>>>  - HVMlite hardware domain: can we get rid of the PHYSDEV ops and PIRQ 
>>>    event channels?
>>>  - HVMlite PCI-passthrough: can we get rid of pciback/pcifront?
>>
>> +1000, for both.
> 
> I'm a little lost here: However nice that would be, how do you
> envision this to work? For the first one, as pointed out before,
> there are physdevops which the hardware domain needs to
> issue to assist Xen (as a result of parsing and executing AML).
> And for the second one, something needs to translate virtual
> guest PCI topology to host physical one as well as mediate
> config space accesses.

I've got a little carried over in this first statement, inside of the
"ACPI" section in the document below there's a list of physdevops that
we cannot get rid of, however that's considerably smaller than the
current set. We are at least going to keep PHYSDEVOP_pci_device_add and
PHYSDEVOP_pci_mmcfg_reserved.

Regarding PIRQs, for MSI/MSI-X I think we already have the ability to
trap and emulate IIRC, which should allow us to detect when the hardware
domain is trying to set them and act consequently. Xen should receive
the native interrupts and inject them to the guest, but I assume this is
quite similar to what's already done for PCI-passthrough.

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).

As for PCI config space accesses, don't we already do that? We trap on
access to the 0xcf8 io port.

>>>  * `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)?

Roger.

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