All of lore.kernel.org
 help / color / mirror / Atom feed
* Guidance for PVHv2 usage?
@ 2017-05-29 15:58 PGNet Dev
  2017-05-29 17:03 ` Roger Pau Monné
  0 siblings, 1 reply; 5+ messages in thread
From: PGNet Dev @ 2017-05-29 15:58 UTC (permalink / raw)
  To: xen-devel

Starting with

	Xen Changes For Linux 4.11: Lands PVHv2 Guest Support
	https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.11-Xen-Changes

	[GIT PULL] xen: features and fixes for 4.11-rc0
	http://lkml.iu.edu/hypermail/linux/kernel/1702.2/03209.html

IIUC, Xen 4.9 + kernel-default > v4.11 should now fully support PVHv2?

I'm running Xen 4.9.0 host on kernel 4.11.3

	dmesg | egrep -i "linux version|xen version"
		[    0.000000] Linux version 4.11.3-2.g7262353-default (geeko@buildhost) (gcc version 7.1.1 20170517 [gcc-7-branch revision 248152] (SUSE Linux) ) #1 SMP PREEMPT Thu May 25 17:55:04 UTC 2017 (7262353)
		[    0.000000] Xen version: 4.9.0_07-503 (preserve-AD)

, both installed from pkgs built for an Opensuse Leap 42.2 env.

The docs @

	https://xenbits.xen.org/docs/unstable/misc/hvmlite.html
	https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#Support-for-Paravirtualisation-of-HVM-Guests

are not clear on usage.

This

	https://xenbits.xen.org/docs/unstable/misc/pvh.html

suggests that for

	PVH 
		...
		ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz, "generic")
		...

the .cfg spec'n should be

	builder='generic'

but, there's no mention of which value for specific PVHv2 usage.

Poking around, I've found discussion that PVH may be eventually retired, and replaced with PVHv2, with same usage.

Is that the case already?  Or is there a transition state in effect, where both are available?

Atm, I do have a 'converted' HVM guest booting into _some- form of PVH for testing.

My current setup -- cobbled together from old PVH notes and some older posts, contains, in Grub

	GRUB_CMDLINE_XEN="dom0=hvm dom0_mem=4G,max:4G dom0_max_vcpus=4 ..."
	                  ^^^^^^^^

and in Guest.cfg

	builder = 'linux'
	kernel = '/usr/lib/grub2/x86_64-xen/grub.xen'
	xen_platform_pci = 1
	device_model_version = 'qemu-xen'
	...

With that^, the guest *IS* up & , as far as I've tested, functional.

At current host & guest loglevels, I've not yet seen any errors  -- I'm just not yet clear whether it's successfully, or completely & correctly, PVHv2 ...

Bottom line -- 

What *IS* the config/usage for PVHv2?  (Any current docs available?)


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guidance for PVHv2 usage?
  2017-05-29 15:58 Guidance for PVHv2 usage? PGNet Dev
@ 2017-05-29 17:03 ` Roger Pau Monné
  2017-05-29 17:28   ` PGNet Dev
  0 siblings, 1 reply; 5+ messages in thread
From: Roger Pau Monné @ 2017-05-29 17:03 UTC (permalink / raw)
  To: PGNet Dev; +Cc: xen-devel

On Mon, May 29, 2017 at 08:58:04AM -0700, PGNet Dev wrote:
> Starting with
> 
> 	Xen Changes For Linux 4.11: Lands PVHv2 Guest Support
> 	https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.11-Xen-Changes
> 
> 	[GIT PULL] xen: features and fixes for 4.11-rc0
> 	http://lkml.iu.edu/hypermail/linux/kernel/1702.2/03209.html
> 
> IIUC, Xen 4.9 + kernel-default > v4.11 should now fully support PVHv2?

For DomUs yes, for Dom0 not yet.

> I'm running Xen 4.9.0 host on kernel 4.11.3
> 
> 	dmesg | egrep -i "linux version|xen version"
> 		[    0.000000] Linux version 4.11.3-2.g7262353-default (geeko@buildhost) (gcc version 7.1.1 20170517 [gcc-7-branch revision 248152] (SUSE Linux) ) #1 SMP PREEMPT Thu May 25 17:55:04 UTC 2017 (7262353)
> 		[    0.000000] Xen version: 4.9.0_07-503 (preserve-AD)
> 
> , both installed from pkgs built for an Opensuse Leap 42.2 env.
> 
> The docs @
> 
> 	https://xenbits.xen.org/docs/unstable/misc/hvmlite.html
> 	https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#Support-for-Paravirtualisation-of-HVM-Guests
> 
> are not clear on usage.
> 
> This
> 
> 	https://xenbits.xen.org/docs/unstable/misc/pvh.html
> 
> suggests that for
> 
> 	PVH 
> 		...
> 		ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz, "generic")
> 		...

Forget about this document, I should have removed it as part of the
PVHv1 code removal. In any case, those where PVHv1 internal details,
that are to no use to the end user.

> the .cfg spec'n should be
> 
> 	builder='generic'
> 
> but, there's no mention of which value for specific PVHv2 usage.
> 
> Poking around, I've found discussion that PVH may be eventually retired, and replaced with PVHv2, with same usage.
> 
> Is that the case already?  Or is there a transition state in effect, where both are available?

Almost, Xen is still currently transitioning from PVHv1 to PVHv2.
PVHv1 is not available anymore, and PVHv2 is still experimental (and
not finished in the Dom0 case).

> Atm, I do have a 'converted' HVM guest booting into _some- form of PVH for testing.
> 
> My current setup -- cobbled together from old PVH notes and some older posts, contains, in Grub
> 
> 	GRUB_CMDLINE_XEN="dom0=hvm dom0_mem=4G,max:4G dom0_max_vcpus=4 ..."
> 	                  ^^^^^^^^

I guess this is in the Dom0 grub config file? In any case, please
hold off before trying Dom0, it's still not in a working state.

> and in Guest.cfg
> 
> 	builder = 'linux'
> 	kernel = '/usr/lib/grub2/x86_64-xen/grub.xen'
> 	xen_platform_pci = 1
> 	device_model_version = 'qemu-xen'
> 	...

I'm not really sure what this guest is, PV I assume?

builder = 'linux' is not a valid option [0]. Also grub.xen (which I
imagine is pvgrub) is not going to work for PVHv2, you will have to
direct boot into the kernel you wish to use. For example a suitable
config file for PVHv2 would be:

builder='hvm'
device_model_version='none'

kernel='/path/to/kernel'
ramdisk='/path/to/initrd'

Note that this is a temporary interface, this is subject to change.

> 
> With that^, the guest *IS* up & , as far as I've tested, functional.
> 
> At current host & guest loglevels, I've not yet seen any errors  -- I'm just not yet clear whether it's successfully, or completely & correctly, PVHv2 ...
> 
> Bottom line -- 
> 
> What *IS* the config/usage for PVHv2?  (Any current docs available?)

Since the interface is not yet finished, no, there are no current docs
available, sorry.

Roger.

[0] http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html#Selecting-Guest-Type

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guidance for PVHv2 usage?
  2017-05-29 17:03 ` Roger Pau Monné
