[Xen-devel] Interested in taking up a project

Hi, I am interested in doing the following project for Xen, Introducing PowerClamp-like driv

Re: [Xen-devel] Newbie

Thanks for the reply Razvan, but I meant how will i test my code, when I make some changes ? On Fri, Jun 19, 2015 at 12:14 AM, Razvan Cojocaru wrote: > On 06/18/2015 09:40 PM, Abhinav Gupta wrote: > > Hello Xen developers, > > I'm new here. I'm not able to find any link for bugs/issues or > > d

Re: [Xen-devel] Newbie

On 06/18/2015 09:46 PM, Abhinav Gupta wrote: > Thanks for the reply Razvan, but I meant how will i test my code, when I > make some changes ? Well, like any piece of software, you check to see that your changes do what they're supposed to do by running your modified Xen with a relevant test scenar

Re: [Xen-devel] 4.5 qemu tree tagging

>>> On 18.06.15 at 17:14, wrote: > Jan Beulich writes ("4.5 qemu tree tagging"): >> could you please tag the respective qemu trees for 4.5.1? Considering >> the little (if any at all) testing feedback we've been getting on stable >> RCs, and considering how late we are with it, I actually see no p

[Xen-devel] [PATCH 0/2] xen{trace/analyze}: fix build on FreeBSD

Fix the build of xentrace/xenalyze on FreeBSD, and possibly other libcs not having argp. Also fix the usage of fstat64 and O_LARGEFILE. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/2] configure: check for argp

argp is only present in the GNU C library, so add a specific check for it in configure. Also check if -largp is needed for linking against it. Please run autoconf after applying. Signed-off-by: Roger Pau Monné Cc: George Dunlap Cc: Ian Jackson Cc: Ian Campbell Cc: Wei Liu Cc: Olaf Hering --

[Xen-devel] [PATCH 1/2] xen{trace/analyze}: don't use 64bit versions of libc functions

This is not needed, neither encouraged. Configure already checks _FILE_OFFSET_BITS and appends it when needed, so that the right functions are used. Also remove the usage of loff_t and O_LARGEFILE for the same reason. Signed-off-by: Roger Pau Monné Cc: George Dunlap Cc: Ian Jackson Cc: Ian Camp

Re: [Xen-devel] Interested in taking up a project

You should CC the respective technical contact George Dunlap. I've done this for you now. On Fri, Jun 19, 2015 at 07:02:55AM +, Abhinav Gupta wrote: > Hi, > > I am interested in doing the following project for Xen, Introducing >

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

>>> On 18.06.15 at 12:40, wrote: > On 18/06/15 11:36, Jan Beulich wrote: > On 17.06.15 at 14:02, wrote: >>> --- a/xen/common/event_channel.c >>> +++ b/xen/common/event_channel.c >>> @@ -1175,22 +1175,6 @@ int alloc_unbound_xen_event_channel( >>> >>> void free_xen_event_channel(struct domai

Re: [Xen-devel] [PATCH v3 07/11] x86/intel_pstate: changes in cpufreq_del_cpu for CPU offline

>>> On 11.06.15 at 10:28, wrote: > cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we change > to NULL it after the call of cpufreq_driver->exit. Otherwise, a > calltrace will show up on your screen due to the reference of a NULL > pointer when you power down the system. Apart from wh

Re: [Xen-devel] stable trees (was: [xen-4.2-testing test] 58584: regressions)

>>> On 18.06.15 at 16:22, wrote: > On Thu, 2015-06-18 at 12:37 +0100, Jan Beulich wrote: >> >>> On 17.06.15 at 12:26, wrote: >> > Jan Beulich writes ("stable trees (was: [xen-4.2-testing test] 58584: >> > regressions)"): >> >> Which leaves several options: >> >> - the problem was always there, b

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

On 19/06/15 10:29, Jan Beulich wrote: On 18.06.15 at 12:40, wrote: >> On 18/06/15 11:36, Jan Beulich wrote: >> On 17.06.15 at 14:02, wrote: --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -1175,22 +1175,6 @@ int alloc_unbound_xen_event_channel(

Re: [Xen-devel] [PATCH OSSTEST v2 12/19] ts-kernel-build: Support --reuse to keep same build tree

On Thu, 2015-06-18 at 18:58 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 12/19] ts-kernel-build: Support > --reuse to keep same build tree"): > > This is very useful when iterating over kernel configurations, since > > it avoids blowing away the build tree and all the existi

Re: [Xen-devel] [PATCH OSSTEST v2 05/19] Refactor pxelinux configuration

On Thu, 2015-06-18 at 18:49 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 05/19] Refactor pxelinux > configuration"): > > The mechanism used to PXE boot can differ depending on the firmware > > type. Therefore refactor into Osstest::TestSupport and key off a new > > host prop

Re: [Xen-devel] [PATCH OSSTEST v2 17/19] Debian: Ignore xen-syms entries in grub.cfg.

On Thu, 2015-06-18 at 19:04 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 17/19] Debian: Ignore xen-syms > entries in grub.cfg."): > > These can't (in general?) actually be booted. > > They can't be booted at all. That they are included in the menu is a > bug in something.

