PV on HVM

PV on HVM

[Stefano Stabellini]

Hi all,
this is the updated version of the PV on HVM series: many bugs have been
fixed and VIRQ_TIMER support has been added.
In order to be able to use VIRQ_TIMER and to improve performances you
need two other patches to Xen to implement the vector callback mechanism
for event channel delivery and to export some time related hypercalls to
HVM guests too.

This series is based on a standard 2.6.32 tree, a git tree is also
available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git

branch name 2.6.32-pvhvm.

This is the first time I am using git send-email, if something goes
wrong you know why :)

Cheers,

Stefano

Re: PV on HVM

[Alex Bligh]

Stefano,

--On 10 May 2010 15:20:36 +0100 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> this is the updated version of the PV on HVM series: many bugs have been
> fixed and VIRQ_TIMER support has been added.
> In order to be able to use VIRQ_TIMER and to improve performances you
> need two other patches to Xen to implement the vector callback mechanism
> for event channel delivery and to export some time related hypercalls to
> HVM guests too.
>
> This series is based on a standard 2.6.32 tree, a git tree is also
> available here:
>
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git
>
> branch name 2.6.32-pvhvm.

This appears to a be complete kernel tree. It isn't immediately
obvious from the git log whether there are substantial differences
outside drivers/xen and include/xen? Are there any? Or should I be able
to simply import these directories into a distributor kernel tree
and compile from there?

One of the problems I found when doing this:
  http://blog.alex.org.uk/archives/23
is that the standard Ubuntu tree already has a xen directory,
leading to all sorts of amusing collisions, at compile time (in
terms of filename paths), and at link time (if CONFIG_XEN
is selected, and the idea is to build a kernel that works
both in paravirtualised guest mode and in HVM mode with PV
drivers). I got around the former, but not the latter.

-- 
Alex Bligh

Re: PV on HVM

[Stefano Stabellini]

On Mon, 10 May 2010, Alex Bligh wrote:
> Stefano,
> 
> --On 10 May 2010 15:20:36 +0100 Stefano Stabellini 
> <stefano.stabellini@eu.citrix.com> wrote:
> 
> > this is the updated version of the PV on HVM series: many bugs have been
> > fixed and VIRQ_TIMER support has been added.
> > In order to be able to use VIRQ_TIMER and to improve performances you
> > need two other patches to Xen to implement the vector callback mechanism
> > for event channel delivery and to export some time related hypercalls to
> > HVM guests too.
> >
> > This series is based on a standard 2.6.32 tree, a git tree is also
> > available here:
> >
> > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git
> >
> > branch name 2.6.32-pvhvm.
> 
> This appears to a be complete kernel tree. It isn't immediately
> obvious from the git log whether there are substantial differences
> outside drivers/xen and include/xen? Are there any? Or should I be able
> to simply import these directories into a distributor kernel tree
> and compile from there?

It should be easy to read the differences because there aren't many
commits on top of the 2.6.32 release, you need all the changes after:

commit 22763c5cf3690a681551162c15d34d935308c8d7
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Dec 2 19:51:21 2009 -0800

    Linux 2.6.32

> 
> One of the problems I found when doing this:
>   http://blog.alex.org.uk/archives/23
> is that the standard Ubuntu tree already has a xen directory,
> leading to all sorts of amusing collisions, at compile time (in
> terms of filename paths), and at link time (if CONFIG_XEN
> is selected, and the idea is to build a kernel that works
> both in paravirtualised guest mode and in HVM mode with PV
> drivers). I got around the former, but not the latter.
> 

I am not sure what is the best way for you to integrate these changes on
top of the Ubuntu kernel tree, but it should be possible.
Try disabling the backends in the config file and just enable
CONFIG_XEN, CONFIG_XEN_PLATFORM_PCI and the disk and network frontends.

Re: PV on HVM

[Alex Bligh]

--On 10 May 2010 15:58:16 +0100 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> It should be easy to read the differences because there aren't many
> commits on top of the 2.6.32 release, you need all the changes after:
>
> commit 22763c5cf3690a681551162c15d34d935308c8d7
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Wed Dec 2 19:51:21 2009 -0800