@ 2017-05-29 17:28   ` PGNet Dev
  2017-05-30  7:29     ` Roger Pau Monné
  0 siblings, 1 reply; 5+ messages in thread
From: PGNet Dev @ 2017-05-29 17:28 UTC (permalink / raw)
  To: Roger Pau Monné; +Cc: xen-devel

On 5/29/17 10:03 AM, Roger Pau Monné wrote:
>> IIUC, Xen 4.9 + kernel-default > v4.11 should now fully support PVHv2?
> 
> For DomUs yes, for Dom0 not yet.

thx

> Forget about this document, I should have removed it as part of the
> PVHv1 code removal. In any case, those where PVHv1 internal details,
> that are to no use to the end user.

noted

>> Is that the case already?  Or is there a transition state in effect, where both are available?
> 
> Almost, Xen is still currently transitioning from PVHv1 to PVHv2.
> PVHv1 is not available anymore, and PVHv2 is still experimental (and
> not finished in the Dom0 case).

Aha.  The still-experimental state wasn't immediately clear from the Phoronix article's "... Lands ..." title.

>> 	GRUB_CMDLINE_XEN="dom0=hvm dom0_mem=4G,max:4G dom0_max_vcpus=4 ..."
>> 	                  ^^^^^^^^
> 
> I guess this is in the Dom0 grub config file?

Yes / Sry, should've been clearer on that.

> In any case, please
> hold off before trying Dom0, it's still not in a working state.

Does "hold off" -- in this fuzzy interim -- simply mean -- do NOT specify any dom0=XXX?  Or to specify dom0=pvh, or somesuch?

>> and in Guest.cfg
>>
>> 	builder = 'linux'
>> 	kernel = '/usr/lib/grub2/x86_64-xen/grub.xen'
>> 	xen_platform_pci = 1
>> 	device_model_version = 'qemu-xen'
>> 	...
> 
> I'm not really sure what this guest is, PV I assume?

Heh.  Well, that's a good question.

It WAS hvm, and now it's TRYING to be PVHv2.  It's booted atm as SOMETHING ... I suppose it's 'still' PVH.

That^ config IS what I *used* to use for PVH on Opensuse ...

> builder = 'linux' is not a valid option [0].

It is -- or at least, WAS -- for Opensuse's Xen:

   https://lists.opensuse.org/opensuse-virtual/2016-01/msg00004.html

Also referenced here:

   https://patchwork.kernel.org/patch/9368403/


I've been running only HVM guests for awhile, so I am NOT certain that hasn't changed ...

In any case, the Guest *IS* launching with builder=linux, with no complaint at the moment.

Unclear, then, what that means if it is, in fact, NOT a valid option.

> Also grub.xen (which I imagine is pvgrub)

It's from grub2

 rpm -q --whatprovides /usr/lib/grub2/x86_64-xen/grub.xen
  grub2-x86_64-xen-2.02-3.3.x86_64

