All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Roger Pau Monne <roger.pau@citrix.com>
Cc: Juergen Gross <jgross@suse.com>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [RFC] xen/pvh: detect PVH after kexec
Date: Tue, 21 Mar 2017 11:00:50 +0000	[thread overview]
Message-ID: <937a44af-2b07-7af7-576c-9f07522f7b7c@citrix.com> (raw)
In-Reply-To: <58D1119402000078001459A9@prv-mh.provo.novell.com>

On 21/03/17 10:42, Jan Beulich wrote:
>>>> On 21.03.17 at 11:21, <roger.pau@citrix.com> wrote:
>> On Tue, Mar 21, 2017 at 04:07:51AM -0600, Jan Beulich wrote:
>>>>>> On 21.03.17 at 11:01, <roger.pau@citrix.com> wrote:
>>>> On Tue, Mar 21, 2017 at 10:21:52AM +0100, Vitaly Kuznetsov wrote:
>>>>> Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:
>>>>>
>>>>>> On 03/20/2017 02:20 PM, Vitaly Kuznetsov wrote:
>>>>>>> PVH guests after kexec boot like normal HVM guests and we're not entering
>>>>>>> xen_prepare_pvh()
>>>>>> Is it not? Aren't we going via xen_hvm_shutdown() and then
>>>>>> SHUTDOWN_soft_reset which would restart at the same entry point as
>>>>>> regular boot?
>>>>> No, we're not doing regular boot: from outside of the guest we don't
>>>>> really know where the new kernel is placed (as guest does it on its
>>>>> own). We do soft reset to clean things up and then guest jumps to the
>>>>> new kernel starting point by itself.
>>>>>
>>>>> We could (in theory, didn't try) make it jump to the PVH starting point
>>>>> but we'll have to at least prepare the right boot params for
>>>>> init_pvh_bootparams and this looks like additional
>>>>> complication. PVHVM-style startup suits us well but we still need to be
>>>>> PVH-aware.
>>>> We are going to have the same issue when booting PVH with OVMF, Linux will 
>> be
>>>> started at the native UEFI entry point, and we will need some way to detect
>>>> that we are running in PVH mode.
>>> I'm confused: PVH boots without any firmware, doesn't it? Hence
>>> it shouldn't matter if there's no (legacy) BIOS or no OVMF ...
>> Right now yes, we have no firmware available to PVH at all, but Anthony is
>> already working on porting OVMF to PVH [0].
> But that leaves open the "why" aspect: What use is OVMF to a
> PVH guest?

1) To work around the massive security attack surface of PV guests.
2) Because we think we can boot windows without Qemu in this way.

With my XenServer hat on, this is an absolute must.  I want to be
loading a single hvmloader-like-thing (pvhloader?) from dom0, which can
then chainload the guests preferred bootloader, parse filesystems and
kernels, all in guest context rather than dom0 context.

This also means that when the guest switches to a new filesystem, or
linux change their compression, no dom0 modifications are required.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-03-21 11:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20 18:20 [RFC] xen/pvh: detect PVH after kexec Vitaly Kuznetsov
2017-03-20 20:21 ` Boris Ostrovsky
2017-03-21  9:21   ` Vitaly Kuznetsov
2017-03-21 10:01     ` Roger Pau Monne
2017-03-21 10:07       ` Roger Pau Monne
2017-03-21 10:07       ` Jan Beulich
2017-03-21 10:21         ` Roger Pau Monne
2017-03-21 10:42           ` Jan Beulich
2017-03-21 10:59             ` Roger Pau Monne
2017-03-21 11:00             ` Andrew Cooper [this message]
2017-03-21 11:53       ` Vitaly Kuznetsov
2017-03-21 12:13         ` Roger Pau Monne
2017-03-21 14:05           ` Boris Ostrovsky
2017-03-21 14:16             ` Roger Pau Monne
2017-03-21 15:01               ` Boris Ostrovsky
2017-03-21 14:35             ` Vitaly Kuznetsov
2017-03-21 14:44         ` Vitaly Kuznetsov
2017-03-21 15:14           ` Boris Ostrovsky
2017-03-21 17:10             ` Vitaly Kuznetsov
2017-03-21 17:28               ` Roger Pau Monne

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=937a44af-2b07-7af7-576c-9f07522f7b7c@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=vkuznets@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.