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 08:02:53 -0700	[thread overview]
Message-ID: <56A252AD02000078000CA2FC@prv-mh.provo.novell.com> (raw)
In-Reply-To: <56A23F9C.7040908@citrix.com>

>>> On 22.01.16 at 15:41, <roger.pau@citrix.com> wrote:
> El 22/01/16 a les 14.24, Jan Beulich ha escrit:
>>>>> 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).
> 
> So most of this assumes that if we ever want to enable any of those
> devices we will provide ACPI tables to the guest?

We could check whether exposing SFI tables to the guest would
be a simpler mechanism allowing enough control.

In the absence of ACPI we need to settle on defaults: As Andrew
has said, contemporary logic would imply no legacy devices for an
environment that can be (made) aware of such.

> The RTC can also be used as an interrupt source, which I think it's not
> covered by the ACPI_FADT_NO_CMOS_RTC flag.

Certainly if there's no RTC device, then there's also no legacy
IRQ8.

>>> 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.
> 
> Hm that seems like a rather convoluted procedure, and this needs to be
> available very early on during the boot process usually.

As long as the legacy MMIO address range isn't re-used by some
other device, having an OS blindly write to that range is quite okay
(and common practice) I think. Iiuc you think about getting log
messages out early?

>>> PIT: assumed to be always present in the PC architecture.
>> 
>> See PIC above.
> 
> At least on FreeBSD PIT is used much earlier than parsing any ACPI
> tables (it's used to implement a busy-wait DELAY routine), so I don't
> think it's sensible to tie this device to ACPI. Also see my note above
> about requiring ACPI in order to signal all of this.

See above: Quite likely you will need to do away with using PIT when
run as HVMlite guest.

>>> 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.
> 
> I still think we should probably enable those, because they tend to be
> used very early on boot, before parsing ACPI tables, and in general are
> considered to be always there on PCs.

No if you think the modern legacy free way.

Jan