Re: [Xen-devel] [PATCH OSSTEST v2 07/19] Enable chain loading to local disk for UEFI PXE systems.

On Thu, 2015-06-18 at 18:52 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 07/19] Enable chain loading to local > disk for UEFI PXE systems."): > > First arrange for bootloader to be installed to removable media path, > > by using a new in Jessie preseed option. Then use that

[Xen-devel] [xen-unstable test] 58727: regressions - FAIL

flight 58727 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/58727/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs.

Re: [Xen-devel] [PATCH OSSTEST v2 09/19] ts-kernel-build: Additional kernel options for Mustang

On Thu, 2015-06-18 at 18:55 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 09/19] ts-kernel-build: Additional > kernel options for Mustang"): > > XXX We probably need a newer kernel to actually be useful. > > This doesn't seem quite finished ? Sorry, yes, I forgot about this

Re: [Xen-devel] [PATCH OSSTEST v2 10/19] ts-host-install: Set dtbs in the non-special kernel case too.

On Thu, 2015-06-18 at 18:56 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 10/19] ts-host-install: Set dtbs in > the non-special kernel case too."): > > XXX fold somewhere? > > I don't mind it being in a patch by itself, but I do want a commit > message that tells me why, not

Re: [Xen-devel] [RESEND] nested EPT: fix the handling of nested EPT.

> > > > xen/arch/x86/mm/p2m-ept.c | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m- > ept.c > > > > index 5133eb6..26293a0 100644 > > > > --- a/xen/arch/x86/mm/p2m-ept.c > > > > +++ b/xen/arch/x86/mm/p2m-ept.c > > > > @@

