Re: [Xen-devel] [PATCH V7 1/3] x86/xsaves: fix overwriting between non-lazy/lazy xsaves

>>> On 05.04.16 at 07:30, wrote: > On Mon, Apr 04, 2016 at 09:51:56AM -0600, Jan Beulich wrote: >> Btw, I think this shouldn't be a #define, as it can - afaict - be derived >> from CPUID output. > Ok. >>But this can easily be a follow-up patch, even one >> that doesn't make it into 4.7. > I do no

Re: [Xen-devel] [PATCH V7 1/3] x86/xsaves: fix overwriting between non-lazy/lazy xsaves

On Tue, Apr 05, 2016 at 01:17:34AM -0600, Jan Beulich wrote: > >>> On 05.04.16 at 07:30, wrote: > > On Mon, Apr 04, 2016 at 09:51:56AM -0600, Jan Beulich wrote: > > Do you mean the follow-up patch ( XSTATE_XSAVES_ONLY derived from cpuid) > > will not into 4.7 ? > > You're aware that we're past th

Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading

>>> On 04.04.16 at 21:44, wrote: > On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote: >> >>> On 31.03.16 at 23:26, wrote: >> >> Also - how well will this O(n^2) lookup work once there are enough >> >> payloads? I think this calls for the alternative vmap() extension I've >> >> been sug

Re: [Xen-devel] [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.

>>> On 04.04.16 at 22:01, wrote: > On Mon, Apr 04, 2016 at 09:00:00AM -0600, Jan Beulich wrote: >> >>> On 24.03.16 at 21:00, wrote: >> > @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to >> > match against. >> > The old code allows much more flexibility and an additional

Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS

>>> On 05.04.16 at 03:07, wrote: > Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced > a bug: it made it possible, in Credit and Credit2, when doing domain > or vcpu parameters' manipulation, to leave the hypervisor with a > spinlock held and interrupts disabled. > > Fix it. >

Re: [Xen-devel] XSM permissive by default.

>>> On 04.04.16 at 19:12, wrote: > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] XSM permissive by default."): >> I presume this patch would be to folks +1: >> >> From 3373a50f386b41eea6ecede4b430e4fa09b2fe7e Mon Sep 17 00:00:00 2001 >> From: Konrad Rzeszutek Wilk >> Date: Thu, 10 Mar 2016 12:0

Re: [Xen-devel] [PATCH v3 0/5] xentrace/xenalyze Support on ARM

>>> On 04.04.16 at 20:48, wrote: > This patch set adds support for xentrace/xenalyze to the ARM platform. > > The Xen heap memory mapping, timestamping, and P2M translation needed > by xentrace is corrected for operation on the ARM platform using the > x86 platform as reference. Trace buffer init

Re: [Xen-devel] [PATCH v4 3/6] smp: add function to execute a function synchronously on a cpu

On Tue, Apr 05, 2016 at 07:10:04AM +0200, Juergen Gross wrote: > +int smp_call_on_cpu(unsigned int cpu, bool pin, int (*func)(void *), void > *par) Why .pin and not .phys? .pin does not (to me) reflect the hypervisor/physical-cpu thing. Also, as per smp_call_function_single() would it not be mor

Re: [Xen-devel] [PATCH v3 1/5] xentrace: Common Support for get_pg_owner/put_pg_owner on ARM and x86

>>> On 04.04.16 at 20:48, wrote: > +void put_pg_owner(struct domain *pg_owner) > +{ > +rcu_unlock_domain(pg_owner); > +} I cannot see why this then can't just become an inline function. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http:

Re: [Xen-devel] [PATCH] x86/pvh: Initialize ioreq server for PVH guests

>>> On 04.04.16 at 23:05, wrote: > ioreq server list needs to be initialized for PVH guests. This list is > walked in handle_hvm_io_completion() by all guests in HVM containers and > leaving it uninitialized may cause PVH guests to crash there. > > Signed-off-by: Boris Ostrovsky Reviewed-by: Ja

Re: [Xen-devel] [PATCH V7 3/3] x86/xsaves: ebx may return wrong value using CPUID eax=0xdh, ecx =1

>>> On 31.03.16 at 10:57, wrote: > Refer to SDM 13.4.3 Extended Region of an XSAVE Area. The value return No section numbers please - they tend to change. > by ecx[1] with cpuid function 0xdh and sub-fucntion i (i>1) indicates Either "0xd" or "0dh". And "function". > --- a/xen/arch/x86/traps.c

Re: [Xen-devel] [PATCH v9 1/3] VT-d: add a command line parameter for Queued Invalidation

>>> On 01.04.16 at 16:47, wrote: The subject should mention "timeout", perhaps either in addition to or in place of "command line". > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -1532,6 +1532,24 @@ Note that if **watchdog** option is also specified

Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS

