On Sun, Apr 01, 2018 at 10:29:58PM +0200, Olaf Hering wrote:
> Add an option to control when vTSC emulation will be activated for a
> domU with tsc_mode=default. Without such option each TSC access from
> domU will be emulated, which causes a significant perfomance drop for
> workloads that make us
Hi, Lars,
Chao and I will be traveling and thus will miss the meeting. From our side, we
propose continue to discuss the features which we didn't cover last time,
including SGX, SPP, PT-VMX and 288 vCPU.
Best Regards
John Ji
-Original Message-
From: George Dunlap [mailto:george.dun
On Sun, Apr 01, Wei Liu wrote:
> No. That's a bug in our build system.
Thanks. For some reason only gcc48-4.8.3.rpm from SLE_11 is affected,
not gcc43-4.3.4.rpm from SLE_11 nor gcc48-4.8.5.rpm from SLE_12.
This fixes my packages for the time being:
sed -i '/ stubdom install-grub/d' Makefile
Olaf
On 2018/3/27 16:52, Jan Beulich wrote:
On 27.03.18 at 06:52, wrote:
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. It's not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20
On Mon, Apr 02, 2018 at 11:40:54AM +0200, Olaf Hering wrote:
> On Sun, Apr 01, Wei Liu wrote:
>
> > No. That's a bug in our build system.
>
> Thanks. For some reason only gcc48-4.8.3.rpm from SLE_11 is affected,
> not gcc43-4.3.4.rpm from SLE_11 nor gcc48-4.8.5.rpm from SLE_12.
> This fixes my pa
Am Mon, 2 Apr 2018 10:44:23 +0100
schrieb Wei Liu :
> I suppose you hit some sort of compile error because pv-grub has rotten?
A post-build check scans the build log for warnings. Some of them are seen as
fatal, and the otherwise successful build is marked as FAIL, no rpm package is
provided. S
On 03/27/2018 03:48 PM, Marc Zyngier wrote:
On 27/03/18 10:07, Manish Jaggi wrote:
This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler
Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. Thi
On 04/02/2018 04:33 PM, Manish Jaggi wrote:
On 03/27/2018 03:48 PM, Marc Zyngier wrote:
On 27/03/18 10:07, Manish Jaggi wrote:
This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler
Add a handler for writing the
This patch set is part of a set of patches that together allow containment
of unrecoverable AER errors from PCIe devices assigned to guests in
passthrough mode. The containment is achieved by forcibly removing the
erring PCIe device from the guest.
The original xen-pciback patch corresponding to t
When a guest is created, register the AER event handler to handle the
AER errors. When an AER error occurs, the handler will forcibly remove
the erring PCIe device from the guest.
Signed-off-by: Venu Busireddy
Signed-off-by: Wim Ten Have
---
tools/libxl/libxl_create.c | 11 +--
tools/li
Implement the callback function to handle unrecoverable AER errors, and
also the public APIs that can be used to register/unregister the handler.
When an AER error occurs, the handler will forcibly remove the erring
PCIe device from the guest.
Signed-off-by: Venu Busireddy
---
tools/libxl/libxl.
flight 121686 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
119227
Tests w
flight 121682 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 121272
From: Bob Liu
The current VBD layer reserves buffer space for each attached device based on
three statically configured settings which are read at boot time.
* max_indirect_segs: Maximum amount of segments.
* max_ring_page_order: Maximum order of pages to be used for the shared ring.
* max_que
Hi!
This patch allows dynamic reconfiguration of the three different parameters
that an Xen blkfront driver initially negotiates:
* max_indirect_segs: Maximum amount of segments.
* max_ring_page_order: Maximum order of pages to be used for the shared ring.
* max_queues: Maximum of queues(ring
flight 121679 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121679/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
test-amd64-i386-lib
flight 121706 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754
build-i386-rumprun
flight 121700 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121700/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub broken in 121444
test-a
flight 121704 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121704/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 broken in 121358
Tests
flight 121710 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121710/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5b91bf82c67b586b9588cbe4bbffa1588f6b5926
baseline version:
ovmf 9c7d0d499296e444e39e9
flight 121707 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121707/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 121380
test-armhf-armhf-libvirt 14 saveresto
flight 121705 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121705/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 120095
test-amd64-amd64-
ping
On 03/27/2018 08:41 AM, Oleksandr Andrushchenko wrote:
Hi, Konrad!
Could you please review?
Thank you,
Oleksandr
On 03/21/2018 09:25 AM, Oleksandr Andrushchenko wrote:
On 03/21/2018 09:20 AM, Takashi Iwai wrote:
On Wed, 21 Mar 2018 08:15:36 +0100,
Oleksandr Andrushchenko wrote:
On 03/
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.
Signed-off-by: Ma
From: Boris Ostrovsky
Signed-off-by: Boris Ostrovsky
Signed-off-by: Maran Wilson
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Roger Pau Monné
Cc: Boris Ostrovsky
Cc: Maran Wilson
---
Changes in v5:
* Fix calculation of start_info_size (and move it from under
"if(!dom->device_model)"
* Rebase
---
From: Boris Ostrovsky
Since hvm_start_info has now been expanded to include memory map (i.e.
e820) we need to know size of this map by the time we create
dom->start_info_seg in alloc_magic_pages_hvm().
To do so we have to call libxl__arch_domain_construct_memmap() earlier,
before xc_dom_build_im
From: Boris Ostrovsky
We will later copy it to hvm_start_info.
(Also remove stale comment claming that xc_dom_image.start_info_seg is
only used for HVMlite guests)
Signed-off-by: Boris Ostrovsky
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Roger Pau Monné
Cc: Boris Ostrovsky
Cc: Maran Wilson
---
C
Here is the patch series for updating the canonical definition of the
hvm_start_info struct corresponding to the discussion happening on the
linux-kernel and kvm mailing lists regarding Qemu/KVM use of the PVH
entry point:
KVM: x86: Allow Qemu/KVM to use PVH entry point
https://lkml.org/lkml
flight 121711 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121711/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 broken
Tests which are
29 matches
Mail list logo