which I thought makes it pvgrub2?  Not that it matters since, apparently

> is not going to work for PVHv2,


> you will have to
> direct boot into the kernel you wish to use. For example a suitable
> config file for PVHv2 would be:
> 
> builder='hvm'
> device_model_version='none'
> 
> kernel='/path/to/kernel'
> ramdisk='/path/to/initrd'


so, just to be clear, for PVHv2, we'll use =HVM, not PVH (=generic), builder? Even given that PVHv1 is not available anymore, and it _sounds_ like PVHv2 will "replace" PVH?

> Note that this is a temporary interface, this is subject to change.

sure.  hence, 'testing' ...

> Since the interface is not yet finished, no, there are no current docs
> available, sorry.

Thanks.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guidance for PVHv2 usage?
  2017-05-29 17:28   ` PGNet Dev
@ 2017-05-30  7:29     ` Roger Pau Monné
  2017-05-30 12:34       ` PGNet Dev
  0 siblings, 1 reply; 5+ messages in thread
From: Roger Pau Monné @ 2017-05-30  7:29 UTC (permalink / raw)
  To: PGNet Dev; +Cc: xen-devel

On Mon, May 29, 2017 at 10:28:03AM -0700, PGNet Dev wrote:
> On 5/29/17 10:03 AM, Roger Pau Monné wrote:
[...]
> > In any case, please
> > hold off before trying Dom0, it's still not in a working state.
> 
> Does "hold off" -- in this fuzzy interim -- simply mean -- do NOT specify any dom0=XXX?  Or to specify dom0=pvh, or somesuch?

dom0=pvh is what should be used once it's finished. Right now there's
no PVHv2 Dom0 support in Linux, and the Xen side is not finished. If
you manage to get this booting, you are going to hit a panic in Xen
code [0].

> >> and in Guest.cfg
> >>
> >> 	builder = 'linux'
> >> 	kernel = '/usr/lib/grub2/x86_64-xen/grub.xen'
> >> 	xen_platform_pci = 1
> >> 	device_model_version = 'qemu-xen'
> >> 	...
> > 
> > I'm not really sure what this guest is, PV I assume?
> 
> Heh.  Well, that's a good question.
> 
> It WAS hvm, and now it's TRYING to be PVHv2.  It's booted atm as SOMETHING ... I suppose it's 'still' PVH.

I think you booted a PV guest.

> That^ config IS what I *used* to use for PVH on Opensuse ...
> 
> > builder = 'linux' is not a valid option [0].
> 
> It is -- or at least, WAS -- for Opensuse's Xen:
> 
>    https://lists.opensuse.org/opensuse-virtual/2016-01/msg00004.html
> 
> Also referenced here:
> 
>    https://patchwork.kernel.org/patch/9368403/

I think builder='linux' should be builder='generic' on the examples
above. It simply works because it's ignored and builder='generic' is
used as the default value.

[...]
> > you will have to
> > direct boot into the kernel you wish to use. For example a suitable
> > config file for PVHv2 would be:
> > 
> > builder='hvm'
> > device_model_version='none'
> > 
> > kernel='/path/to/kernel'
> > ramdisk='/path/to/initrd'
> 
> 
> so, just to be clear, for PVHv2, we'll use =HVM, not PVH (=generic), builder? Even given that PVHv1 is not available anymore, and it _sounds_ like PVHv2 will "replace" PVH?

For PVHv2 we want to use "pvh=1" in the config file. Sadly this is not
yet implemented, so the only way to boot a PVHv2 guest is using:

builder='hvm'
device_model_version='none'

Roger

[0] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/dom0_build.c;hb=HEAD#l1093

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Guidance for PVHv2 usage?
  2017-05-30  7:29     ` Roger Pau Monné
@ 2017-05-30 12:34       ` PGNet Dev
  0 siblings, 0 replies; 5+ messages in thread
From: PGNet Dev @ 2017-05-30 12:34 UTC (permalink / raw)
  To: Roger Pau Monné; +Cc: xen-devel

On 5/30/17 12:29 AM, Roger Pau Monné wrote:
...
> dom0=pvh is what should be used once it's finished. Right now there's
> no PVHv2 Dom0 support in Linux, and the Xen side is not finished. If
> you manage to get this booting, you are going to hit a panic in Xen
> code [0].
...> I think builder='linux' should be builder='generic' on the examples
> above. It simply works because it's ignored and builder='generic' is
> used as the default value.
...
> For PVHv2 we want to use "pvh=1" in the config file. Sadly this is not
> yet implemented, so the only way to boot a PVHv2 guest is using:
> 
> builder='hvm'
> device_model_version='none'
...
> [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/dom0_build.c;hb=HEAD#l1093

All clear & helpful, thanks.




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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-05-30 12:34 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-29 15:58 Guidance for PVHv2 usage? PGNet Dev
2017-05-29 17:03 ` Roger Pau Monné
2017-05-29 17:28   ` PGNet Dev
2017-05-30  7:29     ` Roger Pau Monné
2017-05-30 12:34       ` PGNet Dev

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.