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

[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.

[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

[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

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

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

[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

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 ; >

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

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 > ;

[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

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

[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

[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

[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

[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

[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

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

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 =

[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

[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

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

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

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 > >

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

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.

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

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,

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 |=

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

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

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

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,

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 > >

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, > wrote: > On 2/15/2016 4:08 PM, Jan Beulich wrote: >>

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

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

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

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

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

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

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,

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

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 +

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

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

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

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

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

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

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

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

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: [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

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

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 =

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

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

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

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

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 >

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

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

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

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 =

[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) >>>

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

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

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,

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

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) >>

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

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

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, _dirs)) { > > > +rc = libxl__device_vscsi_reconfigure_add(egc, aodev, > > > _saved, _config, be_path); > > > +if (rc) > > > +goto out; > > >

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

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 >>>

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,

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 -

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

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; > +

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; > +

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,

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

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

  1   2   >