mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Juergen Gross <jgross@suse.com>, Jan Beulich <JBeulich@suse.com>
Cc: len.brown@intel.com, x86@kernel.org, tglx@linutronix.de,
	xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com,
	mingo@redhat.com, rkrcmar@redhat.com, rjw@rjwysocki.net,
	pavel@ucw.cz, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	hpa@zytor.com
Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest
Date: Wed, 8 Nov 2017 13:03:44 +0100	[thread overview]
Message-ID: <256b90df-547e-3287-d13f-3ffb346b4bc2@redhat.com> (raw)
In-Reply-To: <aca21edf-bbfa-4911-d79b-bd5e2280ab33@suse.com>

On 08/11/2017 12:55, Juergen Gross wrote:
> On 08/11/17 12:18, Jan Beulich wrote:
>>>>> On 08.11.17 at 10:07, <jgross@suse.com> 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 understanding of Xen is very rusty at this point, but I think a
"completely" legacy-free HVM domain will still have a PCI bus and the
Xen platform device on that bus.

A PVH domain just knows how to access the Xen PV features.

Paolo

  reply	other threads:[~2017-11-08 12:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08  9:07 [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path Juergen Gross
2017-11-08  9:07 ` [PATCH 1/3] x86/acpi: add test for ACPI_FADT_NO_VGA Juergen Gross
2017-11-08  9:07 ` [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86 structure Juergen Gross
2017-11-08  9:13   ` Ingo Molnar
2017-11-08  9:27     ` Juergen Gross
2017-11-08  9:40       ` Ingo Molnar
2017-11-08  9:49         ` Juergen Gross
2017-11-08  9:58           ` Ingo Molnar
2017-11-08  9:53   ` Paolo Bonzini
2017-11-08  9:07 ` [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest Juergen Gross
2017-11-08 11:18   ` [Xen-devel] " Jan Beulich
     [not found]   ` <5A02F633020000780018D26A@suse.com>
2017-11-08 11:55     ` Juergen Gross
2017-11-08 12:03       ` Paolo Bonzini [this message]
2017-11-08 12:24         ` Juergen Gross
2017-11-08 12:26           ` Paolo Bonzini
2017-11-08 12:40             ` Juergen Gross
2017-11-08 12:31       ` Jan Beulich
2017-11-08 12:45         ` Juergen Gross
2017-11-08 12:58           ` Jan Beulich
     [not found]           ` <5A030D78020000780018D37B@suse.com>
2017-11-08 13:36             ` Juergen Gross
2017-11-08 14:10               ` Boris Ostrovsky
2017-11-08 14:17                 ` Juergen Gross
2017-11-08 14:24                   ` Boris Ostrovsky
2017-11-08 13:37 ` [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path Boris Ostrovsky
2017-11-08 13:40   ` Juergen Gross
2017-11-08 13:47     ` Boris Ostrovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=256b90df-547e-3287-d13f-3ffb346b4bc2@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=kvm@vger.kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®