[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |