[xen-unstable test] 149335: regressions - FAIL

flight 149335 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/149335/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-dom0pvh-xl-intel 18 guest-localmigrate/x10 fail REGR. vs. 149188 build-amd64-xs

Re: 4.13: import xen.lowlevel.xc fails with SystemError: bad call flags

On Thu, 2 Apr 2020 at 20:56, Andrew Cooper wrote: > > We've got a fix in staging > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e19b4b3b55f84e0cfcc02fe5d66965969a81c965 > > It hasn't been backported to the 4.13 stable tree yet. > > ~Andrew Bingo! I guess I must have missed that whe

Re: [PATCH v5 10/10] x86emul: support MCOMMIT

On 24/03/2020 12:37, Jan Beulich wrote: > The dependency on a new EFER bit implies that we need to set that bit > ourselves in order to be able to successfully invoke the insn. > > Also once again introduce the SVM related constants at this occasion. > > Signed-off-by: Jan Beulich > --- > RFC: The

[ovmf test] 149325: all pass - PUSHED

flight 149325 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/149325/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 4deef2d865efdc61d1a53ad7bd48f9dd42560b45 baseline version: ovmf e210fc130e5c9738909dc

Re: [PATCH v5 05/10] x86emul: support MOVDIR64B insn

On 24/03/2020 12:34, Jan Beulich wrote: > Introduce a new blk() hook, paralleling the rmw() on in certain way, but > being intended for larger data sizes, and hence its HVM intermediate > handling function doesn't fall back to splitting the operation if the > requested virtual address can't be mapp

Re: [PATCH 5/5] x86/p2m: use available local variable in guest_physmap_add_entry()

On 01/04/2020 12:40, Jan Beulich wrote: > The domain is being passed in - no need to obtain it from p2m->domain. > Also drop a pointless cast while touching this code anyway. > > Signed-off-by: Jan Beulich > > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -905,7 +905,7 @@ guest_ph

Re: [PATCH 4/5] x86/p2m: drop pointless nested variable from guest_physmap_add_entry()

On 01/04/2020 12:40, Jan Beulich wrote: > There's an outer scope rc already, and its use for the mem-sharing logic > does not conflict with its use elsewhere in the function. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper

Re: [PATCH 3/5] x86/p2m: make p2m_remove_page()'s parameters type-safe