Indeed. It would help if I had selected the branch correctly
before posting that. Yes there are comparatively few changes.

> I am not sure what is the best way for you to integrate these changes on
> top of the Ubuntu kernel tree, but it should be possible.
> Try disabling the backends in the config file and just enable
> CONFIG_XEN, CONFIG_XEN_PLATFORM_PCI and the disk and network frontends.

My worry was in part that it wouldn't patch in, as Ubuntu already
has patches in the tree. That's why I tried to make them
compile as a completely separate module and not rely on any
in-kernel xen stuff. However, now the number of patches are
manageable, this should be doable.

-- 
Alex Bligh

Re: PV on HVM

[Jeremy Fitzhardinge]

On 05/10/2010 07:20 AM, Stefano Stabellini wrote:
> Hi all,
> this is the updated version of the PV on HVM series: many bugs have been
> fixed and VIRQ_TIMER support has been added.
> In order to be able to use VIRQ_TIMER and to improve performances you
> need two other patches to Xen to implement the vector callback mechanism
> for event channel delivery and to export some time related hypercalls to
> HVM guests too.
>
> This series is based on a standard 2.6.32 tree, a git tree is also
> available here:
>
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git
>
> branch name 2.6.32-pvhvm.
>   

I'm confused.  These patches don't seem to correspond with that branch. 
Are these the same as the branch but rearranged, or something else?

Thanks,
    J

Re: PV on HVM

[Jeremy Fitzhardinge]

On 05/10/2010 01:40 PM, Jeremy Fitzhardinge wrote:
> On 05/10/2010 07:20 AM, Stefano Stabellini wrote:
>   
>> Hi all,
>> this is the updated version of the PV on HVM series: many bugs have been
>> fixed and VIRQ_TIMER support has been added.
>> In order to be able to use VIRQ_TIMER and to improve performances you
>> need two other patches to Xen to implement the vector callback mechanism
>> for event channel delivery and to export some time related hypercalls to
>> HVM guests too.
>>
>> This series is based on a standard 2.6.32 tree, a git tree is also
>> available here:
>>
>> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git
>>
>> branch name 2.6.32-pvhvm.
>>   
>>     
> I'm confused.  These patches don't seem to correspond with that branch. 
> Are these the same as the branch but rearranged, or something else?
>   

I see, it looks like the condensed version of the branch.  I really
prefer you'd keep the patches incremental: its much easier to review the
incremental changes rather than folding updates into the
already-reviewed base patches.  Folding down is a late-stage process for
submission, and not something that should be done prematurely.

    J

Re: PV on HVM

[Stefano Stabellini]

On Mon, 10 May 2010, Jeremy Fitzhardinge wrote:
> On 05/10/2010 01:40 PM, Jeremy Fitzhardinge wrote:
> > On 05/10/2010 07:20 AM, Stefano Stabellini wrote:
> >   
> >> Hi all,
> >> this is the updated version of the PV on HVM series: many bugs have been
> >> fixed and VIRQ_TIMER support has been added.
> >> In order to be able to use VIRQ_TIMER and to improve performances you
> >> need two other patches to Xen to implement the vector callback mechanism
> >> for event channel delivery and to export some time related hypercalls to
> >> HVM guests too.
> >>
> >> This series is based on a standard 2.6.32 tree, a git tree is also
> >> available here:
> >>
> >> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git
> >>
> >> branch name 2.6.32-pvhvm.
> >>   
> >>     
> > I'm confused.  These patches don't seem to correspond with that branch. 
> > Are these the same as the branch but rearranged, or something else?
> >   
> 
> I see, it looks like the condensed version of the branch.  I really
> prefer you'd keep the patches incremental: its much easier to review the
> incremental changes rather than folding updates into the
> already-reviewed base patches.  Folding down is a late-stage process for
> submission, and not something that should be done prematurely.
> 
 
Yep, I guess I have been overzealous: I folded the small commits in
'patch size' commits and then I sent them over.
However the git tree still contains all the original incremental
changes.