[PATCH v1 0/8]: PVH (PV guest with extensions)

[PATCH v1 0/8]: PVH (PV guest with extensions)

[Mukesh Rathor]

Hi guys,

Ok, I've made all the changes from prev RFC patch submission. Tested
all the combinations. The patches are a bit smaller from before, and
couldn't be separated like before, so I can't state whats different in
each patch. But, it's not too bad to review now.

As before, they were built on top of
fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
        
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

thanks,
Mukesh

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)u

[Stefano Stabellini]

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.
> 
> As before, they were built on top of
> fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
>         
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

The patch series is not in a bad state. It is reasonable to aim for a
merge in 3.8.
At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
which interfaces are going to be shared with Xen on ARM ;-)

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)u

[Ian Campbell]

On Mon, 2012-09-24 at 16:16 +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> The patch series is not in a bad state. It is reasonable to aim for a
> merge in 3.8.
> At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> which interfaces are going to be shared with Xen on ARM ;-)

Indeed, I intend to rebase my ARM patches to use these ASAP, if not this
week then when I get back from my long weekend vacation next week.

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)u

[Konrad Rzeszutek Wilk]

On Mon, Sep 24, 2012 at 04:16:29PM +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I took them for a spin over the weekend and stuck them on top of my
#linux-next - 

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh

which worked well as PV guest (dom0, domU, etc). It didn't do too well
as PVHVM guest, but that might be just that some of the 'if (xen..)'
are properly not set or I mismerged badly. The later is probably likely as
I did screw it up at least twice (as you can see from my log).

Hm, let me give them also a whirl on top of fc6bdb59a501740b28ed3b616641a22c8dc5dd31

> 
> The patch series is not in a bad state. It is reasonable to aim for a
> merge in 3.8.
> At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> which interfaces are going to be shared with Xen on ARM ;-)

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)u

[Konrad Rzeszutek Wilk]

On Mon, Sep 24, 2012 at 11:29:51AM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 24, 2012 at 04:16:29PM +0100, Stefano Stabellini wrote:
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> I took them for a spin over the weekend and stuck them on top of my
> #linux-next - 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh
> 
> which worked well as PV guest (dom0, domU, etc). It didn't do too well
> as PVHVM guest, but that might be just that some of the 'if (xen..)'
> are properly not set or I mismerged badly. The later is probably likely as
> I did screw it up at least twice (as you can see from my log).
> 
> Hm, let me give them also a whirl on top of fc6bdb59a501740b28ed3b616641a22c8dc5dd31

And with 3683243b2c551e58082b179fd153c7d43ddc503b applied on top of it
I boots just fine. So I had to mess up the merge somehow.

> 
> > 
> > The patch series is not in a bad state. It is reasonable to aim for a
> > merge in 3.8.
> > At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> > which interfaces are going to be shared with Xen on ARM ;-)

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.

FYI I've actually read through all of them, I just didn't have much to
say because Stefano already said most of what I would have said.

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission.

Did I miss the patch with the changes to arch/x86/xen/xen-head.S which
declare the features which are used here as supported by the kernel
image?

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.
> 
> As before, they were built on top of
> fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
>         
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Is that correct? That's this commit:

commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
Merge: 44d82e2 1fcfd08
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Aug 2 11:52:39 2012 -0700

Why so old? Makes it hard to take these for a spin due to the
rebasing...

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Konrad Rzeszutek Wilk]

On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> Is that correct? That's this commit:
> 
> commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> Merge: 44d82e2 1fcfd08
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu Aug 2 11:52:39 2012 -0700
> 
> Why so old? Makes it hard to take these for a spin due to the
> rebasing...

I rebased them on top v3.6-rc6 (look in #linux-next-pvh) but I must
have done something wrong b/c it won't boot as PVHVM. Time to do some git
bisection and see where I failed.

> 
> Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Konrad Rzeszutek Wilk]