Re: [Xen-devel] [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install

On Thu, 2015-06-18 at 18:57 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order > during install"): > > Debian inserts itself before any existing entries, including the PXE > > one, meaning we otherwise cannot remotely regroove the box. Preseed

Re: [Xen-devel] [PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config

On Thu, 2015-06-18 at 18:59 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 13/19] standalone: Prefer > ./standalone.config to $HOME/.xen-osstest/config"): > > OSSTEST_CONFIG still trumps both. > > This results in us having >standalone-config-example >production-config

Re: [Xen-devel] [PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config

On Fri, 2015-06-19 at 11:22 +0100, Ian Campbell wrote: > On Thu, 2015-06-18 at 18:59 +0100, Ian Jackson wrote: > > Ian Campbell writes ("[PATCH OSSTEST v2 13/19] standalone: Prefer > > ./standalone.config to $HOME/.xen-osstest/config"): > > > OSSTEST_CONFIG still trumps both. > > > > This results

Re: [Xen-devel] Windows install problems on Xeon E5-2403 v2

On Thu, 2015-06-11 at 09:01 +0100, Jan Beulich wrote: > >>> On 11.06.15 at 09:37, wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: Thursday, June 11, 2015 2:58 PM > >> > >> All, > >> > >> we're seeing recurring but intermittent failures in osstest on just the > >> two hosts u

Re: [Xen-devel] performace issue when turn on apicv

>>> On 18.06.15 at 16:55, wrote: > I'm John's colleague. We looked into the details of the tracing data, and > found that the number of MSR_IA32_APICTMICT_MSR > event is quite high when apic-v is enabled(about 9x more compared with apic-v > disabled). > > Below is the details: > > EXIT_REASON_

Re: [Xen-devel] [PATCH OSSTEST v2 01/19] Introduce mg-pxe-loader-update

On Thu, 2015-06-18 at 18:42 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST v2 01/19] Introduce > mg-pxe-loader-update"): > > The story for PXE booting via UEFI (at least on arm64) is not so > > straightforward as with pxelinux on x86. There seems to no good > > bootloader to laun

Re: [Xen-devel] [PATCH OSSTEST v2 05/19] Refactor pxelinux configuration

Ian Campbell writes ("Re: [PATCH OSSTEST v2 05/19] Refactor pxelinux configuration"): > On Thu, 2015-06-18 at 18:49 +0100, Ian Jackson wrote: > > Are you expecting to introduce setup_FIRMWARE_SOMETHINGELSE ? > > I think initially I was initially expecting to but ended up not needing > to. > > I

Re: [Xen-devel] [PATCH OSSTEST v2 10/19] ts-host-install: Set dtbs in the non-special kernel case too.

Ian Campbell writes ("Re: [PATCH OSSTEST v2 10/19] ts-host-install: Set dtbs in the non-special kernel case too."): > On Thu, 2015-06-18 at 18:56 +0100, Ian Jackson wrote: > > I don't mind it being in a patch by itself, but I do want a commit > > message that tells me why, not just what. > > I re

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

>>> On 19.06.15 at 11:52, wrote: > On 19/06/15 10:29, Jan Beulich wrote: > On 18.06.15 at 12:40, wrote: >>> On 18/06/15 11:36, Jan Beulich wrote: >>> On 17.06.15 at 14:02, wrote: > --- a/xen/common/event_channel.c > +++ b/xen/common/event_channel.c > @@ -1175,22 +1175,6 @@ in

Re: [Xen-devel] [PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config

Ian Campbell writes ("Re: [PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config"): > On Fri, 2015-06-19 at 11:22 +0100, Ian Campbell wrote: > > On Thu, 2015-06-18 at 18:59 +0100, Ian Jackson wrote: > > > This results in us having > > >standalone-config-ex

Re: [Xen-devel] [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install

Ian Campbell writes ("Re: [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install"): > On Thu, 2015-06-18 at 18:57 +0100, Ian Jackson wrote: > > This seems a pretty serious bug. Is there a way to avoid it ? > > Unfortunately not as far as I can tell, it seems to be a major > shortc

Re: [Xen-devel] [PATCH OSSTEST v2 05/19] Refactor pxelinux configuration

On Fri, 2015-06-19 at 11:45 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH OSSTEST v2 05/19] Refactor pxelinux > configuration"): > > On Thu, 2015-06-18 at 18:49 +0100, Ian Jackson wrote: > > > Are you expecting to introduce setup_FIRMWARE_SOMETHINGELSE ? > > > > I think initially I

Re: [Xen-devel] Interested in taking up a project

Please use "reply to all" and don't top-post. I added xen-devel@ back to CC list. On Fri, Jun 19, 2015 at 10:40:48AM +, Abhinav Gupta wrote: > Thanks > I need one more suggestion.. Any specific IDE that can help me in the > process of development? > I don't use IDE. I don't think most develo

[Xen-devel] [PATCH] don't put dom0 console info directly after start_info data

The console information of dom0 is living in the same memory page as the start_info data. Don't put the console data directly after the start_info to leave some room for future structure enlargements. Otherwise a dom0 with a newer start_info layout than the hypervisor could interprete console data

[Xen-devel] [PATCH] update comments regarding pv-domain memory layout

The comments describing the initial pv-domain memory layout are not complete. They do not mention the pages with console info and xenstore data. Add this information to the comments. Signed-off-by: Juergen Gross --- xen/include/public/xen.h | 17 ++--- 1 file changed, 10 insertions(

Re: [Xen-devel] stable trees (was: [xen-4.2-testing test] 58584: regressions)

On Fri, 2015-06-19 at 10:51 +0100, Jan Beulich wrote: > >>> On 18.06.15 at 16:22, wrote: > > On Thu, 2015-06-18 at 12:37 +0100, Jan Beulich wrote: > >> >>> On 17.06.15 at 12:26, wrote: > >> > Jan Beulich writes ("stable trees (was: [xen-4.2-testing test] 58584: > >> > regressions)"): > >> >> Whi

Re: [Xen-devel] [PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config

On Fri, 2015-06-19 at 12:04 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH OSSTEST v2 13/19] standalone: Prefer > ./standalone.config to $HOME/.xen-osstest/config"): > > On Fri, 2015-06-19 at 11:22 +0100, Ian Campbell wrote: > > > On Thu, 2015-06-18 at 18:59 +0100, Ian Jackson wrote:

Re: [Xen-devel] [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install

On Fri, 2015-06-19 at 12:02 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot > order during install"): > > On Thu, 2015-06-18 at 18:57 +0100, Ian Jackson wrote: > > > This seems a pretty serious bug. Is there a way to avoid it ? > > > > Unfor

Re: [Xen-devel] [PATCH v2][RFC] libxl: Add AHCI support for upstream qemu

Il 11/06/2015 12:28, Fabio Fantoni ha scritto: Il 11/06/2015 12:06, Zir Blazer ha scritto: Since I'm not a developer I may be peeking my nose a bit too far, but based on what I know, I think that enabling AHCI by default would be a compatibility suicide. I'm not sure about Linux and Windows Vi

[Xen-devel] [xen-4.5-testing test] 58728: regressions - FAIL

flight 58728 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58728/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58717 REGR. vs. 58528 Tests

Re: [Xen-devel] [PATCH] don't put dom0 console info directly after start_info data

>>> On 19.06.15 at 13:06, <"jgr...@suse.com".non-mime.internet> wrote: > The console information of dom0 is living in the same memory page as the > start_info data. Don't put the console data directly after the start_info > to leave some room for future structure enlargements. Otherwise a dom0 > wi

Re: [Xen-devel] [PATCH OSSTEST v3 12/11] toolstack/libvirt: install libnl-3-200 on Jessie

Wei Liu writes ("[PATCH OSSTEST v3 12/11] toolstack/libvirt: install libnl-3-200 on Jessie"): > Signed-off-by: Wei Liu ... > diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm > index e7f4860..c71f88a 100644 > --- a/Osstest/Toolstack/libvirt.pm > +++ b/Osstest/Toolstack/libv

Re: [Xen-devel] [PATCH] don't put dom0 console info directly after start_info data

On 06/19/2015 02:04 PM, Jan Beulich wrote: On 19.06.15 at 13:06, <"jgr...@suse.com".non-mime.internet> wrote: The console information of dom0 is living in the same memory page as the start_info data. Don't put the console data directly after the start_info to leave some room for future structure

[Xen-devel] Developer Summit BoF's (Aug 17 & 18) and Developer Meeting Aug 19 in Seattle

Hi all, I created two pages to help assignment of BoF's and topics that we should cover in the Developer Meeting the day after Developer Summit. You can sign up for BoF's and the Developer Meeting by replying to this mail or by editing the following two wiki pages * http://wiki.xenproject.org/w

Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job

Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job"): > So, may I implement these action via below recipe in sg-run-job? Since, this > would be less code to > be changed and we want to avoid to involve tcl plumbing in sg-run-job. Also, > I thin

Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job

Ian Jackson writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job"): ... > But it isn't as simple as you suggest, unfortunately. Because: > > > proc need-hosts/test-nested {} {return host} > > proc run-job/test-nested {} { > > run-ts . = ts-debian-hvm-install

Re: [Xen-devel] [PATCH] libxc: delete sent_last_iter

Wei Liu writes ("[PATCH] libxc: delete sent_last_iter"): > It's set in code but never used. Detected by -Wunused-but-set-variable. Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH OSSTEST v3 06/11] Cope with Jessie's d-i vg name

Wei Liu writes ("[PATCH OSSTEST v3 06/11] Cope with Jessie's d-i vg name"): > In Jessie the default vg name is changed to "$hostname-vg". Make that > default case and check for wheezy, squeeze and lenny for backward > compatibility. > > Signed-off-by: Wei Liu Acked-by: Ian Jackson

[Xen-devel] [PATCH] xen-netback: fix a BUG() during initialization

From: "Palik, Imre" Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime settable") introduced the capability to change the bandwidth rate limit at runtime. But it also introduced a possible crashing bug. If netback receives two XenbusStateConnected without getting the hotplu

Re: [Xen-devel] [PATCH OSSTEST v3 09/11] ts-xen-build-prep: reverse the test for installing libc6-dev-i386

Wei Liu writes ("[PATCH OSSTEST v3 09/11] ts-xen-build-prep: reverse the test for installing libc6-dev-i386"): > Starting from wheezy, Debian introduced multiarch support, so we need to > install libc6-dev-i386 to build tools. > > Since multiarch will be permanent, we reverse the test to not inst

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

On 19/06/15 11:55, Jan Beulich wrote: On 19.06.15 at 11:52, wrote: >> On 19/06/15 10:29, Jan Beulich wrote: >> On 18.06.15 at 12:40, wrote: On 18/06/15 11:36, Jan Beulich wrote: On 17.06.15 at 14:02, wrote: >> --- a/xen/common/event_channel.c >> +++ b/xen/common/ev

[Xen-devel] [xen-4.4-testing test] 58730: regressions - FAIL

flight 58730 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58730/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 58451 test-amd64-amd64

Re: [Xen-devel] [PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates to better handle Jessie onwards.

Wei Liu writes ("[PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates to better handle Jessie onwards."): > From: Ian Campbell > > In mg-debian-installer-update: > > - Expand the list of (suite,arch) combinations which don't exist and > move it to the top. ... > -# Newer kerne

[Xen-devel] [OSSTEST PATCH 1/2] config: Default Stash to $c{Logs}, not "logs"

Signed-off-by: Ian Jackson --- Osstest.pm |3 ++- production-config |1 - production-config-cambridge |1 - 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/Osstest.pm b/Osstest.pm index 8948666..fc46487 100644 --- a/Osstest.pm +++ b/Osstest.pm

[Xen-devel] [OSSTEST PATCH 2/2] config: Computed defaults for Logs and Results

Signed-off-by: Ian Jackson --- Osstest.pm |9 +++-- production-config |2 -- production-config-cambridge |2 -- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/Osstest.pm b/Osstest.pm index fc46487..c89c941 100644 --- a/Osstest.pm +++ b/Os

[Xen-devel] [PATCH v2] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node

When the property "clock-frequency" is present in the DT timer node, it means that the bootloader/firmware didn't correctly configure the CNTFRQ/CNTFRQ_EL0 on each processor. The best solution would be to fix the offending firmware/bootloader, although it may not always be possible to modify and r

Re: [Xen-devel] [OSSTEST PATCH 1/2] config: Default Stash to $c{Logs}, not "logs"

On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote: > Signed-off-by: Ian Jackson Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH 2/2] config: Computed defaults for Logs and Results

On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote: > Signed-off-by: Ian Jackson No functional change AFAICT. Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

>>> On 11.06.15 at 11:51, wrote: > On 11/06/15 09:35, Jan Beulich wrote: >> While I continue to be of the opinion that all direct writes to >> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask, >> MSI per entry mask) outside of the hypervisor are wrong and >> should be eliminated, the s

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

>>> On 19.06.15 at 14:23, wrote: > On 19/06/15 11:55, Jan Beulich wrote: > On 19.06.15 at 11:52, wrote: >>> On 19/06/15 10:29, Jan Beulich wrote: >>> On 18.06.15 at 12:40, wrote: > On 18/06/15 11:36, Jan Beulich wrote: > On 17.06.15 at 14:02, wrote: >>> --- a/xen/common/

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

On June 19, 2015 9:00:39 AM EDT, Jan Beulich wrote: On 11.06.15 at 11:51, wrote: >> On 11/06/15 09:35, Jan Beulich wrote: >>> While I continue to be of the opinion that all direct writes to >>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask, >>> MSI per entry mask) outside of t

Re: [Xen-devel] [PATCH 1/2] xen{trace/analyze}: don't use 64bit versions of libc functions

On Fri, Jun 19, 2015 at 10:58:24AM +0200, Roger Pau Monne wrote: > This is not needed, neither encouraged. Configure already checks > _FILE_OFFSET_BITS and appends it when needed, so that the right functions > are used. Also remove the usage of loff_t and O_LARGEFILE for the same > reason. > > Sig

Re: [Xen-devel] [PATCH 2/2] configure: check for argp

On Fri, Jun 19, 2015 at 10:58:25AM +0200, Roger Pau Monne wrote: > argp is only present in the GNU C library, so add a specific check for it in > configure. Also check if -largp is needed for linking against it. > > Please run autoconf after applying. > > Signed-off-by: Roger Pau Monné > Cc: Geo

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

Hi, On 6/18/2015 10:54 PM, Ian Campbell wrote: On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote: Hi, I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have no clear idea about why Dom0 kernel panic. Have you confirmed that this same kernel runs reliably natively on this plat

Re: [Xen-devel] [OSSTEST PATCH 2/2] config: Computed defaults for Logs and Results

Ian Campbell writes ("Re: [OSSTEST PATCH 2/2] config: Computed defaults for Logs and Results"): > On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote: > > Signed-off-by: Ian Jackson > > No functional change AFAICT. Indeed. I have collected these and your --reuse patch into a branch of miscell

Re: [Xen-devel] [PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates to better handle Jessie onwards.

On Wed, 2015-06-17 at 14:06 +0100, Wei Liu wrote: > +case $suite_$arch in Sorry, this is buggy, it looks for a variable named "suite_" which doesn't exist and so nothing matches. It needs this: diff --git a/mg-debian-installer-update b/mg-debian-installer-update index b9b1146..6a26675 100755 ---

[Xen-devel] Raisin moving to git://xenbits.xen.org/raisin.git

Hi all, The Raisin git repository has just moved out of my personal git space on xenbits to a more official location. The new git Raisin URL is: git://xenbits.xen.org/raisin.git http://xenbits.xen.org/gitweb/?p=raisin.git Cheers, Stefano ___ Xen-deve

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

El 19/06/15 a les 15.00, Jan Beulich ha escrit: On 11.06.15 at 11:51, wrote: >> On 11/06/15 09:35, Jan Beulich wrote: >>> While I continue to be of the opinion that all direct writes to >>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask, >>> MSI per entry mask) outside of the hy

Re: [Xen-devel] performace issue when turn on apicv

On Thu, Jun 18, 2015 at 10:35:37AM +0100, Jan Beulich wrote: > >>> On 18.06.15 at 11:18, wrote: > > Jan Beulich wrote on 2015-06-18: > > On 18.06.15 at 10:53, wrote: > >>> Jan Beulich wrote on 2015-06-18: > >>> On 18.06.15 at 10:20, wrote: > > Apart from that I notice that the EXIT_R

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

>>> On 19.06.15 at 15:05, wrote: >>And now that I started looking into what it takes to make this >>work, I'm having a deja vu: In order for us to reliably intercept >>all CFG accesses, we need to whitelist the MMCFG pages of >>devices we know we don't care about being written. I.e. we >>need to s

Re: [Xen-devel] [PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates to better handle Jessie onwards.

On Fri, Jun 19, 2015 at 02:50:34PM +0100, Ian Campbell wrote: > On Wed, 2015-06-17 at 14:06 +0100, Wei Liu wrote: > > +case $suite_$arch in > > Sorry, this is buggy, it looks for a variable named "suite_" which > doesn't exist and so nothing matches. It needs this: > > diff --git a/mg-debian-inst

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

>>> On 19.06.15 at 16:07, wrote: > I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but > for it to have any effect we need to stop unconditionally mapping > everything as MMIO regions on PVH Dom0. Right, I didn't mean to imply PVH would have any chance of working right now. B

[Xen-devel] [PATCH] xen/events/fifo: Consume unprocessed events when a CPU dies

When a CPU is offlined, there may be unprocessed events on a port for that CPU. If the port is subsequently reused on a different CPU, it could be in an unexpected state with the link bit set, resulting in interrupts being missed. Fix this by consuming any unprocessed events for a particular CPU w

[Xen-devel] [PATCH OSSTEST] ts-libvirt-build: Enable debug symbols in binaries

... by passing -g as appropriate. Also ensure debug logging is enabled with --enable-debug (which doesn't imply -g during build!). Signed-off-by: Ian Campbell --- ts-libvirt-build | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ts-libvirt-build b/ts-libvirt-build index 3

Re: [Xen-devel] [PATCH] xen-netback: fix a BUG() during initialization

On Fri, Jun 19, 2015 at 02:21:51PM +0200, Imre Palik wrote: > From: "Palik, Imre" > > Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime > settable") > introduced the capability to change the bandwidth rate limit at runtime. > But it also introduced a possible crashing bug.

Re: [Xen-devel] [PATCH] xen/events/fifo: Consume unprocessed events when a CPU dies

On 06/19/2015 11:15 AM, Ross Lagerwall wrote: When a CPU is offlined, there may be unprocessed events on a port for that CPU. If the port is subsequently reused on a different CPU, it could be in an unexpected state with the link bit set, resulting in interrupts being missed. Fix this by consumi

Re: [Xen-devel] [PATCH] xen/events/fifo: Consume unprocessed events when a CPU dies

On 19/06/15 17:02, Boris Ostrovsky wrote: > On 06/19/2015 11:15 AM, Ross Lagerwall wrote: >> When a CPU is offlined, there may be unprocessed events on a port for >> that CPU. If the port is subsequently reused on a different CPU, it >> could be in an unexpected state with the link bit set, result

Re: [Xen-devel] [PATCH OSSTEST] ts-libvirt-build: Enable debug symbols in binaries

Ian Campbell writes ("[PATCH OSSTEST] ts-libvirt-build: Enable debug symbols in binaries"): > ... by passing -g as appropriate. > > Also ensure debug logging is enabled with --enable-debug (which > doesn't imply -g during build!). > > Signed-off-by: Ian Campbell Acked-by: Ian Jackson And bun

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

flight 58731 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/58731/ 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 OSSTEST v3 12/11] toolstack/libvirt: install libnl-3-200 on Jessie

On Fri, Jun 19, 2015 at 01:05:55PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH OSSTEST v3 12/11] toolstack/libvirt: install > libnl-3-200 on Jessie"): > > Signed-off-by: Wei Liu > ... > > diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm > > index e7f4860..c71f88a 1

[Xen-devel] [PATCH libvirt] libxl: avoid freeing an uninitialised bitmap

If vm->def->cputune.nvcpupin is 0 in libxlDomainSetVcpuAffinities (as seems to be the case on arm) then the VIR_FREE after cleanup: would be operating on an uninitialised pointer in map.map. Fix this by using libxl_bitmap_init and libxl_bitmap_dispose in the appropriate places (like VIR_FREE libxl

Re: [Xen-devel] [libvirt] [PATCH libvirt] libxl: avoid freeing an uninitialised bitmap

On 06/19/2015 10:33 AM, Ian Campbell wrote: > If vm->def->cputune.nvcpupin is 0 in libxlDomainSetVcpuAffinities (as > seems to be the case on arm) then the VIR_FREE after cleanup: would be > operating on an uninitialised pointer in map.map. > > Fix this by using libxl_bitmap_init and libxl_bitmap_

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

On 19/06/15 14:04, Jan Beulich wrote: On 19.06.15 at 14:23, wrote: >> On 19/06/15 11:55, Jan Beulich wrote: >> On 19.06.15 at 11:52, wrote: On 19/06/15 10:29, Jan Beulich wrote: On 18.06.15 at 12:40, wrote: >> On 18/06/15 11:36, Jan Beulich wrote: >> On 17.06.1

[Xen-devel] [qemu-mainline test] 58732: regressions - FAIL

flight 58732 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/58732/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 58721 Regressions whic

[Xen-devel] [ovmf test] 58734: regressions - FAIL

flight 58734 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/58734/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 58723 Regressions which are regard

[Xen-devel] [PATCH v25 07/15] x86/VPMU: Save VPMU state for PV guests during context switch

Save VPMU state during context switch for both HVM and PV(H) guests. A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs is_running to be correctly set/cleared. To prepare for that, call context_

[Xen-devel] [PATCH v25 03/15] x86/VPMU: Make vpmu not HVM-specific

vpmu structure will be used for both HVM and PV guests. Move it from hvm_vcpu to arch_vcpu. Signed-off-by: Boris Ostrovsky Acked-by: Jan Beulich Reviewed-by: Kevin Tian Reviewed-by: Dietmar Hahn Tested-by: Dietmar Hahn --- xen/include/asm-x86/domain.h | 2 ++ xen/include/asm-x86/hvm/vcpu.h

[Xen-devel] [PATCH v25 00/15] x86/PMU: Xen PMU PV(H) support

Changes in v25: * Add extra check for consistency in patch 4 * Replace few returns with 'ret = -E...' (patches 4 and 12) * Clarified commit message in patch 8 * A couple of cosmetic changes in patch 12 (I left AMD multi-counter problem unfixed since what I thought would be sufficient to fix it did

[Xen-devel] [PATCH v25 09/15] x86/VPMU: Add support for PMU register handling on PV guests

Intercept accesses to PMU MSRs and process them in VPMU module. If vpmu ops for VCPU are not initialized (which is the case, for example, for PV guests that are not "VPMU-enlightened") access to MSRs will return failure. Dump VPMU state for all domains (HVM and PV) when requested. Signed-off-by:

[Xen-devel] [PATCH v25 04/15] x86/VPMU: Interface for setting PMU mode and flags

Add runtime interface for setting PMU mode and flags. Three main modes are provided: * XENPMU_MODE_OFF: PMU is not virtualized * XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts. * XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0 can profile itself

[Xen-devel] [PATCH v25 12/15] x86/VPMU: Handle PMU interrupts for PV(H) guests

Add support for handling PMU interrupts for PV(H) guests. VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush hypercall. This allows the guest to access PMU MSR values that are stored in VPMU context which is shared between hypervisor and domain, thus avoiding traps to hy

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

No need to compute those masks on every MSR access. Also, when checking MSR_P6_EVNTSELx registers make sure that bit 21 (which is a reserved bit) is not set. Signed-off-by: Boris Ostrovsky Acked-by: Kevin Tian --- xen/arch/x86/hvm/vmx/vpmu_core2.c | 28 ++-- 1 file chan

[Xen-devel] [PATCH v25 01/15] common/symbols: Export hypervisor symbols to privileged guest

Export Xen's symbols as {} triplet via new XENPF_get_symbol hypercall Signed-off-by: Boris Ostrovsky Acked-by: Daniel De Graaf Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Dietmar Hahn Tested-by: Dietmar Hahn --- xen/arch/x86/platform_hypercall.c | 28 +++ xen/common/sym

[Xen-devel] [PATCH v25 05/15] x86/VPMU: Initialize VPMUs with __initcall

Move some VPMU initilization operations into __initcalls to avoid performing same tests and calculations for each vcpu. Signed-off-by: Boris Ostrovsky Acked-by: Jan Beulich --- xen/arch/x86/hvm/svm/vpmu.c | 106 -- xen/arch/x86/hvm/vmx/vpmu_core2.c | 151 ++

[Xen-devel] [PATCH v25 15/15] x86/VPMU: Move VPMU files up from hvm/ directory

Since PMU is now not HVM specific we can move VPMU-related files up from arch/x86/hvm/ directory. Specifically: arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c include/asm-x86/h

[Xen-devel] [PATCH v25 06/15] x86/VPMU: Initialize PMU for PV(H) guests

Code for initializing/tearing down PMU for PV guests Signed-off-by: Boris Ostrovsky Acked-by: Daniel De Graaf Acked-by: Jan Beulich Acked-by: Kevin Tian --- tools/flask/policy/policy/modules/xen/xen.te | 4 + xen/arch/x86/domain.c| 2 + xen/arch/x86/hvm/hvm.c

[Xen-devel] [PATCH v25 08/15] x86/VPMU: When handling MSR accesses, leave fault injection to callers

Hypervisor cannot easily inject faults into PV guests from arch-specific VPMU read/write MSR handlers (unlike it is in the case of HVM guests). With this patch vpmu_do_msr() will return an error code to indicate whether an error was encountered during MSR processing (instead of stating that the ac

[Xen-devel] [PATCH v25 02/15] x86/VPMU: Add public xenpmu.h

Add pmu.h header files, move various macros and structures that will be shared between hypervisor and PV guests to it. Move MSR banks out of architectural PMU structures to allow for larger sizes in the future. The banks are allocated immediately after the context and PMU structures store offsets

[Xen-devel] [PATCH v25 14/15] x86/VPMU: Add privileged PMU mode

Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged domain (dom0) profile both itself (and the hypervisor) and the guests. While this mode is on profiling in guests is disabled. Signed-off-by: Boris Ostrovsky Acked-by: Jan Beulich --- xen/arch/x86/hvm/vpmu.c | 40

[Xen-devel] [PATCH v25 13/15] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr

The two routines share most of their logic. Signed-off-by: Boris Ostrovsky Reviewed-by: Dietmar Hahn --- xen/arch/x86/hvm/vpmu.c| 75 -- xen/include/asm-x86/hvm/vpmu.h | 14 ++-- 2 files changed, 41 insertions(+), 48 deletions(-) diff --git a

  1   2   >