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

From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID
Date: Fri, 22 Jan 2016 06:24:58 -0700	[thread overview]
Message-ID: <56A23BBA02000078000CA145@prv-mh.provo.novell.com> (raw)
In-Reply-To: <56A223F0.8020005@citrix.com>

>>> On 22.01.16 at 13:43, <roger.pau@citrix.com> wrote:
> RTC: I don't know of any way to signal the RTC presence, AFAICT it's
> always assumed to be there in the PC architecture. Could maybe return ~0
> when reading from IO port 0x71, but that's meh..., not the best way IMHO.

There actually is an RTC-absent flag in the FADT, which the
hypervisor itself actually looks at (ACPI_FADT_NO_CMOS_RTC).

> PIC: same as RTC, I don't know of any way to signal it's presence since
> it's assumed to be there.

I think PIC absence can also be gathered from ACPI
(ACPI_FADT_HW_REDUCED).

> VGA: again I don't think there's an easy way to signal it's presence,
> apart from returning ~0 from the multiple IO ports it uses. The fact
> that the 0xA0000-0xBFFFF memory range is also marked as RAM in the e820
> map in HVMlite DomUs should also trigger OSes into disabling VGA due to
> the lack of proper MMIO range, but sadly I think most OSes just assume
> it's there.

Yes, VGA is kind of more difficult. Looking at all PCI devices'
command words may provide a hint, as may looking at all PCI
bridges' bridge control words.

> PIT: assumed to be always present in the PC architecture.

See PIC above.

> PM: I'm leaning to split this into ACPI_PM and ACPI_TIMER as said
> before. ACPI_TIMER presence it's contained inside of ACPI tables, and
> the availability of ACPI_PM (power management) can be inferred from the
> presence of ACPI itself.

As indicated in the original discussion, I don't think these should
have been separate flags anyway - either you have ACPI (then
you have indication of both in FADT), or there is no ACPI.

> AMD guest IOMMU: AFAICT this seems to be currently disabled, since the
> MMIO range it checks is [~0ULL, ~0ULL + 0x8000]. There is a function to
> change the base address ~0ULL to something else, but it doesn't seem to
> be reachable from any path. In any case, I guess the presence of this
> device will be reported from ACPI.

Yes, the implementation is incomplete (abandoned?), but IOMMU
presence can always be determined by the guest through
inspecting its ACPI tables.

> 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?

That may be a sane initial setup, but with the ACPI flags named
above we may be able to expressed even their absence.

> Then I think we could get away without any Xen-specific way of reporting
> enabled devices.

Indeed - that should be the preferred goal.

Jan