Re: [Xen-devel] Xen BUG at page_alloc.c:1738 (Xen 4.5)

>>> On 31.05.15 at 00:43, wrote: > On 30/05/2015 23:07, M A Young wrote: >> On Fri, 29 May 2015, Andrew Cooper wrote: >>> FC22 is miscompiling the C to: >>> >>> struct page_info *page = mfn_to_page(mfn); >>> struct domain *owner = page_get_owner_and_reference(page); >>> if ( owner ) >>> put_pa

Re: [Xen-devel] Xen BUG at page_alloc.c:1738 (Xen 4.5)

On Mon, 1 Jun 2015, Jan Beulich wrote: > >>> On 31.05.15 at 00:43, wrote: > > On 30/05/2015 23:07, M A Young wrote: > >> On Fri, 29 May 2015, Andrew Cooper wrote: > >>> FC22 is miscompiling the C to: > >>> > >>> struct page_info *page = mfn_to_page(mfn); > >>> struct domain *owner = page_get_owne

Re: [Xen-devel] [PATCH] drivers: xen-blkfront: blkif_recover: recheck feature-persistent

El 26/05/15 a les 2.11, Bob Liu ha escrit: > When migrate from !feature-persistent host to feature-persistent host, domU > still think new host/backend don't support persistent. > Dmesg like: > backed has not unmapped grant: 839 > backed has not unmapped grant: 773 > backed has not unmapped grant:

Re: [Xen-devel] [xen-4.2-testing test] 57630: regressions - FAIL

>>> On 01.06.15 at 00:57, wrote: > flight 57630 xen-4.2-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/57630/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-xend-winxpsp3 16 guest-stop

Re: [Xen-devel] [xen-4.3-testing test] 57600: regressions - trouble: blocked/broken/fail/pass

>>> On 31.05.15 at 19:18, wrote: > flight 57600 xen-4.3-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/57600/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-xend-qemut-winxpsp3 16 guest-s

Re: [Xen-devel] [PATCH v8 03/13] x86: maintain COS to CBM mapping for each socket

On Fri, May 29, 2015 at 04:38:31PM +0800, Chao Peng wrote: > On Fri, May 29, 2015 at 09:06:46AM +0100, Jan Beulich wrote: > > >>> On 29.05.15 at 04:43, wrote: > > > On Thu, May 28, 2015 at 02:17:54PM +0100, Jan Beulich wrote: > > >> >>> On 21.05.15 at 10:41, wrote: > > >> > +static int cat_cpu_in

[Xen-devel] [Patch v3 27/36] x86, irq: Use access helper irq_data_get_affinity_mask()

Use access helper irq_data_get_affinity_mask() to hide implementation details of struct irq_desc. Signed-off-by: Jiang Liu --- arch/x86/kernel/apic/io_apic.c |2 +- arch/x86/kernel/apic/vector.c|5 ++--- arch/x86/kernel/irq.c|5 +++-- drivers/xen/events/events_base.

Re: [Xen-devel] [PATCH V5 10/10] xen/arm64: increase MAX_VIRT_CPUS to 128 on arm64

Hi Chen, On 01/06/2015 01:56, Chen Baozi wrote: For instance, with your series a cluster can use up to 16 cores but the GIC-500 is only supporting up to 8 cores... Well, if 4096 is a acceptable value, it will cost 512M address space for GICR_* (We need to chagne patch #1 too). Although we do h

Re: [Xen-devel] [PATCH] xen: netback: fix error printf format string.

On Sun, 2015-05-31 at 21:26 -0700, David Miller wrote: > From: Ian Campbell > Date: Fri, 29 May 2015 17:22:04 +0100 > > > drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’: > > drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects > > argument of type ‘long

Re: [Xen-devel] [PATCH] drivers: xen-blkfront: blkif_recover: recheck feature-persistent

On 06/01/2015 03:50 PM, Roger Pau Monné wrote: > El 26/05/15 a les 2.11, Bob Liu ha escrit: >> When migrate from !feature-persistent host to feature-persistent host, domU >> still think new host/backend don't support persistent. >> Dmesg like: >> backed has not unmapped grant: 839 >> backed has no

Re: [Xen-devel] [xen-4.4-testing test] 57474: tolerable trouble: blocked/broken/fail/pass - PUSHED

>>> On 29.05.15 at 20:51, wrote: > flight 57474 xen-4.4-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/57474/ > > Failures :-/ but no regressions. > > Tests which are failing intermittently (not blocking): > test-armhf-armhf-xl-multivcpu 3 host-install(3) brok

[Xen-devel] [PATCH OSSTEST] Toolstack: Do not pass -F to xm shutdown (Was: Re: [xen-4.2-testing test] 57630: regressions - FAIL)

On Mon, 2015-06-01 at 08:56 +0100, Jan Beulich wrote: > >>> On 01.06.15 at 00:57, wrote: > > flight 57630 xen-4.2-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/57630/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests whi

Re: [Xen-devel] [PATCH v8 03/13] x86: maintain COS to CBM mapping for each socket

>>> On 01.06.15 at 10:05, wrote: > 2) Unfeasible to allocate memory first and do initialization later in > cpu hotplug notifications. My former approach is performing both the > allocation and initialization in the CPU_STARTING, which is not a good > idea indicated by Jan. Considering

