Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

>>> On 23.01.18 at 18:43, wrote: >> Yet you'll need to provide the kernel messages > > I attached a console log "xen-console-log.txt". > > Here, Xen crash even without the "dom0_mem=1G,max:1G" option : Xen doesn't crash at all. It's the Dom0 kernel which panics, but the

[Xen-devel] [linux-linus test] 118283: regressions - FAIL

flight 118283 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/118283/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 118250

Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:

>>> On 24.01.18 at 01:47, wrote: > On Tue, 23 Jan 2018, Jan Beulich wrote: >> >>> On 23.01.18 at 01:41, wrote: >> > On 23/01/2018 00:38, Stefano Stabellini wrote: >> >> On Tue, 23 Jan 2018, Andrew Cooper wrote: >> >>> On 22/01/2018 23:48,

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

>>> On 23.01.18 at 18:33, wrote: > Well at very least there should be something in the boot scrool that > says, "Enabling Xen Pagetable protection (XPTI) for PV guests" or > something. (That goes for the current round of XPTI as well really.) And indeed I have this on

[Xen-devel] [PATCH AUTOSEL for 4.14 098/100] x86/xen: Support early interrupts in xen pv guests

From: Juergen Gross [ Upstream commit 42b3a4cb5609de757f5445fcad18945ba9239a07 ] Add early interrupt handlers activated by idt_setup_early_handler() to the handlers supported by Xen pv guests. This will allow for early WARN() calls not crashing the guest. Suggested-by: Andy

[Xen-devel] pvscsi is not supported by xl command

Hi Juergen, Would you please let me know if pvscsi is still supported by the most recent xen, as 'vscsi' is not supported in domU config file and scsi-attach/scsi-detach are not supported by xl command. Are scsi-attach/scsi-detach still on the roadmap and will be added to xl in the future, or

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

flight 118281 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/118281/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 118174

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

On 01/18/2018 05:33 AM, Wei Liu wrote: > On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote: >> Wei, >> >> On 01/12/17 15:14, Juergen Gross wrote: >>> Instead of locating the RSDP table below 1MB put it just below 4GB >>> like the rest of the ACPI tables in case of PVH guests. This will

Re: [Xen-devel] [PATCH v2 3/3] drop "domain_" prefix from struct domain's dirty CPU mask

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, January 23, 2018 6:17 PM > > It being a field of struct domain is sufficient to recognize its > purpose. > > Signed-off-by: Jan Beulich > Reviewed-by: Wei Liu > Reviewed-by: George Dunlap

Re: [Xen-devel] Xen fails to boot inside QEMU on x86, no VMX:

On Tue, 23 Jan 2018, Jan Beulich wrote: > >>> On 23.01.18 at 01:41, wrote: > > On 23/01/2018 00:38, Stefano Stabellini wrote: > >> On Tue, 23 Jan 2018, Andrew Cooper wrote: > >>> On 22/01/2018 23:48, Stefano Stabellini wrote: > Hi all, > > Running Xen

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

flight 118279 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/118279/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail REGR. vs. 117197 Tests which

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

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