On Wed, Sep 26, 2012 at 09:37:36AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > 
> > Is that correct? That's this commit:
> > 
> > commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> > Merge: 44d82e2 1fcfd08
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Thu Aug 2 11:52:39 2012 -0700
> > 
> > Why so old? Makes it hard to take these for a spin due to the
> > rebasing...
> 
> I rebased them on top v3.6-rc6 (look in #linux-next-pvh) but I must
> have done something wrong b/c it won't boot as PVHVM. Time to do some git
> bisection and see where I failed.

Culprit found. I've rebased and added some of my patches to the branch.
They are on top of v3.6-rc6 + patches going in for v3.7.

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Wed, 2012-09-26 at 14:37 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > 
> > Is that correct? That's this commit:
> > 
> > commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> > Merge: 44d82e2 1fcfd08
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Thu Aug 2 11:52:39 2012 -0700
> > 
> > Why so old? Makes it hard to take these for a spin due to the
> > rebasing...
> 
> I rebased them on top v3.6-rc6 (look in #linux-next-pvh)

I found this, thanks.

>  but I must
> have done something wrong b/c it won't boot as PVHVM. Time to do some git
> bisection and see where I failed.

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Mukesh Rathor]

On Tue, 25 Sep 2012 14:54:23 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission.
> 
> Did I miss the patch with the changes to arch/x86/xen/xen-head.S which
> declare the features which are used here as supported by the kernel
> image?
> 
> Ian.
> 

Strange, adding following to head.S

        ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
        ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------

and xenstore won't start in dom0. What gives?

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote:
> On Tue, 25 Sep 2012 14:54:23 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission.
> > 
> > Did I miss the patch with the changes to arch/x86/xen/xen-head.S which
> > declare the features which are used here as supported by the kernel
> > image?
> > 
> > Ian.
> > 
> 
> Strange, adding following to head.S
> 
>         ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
>         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------
> 
> and xenstore won't start in dom0. What gives?

I have no idea, I can't think of any way that xenstored would be able to
even see the notes given in the dom0 kernel image.

Are you sure you only that one exact change?



Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Konrad Rzeszutek Wilk]

On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote:
> On Tue, 25 Sep 2012 14:54:23 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission.
> > 
> > Did I miss the patch with the changes to arch/x86/xen/xen-head.S which
> > declare the features which are used here as supported by the kernel
> > image?
> > 
> > Ian.
> > 
> 
> Strange, adding following to head.S
> 
>         ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
>         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------
> 
> and xenstore won't start in dom0. What gives?

What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value
that is defined for a different purpose? Did you check the Xen hypervisor
header files?

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Mukesh Rathor]

On Tue, 2 Oct 2012 09:09:11 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote:
> > On Tue, 25 Sep 2012 14:54:23 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > > Hi guys,
> > > > 
> > > > Ok, I've made all the changes from prev RFC patch submission.
> > > 
> > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S
> > > which declare the features which are used here as supported by
> > > the kernel image?
> > > 
> > > Ian.
> > > 
> > 
> > Strange, adding following to head.S
> > 
> >         ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
> >         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------
> > 
> > and xenstore won't start in dom0. What gives?
> 
> What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value
> that is defined for a different purpose? Did you check the Xen
> hypervisor header files?

Ah, right. I was looking at linux header file, which is behind xen.

Thanks konrad.

Mukesh

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote:
> On Tue, 2 Oct 2012 09:09:11 -0400
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > On Mon, Oct 01, 2012 at 02:28:26PM -0700, Mukesh Rathor wrote:
> > > On Tue, 25 Sep 2012 14:54:23 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > 
> > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > > > Hi guys,
> > > > > 
> > > > > Ok, I've made all the changes from prev RFC patch submission.
> > > > 
> > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S
> > > > which declare the features which are used here as supported by
> > > > the kernel image?
> > > > 
> > > > Ian.
> > > > 
> > > 
> > > Strange, adding following to head.S
> > > 
> > >         ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
> > >         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------
> > > 
> > > and xenstore won't start in dom0. What gives?
> > 
> > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a value
> > that is defined for a different purpose? Did you check the Xen
> > hypervisor header files?
> 
> Ah, right. I was looking at linux header file, which is behind xen.