On 01/04/2020 12:39, Jan Beulich wrote: > @@ -790,21 +789,23 @@ p2m_remove_page(struct p2m_domain *p2m, >&cur_order, NULL); > > if ( p2m_is_valid(t) && > - (!mfn_valid(_mfn(mfn)) || mfn + i != mfn_x(mfn_return)) ) > + (!

[linux-linus bisection] complete build-arm64-pvops

branch xen-unstable xenbranch xen-unstable job build-arm64-pvops testid kernel-build Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git *** Found and reproduced problem changeset *** Bug is in tr

Re: [PATCH 2/5] x86/p2m: don't assert that the passed in MFN matches for a remove

On 01/04/2020 12:39, Jan Beulich wrote: > guest_physmap_remove_page() gets handed an MFN from the outside, yet > takes the necessary lock to prevent further changes to the GFN <-> MFN > mapping itself. While some callers, in particular guest_remove_page() > (by way of having called get_gfn_query())

Re: [PATCH 1/5] x86/p2m: don't ignore p2m_remove_page()'s return value

On 01/04/2020 12:38, Jan Beulich wrote: > It's not very nice to return from guest_physmap_add_entry() after > perhaps already having made some changes to the P2M, but this is pre- > existing practice in the function, and imo better than ignoring errors. > > Take the liberty and replace an mfn_add()

Re: [Xen-devel] [PATCH 5/5] x86emul: disable FPU/MMX/SIMD insn emulation when !HVM

On 20/12/2019 16:01, Andrew Cooper wrote: >> Suggested-by: Andrew Cooper >> Signed-off-by: Jan Beulich >> --- >> I'll be happy to take suggestions allowing to avoid -Wno-unused-label. > I think I'm going to need a little while to figure out how this works. So, after having had an evening playing

[linux-5.4 test] 149311: regressions - FAIL

flight 149311 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/149311/ 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. 146121 Regressions w

Re: [PATCH] x86/HVM: expose VM assist hypercall

On 02/04/2020 08:46, Jan Beulich wrote: > In preparation for the addition of VMASST_TYPE_runstate_update_flag > commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled > the hypercall for Arm. I consider it not logical that it then isn't also > exposed to x86 HVM guests (with the s

Re: [PATCH v2] x86/PV: remove unnecessary toggle_guest_pt() overhead

On 20/12/2019 14:06, Jan Beulich wrote: > While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly > expensive (but still needed only for the toggle_guest_mode() path), the > effect of the latter on the exit-to-guest path is not insignificant. > Move the logic into toggle_guest_mode

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

(+Marc) Hi Stefano, On 02/04/2020 18:19, Stefano Stabellini wrote: On Wed, 1 Apr 2020, Julien Grall wrote: On 01/04/2020 01:57, Stefano Stabellini wrote: On Mon, 30 Mar 2020, Julien Grall wrote: Hi Stefano, On 30/03/2020 17:35, Stefano Stabellini wrote: On Sat, 28 Mar 2020, Julien Grall wr

Re: [PATCH v2 2/2] xen: credit2: fix credit reset happening too few times

> On Mar 19, 2020, at 12:12 AM, Dario Faggioli wrote: > > There is a bug in commit 5e4b4199667b9 ("xen: credit2: only reset > credit on reset condition"). In fact, the aim of that commit was to > make sure that we do not perform too many credit reset operations > (which are not super cheap, and

Re: [PATCH v2 1/2] xen: credit2: avoid vCPUs to ever reach lower credits than idle

> On Mar 19, 2020, at 12:11 AM, Dario Faggioli wrote: > > There have been report of stalls of guest vCPUs, when Credit2 was used. > It seemed like these vCPUs were not getting scheduled for very long > time, even under light load conditions (e.g., during dom0 boot). > > Investigations led to t

Re: [PATCH 4/4] x86/APIC: restrict certain messages to BSP

On 13/03/2020 09:26, Jan Beulich wrote: > All CPUs get an equal setting of EOI broadcast suppression; no need to > log one message per CPU, even if it's only in verbose APIC mode. > > Only the BSP is eligible to possibly get ExtINT enabled; no need to log > that it gets disabled on all APs, even if

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

On Wed, 1 Apr 2020, Julien Grall wrote: > On 01/04/2020 01:57, Stefano Stabellini wrote: > > On Mon, 30 Mar 2020, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 30/03/2020 17:35, Stefano Stabellini wrote: > > > > On Sat, 28 Mar 2020, Julien Grall wrote: > > > > > qHi Stefano, > > > > > > >

[OSSTEST PATCH 2/2] ts-logs-capture: Cope better with unbootable host (2)

shutdown_guests might conceivably fail due to a flaky host. In that case we want not to declare the job broken so ts-logs-capture most not fail. But in that case we should skip fishing in-guest logs out of guest fs's. Signed-off-by: Ian Jackson --- ts-logs-capture | 31 +++-

[OSSTEST PATCH 1/2] ts-logs-capture: Cope better with unbootable host

If we cannot ssh to the host to fish out its own logs, do not try to do any of the other log captures which involve ssh'ing to the host. This includes {fetch,extract}_logs_guest, which tolerated this situation - so then it's an optimisation. But it also includes shutdown_guests, which was introdu

[linux-linus test] 149306: regressions - FAIL

flight 149306 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/149306/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 149238 Regressions which a

Re: [PATCH] xen/x86: Use macro DIV_ROUND_UP

On 02/04/2020 16:53, Simran Singhal wrote: > Use the DIV_ROUND_UP macro to replace open-coded divisor calculation > (((n) + (d) - 1) /(d)) to improve readability. > > Signed-off-by: Simran Singhal Acked-by: Andrew Cooper

[PATCH] hvmloader: probe memory below 4G before allocation for OVMF

The area just below 4G where OVMF image is originally relocated is not necessarily a hole - it might contain pages preallocated by device model or the toolstack. By unconditionally populating on top of this memory the original pages are getting lost while still potentially foreign mapped in Dom0.

[PATCH] xen/x86: Use macro DIV_ROUND_UP

Use the DIV_ROUND_UP macro to replace open-coded divisor calculation (((n) + (d) - 1) /(d)) to improve readability. Signed-off-by: Simran Singhal --- xen/arch/x86/mm.c| 2 +- xen/arch/x86/tboot.c | 2 +- xen/arch/x86/x86_64/mm.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-

[PATCH v7 11/12] tools/libxc: remove xc_set_parameters()

There is no user of xc_set_parameters() left, so remove it. Signed-off-by: Juergen Gross --- V6: - new patch --- tools/libxc/include/xenctrl.h | 1 - tools/libxc/xc_misc.c | 21 - 2 files changed, 22 deletions(-) diff --git a/tools/libxc/include/xenctrl.h b/tools/li

[PATCH v7 01/12] xen/vmx: let opt_ept_ad always reflect the current setting

In case opt_ept_ad has not been set explicitly by the user via command line or runtime parameter, it is treated as "no" on Avoton cpus. Change that handling by setting opt_ept_ad to 0 for this cpu type explicitly if no user value has been set. By putting this into the (renamed) boot time initiali

[PATCH v7 05/12] libs: add libxenhypfs

Add the new library libxenhypfs for access to the hypervisor filesystem. Signed-off-by: Juergen Gross Acked-by: Wei Liu --- V1: - rename to libxenhypfs - add xenhypfs_write() V3: - major rework due to new hypervisor interface - add decompression capability V4: - add dependency to libz in pkgco

[PATCH v7 08/12] xen: add /buildinfo/config entry to hypervisor filesystem

Add the /buildinfo/config entry to the hypervisor filesystem. This entry contains the .config file used to build the hypervisor. Signed-off-by: Juergen Gross --- V3: - store data in gzip format - use binfile mechanism to create data file - move code to kernel.c V6: - add config item for the /bui

[PATCH v7 03/12] docs: add feature document for Xen hypervisor sysfs-like support

On the 2019 Xen developer summit there was agreement that the Xen hypervisor should gain support for a hierarchical name-value store similar to the Linux kernel's sysfs. In the beginning there should only be basic support: entries can be added from the hypervisor itself only, there is a simple hyp

[PATCH v7 02/12] xen: add a generic way to include binary files as variables

Add a new script xen/tools/binfile for including a binary file at build time being usable via a pointer and a size variable in the hypervisor. Make use of that generic tool in xsm. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Reviewed-by: Wei Liu --- V3: - new patch V4: - add alignme

[PATCH v7 09/12] xen: add runtime parameter access support to hypfs

Add support to read and modify values of hypervisor runtime parameters via the hypervisor file system. As runtime parameters can be modified via a sysctl, too, this path has to take the hypfs rw_lock as writer. For custom runtime parameters the connection between the parameter value and the file

[PATCH v7 04/12] xen: add basic hypervisor filesystem support

Add the infrastructure for the hypervisor filesystem. This includes the hypercall interface and the base functions for entry creation, deletion and modification. In order not to have to repeat the same pattern multiple times in case adding a new node should BUG_ON() failure, the helpers for addin

[PATCH v7 12/12] xen: remove XEN_SYSCTL_set_parameter support

The functionality of XEN_SYSCTL_set_parameter is available via hypfs now, so it can be removed. This allows to remove the kernel_param structure for runtime parameters by putting the now only used structure element into the hypfs node structure of the runtime parameters. Signed-off-by: Juergen Gr

[PATCH v7 10/12] tools/libxl: use libxenhypfs for setting xen runtime parameters

Instead of xc_set_parameters() use xenhypfs_write() for setting parameters of the hypervisor. Signed-off-by: Juergen Gross --- V6: - new patch --- tools/Rules.mk | 2 +- tools/libxl/Makefile | 3 ++- tools/libxl/libxl.c | 53 ++

[PATCH v7 07/12] xen: provide version information in hypfs

Provide version and compile information in /buildinfo/ node of the Xen hypervisor file system. As this information is accessible by dom0 only no additional security problem arises. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich --- V3: - new patch V4: - add __read_mostly annotations (Jan

[PATCH v7 06/12] tools: add xenfs tool

Add the xenfs tool for accessing the hypervisor filesystem. Signed-off-by: Juergen Gross Acked-by: Wei Liu --- V1: - rename to xenhypfs - don't use "--" for subcommands - add write support V2: - escape non-printable characters per default with cat subcommand (Ian Jackson) - add -b option to c

[PATCH v7 00/12] Add hypervisor sysfs-like support

On the 2019 Xen developer summit there was agreement that the Xen hypervisor should gain support for a hierarchical name-value store similar to the Linux kernel's sysfs. This is a first implementation of that idea adding the basic functionality to hypervisor and tools side. The interface to any us

[qemu-mainline test] 149303: regressions - FAIL

flight 149303 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/149303/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 144861 test-amd6

Re: [PATCH v2 0/2] x86/cpuidle: Cannon Lake adjustments

On 02/04/2020 09:22, Jan Beulich wrote: > As requested in reply to v1, this is now a pair of patches with > the expectation that only patch 1 would be acked and go in. > > 1: drop Cannon Lake support > 2: support Cannon Lake (again) Dropping Cannon Lake support is only of any incremental benefit i

RE: [PATCH for-5.0] xen-block: Fix double qlist remove

> -Original Message- > From: Anthony PERARD > Sent: 02 April 2020 14:08 > To: qemu-de...@nongnu.org > Cc: qemu-sta...@nongnu.org; Anthony PERARD ; > Stefano Stabellini > ; Paul Durrant ; Stefan Hajnoczi > ; Kevin > Wolf ; Max Reitz ; > xen-devel@lists.xenproject.org; qemu- > bl...@nongn

Re: [Xen-devel] [PATCH] tools/xenstore: fix a use after free problem in xenstored

Ping? On 24.03.20 11:12, Juergen Gross wrote: Commit 562a1c0f7ef3fb ("tools/xenstore: dont unlink connection object twice") introduced a potential use after free problem in domain_cleanup(): after calling talloc_unlink() for domain->conn domain->conn is set to NULL. The problem is that domain is

Re: [PATCH v4] x86: clear RDRAND CPUID bit on AMD family 15h/16h

On 09/03/2020 09:08, Jan Beulich wrote: > Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24: > > There have been reports of RDRAND issues after resuming from suspend on > some AMD family 15h and family 16h systems. This issue stems from a BIOS > not performing the proper

RE: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context

> -Original Message- > From: Jan Beulich > Sent: 02 April 2020 12:08 > To: p...@xen.org > Cc: xen-devel@lists.xenproject.org; 'Andrew Cooper' > ; 'George Dunlap' > ; 'Ian Jackson' ; > 'Julien Grall' > ; 'Stefano Stabellini' ; 'Wei Liu' > > Subject: Re: [PATCH 1/5] xen/common: introduce

[libvirt test] 149314: regressions - FAIL

flight 149314 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/149314/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182 build-i386-libvirt

[PATCH for-5.0] xen-block: Fix double qlist remove

Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on remove") revealed that a request was removed twice from a list, once in xen_block_finish_request() and a second time in xen_block_release_request() when both function are called from xen_block_complete_aio(). But also, the `requests_

[xen-unstable test] 149297: regressions - FAIL

flight 149297 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/149297/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 149188 build-i386

Re: 4.13: import xen.lowlevel.xc fails with SystemError: bad call flags

On 02/04/2020 13:43, Kevin Buckley wrote: > Hello again, > > despite having built a Xen 4.13 with just Python3 on a > Linux From Scratch system, > > http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html > > specifically > > http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html#ch-xen > > > and booted into

4.13: import xen.lowlevel.xc fails with SystemError: bad call flags

Hello again, despite having built a Xen 4.13 with just Python3 on a Linux From Scratch system, http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html specifically http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html#ch-xen and booted into the Dom0 (Linux 5.5.3, GCC 9.2.0, Python 3.8.1) without issue

Re: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for XenDevice-s

On 4/2/20 11:49 AM, Paul Durrant wrote: -Original Message- From: Philippe Mathieu-Daudé Sent: 01 April 2020 17:14 To: Anthony PERARD ; qemu-de...@nongnu.org Cc: xen-devel@lists.xenproject.org; Peter Maydell ; Paul Durrant ; Markus Armbruster Subject: Re: [Qemu-devel] [PULL 06/25] xen:

Re: [PATCH v2] x86emul: suppress "not built" warning for test harness for run targets

On 20/03/2020 16:11, Jan Beulich wrote: > The run* targets can be used to test whatever the tool chain is capable > of building, as long as at least the main harness source file builds. > Don't probe the tools chain, in particular to avoid issuing the warning, > in this case. While looking into thi

Re: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context

On 02.04.2020 11:58, Paul Durrant wrote: >> -Original Message- >> From: Jan Beulich >> Sent: 01 April 2020 15:51 >> To: Paul Durrant >> Cc: xen-devel@lists.xenproject.org; Andrew Cooper >> ; George Dunlap >> ; Ian Jackson ; Julien >> Grall ; >> Stefano Stabellini ; Wei Liu >> Subject:

Re: [PATCH] x86emul: inherit HOSTCC when building 32-bit harness on 64-bit host

On 02/04/2020 10:43, Jan Beulich wrote: > We're deliberately bringing XEN_COMPILE_ARCH and XEN_TARGET_ARCH out of > sync in this case, and hence HOSTCC won't get set from CC. Therefore > without this addition HOSTCC would not match a possible make command > line override of CC, but default to "gcc"

[PATCH 4/5] x86/ucode: Drop ops->free_patch()

With the newly cleaned up vendor logic, each struct microcode_patch is a trivial object in memory with no dependent allocations. This is unlikely to change moving forwards, and function pointers are expensive in the days of retpoline. Move the responsibility to xfree() back to common code. If th

[PATCH 1/5] x86/ucode/intel: Remove CPUID from collect_cpu_info()

The CPUID instruction is expensive. No point executing it twice when once will do fine. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/cpu/microcode/intel.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/arch/x86/

[PATCH 0/5] x86/ucode: Cleanup part 5/n

Some fairly minor changes while I wait for more answers from vendors. I'm annoyed that I didn't spot patch 2 earlier, because it would have simplied some of the previous cleanup work. Oh well... Andrew Cooper (5): x86/ucode/intel: Remove CPUID from collect_cpu_info() x86/ucode: Drop ops->mat

[PATCH 2/5] x86/ucode: Drop ops->match_cpu()

It turns out there are no callers of the hook(). The only callers are the local, which can easily be rearranged to use the appropriate internal helper. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/cpu/microcode/amd.c | 8 +--- xen

[PATCH 3/5] x86/ucode: Don't try to cope with NULL pointers in apply_microcode()

No paths to apply_microcode() pass a NULL pointer, and other hooks don't tolerate one in the first place. We can expect the core logic not to pass us junk, so drop the checks. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/cpu/microcode/amd.

[PATCH 5/5] x86/ucode: Simplify the ops->collect_cpu_info() API

All callers pass &this_cpu(cpu_sig) for the cpu_sig parameter, and all implementations unconditionally return 0. Simplify it to be void. Drop the long-stale comment on the AMD side, whose counterpart in start_update() used to be "collect_cpu_info() doesn't fail so we're fine". Signed-off-by: And

RE: [PATCH 1/5] xen/common: introduce a new framework for save/restore of 'domain' context

> -Original Message- > From: Jan Beulich > Sent: 01 April 2020 15:51 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Andrew Cooper > ; George Dunlap > ; Ian Jackson ; Julien > Grall ; > Stefano Stabellini ; Wei Liu > Subject: Re: [PATCH 1/5] xen/common: introduce a new framewo

RE: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for XenDevice-s

> -Original Message- > From: Philippe Mathieu-Daudé > Sent: 01 April 2020 17:14 > To: Anthony PERARD ; qemu-de...@nongnu.org > Cc: xen-devel@lists.xenproject.org; Peter Maydell ; > Paul Durrant > ; Markus Armbruster > Subject: Re: [Qemu-devel] [PULL 06/25] xen: create xenstore areas for

[PATCH] x86emul: inherit HOSTCC when building 32-bit harness on 64-bit host

We're deliberately bringing XEN_COMPILE_ARCH and XEN_TARGET_ARCH out of sync in this case, and hence HOSTCC won't get set from CC. Therefore without this addition HOSTCC would not match a possible make command line override of CC, but default to "gcc", likely causing the build to fail for test_x86_

Re: [PATCH v2] x86emul: suppress "not built" warning for test harness for run targets

On 20.03.2020 17:11, Jan Beulich wrote: > The run* targets can be used to test whatever the tool chain is capable > of building, as long as at least the main harness source file builds. > Don't probe the tools chain, in particular to avoid issuing the warning, > in this case. While looking into thi

Ping: [PATCH v4] x86: clear RDRAND CPUID bit on AMD family 15h/16h

On 09.03.2020 10:08, Jan Beulich wrote: > Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24: > > There have been reports of RDRAND issues after resuming from suspend on > some AMD family 15h and family 16h systems. This issue stems from a BIOS > not performing the prope

[PATCH v2 1/2] x86/cpuidle: drop Cannon Lake support

As per SDM rev 071 Cannon Lake has - no CC3 residency MSR at 3FC, - a CC1 residency MSR ar 660 (like various Atoms), - a useless (always zero) CC3 residency MSR at 662. However, this CPU model has been discontinued and isn't a primary target of Xen anyway. Hence (at least for now) rather than corre

[PATCH v2 2/2] x86/cpuidle: support Cannon Lake (again)

As per SDM rev 071 Cannon Lake has - no CC3 residency MSR at 3FC, - a CC1 residency MSR ar 660 (like various Atoms), - a useless (always zero) CC3 residency MSR at 662. Hence it needs a separate case label. Signed-off-by: Jan Beulich --- v2: Split. This patch is beign submitted more for completen

[PATCH v2 0/2] x86/cpuidle: Cannon Lake adjustments

As requested in reply to v1, this is now a pair of patches with the expectation that only patch 1 would be acked and go in. 1: drop Cannon Lake support 2: support Cannon Lake (again) Jan

Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

> On 1 Apr 2020, at 18:23, Julien Grall wrote: > > > > On 01/04/2020 10:54, Bertrand Marquis wrote: >>> On 1 Apr 2020, at 09:30, Julien Grall >> > wrote: >>> >>> >>> >>> On 01/04/2020 01:57, Stefano Stabellini wrote: On Mon, 30 Mar 2020, Julien Grall wrote:

Ping: [PATCH v2] x86/PV: remove unnecessary toggle_guest_pt() overhead

On 20.12.2019 15:06, Jan Beulich wrote: > While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly > expensive (but still needed only for the toggle_guest_mode() path), the > effect of the latter on the exit-to-guest path is not insignificant. > Move the logic into toggle_guest_mode

Ping: [PATCH 4/4] x86/APIC: restrict certain messages to BSP

On 16.03.2020 10:10, Jan Beulich wrote: > On 13.03.2020 17:18, Andrew Cooper wrote: >> On 13/03/2020 09:26, Jan Beulich wrote: >>> All CPUs get an equal setting of EOI broadcast suppression; no need to >>> log one message per CPU, even if it's only in verbose APIC mode. >>> >>> Only the BSP is elig

[PATCH] x86/HVM: expose VM assist hypercall

In preparation for the addition of VMASST_TYPE_runstate_update_flag commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled the hypercall for Arm. I consider it not logical that it then isn't also exposed to x86 HVM guests (with the same single feature permitted to be enabled as Ar