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

Re: [Xen-devel] [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID

>>> On 22.01.16 at 15:59, <roger.pau@xxxxxxxxxx> wrote:
> El 22/01/16 a les 14.34, Andrew Cooper ha escrit:
>> On 22/01/16 12:43, Roger Pau Monnà wrote:
>>> IOAPIC: tied to LAPIC (so either both enabled or none).
>> An IOAPIC is by no means required - they are only for turning legacy
>> interrupts into MSIs.  It would be perfectly fine for a PVH domain to
>> have an LAPIC and an SRIOV virtual function, without an IOAPIC at all.
>> The presence of LAPICs and IOAPICs reside in the MADT ACPI table.
> Right, so as said in the reply to Jan, we will require ACPI in order to
> enable any of this pieces. I don't have a problem with that, just wasn't
> sure if this requirement was desired.

The question is whether a non-Dom0 HVMlite guest needs any
of these in the first place. Because if it doesn't (and that's the
mode we provide right now), making them dependent on ACPI
availability should be quite fine: If we need them for some
purpose in the guest, we'd need to make ACPI tables available.

> If that's the plan, then I think we would also need to fixup the tables
> provided to Dom0 in order to match what's available, but that can be
> discussed later.

I don't see what you're getting at here: The IO-APIC information
should be usable as is for Dom0 (as is the case for PV).

>>> So, we have the following devices that are assumed to be there: RTC,
>>> PIC, PIT. Everything else I think can be signalled by other means
>>> already available.
>>> IMHO, I think we could say that the PIC is never going to be available
>>> to HVMlite guests (in any case we would enable the lapic/ioapic), and
>>> maybe enable the RTC and PIT by default?
>>> Then I think we could get away without any Xen-specific way of reporting
>>> enabled devices.
>> DMLite is a new container type.  I would far rather it was assumed that
>> there was no legacy hardware at all.
> So I take that you are in favour of only considering enabling the local
> APIC and IO APIC maybe for HVMlite, because of the performance benefits,
> while the other devices are _never_ going to be available to HVMlite
> guests/hosts at all? (Dom0 already gets the hw VGA)
> IMHO, I would like to be able to eventually enable them in order to
> provide an environment that's as close as possible to a compatible PC,
> in order to reduce the amount of changes required in order to port an OS
> to run in this mode.

I didn't think that's among the goals for HVMlite. Just like PV and PVH,
HVMlite requires OS awareness.


Xen-devel mailing list



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