Phew!

You are going to add the other features which PVH uses too, right?

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Mukesh Rathor]

On Tue, 2 Oct 2012 10:35:28 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote:
> > On Tue, 25 Sep 2012 14:54:23 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > > Hi guys,
> > > > 
> > > > Ok, I've made all the changes from prev RFC patch submission.
> > > 
> > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S
> > > which declare the features which are used here as supported by
> > > the kernel image?
> > > 
> > > Ian.
> > > 
> > 
> > Strange, adding following to head.S
> > 
> >         ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
> >         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------
> > 
> > and xenstore won't start in dom0. What gives?
> 
> I have no idea, I can't think of any way that xenstored would be able
> to even see the notes given in the dom0 kernel image.
> 
> Are you sure you only that one exact change?

You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it
XEN_ELFNOTE_PV_EXTENSIONS. Please LMK.

tanks
Mukesh

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Konrad Rzeszutek Wilk]

On Wed, Oct 03, 2012 at 12:11:22PM -0700, Mukesh Rathor wrote:
> On Tue, 2 Oct 2012 10:35:28 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-10-01 at 22:28 +0100, Mukesh Rathor wrote:
> > > On Tue, 25 Sep 2012 14:54:23 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > 
> > > > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > > > Hi guys,
> > > > > 
> > > > > Ok, I've made all the changes from prev RFC patch submission.
> > > > 
> > > > Did I miss the patch with the changes to arch/x86/xen/xen-head.S
> > > > which declare the features which are used here as supported by
> > > > the kernel image?
> > > > 
> > > > Ian.
> > > > 
> > > 
> > > Strange, adding following to head.S
> > > 
> > >         ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
> > >         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------
> > > 
> > > and xenstore won't start in dom0. What gives?
> > 
> > I have no idea, I can't think of any way that xenstored would be able
> > to even see the notes given in the dom0 kernel image.
> > 
> > Are you sure you only that one exact change?
> 
> You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it
> XEN_ELFNOTE_PV_EXTENSIONS. Please LMK.

XEN_ELFNOTE_PVH_FEATURES ?

That way you can fill it with different 'features' flags
if need to. Say 1<<1 is basic, etc.


> 
> tanks
> Mukesh

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Mukesh Rathor]

On Wed, 3 Oct 2012 11:24:04 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote:
> > On Tue, 2 Oct 2012 09:09:11 -0400
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
 > > 
> > > > Strange, adding following to head.S
> > > > 
> > > >         ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
> > > >         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------
> > > > 
> > > > and xenstore won't start in dom0. What gives?
> > > 
> > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a
> > > value that is defined for a different purpose? Did you check the
> > > Xen hypervisor header files?
> > 
> > Ah, right. I was looking at linux header file, which is behind xen.
> 
> Phew!
> 
> You are going to add the other features which PVH uses too, right?
> 
> Ian.
> 

Sorry, confused. Not very familiar with this. You mean, something like:

        ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH,      .long 1)
        ELFNOTE(Xen, XEN_ELFNOTE_PVH_FEATURES,  .asciz "writable_page_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector")

Something like this?

thanks
Mukesh

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote:
> > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it
> > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK.

My intention was that you add XENFEAT_supervisor_mode_kernel et al. to
the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new
note. I some how missed that this is what you were doing above. e.g.
what I meant was:

in Kconfig:
config XEN_X86_PVH
	bool "Support for running as a PVH guest (EXPERIMENTAL)"
	depends X86_64 && <..etc..> && EXPERIMENTAL
	help
                        This option enables support for running as a PVH
                        guest (PV guest using hardware extensions) under
                        a suitably capable hypervisor.
                        
                        This option is EXPERIMETNAL because the
                        hypervisor interfaces which it uses are not yet
                        considered stable therefore backwards and
                        forwards compatibility is not yet guaranteed.
                        
                        If unsure, say N.

