[Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int and uint types

Changes from v1: use int64_t to cast the uint32_t type to the signed type.

This is the updated version patch to fix the multiply issue for int and uint types operands, which reflects Stefano's comments.

The following patch fixes an issue of (uint * int) multiply in QEMU.
The bug phenomenon is that, it causes the Level 1 (L1) Xen boots more than 30 minutes on Level 0 (L0) Xen (The nested virtualization case).
Please help to review and pull.

I saw the upstream QEMU also have a similar code piece, I will also send a patch there.

Thanks,
Dongxiao

From d71f9be82ec0079aa88f779dea90e475b177e32f Mon Sep 17 00:00:00 2001
From: Dongxiao Xu <dongxiao.xu@intel.com>
Date: Mon, 20 Aug 2012 16:45:04 +0800
Subject: [PATCH] helper2: fix multiply issue for int and uint types

If the two multiply operands are int and uint types separately,
the int type will be transformed to uint firstly, which is not the
intent in our code piece. The fix is to add (int64_t) transform
for the uint type before the multiply.

This helps to fix the Xen hypevisor slow booting issue (boots more
than 30 minutes) on another Xen hypervisor
(the nested virtualization case).

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
i386-dm/helper2.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index c6d049c..c093249 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -364,7 +364,7 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
for (i = 0; i < req->count; i++) {
tmp = do_inp(env, req->addr, req->size);
write_physical((target_phys_addr_t) req->data
- + (sign * i * req->size),
+ + (sign * i * (int64_t)req->size),
req->size, &tmp);
}
}
@@ -376,7 +376,7 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
unsigned long tmp = 0;

read_physical((target_phys_addr_t) req->data
- + (sign * i * req->size),
+ + (sign * i * (int64_t)req->size),
req->size, &tmp);
do_outp(env, req->addr, req->size, tmp);
}
@@ -394,13 +394,13 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
if (req->dir == IOREQ_READ) {
for (i = 0; i < req->count; i++) {
read_physical(req->addr
- + (sign * i * req->size),
+ + (sign * i * (int64_t)req->size),
req->size, &req->data);
}
} else if (req->dir == IOREQ_WRITE) {
for (i = 0; i < req->count; i++) {
write_physical(req->addr
- + (sign * i * req->size),
+ + (sign * i * (int64_t)req->size),
req->size, &req->data);
}
}
@@ -410,19 +410,19 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
if (req->dir == IOREQ_READ) {
for (i = 0; i < req->count; i++) {
read_physical(req->addr
- + (sign * i * req->size),
+ + (sign * i * (int64_t)req->size),
req->size, &tmp);
write_physical((target_phys_addr_t )req->data
- + (sign * i * req->size),
+ + (sign * i * (int64_t)req->size),
req->size, &tmp);
}
} else if (req->dir == IOREQ_WRITE) {
for (i = 0; i < req->count; i++) {
read_physical((target_phys_addr_t) req->data
- + (sign * i * req->size),
+ + (sign * i * (int64_t)req->size),
req->size, &tmp);
write_physical(req->addr
- + (sign * i * req->size),
+ + (sign * i * (int64_t)req->size),
req->size, &tmp);
}
}
--
1.7.1

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

On Mon, 20 Aug 2012, Xu, Dongxiao wrote:
> Changes from v1: use int64_t to cast the uint32_t type to the signed type.
>
> This is the updated version patch to fix the multiply issue for int and uint types operands, which reflects Stefano's comments.
>
> The following patch fixes an issue of (uint * int) multiply in QEMU.
> The bug phenomenon is that, it causes the Level 1 (L1) Xen boots more than 30 minutes on Level 0 (L0) Xen (The nested virtualization case).
> Please help to review and pull.
>
> I saw the upstream QEMU also have a similar code piece, I will also send a patch there.

Please send the corresponding patch for upstream QEMU.


