Due to a bug in the glibc headers the macros makedev(), major() and
minor() where avaialble by including sys/types.h. This bug was
addressed in glibc-2.25 by introducing a warning when these macros are
used. Since Xen is build with -Werror this new warning cause a compile
error.
Use sys/sysmacros.
libgnttab contains the complete gntshr support, but the tools build
infrastructure contains dedicated support for gntshr _and_ gnttab.
Remove the gntshr specific flags and switch their users to gnttab
instead.
Signed-off-by: Juergen Gross
---
.gitignore| 1 -
tools/Rule
Hi Stefano,
On 2017/3/15 8:24, Stefano Stabellini wrote:
> On Mon, 13 Mar 2017, Wei Chen wrote:
>> We want to add HCR_EL2 register to Xen context switch. And each copy
>> of HCR_EL2 in vcpu structure will be initialized with the same set
>> of trap flags as the HCR_EL2 register. We introduce a hel
flight 106680 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-buildfail REGR. vs. 106664
Tests which
>>> On 15.03.17 at 03:52, wrote:
> Sorry, I may not fully understand your meaning. My thoughts are below.
> 1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';
>
> 2. After that, we get valid cpumask through cpupool_domain_cpumask();
>
> 3. If the actual valid cpumask changed after
On 14/03/2017 21:23, Stefano Stabellini wrote:
> On Tue, 14 Mar 2017, Stefano Stabellini wrote:
>>> Then you add to Makefile:
>>>
>>> CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
>>> CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y)
>>> +CONFIG_XEN := $(CONFIG_XEN_BACK
>>> On 14.03.17 at 22:07, wrote:
> On 12/14/2016 09:37 AM, Razvan Cojocaru wrote:
>> On 12/14/2016 09:14 AM, Jan Beulich wrote:
>> On 13.12.16 at 23:02, wrote:
On 13/12/2016 21:55, Razvan Cojocaru wrote:
> On a somewhat related note, it's important to also figure out how best
> t
On Tue 14-03-17 14:20:14, Igor Mammedov wrote:
> On Mon, 13 Mar 2017 13:28:25 +0100
> Michal Hocko wrote:
>
> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> > > On Thu, 9 Mar 2017 13:54:00 +0100
> > > Michal Hocko wrote:
[...]
> > > > The kernel is supposed to provide a proper API and that i
On Tue 14-03-17 20:35:21, Andrea Arcangeli wrote:
> Hello,
>
> On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote:
> > On Fri 10-03-17 13:00:37, Reza Arbab wrote:
> > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote:
> > > >OK, so while I was playing with this setup some mo
flight 106665 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106665/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 3 host-install(3)broken REGR. vs. 1065
On Mon, 13 Mar 2017 16:55:53 -0700
Stefano Stabellini wrote:
> Do not use the ring.h header installed on the system. Instead, import
> the header into the QEMU codebase. This avoids problems when QEMU is
> built against a Xen version too old to provide all the ring macros.
>
What kind of proble
On 17-03-15 01:40:06, Jan Beulich wrote:
> >>> On 15.03.17 at 03:52, wrote:
> > Sorry, I may not fully understand your meaning. My thoughts are below.
> > 1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';
> >
> > 2. After that, we get valid cpumask through cpupool_domain_cpumask();
>>> On 15.03.17 at 09:18, wrote:
> On 17-03-15 01:40:06, Jan Beulich wrote:
>> >>> On 15.03.17 at 03:52, wrote:
>> > Sorry, I may not fully understand your meaning. My thoughts are below.
>> > 1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';
>> >
>> > 2. After that, we get valid
On 2017/3/15 8:25, Stefano Stabellini wrote:
> On Mon, 13 Mar 2017, Wei Chen wrote:
>> Different domains may have different HCR_EL2 flags. For example, the
>> 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
>> we give each domain a default HCR_EL2 value and save it in the VCPU's
>>> On 15.03.17 at 08:30, wrote:
> flight 106680 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106680/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-armhf 5 xen-build
On 03/15/2017 10:45 AM, Jan Beulich wrote:
On 15.03.17 at 08:30, wrote:
>> flight 106680 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/106680/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be
On Mon, 13 Mar 2017 16:55:54 -0700
Stefano Stabellini wrote:
> It uses the new ring.h macros to declare rings and interfaces.
>
> Signed-off-by: Stefano Stabellini
> CC: anthony.per...@citrix.com
> CC: jgr...@suse.com
> ---
> hw/9pfs/xen_9pfs.h | 20
> 1 file changed, 20 i
Hi Stefano,
On 2017/3/15 8:25, Stefano Stabellini wrote:
> On Mon, 13 Mar 2017, Wei Chen wrote:
>> The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
>> when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
>> DomU in vcpu_initialise, we didn't know the domain's addres
Hi Stefano,
On 2017/3/15 8:45, Stefano Stabellini wrote:
> On Mon, 13 Mar 2017, Wei Chen wrote:
>> In order to distinguish guest-generated SErrors from hypervisor-generated
>> SErrors. We have to place SError checking code in every EL1 -> EL2 paths.
> ^ remove .
>
Ok.
>> That will be an
flight 106683 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 5 xen-buildfail REGR. vs. 106664
Tests which
The previous "tools/libxc: Exposed XEN_DOMCTL_getvcpuextstate" broke
the ARM build (the hypercall does not have a corresponding DOMCTL
ARM struct). This patch fixes the build by returning -ENODEV for
ARM from xc_vcpu_get_extstate().
Signed-off-by: Razvan Cojocaru
---
tools/libxc/xc_domain.c | 4
On 14/03/17 18:35, Vitaly Kuznetsov wrote:
> All code to support Xen PV will get under this new option. For the
> beginning, check for it in the common code.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> Changes since v2:
>select XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross]
> ---
Revi
On 14/03/17 18:35, Vitaly Kuznetsov wrote:
> As a preparation to splitting the code we need to untangle it:
>
> x86_hyper_xen -> x86_hyper_xen_hvm and x86_hyper_xen_pv
> xen_platform() -> xen_platform_hvm() and xen_platform_pv()
> xen_cpu_up_prepare() -> xen_cpu_up_prepare_pv() and xen_cpu_up_prep
On 14/03/17 18:35, Vitaly Kuznetsov wrote:
> Changes since v2:
> - Rebase to 4.11.0-rc1+
> - XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross]
> - .pin_vcpu kept for x86_hyper_xen_hvm to support PVH Dom0 in future
>[Juergen Gross]
> - 'extern' qualifiers dropped from newly introduced functi
On Mon, 13 Mar 2017 16:55:56 -0700
Stefano Stabellini wrote:
> Write the limits of the backend to xenstore. Connect to the frontend.
> Upon connection, allocate the rings according to the protocol
> specification.
>
> Initialize a QEMUBH to schedule work upon receiving an event channel
> notific
On Wed, Mar 15, 2017 at 11:20:30AM +0200, Razvan Cojocaru wrote:
> The previous "tools/libxc: Exposed XEN_DOMCTL_getvcpuextstate" broke
> the ARM build (the hypercall does not have a corresponding DOMCTL
> ARM struct). This patch fixes the build by returning -ENODEV for
> ARM from xc_vcpu_get_extst
On 03/15/2017 11:59 AM, Wei Liu wrote:
> On Wed, Mar 15, 2017 at 11:20:30AM +0200, Razvan Cojocaru wrote:
>> The previous "tools/libxc: Exposed XEN_DOMCTL_getvcpuextstate" broke
>> the ARM build (the hypercall does not have a corresponding DOMCTL
>> ARM struct). This patch fixes the build by return
> From: Ross Lagerwall [mailto:ross.lagerw...@citrix.com]
> Sent: Thursday, March 9, 2017 1:47 AM
>
> When using LivePatch, use of __LINE__ can generate spurious changes in
> functions due to embedded line numbers. For release builds with LivePatch
> enabled, remove the use of these line numbers
flight 106669 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106669/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 104301
Regressions which are
On Tue, Mar 14, 2017 at 08:06:51PM +, Andrew Cooper wrote:
> On 14/03/17 13:31, Juergen Gross wrote:
> > In order to be able to use pkg-config for obtaining linker- and
> > compiler-flags provide a xengnttab.pc and a xengntshr.pc file.
> >
> > Signed-off-by: Juergen Gross
> > Acked-by: Wei Liu
1: centralize put_fpu() invocations
2: correct handling of FPU insns faulting on memory write
3: correct FPU code/data pointers and opcode handling
XTF: add FPU/SIMD register state test
Signed-off-by: Jan Beulich
---
v2: Patch 1 and the XTF one changed (see there), the other two
needed adjust
..., splitting parts of it into check_*() macros. This is in
preparation of making ->put_fpu() do further adjustments to register
state. (Some of the check_xmm() invocations could be avoided, as in
some of the cases no insns handled there can actually raise #XM, but I
think we're better off keeping
On 15/03/17 11:17, Wei Liu wrote:
> On Tue, Mar 14, 2017 at 08:06:51PM +, Andrew Cooper wrote:
>> On 14/03/17 13:31, Juergen Gross wrote:
>>> In order to be able to use pkg-config for obtaining linker- and
>>> compiler-flags provide a xengnttab.pc and a xengntshr.pc file.
>>>
>>> Signed-off-by:
When an FPU instruction with a memory destination fails during the
memory write, it should not affect FPU register state. Due to the way
we emulate FPU (and SIMD) instructions, we can only guarantee this by
- backing out changes to the FPU register state in such a case or
- doing a descriptor read
Prevent leaking the hypervisor ones (stored by hardware during stub
execution), at once making sure the guest sees correct values there.
This piggybacks on the backout logic used to deal with write faults of
FPU insns.
Deliberately ignore the NO_FPU_SEL feature here: Honoring it would
merely mean
Add tests to verify that
- FPU insns leave correct (guest) values in FIP/FDP/FOP/FCS/FDS (at the
example for FSTPS),
- FPU insns writing memory don't update FPU register state when the
write faults (at the example of FISTPS),
- VCVTPS2PH (once implemented in the emulator) doesn't update MXCSR
On Wed, Mar 15, 2017 at 11:26:55AM +0100, Juergen Gross wrote:
> On 15/03/17 11:17, Wei Liu wrote:
> > On Tue, Mar 14, 2017 at 08:06:51PM +, Andrew Cooper wrote:
> >> On 14/03/17 13:31, Juergen Gross wrote:
> >>> In order to be able to use pkg-config for obtaining linker- and
> >>> compiler-fla
flight 106686 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd646 coverity-upload fail REGR. vs. 106549
version t
On 15/03/17 10:26, Juergen Gross wrote:
> On 15/03/17 11:17, Wei Liu wrote:
>> On Tue, Mar 14, 2017 at 08:06:51PM +, Andrew Cooper wrote:
>>> On 14/03/17 13:31, Juergen Gross wrote:
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xengnttab.pc a
On 15/03/17 06:07, Juergen Gross wrote:
> On 14/03/17 21:06, Andrew Cooper wrote:
>> On 14/03/17 13:31, Juergen Gross wrote:
>>> In order to be able to use pkg-config for obtaining linker- and
>>> compiler-flags provide a xengnttab.pc and a xengntshr.pc file.
>>>
>>> Signed-off-by: Juergen Gross
>
On Fri, Mar 10, 2017 at 10:10:57AM +, Tim Deegan wrote:
> The 'val' field in the packet is byte-aligned (because it is part of a
> packed struct), but the pointer argument to kdd_rdmsr() has the normal
> alignment constraints for a uint64_t *. Use a local variable to make sure
> the passed poi
> From: Gao, Chao
> Sent: Monday, February 27, 2017 9:46 AM
>
> We used structure assignment to update irte which was not safe when a
a -> an
> interrupt happend during update. It is better to update IRTE atomically
happend -> happened
> through cmpxchg16b(). When cmpxchg16b is not supported,
On Wed, Mar 15, 2017 at 10:34:55AM +0800, Zhang Chen wrote:
> Address Liu wei's comments.
>
> Signed-off-by: Zhang Chen
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Wed, Mar 15, 2017 at 07:01:34AM +, Olaf Hering wrote:
> Due to a bug in the glibc headers the macros makedev(), major() and
> minor() where avaialble by including sys/types.h. This bug was
> addressed in glibc-2.25 by introducing a warning when these macros are
> used. Since Xen is build wit
On Wed, Mar 15, 2017 at 08:13:31AM +0100, Juergen Gross wrote:
> libgnttab contains the complete gntshr support, but the tools build
> infrastructure contains dedicated support for gntshr _and_ gnttab.
>
> Remove the gntshr specific flags and switch their users to gnttab
> instead.
>
> Signed-off
On Mon, 13 Mar 2017 16:55:57 -0700
Stefano Stabellini wrote:
> Upon receiving an event channel notification from the frontend, schedule
> the bottom half. From the bottom half, read one request from the ring,
> create a pdu and call pdu_submit to handle it.
>
> For now, only handle one request p
On Wed, Mar 15, 2017 at 10:02:46AM +0800, Zhang Chen wrote:
>
>
> On 03/14/2017 07:24 PM, Wei Liu wrote:
> > On Mon, Mar 06, 2017 at 10:59:25AM +0800, Zhang Chen wrote:
> > > We use kernel colo proxy's way to get the checkpoint event
> > > from qemu colo-compare.
> > > Qemu colo-compare need add
On Mon, 13 Mar 2017 16:55:58 -0700
Stefano Stabellini wrote:
> Implement xen_9pfs_init_in/out_iov_from_pdu and
> xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the
> data on the ring.
>
> This is safe as we only handle one request per ring at any given time.
>
> Signed-off-by:
On Mon, 13 Mar 2017 16:55:59 -0700
Stefano Stabellini wrote:
> Once a request is completed, xen_9pfs_push_and_notify gets called. In
> xen_9pfs_push_and_notify, update the indexes (data has already been
> copied to the sg by the common code) and send a notification to the
> frontend.
>
> Schedul
On 15/03/17 07:19, Wei Chen wrote:
Hi Stefano,
Hello,
On 2017/3/15 8:24, Stefano Stabellini wrote:
On Mon, 13 Mar 2017, Wei Chen wrote:
We want to add HCR_EL2 register to Xen context switch. And each copy
of HCR_EL2 in vcpu structure will be initialized with the same set
of trap flags as th
On Tue, Mar 14, 2017 at 04:29:22PM +, Wei Liu wrote:
> On Tue, Mar 14, 2017 at 10:27:25AM +, Wei Liu wrote:
> > On Mon, Mar 13, 2017 at 04:50:12PM +, Wei Liu wrote:
> > > On Fri, Mar 03, 2017 at 12:25:06PM +, Roger Pau Monne wrote:
> > > > This removal applies to both the hypervisor
Hi Wei,
On 15/03/17 08:34, Wei Chen wrote:
On 2017/3/15 8:25, Stefano Stabellini wrote:
On Mon, 13 Mar 2017, Wei Chen wrote:
Different domains may have different HCR_EL2 flags. For example, the
64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
we give each domain a default HC
After reports about degraded performance after a PV domU was migrated
from one dom0 to another it turned out that this issue happens with
every version of Xen and every version of domU kernel.
The used benchmark is 'sysbench memory'. I hacked it up to show how long
the actual work takes, and that
On 15/03/17 11:20, Olaf Hering wrote:
> After reports about degraded performance after a PV domU was migrated
> from one dom0 to another it turned out that this issue happens with
> every version of Xen and every version of domU kernel.
>
> The used benchmark is 'sysbench memory'. I hacked it up to
On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
[...]
> Still missing 'xl info'.
Got Intel NUC5i3MYHE (internally it is NUC5i3MYBE board) into my hands.
I have put 8 GiB RAM and 500 GB SATA 3 into it. Updated BIOS/EFI to 0041
version (it is the latest one). Installed latest Debia
On Mon, 13 Mar 2017 16:55:57 -0700
Stefano Stabellini wrote:
> Upon receiving an event channel notification from the frontend, schedule
> the bottom half. From the bottom half, read one request from the ring,
> create a pdu and call pdu_submit to handle it.
>
> For now, only handle one request p
Hi Ian / Wei,
Qemu-xen commits:
021746c131cdfeab9d82ff918795a9f18d20d7ae PCMachineState: introduce
acpi_build_enabled field
804ba7c10bbc66bb8a8aa73ecc60f620da7423d5 xen: Fix xenpv machine initialisation
(the second one is a fix for the first one)
Fixed a regression with direct kernel boot, which
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 March 2017 10:28
> To: xen-devel
> Cc: Suravee Suthikulpanit ; Andrew
> Cooper ; Paul Durrant
> ; Jun Nakajima ; Kevin
> Tian ; Boris Ostrovsky
> Subject: [PATCH v2 2/3] x86emul: correct handling of FPU insns f
On Fri, Mar 10, 2017 at 10:28:43AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 10, 2017 at 12:23:18PM +0900, Roger Pau Monné wrote:
> > On Thu, Mar 09, 2017 at 07:29:34PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Mar 09, 2017 at 01:26:45PM +, Julien Grall wrote:
> > > > Hi Konrad,
On Wed, Mar 15, 2017 at 01:01:52PM +0100, Sander Eikelenboom wrote:
> Hi Ian / Wei,
>
> Qemu-xen commits:
> 021746c131cdfeab9d82ff918795a9f18d20d7ae PCMachineState: introduce
> acpi_build_enabled field
> 804ba7c10bbc66bb8a8aa73ecc60f620da7423d5 xen: Fix xenpv machine initialisation
> (the second
On 15/03/17 07:49, Jan Beulich wrote:
On 14.03.17 at 22:07, wrote:
>> On 12/14/2016 09:37 AM, Razvan Cojocaru wrote:
>>> On 12/14/2016 09:14 AM, Jan Beulich wrote:
>>> On 13.12.16 at 23:02, wrote:
> On 13/12/2016 21:55, Razvan Cojocaru wrote:
>> On a somewhat related note, it's i
Currently, msi_msg_to_remap_entry is buggy when the live IRTE is in posted
format. Straightforwardly, we can let caller specify which format of IRTE they
want update to. But the problem is current callers are not aware of the
binding with guest interrupt. Making all callers be aware of the binding
We used structure assignment to update irte which was not safe when an
interrupt happened during update. It is better to update IRTE atomically
through cmpxchg16b(). When cmpxchg16b is not supported, two 64-bit write
operations can update IRTE safely when only the high qword or the low qword is
int
From: Feng Wu
Use type-safe structure assignment instead of memcpy()
Use sizeof(*iremap_entry).
Signed-off-by: Feng Wu
Signed-off-by: Chao Gao
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Kevin Tian
---
v10:
- Added several lines for patch [1/6] has been reworked.
v9:
- Delete several lines
The current VT-d PI related code may operate incorrectly in the
following scenarios:
1. When IRTE is in posted mode, we don't need to set the irq
affinity for it, since the destination of these interrupts is
vCPU and the vCPU affinity is set during vCPU scheduling. Patch
[1/6] handles this. In
From: Feng Wu
When cpu is offline, we need to move all the vcpus in its blocking
list to another online cpu, this patch handles it.
Signed-off-by: Feng Wu
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
Acked-by: Kevin Tian
---
v7:
- Pass unsigned int to vmx_pi_desc_fixup()
v6:
- Careful
When a vCPU migrated to another pCPU, pt irqs binded to this vCPU also needed
migration. When VT-d PI is enabled, interrupt vector will be recorded to
a main memory resident data-structure and a notification whose destination
is decided by NDST is generated. NDST is properly adjusted during vCPU
mi
The current logic of using VT-d pi is when guest configurates the pirq's
destination vcpu to a single vcpu, the according IRTE is updated to
posted format. If the destination of the pirq is multiple vcpus, we just use
interrupt remapping. Obviously, we should fall back to remapping interrupt
when g
flight 106690 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106690/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-debianhvm
Hi Mohsen,
> On 15 Mar 2017, at 09:50, Mohsen wrote:
>
> Dear Xen Project community members,
>
> I have written a Xen book recently (pdf attached) which is aimed at teaching
> Xen newbies. I would like to make the book available to the Xen Project under
> a CC-BY-SA-3.0 license. Ideally, I wo
>>> On 15.03.17 at 13:08, wrote:
> On 15/03/17 07:49, Jan Beulich wrote:
> On 14.03.17 at 22:07, wrote:
>>> On 12/14/2016 09:37 AM, Razvan Cojocaru wrote:
On 12/14/2016 09:14 AM, Jan Beulich wrote:
On 13.12.16 at 23:02, wrote:
>> On 13/12/2016 21:55, Razvan Cojocaru wrote:
On Wed, Mar 15, 2017 at 12:07:28PM +, Roger Pau Monné wrote:
> On Fri, Mar 10, 2017 at 10:28:43AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Mar 10, 2017 at 12:23:18PM +0900, Roger Pau Monné wrote:
> > > On Thu, Mar 09, 2017 at 07:29:34PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Thu,
On 15/03/17 13:08, Wei Liu wrote:
> On Wed, Mar 15, 2017 at 01:01:52PM +0100, Sander Eikelenboom wrote:
>> Hi Ian / Wei,
>>
>> Qemu-xen commits:
>> 021746c131cdfeab9d82ff918795a9f18d20d7ae PCMachineState: introduce
>> acpi_build_enabled field
>> 804ba7c10bbc66bb8a8aa73ecc60f620da7423d5 xen: Fix xe
On Wed, Mar 15, 2017 at 08:42:04AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 15, 2017 at 12:07:28PM +, Roger Pau Monné wrote:
> > On Fri, Mar 10, 2017 at 10:28:43AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Mar 10, 2017 at 12:23:18PM +0900, Roger Pau Monné wrote:
> > > > On Thu,
On Tue, Mar 14, 2017 at 05:47:08AM -0600, Jan Beulich wrote:
> All,
>
> with the goal of releasing in about 3 weeks time, please point out
> backport candidates you find missing from the respective staging
> branch, but which you consider relevant.
It's maybe a little bit premature but I would li
On 03/15/2017 06:28 AM, Jan Beulich wrote:
> When an FPU instruction with a memory destination fails during the
> memory write, it should not affect FPU register state. Due to the way
> we emulate FPU (and SIMD) instructions, we can only guarantee this by
> - backing out changes to the FPU register
>>> On 15.03.17 at 14:24, wrote:
> On 03/15/2017 06:28 AM, Jan Beulich wrote:
>> @@ -3716,9 +3720,9 @@ x86_emulate(
>> break;
>>
>> case 0x9b: /* wait/fwait */
>> -fic.insn_bytes = 1;
>> host_and_vcpu_must_have(fpu);
>> get_fpu(X86EMUL_FPU_wait, &fic);
>>
In anticipation of further flavors (AVX, AVX-512) going to be added
(which would make the current situation even worse), facilitate
reduction of build time (and hence latency to availability of test
results) via use of make's -j option.
Signed-off-by: Jan Beulich
--- a/.gitignore
+++ b/.gitignor
On 03/15/2017 09:31 AM, Jan Beulich wrote:
On 15.03.17 at 14:24, wrote:
>> On 03/15/2017 06:28 AM, Jan Beulich wrote:
>>> @@ -3716,9 +3720,9 @@ x86_emulate(
>>> break;
>>>
>>> case 0x9b: /* wait/fwait */
>>> -fic.insn_bytes = 1;
>>> host_and_vcpu_must_have(fp
On 15/03/17 13:37, Jan Beulich wrote:
> In anticipation of further flavors (AVX, AVX-512) going to be added
> (which would make the current situation even worse), facilitate
> reduction of build time (and hence latency to availability of test
> results) via use of make's -j option.
>
> Signed-off-b
On 03/14/2017 01:05 PM, Thomas Garnier wrote:
> This patch aligns MODULES_END to the beginning of the Fixmap section.
> It optimizes the space available for both sections. The address is
> pre-computed based on the number of pages required by the Fixmap
> section.
>
> It will allow GDT remapping in
On 03/13/2017 07:17 PM, Tamas K Lengyel wrote:
> On Mon, Mar 13, 2017 at 6:29 AM, Razvan Cojocaru
> wrote:
>> On 03/13/2017 02:19 PM, Jan Beulich wrote:
>> On 13.03.17 at 13:01, wrote:
On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
>>>
On 03/15/2017 02:42 PM, Jan Beulich wrote:
On 15.03.17 at 13:08, wrote:
>> On 15/03/17 07:49, Jan Beulich wrote:
>> On 14.03.17 at 22:07, wrote:
On 12/14/2016 09:37 AM, Razvan Cojocaru wrote:
> On 12/14/2016 09:14 AM, Jan Beulich wrote:
> On 13.12.16 at 23:02, wrote:
>>
On 3/15/17 6:35 AM, Daniel Kiper wrote:
> On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
>
> [...]
>
>> Still missing 'xl info'.
>
> Got Intel NUC5i3MYHE (internally it is NUC5i3MYBE board) into my hands.
> I have put 8 GiB RAM and 500 GB SATA 3 into it. Updated BIOS/EFI to 0041
On Wed, Mar 15, 2017 at 09:27:27AM -0500, Doug Goldstein wrote:
> On 3/15/17 6:35 AM, Daniel Kiper wrote:
> > On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
> >
> > [...]
> >
> >> Still missing 'xl info'.
> >
> > Got Intel NUC5i3MYHE (internally it is NUC5i3MYBE board) into my hand
On 3/15/17 9:38 AM, Daniel Kiper wrote:
> On Wed, Mar 15, 2017 at 09:27:27AM -0500, Doug Goldstein wrote:
>> On 3/15/17 6:35 AM, Daniel Kiper wrote:
>>> On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
>>>
>>> [...]
>>>
Still missing 'xl info'.
>>>
>>> Got Intel NUC5i3MYHE (inte
On Wed, Mar 15, Andrew Cooper wrote:
> As a crazy idea, doest this help?
> tsc->incarnation = 0
Had to move to another testhost and this seems to help. Will do more testing
once the original testsystems are accessible again. Thanks!
Olaf
signature.asc
Description: PGP signature
__
flight 106693 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106693/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-intel
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditio
On Wed, Mar 15, 2017 at 09:42:53AM -0500, Doug Goldstein wrote:
> On 3/15/17 9:38 AM, Daniel Kiper wrote:
> > On Wed, Mar 15, 2017 at 09:27:27AM -0500, Doug Goldstein wrote:
> >> On 3/15/17 6:35 AM, Daniel Kiper wrote:
> >>> On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
> >>>
> >>
flight 106678 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106678/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106650
test-armhf-armhf-libvirt 13
On Wed, Mar 15, 2017 at 12:56:50PM +, Roger Pau Monn? wrote:
> On Wed, Mar 15, 2017 at 08:42:04AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 15, 2017 at 12:07:28PM +, Roger Pau Monn? wrote:
> > > On Fri, Mar 10, 2017 at 10:28:43AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Fri,
On Wed, Mar 15, Olaf Hering wrote:
> On Wed, Mar 15, Andrew Cooper wrote:
> > As a crazy idea, doest this help?
> > tsc->incarnation = 0
This does indeed help. One system shows now the results below, which
means the performance goes down during migration (to localhost) and goes
back to normal aft
On 15/03/17 15:23, Olaf Hering wrote:
> On Wed, Mar 15, Olaf Hering wrote:
>
>> On Wed, Mar 15, Andrew Cooper wrote:
>>> As a crazy idea, doest this help?
>>> tsc->incarnation = 0
> This does indeed help. One system shows now the results below, which
> means the performance goes down during migrati
On 15/03/17 16:26, Andrew Cooper wrote:
> On 15/03/17 15:23, Olaf Hering wrote:
>> On Wed, Mar 15, Olaf Hering wrote:
>>
>>> On Wed, Mar 15, Andrew Cooper wrote:
As a crazy idea, doest this help?
tsc->incarnation = 0
>> This does indeed help. One system shows now the results below, which
>>> On 15.03.17 at 14:08, wrote:
> With that said, should I submit a new version of the original LOCK patch
> to have in the meantime (until the fix suggested by Andrew is
> implemented, and presumably to be reverted once it lands), or is it not
> worth xen-devel's extra time?
I think it would be
Hi Olaf,
On Wed, Mar 15, 2017 at 12:20:44PM +0100, Olaf Hering wrote:
> After reports about degraded performance after a PV domU was migrated
> from one dom0 to another it turned out that this issue happens with
> every version of Xen and every version of domU kernel.
>
> The used benchmark is 's
On 03/15/2017 11:26 AM, Andrew Cooper wrote:
> On 15/03/17 15:23, Olaf Hering wrote:
>> On Wed, Mar 15, Olaf Hering wrote:
>>
>>> On Wed, Mar 15, Andrew Cooper wrote:
As a crazy idea, doest this help?
tsc->incarnation = 0
>> This does indeed help. One system shows now the results below, w
>>> On 15.03.17 at 14:48, wrote:
> On 03/15/2017 09:31 AM, Jan Beulich wrote:
> On 15.03.17 at 14:24, wrote:
>>> On 03/15/2017 06:28 AM, Jan Beulich wrote:
@@ -3716,9 +3720,9 @@ x86_emulate(
break;
case 0x9b: /* wait/fwait */
-fic.insn_bytes =
On 15/03/17 15:43, Alan Robinson wrote:
> Hi Olaf,
>
> On Wed, Mar 15, 2017 at 12:20:44PM +0100, Olaf Hering wrote:
>> After reports about degraded performance after a PV domU was migrated
>> from one dom0 to another it turned out that this issue happens with
>> every version of Xen and every versi
1 - 100 of 167 matches
Mail list logo
