Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Friday, February 05, 2016 7:24 PM > > > -Original Message- > > From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of > > George Dunlap > > Sent: 05 February 2016 11:14 > > To: Paul Durrant > > Cc: Jan Beulich; George D

[Xen-devel] [PATCH v4 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

This patch moves monitor_domctl to common-side. Purpose: move what's common to common, prepare for implementation of such vm-events on ARM. * move get_capabilities to arch-side => arch_monitor_get_capabilities. * add arch-side monitor op handling function => arch_monitor_domctl_op. e.g. X86-side

[Xen-devel] [PATCH v4 0/2] Vm-events: move monitor vm-events code to common-side.

This patch series is an attempt to move some of the monitor vm-events code to the common-side. Done to make it easier to move additional parts that can be moved to common when ARM-side implementations are to be added. Patches summary: 1. Fix file comment Acked-by: Stefano Stabellini 2. Move m

[Xen-devel] [PATCH v4 1/2] xen/arm: fix file comments

Add file header comment and local variable block @ EOF of xen/arch/arm/hvm.c. Signed-off-by: Corneliu ZUZU Acked-by: Stefano Stabellini --- Changed since v2 (mistakenly not included in v3): --- xen/arch/arm/hvm.c | 29 - 1 file changed, 28 insertions(+), 1 deletion

Re: [Xen-devel] [PATCH 6/8] xen/x86: Avoid overriding initialisers in arrays

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, February 10, 2016 4:02 AM > > Clang objects to having multiple initialisers when creating an array. > > As this warning is useful for spotting obscure bugs, disabling it is > unhelpful. Instead, fix our two deliberate us

Re: [Xen-devel] [PATCH v3 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

> From: Tamas K Lengyel [mailto:tleng...@novetta.com] > Sent: Tuesday, February 16, 2016 3:04 AM > > Sending the dr7 register during vm_events is useful for various applications, > but the current way the register value is gathered is incorrent. In this patch > we extend vmx_vmcs_save so that we g

[Xen-devel] [linux-next test] 82649: regressions - trouble: blocked/broken/fail/pass

flight 82649 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/82649/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 8 leak-check/basis(8) fail REGR. vs. 82419 test-amd64-amd64-xl-qe

Re: [Xen-devel] [PATCH v11 1/2] vmx: VT-d posted-interrupt core logic handling

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, February 2, 2016 5:53 PM > To: Wu, Feng > Cc: Andrew Cooper ; Dario Faggioli > ; George Dunlap ; > Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser > > Subject: RE: [PATCH v11 1/2] vmx: VT-d posted-in

Re: [Xen-devel] [PATCH v11 1/2] vmx: VT-d posted-interrupt core logic handling

> -Original Message- > From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: Wednesday, February 10, 2016 8:36 PM > To: Wu, Feng ; xen-devel@lists.xen.org > Cc: Keir Fraser ; Jan Beulich ; Andrew > Cooper ; Tian, Kevin ; > George Dunlap ; Dario Faggioli > > Subject: Re: [PATCH v1

Re: [Xen-devel] [PATCH v11 1/2] vmx: VT-d posted-interrupt core logic handling

> -Original Message- > From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: Wednesday, February 10, 2016 8:25 PM > To: Wu, Feng ; Jan Beulich > Cc: Andrew Cooper ; Dario Faggioli > ; George Dunlap ; > Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser > > Subject: Re: [PATCH v1

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

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

Re: [Xen-devel] [PATCH v5][RFC]xen: sched: convert RTDS from time to event driven model

Hi Tianyang, Thanks for the patch! Great work and really quick action! :-) I will just comment on something I quickly find out and would look forwarding to Dario's comment. On Mon, Feb 8, 2016 at 11:33 PM, Tianyang Chen wrote: > Changes since v4: > removed unnecessary replenishment queue che

[Xen-devel] [libvirt test] 82637: regressions - FAIL

flight 82637 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/82637/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 82511 Tests which did not succe

[Xen-devel] [qemu-upstream-4.5-testing test] 82621: tolerable FAIL - PUSHED

flight 82621 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/82621/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 6 xen-boot fail in 82431 pass in 82621 test-amd64-i386-xl-qe

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

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

[Xen-devel] [linux-mingo-tip-master test] 82581: regressions - FAIL

flight 82581 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/82581/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684 build-amd6

[Xen-devel] [xen-unstable-smoke test] 82717: tolerable all pass - PUSHED

flight 82717 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/82717/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

Re: [Xen-devel] [PATCH] stubdom: fix link farm runes

Wei Liu, on Mon 15 Feb 2016 19:40:28 +, wrote: > Previously in the three problematic libraries all public headers were > linked to source code directory. We should have created a include > directory and link headers there. > > Signed-off-by: Wei Liu Indeed, 31d2d1e0 (Move xenstore and libxc

Re: [Xen-devel] [PATCH] stubdom: fix link farm runes

On Mon, Feb 15, 2016 at 07:40:28PM +, Wei Liu wrote: > Previously in the three problematic libraries all public headers were > linked to source code directory. We should have created a include > directory and link headers there. We should have created an include directory for each library and

[Xen-devel] [PATCH] stubdom: fix link farm runes

Previously in the three problematic libraries all public headers were linked to source code directory. We should have created a include directory and link headers there. Signed-off-by: Wei Liu --- Cc: Ian Jackson Cc: Stefano Stabellini Cc: Ian Campbell Cc: Wei Liu Cc: Samuel Thibault --- st

Re: [Xen-devel] [PATCH v2 12/30] xen/x86: Generate deep dependencies of features

On 15/02/16 16:27, Jan Beulich wrote: On 15.02.16 at 17:09, wrote: >> On 15/02/16 15:52, Jan Beulich wrote: >> --- a/xen/tools/gen-cpuid.py >> +++ b/xen/tools/gen-cpuid.py >> @@ -138,6 +138,61 @@ def crunch_numbers(state): >> state.hvm_shadow = featureset_to_uint32s(state

[Xen-devel] [PATCH v3 2/2] vm_event: consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs

Currently the registers saved in the request depend on which type of event is filling in the registers. In this patch we consolidate the two versions of register filling function as to return a fix set of registers irrespective of the underlying event. Signed-off-by: Tamas K Lengyel Acked-by: Geo

[Xen-devel] [PATCH v3 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

Sending the dr7 register during vm_events is useful for various applications, but the current way the register value is gathered is incorrent. In this patch we extend vmx_vmcs_save so that we get the correct value. Suggested-by: Andrew Cooper Signed-off-by: Tamas K Lengyel --- Cc: Jun Nakajima

Re: [Xen-devel] [PATCH v3 1/2] xen/x86: merge 2 hvm_event_... functions into 1

On 02/15/2016 07:54 PM, Corneliu ZUZU wrote: > On 2/15/2016 7:47 PM, Tamas K Lengyel wrote: >> >> >> On Mon, Feb 15, 2016 at 10:40 AM, Corneliu ZUZU > > wrote: >> >> On 2/15/2016 10:30 AM, Razvan Cojocaru wrote: >> >> On 02/15/2016 08:35 AM, Corneliu ZUZU w

Re: [Xen-devel] [PATCH v3 1/2] xen/x86: merge 2 hvm_event_... functions into 1

On 2/15/2016 7:47 PM, Tamas K Lengyel wrote: On Mon, Feb 15, 2016 at 10:40 AM, Corneliu ZUZU > wrote: On 2/15/2016 10:30 AM, Razvan Cojocaru wrote: On 02/15/2016 08:35 AM, Corneliu ZUZU wrote: This patch merges almost identical functions

Re: [Xen-devel] [PATCH] docs: document shortcomings of running QEMU as non-root

On Tue, Feb 09, 2016 at 06:30:45PM +, Ian Jackson wrote: > Stefano Stabellini writes ("[PATCH] docs: document shortcomings of running > QEMU as non-root"): > > Running QEMU as non-root causes migration and PCI passthrough not to > > work properly. Migration can be fixed rather easily > > (http

Re: [Xen-devel] [PATCH v3 1/2] xen/x86: merge 2 hvm_event_... functions into 1

On Mon, Feb 15, 2016 at 10:40 AM, Corneliu ZUZU wrote: > On 2/15/2016 10:30 AM, Razvan Cojocaru wrote: > >> On 02/15/2016 08:35 AM, Corneliu ZUZU wrote: >> >>> This patch merges almost identical functions hvm_event_int3 and >>> hvm_event_single_step into a single function called hvm_event_breakpo

Re: [Xen-devel] [PATCH v3 1/2] xen/x86: merge 2 hvm_event_... functions into 1

On 2/15/2016 10:30 AM, Razvan Cojocaru wrote: On 02/15/2016 08:35 AM, Corneliu ZUZU wrote: This patch merges almost identical functions hvm_event_int3 and hvm_event_single_step into a single function called hvm_event_breakpoint. Also fixes event.c file header comment in the process. Signed-off-

Re: [Xen-devel] [PATCH] xen-blkback: advertise indirect segment support earlier

On Wed, Feb 10, 2016 at 01:27:08PM +0100, Roger Pau Monné wrote: > El 10/2/16 a les 12:18, Jan Beulich ha escrit: > > There's no reason to defer this until the connect phase, and in fact > > there are frontend implementations expecting this to be available > > earlier. Move it into the probe functi

Re: [Xen-devel] [PATCH] xen-blkfront: rename indirect descriptor parameter

On Wed, Feb 10, 2016 at 01:22:40PM +0100, Roger Pau Monné wrote: > El 10/2/16 a les 12:21, Jan Beulich ha escrit: > > "max" is rather ambiguous and carries pretty little meaning, the more > > that there are also "max_queues" and "max_ring_page_order". Make this > > "max_indirect_segments" instead,

[Xen-devel] [qemu-mainline test] 82574: tolerable FAIL - PUSHED

flight 82574 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/82574/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 79947 test-armhf-armhf-xl-rtds

Re: [Xen-devel] [PATCH v2 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

On Mon, Feb 15, 2016 at 10:06 AM, Jan Beulich wrote: > >>> On 15.02.16 at 17:55, wrote: > > On Mon, Feb 15, 2016 at 9:48 AM, Jan Beulich wrote: > > > >> >>> On 15.02.16 at 17:27, wrote: > >> > On Fri, Feb 12, 2016 at 8:00 AM, Jan Beulich > wrote: > >> > > >> >> >>> On 12.02.16 at 13:57, wrot

Re: [Xen-devel] [PATCH v2 15/30] xen/x86: Improvements to in-hypervisor cpuid sanity checks

On 15/02/16 15:43, Jan Beulich wrote: On 05.02.16 at 14:42, wrote: >> @@ -4617,50 +4618,39 @@ void hvm_cpuid(unsigned int input, unsigned int >> *eax, unsigned int *ebx, >> /* Fix up VLAPIC details. */ >> *ebx &= 0x00FFu; >> *ebx |= (v->vcpu_id * 2) << 24; >> +

Re: [Xen-devel] [PATCH v8 3/5] libxl: add support for vscsi

Wei Liu writes ("Re: [PATCH v8 3/5] libxl: add support for vscsi"): > If it is mandated by hardware that empty scsi controller doesn't > exist, that's of course fine. But I don't think it is mandated in > reality? I can have no disk attached to a controller and that should > be fine. For the avoid

Re: [Xen-devel] [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select

On Mon, 15 Feb 2016, David Vrabel wrote: > On 15/02/16 16:51, Stefano Stabellini wrote: > > CC'ing a few others. > > > > On Fri, 12 Feb 2016, Arnd Bergmann wrote: > >> The Xen framebuffer driver selects the xen keyboard driver, so the latter > >> will be built-in if XEN_FBDEV_FRONTEND=y. However,

Re: [Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01

On Mon, Feb 15, 2016 at 10:45:48AM -0600, Doug Goldstein wrote: > On 2/15/16 10:28 AM, Wei Liu wrote: > > On Sun, Feb 14, 2016 at 07:39:35PM +1100, Steven Haigh wrote: > >> Hi all, > >> > >> Just been looking at the polarssl parts in Xen 4.6 and others - seems > >> like we're hard coded to version

Re: [Xen-devel] RFC: configuring QEMU virtfs for Xen PV(H) guests

On Fri, 12 Feb 2016, Wei Liu wrote: > # Option 3: Only use -fsdev > > The third way of doing it would be to not use QEMU command line to > create device at all. We only use -fsdev to create fsdev and in > xen_init_pv we reply on information in xenstore to create 9pfs > transport. In this case: >

Re: [Xen-devel] [PATCH] tools/libxc: Fix use of zlib-options when building the domain builder

Roger Pau Monné writes ("Re: [PATCH] tools/libxc: Fix use of zlib-options when building the domain builder"): > El 12/2/16 a les 20:21, Andrew Cooper ha escrit: > > c/s de0f8c7c changed the use of zlib-options, and moved it from being > > locally > > generated to coming from ./configure. > > > >

Re: [Xen-devel] [PATCH v2 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

>>> On 15.02.16 at 17:55, wrote: > On Mon, Feb 15, 2016 at 9:48 AM, Jan Beulich wrote: > >> >>> On 15.02.16 at 17:27, wrote: >> > On Fri, Feb 12, 2016 at 8:00 AM, Jan Beulich wrote: >> > >> >> >>> On 12.02.16 at 13:57, wrote: >> >> > On Feb 12, 2016 02:12, "Jan Beulich" wrote: >> >> >> >> >>

Re: [Xen-devel] [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select

On 15/02/16 16:51, Stefano Stabellini wrote: > CC'ing a few others. > > On Fri, 12 Feb 2016, Arnd Bergmann wrote: >> The Xen framebuffer driver selects the xen keyboard driver, so the latter >> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT >> is a loadable module, this confi

Re: [Xen-devel] [PATCH 11/14] xenalyze: handle scheduling events

On Mon, 2016-02-15 at 11:51 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 05, 2016 at 07:35:22PM +0100, Dario Faggioli wrote: > >  > > @@ -7559,6 +7546,14 @@ void sched_summary_domain(struct domain_data > > *d) > >  } > >  } > >   > > +void dump_sched_vcpu_action(struct record_info *ri, con

Re: [Xen-devel] [PATCH 06/14] xen: sched: tracing: enable TSC tracing for all events

On Mon, 2016-02-15 at 11:32 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 05, 2016 at 07:34:18PM +0100, Dario Faggioli wrote: > > it is enabled for pretty much all of them already. > > There were just a few that had it disabled. > > > > When tracing a scheduler, timing information is > > reall

Re: [Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

On 2/15/2016 6:51 PM, Tamas K Lengyel wrote: On Mon, Feb 15, 2016 at 9:44 AM, Jan Beulich > wrote: >>> On 15.02.16 at 17:28, mailto:cz...@bitdefender.com>> wrote: > On 2/15/2016 4:08 PM, Jan Beulich wrote: >> >>> After changing 1 to 1U though, I don't

Re: [Xen-devel] git workflow and http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

>>> On 15.02.16 at 17:10, wrote: > El 15/2/16 a les 17:00, Konrad Rzeszutek Wilk ha escrit: >> Hey, >> >> I wanted to ask what folks would think of expanding the Wiki to include > (making it a diff >> for simpler) this change. With my giant 30 set of patches that not only CC-ed >> xen-devel twic

Re: [Xen-devel] [PATCH v2 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

On Mon, Feb 15, 2016 at 9:48 AM, Jan Beulich wrote: > >>> On 15.02.16 at 17:27, wrote: > > On Fri, Feb 12, 2016 at 8:00 AM, Jan Beulich wrote: > > > >> >>> On 12.02.16 at 13:57, wrote: > >> > On Feb 12, 2016 02:12, "Jan Beulich" wrote: > >> >> > >> >> >>> On 12.02.16 at 01:22, wrote: > >> >>

Re: [Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

On Mon, Feb 15, 2016 at 9:44 AM, Jan Beulich wrote: > >>> On 15.02.16 at 17:28, wrote: > > On 2/15/2016 4:08 PM, Jan Beulich wrote: > >> > >>> After changing 1 to 1U though, I don't understand why we should also > >>> range-check mop->event. > >>> I'm imagining when (mop->event > 31): > >>> * (1

Re: [Xen-devel] [PATCH 11/14] xenalyze: handle scheduling events

On Fri, Feb 05, 2016 at 07:35:22PM +0100, Dario Faggioli wrote: > so the trace will show properly decoded info, > rather than just a bunch of hex codes. > > Signed-off-by: Dario Faggioli > --- > Cc: George Dunlap > Cc: Ian Jackson > Cc: Ian Campbell > Cc: Wei Liu > Cc: Olaf Hering > --- > t

Re: [Xen-devel] [PATCH] xen/x86: Fix errors arising from c/s dab76ff

>>> On 15.02.16 at 16:15, wrote: > What about something like this instead? (Ported to be on top of this > patch, since it's already been committed.) > > -George > > [PATCH] xen/p2m: Make dump table printing less clever > > Rather than detecting whether to print out the numerical value of the

Re: [Xen-devel] [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select

CC'ing a few others. On Fri, 12 Feb 2016, Arnd Bergmann wrote: > The Xen framebuffer driver selects the xen keyboard driver, so the latter > will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT > is a loadable module, this configuration cannot work. On mainline kernels, > the symbo

Re: [Xen-devel] [PATCH v2 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

>>> On 15.02.16 at 17:27, wrote: > On Fri, Feb 12, 2016 at 8:00 AM, Jan Beulich wrote: > >> >>> On 12.02.16 at 13:57, wrote: >> > On Feb 12, 2016 02:12, "Jan Beulich" wrote: >> >> >> >> >>> On 12.02.16 at 01:22, wrote: >> >> > Sending the dr7 register during vm_events is useful for various >>

Re: [Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01

On 2/15/16 10:28 AM, Wei Liu wrote: > On Sun, Feb 14, 2016 at 07:39:35PM +1100, Steven Haigh wrote: >> Hi all, >> >> Just been looking at the polarssl parts in Xen 4.6 and others - seems >> like we're hard coded to version 1.1.4 which was released on 31st May 2012. >> >> Branch 1.1.x has been EOL f

Re: [Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

>>> On 15.02.16 at 17:28, wrote: > On 2/15/2016 4:08 PM, Jan Beulich wrote: >> >>> After changing 1 to 1U though, I don't understand why we should also >>> range-check mop->event. >>> I'm imagining when (mop->event > 31): >>> * (1U << mop->event) = 0 or >= (0x1 + 0x) (?) >> No, it's plain

Re: [Xen-devel] [PATCH 09/14] xentrace: formats: add events from Credit2 scheduler

On Fri, Feb 05, 2016 at 07:34:56PM +0100, Dario Faggioli wrote: > Signed-off-by: Dario Faggioli > --- > Cc: George Dunlap > Cc: Ian Jackson > Cc: Ian Campbell > Cc: Wei Liu > Cc: Olaf Hering > --- > tools/xentrace/formats | 13 + > 1 file changed, 13 insertions(+) > > diff --g

Re: [Xen-devel] [PATCH 07/14] xentrace: formats: update format of scheduling events

On Mon, 2016-02-15 at 11:38 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 05, 2016 at 07:34:30PM +0100, Dario Faggioli wrote: > > to include the vcpu IDs, in a way that matches > > how the "dom:vcpu" couple is displayed in other > > events (runstate changes). > > Could you also add: > "Also ad

Re: [Xen-devel] [PATCH 03/14] xen: sched: fi position of TRC_SCHED_DOM_{ADD, REM}

On Mon, Feb 15, 2016 at 05:37:05PM +0100, Dario Faggioli wrote: > On Mon, 2016-02-15 at 11:22 -0500, Konrad Rzeszutek Wilk wrote: > > On Fri, Feb 05, 2016 at 07:33:50PM +0100, Dario Faggioli wrote: > > > > On the title you have 'fi', but I think you meant 'fix'. > > > Indeed, sorry for that. > >

Re: [Xen-devel] [PATCH 08/14] xentrace: formats: add events from Credit scheduler

On Fri, Feb 05, 2016 at 07:34:43PM +0100, Dario Faggioli wrote: > Signed-off-by: Dario Faggioli Reviewed-by: Konrad Rzeszutek Wilk > --- > Cc: George Dunlap > Cc: Ian Jackson > Cc: Ian Campbell > Cc: Wei Liu > Cc: Olaf Hering > --- > tools/xentrace/formats |7 +++ > 1 file changed,

Re: [Xen-devel] [PATCH 07/14] xentrace: formats: update format of scheduling events

On Fri, Feb 05, 2016 at 07:34:30PM +0100, Dario Faggioli wrote: > to include the vcpu IDs, in a way that matches > how the "dom:vcpu" couple is displayed in other > events (runstate changes). Could you also add: "Also add the trace for TRC_SCHED_SHUTDOWN_CODE which was missing and was done via SCH

Re: [Xen-devel] [PATCH 03/14] xen: sched: fi position of TRC_SCHED_DOM_{ADD, REM}

On Mon, 2016-02-15 at 11:22 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 05, 2016 at 07:33:50PM +0100, Dario Faggioli wrote: > > On the title you have 'fi', but I think you meant 'fix'. > Indeed, sorry for that. > > so that they actually live in the functions that > > do the scheduling rela

Re: [Xen-devel] [Qemu-devel] [PATCH] xen: xen_is_pirq_msi only when xen_enabled()

On Mon, 15 Feb 2016, Markus Armbruster wrote: > Stefano Stabellini writes: > > > Only return true from xen_is_pirq_msi when Xen is enabled: the function > > should never identify an MSI as Xen pirq when not running on Xen. > > Is this supposed to fix ivshmem-test with SPEED=slow? >From the thre

Re: [Xen-devel] [PATCH 06/14] xen: sched: tracing: enable TSC tracing for all events

On Fri, Feb 05, 2016 at 07:34:18PM +0100, Dario Faggioli wrote: > it is enabled for pretty much all of them already. > There were just a few that had it disabled. > > When tracing a scheduler, timing information is > really important, so enable it everywhere scheduling > related. > > Note that th

Re: [Xen-devel] [PATCH 05/14] xen: RTDS: pack trace data better for xentrace_format

On Fri, Feb 05, 2016 at 07:34:05PM +0100, Dario Faggioli wrote: > when tracing runstate changes, the vcpu and domain IDs > are encoded in the lower and higher, respectively, parts > of a 32 bits integer. When decoding a trace with > xentrace_format, this makes it possible to display > such events l

Re: [Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

On 2/15/2016 4:08 PM, Jan Beulich wrote: After changing 1 to 1U though, I don't understand why we should also range-check mop->event. I'm imagining when (mop->event > 31): * (1U << mop->event) = 0 or >= (0x1 + 0x) (?) No, it's plain undefined. Weirdo C, didn't know that! I've just re

Re: [Xen-devel] [PATCH 04/14] xen: credit2: pack trace data better for xentrace_format

On Fri, Feb 05, 2016 at 07:33:57PM +0100, Dario Faggioli wrote: > when tracing runstate changes, the vcpu and domain IDs > are encoded in the lower and higher, respectively, parts > of a 32 bits integer. When decoding a trace with > xentrace_format, this makes it possible to display > such events l

Re: [Xen-devel] [PATCH 01/14] xen: sched: __runq_tickle takes a useless cpu parameter

On Mon, 2016-02-15 at 11:14 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 05, 2016 at 07:33:34PM +0100, Dario Faggioli wrote: > > as it is always acts on v->processor of the vcpu because > > of which we are tickling. > > s/because of which// ? > Yeah, well, technically, as tickling means "rai

Re: [Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01

On Sun, Feb 14, 2016 at 07:39:35PM +1100, Steven Haigh wrote: > Hi all, > > Just been looking at the polarssl parts in Xen 4.6 and others - seems > like we're hard coded to version 1.1.4 which was released on 31st May 2012. > > Branch 1.1.x has been EOL for a number of years, 1.2.x has been EOL >

Re: [Xen-devel] [PATCH v2 12/30] xen/x86: Generate deep dependencies of features

>>> On 15.02.16 at 17:09, wrote: > On 15/02/16 15:52, Jan Beulich wrote: >> > --- a/xen/tools/gen-cpuid.py > +++ b/xen/tools/gen-cpuid.py > @@ -138,6 +138,61 @@ def crunch_numbers(state): > state.hvm_shadow = featureset_to_uint32s(state.raw_hvm_shadow, >>> nr_entries) >

Re: [Xen-devel] [PATCH v2 1/2] hvm/vmx: save dr7 during vmx_vmcs_save

On Fri, Feb 12, 2016 at 8:00 AM, Jan Beulich wrote: > >>> On 12.02.16 at 13:57, wrote: > > On Feb 12, 2016 02:12, "Jan Beulich" wrote: > >> > >> >>> On 12.02.16 at 01:22, wrote: > >> > Sending the dr7 register during vm_events is useful for various > > applications, > >> > but the current way

Re: [Xen-devel] [PATCH 03/14] xen: sched: fi position of TRC_SCHED_DOM_{ADD, REM}

On Fri, Feb 05, 2016 at 07:33:50PM +0100, Dario Faggioli wrote: On the title you have 'fi', but I think you meant 'fix'. > so that they actually live in the functions that > do the scheduling related domain initialization and > destruction. > > Signed-off-by: Dario Faggioli .. would it make se

Re: [Xen-devel] git workflow and http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

On Mon, Feb 15, 2016 at 11:00:58AM -0500, Konrad Rzeszutek Wilk wrote: > Hey, > > I wanted to ask what folks would think of expanding the Wiki to include > (making it a diff > for simpler) this change. With my giant 30 set of patches that not only CC-ed > xen-devel twice but had some patches CC s

Re: [Xen-devel] [PATCH v2 2/2] vm_event: consolidate hvm_event_fill_regs and p2m_vm_event_fill_regs

On Fri, Feb 12, 2016 at 7:57 AM, Jan Beulich wrote: > >>> On 12.02.16 at 13:50, wrote: > > On Feb 12, 2016 03:41, "Jan Beulich" wrote: > >> In which case ASSERT(is_hvm_vcpu(curr)) would be the common > >> way to document this (at once avoiding the open coding of > >> is_hvm_vcpu()). > >> > > >

Re: [Xen-devel] [PATCH 02/14] xen: sched: move up the trace record for vcpu_wake and vcpu_sleep

On Fri, Feb 05, 2016 at 07:33:42PM +0100, Dario Faggioli wrote: > vcpu_wake() and vcpu_sleep() are called before the specific > schedulers wakeup and sleep routines (in fact, it is them > that calls those specific routine). Yeah!! > > Make the trace reflect that, by moving the records up. In > f

Re: [Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

On Mon, Feb 15, 2016 at 7:08 AM, Jan Beulich wrote: > >>> On 15.02.16 at 14:29, wrote: > > On 2/15/2016 2:44 PM, Jan Beulich wrote: > >> > >>> switch ( mop->op ) > >>> { > >>> case XEN_DOMCTL_MONITOR_OP_ENABLE: > >>> case XEN_DOMCTL_MONITOR_OP_DISABLE: > >>> /*

Re: [Xen-devel] [PATCH 01/14] xen: sched: __runq_tickle takes a useless cpu parameter

On Fri, Feb 05, 2016 at 07:33:34PM +0100, Dario Faggioli wrote: > as it is always acts on v->processor of the vcpu because > of which we are tickling. s/because of which// ? > > Getting rid of it makes the code easier to understand > and better looking. > > While there, remove a spurious blank

Re: [Xen-devel] [PATCH] Config.mk: Update SEABIOS_UPSTREAM_TAG to rel-1.9.1

On Mon, Feb 15, 2016 at 08:38:02AM -0600, Doug Goldstein wrote: > Switch from tracking a commit post 1.9.0 to the 1.9.1 release. > Thanks for this patch. We can't apply this patch just yet. We need to wait a bit until the change to upstream trickles down to our own tree [0] -- OSSTest will work o

Re: [Xen-devel] git workflow and http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

El 15/2/16 a les 17:00, Konrad Rzeszutek Wilk ha escrit: > Hey, > > I wanted to ask what folks would think of expanding the Wiki to include > (making it a diff > for simpler) this change. With my giant 30 set of patches that not only CC-ed > xen-devel twice but had some patches CC some maintainer

Re: [Xen-devel] [PATCH v2 12/30] xen/x86: Generate deep dependencies of features

On 15/02/16 15:52, Jan Beulich wrote: > --- a/xen/tools/gen-cpuid.py +++ b/xen/tools/gen-cpuid.py @@ -138,6 +138,61 @@ def crunch_numbers(state): state.hvm_shadow = featureset_to_uint32s(state.raw_hvm_shadow, >> nr_entries) state.hvm_hap = featureset_to_uint32s(s

[Xen-devel] [xen-unstable-smoke test] 82684: tolerable all pass - PUSHED

flight 82684 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/82684/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

Re: [Xen-devel] git workflow and http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

On 15/02/16 16:00, Konrad Rzeszutek Wilk wrote: > Hey, > > I wanted to ask what folks would think of expanding the Wiki to include > (making it a diff > for simpler) this change. With my giant 30 set of patches that not only CC-ed > xen-devel twice but had some patches CC some maintainers but not

[Xen-devel] git workflow and http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

Hey, I wanted to ask what folks would think of expanding the Wiki to include (making it a diff for simpler) this change. With my giant 30 set of patches that not only CC-ed xen-devel twice but had some patches CC some maintainers but not others - I figured it may be good to describe this in the

Re: [Xen-devel] [PATCH v2 12/30] xen/x86: Generate deep dependencies of features

>>> On 15.02.16 at 16:28, wrote: > On 15/02/16 14:06, Jan Beulich wrote: > On 05.02.16 at 14:42, wrote: >>> @@ -20,12 +21,34 @@ uint32_t __read_mostly hvm_featureset[FSCAPINTS]; >>> >>> static void sanitise_featureset(uint32_t *fs) >>> { >>> +uint32_t disabled_features[FSCAPINTS]; >>>

Re: [Xen-devel] [PATCH v2 11/30] xen/x86: Calculate maximum host and guest featuresets

On 15/02/16 15:07, Jan Beulich wrote: > +uint32_t __read_mostly raw_featureset[FSCAPINTS]; +uint32_t __read_mostly host_featureset[FSCAPINTS]; +uint32_t __read_mostly pv_featureset[FSCAPINTS]; +uint32_t __read_mostly hvm_featureset[FSCAPINTS]; + +static void sanitise_f

Re: [Xen-devel] [PATCH v8 3/5] libxl: add support for vscsi

On Mon, Feb 15, 2016 at 04:24:38PM +0100, Olaf Hering wrote: > On Mon, Feb 15, Wei Liu wrote: > > > > I think yes, DEFINE_DEVICES_ADD has to be used somewhere. > > I'm confused. You're joking, right? "Has to be used somewhere" is not > > a justification for having it in this particular place. > >

Re: [Xen-devel] [PATCH v2 15/30] xen/x86: Improvements to in-hypervisor cpuid sanity checks

>>> On 05.02.16 at 14:42, wrote: > @@ -4617,50 +4618,39 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, > unsigned int *ebx, > /* Fix up VLAPIC details. */ > *ebx &= 0x00FFu; > *ebx |= (v->vcpu_id * 2) << 24; > + > +*ecx &= hvm_featureset[FEATURESET

Re: [Xen-devel] [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

On 15/02/16 15:02, Jan Beulich wrote: On 15.02.16 at 15:53, wrote: >> On 15/02/16 14:50, Jan Beulich wrote: >> On 15.02.16 at 15:38, wrote: On 15/02/16 09:20, Jan Beulich wrote: On 12.02.16 at 18:42, wrote: >> On 12/02/16 17:05, Jan Beulich wrote: >> On 05.02.1

Re: [Xen-devel] [PATCH] Fixes to Xen pcifront and pciback (v1)

On Mon, Feb 15, 2016 at 02:38:22PM +, David Vrabel wrote: > On 15/02/16 14:35, David Vrabel wrote: > > On 11/02/16 21:10, Konrad Rzeszutek Wilk wrote: > >> Hey, > >> > >> These are patches that were developed for the Debian bug > >> 810379 which san Tommi had openned. > >> > >> The issue around

Re: [Xen-devel] [PATCH v2 13/30] xen/x86: Clear dependent features when clearing a cpu cap

On 15/02/16 14:53, Jan Beulich wrote: On 05.02.16 at 14:42, wrote: >> --- a/xen/arch/x86/cpu/common.c >> +++ b/xen/arch/x86/cpu/common.c >> @@ -53,8 +53,24 @@ static unsigned int cleared_caps[NCAPINTS]; >> >> void __init setup_clear_cpu_cap(unsigned int cap) >> { >> +const uint32_t *d

Re: [Xen-devel] [PATCH v2 12/30] xen/x86: Generate deep dependencies of features

On 15/02/16 14:06, Jan Beulich wrote: On 05.02.16 at 14:42, wrote: >> @@ -20,12 +21,34 @@ uint32_t __read_mostly hvm_featureset[FSCAPINTS]; >> >> static void sanitise_featureset(uint32_t *fs) >> { >> +uint32_t disabled_features[FSCAPINTS]; >> unsigned int i; >> >> for ( i

Re: [Xen-devel] [PATCH v8 3/5] libxl: add support for vscsi

On Mon, Feb 15, Wei Liu wrote: > > I think yes, DEFINE_DEVICES_ADD has to be used somewhere. > I'm confused. You're joking, right? "Has to be used somewhere" is not > a justification for having it in this particular place. What would be the appropriate place? I think its there since I started wor

Re: [Xen-devel] [PATCH] tools/libxc: Fix use of zlib-options when building the domain builder

El 12/2/16 a les 20:21, Andrew Cooper ha escrit: > c/s de0f8c7c changed the use of zlib-options, and moved it from being locally > generated to coming from ./configure. > > However, it neglected to modify the users of zlib-options. The curious use of > $(call ...) was to select either the -D or -

Re: [Xen-devel] [PATCH v8 3/5] libxl: add support for vscsi

On Fri, Feb 12, 2016 at 07:24:59PM +0100, Olaf Hering wrote: [...] > > > > +if (libxl__xs_directory(gc, XBT_NULL, be_path, &be_dirs)) { > > > +rc = libxl__device_vscsi_reconfigure_add(egc, aodev, > > > &vscsi_saved, &d_config, be_path); > > > +if (rc) > > > +goto o

Re: [Xen-devel] [PATCH] xen/x86: Fix errors arising from c/s dab76ff

On 12/02/16 14:59, Andrew Cooper wrote: > Coverity correctly identifies that the changes in mtrr_attrib_to_str() > introduce dead code. strings[] is a 2d array, rather than an array of > strings, which means that strings[x] will never be a NULL pointer. > > Adjust the check to compenstate, by loo

Re: [Xen-devel] [PATCH v2 11/30] xen/x86: Calculate maximum host and guest featuresets

>>> On 15.02.16 at 15:57, wrote: > On 15/02/16 13:37, Jan Beulich wrote: > On 05.02.16 at 14:42, wrote: >>> --- a/xen/arch/x86/cpuid.c >>> +++ b/xen/arch/x86/cpuid.c >>> @@ -1,13 +1,165 @@ >>> #include >>> #include >>> +#include >>> +#include >>> +#include >>> + >>> +#define COMMON_1D

Re: [Xen-devel] [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

>>> On 15.02.16 at 15:53, wrote: > On 15/02/16 14:50, Jan Beulich wrote: > On 15.02.16 at 15:38, wrote: >>> On 15/02/16 09:20, Jan Beulich wrote: >>> On 12.02.16 at 18:42, wrote: > On 12/02/16 17:05, Jan Beulich wrote: > On 05.02.16 at 14:42, wrote: >>> #define X86_FEAT

Re: [Xen-devel] Two linkers - EFI one (mingw64) and normal GNU one [Fedora]

On 2/15/16 8:26 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 15, 2016 at 02:32:45AM -0700, Jan Beulich wrote: > On 12.02.16 at 18:19, wrote: >>> Fedora for the longest time seems to have two linkers - one normal for GNU >>> applications and then another - mingw64 - for building EFI applicati

Re: [Xen-devel] [PATCH v2 11/30] xen/x86: Calculate maximum host and guest featuresets

On 15/02/16 13:37, Jan Beulich wrote: On 05.02.16 at 14:42, wrote: >> --- a/xen/arch/x86/cpuid.c >> +++ b/xen/arch/x86/cpuid.c >> @@ -1,13 +1,165 @@ >> #include >> #include >> +#include >> +#include >> +#include >> + >> +#define COMMON_1D INIT_COMMON_FEATURES >> >> const uint32_t kn

Re: [Xen-devel] [PATCH v2 13/30] xen/x86: Clear dependent features when clearing a cpu cap

>>> On 05.02.16 at 14:42, wrote: > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -53,8 +53,24 @@ static unsigned int cleared_caps[NCAPINTS]; > > void __init setup_clear_cpu_cap(unsigned int cap) > { > + const uint32_t *dfs; > + unsigned int i; > + > + if (

Re: [Xen-devel] [PATCH v2 13/30] xen/x86: Clear dependent features when clearing a cpu cap

>>> On 05.02.16 at 14:42, wrote: > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -53,8 +53,24 @@ static unsigned int cleared_caps[NCAPINTS]; > > void __init setup_clear_cpu_cap(unsigned int cap) > { > + const uint32_t *dfs; > + unsigned int i; > + > + if (

Re: [Xen-devel] [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

On 15/02/16 14:50, Jan Beulich wrote: On 15.02.16 at 15:38, wrote: >> On 15/02/16 09:20, Jan Beulich wrote: >> On 12.02.16 at 18:42, wrote: On 12/02/16 17:05, Jan Beulich wrote: On 05.02.16 at 14:42, wrote: >> #define X86_FEATURE_MWAITX( 3*32+29) /* MWAIT ex

Re: [Xen-devel] [PATCH v2 10/30] xen/x86: Annotate VM applicability in featureset

>>> On 15.02.16 at 15:38, wrote: > On 15/02/16 09:20, Jan Beulich wrote: > On 12.02.16 at 18:42, wrote: >>> On 12/02/16 17:05, Jan Beulich wrote: >>> On 05.02.16 at 14:42, wrote: > #define X86_FEATURE_MWAITX( 3*32+29) /* MWAIT extension >>> (MONITORX/MWAITX) */ Why n

Re: [Xen-devel] [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.

On 02/15/2016 09:05 AM, Konrad Rzeszutek Wilk wrote: On Sat, Feb 13, 2016 at 08:23:14PM -0500, Boris Ostrovsky wrote: On 02/11/2016 04:10 PM, Konrad Rzeszutek Wilk wrote: This patch fixes the issue by: 1) Use kzalloc to initialize to a well known state. 2) Put 'struct pci_sysdata' at the st

  1   2   >