> Thanks,
> Dongxiao
>
> >From d71f9be82ec0079aa88f779dea90e475b177e32f Mon Sep 17 00:00:00 2001
> From: Dongxiao Xu <dongxiao.xu@intel.com>
> Date: Mon, 20 Aug 2012 16:45:04 +0800
> Subject: [PATCH] helper2: fix multiply issue for int and uint types
>
> If the two multiply operands are int and uint types separately,
> the int type will be transformed to uint firstly, which is not the
> intent in our code piece. The fix is to add (int64_t) transform
> for the uint type before the multiply.
>
> This helps to fix the Xen hypevisor slow booting issue (boots more
> than 30 minutes) on another Xen hypervisor
> (the nested virtualization case).
>
> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


> ---
> i386-dm/helper2.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
> index c6d049c..c093249 100644
> --- a/i386-dm/helper2.c
> +++ b/i386-dm/helper2.c
> @@ -364,7 +364,7 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
> for (i = 0; i < req->count; i++) {
> tmp = do_inp(env, req->addr, req->size);
> write_physical((target_phys_addr_t) req->data
> - + (sign * i * req->size),
> + + (sign * i * (int64_t)req->size),
> req->size, &tmp);
> }
> }
> @@ -376,7 +376,7 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
> unsigned long tmp = 0;
>
> read_physical((target_phys_addr_t) req->data
> - + (sign * i * req->size),
> + + (sign * i * (int64_t)req->size),
> req->size, &tmp);
> do_outp(env, req->addr, req->size, tmp);
> }
> @@ -394,13 +394,13 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
> if (req->dir == IOREQ_READ) {
> for (i = 0; i < req->count; i++) {
> read_physical(req->addr
> - + (sign * i * req->size),
> + + (sign * i * (int64_t)req->size),
> req->size, &req->data);
> }
> } else if (req->dir == IOREQ_WRITE) {
> for (i = 0; i < req->count; i++) {
> write_physical(req->addr
> - + (sign * i * req->size),
> + + (sign * i * (int64_t)req->size),
> req->size, &req->data);
> }
> }
> @@ -410,19 +410,19 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
> if (req->dir == IOREQ_READ) {
> for (i = 0; i < req->count; i++) {
> read_physical(req->addr
> - + (sign * i * req->size),
> + + (sign * i * (int64_t)req->size),
> req->size, &tmp);
> write_physical((target_phys_addr_t )req->data
> - + (sign * i * req->size),
> + + (sign * i * (int64_t)req->size),
> req->size, &tmp);
> }
> } else if (req->dir == IOREQ_WRITE) {
> for (i = 0; i < req->count; i++) {
> read_physical((target_phys_addr_t) req->data
> - + (sign * i * req->size),
> + + (sign * i * (int64_t)req->size),
> req->size, &tmp);
> write_physical(req->addr
> - + (sign * i * req->size),
> + + (sign * i * (int64_t)req->size),
> req->size, &tmp);
> }
> }
> --
> 1.7.1
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

> -----Original Message-----
> > >From d71f9be82ec0079aa88f779dea90e475b177e32f Mon Sep 17 00:00:00
> > >2001
> > From: Dongxiao Xu <dongxiao.xu@intel.com>
> > Date: Mon, 20 Aug 2012 16:45:04 +0800
> > Subject: [PATCH] helper2: fix multiply issue for int and uint types
> >
> > If the two multiply operands are int and uint types separately, the
> > int type will be transformed to uint firstly, which is not the intent
> > in our code piece. The fix is to add (int64_t) transform for the uint
> > type before the multiply.
> >
> > This helps to fix the Xen hypevisor slow booting issue (boots more
> > than 30 minutes) on another Xen hypervisor (the nested virtualization
> > case).
> >
> > Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
>
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Will this patch supposed to be merge in Xen 4.2?

Actually this is a fix for the nested Xen booting up issue, and it is already merged in QEMU upstream.

We have several patches to fix issues and enable the nested virtualization for Xen on Xen.
They are:

1) QEMU/helper2.c: Fix multiply issue for int and uint types.
This patch is to fix the issue of nested Xen boot up. (in this mail)

2) Xiantao Zhang will (suppose today) send out another patch to fix the L2 guest booting issue.

3) nvmx: fix resource relinquish for nested VMX.
This patch is to fix the destroy issue (resource is not released, xl list still shows the guest) for L1 guest with a L2 guest running in it. (Already sent into mailing list)

4) Another patch is already merged by Ian J, which could fix the booting slow issue for L2 guest, see:
[xenbits.xen.org]

For the remaining three, will you accept them for Xen 4.2 release?

Thanks,
Dongxiao

>
>
> > ---
> > i386-dm/helper2.c | 16 ++++++++--------
> > 1 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c index
> > c6d049c..c093249 100644
> > --- a/i386-dm/helper2.c
> > +++ b/i386-dm/helper2.c
> > @@ -364,7 +364,7 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t
> *req)
> > for (i = 0; i < req->count; i++) {
> > tmp = do_inp(env, req->addr, req->size);
> > write_physical((target_phys_addr_t) req->data
> > - + (sign * i * req->size),
> > + + (sign * i * (int64_t)req->size),
> > req->size, &tmp);
> > }
> > }
> > @@ -376,7 +376,7 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t
> *req)
> > unsigned long tmp = 0;
> >
> > read_physical((target_phys_addr_t) req->data
> > - + (sign * i * req->size),
> > + + (sign * i * (int64_t)req->size),
> > req->size, &tmp);
> > do_outp(env, req->addr, req->size, tmp);
> > }
> > @@ -394,13 +394,13 @@ static void cpu_ioreq_move(CPUState *env,
> ioreq_t *req)
> > if (req->dir == IOREQ_READ) {
> > for (i = 0; i < req->count; i++) {
> > read_physical(req->addr
> > - + (sign * i * req->size),
> > + + (sign * i * (int64_t)req->size),
> > req->size, &req->data);
> > }
> > } else if (req->dir == IOREQ_WRITE) {
> > for (i = 0; i < req->count; i++) {
> > write_physical(req->addr
> > - + (sign * i * req->size),
> > + + (sign * i * (int64_t)req->size),
> > req->size, &req->data);
> > }
> > }
> > @@ -410,19 +410,19 @@ static void cpu_ioreq_move(CPUState *env,
> ioreq_t *req)
> > if (req->dir == IOREQ_READ) {
> > for (i = 0; i < req->count; i++) {
> > read_physical(req->addr
> > - + (sign * i * req->size),
> > + + (sign * i * (int64_t)req->size),
> > req->size, &tmp);
> > write_physical((target_phys_addr_t )req->data
> > - + (sign * i * req->size),
> > + + (sign * i * (int64_t)req->size),
> > req->size, &tmp);
> > }
> > } else if (req->dir == IOREQ_WRITE) {
> > for (i = 0; i < req->count; i++) {
> > read_physical((target_phys_addr_t) req->data
> > - + (sign * i * req->size),
> > + + (sign * i * (int64_t)req->size),
> > req->size, &tmp);
> > write_physical(req->addr
> > - + (sign * i * req->size),
> > + + (sign * i * (int64_t)req->size),
> > req->size, &tmp);
> > }
> > }
> > --
> > 1.7.1
> >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

On 24/08/2012 02:17, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:

> 1) QEMU/helper2.c: Fix multiply issue for int and uint types.
> This patch is to fix the issue of nested Xen boot up. (in this mail)
>
> 2) Xiantao Zhang will (suppose today) send out another patch to fix the L2
> guest booting issue.
>
> 3) nvmx: fix resource relinquish for nested VMX.
> This patch is to fix the destroy issue (resource is not released, xl list
> still shows the guest) for L1 guest with a L2 guest running in it. (Already
> sent into mailing list)
>
> 4) Another patch is already merged by Ian J, which could fix the booting slow
> issue for L2 guest, see:
> [xenbits.xen.org]
> 61abdab90becac519716515c3be4
>
> For the remaining three, will you accept them for Xen 4.2 release?

