From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752659AbdKHNgl (ORCPT ); Wed, 8 Nov 2017 08:36:41 -0500 Received: from mx2.suse.de ([195.135.220.15]:60870 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752376AbdKHNgj (ORCPT ); Wed, 8 Nov 2017 08:36:39 -0500 Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest To: Jan Beulich Cc: len.brown@intel.com, x86@kernel.org, tglx@linutronix.de, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, mingo@redhat.com, pbonzini@redhat.com, rkrcmar@redhat.com, rjw@rjwysocki.net, pavel@ucw.cz, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com References: <20171108090739.26491-1-jgross@suse.com> <20171108090739.26491-4-jgross@suse.com> <5A02F633020000780018D26A@suse.com> <5A030726020000780018D323@prv-mh.provo.novell.com> <37c2e2cc-4419-0adf-2f9c-ad7762c95cbd@suse.com> <5A030D78020000780018D37B@suse.com> From: Juergen Gross Message-ID: Date: Wed, 8 Nov 2017 14:36:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5A030D78020000780018D37B@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/11/17 13:58, Jan Beulich wrote: >>>> On 08.11.17 at 13:45, wrote: >> On 08/11/17 13:31, Jan Beulich wrote: >>>>>> On 08.11.17 at 12:55, wrote: >>>> On 08/11/17 12:18, Jan Beulich wrote: >>>>>>>> On 08.11.17 at 10:07, wrote: >>>>>> In case we are booted via the default boot entry by a generic loader >>>>>> like grub or OVMF it is necessary to distinguish between a HVM guest >>>>>> with a device model supporting legacy devices and a PVH guest without >>>>>> device model. >>>>>> >>>>>> PVH guests will always have x86_platform.legacy.no_vga set and >>>>>> x86_platform.legacy.rtc cleared, while both won't be true for HVM >>>>>> guests. >>>>>> >>>>>> Test for both conditions in the guest_late_init hook and set xen_pvh >>>>>> to true if they are met. >>>>> >>>>> This sounds pretty fragile to me: I can't see a reason why a proper >>>>> HVM guest couldn't come without VGA and RTC. That's not possible >>>>> today, agreed, but certainly an option down the road if virtualization >>>>> follows bare metal's road towards being legacy free. >>>> >>>> From guest's perspective: what is the difference between a legacy free >>>> HVM domain and PVH? In the end the need for differentiating is to avoid >>>> access to legacy features in PVH as those would require a device model. >>> >>> My point is that "legacy free" would likely be reached over time (and >>> even once fully reached, hybrid configurations would be possible). >>> I.e. there could be a setup with PIC, but with neither VGA nor RTC. >>> That's still not PVH then. Nor do all legacy features require a device >>> model in the first place - some of them are being emulated entirely >>> in the hypervisor. >>> >>> Furthermore, PVH absolutely requires guest awareness afaict, while >>> legacy-free pure HVM guests (with an OS only aware of the possible >>> absence of legacy devices) would still be possible. >> >> Hmm, where else do you expect PVH awareness to be required? Maybe for >> vcpu hotplugging, but this could easily be solved by adding a Xenstore >> entry containing the required information. Is there any other problem to >> be expected before Xenstore access is possible? > > Let me ask the question the other way around: What's all the PVH > specific code for under arch/x86/xen/ if there's no difference? One Most of it is for early boot when coming through the PVH specific boot entry. > thing I seem to remember is that getting hold of the ACPI tables > is different between PVH and HVM. Iirc the distinct PVH entry point > is (in part) for that purpose. In the end - with that separate entry > point - it is not really clear to me why any "detection" needs to be > done in the first place: You'd know which mode you're in by knowing > which entry point path you've taken. Its all in the commit message: I am trying to enable a boot loader to use the default kernel boot entry for PVH. This will reduce the needed modifications in the loader. Regarding ACPI tables: current PVH implementation in Linux kernel seems not to make use of the special information presented in the boot information block. Juergen