* [xen-unstable test] 62968: regressions - FAIL
@ 2015-10-15 14:45 osstest service owner
2015-10-15 15:21 ` Wei Liu
0 siblings, 1 reply; 11+ messages in thread
From: osstest service owner @ 2015-10-15 14:45 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 11308 bytes --]
flight 62968 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62968/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 62711
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 62711
test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 62711
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 62711
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail like 62711
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62711
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 62711
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-armhf-armhf-libvirt-raw 9 debian-di-install fail never pass
test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail never pass
test-armhf-armhf-libvirt 14 guest-saverestore fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 9 debian-di-install fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
version targeted for testing:
xen ee653b97ce369decfdd4d18979fd9f6aec0073c2
baseline version:
xen a23ce429779011de127e8ff6c9bf3486d87154d5
Last test of basis 62711 2015-10-07 10:34:21 Z 8 days
Failing since 62733 2015-10-08 22:34:06 Z 6 days 7 attempts
Testing same since 62968 2015-10-14 22:11:34 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Brijesh Singh <brijeshkumar.singh@amd.com>
Daniel Kiper <daniel.kiper@oracle.com>
Dario Faggioli <dario.faggioli@citrix.com>
Fabio Fantoni <fabio.fantoni@m2r.biz>
George Dunlap <george.dunlap@citrix.com>
He Chen <he.chen@linux.intel.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Juergen Gross <jgross@suse.com>
Julien Grall <julien.grall@citrix.com>
Mike Latimer <mlatimer@suse.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
Sander Eikelenboom <linux@eikelenboom.it>
Tamas K Lengyel <tamas@tklengyel.com>
Tim Deegan <tim@xen.org>
Wei Liu <wei.liu2@citrix.com>
Wei Wang <wei.w.wang@intel.com>
Yang Zhang <yang.z.zhang@intel.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen pass
build-i386-rumpuserxen pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm fail
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumpuserxen-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumpuserxen-i386 pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair fail
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 fail
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd fail
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 1127 lines long.)
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable test] 62968: regressions - FAIL
2015-10-15 14:45 [xen-unstable test] 62968: regressions - FAIL osstest service owner
@ 2015-10-15 15:21 ` Wei Liu
2015-10-15 15:26 ` Wei Liu
0 siblings, 1 reply; 11+ messages in thread
From: Wei Liu @ 2015-10-15 15:21 UTC (permalink / raw)
To: osstest service owner; +Cc: xen-devel, wei.liu2
On Thu, Oct 15, 2015 at 02:45:47PM +0000, osstest service owner wrote:
> flight 62968 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62968/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 62711
Oct 15 02:59:53.981151 (d1) [ 0.000000] console [tty0] enabled
Oct 15 02:59:53.981213 (d1) [ 0.000000] console [hvc0] enabled
Oct 15 02:59:53.989101 (d1) [ 0.000000] bootconsole [xenboot0] disabled
Oct 15 02:59:53.989168 (XEN) traps.c:3287: GPF (0000): ffff82d080195e22 -> ffff82d080244d91
Don't know what to make of this.
Wei.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable test] 62968: regressions - FAIL
2015-10-15 15:21 ` Wei Liu
@ 2015-10-15 15:26 ` Wei Liu
2015-10-15 15:52 ` Andrew Cooper
0 siblings, 1 reply; 11+ messages in thread
From: Wei Liu @ 2015-10-15 15:26 UTC (permalink / raw)
To: osstest service owner
Cc: Andrew Cooper, xen-devel, wei.liu2, Jan Beulich,
Roger Pau Monné
On Thu, Oct 15, 2015 at 04:21:02PM +0100, Wei Liu wrote:
> On Thu, Oct 15, 2015 at 02:45:47PM +0000, osstest service owner wrote:
> > flight 62968 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/62968/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 62711
>
> Oct 15 02:59:53.981151 (d1) [ 0.000000] console [tty0] enabled
> Oct 15 02:59:53.981213 (d1) [ 0.000000] console [hvc0] enabled
> Oct 15 02:59:53.989101 (d1) [ 0.000000] bootconsole [xenboot0] disabled
> Oct 15 02:59:53.989168 (XEN) traps.c:3287: GPF (0000): ffff82d080195e22 -> ffff82d080244d91
>
> Don't know what to make of this.
>
According to
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/xen-unstable
This failure is the first of its kind in xen-unstable flight.
According to
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/ALL
There were similar errors in other branches, but the actual symptom is
different -- there was no sign of GP fault.
Wei.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable test] 62968: regressions - FAIL
2015-10-15 15:26 ` Wei Liu
@ 2015-10-15 15:52 ` Andrew Cooper
2015-10-15 16:07 ` Wei Liu
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Cooper @ 2015-10-15 15:52 UTC (permalink / raw)
To: Wei Liu, osstest service owner
Cc: xen-devel, Jan Beulich, Roger Pau Monné
On 15/10/15 16:26, Wei Liu wrote:
> On Thu, Oct 15, 2015 at 04:21:02PM +0100, Wei Liu wrote:
>> On Thu, Oct 15, 2015 at 02:45:47PM +0000, osstest service owner wrote:
>>> flight 62968 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/62968/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 62711
>> Oct 15 02:59:53.981151 (d1) [ 0.000000] console [tty0] enabled
>> Oct 15 02:59:53.981213 (d1) [ 0.000000] console [hvc0] enabled
>> Oct 15 02:59:53.989101 (d1) [ 0.000000] bootconsole [xenboot0] disabled
>> Oct 15 02:59:53.989168 (XEN) traps.c:3287: GPF (0000): ffff82d080195e22 -> ffff82d080244d91
>>
>> Don't know what to make of this.
>>
> According to
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/xen-unstable
>
> This failure is the first of its kind in xen-unstable flight.
>
> According to
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/ALL
>
> There were similar errors in other branches, but the actual symptom is
> different -- there was no sign of GP fault.
Do you have the debug hypervisor to hand? `addr2line -e xen-syms
ffff82d080195e22` will give you some clues.
This was a #GP fault which had a extable entry for it, which means it
was expected to possibly fault. At a complete guess, possibly an rdmsr
emulation for a PV guest.
~Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable test] 62968: regressions - FAIL
2015-10-15 15:52 ` Andrew Cooper
@ 2015-10-15 16:07 ` Wei Liu
2015-10-15 16:30 ` [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests Roger Pau Monne
0 siblings, 1 reply; 11+ messages in thread
From: Wei Liu @ 2015-10-15 16:07 UTC (permalink / raw)
To: Andrew Cooper
Cc: xen-devel, Wei Liu, osstest service owner, Jan Beulich,
Roger Pau Monné
On Thu, Oct 15, 2015 at 04:52:07PM +0100, Andrew Cooper wrote:
> On 15/10/15 16:26, Wei Liu wrote:
> > On Thu, Oct 15, 2015 at 04:21:02PM +0100, Wei Liu wrote:
> >> On Thu, Oct 15, 2015 at 02:45:47PM +0000, osstest service owner wrote:
> >>> flight 62968 xen-unstable real [real]
> >>> http://logs.test-lab.xenproject.org/osstest/logs/62968/
> >>>
> >>> Regressions :-(
> >>>
> >>> Tests which did not succeed and are blocking,
> >>> including tests which could not be run:
> >>> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 62711
> >> Oct 15 02:59:53.981151 (d1) [ 0.000000] console [tty0] enabled
> >> Oct 15 02:59:53.981213 (d1) [ 0.000000] console [hvc0] enabled
> >> Oct 15 02:59:53.989101 (d1) [ 0.000000] bootconsole [xenboot0] disabled
> >> Oct 15 02:59:53.989168 (XEN) traps.c:3287: GPF (0000): ffff82d080195e22 -> ffff82d080244d91
> >>
> >> Don't know what to make of this.
> >>
> > According to
> > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/xen-unstable
> >
> > This failure is the first of its kind in xen-unstable flight.
> >
> > According to
> > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/ALL
> >
> > There were similar errors in other branches, but the actual symptom is
> > different -- there was no sign of GP fault.
>
> Do you have the debug hypervisor to hand? `addr2line -e xen-syms
> ffff82d080195e22` will give you some clues.
>
> This was a #GP fault which had a extable entry for it, which means it
> was expected to possibly fault. At a complete guess, possibly an rdmsr
> emulation for a PV guest.
>
The current conclusion is that this is actually a toolstack bug that
manifests later. I will look into it.
Wei.
> ~Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
2015-10-15 16:07 ` Wei Liu
@ 2015-10-15 16:30 ` Roger Pau Monne
2015-10-15 16:39 ` Juergen Gross
2015-10-15 16:41 ` Ian Campbell
0 siblings, 2 replies; 11+ messages in thread
From: Roger Pau Monne @ 2015-10-15 16:30 UTC (permalink / raw)
To: xen-devel; +Cc: Wei Liu, Ian Jackson, Ian Campbell, Roger Pau Monne
Fix the types used to store the memory parameters of an HVM guest,
previously they defaulted to unsigned long on 32bit toolstack builds, which
is wrong because a 32bit value cannot hold a 64bit memory address that
crosses the 4GB boundary.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
I don't have a 32bit Dom0 at hand, so if someone can try to create a HVM
guests using a 32bit toolstack with more than 4GB of RAM it would be
helpful.
---
tools/libxc/include/xc_dom.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index e52b023..eb3e355 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -186,11 +186,11 @@ struct xc_dom_image {
} container_type;
/* HVM specific fields. */
- xen_pfn_t target_pages;
- xen_pfn_t mmio_start;
- xen_pfn_t mmio_size;
- xen_pfn_t lowmem_end;
- xen_pfn_t highmem_end;
+ unsigned long target_pages;
+ unsigned long long mmio_start;
+ unsigned long long mmio_size;
+ unsigned long lowmem_end;
+ unsigned long long highmem_end;
/* Extra ACPI tables passed to HVMLOADER */
struct xc_hvm_firmware_module acpi_module;
--
1.9.5 (Apple Git-50.3)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
2015-10-15 16:30 ` [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests Roger Pau Monne
@ 2015-10-15 16:39 ` Juergen Gross
2015-10-15 16:41 ` Ian Campbell
1 sibling, 0 replies; 11+ messages in thread
From: Juergen Gross @ 2015-10-15 16:39 UTC (permalink / raw)
To: Roger Pau Monne, xen-devel; +Cc: Ian Jackson, Wei Liu, Ian Campbell
On 10/15/2015 06:30 PM, Roger Pau Monne wrote:
> Fix the types used to store the memory parameters of an HVM guest,
> previously they defaulted to unsigned long on 32bit toolstack builds, which
> is wrong because a 32bit value cannot hold a 64bit memory address that
> crosses the 4GB boundary.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
> I don't have a 32bit Dom0 at hand, so if someone can try to create a HVM
> guests using a 32bit toolstack with more than 4GB of RAM it would be
> helpful.
> ---
> tools/libxc/include/xc_dom.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index e52b023..eb3e355 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -186,11 +186,11 @@ struct xc_dom_image {
> } container_type;
>
> /* HVM specific fields. */
> - xen_pfn_t target_pages;
> - xen_pfn_t mmio_start;
> - xen_pfn_t mmio_size;
> - xen_pfn_t lowmem_end;
> - xen_pfn_t highmem_end;
> + unsigned long target_pages;
> + unsigned long long mmio_start;
I'd prefer xen_paddr_t.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
2015-10-15 16:30 ` [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests Roger Pau Monne
2015-10-15 16:39 ` Juergen Gross
@ 2015-10-15 16:41 ` Ian Campbell
2015-10-15 16:52 ` Roger Pau Monné
1 sibling, 1 reply; 11+ messages in thread
From: Ian Campbell @ 2015-10-15 16:41 UTC (permalink / raw)
To: Roger Pau Monne, xen-devel; +Cc: Wei Liu, Ian Jackson
On Thu, 2015-10-15 at 18:30 +0200, Roger Pau Monne wrote:
> Fix the types used to store the memory parameters of an HVM guest,
> previously they defaulted to unsigned long on 32bit toolstack builds, which
> is wrong because a 32bit value cannot hold a 64bit memory address that
> crosses the 4GB boundary.
This header includes a xen_paddr_t in it which looks like the appropriate
type for most of these.
The ones which have units of pages which you've changed from xen_pfn_t to
unsigned long (not long long) should surely remain xen_pfn_t? At least
target_pages should IMHO.
lowmem_end doesn't strictly need to be 64-bit, but xen_paddr_t seems like
the appropriate type semantically nonetheless.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
> I don't have a 32bit Dom0 at hand, so if someone can try to create a HVM
> guests using a 32bit toolstack with more than 4GB of RAM it would be
> helpful.
> ---
> tools/libxc/include/xc_dom.h | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index e52b023..eb3e355 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -186,11 +186,11 @@ struct xc_dom_image {
> } container_type;
>
> /* HVM specific fields. */
> - xen_pfn_t target_pages;
> - xen_pfn_t mmio_start;
> - xen_pfn_t mmio_size;
> - xen_pfn_t lowmem_end;
> - xen_pfn_t highmem_end;
> + unsigned long target_pages;
> + unsigned long long mmio_start;
> + unsigned long long mmio_size;
> + unsigned long lowmem_end;
> + unsigned long long highmem_end;
>
> /* Extra ACPI tables passed to HVMLOADER */
> struct xc_hvm_firmware_module acpi_module;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
2015-10-15 16:41 ` Ian Campbell
@ 2015-10-15 16:52 ` Roger Pau Monné
2015-10-15 17:16 ` Ian Campbell
0 siblings, 1 reply; 11+ messages in thread
From: Roger Pau Monné @ 2015-10-15 16:52 UTC (permalink / raw)
To: Ian Campbell, xen-devel; +Cc: Wei Liu, Ian Jackson
El 15/10/15 a les 18.41, Ian Campbell ha escrit:
> On Thu, 2015-10-15 at 18:30 +0200, Roger Pau Monne wrote:
>> Fix the types used to store the memory parameters of an HVM guest,
>> previously they defaulted to unsigned long on 32bit toolstack builds, which
>> is wrong because a 32bit value cannot hold a 64bit memory address that
>> crosses the 4GB boundary.
>
> This header includes a xen_paddr_t in it which looks like the appropriate
> type for most of these.
>
> The ones which have units of pages which you've changed from xen_pfn_t to
> unsigned long (not long long) should surely remain xen_pfn_t? At least
> target_pages should IMHO.
>
> lowmem_end doesn't strictly need to be 64-bit, but xen_paddr_t seems like
> the appropriate type semantically nonetheless.
Right, I didn't realize we had a xen_paddr_t type, thanks to Juergen and
you for pointing it out. mmio_size is not a paddr, so I'm going to leave
it as unsigned long long.
Roger.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
2015-10-15 16:52 ` Roger Pau Monné
@ 2015-10-15 17:16 ` Ian Campbell
2015-10-15 17:17 ` Andrew Cooper
0 siblings, 1 reply; 11+ messages in thread
From: Ian Campbell @ 2015-10-15 17:16 UTC (permalink / raw)
To: Roger Pau Monné, xen-devel; +Cc: Wei Liu, Ian Jackson
On Thu, 2015-10-15 at 18:52 +0200, Roger Pau Monné wrote:
> El 15/10/15 a les 18.41, Ian Campbell ha escrit:
> > On Thu, 2015-10-15 at 18:30 +0200, Roger Pau Monne wrote:
> >> Fix the types used to store the memory parameters of an HVM guest,
> >> previously they defaulted to unsigned long on 32bit toolstack
> builds, which
> >> is wrong because a 32bit value cannot hold a 64bit memory address
> that
> >> crosses the 4GB boundary.
> >
> > This header includes a xen_paddr_t in it which looks like the
> appropriate
> > type for most of these.
> >
> > The ones which have units of pages which you've changed from
> xen_pfn_t to
> > unsigned long (not long long) should surely remain xen_pfn_t? At
> least
> > target_pages should IMHO.
> >
> > lowmem_end doesn't strictly need to be 64-bit, but xen_paddr_t
> seems like
> > the appropriate type semantically nonetheless.
>
> Right, I didn't realize we had a xen_paddr_t type, thanks to Juergen
> and
> you for pointing it out. mmio_size is not a paddr, so I'm going to
> leave
> it as unsigned long long.
The size of a paddr region can be considered to be a paddr from my PoV.
Ian.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
2015-10-15 17:16 ` Ian Campbell
@ 2015-10-15 17:17 ` Andrew Cooper
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Cooper @ 2015-10-15 17:17 UTC (permalink / raw)
To: Ian Campbell, Roger Pau Monné, xen-devel; +Cc: Ian Jackson, Wei Liu
On 15/10/15 18:16, Ian Campbell wrote:
> On Thu, 2015-10-15 at 18:52 +0200, Roger Pau Monné wrote:
>> El 15/10/15 a les 18.41, Ian Campbell ha escrit:
>>> On Thu, 2015-10-15 at 18:30 +0200, Roger Pau Monne wrote:
>>>> Fix the types used to store the memory parameters of an HVM guest,
>>>> previously they defaulted to unsigned long on 32bit toolstack
>> builds, which
>>>> is wrong because a 32bit value cannot hold a 64bit memory address
>> that
>>>> crosses the 4GB boundary.
>>> This header includes a xen_paddr_t in it which looks like the
>> appropriate
>>> type for most of these.
>>>
>>> The ones which have units of pages which you've changed from
>> xen_pfn_t to
>>> unsigned long (not long long) should surely remain xen_pfn_t? At
>> least
>>> target_pages should IMHO.
>>>
>>> lowmem_end doesn't strictly need to be 64-bit, but xen_paddr_t
>> seems like
>>> the appropriate type semantically nonetheless.
>> Right, I didn't realize we had a xen_paddr_t type, thanks to Juergen
>> and
>> you for pointing it out. mmio_size is not a paddr, so I'm going to
>> leave
>> it as unsigned long long.
> The size of a paddr region can be considered to be a paddr from my PoV.
+1. Better to use xen_paddr_t across the board than to mix and match.
~Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-10-15 17:18 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-15 14:45 [xen-unstable test] 62968: regressions - FAIL osstest service owner
2015-10-15 15:21 ` Wei Liu
2015-10-15 15:26 ` Wei Liu
2015-10-15 15:52 ` Andrew Cooper
2015-10-15 16:07 ` Wei Liu
2015-10-15 16:30 ` [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests Roger Pau Monne
2015-10-15 16:39 ` Juergen Gross
2015-10-15 16:41 ` Ian Campbell
2015-10-15 16:52 ` Roger Pau Monné
2015-10-15 17:16 ` Ian Campbell
2015-10-15 17:17 ` Andrew Cooper
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.