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

Re: [Xen-devel] HVMlite ABI specification DRAFT A



>>> On 05.02.16 at 10:50, <roger.pau@xxxxxxxxxx> 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).

>>>>  * `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.

Jan


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


 


Rackspace

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