Re: [Xen-devel] [PATCH] drivers: xen-blkback: delay pending_req allocation to connect_ring

El 26/05/15 a les 2.06, Bob Liu ha escrit: > In connect_ring, we can know exactly how many pages are used for the shared > ring and also whether feature-persistent is enabled, delay pending_req > allocation here so that we won't waste too much memory. I would very much prefer for this to be a pre-

Re: [Xen-devel] [PATCH v2 for Xen 4.6 0/4] Enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

On 05/29/2015 03:40 PM, Meng Xu wrote: > 2015-05-29 4:15 GMT-07:00 Dario Faggioli : > >> On Tue, 2015-05-26 at 09:59 +0100, Ian Campbell wrote: >>> On Mon, 2015-05-25 at 18:59 -0500, Chong Li wrote: >>> >>> This series arrived in my mailbox as 5 distinct mails. >>> >>> Please use git send-email su

Re: [Xen-devel] [PATCH v2] dmar: device scope mem leak fix

>>> On 01.06.15 at 06:47, wrote: >> From: Tian, Kevin >> Sent: Monday, June 01, 2015 12:43 PM >> >> >> and looks you dropped earlier changes to acpi_parse_one_rmrr. any >> elaboration why it's not required in this version? > > Never mind this one. Seems you have it in RMRR patch set. No - it

Re: [Xen-devel] [PATCH v2 for Xen 4.6 0/4] Enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

On Mon, 2015-06-01 at 09:36 +0100, George Dunlap wrote: > Signed-off-by: George Dunlap > --- > CC: Ian Campbell > CC: Wei Liu Most people put the Cc about the cut (---) which is fine too. It means the history ends up recording who was copied on the patch, which isn't necessarily a bad thing. >

[Xen-devel] [linux-3.4 test] 57661: regressions - FAIL

flight 57661 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/57661/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect test-amd64-amd64-pair

Re: [Xen-devel] [PATCH v2 for Xen 4.6 0/4] Enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

On 06/01/2015 09:48 AM, Ian Campbell wrote: > On Mon, 2015-06-01 at 09:36 +0100, George Dunlap wrote: >> Signed-off-by: George Dunlap >> --- >> CC: Ian Campbell >> CC: Wei Liu > > Most people put the Cc about the cut (---) which is fine too. It means > the history ends up recording who was copi

Re: [Xen-devel] [PATCH net] xen: netback: read hotplug script once at start of day.

On Fri, 2015-05-29 at 18:38 +0100, Wei Liu wrote: > On Fri, May 29, 2015 at 05:24:53PM +0100, Ian Campbell wrote: > [...] > > if (be->vif != NULL) > > return 0; > > @@ -417,12 +409,23 @@ static int backend_create_xenvif(struct backend_info > > *be) > > return (err < 0)

Re: [Xen-devel] [PATCH v6 2/4] iommu VT-d: separate rmrr addition function

>>> On 29.05.15 at 23:38, wrote: > In preparation for auxiliary RMRR data provided on Xen > command line, make RMRR adding a separate function. > Also free memery for rmrr device scope in error path. > No changes since v5. Certainly there is. (And the statement wouldn't belong here anyway, but be

Re: [Xen-devel] [PATCH v6 3/4] pci: add wrapper for parse_pci

>>> On 29.05.15 at 23:38, wrote: > For sbdf'si parsing in rmrr command line add __parse_pci with addtional > parameter def_seg. __parse_pci will help to identify if segment was > found > in string being parsed or default segment was used. > Make a wrapper parse_pci so the rest of the callers are n

Re: [Xen-devel] [PATCH v8 03/13] x86: maintain COS to CBM mapping for each socket

On Mon, Jun 01, 2015 at 09:36:15AM +0100, Jan Beulich wrote: > >>> On 01.06.15 at 10:05, wrote: > > 2) Unfeasible to allocate memory first and do initialization later in > > cpu hotplug notifications. My former approach is performing both the > > allocation and initialization in the CPU_STARTING,

Re: [Xen-devel] [PATCH v2 for Xen 4.6 0/4] Enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

On Mon, 2015-06-01 at 09:50 +0100, George Dunlap wrote: > On 06/01/2015 09:48 AM, Ian Campbell wrote: > > On Mon, 2015-06-01 at 09:36 +0100, George Dunlap wrote: > >> Signed-off-by: George Dunlap > >> --- > >> CC: Ian Campbell > >> CC: Wei Liu > > > > Most people put the Cc about the cut (---)

Re: [Xen-devel] [PATCH v2 for Xen 4.6 0/4] Enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

>>> On 01.06.15 at 10:50, wrote: > On 06/01/2015 09:48 AM, Ian Campbell wrote: >> On Mon, 2015-06-01 at 09:36 +0100, George Dunlap wrote: >>> Signed-off-by: George Dunlap >>> --- >>> CC: Ian Campbell >>> CC: Wei Liu >> >> Most people put the Cc about the cut (---) which is fine too. It means >

Re: [Xen-devel] [PATCH] drivers: xen-blkback: delay pending_req allocation to connect_ring

On 06/01/2015 04:36 PM, Roger Pau Monné wrote: > El 26/05/15 a les 2.06, Bob Liu ha escrit: >> In connect_ring, we can know exactly how many pages are used for the shared >> ring and also whether feature-persistent is enabled, delay pending_req >> allocation here so that we won't waste too much me

Re: [Xen-devel] [PATCH 4/4] iommu: add rmrr Xen command line option for extra rmrrs

>>> On 01.06.15 at 08:30, wrote: >> From: elena.ufimts...@oracle.com [mailto:elena.ufimts...@oracle.com] >> +rmrrn = xzalloc(struct acpi_rmrr_unit); >> +if ( !rmrrn ) >> +return; >> + >> +rmrrn->scope.devices = xmalloc_array(u16, >> +

Re: [Xen-devel] [PATCH v2 for Xen 4.6 0/4] Enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

On 01/06/15 09:58, Jan Beulich wrote: On 01.06.15 at 10:50, wrote: >> On 06/01/2015 09:48 AM, Ian Campbell wrote: >>> On Mon, 2015-06-01 at 09:36 +0100, George Dunlap wrote: Signed-off-by: George Dunlap --- CC: Ian Campbell CC: Wei Liu >>> Most people put the Cc about t

Re: [Xen-devel] [PATCH net] xen: netback: read hotplug script once at start of day.

On Mon, Jun 01, 2015 at 09:52:45AM +0100, Ian Campbell wrote: > On Fri, 2015-05-29 at 18:38 +0100, Wei Liu wrote: > > On Fri, May 29, 2015 at 05:24:53PM +0100, Ian Campbell wrote: > > [...] > > > if (be->vif != NULL) > > > return 0; > > > @@ -417,12 +409,23 @@ static int backend_create_

Re: [Xen-devel] [PATCH 4/4] iommu: add rmrr Xen command line option for extra rmrrs

>>> On 29.05.15 at 23:38, wrote: > --- a/xen/drivers/passthrough/vtd/dmar.c > +++ b/xen/drivers/passthrough/vtd/dmar.c > @@ -866,6 +866,106 @@ out: > return ret; > } > > +#define MAX_EXTRA_RMRR_PAGES 16 > +#define MAX_EXTRA_RMRR 10 > + > +/* RMRR units derived from command line rmrr option

Re: [Xen-devel] [PATCH v2 6/9] x86/intel_pstate: the main boby of the intel_pstate driver

On 29/05/2015 16:46, Jan Beulich wrote > >>> On 29.05.15 at 10:19, wrote: > > On 26/05/2015 21:58, Jan Beulich wrote > >> >>> On 13.05.16 at 09:50, wrote: > >> > +static int intel_pstate_verify_policy(struct cpufreq_policy > >> > +*policy) { > >> > +cpufreq_verify_within_limits(policy, policy

Re: [Xen-devel] [PATCH 4/4] iommu: add rmrr Xen command line option for extra rmrrs

>>> On 01.06.15 at 08:30, wrote: >> From: elena.ufimts...@oracle.com [mailto:elena.ufimts...@oracle.com] >> --- a/docs/misc/xen-command-line.markdown >> +++ b/docs/misc/xen-command-line.markdown >> @@ -1185,6 +1185,19 @@ Specify the host reboot method. >> 'efi' instructs Xen to reboot using the

Re: [Xen-devel] [PATCH v2 for Xen 4.6 0/4] Enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

On 06/01/2015 10:06 AM, Andrew Cooper wrote: > On 01/06/15 09:58, Jan Beulich wrote: > On 01.06.15 at 10:50, wrote: >>> On 06/01/2015 09:48 AM, Ian Campbell wrote: On Mon, 2015-06-01 at 09:36 +0100, George Dunlap wrote: > Signed-off-by: George Dunlap > --- > CC: Ian Campbell

[Xen-devel] [PATCH OSSTEST] Toolstack: Do not pass -F to xm shutdown (Was: Re: [xen-4.2-testing test] 57630: regressions - FAIL)

>>> On 01.06.15 at 10:34, wrote: > Subject: [PATCH] Toolstack: Do not pass -F to xm shutdown > > This is a feature of xl only. > > Signed-off-by: Ian Campbell > --- > Osstest/Toolstack/xl.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Osstest/Toolstack/xl.pm b/Oss

[Xen-devel] The size of memory is wrong inside of virtual machine(VM) when using OVMF

Hi all: I encountered a troublesome problem about OVMF. I used OVMF.fd as a BIOS of virtual machine(VM). 1、my environment: xen_version: 4.6-unstable I git clone xen from git://xenbits.xen.org/xen.git. configure it and parameters as below: ./co

[Xen-devel] [Formal Vote] Changes to Xen Project Security Vulnerability Process - Open until June 8th, 2015

Hi, in accordance with the project's governance, I would like to put the following text changes to a committer vote (committers are on the TO list). The discussion leading to the changes can be found at http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg02881.html

Re: [Xen-devel] [PATCH v2 6/9] x86/intel_pstate: the main boby of the intel_pstate driver

>>> On 01.06.15 at 11:12, wrote: > On 29/05/2015 16:46, Jan Beulich wrote >> >>> On 29.05.15 at 10:19, wrote: >> > On 26/05/2015 21:58, Jan Beulich wrote >> >> >>> On 13.05.16 at 09:50, wrote: >> >> > +static int intel_pstate_verify_policy(struct cpufreq_policy >> >> > +*policy) { >> >> > +c

Re: [Xen-devel] [PATCH v2 for Xen 4.6 0/4] Enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

On Mon, 2015-06-01 at 10:20 +0100, George Dunlap wrote: > On 06/01/2015 10:06 AM, Andrew Cooper wrote: > > On 01/06/15 09:58, Jan Beulich wrote: > > On 01.06.15 at 10:50, wrote: > >>> On 06/01/2015 09:48 AM, Ian Campbell wrote: > On Mon, 2015-06-01 at 09:36 +0100, George Dunlap wrote: > >

Re: [Xen-devel] [PATCH OSSTEST] Toolstack: Do not pass -F to xm shutdown (Was: Re: [xen-4.2-testing test] 57630: regressions - FAIL)

On Mon, 2015-06-01 at 10:21 +0100, Jan Beulich wrote: > >>> On 01.06.15 at 10:34, wrote: > > Subject: [PATCH] Toolstack: Do not pass -F to xm shutdown > > > > This is a feature of xl only. > > > > Signed-off-by: Ian Campbell > > --- > > Osstest/Toolstack/xl.pm | 2 +- > > 1 file changed, 1 ins

Re: [Xen-devel] [PATCH OSSTEST] Toolstack: Do not pass -F to xm shutdown (Was: Re: [xen-4.2-testing test] 57630: regressions - FAIL)

>>> On 01.06.15 at 11:42, wrote: > On Mon, 2015-06-01 at 10:21 +0100, Jan Beulich wrote: >> >>> On 01.06.15 at 10:34, wrote: >> > Subject: [PATCH] Toolstack: Do not pass -F to xm shutdown >> > >> > This is a feature of xl only. >> > >> > Signed-off-by: Ian Campbell >> > --- >> > Osstest/Tools

Re: [Xen-devel] [xen-unstable test] 57488: regressions - trouble: broken/fail/pass

>>> On 30.05.15 at 01:24, wrote: > flight 57488 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/57488/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-freebsd10-amd64 14 guest-saverest

Re: [Xen-devel] [xen-unstable test] 57644: regressions - trouble: blocked/broken/fail/pass

On Mon, 2015-06-01 at 03:40 +, osstest service user wrote: > flight 57644 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/57644/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-armhf-armhf-xl-c

Re: [Xen-devel] [PATCH OSSTEST] Toolstack: Do not pass -F to xm shutdown (Was: Re: [xen-4.2-testing test] 57630: regressions - FAIL)

On Mon, 2015-06-01 at 09:34 +0100, Ian Campbell wrote: > From aa79bd958fe42da2876fd76e61468c183a7fabdc Mon Sep 17 00:00:00 2001 > From: Ian Campbell > Date: Mon, 1 Jun 2015 09:32:37 +0100 > Subject: [PATCH] Toolstack: Do not pass -F to xm shutdown > > This is a feature of xl only. > > Signed-off

Re: [Xen-devel] [PATCH] libxl: Don't insert PCI device into xenstore for HVM guests

On Fri, May 29, 2015 at 8:59 AM, Ross Lagerwall wrote: > When doing passthrough of a PCI device for an HVM guest, don't insert > the device into xenstore, otherwise pciback attempts to use it which > conflicts with QEMU. > > This manifests itself such that the first time a device is passed to a >

[Xen-devel] [PATCH v3 1/4] libxc/libxl: fill xc_hvm_build_args in libxl

When building HVM guests, originally some fields of xc_hvm_build_args are filled in xc_hvm_build (and buried in the wrong function), some are set in libxl__build_hvm before passing xc_hvm_build_args to xc_hvm_build. This is fragile. After examining the code in xc_hvm_build that sets those fields,

[Xen-devel] [PATCH v3 2/4] libxc: print more error messages when failed

No functional changes introduced. Signed-off-by: Wei Liu Cc: Ian Campbell Cc: Ian Jackson --- tools/libxc/xc_hvm_build_x86.c | 30 +++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c index

[Xen-devel] [PATCH v3 3/4] libxc: rework vnuma bits in setup_guest

Make the setup process similar to PV counterpart. That is, to allocate a P2M array that covers the whole memory range and start from there. This is clearer than using an array with no holes in it. Also the dummy layout should take MMIO hole into consideration. We might end up having two vmemranges

[Xen-devel] [PATCH v3 2/2] efi: Avoid calling boot services after ExitBootServices()

After the first call to ExitBootServices(), avoid calling any boot services by setting setting efi_bs to NULL and entering an infinite loop in blexit(). Signed-off-by: Ross Lagerwall --- xen/common/efi/boot.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/x

[Xen-devel] [PATCH v3 0/4] Fix HVM vNUMA

Boris discovered that HVM vNUMA didn't actually work. This patch series fixes that. The first patch is a prerequisite patch for the actual fixes. The second patch is to help debugging. The fixes are in the last two patches, which can be squashed into one if necessary. Patch 1 and 3 are updated in

[Xen-devel] [PATCH v3 4/4] libxl: fix HVM vNUMA

This patch does two thing: The original code erroneously fills in xc_hvm_build_args before generating vmemranges. The effect is that guest memory is populated without vNUMA information. Move the hunk to right place to fix this. Move the subtraction of video ram to libxl__vnuma_build_vmemrange_hvm

[Xen-devel] [PATCH v3 1/2] efi: Fix allocation problems if ExitBootServices() fails

If calling ExitBootServices() fails, the required memory map size may have increased. When initially allocating the memory map, allocate a slightly larger buffer (by an arbitrary 8 entries) to fix this. The ARM code path was already allocating a larger buffer than required, so this moves the code

[Xen-devel] [qemu-mainline test] 57666: regressions - trouble: broken/fail/pass

flight 57666 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/57666/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56831 Tests which are fai

Re: [Xen-devel] [PATCH v3 2/2] efi: Avoid calling boot services after ExitBootServices()

On 01/06/15 11:17, Ross Lagerwall wrote: > After the first call to ExitBootServices(), avoid calling any boot > services by setting setting efi_bs to NULL and entering an infinite loop > in blexit(). > > Signed-off-by: Ross Lagerwall > --- > xen/common/efi/boot.c | 16 +--- > 1 file c

[Xen-devel] [PATCH v2] xen: netback: fix printf format string warning

drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’: drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘int’ [-Wformat=] (txreq.offset&~PAGE_MASK) + txreq.size); ^ PAGE_MASK's typ

[Xen-devel] [PATCH v2 net] xen: netback: read hotplug script once at start of day.

When we come to tear things down in netback_remove() and generate the uevent it is possible that the xenstore directory has already been removed (details below). In such cases netback_uevent() won't be able to read the hotplug script and will write a xenstore error node. A recent change to the hy

Re: [Xen-devel] [PATCH v3 2/2] efi: Avoid calling boot services after ExitBootServices()

>>> On 01.06.15 at 12:26, wrote: > On 01/06/15 11:17, Ross Lagerwall wrote: >> --- a/xen/common/efi/boot.c >> +++ b/xen/common/efi/boot.c >> @@ -216,6 +216,12 @@ static void __init noreturn blexit(const CHAR16 *str) >> PrintStr((CHAR16 *)str); >> PrintStr(newline); >> >> +if (

Re: [Xen-devel] Running 3.9 kernel in domU with 3.11 kernel in dom0

On 30/05/15 14:43, Gautam Malu wrote: > Hi, Hello, It's not necessary to send the same mail twice at one day of interval. The mail will be answered as soon as we can... The xen-arm mailing list has been archived few months ago and this question should be asked on xen-users given it's more a conf

Re: [Xen-devel] [PATCH v23 10/15] x86/VPMU: Use pre-computed masks when checking validity of MSRs

>>> On 29.05.15 at 20:42, wrote: > No need to compute those masks on every MSR access. > > Also, when checking MSR_P6_EVNTSELx registers make sure that bit 21 > is not set. I had hoped you would save me and other readers to look up what this bit means by giving a reason why this change is wanted

Re: [Xen-devel] [PATCH v3 1/2] efi: Fix allocation problems if ExitBootServices() fails

>>> On 01.06.15 at 12:17, wrote: > If calling ExitBootServices() fails, the required memory map size may > have increased. When initially allocating the memory map, allocate a > slightly larger buffer (by an arbitrary 8 entries) to fix this. > > The ARM code path was already allocating a larger b

Re: [Xen-devel] [PATCH] xen/arm: gic-hip04: Resync the driver with the GICv2

Hi, On 18/05/15 14:36, Zoltan Kiss wrote: > > > On 15/05/15 22:08, Julien Grall wrote: >> Hi Zoltan, >> >> On 07/05/2015 13:37, Zoltan Kiss wrote: >> >>> On 07/05/15 10:32, Ian Campbell wrote: On Thu, 2015-05-07 at 09:52 +0100, Zoltan Kiss wrote: > Looks good at first glance, let me try

Re: [Xen-devel] [PATCH] xen/arm: gic-hip04: Resync the driver with the GICv2

On Mon, 2015-06-01 at 12:13 +0100, Julien Grall wrote: > Hi, > > On 18/05/15 14:36, Zoltan Kiss wrote: > > > > > > On 15/05/15 22:08, Julien Grall wrote: > >> Hi Zoltan, > >> > >> On 07/05/2015 13:37, Zoltan Kiss wrote: > >> > >>> On 07/05/15 10:32, Ian Campbell wrote: > On Thu, 2015-05-07

Re: [Xen-devel] [PATCH v2] xen: netback: fix printf format string warning

On Mon, Jun 01, 2015 at 11:30:04AM +0100, Ian Campbell wrote: > drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’: > drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects > argument of type ‘long unsigned int’, but argument 5 has type ‘int’ > [-Wformat=] >

Re: [Xen-devel] [PATCH v3 1/2] efi: Fix allocation problems if ExitBootServices() fails

On Mon, 2015-06-01 at 12:10 +0100, Jan Beulich wrote: > >>> On 01.06.15 at 12:17, wrote: > > If calling ExitBootServices() fails, the required memory map size may > > have increased. When initially allocating the memory map, allocate a > > slightly larger buffer (by an arbitrary 8 entries) to fix

Re: [Xen-devel] [PATCH v2 net] xen: netback: read hotplug script once at start of day.

On Mon, Jun 01, 2015 at 11:30:24AM +0100, Ian Campbell wrote: > When we come to tear things down in netback_remove() and generate the > uevent it is possible that the xenstore directory has already been > removed (details below). > > In such cases netback_uevent() won't be able to read the hotplug

Re: [Xen-devel] [PATCH] xen/arm: gic-hip04: Resync the driver with the GICv2

Hi, Yes, we managed to test it, and it works. Then only thing I've found is this bit: +/* Only 1020 interrupts are supported */ +gicv2_info.nr_lines = min(1020U, nr_lines); This interrupt controller only supports 511, so 1020 should be replaced. We had such checking in the code in th

[Xen-devel] [linux-linus test] 57671: trouble: blocked/broken/fail/pass

flight 57671 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/57671/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken REGR. vs. 57442

Re: [Xen-devel] [PATCH] xen/arm: gic-hip04: Resync the driver with the GICv2

On 01/06/15 12:25, Zoltan Kiss wrote: > Hi, > > Yes, we managed to test it, and it works. Then only thing I've found is > this bit: > > +/* Only 1020 interrupts are supported */ > +gicv2_info.nr_lines = min(1020U, nr_lines); > > This interrupt controller only supports 511, so 1020 should

Re: [Xen-devel] [Draft C] Xen on ARM vITS Handling

On Wed, 2015-05-27 at 22:14 +0530, Vijay Kilari wrote: > > ## pITS Scheduling > > > > A pITS scheduling pass is attempted: > > > > * On write to any virtual `CWRITER` iff that write results in there > > being new outstanding requests for that vits; > >You mean, scheduling pass (softirq trigg

[Xen-devel] [rumpuserxen test] 57717: regressions - FAIL

flight 57717 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/57717/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxe

Re: [Xen-devel] [PATCH] frontswap: allow multiple backends

On Fri, May 29, 2015 at 6:07 PM, Andrew Morton wrote: > On Thu, 28 May 2015 16:28:37 -0400 Dan Streetman wrote: > >> Change frontswap single pointer to a singly linked list of frontswap >> implementations. Update Xen tmem implementation as register no longer >> returns anything. >> >> Frontswap

Re: [Xen-devel] [Draft C] Xen on ARM vITS Handling

On 01/06/15 13:11, Ian Campbell wrote: >>> ### Device ID (`ID`) >>> >>> This parameter is used by commands which manage a specific device and >>> the interrupts associated with that device. Checking if a device is >>> present and retrieving the data structure must be fast. >>> >>> The device identi

[Xen-devel] [PATCH V6 02/10] xen/arm: Add functions of mapping between vCPUID and virtual affinity

From: Chen Baozi GICv3 restricts that the maximum number of CPUs in affinity 0 (one cluster) is 16. That is to say the upper 4 bits of affinity 0 is unused. Current implementation considers that AFF0 is equal to vCPUID, which makes all vCPUs in one cluster, limiting its number to 16. If we would

[Xen-devel] [PATCH V6 01/10] xen/arm: gic-v3: Increase the size of GICR in address space for guest

From: Chen Baozi Currently it only supports up to 8 vCPUs. Increase the region to hold up to 128 vCPUs, which is the maximum number that GIC-500 supports. Signed-off-by: Chen Baozi Reviewed-by: Julien Grall --- xen/include/public/arch-arm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletio

[Xen-devel] [PATCH V6 03/10] xen/arm: Use the new functions for vCPUID/vaffinity transformation

From: Chen Baozi There are 3 places to change: * Initialise vMPIDR value in vcpu_initialise() * Find the vCPU from vMPIDR affinity information when accessing GICD registers in vGIC * Find the vCPU from vMPIDR affinity information when booting with vPSCI in vGIC - Also make the code for PSC

[Xen-devel] [PATCH V6 00/10] Support more than 8 vcpus on arm64 with GICv3

From: Chen Baozi Currently the number of vcpus on arm64 with GICv3 is limited up to 8 due to the fixed size of redistributor mmio region. Increasing the size makes the number expand to 16 because of AFF0 restriction on GICv3. To create a guest up to 128 vCPUs, which is the maxium number that GIC-

[Xen-devel] [PATCH V6 04/10] xen/arm: Use cpumask_t type for vcpu_mask in vgic_to_sgi

From: Chen Baozi Use cpumask_t instead of unsigned long which can only express 64 cpus at the most. Add the {gicv2|gicv3}_sgir_to_cpumask in corresponding vGICs to translate GICD_SGIR/ICC_SGI1R_EL1 to vcpu_mask for vgic_to_sgi. Signed-off-by: Chen Baozi --- xen/arch/arm/vgic-v2.c|

[Xen-devel] [PATCH V6 06/10] tools/libxl: Set 'reg' of cpu node equal to MPIDR affinity for domU

From: Chen Baozi According to ARM CPUs bindings, the reg field should match the MPIDR's affinity bits. We will use AFF0 and AFF1 when constructing the reg value of the guest at the moment, for it is enough for the current max vcpu number. Signed-off-by: Chen Baozi Reviewed-by: Julien Grall ---

[Xen-devel] [PATCH V6 05/10] xen/arm64: gicv3: Use AFF1 when translating ICC_SGI1R_EL1 to cpumask

From: Chen Baozi To support more than 16 vCPUs, we have to calculate cpumask with AFF1 field value in ICC_SGI1R_EL1. Signed-off-by: Chen Baozi --- xen/arch/arm/vgic-v3.c| 30 ++ xen/include/asm-arm/gic_v3_defs.h | 2 ++ 2 files changed, 28 insertions(+)

[Xen-devel] [PATCH V6 07/10] xen/arm: Set 'reg' of cpu node for dom0 to match MPIDR's affinity

From: Chen Baozi According to ARM CPUs bindings, the reg field should match the MPIDR's affinity bits. We will use AFF0 and AFF1 when constructing the reg value of the guest at the moment, for it is enough for the current max vcpu number. Signed-off-by: Chen Baozi --- xen/arch/arm/domain_build

[Xen-devel] [PATCH V6 08/10] xen: Add arch_domain_preinit to initialise vGIC before evtchn_init

From: Chen Baozi evtchn_init will call domain_max_vcpus to allocate poll_mask. On arm/arm64 platform, this number is determined by the vGIC the guest is going to use, which won't be initialised until arch_domain_create is called in current implementation. However, moving arch_domain_create means

[Xen-devel] [PATCH V6 09/10] xen/arm: make domain_max_vcpus return value from vgic_ops

From: Chen Baozi When a guest uses vGICv2, the maximum number of vCPU it can support should not be as many as MAX_VIRT_CPUS, which will be more than 8 when GICv3 is used on arm64. So the domain_max_vcpus should return the value according to the vGIC the domain uses. We didn't keep it as the old

[Xen-devel] [PATCH V6 10/10] xen/arm64: increase MAX_VIRT_CPUS to 128 on arm64

From: Chen Baozi After we have increased the size of GICR in address space for guest and made use of both AFF0 and AFF1 in (v)MPIDR, we are now able to support up to 4096 vCPUs in theory. However, it will cost 512M address space for GICR region, which is not necessary big at the moment. Consideri

Re: [Xen-devel] [PATCH] tools: link executables with libtinfo explicitly

On Sat, May 30, 2015 at 12:07:28AM +0200, Daniel Kiper wrote: > binutils 2.22 changed ld default from --copy-dt-needed-entries > to -no-copy-dt-needed-entries. This revealed that some objects > are linked implicitly with libtinfo and newer ld fails to build > relevant executables. > > Below is sho

Re: [Xen-devel] [Draft C] Xen on ARM vITS Handling

On Fri, 2015-05-29 at 14:40 +0100, Julien Grall wrote: > Hi Ian, > > NIT: You used my Linaro email which I think is de-activated now :). I keep finding new address books with that address in them! > > ## ITS Translation Table > > > > Message signalled interrupts are translated into an LPI via a

Re: [Xen-devel] [PATCH] xen/arm: gic-hip04: Resync the driver with the GICv2

On 01/06/15 13:11, Julien Grall wrote: On 01/06/15 12:25, Zoltan Kiss wrote: Hi, Yes, we managed to test it, and it works. Then only thing I've found is this bit: +/* Only 1020 interrupts are supported */ +gicv2_info.nr_lines = min(1020U, nr_lines); This interrupt controller only su

Re: [Xen-devel] [PATCH v4] xen: sched_rt: print useful affinity info when dumping

On 05/12/2015 03:06 PM, Dario Faggioli wrote: > In fact, printing the cpupool's CPU online mask > for each vCPU is just redundant, as that is the > same for all the vCPUs of all the domains in the > same cpupool, while hard affinity is already part > of the output of dumping domains info. > > Inst

Re: [Xen-devel] [PATCH RFC 2/5] blkif: document new blkback path xenstore node

On Fri, May 22, 2015 at 11:18:55AM +0200, Roger Pau Monne wrote: > FreeBSD blkback uses the path xenstore node in order to fetch the path to > the underlying backing storage (either a block device or raw image). This > node is set by the hotplug scripts. > > Signed-off-by: Roger Pau Monné > Cc: I

Re: [Xen-devel] [PATCH] tools: link executables with libtinfo explicitly

On Mon, Jun 01, 2015 at 02:06:44PM +0100, Wei Liu wrote: > On Sat, May 30, 2015 at 12:07:28AM +0200, Daniel Kiper wrote: > > binutils 2.22 changed ld default from --copy-dt-needed-entries > > to -no-copy-dt-needed-entries. This revealed that some objects > > are linked implicitly with libtinfo and

Re: [Xen-devel] [Draft C] Xen on ARM vITS Handling

On Fri, 2015-05-29 at 15:06 +0100, Julien Grall wrote: > Hi Vijay, > > On 27/05/15 17:44, Vijay Kilari wrote: > >> ## Command Translation > >> > >> Of the existing GICv3 ITS commands, `MAPC`, `MAPD`, `MAPVI`/`MAPI` are > >> potentially time consuming commands as these commands creates entry in > >

Re: [Xen-devel] [PATCH] tools: link executables with libtinfo explicitly

On Mon, Jun 01, 2015 at 03:26:58PM +0200, Daniel Kiper wrote: [...] > > > tools/misc/Makefile |2 +- > > > tools/xenstat/xentop/Makefile |2 +- > > > 5 files changed, 53 insertions(+), 2 deletions(-) > > > > > > diff --git a/config/Tools.mk.in b/config/Tools.mk.in > > > index d67

Re: [Xen-devel] [Draft C] Xen on ARM vITS Handling

On Mon, 2015-06-01 at 13:24 +0100, Julien Grall wrote: > On 01/06/15 13:11, Ian Campbell wrote: > >>> ### Device ID (`ID`) > >>> > >>> This parameter is used by commands which manage a specific device and > >>> the interrupts associated with that device. Checking if a device is > >>> present and re

[Xen-devel] [xen-4.5-testing test] 57676: regressions - trouble: broken/fail/pass

flight 57676 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/57676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. vs. 56941 Tests

Re: [Xen-devel] [PATCH] unmodified-drivers: tolerate IRQF_DISABLED being undefined

On Mon, 2015-06-01 at 14:50 +0100, Jan Beulich wrote: > It's being removed in Linux 4.1. > > Signed-off-by: Jan Beulich Not sure who should, but: Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-d

[Xen-devel] [PATCH] unmodified-drivers: tolerate IRQF_DISABLED being undefined

It's being removed in Linux 4.1. Signed-off-by: Jan Beulich --- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c +++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c @@ -350,11 +350,13 @@ int xen_irq_init(struct pci_dev *pdev) #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22)

Re: [Xen-devel] [PATCH] unmodified-drivers: tolerate IRQF_DISABLED being undefined

>>> On 01.06.15 at 15:56, wrote: > On Mon, 2015-06-01 at 14:50 +0100, Jan Beulich wrote: >> It's being removed in Linux 4.1. >> >> Signed-off-by: Jan Beulich > > Not sure who should, but: I guess no-one really needs to for that old code. But thanks! Jan _

[Xen-devel] [PATCHv2] frontswap: allow multiple backends

Change frontswap single pointer to a singly linked list of frontswap implementations. Update Xen tmem implementation as register no longer returns anything. Frontswap only keeps track of a single implementation; any implementation that registers second (or later) will replace the previously regis

[Xen-devel] [xen-4.3-testing test] 57680: regressions - trouble: blocked/broken/fail/pass

flight 57680 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/57680/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 3 host-install(3) broken REGR. vs. 53768 test-amd64-i386-x

[Xen-devel] [PATCH RFC] hotplug/Linux: Add --wait to iptables calls.

This help to avoid guest creation error when a downstream project is also updating the iptables at guest creation time. The error seen is this one: libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-bridge online [-1] exited with error status 4 Apparently, exit

Re: [Xen-devel] [PATCH RFC] hotplug/Linux: Add --wait to iptables calls.

>>> On 01.06.15 at 16:59, wrote: > --- a/tools/hotplug/Linux/vif-common.sh > +++ b/tools/hotplug/Linux/vif-common.sh > @@ -130,9 +130,9 @@ frob_iptable() > local c="-D" >fi > > - iptables "$c" FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev" \ > + iptables --wait "$c" FORWA

Re: [Xen-devel] [PATCH RFC] hotplug/Linux: Add --wait to iptables calls.

On Mon, 2015-06-01 at 16:08 +0100, Jan Beulich wrote: > >>> On 01.06.15 at 16:59, wrote: > > --- a/tools/hotplug/Linux/vif-common.sh > > +++ b/tools/hotplug/Linux/vif-common.sh > > @@ -130,9 +130,9 @@ frob_iptable() > > local c="-D" > >fi > > > > - iptables "$c" FORWARD -m physdev --ph

  1   2   >