On 05/04/16 00:14, Andrew Cooper wrote: > On 04/04/2016 23:45, Chong Li wrote: >> From: Chong-Li >> >> Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced >> a bug: it made it possible, in Credit and Credit2, when doing domain >> or vcpu parameters' manipulation, to leave the hy

Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS

On 05/04/16 08:57, Jan Beulich wrote: On 05.04.16 at 03:07, wrote: >> Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced >> a bug: it made it possible, in Credit and Credit2, when doing domain >> or vcpu parameters' manipulation, to leave the hypervisor with a >> spinlock h

Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code

On Mon, Apr 4, 2016 at 6:16 PM, Andrew Cooper wrote: > On 04/04/16 18:11, Andrew Cooper wrote: >> On 04/04/16 17:59, Ian Jackson wrote: >>> George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream >>> disk argument code"): I looked through the patch in the branch provided in

Re: [Xen-devel] [PATCH v4 1/6] xen: sync xen header

On 05/04/16 06:10, Juergen Gross wrote: > Import the actual version of include/xen/interface/sched.h from Xen. Acked-by: David Vrabel David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/HVM: remove dead code

On 04/04/16 07:28, Jan Beulich wrote: > With commit 96ae556569 ("x86/HVM: fix forwarding of internally cached > requests") rc doesn't change anymore in the respective preceding > switch() statements. > > Coverity ID: 1358080 > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper __

Re: [Xen-devel] [PATCH v9 2/3] VT-d: wrap a _sync version for all VT-d flush interfaces

>>> On 01.04.16 at 16:47, wrote: > The dev_invalidate_iotlb() scans ats_devices list to flush ATS devices, > and the invalidate_sync() is put after dev_invalidate_iotlb() to > synchronize with hardware for flush status. If we assign multiple > ATS devices to a domain, the flush status is about all

Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS

On Tue, 2016-04-05 at 10:18 +0100, George Dunlap wrote: > On 05/04/16 00:14, Andrew Cooper wrote: > > On 04/04/2016 23:45, Chong Li wrote: > > > --- > > >  xen/common/sched_credit.c  | 1 + > > >  xen/common/sched_credit2.c | 1 + > > >  2 files changed, 2 insertions(+) > > > > > > diff --git a/xen/

Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS

On Tue, 2016-04-05 at 10:25 +0100, George Dunlap wrote: > On 05/04/16 08:57, Jan Beulich wrote: > >  > > > Signed-off-by: Chong Li > > > > > > Acked-by: Dario Faggioli > > This appears to be the 3rd variant of the patch, all with the same > > bogus subject, and no versioning information at all.