Yes! I will look at (3) today. The others should be strongly considered too.

-- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

On Fri, 24 Aug 2012, Xu, Dongxiao wrote:
> > -----Original Message-----
> > > >From d71f9be82ec0079aa88f779dea90e475b177e32f Mon Sep 17 00:00:00
> > > >2001
> > > From: Dongxiao Xu <dongxiao.xu@intel.com>
> > > Date: Mon, 20 Aug 2012 16:45:04 +0800
> > > Subject: [PATCH] helper2: fix multiply issue for int and uint types
> > >
> > > If the two multiply operands are int and uint types separately, the
> > > int type will be transformed to uint firstly, which is not the intent
> > > in our code piece. The fix is to add (int64_t) transform for the uint
> > > type before the multiply.
> > >
> > > This helps to fix the Xen hypevisor slow booting issue (boots more
> > > than 30 minutes) on another Xen hypervisor (the nested virtualization
> > > case).
> > >
> > > Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> >
> > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> Will this patch supposed to be merge in Xen 4.2?
>
> Actually this is a fix for the nested Xen booting up issue, and it is already merged in QEMU upstream.
>
> We have several patches to fix issues and enable the nested virtualization for Xen on Xen.
> They are:
>
> 1) QEMU/helper2.c: Fix multiply issue for int and uint types.
> This patch is to fix the issue of nested Xen boot up. (in this mail)
>
> 2) Xiantao Zhang will (suppose today) send out another patch to fix the L2 guest booting issue.
>
> 3) nvmx: fix resource relinquish for nested VMX.
> This patch is to fix the destroy issue (resource is not released, xl list still shows the guest) for L1 guest with a L2 guest running in it. (Already sent into mailing list)
>
> 4) Another patch is already merged by Ian J, which could fix the booting slow issue for L2 guest, see:
> [xenbits.xen.org]
>
> For the remaining three, will you accept them for Xen 4.2 release?

I can only speak for qemu-upstream-unstable, but I'll certainly backport
the int/uint fix as soon as it gets accepted in QEMU upstream.

Regarding the other patches, if any of them are for
qemu-upstream-unstable, I am going to backport them only if they are
bugfixes.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Friday, August 24, 2012 7:25 PM
> To: Xu, Dongxiao
> Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> and uint types
>
>
> I can only speak for qemu-upstream-unstable, but I'll certainly backport the
> int/uint fix as soon as it gets accepted in QEMU upstream.
>
> Regarding the other patches, if any of them are for qemu-upstream-unstable, I
> am going to backport them only if they are bugfixes.

It seems that the int/uint patch is already merged by Anthony L, see commit b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.

Sorry I have been running away from Xen list for a long time and not familiar with the current rules.
For QEMU bug fixes, is it the regulation that patch developer need to fix the QEMU upstream, and Stefano will be in charge to backport it? Or patch developer needs to fix both?

Thanks,
Dongxiao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Friday, August 24, 2012 7:25 PM
> > To: Xu, Dongxiao
> > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > xen-devel@lists.xen.org
> > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> > and uint types
> >
> >
> > I can only speak for qemu-upstream-unstable, but I'll certainly backport the
> > int/uint fix as soon as it gets accepted in QEMU upstream.
> >
> > Regarding the other patches, if any of them are for qemu-upstream-unstable, I
> > am going to backport them only if they are bugfixes.
>
> It seems that the int/uint patch is already merged by Anthony L, see commit b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.

Thanks for letting me know.
I am current away on a conference but I'll try to get the backport done by
the end of the week nonetheless.


> Sorry I have been running away from Xen list for a long time and not familiar with the current rules.
> For QEMU bug fixes, is it the regulation that patch developer need to fix the QEMU upstream, and Stefano will be in charge to backport it? Or patch developer needs to fix both?

