From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Subject: Re: [PATCH v4 6/6] x86/HVM: report the set of enabled emulated devices through CPUID Date: Fri, 22 Jan 2016 16:41:55 +0100 Message-ID: <56A24DC3.7080602@citrix.com> References: <1453395092-88090-1-git-send-email-roger.pau@citrix.com> <1453395092-88090-7-git-send-email-roger.pau@citrix.com> <56A2193202000078000C9FC1@prv-mh.provo.novell.com> <56A223F0.8020005@citrix.com> <56A23BBA02000078000CA145@prv-mh.provo.novell.com> <56A23F9C.7040908@citrix.com> <56A252AD02000078000CA2FC@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aMdqa-0002Zj-SD for xen-devel@lists.xenproject.org; Fri, 22 Jan 2016 15:42:00 +0000 In-Reply-To: <56A252AD02000078000CA2FC@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org El 22/01/16 a les 16.02, Jan Beulich ha escrit: >>>> On 22.01.16 at 15:41, wrote: >> El 22/01/16 a les 14.24, Jan Beulich ha escrit: >>>>>> On 22.01.16 at 13:43, 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. Oh yes, that's certainly not a problem for FreeBSD. I've already replaced the usage of the PIT during early boot with the PV timer. I was just pointing this out in order to make it easier for other OSes to adopt HVMlite, I wouldn't be surprised to find out that other OSes also use the PIT as an early source for delay available universally. >>>> 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. Ack. Roger.