Adjust the depends to suit reality.

I thought we had that second paragraph for ARM too, but it seems like I
was wrong, we should probably add it.

then in xen-head.S (adjusted for features actually used by PVH):
#ifdef CONFIG_XEN_X86_PVH
#define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \
		     "XENFEAT_auto_translated_physmap|" \
		     "XENFEAT_supervisor_mode_kernel" \
		     "XENFEAT_hvm_callback_vector"
#else
#define FEATURES_PVH /* Not supported */
#endif
...
ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
...

I don't think we need to define a XENFEAT_pvh (or whatever it might be
called) since don't need it in the code so there's no need to define/use
it here. If/when we need something like that we can add it, or
preferably some more specific thing for the use case which crops up.

> XEN_ELFNOTE_PVH_FEATURES ?
> 
> That way you can fill it with different 'features' flags
> if need to. Say 1<<1 is basic, etc.

I don't think we need a PVH specific ELF note which just replicates the
XENFEAT infrastructure at this stage, if we do come to that then it
would be better to give PVH its own leaf in the existing feature space
(e.g. starting at 1*32+0).

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Wed, 2012-10-03 at 23:26 +0100, Mukesh Rathor wrote:
> On Wed, 3 Oct 2012 11:24:04 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Tue, 2012-10-02 at 19:55 +0100, Mukesh Rathor wrote:
> > > On Tue, 2 Oct 2012 09:09:11 -0400
> > > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > 
>  > > 
> > > > > Strange, adding following to head.S
> > > > > 
> > > > >         ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   _ASM_PTR 0)
> > > > >         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH, .long 1)  <--------
> > > > > 
> > > > > and xenstore won't start in dom0. What gives?
> > > > 
> > > > What is XEN_ELFNOTE_GUEST_PVH number? You might be re-using a
> > > > value that is defined for a different purpose? Did you check the
> > > > Xen hypervisor header files?
> > > 
> > > Ah, right. I was looking at linux header file, which is behind xen.
> > 
> > Phew!
> > 
> > You are going to add the other features which PVH uses too, right?
> > 
> > Ian.
> > 
> 
> Sorry, confused. Not very familiar with this. You mean, something like:
> 
>         ELFNOTE(Xen, XEN_ELFNOTE_GUEST_PVH,      .long 1)
>         ELFNOTE(Xen, XEN_ELFNOTE_PVH_FEATURES,  .asciz "writable_page_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector")
> 
> Something like this?

Nearly, I meant to add them to the existing features note.

I just replied to the previous mail with some more detail.

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Konrad Rzeszutek Wilk]

On Thu, Oct 4, 2012 at 4:15 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote:
>> > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it
>> > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK.
>
> My intention was that you add XENFEAT_supervisor_mode_kernel et al. to
> the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new
> note. I some how missed that this is what you were doing above. e.g.
> what I meant was:
>
> in Kconfig:
> config XEN_X86_PVH
>         bool "Support for running as a PVH guest (EXPERIMENTAL)"
>         depends X86_64 && <..etc..> && EXPERIMENTAL
>         help
>                         This option enables support for running as a PVH
>                         guest (PV guest using hardware extensions) under
>                         a suitably capable hypervisor.
>
>                         This option is EXPERIMETNAL because the
>                         hypervisor interfaces which it uses are not yet
>                         considered stable therefore backwards and
>                         forwards compatibility is not yet guaranteed.
>
>                         If unsure, say N.
>
> Adjust the depends to suit reality.
>
> I thought we had that second paragraph for ARM too, but it seems like I
> was wrong, we should probably add it.
>
> then in xen-head.S (adjusted for features actually used by PVH):
> #ifdef CONFIG_XEN_X86_PVH
> #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \
>                      "XENFEAT_auto_translated_physmap|" \
>                      "XENFEAT_supervisor_mode_kernel" \
>                      "XENFEAT_hvm_callback_vector"
> #else
> #define FEATURES_PVH /* Not supported */
> #endif
> ...
> ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)