That's right: fix needs to be upstream first then I'll backport it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Tuesday, August 28, 2012 1:14 AM
> To: Xu, Dongxiao
> Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> and uint types
>
> On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Friday, August 24, 2012 7:25 PM
> > > To: Xu, Dongxiao
> > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > xen-devel@lists.xen.org
> > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > issue for int and uint types
> > >
> > >
> > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > >
> > > Regarding the other patches, if any of them are for
> > > qemu-upstream-unstable, I am going to backport them only if they are
> bugfixes.
> >
> > It seems that the int/uint patch is already merged by Anthony L, see commit
> b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
>
> Thanks for letting me know.
> I am current away on a conference but I'll try to get the backport done by the
> end of the week nonetheless.

Hi Stefano,

It seems that the patch is still not in qemu-xen repo, could you help to backport it?

Thanks,
Dongxiao

>
>
> > Sorry I have been running away from Xen list for a long time and not familiar
> with the current rules.
> > For QEMU bug fixes, is it the regulation that patch developer need to fix the
> QEMU upstream, and Stefano will be in charge to backport it? Or patch
> developer needs to fix both?
>
> That's right: fix needs to be upstream first then I'll backport it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

> -----Original Message-----
> From: Xu, Dongxiao
> Sent: Wednesday, September 05, 2012 11:01 AM
> To: Stefano Stabellini
> Cc: Keir (Xen.org); Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> and uint types
>
> > On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Friday, August 24, 2012 7:25 PM
> > > > To: Xu, Dongxiao
> > > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > > xen-devel@lists.xen.org
> > > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > > issue for int and uint types
> > > >
> > > >
> > > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > > >
> > > > Regarding the other patches, if any of them are for
> > > > qemu-upstream-unstable, I am going to backport them only if they
> > > > are
> > bugfixes.
> > >
> > > It seems that the int/uint patch is already merged by Anthony L, see
> > > commit
> > b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
> >
> > Thanks for letting me know.
> > I am current away on a conference but I'll try to get the backport
> > done by the end of the week nonetheless.
>
> Hi Stefano,
>
> It seems that the patch is still not in qemu-xen repo, could you help to backport
> it?

I saw both Xen and qemu-xen are tagged as RC4, however this fix is still not there.

Without this fix, I think L1 Xen could not boot on L0 Xen successfully.

Thanks,
Dongxiao

>
> Thanks,
> Dongxiao
>
> >
> >
> > > Sorry I have been running away from Xen list for a long time and not
> > > familiar
> > with the current rules.
> > > For QEMU bug fixes, is it the regulation that patch developer need
> > > to fix the
> > QEMU upstream, and Stefano will be in charge to backport it? Or patch
> > developer needs to fix both?
> >
> > That's right: fix needs to be upstream first then I'll backport it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]

On Mon, 10 Sep 2012, Xu, Dongxiao wrote:
> > -----Original Message-----
> > From: Xu, Dongxiao
> > Sent: Wednesday, September 05, 2012 11:01 AM
> > To: Stefano Stabellini
> > Cc: Keir (Xen.org); Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> > and uint types
> >
> > > On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > > > -----Original Message-----
> > > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > > Sent: Friday, August 24, 2012 7:25 PM
> > > > > To: Xu, Dongxiao
> > > > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > > > xen-devel@lists.xen.org
> > > > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > > > issue for int and uint types
> > > > >
> > > > >
> > > > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > > > >
> > > > > Regarding the other patches, if any of them are for
> > > > > qemu-upstream-unstable, I am going to backport them only if they
> > > > > are
> > > bugfixes.
> > > >
> > > > It seems that the int/uint patch is already merged by Anthony L, see
> > > > commit
> > > b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
> > >
> > > Thanks for letting me know.
> > > I am current away on a conference but I'll try to get the backport
> > > done by the end of the week nonetheless.
> >
> > Hi Stefano,
> >
> > It seems that the patch is still not in qemu-xen repo, could you help to backport
> > it?
>
> I saw both Xen and qemu-xen are tagged as RC4, however this fix is still not there.
>
> Without this fix, I think L1 Xen could not boot on L0 Xen successfully.

The patch is now in staging/qemu-upstream-unstable.git.
Sorry for the delay.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
[lists.xen.org]