Re: [Xen-devel] upstream merge status for 2.6.35, .36? PV on HVM Xen

[Boris Derzhavets <bderzhavets@xxxxxxxxx>]

[Xen-devel] [PATCH 0/12] PV on HVM Xen

Thursday, June 3, 2010 9:07 AM

From:

"Stefano Stabellini" <Stefano.Stabellini@xxxxxxxxxxxxx>

Add sender to Contacts

To:

"linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>

Cc:

"Stefano Stabellini" <Stefano.Stabellini@xxxxxxxxxxxxx>, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Don Dutile" <ddutile@xxxxxxxxxx>, "Sheng Yang" <sheng@xxxxxxxxxxxxxxx>... more

Hi all,
the last update on the PV on HVM Xen series contains the following
changes:

- some variables and functions have been renamed following Jeremy's
suggestions, in particular:
s/init_shared_info/xen_hvm_init_shared_info
s/xen_platform_pci/xen_platform_pci_enabled
s/UNPLUG_/XEN_UNPLUG_

- the two platform_pci.h header files have been merged and the useless
intro has been removed;

- the xen platform pci product number and driver versions have been made
static;

- the description on the VIRQ_TIMER patch has been improved;

- a new patch to fix hpet behaviour has been introduced: hpet_disable is
called unconditionally on machine shutdown, and doesn't check whether
hpet has been actually enabled, causing trouble if it hasn't;

- the vector callback patch has been improved: we don't use the ipi
vector anymore but we allocate our own so that we can avoid useless and
expensive vlapic acks.


Meanwhile the vector callback patch for xen has been checked into
xen-unstable, so you don't need a separate patch for xen anymore to take
full advantage of this patch series.

A git tree is available here:

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

branch name 2.6.34-pvhvm-v3.

Cheers,

Stefano

--- On Sat, 6/5/10, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:

From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] upstream merge status for 2.6.35, .36?
To: "Josip Rodin" <joy@xxxxxxxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Date: Saturday, June 5, 2010, 8:36 PM

On 06/05/2010 05:51 AM, Josip Rodin wrote:
> On Fri, Jun 04, 2010 at 05:20:06PM -0700, Jeremy Fitzhardinge wrote:
>   
>> On 06/04/2010 03:39 PM, Josip Rodin wrote:
>>     
>>> What about the future? I saw Konrad's applied his swiotlb tree with the
>>> right acks for inclusion into linux-next, so that looks like it's planned
>>> to be ready to go in when the .36 merge window opens, right?
>>>       
>> Yes, and I'm hoping we can get pcifront and pvhvm lined up for .36; with
>> those in place, its a short jump to full dom0 functionality (which, no
>> promises, might also get into .36 on their tails).
>>     
> Are those changes able to get into linux-next standalone like swiotlb,
> or do they go in via some other branch, or even directly?
>   

linux-next isn't itself a path to upstream, but any change which has
been cooking in linux-next for a while is immediately more legitimate as
an upstream submission.

In general changes which affect other subsystems will go via those
subsystems maintainer trees, which in turn will likely end up in
linux-next (swiotlb being slightly exceptional in that its maintainer
doesn't have a git tree).  I'll submit any pure Xen changes directly.

> Also, pvhvm seems to have several versions, xen/pvhvm-sheng,
> xen/pvhvm-stefano, xen/pvhvm-stefano-rebase - which one of those
> is supposed to become the upstreamable one?
>   

Stefano is working on it in his own branch.  I have not been tracking it
closely so far.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel