mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Paolo Bonzini <pbonzini@redhat.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:24:02 +0100	[thread overview]
Message-ID: <136bd3b8-5301-84c9-9bdf-6ebf781f9256@suse.com> (raw)
In-Reply-To: <256b90df-547e-3287-d13f-3ffb346b4bc2@redhat.com>

On 08/11/17 13:03, Paolo Bonzini wrote:
> 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.

A HVM domain does so, too. Today maybe only partially, but e.g. event
channels work in a HVM domain even without the Xen platform device.
Grant tables can be made working without the platform device, too,
and I'm already preparing a patch to do exactly that.

The only need for the platform device will then be to have an
interface for unplugging emulated boot devices in favor of the pv
devices. And without the platform device we can just skip that
step without doing any harm, as this can happen only for PVH where
we have no need to do the unplug, or for HVM explicitly configured
to work without platform device needing to continue using the
emulated devices as it is doing today in this case.


Juergen

  reply	other threads:[~2017-11-08 12:24 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
2017-11-08 12:24         ` Juergen Gross [this message]
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=136bd3b8-5301-84c9-9bdf-6ebf781f9256@suse.com \
    --to=jgross@suse.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=hpa@zytor.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=pbonzini@redhat.com \
    --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®