As long as those new fields exists with the older hypervisors - that
is OK. If you define new
ones the old hypervisors (say Xen 4.1) will refuse booting the kernel.

> ...
>
> I don't think we need to define a XENFEAT_pvh (or whatever it might be
> called) since don't need it in the code so there's no need to define/use
> it here. If/when we need something like that we can add it, or
> preferably some more specific thing for the use case which crops up.
>
>> XEN_ELFNOTE_PVH_FEATURES ?
>>
>> That way you can fill it with different 'features' flags
>> if need to. Say 1<<1 is basic, etc.
>
> I don't think we need a PVH specific ELF note which just replicates the
> XENFEAT infrastructure at this stage, if we do come to that then it
> would be better to give PVH its own leaf in the existing feature space
> (e.g. starting at 1*32+0).
>
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Ian Campbell]

On Thu, 2012-10-04 at 13:52 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 4, 2012 at 4:15 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote:
> >> > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it
> >> > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK.
> >
> > My intention was that you add XENFEAT_supervisor_mode_kernel et al. to
> > the existing XEN_ELFNOTE_FEATURES note rather than adding a whole new
> > note. I some how missed that this is what you were doing above. e.g.
> > what I meant was:
> >
> > in Kconfig:
> > config XEN_X86_PVH
> >         bool "Support for running as a PVH guest (EXPERIMENTAL)"
> >         depends X86_64 && <..etc..> && EXPERIMENTAL
> >         help
> >                         This option enables support for running as a PVH
> >                         guest (PV guest using hardware extensions) under
> >                         a suitably capable hypervisor.
> >
> >                         This option is EXPERIMETNAL because the
> >                         hypervisor interfaces which it uses are not yet
> >                         considered stable therefore backwards and
> >                         forwards compatibility is not yet guaranteed.
> >
> >                         If unsure, say N.
> >
> > Adjust the depends to suit reality.
> >
> > I thought we had that second paragraph for ARM too, but it seems like I
> > was wrong, we should probably add it.
> >
> > then in xen-head.S (adjusted for features actually used by PVH):
> > #ifdef CONFIG_XEN_X86_PVH
> > #define FEATURES_PVH "XENFEAT_writable_descriptor_tables|" \
> >                      "XENFEAT_auto_translated_physmap|" \
> >                      "XENFEAT_supervisor_mode_kernel" \
> >                      "XENFEAT_hvm_callback_vector"
> > #else
> > #define FEATURES_PVH /* Not supported */
> > #endif
> > ...
> > ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz "!writable_page_tables|pae_pgdir_above_4gb"FEATURES_PVH)
> 
> As long as those new fields exists with the older hypervisors - that
> is OK. If you define new
> ones the old hypervisors (say Xen 4.1) will refuse booting the kernel.

The note declares features which can be supported by this kernel but
they are not mandatory unless you prefix them with a "!" so assuming you
don't put a ! in an older hypervisor will boot the kernel just fine. It
just won't enable PVH, which is what we want.

Ian.

Re: [PATCH v1 0/8]: PVH (PV guest with extensions)

[Mukesh Rathor]

On Thu, 4 Oct 2012 09:15:26 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-10-03 at 21:39 +0100, Konrad Rzeszutek Wilk wrote:
> > > You Ok with XEN_ELFNOTE_GUEST_PVH, or should I call it
> > > XEN_ELFNOTE_PV_EXTENSIONS. Please LMK.
> 
> 
> > XEN_ELFNOTE_PVH_FEATURES ?
> > 
> > That way you can fill it with different 'features' flags
> > if need to. Say 1<<1 is basic, etc.
> 
> I don't think we need a PVH specific ELF note which just replicates
> the XENFEAT infrastructure at this stage, if we do come to that then
> it would be better to give PVH its own leaf in the existing feature
> space (e.g. starting at 1*32+0).
> 
> Ian.

Got it, thanks for the nice detailed note. I'll change it as above.

Mukesh