Re: [Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

On 23/01/18 02:19, Boris Ostrovsky wrote: > > > On 01/22/2018 07:17 PM, Andrew Cooper wrote: >> On 22/01/2018 22:27, Boris Ostrovsky wrote: >>> On 01/19/2018 08:36 AM, Andrew Cooper wrote: On 19/01/18 11:43, Jan Beulich wrote: >> @@ -99,6 +106,10 @@ UNLIKELY_END(realmode) >>  

Re: [Xen-devel] [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On 12 January 2018 at 11:24, Daniel Kiper wrote: > Hi Ard, > > On Thu, Jan 11, 2018 at 12:51:07PM +, Ard Biesheuvel wrote: >> On 9 January 2018 at 14:22, Daniel Kiper wrote: >> > Hi, >> > >> > Initialize UEFI secure boot state during dom0

[Xen-devel] [examine test] 118286: tolerable ALL FAIL

flight 118286 examine real [real] http://logs.test-lab.xenproject.org/osstest/logs/118286/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: examine-laxton1 2 hosts-allocatebroken blocked in 116480 examine-pinot02

[Xen-devel] [seabios test] 118280: regressions - FAIL

flight 118280 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/118280/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539 Tests which did not

Re: [Xen-devel] I only see one CPU core on Xen when booted via grub

On Tue, Jan 23, 2018 at 01:03:04PM +0100, msd+xen-de...@msd.im wrote: > >I need at least GRUB2 version, Xen version > > ``` > # apt-cache policy grub2-common > grub2-common: > Installé : 2.02~beta3-5 > Candidat : 2.02~beta3-5 > Table de version : > *** 2.02~beta3-5 500 > 500

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

On Tue, Jan 23, 2018 at 10:16:45AM -0700, Jan Beulich wrote: > >>> Wei Liu 01/23/18 4:44 PM >>> > On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote: > >> --- a/xen/include/public/domctl.h > >> +++ b/xen/include/public/domctl.h > >> @@ -38,7 +38,7 @@ > >>

[Xen-devel] [libvirt test] 118278: tolerable all pass - PUSHED

flight 118278 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/118278/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118237 test-armhf-armhf-libvirt 14

Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

Yet you'll need to provide the kernel messages I attached a console log "xen-console-log.txt". Here, Xen crash even without the "dom0_mem=1G,max:1G" option : ``` # cat /boot/efi/EFI/xen/xen.cfg [global] default=xen [xen] options=loglvl=all com1=115200,8n1 console=com1,vga kernel=vmlinuz

Re: [Xen-devel] [PATCH v4] kexec-tools: Perform run-time linking of libxenctrl.so

Daniel, I've implemented your feedback and posted the following: [PATCH v1] kexec-tools: Tweak run-time handling of libxenctrl.so Regards, eric On 01/18/2018 05:55 AM, Daniel Kiper wrote: On Wed, Jan 17, 2018 at 10:39:01AM -0600, Eric DeVolder wrote: When kexec is utilized in a Xen

Re: [Xen-devel] [PATCH] x86: slightly reduce Meltdown band-aid overhead

On 01/18/2018 03:39 PM, Jan Beulich wrote: > I'm not sure why I didn't do this right away: By avoiding to make any > of the cloned directmap PTEs global, there's no need to fiddle with > CR4.PGE on any of the entry paths. Only the exit paths need to flush > global mappings. > > The reduced

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 01/23/2018 04:56 PM, Juergen Gross wrote: > On 23/01/18 17:45, George Dunlap wrote: >> On 01/22/2018 06:39 PM, Andrew Cooper wrote: >>> Juergen: you're now adding a LTR into the context switch path which >>> tends to be very slow.  I.e. As currently presented, this series >>> necessarily has a

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

>>> Wei Liu 01/23/18 4:44 PM >>> On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote: >> --- a/xen/include/public/domctl.h >> +++ b/xen/include/public/domctl.h >> @@ -38,7 +38,7 @@ >> #include "hvm/save.h" >> #include "memory.h" >> >> -#define

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 23/01/18 17:45, George Dunlap wrote: > On 01/22/2018 06:39 PM, Andrew Cooper wrote: >> Juergen: you're now adding a LTR into the context switch path which >> tends to be very slow.  I.e. As currently presented, this series >> necessarily has a higher runtime overhead than Jan's XPTI. > > So

Re: [Xen-devel] [RFC v4 3/8] xen/linux_compat: Add a Linux compat header

On Mon, Dec 18, 2017 at 08:16:58PM -0700, Sameer Goel wrote: > For porting files directly from Linux it is useful to have a function mapping > definitions from Linux to Xen. This file adds common API functions and > other defines that are needed for porting arm SMMU drivers. It would be good that

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 01/22/2018 06:39 PM, Andrew Cooper wrote: > On 22/01/18 16:51, Jan Beulich wrote: > On 22.01.18 at 16:00, wrote: >>> On 22/01/18 15:48, Jan Beulich wrote: >>> On 22.01.18 at 15:38, wrote: > On 22/01/18 15:22, Jan Beulich wrote: > On

Re: [Xen-devel] [RFC v4 3/8] xen/linux_compat: Add a Linux compat header

On Mon, Dec 18, 2017 at 08:16:58PM -0700, Sameer Goel wrote: > For porting files directly from Linux it is useful to have a function mapping > definitions from Linux to Xen. This file adds common API functions and > other defines that are needed for porting arm SMMU drivers. > > Signed-off-by:

Re: [Xen-devel] [RFC v4 1/8] Port WARN_ON_ONCE() from Linux

On Mon, Dec 18, 2017 at 08:16:56PM -0700, Sameer Goel wrote: > Port WARN_ON_ONCE macro from Linux. > > Signed-off-by: Sameer Goel > --- > xen/include/xen/lib.h | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/xen/include/xen/lib.h

Re: [Xen-devel] [PATCH] x86/shutdown: Use ACPI reboot method for Dell PowerEdge R740

On 01/22/2018 12:29 PM, Jan Beulich wrote: On 19.01.18 at 17:57, wrote: --- a/xen/arch/x86/shutdown.c +++ b/xen/arch/x86/shutdown.c @@ -511,6 +511,15 @@ static struct dmi_system_id __initdata reboot_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "Latitude

Re: [Xen-devel] [PATCH v5] x86: relocate pvh_info

On Tue, Jan 23, 2018 at 03:18:22PM +, Andrew Cooper wrote: > On 23/01/18 15:13, Wei Liu wrote: > > @@ -226,14 +259,27 @@ static multiboot_info_t *mbi2_reloc(u32 mbi_in) > > return mbi_out; > > } > > > > -multiboot_info_t __stdcall *reloc(u32 mb_magic, u32 mbi_in, u32 trampoline) > >

Re: [Xen-devel] [PATCH v4 1/6] xen/mm: Make xenmem_add_to_physmap global

On Tue, Jan 23, 2018 at 03:22:41PM +, Ross Lagerwall wrote: > Make it global in preparation to be called by a new dmop. > > Signed-off-by: Ross Lagerwall > Reviewed-by: Paul Durrant > Acked-by: Jan Beulich Acked-by:

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

On Tue, Jan 23, 2018 at 03:47:52PM +, Ross Lagerwall wrote: > On 01/23/2018 03:44 PM, Wei Liu wrote: > > On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote: > > > Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has > > > been replaced by a dmop. Change

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

On 01/23/2018 03:44 PM, Wei Liu wrote: On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote: Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so that it is only defined when

Re: [Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

On Tue, Jan 23, 2018 at 03:22:46PM +, Ross Lagerwall wrote: > Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has > been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so > that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and > have it call the

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

Hi Sameer, On 19/12/17 03:17, Sameer Goel wrote: Pull common defines for SMMU drivers in a local header. I was expected to see this patch before SMMUv3 is added. But I am ok with that too. However, if you want to do some renaming this should be done separately. So it will be easier to

Re: [Xen-devel] [RFC v4 7/8] xen/smmu: Add a new config define for legacy SMMU

Hi Sameer, On 19/12/17 03:17, Sameer Goel wrote: Add a new config item to control compilation for legacy arm SMMU. Signed-off-by: Sameer Goel --- xen/drivers/passthrough/arm/Kconfig | 6 ++ xen/drivers/passthrough/arm/Makefile | 2 +- 2 files changed, 7

[Xen-devel] [PATCH v4 6/6] x86/domctl: Remove XEN_DOMCTL_pin_mem_cacheattr

Remove the implementation of XEN_DOMCTL_pin_mem_cacheattr since it has been replaced by a dmop. Change xc_domain_pin_memory_cacheattr() so that it is only defined when XC_WANT_COMPAT_DEVICEMODEL_API is set and have it call the new dmop. Leave the definitions of XEN_DOMCTL_MEM_CACHEATTR_* since

[Xen-devel] [PATCH v4 4/6] tools: libxendevicemodel: Provide xendevicemodel_relocate_memory

Signed-off-by: Ross Lagerwall Acked-by: Ian Jackson Reviewed-by: Paul Durrant --- Changed in v4: * Rename add_to_physmap to relocate_memory to match hypervisor interface. Changed in v3: * Match width of size with

[Xen-devel] [PATCH v4 0/6] Add dmops to allow use of VGA with restricted QEMU

The recently added support for restricting QEMU prevents use of the VGA console. This series addresses that by adding a couple of new dmops. A corresponding patch for QEMU is needed to make use of the new dmops. Changes in v4: * Rename add_to_physmap -> relocate_memory. * Use continutation

[Xen-devel] [PATCH v4 5/6] tools: libxendevicemodel: Provide xendevicemodel_pin_memory_cacheattr

Signed-off-by: Ross Lagerwall Acked-by: Ian Jackson Reviewed-by: Paul Durrant --- tools/libs/devicemodel/core.c | 19 +++ tools/libs/devicemodel/include/xendevicemodel.h | 14

[Xen-devel] [PATCH v4 3/6] x86/hvm: Provide XEN_DMOP_pin_memory_cacheattr

Provide XEN_DMOP_pin_memory_cacheattr to allow a deprivileged QEMU to pin the caching type of RAM after moving the VRAM. It is equivalent to XEN_DOMCTL_pin_memory_cacheattr. Signed-off-by: Ross Lagerwall Reviewed-by: Paul Durrant Reviewed-by:

[Xen-devel] [PATCH v4 1/6] xen/mm: Make xenmem_add_to_physmap global

Make it global in preparation to be called by a new dmop. Signed-off-by: Ross Lagerwall Reviewed-by: Paul Durrant Acked-by: Jan Beulich --- xen/common/memory.c | 5 ++--- xen/include/xen/mm.h | 3 +++ 2 files changed, 5

Re: [Xen-devel] [PATCH v2] libxc: don't fail domain creation when unpacking initrd fails

On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote: > At least Linux kernels have been able to work with gzip-ed initrd for > quite some time; initrd compressed with other methods aren't even being > attempted to unpack. Furthermore the unzip-ing routine used here isn't > capable of

[Xen-devel] [PATCH v8 01/11] vpci: introduce basic handlers to trap accesses to the PCI config space

This functionality is going to reside in vpci.c (and the corresponding vpci.h header), and should be arch-agnostic. The handlers introduced in this patch setup the basic functionality required in order to trap accesses to the PCI config space, and allow decoding the address and finding the

[Xen-devel] [PATCH v8 04/11] pci: split code to size BARs from pci_add_device

So that it can be called from outside in order to get the size of regular PCI BARs. This will be required in order to map the BARs from PCI devices into PVH Dom0 p2m. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich --- Changes since v7: - Do not

[Xen-devel] [PATCH v8 06/11] xen: introduce rangeset_consume_ranges

This function allows to iterate over a rangeset while removing the processed regions. This will be used in order to split processing of large memory areas when mapping them into the guest p2m. Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu ---

[Xen-devel] [PATCH v8 08/11] x86/pt: mask MSI vectors on unbind

When a MSI device with per-vector masking capabilities is detected or added to Xen all the vectors are masked when initializing it. This implies that the first time the interrupt is bound to a domain it's masked. This however only applies to the first time the interrupt is bound because neither

[Xen-devel] [PATCH v8 03/11] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

So that MMCFG regions not present in the MCFG ACPI table can be added at run time by the hardware domain. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper ---

[Xen-devel] [PATCH v8 00/11] vpci: PCI config space emulation

Hello, The following series contain an implementation of handlers for the PCI configuration space inside of Xen. This allows Xen to detect accesses to the PCI configuration space and react accordingly. Why is this needed? IMHO, there are two main points of doing all this emulation inside of Xen,

[Xen-devel] [PATCH v2] x86/compat: fix compilation errors with clang 6

The following errors are generated when compiling Xen with clang 6: In file included from x86_64/asm-offsets.c:9: In file included from /root/src/xen/xen/include/xen/sched.h:8: In file included from /root/src/xen/xen/include/xen/shared.h:6: In file included from

Re: [Xen-devel] [PATCH] x86/compat: fix compilation errors with clang 6

On Tue, Jan 23, 2018 at 06:34:44AM -0700, Jan Beulich wrote: > >>> On 23.01.18 at 13:38, wrote: > > Fix this by using pragma push/pop in order to store the current pragma > > value in the compiler stack and later restoring it. > > For Linux this is fine all the way back to

[Xen-devel] [PATCH] x86: avoid insn patching on fully async entry paths

As long as our patching logic isn't safe against concurrently occurring NMI or #MC we should avoid patching those paths. For sanity's sake also avoid this on the #DF entry path. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@

Re: [Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

>>> On 23.01.18 at 12:18, wrote: > As explained on the Xen_EFI wiki page, I have added a line "options=" > into my file "/boot/efi/EFI/xen/xen.cfg" : > > ``` > # cat /boot/efi/EFI/xen/xen.cfg : > [global] > default=xen > > [xen] > options=dom0_mem=1G,max:1G >

Re: [Xen-devel] [PATCH] x86/compat: fix compilation errors with clang 6

>>> On 23.01.18 at 13:38, wrote: > Fix this by using pragma push/pop in order to store the current pragma > value in the compiler stack and later restoring it. For Linux this is fine all the way back to gcc 4.1 afaict, but what about other OSes using gcc? In 4.1, only

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 23/01/18 12:45, Andrew Cooper wrote: > On 23/01/18 10:10, Juergen Gross wrote: >> On 23/01/18 10:31, Jan Beulich wrote: >> On 23.01.18 at 10:24, wrote: On 23/01/18 09:53, Jan Beulich wrote: On 23.01.18 at 07:34, wrote: >> On 22/01/18

Re: [Xen-devel] [PATCH v4 3/4] x86emul: Support vaes insns

>>> On 23.01.18 at 13:56, wrote: > I did below TEMP patch, please help me check whther this patch meet your > requirements, many thanks! Looks reasonable at the first glance, provided you add a proper fall-through annotation to the new fall-through. Jan

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey, Hi! On Mon, 2018-01-22 at 18:39 +, Andrew Cooper wrote: > > > > On 22.01.18 at 15:38, wrote: > > > I'm quite sure the performance will be much better as it doesn't > > > require > > > per physical cpu L4 page tables, but

Re: [Xen-devel] [PATCH v2] libxc: don't fail domain creation when unpacking initrd fails

>>> On 23.01.18 at 11:55, wrote: > On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote: >> At least Linux kernels have been able to work with gzip-ed initrd for >> quite some time; initrd compressed with other methods aren't even being >> attempted to unpack.

[Xen-devel] [linux-linus test] 118276: regressions - FAIL

flight 118276 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/118276/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 118250 Tests which

Re: [Xen-devel] [PATCH v4] x86: relocate pvh_info

>>> On 23.01.18 at 12:44, wrote: > On Tue, Jan 23, 2018 at 02:14:51AM -0700, Jan Beulich wrote: >> >>> On 22.01.18 at 19:31, wrote: >> > On Mon, Jan 22, 2018 at 06:19:43PM +, Andrew Cooper wrote: >> >> On 22/01/18 18:17, Wei Liu wrote: >> >> > So you

Re: [Xen-devel] [PATCH v4 3/4] x86emul: Support vaes insns

On Thu, Jan 18, 2018 at 07:13:21AM -0700, Jan Beulich wrote: > >>> On 03.01.18 at 09:26, wrote: > > The previous aes insns only support legacy and AVX128. > > Icelake added AVX256 support. > > Same remark here as for the pclmulqdq patch. > > > Signed-off-by: Yang Zhong

[Xen-devel] [PATCH] x86/compat: fix compilation errors with clang 6

The following errors are generated when compiling Xen with clang 6: In file included from x86_64/asm-offsets.c:9: In file included from /root/src/xen/xen/include/xen/sched.h:8: In file included from /root/src/xen/xen/include/xen/shared.h:6: In file included from

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

Hi Roger, On 23/01/18 12:10, Roger Pau Monné wrote: On Tue, Jan 23, 2018 at 11:44:30AM +, Julien Grall wrote: Hi Roger, On 23/01/18 11:39, Roger Pau Monné wrote: On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote: diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

On Tue, Jan 23, 2018 at 11:44:30AM +, Julien Grall wrote: > Hi Roger, > > On 23/01/18 11:39, Roger Pau Monné wrote: > > On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote: > > > diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h > > > index e2019b02a3..a103e49089 100644

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

On Tue, Jan 23, 2018 at 01:52:50PM +0200, Oleksandr Tyshchenko wrote: > Hi Mirela, > > Just some remarks regarding the scope of work: > > +In addition, the following have to be implemented: > +* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call) > +* Suspend/resume Xen (triggered by

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

Hi Mirela, Just some remarks regarding the scope of work: +In addition, the following have to be implemented: +* Suspend/resume vCPU (triggered by vSYSTEM_SUSPEND call) +* Suspend/resume Xen (triggered by vSYSTEM_SUSPEND called by Dom0), including: + * Disable wathdog on suspend, enable it

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 23/01/18 10:10, Juergen Gross wrote: > On 23/01/18 10:31, Jan Beulich wrote: > On 23.01.18 at 10:24, wrote: >>> On 23/01/18 09:53, Jan Beulich wrote: >>> On 23.01.18 at 07:34, wrote: > On 22/01/18 19:39, Andrew Cooper wrote: >> One of my

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

Hi Roger, On 23/01/18 11:39, Roger Pau Monné wrote: On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote: diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h index e2019b02a3..a103e49089 100644 --- a/xen/include/xen/bitops.h +++ b/xen/include/xen/bitops.h @@ -223,7 +223,7

Re: [Xen-devel] [PATCH v4] x86: relocate pvh_info

On Tue, Jan 23, 2018 at 02:14:51AM -0700, Jan Beulich wrote: > >>> On 22.01.18 at 19:31, wrote: > > On Mon, Jan 22, 2018 at 06:19:43PM +, Andrew Cooper wrote: > >> On 22/01/18 18:17, Wei Liu wrote: > >> > So you want reloc.o to contain pvh_info_reloc unconditionally? > >>

Re: [Xen-devel] [RFC v4 4/8] passthrough/arm: Modify SMMU driver to use generic device definition

Hi Sameer, On 19/12/17 03:16, Sameer Goel wrote: Modify the SMMU code to use generic device instead of dt_device_node for functions that can be used for ACPI based systems too. Signed-off-by: Sameer Goel Acked-by: Julien Grall Cheers, ---

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

On Mon, Dec 18, 2017 at 08:16:57PM -0700, Sameer Goel wrote: > diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h > index e2019b02a3..a103e49089 100644 > --- a/xen/include/xen/bitops.h > +++ b/xen/include/xen/bitops.h > @@ -223,7 +223,7 @@ static inline __u32 ror32(__u32 word,

Re: [Xen-devel] [RFC v4 2/8] xen/bitops: Rename LOG_2 to ilog2

Hi Sameer, On 19/12/17 03:16, Sameer Goel wrote: Changing the name of the macro from LOG_2 to ilog2.This makes the function name similar to its Linux counterpart. Since, this is not used in mutiple places, so the code churn is minimal. s/mutiple/multiple/ This change helps in porting

Re: [Xen-devel] [RFC v4 1/8] Port WARN_ON_ONCE() from Linux

Hi Sameer, On 19/12/17 03:16, Sameer Goel wrote: Port WARN_ON_ONCE macro from Linux. Signed-off-by: Sameer Goel --- xen/include/xen/lib.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h index

Re: [Xen-devel] I only see one CPU core on Xen when booted via grub

On Tue, Jan 23, 2018 at 03:09:19AM -0700, Jan Beulich wrote: > >>> On 23.01.18 at 10:39, wrote: > >> ... your report is very likely duplicating earlier ones where the > >> ACPI root point cannot be found without it being properly > >> propagated through by grub from EFI to

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

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

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 23/01/18 08:36, Jan Beulich wrote: On 22.01.18 at 20:02, wrote: >> On 22/01/18 18:48, George Dunlap wrote: >>> On 01/22/2018 06:39 PM, Andrew Cooper wrote: Jan: As to the things not covered by the current XPTI, hiding most of the .text section is

[Xen-devel] [Xen EFI] Impossible to limit the dom0 memory

Hi, I have configured Xen to boot directly from EFI (with `efibootmgr`). As explained on the Xen_EFI wiki page, I have added a line "options=" into my file "/boot/efi/EFI/xen/xen.cfg" : ``` # cat /boot/efi/EFI/xen/xen.cfg : [global] default=xen [xen] options=dom0_mem=1G,max:1G

Re: [Xen-devel] [PATCH v2 for-next 3/9] gcov: rename sysctl and functions

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 for-next 3/9] gcov: rename sysctl and functions"): > On 09.11.17 at 12:13, wrote: > > Change gcov to cov (for internal interfaces) or coverage (for the > > public ones). ... > Btw., I still have this (and subsequent patches in

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 01/22/2018 07:02 PM, Andrew Cooper wrote: > On 22/01/18 18:48, George Dunlap wrote: >> On 01/22/2018 06:39 PM, Andrew Cooper wrote: >>> On 22/01/18 16:51, Jan Beulich wrote: >>> On 22.01.18 at 16:00, wrote: > On 22/01/18 15:48, Jan Beulich wrote: > On 22.01.18

Re: [Xen-devel] [PATCH v2 1/3] replace vCPU's dirty CPU mask by numeric ID

Hi Jan, On 23/01/18 10:12, Jan Beulich wrote: At most one bit can be set in the masks, so especially on larger systems it's quite a bit of unnecessary memory and processing overhead to track the information as a mask. Store the numeric ID of the respective CPU instead, or VCPU_CPU_CLEAN if no

Re: [Xen-devel] [PATCH v2 3/3] drop "domain_" prefix from struct domain's dirty CPU mask

Hi Jan, On 23/01/18 10:16, Jan Beulich wrote: It being a field of struct domain is sufficient to recognize its purpose. Signed-off-by: Jan Beulich Reviewed-by: Wei Liu Reviewed-by: George Dunlap Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH v2] libxc: don't fail domain creation when unpacking initrd fails

On Mon, Dec 04, 2017 at 05:46:41AM -0700, Jan Beulich wrote: > At least Linux kernels have been able to work with gzip-ed initrd for > quite some time; initrd compressed with other methods aren't even being > attempted to unpack. Furthermore the unzip-ing routine used here isn't > capable of

Re: [Xen-devel] [PATCH v7 for-next 12/12] vpci/msix: add MSI-X handlers

On Wed, Dec 20, 2017 at 09:13:34AM -0700, Jan Beulich wrote: > >>> On 18.10.17 at 13:40, wrote: > > +if ( new_enabled && !new_masked && (!msix->enabled || msix->masked) ) > > +{ > > +for ( i = 0; i < msix->max_entries; i++ ) > > +{ > > +if

[Xen-devel] [PATCH 3/4] x86: re-organize toggle_guest_*()

toggle_guest_mode() is only ever being called for 64-bit PV vCPU-s - replace the 32-bit PV conditional by an ASSERT(). Introduce a local helper without 32-bit PV conditional, to be used by both pre-existing functions. Signed-off-by: Jan Beulich --- a/xen/arch/x86/pv/domain.c

[Xen-devel] [PATCH 2/4] x86: eliminate most XPTI entry/exit code when it's not in use

Introduce a synthetic feature flag to use alternative instruction patching to NOP out all code on entry/exit paths other than those involved in NMI/#MC handling (the patching logic can't properly handle those paths yet). Having NOPs here is generally better than using conditional branches. Also

[Xen-devel] [PATCH 1/4] x86: remove CR reads from exit-to-guest path

CR3 is - during normal operation - only ever loaded from v->arch.cr3, so there's no need to read the actual control register. For CR4 we can generally use the cached value on all synchronous entry end exit paths. Signed-off-by: Jan Beulich ---

[Xen-devel] [PATCH 0/4] x86: reduce Meltdown band-aid overhead a little further

Prereq: x86: slightly reduce Meltdown band-aid overhead (https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01609.html) The overall effect of this series is smaller than that of the single patch above (up to 1% in my measurements, but again instead of the almost 40% loss of

Re: [Xen-devel] [PATCH v2 1/3] replace vCPU's dirty CPU mask by numeric ID

On 23/01/2018 10:12, Jan Beulich wrote: > @@ -803,6 +803,11 @@ static inline int vcpu_runnable(struct v > atomic_read(>domain->pause_count)); > } > > +static inline bool vcpu_cpu_dirty(const struct vcpu *v) > +{ Oh - one extra through.  BUILD_BUG_ON(NR_CPUS >= VCPU_CPU_CLEAN) ?

[Xen-devel] Ping: [PATCH v2] libxc: don't fail domain creation when unpacking initrd fails

>>> On 04.12.17 at 13:46, wrote: > At least Linux kernels have been able to work with gzip-ed initrd for > quite some time; initrd compressed with other methods aren't even being > attempted to unpack. Furthermore the unzip-ing routine used here isn't > capable of dealing with various forms of

Re: [Xen-devel] [PATCH RFC v2 02/12] x86: don't use hypervisor stack size for dumping guest stacks

On 23/01/18 11:11, Jan Beulich wrote: On 23.01.18 at 10:58, wrote: >> On 23/01/18 10:26, Jan Beulich wrote: >> On 22.01.18 at 13:32, wrote: show_guest_stack() and compat_show_guest_stack() stop dumping the stack of the guest whenever its

[Xen-devel] [PATCH v2 2/3] x86: avoid explicit TLB flush when saving exec state

Now that it's obvious that only a single dirty CPU can exist for a vCPU, it becomes clear that flush_mask() doesn't need to be invoked when sync_local_execstate() was already run. And with the IPI handler clearing FLUSH_TLB from the passed flags anyway if __sync_local_execstate() returns true, it

[Xen-devel] [PATCH v2 1/3] replace vCPU's dirty CPU mask by numeric ID

At most one bit can be set in the masks, so especially on larger systems it's quite a bit of unnecessary memory and processing overhead to track the information as a mask. Store the numeric ID of the respective CPU instead, or VCPU_CPU_CLEAN if no dirty state exists. Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH RFC v2 02/12] x86: don't use hypervisor stack size for dumping guest stacks

>>> On 23.01.18 at 10:58, wrote: > On 23/01/18 10:26, Jan Beulich wrote: > On 22.01.18 at 13:32, wrote: >>> show_guest_stack() and compat_show_guest_stack() stop dumping the >>> stack of the guest whenever its virtual address reaches the same >>> alignment

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 23/01/18 10:31, Jan Beulich wrote: On 23.01.18 at 10:24, wrote: >> On 23/01/18 09:53, Jan Beulich wrote: >> On 23.01.18 at 07:34, wrote: On 22/01/18 19:39, Andrew Cooper wrote: > One of my concerns is that this patch series moves further

Re: [Xen-devel] I only see one CPU core on Xen when booted via grub

>>> On 23.01.18 at 10:39, wrote: >> ... your report is very likely duplicating earlier ones where the >> ACPI root point cannot be found without it being properly >> propagated through by grub from EFI to Xen. Iirc the only >> way around that is to chainload xen.efi, if the

[Xen-devel] [PATCH v2 0/3] misc flush and dirty-mask related adjustments

1: replace vCPU's dirty CPU mask by numeric ID 2: x86: avoid explicit TLB flush when saving exec state 3: drop "domain_" prefix from struct domain's dirty CPU mask Signed-off-by: Jan Beulich --- v2: Addressing review comments - see individual patches.

Re: [Xen-devel] [PATCH RFC v2 02/12] x86: don't use hypervisor stack size for dumping guest stacks

On 23/01/18 10:26, Jan Beulich wrote: On 22.01.18 at 13:32, wrote: >> show_guest_stack() and compat_show_guest_stack() stop dumping the >> stack of the guest whenever its virtual address reaches the same >> alignment which is used for the hypervisor stacks. >> >> Remove this

[Xen-devel] [PATCH v3] x86/p2m: force return value checking of p2m_set_entry()

As XSAs 246 and 247 have shown, not doing so is rather dangerous. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper Acked-by: Kevin Tian --- v3: Make sure vm_event_cancel_slot() is called from the new error path in

Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

On 23/01/18 09:40, Jan Beulich wrote: On 23.01.18 at 06:50, wrote: >> On 22/01/18 17:51, Jan Beulich wrote: >>> But isn't that model having the same synchronization issues upon >>> guest L4 updates which Andrew was fighting with? >> >> I don't think so, as the number of

  1   2   >