Re: [Xen-devel] [PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu

On 05/04/16 06:10, Juergen Gross wrote: > Some hardware models (e.g. Dell Studio 1555 laptops) require calls to > the firmware to be issued on cpu 0 only. As Dom0 might have to use > these calls, add xen_pin_vcpu() to achieve this functionality. > > In case either the domain doesn't have the privi

Re: [Xen-devel] [PATCH v9 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue

>>> On 01.04.16 at 16:47, wrote: > If Device-TLB flush timed out, we would hide the target ATS Please re-consider the use of the word "would" in all your patch descriptions. > --- a/xen/drivers/passthrough/vtd/qinval.c > +++ b/xen/drivers/passthrough/vtd/qinval.c > @@ -217,6 +217,58 @@ static in

Re: [Xen-devel] [PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu

On 05/04/16 11:45, David Vrabel wrote: > On 05/04/16 06:10, Juergen Gross wrote: >> Some hardware models (e.g. Dell Studio 1555 laptops) require calls to >> the firmware to be issued on cpu 0 only. As Dom0 might have to use >> these calls, add xen_pin_vcpu() to achieve this functionality. >> >> In

Re: [Xen-devel] [PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu

On 05/04/16 11:01, Juergen Gross wrote: > > No, I don't think this is a good idea. In the EINVAL or EBUSY case a > simple Xen admin command might be enough to make the next call succeed. > I don't want to disable pinning in this case. Ok. Acked-by: David Vrabel David _

Re: [Xen-devel] [PATCH v4 3/6] smp: add function to execute a function synchronously on a cpu

On 05/04/16 10:11, Peter Zijlstra wrote: > On Tue, Apr 05, 2016 at 07:10:04AM +0200, Juergen Gross wrote: >> +int smp_call_on_cpu(unsigned int cpu, bool pin, int (*func)(void *), void >> *par) > > Why .pin and not .phys? .pin does not (to me) reflect the > hypervisor/physical-cpu thing. I don't

Re: [Xen-devel] [PATCH v2 2/6] x86/time: refactor init_platform_time()

>>> On 29.03.16 at 15:44, wrote: > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -533,6 +533,30 @@ static void resume_platform_timer(void) > plt_stamp = plt_src.read_counter(); > } > > +static int __init try_platform_timer(struct platform_timesource *pts) > +{ > +int rc =

Re: [Xen-devel] [PATCH v2 1/6] public/xen.h: add flags field to vcpu_time_info

>>> On 29.03.16 at 15:44, wrote: > --- a/xen/include/public/xen.h > +++ b/xen/include/public/xen.h > @@ -614,10 +614,14 @@ struct vcpu_time_info { > */ > uint32_t tsc_to_system_mul; > int8_t tsc_shift; > -int8_t pad1[3]; > +uint8_t flags; > +uint8_t pad1[2]; > };

[Xen-devel] Policy for force pushing smoke branch Was: Re: [xen-unstable-smoke test] 88656: regressions - FAIL [and 1 more messages] [and 1 more messages]

Ian Jackson writes ("Policy for force pushing smoke branch Was: Re: [Xen-devel] [xen-unstable-smoke test] 88656: regressions - FAIL [and 1 more messages]"): > I'll do a force push to xen.git#master if this is the only blocker, > too. Also, any necessary force push of the osstest tested libvirt >

Re: [Xen-devel] Policy for force pushing smoke branch Was: Re: [xen-unstable-smoke test] 88656: regressions - FAIL [and 1 more messages] [and 1 more messages]

On Tue, Apr 05, 2016 at 11:31:29AM +0100, Ian Jackson wrote: > Ian Jackson writes ("Policy for force pushing smoke branch Was: Re: > [Xen-devel] [xen-unstable-smoke test] 88656: regressions - FAIL [and 1 more > messages]"): > > I'll do a force push to xen.git#master if this is the only blocker, >

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

>>> On 29.03.16 at 15:44, wrote: > Introduce support for using TSC as platform time which is the highest > resolution time and most performant to get (~20 nsecs). Though there > are also several problems associated with its usage, and there isn't a > complete (and architecturally defined) guarant

Re: [Xen-devel] [PATCH v2 2/6] x86/time: refactor init_platform_time()

On 04/05/2016 11:09 AM, Jan Beulich wrote: On 29.03.16 at 15:44, wrote: >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -533,6 +533,30 @@ static void resume_platform_timer(void) >> plt_stamp = plt_src.read_counter(); >> } >> >> +static int __init try_platform_timer(str

[Xen-devel] Issues with the xen-access.c model

Hello, xen-access.c does roughly this: for (;;) { poll_evt_channel(); if (new_events) { while (ring_buffer_has_requests) { pull_request(); process_request(); put_response(); }

Re: [Xen-devel] [PATCH v2 1/6] public/xen.h: add flags field to vcpu_time_info

On 04/05/2016 11:16 AM, Jan Beulich wrote: On 29.03.16 at 15:44, wrote: >> --- a/xen/include/public/xen.h >> +++ b/xen/include/public/xen.h >> @@ -614,10 +614,14 @@ struct vcpu_time_info { >> */ >> uint32_t tsc_to_system_mul; >> int8_t tsc_shift; >> -int8_t pad1[3];

Re: [Xen-devel] [PATCH v2 2/6] x86/time: refactor init_platform_time()

>>> On 05.04.16 at 12:55, wrote: > On 04/05/2016 11:09 AM, Jan Beulich wrote: > On 29.03.16 at 15:44, wrote: >>> +if ( rc <= 0 ) >>> +return rc; >>> + >>> +plt_mask = (u64)~0ull >> (64 - pts->counter_bits); >>> + >>> +set_time_scale(&plt_scale, pts->frequency); >>> + >>> +

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

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

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

flight 88716 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/88716/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-amd64-xl-qemuu-ov

[Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

Hi libvirt maintainers, Xen's control library libxenlight (libxl) requires application (libvirt in this case) to explictily define LIBXL_API_VERSION. This is lacking at the moment so libvirt's libxl driver always gets the latest APIs. We changed one of the APIs in libxl so libvirt's libxl driver c

Re: [Xen-devel] [PATCH v2 4/6] x86/time: streamline platform time init on plt_init()

>>> On 29.03.16 at 15:44, wrote: > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -434,6 +434,7 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns) > / > * PLATFORM TIMER 4: TSC > */ > +static bool_t clocksource_is_tsc; __read_m

Re: [Xen-devel] [PATCH v2 5/6] x86/time: refactor read_platform_stime()

>>> On 29.03.16 at 15:44, wrote: > -static s_time_t read_platform_stime(void) > +static s_time_t read_platform_stime(u64 *stamp) > { > -u64 count; > +u64 plt_stamp_counter, count; "stamp" and "counter" seem kind of redundant. > s_time_t stime; > > ASSERT(!local_irq_is_enable

Re: [Xen-devel] Issues with the xen-access.c model

On 05/04/16 11:55, Razvan Cojocaru wrote: > Hello, > > xen-access.c does roughly this: > > for (;;) { > poll_evt_channel(); > > if (new_events) { > while (ring_buffer_has_requests) { > pull_request(); > process_request(); >

Re: [Xen-devel] [PATCH v2 6/6] x86/time: implement PVCLOCK_TSC_STABLE_BIT

>>> On 29.03.16 at 15:44, wrote: > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -43,6 +43,10 @@ > static char __initdata opt_clocksource[10]; > string_param("clocksource", opt_clocksource); > > +/* opt_nocpuhotplug: Set if CPU hotplug isn't meant to be used */ > +static bool_t __

Re: [Xen-devel] [PATCH v4 07/14] hvmloader: Grab the hvm_start_info pointer

>>> On 14.03.16 at 18:55, wrote: > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: enable per-VCPU parameter for RTDS

On Mon, Apr 04, 2016 at 08:07:13PM -0500, Chong Li wrote: > Commit f7b87b0745b4 ("enable per-VCPU parameter for RTDS") introduced > a bug: it made it possible, in Credit and Credit2, when doing domain > or vcpu parameters' manipulation, to leave the hypervisor with a > spinlock held and interrupts

Re: [Xen-devel] [PATCH v4 08/14] hvmloader: Locate the BIOS blob

>>> On 14.03.16 at 18:55, wrote: > --- a/tools/firmware/hvmloader/hvmloader.c > +++ b/tools/firmware/hvmloader/hvmloader.c > @@ -253,10 +253,40 @@ static void acpi_enable_sci(void) > BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN)); > } > > +const struct hvm_modlist_entry *get_module_entry( > +

Re: [Xen-devel] [PATCH v4 09/14] hvmloader: Check modules whereabouts in perform_tests

>>> On 14.03.16 at 18:55, wrote: > As perform_tests() is going to clear memory past 4MB, we check that the > memory can be use or we skip the tests. > > Signed-off-by: Anthony PERARD > --- > Changes in v4: > - move the check into the perform_test() function. > - skip tests instead of using BUG.

Re: [Xen-devel] [PATCH v4 10/14] hvmloader: Load SeaBIOS from hvm_start_info modules

>>> On 14.03.16 at 18:55, wrote: > ... and do not include the SeaBIOS ROM into hvmloader anymore. > > This also fix the dependency on roms.inc, hvmloader.o does not include it. > > Signed-off-by: Anthony PERARD > --- > Change in V4: > - check that seabios_config.bios_address have a probably goo

Re: [Xen-devel] [PATCH v4 11/14] hvmloader: Load OVMF from modules

>>> On 14.03.16 at 18:55, wrote: > ... and do not include the OVMF ROM into hvmloader anymore. > > Signed-off-by: Anthony PERARD Acked-by: Jan Beulich with some cosmetics left to be done: > /* Copy low-reset vector portion. */ > -memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->im

[Xen-devel] [PATCH v4] xen/arm64: check XSM Magic from the second unknown module.

From: Fu Wei This patch adds a has_xsm_magic helper function for detecting XSM from the second unknown module. If Xen can't get the kind of module from compatible, we guess the kind of these unknowns respectively: (1) The first unknown must be kernel. (2) Detect the XSM Magic from the 2n

Re: [Xen-devel] [PATCH v3] xen/arm64: check XSM Magic and Signature from the second unknown module.

Hi Julien, I have taken all you suggestions and posted the v4 patch, please review it. Great thanks for your help !! On 2 April 2016 at 02:10, Julien Grall wrote: > (Use Stefano's new e-mail address) > Hi Fu Wei, > > On 29/03/16 04:26, fu@linaro.org wrote: >> >> From: Fu Wei >> >> This patc

Re: [Xen-devel] [PATCH] kernel-parameters: document earlycon=xenboot

On Mon, Apr 04, 2016 at 10:48:11PM -0400, Chris Patterson wrote: > Add earlycon=xenboot option to Documentation/kernel-parameters.txt. > But it is not true. I tried this on x86: "earlycon=xenboot console=tty0" And nothing from Linux came during earlyboot to the Xen console? > Signed-off-by: Ch

Re: [Xen-devel] [PATCH v2 1/3] x86/ioreq server: Add new functions to get/set memory types.

On Thu, Mar 31, 2016 at 11:53 AM, Yu Zhang wrote: > For clarity this patch breaks the code to set/get memory types out > of do_hvm_op() into dedicated functions: hvmop_set/get_mem_type(). > Also, for clarity, checks for whether a memory type change is allowed > are broken out into a separate funct

[Xen-devel] [xen-unstable-smoke test] 88802: tolerable FAIL - PUSHED

flight 88802 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/88802/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-buildfail like 88699 Tests which did not suc

Re: [Xen-devel] [PATCH v4 08/14] hvmloader: Locate the BIOS blob

On Tue, 5 Apr 2016, Jan Beulich wrote: > >>> On 14.03.16 at 18:55, wrote: > > --- a/tools/firmware/hvmloader/hvmloader.c > > +++ b/tools/firmware/hvmloader/hvmloader.c > > @@ -253,10 +253,40 @@ static void acpi_enable_sci(void) > > BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN)); > > } > > > >

Re: [Xen-devel] [PATCH v4] xen/arm64: check XSM Magic from the second unknown module.

>>> On 05.04.16 at 15:38, wrote: > --- a/xen/xsm/xsm_core.c > +++ b/xen/xsm/xsm_core.c > @@ -19,6 +19,8 @@ > > #ifdef CONFIG_XSM > > +#include This is not a good idea. Note how xsm_policy.c limits this inclusion to the CONFIG_HAS_DEVICE_TREE case only, which is the least that should be done

Re: [Xen-devel] [PATCH v4 08/14] hvmloader: Locate the BIOS blob

>>> On 05.04.16 at 16:05, wrote: > On Tue, 5 Apr 2016, Jan Beulich wrote: >> >>> On 14.03.16 at 18:55, wrote: >> > --- a/tools/firmware/hvmloader/hvmloader.c >> > +++ b/tools/firmware/hvmloader/hvmloader.c >> > @@ -253,10 +253,40 @@ static void acpi_enable_sci(void) >> > BUG_ON(!(pm1a_cnt_va

[Xen-devel] [PATCH] libxl: libxl_domain_create_restore has an extra argument

In the latest libxenlight code, libxl_domain_create_restore accepts a new argument. Update libvirt's libxl driver for that. Use the macro provided by libxenlight to detect which version should be used. The new parameter (send_back_fd) is set to -1 because libvirt provides no such fd. Signed-off-b

Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server

On Thu, Mar 31, 2016 at 11:53 AM, Yu Zhang wrote: > Previously p2m type p2m_mmio_write_dm was introduced for write- > protected memory pages whose write operations are supposed to be > forwarded to and emulated by an ioreq server. Yet limitations of > rangeset restrict the number of guest pages to

Re: [Xen-devel] [PATCH] libxl: libxl_domain_create_restore has an extra argument

CC Jim as well On Tue, Apr 05, 2016 at 03:20:12PM +0100, Wei Liu wrote: > In the latest libxenlight code, libxl_domain_create_restore accepts a > new argument. Update libvirt's libxl driver for that. Use the macro > provided by libxenlight to detect which version should be used. > > The new param

Re: [Xen-devel] [PATCH v4] xen/arm64: check XSM Magic from the second unknown module.

Hi Jan, On 5 April 2016 at 22:16, Jan Beulich wrote: On 05.04.16 at 15:38, wrote: >> --- a/xen/xsm/xsm_core.c >> +++ b/xen/xsm/xsm_core.c >> @@ -19,6 +19,8 @@ >> >> #ifdef CONFIG_XSM >> >> +#include > > This is not a good idea. Note how xsm_policy.c limits this inclusion to > the CONFIG_H

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

On 04/05/2016 11:43 AM, Jan Beulich wrote: On 29.03.16 at 15:44, wrote: >> Introduce support for using TSC as platform time which is the highest >> resolution time and most performant to get (~20 nsecs). Though there >> are also several problems associated with its usage, and there isn't a >

Re: [Xen-devel] [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k

On Tue, Apr 05, 2016 at 07:10:07AM +0200, Juergen Gross wrote: > Use the smp_call_on_cpu() function to call system management > mode on cpu 0. > Make call secure by adding get_online_cpus() to avoid e.g. suspend > resume cycles in between. > > Signed-off-by: Juergen Gross > --- > V4: add call to

Re: [Xen-devel] [PATCH v2 1/3] x86/ioreq server: Add new functions to get/set memory types.

On Tue, Apr 5, 2016 at 2:57 PM, George Dunlap wrote: > On Thu, Mar 31, 2016 at 11:53 AM, Yu Zhang wrote: >> For clarity this patch breaks the code to set/get memory types out >> of do_hvm_op() into dedicated functions: hvmop_set/get_mem_type(). >> Also, for clarity, checks for whether a memory ty

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

>>> On 05.04.16 at 16:56, wrote: > On 04/05/2016 11:43 AM, Jan Beulich wrote: > On 29.03.16 at 15:44, wrote: >>> @@ -541,6 +613,10 @@ static int __init try_platform_timer(struct >>> platform_timesource *pts) >>> if ( rc <= 0 ) >>> return rc; >>> >>> +/* We have a platform

Re: [Xen-devel] [PATCH v2 4/6] x86/time: streamline platform time init on plt_init()

On 04/05/2016 12:46 PM, Jan Beulich wrote: On 29.03.16 at 15:44, wrote: >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -434,6 +434,7 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns) >> / >> * PLATFORM TIMER 4: TSC >>

Re: [Xen-devel] [PATCH] libxl: libxl_domain_create_restore has an extra argument

Wei Liu writes ("Re: [PATCH] libxl: libxl_domain_create_restore has an extra argument"): > CC Jim as well > > On Tue, Apr 05, 2016 at 03:20:12PM +0100, Wei Liu wrote: > > In the latest libxenlight code, libxl_domain_create_restore accepts a > > new argument. Update libvirt's libxl driver for that

Re: [Xen-devel] [PATCH] libxl: fix POLLHUP handling

On Thu, Mar 31, 2016 at 02:50:07PM +0200, Roger Pau Monne wrote: > The current code in bootloader_copyfail will error out on expected POLLHUPs > because of a missing "else" in the if clause. > > The behaviour that triggers this bug has only been seen on FreeBSD so far. > > Signed-off-by: Roger Pa

[Xen-devel] Stub domain crash on Xen v4.6.1

Hi, after adding the 'device_model_stubdomain_override = 1' to an otherwise fine configuration the domain crashes on start. Xen is v4.6.1 compiled from source on Debian Jessie 64bits this way: - ./configure --enable-stubdom --enable-githttp - make dist-xen - make dist-tools - make di

Re: [Xen-devel] [PATCH v2 4/6] x86/time: streamline platform time init on plt_init()

>>> On 05.04.16 at 17:12, wrote: > On 04/05/2016 12:46 PM, Jan Beulich wrote: > On 29.03.16 at 15:44, wrote: >>> @@ -516,17 +519,31 @@ static s_time_t __read_platform_stime(u64 >>> platform_time) >>> return (stime_platform_stamp + scale_delta(diff, &plt_scale)); >>> } >>> >>> +static

Re: [Xen-devel] [PATCH v2 5/6] x86/time: refactor read_platform_stime()

On 04/05/2016 12:52 PM, Jan Beulich wrote: On 29.03.16 at 15:44, wrote: >> -static s_time_t read_platform_stime(void) >> +static s_time_t read_platform_stime(u64 *stamp) >> { >> -u64 count; >> +u64 plt_stamp_counter, count; > > "stamp" and "counter" seem kind of redundant. > A bi

Re: [Xen-devel] [PATCH v2 5/6] x86/time: refactor read_platform_stime()

>>> On 05.04.16 at 17:22, wrote: > On 04/05/2016 12:52 PM, Jan Beulich wrote: > On 29.03.16 at 15:44, wrote: >>> -static s_time_t read_platform_stime(void) >>> +static s_time_t read_platform_stime(u64 *stamp) >>> { >>> -u64 count; >>> +u64 plt_stamp_counter, count; >> >> "stamp" and

Re: [Xen-devel] [PATCH v4 11/26] xen/x86: Improvements to in-hypervisor cpuid sanity checks

On 28/03/16 16:29, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 23, 2016 at 04:36:14PM +, Andrew Cooper wrote: >> Currently, {pv,hvm}_cpuid() has a large quantity of essentially-static logic >> for modifying the features visible to a guest. A lot of this can be subsumed >> by {pv,hvm}_featuremas

[Xen-devel] [linux-4.1 test] 88721: regressions - FAIL

flight 88721 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/88721/ 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. 66399 build-i386-rumpuserxen

Re: [Xen-devel] [PATCH] x86/mm/pat: Fix BUG_ON in mmap_mem on QEMU/i386

+xen-devl On Tue, 2016-04-05 at 13:09 +0200, Borislav Petkov wrote: > On Fri, Apr 01, 2016 at 04:19:45PM -0600, Toshi Kani wrote: > > > > The following BUG_ON error was reported on QEMU/i386: > > > >   kernel BUG at arch/x86/mm/physaddr.c:79! > >   Call Trace: > >   phys_mem_access_prot_allowed

Re: [Xen-devel] Issues with the xen-access.c model

On Tue, Apr 5, 2016 at 6:13 AM, Andrew Cooper wrote: > On 05/04/16 11:55, Razvan Cojocaru wrote: > > Hello, > > > > xen-access.c does roughly this: > > > > for (;;) { > > poll_evt_channel(); > > > > if (new_events) { > > while (ring_buffer_has_requests) { > >

Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling

On 04/02/2016 10:01 AM, Andy Lutomirski wrote: Andy Lutomirski (9): x86/head: Pass a real pt_regs and trapnr to early_fixup_exception x86/head: Move the early NMI fixup into C x86/head: Move early exception panic code into early_fixup_exception x86/traps: Enable all exception handler

Re: [Xen-devel] [PATCH] kernel-parameters: document earlycon=xenboot

On Tue, Apr 5, 2016 at 9:49 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Apr 04, 2016 at 10:48:11PM -0400, Chris Patterson wrote: >> Add earlycon=xenboot option to Documentation/kernel-parameters.txt. >> > > But it is not true. > > I tried this on x86: "earlycon=xenboot console=tty0" > I can invest

Re: [Xen-devel] pv-grub guest booting fail with recent qemu-xen

On Tue, Apr 05, 2016 at 01:26:47AM +, Hao, Xudong wrote: > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Konrad > > Rzeszutek Wilk > > Sent: Friday, April 1, 2016 11:55 PM > > To: Hao, Xudong > > Cc: samuel.thiba...@ens-lyon.org; xen-dev

Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading

> > Please advise. > > Well, I certainly didn't think of it getting done that way. To me the > most natural generalization would be for an arch to register one or > more secondary ranges (which could even get referred to by an > enum) at boot time (or maybe that could even be arranged for at > com

Re: [Xen-devel] Issues with the xen-access.c model

On 04/05/16 18:35, Tamas K Lengyel wrote: > > > On Tue, Apr 5, 2016 at 6:13 AM, Andrew Cooper > wrote: > > On 05/04/16 11:55, Razvan Cojocaru wrote: > > Hello, > > > > xen-access.c does roughly this: > > > > for (;;) { > > poll

Re: [Xen-devel] [PATCH 03/16] xen: sched: make implementing .alloc_pdata optional

On Mon, 2016-04-04 at 00:13 -0600, Jan Beulich wrote: > > > > On 01.04.16 at 19:01, wrote: > > Ok, I'll do: > > > > sd->sched_priv = SCHED_OP(&ops, alloc_pdata, cpu); > > if ( IS_ERR(sd->sched_priv) ) > > { > > int err = PTR_ERR(sd->sched_priv); > > > > sd->sched_priv

Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading

>>> On 05.04.16 at 17:50, wrote: > That actually ended up pretty simple. It won't compile for ARM yet, > see below please. This comes pretty close. A few minor comments below. > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -100,6 +100,9 @@ unsigned long __read_mostly xen_phys_sta

Re: [Xen-devel] Issues with the xen-access.c model

On 05/04/16 16:55, Razvan Cojocaru wrote: > On 04/05/16 18:35, Tamas K Lengyel wrote: >> >> On Tue, Apr 5, 2016 at 6:13 AM, Andrew Cooper > > wrote: >> >> On 05/04/16 11:55, Razvan Cojocaru wrote: >> > Hello, >> > >> > xen-access.c does roughly this

Re: [Xen-devel] [PATCH v4 12/26] x86/cpu: Move set_cpumask() calls into c_early_init()

On 28/03/16 16:55, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 23, 2016 at 04:36:15PM +, Andrew Cooper wrote: >> Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the >> commandline-provided masks would take effect in Xen's view of the features. > s/the// ? > > Or perhaps s

Re: [Xen-devel] [PATCH v4 13/26] x86/cpu: Sysctl and common infrastructure for levelling context switching

On 28/03/16 17:12, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 23, 2016 at 04:36:16PM +, Andrew Cooper wrote: >> A toolstack needs to know how much control Xen has over the visible cpuid >> values in PV guests. Provide an explicit mechanism to query what Xen is >> capable of. >> >> This interfa

Re: [Xen-devel] [PATCH 09/16] xen: sched: close potential races when switching scheduler to CPUs

On Wed, 2016-03-23 at 19:05 +, George Dunlap wrote: > On 18/03/16 19:05, Dario Faggioli wrote: > > > > by using the sched_switch hook that we have introduced in > > the various schedulers. > > > > The key is to let the actual switch of scheduler and the > > remapping of the scheduler lock for

Re: [Xen-devel] [PATCH] kernel-parameters: document earlycon=xenboot

On Tue, Apr 05, 2016 at 11:43:36AM -0400, Chris Patterson wrote: > On Tue, Apr 5, 2016 at 9:49 AM, Konrad Rzeszutek Wilk > wrote: > > On Mon, Apr 04, 2016 at 10:48:11PM -0400, Chris Patterson wrote: > >> Add earlycon=xenboot option to Documentation/kernel-parameters.txt. > >> > > > > But it is not

Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading

> > -void *vm_alloc(unsigned int nr, unsigned int align) > > +void __init vm_init(void) > > +{ > > +vm_init_type(VMAP_VIRT); > > +#ifdef CONFIG_XSPLICE > > +vm_init_type(XEN_VIRT); > > +#endif > > +} > > I think we should leave it to the arch to call vm_init_type() for > the non-default ty

Re: [Xen-devel] [PATCH v4 14/26] x86/cpu: Rework AMD masking MSR setup

On 28/03/16 19:55, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 23, 2016 at 04:36:17PM +, Andrew Cooper wrote: >> This patch is best reviewed as its end result rather than as a diff, as it >> rewrites almost all of the setup. >> >> On the BSP, cpuid information is used to evaluate the potential a

[Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.

From: Fu Wei This patch adds a has_xsm_magic helper function for detecting XSM from the second unknown module. If Xen can't get the kind of module from compatible, we guess the kind of these unknowns respectively: (1) The first unknown must be kernel. (2) Detect the XSM Magic from the 2n

Re: [Xen-devel] [PATCH v6] libxl: allow 'phy' backend to use empty files

On Wed, Feb 17, 2016 at 5:20 PM, Roger Pau Monne wrote: > This was introduced by 97ee1f (~5 years ago), but was probably never > surfaced because most people used regular files as CDROM images, so the PHY > backend was actually never selected. A year ago this was changed, and now > regular RAW fil

Re: [Xen-devel] [PATCH v4 15/26] x86/cpu: Rework Intel masking/faulting setup

On 28/03/16 20:14, Konrad Rzeszutek Wilk wrote: >> + * Context switch levelling state to the next domain. A parameter of NULL >> is >> + * used to context switch to the default host state, and is used by the >> BSP/AP >> + * startup code. >> + */ >> +static void intel_ctxt_switch_levelling(const

Re: [Xen-devel] [PATCH 16/16] xen: sched: implement vcpu hard affinity in Credit2

On Thu, 2016-03-24 at 15:42 +, George Dunlap wrote: > On Fri, Mar 18, 2016 at 7:06 PM, Dario Faggioli > wrote: > > > > From: Justin Weaver > >  > > Signed-off-by: Justin Weaver > > Signed-off-by: Dario Faggioli > Just checking, are the main changes between this patch and the v4 > that > Ju

Re: [Xen-devel] [PATCH v4 17/26] x86/pv: Provide custom cpumasks for PV domains

On 28/03/16 20:40, Konrad Rzeszutek Wilk wrote: > On Wed, Mar 23, 2016 at 04:36:20PM +, Andrew Cooper wrote: >> And use them in preference to cpumask_defaults on context switch. HVM >> domains > Extra space before HVM It is normal to have two spaces following a full stop in written text. Ob

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

On 04/05/2016 04:12 PM, Jan Beulich wrote: On 05.04.16 at 16:56, wrote: >> On 04/05/2016 11:43 AM, Jan Beulich wrote: >> On 29.03.16 at 15:44, wrote: @@ -541,6 +613,10 @@ static int __init try_platform_timer(struct platform_timesource *pts) if ( rc <= 0 )

Re: [Xen-devel] [PATCH v2 5/6] x86/time: refactor read_platform_stime()

On 04/05/2016 04:26 PM, Jan Beulich wrote: On 05.04.16 at 17:22, wrote: >> On 04/05/2016 12:52 PM, Jan Beulich wrote: >> On 29.03.16 at 15:44, wrote: -static s_time_t read_platform_stime(void) +static s_time_t read_platform_stime(u64 *stamp) { -u64 count;

Re: [Xen-devel] [PATCH v2 4/6] x86/time: streamline platform time init on plt_init()

On 04/05/2016 04:22 PM, Jan Beulich wrote: On 05.04.16 at 17:12, wrote: >> On 04/05/2016 12:46 PM, Jan Beulich wrote: >> On 29.03.16 at 15:44, wrote: @@ -516,17 +519,31 @@ static s_time_t __read_platform_stime(u64 platform_time) return (stime_platform_stamp + scale_d

Re: [Xen-devel] [PATCH 09/16] xen: sched: close potential races when switching scheduler to CPUs

On Thu, 2016-03-24 at 12:14 +, George Dunlap wrote: > On 18/03/16 19:05, Dario Faggioli wrote: > > > > by using the sched_switch hook that we have introduced in > > the various schedulers. > > > > The key is to let the actual switch of scheduler and the > > remapping of the scheduler lock for

Re: [Xen-devel] [PATCH v5 10/28] xsplice: Implement payload loading

On Tue, Apr 05, 2016 at 12:45:44PM -0400, Konrad Rzeszutek Wilk wrote: > > > -void *vm_alloc(unsigned int nr, unsigned int align) > > > +void __init vm_init(void) > > > +{ > > > +vm_init_type(VMAP_VIRT); > > > +#ifdef CONFIG_XSPLICE > > > +vm_init_type(XEN_VIRT); > > > +#endif > > > +} > >

Re: [Xen-devel] [PATCH v4 26/26] tools/libxc: Calculate xstate cpuid leaf from guest information

On 31/03/16 08:48, Jan Beulich wrote: On 23.03.16 at 17:36, wrote: >> --- a/tools/libxc/xc_cpuid_x86.c >> +++ b/tools/libxc/xc_cpuid_x86.c >> @@ -398,54 +398,97 @@ static void intel_xc_cpuid_policy(xc_interface *xch, >> } >> } >> >> +/* XSTATE bits in XCR0. */ >> +#define X86_XCR0_X87

[Xen-devel] [libvirt test] 88753: regressions - trouble: blocked/broken/pass

flight 88753 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/88753/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 88483 build-armhf-

  1   2   >