Re: [PATCH v2 2/2] Revert "xen-netback: Check for hotplug-status existence before watching"

On 22/02/2022 00:18, Marek Marczykowski-Górecki wrote: This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d. The reasoning in the commit was wrong - the code expected to setup the watch even if 'hotplug-status' didn't exist. In fact, it relied on the watch being fired the first time -

Re: [PATCH v2 1/2] Revert "xen-netback: remove 'hotplug-status' once it has served its purpose"

On 22/02/2022 00:18, Marek Marczykowski-Górecki wrote: This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2. The 'hotplug-status' node should not be removed as long as the vif device remains configured. Otherwise the xen-netback would wait for re-running the network script even if it

Re: [PATCH 1/2] x86/p2m: make p2m_get_page_from_gfn() handle grant and shared cases better

On 23.02.2022 19:11, Tamas K Lengyel wrote: >> @@ -607,6 +607,7 @@ struct page_info *p2m_get_page_from_gfn( >> >> /* Error path: not a suitable GFN at all */ >> if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_pod(*t) && >> + (!p2m_is_shared(*t) || !(q &

[linux-linus test] 168209: tolerable FAIL - PUSHED

flight 168209 linux-linus real [real] flight 168213 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168209/ http://logs.test-lab.xenproject.org/osstest/logs/168213/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Proposal for Porting Xen to Armv8-R64 - DraftA

# Proposal for Porting Xen to Armv8-R64 This proposal will introduce the PoC work of porting Xen to Armv8-R64, which includes: - The changes of current Xen capability, like Xen build system, memory management, domain management, vCPU context switch. - The expanded Xen capability, like

Re: [PATCH v2 1/2] Revert "xen-netback: remove 'hotplug-status' once it has served its purpose"

On Tue, 22 Feb 2022 01:18:16 +0100 Marek Marczykowski-Górecki wrote: > This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2. > > The 'hotplug-status' node should not be removed as long as the vif > device remains configured. Otherwise the xen-netback would wait for > re-running the

[linux-5.4 test] 168206: tolerable FAIL - PUSHED

flight 168206 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/168206/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 19 guest-start.2fail REGR. vs. 168130 Tests which did not succeed,

[RFC PATCH 0/2] Introduce reserved Xenheap

The reserved Xenheap, or statically configured Xenheap, refers to parts of RAM reserved in the beginning for Xenheap. Like the static memory allocation, such reserved Xenheap regions are reserved by configuration in the device tree using physical address ranges. This feature is useful to run Xen

[RFC PATCH 2/2] xen/arm: Handle reserved Xenheap pages in boot/heap allocator

This commit firstly adds a global variable `reserved_heap`. This newly introduced global variable is set at the device tree parsing time if the reserved Xenheap ranges are defined in the device tree chosen node. In `setup_mm`, If the reserved Xenheap is enabled and used, we make sure that these

[RFC PATCH 1/2] docs, xen/arm: Introduce reserved Xenheap memory

This commit introduces the reserved Xenheap memory, which is parts of RAM reserved in the beginning of the boot time for Xenheap. A new boolean field `xen_heap` in `struct membank` is added to store the configuration telling if the memory bank is reserved as Xenheap through `xen,static-mem` in

Re: cleanup swiotlb initialization

On 2/22/22 10:35 AM, Christoph Hellwig wrote: Hi all, this series tries to clean up the swiotlb initialization, including that of swiotlb-xen. To get there is also removes the x86 iommu table infrastructure that massively obsfucates the initialization path. Git tree:

[xen-unstable-smoke test] 168210: tolerable all pass - PUSHED

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

[RFC] kernel: xenfs parameter to hide deprecated files

Hi, I have been investigating a very intermittent issue we have with xenstore access hanging. Typically it seems to happen when all domains are stopped prior to a system reboot. xenstore is running in a stubdom and using the hypervisor debug keys indicates the domain is still there. I have

[qemu-mainline test] 168205: tolerable FAIL - PUSHED

flight 168205 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/168205/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168199 test-armhf-armhf-libvirt 16

[PATCH v2] xen/netfront: destroy queues before real_num_tx_queues is zeroed

xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: update the queue counts in the unregistration path"), unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two facts together means, that

Re: [PATCH] xen/netfront: destroy queues before real_num_tx_queues is zeroed

On Tue, Feb 22, 2022 at 12:03:01PM -0800, Jakub Kicinski wrote: > On Mon, 21 Feb 2022 07:27:32 +0100 Juergen Gross wrote: > > On 20.02.22 14:42, Marek Marczykowski-Górecki wrote: > > > xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to > > > delete queues. Since

[xen-unstable-smoke test] 168208: tolerable all pass - PUSHED

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

Re: [PATCH v2] xen/mm: pg_offlined can be defined as bool in free_heap_pages()

On 23/02/2022 19:08, Julien Grall wrote: > From: Julien Grall > > The local variable pg_offlined in free_heap_pages() can only take two > values. So switch it to a bool. > > Signed-off-by: Julien Grall I'd argue this might want to go as far as declaring Fixes: 289610483fc43 which really did

Re: [PATCH] xen/mm: Remove always true ASSERT() in free_heap_pages()

On 23/02/2022 18:38, Julien Grall wrote: From: Julien Grall free_heap_pages() has an ASSERT() checking that node is >= 0. However node is defined as an unsigned int. So it cannot be negative. Therefore remove the check as it will always be true. Coverity-ID: 1055631

Re: [XEN v8 2/2] xen/arm64: io: Support instructions (for which ISS is not valid) on emulated MMIO region using MMIO/ioreq handler

On 21/02/2022 21:10, Ayan Kumar Halder wrote: Hi Julien, Hi, On 21/02/2022 19:13, Julien Grall wrote: On 21/02/2022 19:05, Ayan Kumar Halder wrote: If we (ie Xen) didn't decode the instruction manually, then check_p2m() has not been invoked yet.  This is because of the following

[PATCH v2] xen/mm: pg_offlined can be defined as bool in free_heap_pages()

From: Julien Grall The local variable pg_offlined in free_heap_pages() can only take two values. So switch it to a bool. Signed-off-by: Julien Grall --- Changes in v2: - pg_offlined should be initialized to false rather than true --- xen/common/page_alloc.c | 5 +++-- 1 file

Re: [PATCH] xen/mm: pg_offlined can be defined as bool in free_heap_pages()

Hi, On 23/02/2022 19:03, Andrew Cooper wrote: On 23/02/2022 18:41, Julien Grall wrote: From: Julien Grall The local variable pg_offlined in free_heap_pages() can only take two values. So switch it to a bool. Signed-off-by: Julien Grall --- xen/common/page_alloc.c | 5 +++-- 1 file

Re: [PATCH] xen/mm: pg_offlined can be defined as bool in free_heap_pages()

On 23/02/2022 18:41, Julien Grall wrote: > From: Julien Grall > > The local variable pg_offlined in free_heap_pages() can only take two > values. So switch it to a bool. > > Signed-off-by: Julien Grall > --- > xen/common/page_alloc.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-)

Re: [PATCH v2 2/2] xen/arm: Rename psr_mode_is_user to regs_mode_is_user

Hi Michal, On 22/02/2022 10:56, Michal Orzel wrote: Perform renaming of psr_mode_is_user to regs_mode_is_user in order to reflect that it takes struct cpu_user_regs as a parameter and not psr. Signed-off-by: Michal Orzel Acked-by: Julien Grall Cheers, -- Julien Grall

Re: [PATCH v2 1/2] xen/arm: Rename psr_mode_is_32bit to regs_mode_is_32bit

Hi Michal, On 22/02/2022 10:56, Michal Orzel wrote: Commit aa2f5aefa8de ("xen/arm: Rework psr_mode_is_32bit()") modified the function to take a struct cpu_user_regs instead of psr. Perform renaming of psr_mode_is_32bit to regs_mode_is_32bit to reflect that change. Signed-off-by: Michal Orzel

Re: [PATCH RFC 1/3] xen/efi: Always query the console information and get GOP

Hi Daniel, Gentle ping. Your feedback on this approach would be helpful. On 07/02/2022 08:46, Jan Beulich wrote: On 06.02.2022 20:28, Julien Grall wrote: From: Julien Grall Currently, the EFI stub will only query the console information and get the GOP when using the configuration file.

[PATCH] xen/mm: pg_offlined can be defined as bool in free_heap_pages()

From: Julien Grall The local variable pg_offlined in free_heap_pages() can only take two values. So switch it to a bool. Signed-off-by: Julien Grall --- xen/common/page_alloc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xen/common/page_alloc.c

[PATCH] xen/mm: Remove always true ASSERT() in free_heap_pages()

From: Julien Grall free_heap_pages() has an ASSERT() checking that node is >= 0. However node is defined as an unsigned int. So it cannot be negative. Therefore remove the check as it will always be true. Signed-off-by: Julien Grall --- I have looked at the history. AFAICT, node has always

Re: [PATCH 1/2] x86/p2m: make p2m_get_page_from_gfn() handle grant and shared cases better

> @@ -607,6 +607,7 @@ struct page_info *p2m_get_page_from_gfn( > > /* Error path: not a suitable GFN at all */ > if ( !p2m_is_ram(*t) && !p2m_is_paging(*t) && !p2m_is_pod(*t) && > + (!p2m_is_shared(*t) || !(q & P2M_UNSHARE)) && >

[xen-unstable test] 168203: tolerable FAIL

flight 168203 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/168203/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168198 test-amd64-amd64-qemuu-nested-amd

Re: [RFC] Avoid dom0/HVM performance penalty from MSR access tightening

On 23.02.2022 17:11, Roger Pau Monné wrote: > On Wed, Feb 23, 2022 at 09:38:56AM -0600, Alex Olson wrote: >> 1) For conditions in which MSR registers are writeable from PV guests (such >> as >> dom0), they should probably be readable well, looks like >> MSR_IA32_THERM_CONTROL >> is currently

Re: [RFC] Avoid dom0/HVM performance penalty from MSR access tightening

On 23.02.2022 16:38, Alex Olson wrote: > It seems to me there are a few findings useful to the Xen developers from > venturing down this rabbithole: > > 1) For conditions in which MSR registers are writeable from PV guests (such as > dom0), they should probably be readable well, looks like >

Re: [RFC] Avoid dom0/HVM performance penalty from MSR access tightening

On Wed, Feb 23, 2022 at 09:38:56AM -0600, Alex Olson wrote: > I appreciate your interest, apologies for not replying right away. I've been > digging deeper to have a more meaningful resposne. > > I had attempted to instrument the MSR reads, but only saw a small number reads > being blocked by the

Re: [PATCH v2 11/14] shr_pages field is MEM_SHARING-only

On 23.02.2022 17:04, Jan Beulich wrote: > Conditionalize it and its uses accordingly. The main goal though is to > demonstrate that x86's p2m_teardown() is now empty when !HVM, which in > particular means the last remaining use of p2m_lock() in this cases goes > away. > > Signed-off-by: Jan

[PATCH v2 14/14] x86/P2M: the majority for struct p2m_domain's fields are HVM-only

..., as are the majority of the locks involved. Conditionalize things accordingly. Also adjust the ioreq field's indentation at this occasion. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Reviewed-by: George Dunlap --- v2: Adjust a comment. --- a/xen/arch/x86/mm.c +++

[PATCH v2 13/14] x86/P2M: p2m.c is HVM-only

This only requires moving p2m_percpu_rwlock elsewhere (ultimately I think all P2M locking should go away as well when !HVM, but this looks to require further code juggling). The two other unguarded functions are already unneeded (by virtue of DCE) when !HVM. Signed-off-by: Jan Beulich

[PATCH v2 12/14] paged_pages field is MEM_PAGING-only

Conditionalize it and its uses accordingly. Signed-off-by: Jan Beulich Reviewed-by: Tamas K Lengyel Reviewed-by: George Dunlap --- v2: Re-base (drop clearing of field in getdomaininfo()). --- I was on the edge of introducing a helper for atomic_read(>paged_pages) but decided against because of

[PATCH v2 11/14] shr_pages field is MEM_SHARING-only

Conditionalize it and its uses accordingly. The main goal though is to demonstrate that x86's p2m_teardown() is now empty when !HVM, which in particular means the last remaining use of p2m_lock() in this cases goes away. Signed-off-by: Jan Beulich Reviewed-by: Tamas K Lengyel Reviewed-by:

[PATCH v2 10/14] x86/p2m: re-arrange {,__}put_gfn()

All explicit callers of __put_gfn() are in HVM-only code and hold a valid P2M pointer in their hands. Move the paging_mode_translate() check out of there into put_gfn(), renaming __put_gfn() and making its GFN parameter type-safe. Signed-off-by: Jan Beulich Reviewed-by: George Dunlap --- v2:

[PATCH v2 09/14] x86/P2M: derive HVM-only variant from __get_gfn_type_access()

Introduce an inline wrapper dealing with the non-translated-domain case, while stripping that logic from the main function, which gets renamed to p2m_get_gfn_type_access(). HVM-only callers can then directly use the main function. Along with renaming the main function also make its and the new

[PATCH v2 08/14] x86/P2M: p2m_get_page_from_gfn() is HVM-only

This function is the wrong layer to go through for PV guests. It happens to work, but produces results which aren't fully consistent with get_page_from_gfn(). The latter function, however, cannot be used in map_domain_gfn() as it may not be the host P2M we mean to act on. Signed-off-by: Jan

[PATCH v2 07/14] x86/P2M: split out init/teardown functions

Mostly just code movement, and certainly no functional change intended. In p2m_final_teardown() the calls to p2m_teardown_{alt,nested}p2m() need to be guarded by an is_hvm_domain() check now, though. This matches p2m_init(). And p2m_is_logdirty_range() also gets moved inside the (so far) adjacent

[PATCH v2 06/14] x86/P2M: PoD, altp2m, and nested-p2m are HVM-only

There's no need to initialize respective data for PV domains. Note that p2m_teardown_{alt,nested}p2m() will handle the lack-of-initialization case fine. As a result, despite PV domains having a host P2M associated with them and hence using XENMEM_get_pod_target on such may not be a real problem,

[PATCH v2 05/14] x86/P2M: p2m_{alloc,free}_ptp() and p2m_alloc_table() are HVM-only

This also includes the two p2m related fields. Signed-off-by: Jan Beulich Reviewed-by: Kevin Tian Reviewed-by: George Dunlap --- v2: Re-base. --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -93,7 +93,9 @@ static int p2m_initialise(struct domain int ret = 0;

[PATCH v2 04/14] x86/mm: split set_identity_p2m_entry() into PV and HVM parts

..., moving the former into the new physmap.c. Also call the new functions directly from arch_iommu_hwdom_init() and vpci_make_msix_hole(), as the PV/HVM split is explicit there. Signed-off-by: Jan Beulich Reviewed-by: George Dunlap --- v2: Change arch_iommu_hwdom_init() and

[PATCH v2 03/14] x86/mm: move guest_physmap_{add,remove}_page()

... to a new file, separating the functions from their HVM-specific backing ones, themselves only dealing with the non-translated case. To avoid having a new CONFIG_HVM conditional in there, do away with the inline placeholder. Signed-off-by: Jan Beulich Reviewed-by: George Dunlap --- v2:

[PATCH v2 02/14] x86/P2M: introduce p2m_{add,remove}_page()

Rename guest_physmap_add_entry() to p2m_add_page(); make guest_physmap_remove_page() a trivial wrapper around p2m_remove_page(). This way callers can use suitable pairs of functions (previously violated by hvm/grant_table.c). In HVM-specific code further avoid going through the guest_physmap_*()

[PATCH v2 01/14] x86/P2M: rename p2m_remove_page()

This is in preparation to re-using the original name. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -788,8 +788,8 @@ void p2m_final_teardown(struct domain *d #ifdef CONFIG_HVM static int __must_check -p2m_remove_page(struct p2m_domain *p2m, gfn_t gfn,

[PATCH v2 00/14] x86/mm: large parts of P2M code and struct p2m_domain are HVM-only

The primary goal of this series is to leave p2m.c with, as its leading comment suggests, just code for "physical-to-machine mappings for automatically-translated domains". This requires splitting a few functions, with their non-HVM parts moved elsewhere. There aren't many changes in v2, mostly

Re: [RFC] Avoid dom0/HVM performance penalty from MSR access tightening

Hi Roger, See my other reply which is more detailed. While enabling reads of "MSR_IA32_ENERGY_PERF_BIAS" did not cause any effect in my case, it is one of a handful of exceptions in which MSRs are writeable but not readable. I believe this may result in potentially unexpected behavior in

Re: [RFC] Avoid dom0/HVM performance penalty from MSR access tightening

I appreciate your interest, apologies for not replying right away. I've been digging deeper to have a more meaningful resposne. I had attempted to instrument the MSR reads, but only saw a small number reads being blocked by the code change. They appear to be the list below and the others seem

[PATCH RFC 2/2] x86/p2m: aid the compiler in folding p2m_is_...()

By using | instead of || or (in the negated form) && chances increase for the compiler to recognize that both predicates can actually be folded into an expression requiring just a single branch (via OR-ing together the respective P2M_*_TYPES constants). Signed-off-by: Jan Beulich --- RFC: The

[PATCH 1/2] x86/p2m: make p2m_get_page_from_gfn() handle grant and shared cases better

Grant P2M entries, which are covered by p2m_is_any_ram(), wouldn't pass the get_page() unless the grant was a local one. These need to take the same path as foreign entries. Just the assertion there is not valid for local grants, and hence it triggering needs to be avoided. Shared entries, when

[PATCH 0/2] x86/p2m: type checking adjustments

While the first change is a bug fix (for, admittedly, a case which apparently hasn't occurred in practice, or else we would have had bug reports), it already puts in place an instance of what the 2nd patch is proposing for perhaps wider use. 1: make p2m_get_page_from_gfn() handle grant and shared

Re: [PATCH] RFC: Version support policy

On Wed, Feb 23, 2022 at 01:20:26PM +, George Dunlap wrote: > > On Feb 22, 2022, at 3:42 PM, Marek Marczykowski-Górecki > > wrote: > > > > On Tue, Feb 22, 2022 at 04:05:19PM +0100, Jan Beulich wrote: > >> On 22.02.2022 15:58, George Dunlap wrote: > On Feb 22, 2022, at 12:18 PM, Wojtek

Re: [PATCH v3 60/70] x86: Build check for embedded endbr64 instructions

On 23.02.2022 13:05, Andrew Cooper wrote: > On 23/02/2022 11:31, Jan Beulich wrote: >> On 22.02.2022 16:26, Andrew Cooper wrote: >>> up on a non-instruction boundary. Such embedded instructions mark legal >>> indirect branch targets as far as the CPU is concerned, which aren't legal >>> as >>>

Re: [PATCH v3 59/70] x86: Use control flow typechecking where possible

On 23/02/2022 14:21, Jan Beulich wrote: > On 22.02.2022 16:26, Andrew Cooper wrote: >> Now all callees have been annotated, turn on typechecking to catch issues in >> the future. >> >> This extension isn't in a released version of GCC yet, so provide a container >> to use with the extention

Re: [PATCH v3 59/70] x86: Use control flow typechecking where possible

On 22.02.2022 16:26, Andrew Cooper wrote: > Now all callees have been annotated, turn on typechecking to catch issues in > the future. > > This extension isn't in a released version of GCC yet, so provide a container > to use with the extention included, and add it to CI. RANDCONFIG is necessary

Re: [PATCH] RFC: Version support policy

> On Feb 22, 2022, at 3:42 PM, Marek Marczykowski-Górecki > wrote: > > On Tue, Feb 22, 2022 at 04:05:19PM +0100, Jan Beulich wrote: >> On 22.02.2022 15:58, George Dunlap wrote: On Feb 22, 2022, at 12:18 PM, Wojtek Porczyk wrote: On Mon, Feb 14, 2022 at 09:50:25PM +,

Re: [PATCH 3/3] x86: correct fencing around CLFLUSH

On 23/02/2022 10:13, Jan Beulich wrote: > As noted in the context of 3330013e6739 ("VT-d / x86: re-arrange cache > syncing"): While cache_writeback() has the SFENCE on the correct side of > CLFLUSHOPT, flush_area_local() doesn't. While I can't prove it due to > lacking a copy of the old SDM

Re: [PATCH v3 60/70] x86: Build check for embedded endbr64 instructions

On 23/02/2022 11:31, Jan Beulich wrote: > On 22.02.2022 16:26, Andrew Cooper wrote: >> up on a non-instruction boundary. Such embedded instructions mark legal >> indirect branch targets as far as the CPU is concerned, which aren't legal as >> far as the logic is concerned. > Thinking about it:

[linux-linus test] 168201: tolerable FAIL - PUSHED

flight 168201 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/168201/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168196 test-armhf-armhf-libvirt 16

Re: [PATCH v3 60/70] x86: Build check for embedded endbr64 instructions

On 22.02.2022 16:26, Andrew Cooper wrote: > From: Marek Marczykowski-Górecki > > An interesting corner case occurs when the byte sequence making up endb64 ends Nit: For grep-ability it would be nice to spell this "endbr64". > up on a non-instruction boundary. Such embedded instructions mark

Re: [PATCH 1/3] x86: drop NOP_DS_PREFIX

On 23.02.2022 11:54, Andrew Cooper wrote: > On 23/02/2022 10:12, Jan Beulich wrote: >> This wasn't really necessary to introduce: The binutils change >> permitting use of standalone "ds" (and "cs") in 64-bit code predates >> the minimum binutils version we support. >> >> Signed-off-by: Jan Beulich

Re: [PATCH 2/3] x86/cpuid: replace more cpufeat_word() uses

On 23/02/2022 10:12, Jan Beulich wrote: > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -332,23 +332,22 @@ void __init early_cpu_init(void) > cpuid(0x0001, , , , ); > c->x86 = get_cpu_family(eax, >x86_model, >x86_mask); > > - edx &=

Re: [PATCH 1/3] x86: drop NOP_DS_PREFIX

On 23/02/2022 10:12, Jan Beulich wrote: > This wasn't really necessary to introduce: The binutils change > permitting use of standalone "ds" (and "cs") in 64-bit code predates > the minimum binutils version we support. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper I was never a fan of

[libvirt test] 168202: regressions - FAIL

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

Re: [PATCH v3 29/70] xen/misc: CFI hardening

On 23/02/2022 10:25, Jan Beulich wrote: > On 22.02.2022 16:26, Andrew Cooper wrote: >> Control Flow Integrity schemes use toolchain and optionally hardware support >> to help protect against call/jump/return oriented programming attacks. >> >> Use cf_check to annotate function pointer targets for

Re: [PATCH v3 29/70] xen/misc: CFI hardening

On 22.02.2022 16:26, Andrew Cooper wrote: > Control Flow Integrity schemes use toolchain and optionally hardware support > to help protect against call/jump/return oriented programming attacks. > > Use cf_check to annotate function pointer targets for the toolchain. > > Signed-off-by: Andrew

[PATCH 3/3] x86: correct fencing around CLFLUSH

As noted in the context of 3330013e6739 ("VT-d / x86: re-arrange cache syncing"): While cache_writeback() has the SFENCE on the correct side of CLFLUSHOPT, flush_area_local() doesn't. While I can't prove it due to lacking a copy of the old SDM version, I can only assume this placement was a result

[PATCH 2/3] x86/cpuid: replace more cpufeat_word() uses

Complete what e3662437eb43 ("x86/cpuid: Disentangle logic for new feature leaves") has begun: "Switch to using FEATURESET_* just like the policy/featureset helpers. This breaks the cognitive complexity of needing to know which leaf a specifically named feature should reside in, and is shorter

[PATCH 1/3] x86: drop NOP_DS_PREFIX

This wasn't really necessary to introduce: The binutils change permitting use of standalone "ds" (and "cs") in 64-bit code predates the minimum binutils version we support. Signed-off-by: Jan Beulich --- In fact we could patch _just_ the opcode prefix in flush_area_local(). ---

[PATCH 0/3] x86: correct fencing around CLFLUSH (+some tidying)

While it'll make backporting of the last patch a little harder, it seemed better to me to do some cleanup first this time round. 1: drop NOP_DS_PREFIX 2: cpuid: replace more cpufeat_word() uses 3: correct fencing around CLFLUSH Jan

[xen-unstable-coverity test] 168204: all pass - PUSHED

flight 168204 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/168204/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 210f27e55abd2a57c01105992bc10bc4d7b8132d baseline version: xen

[qemu-mainline test] 168199: tolerable FAIL - PUSHED

flight 168199 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/168199/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168194 test-armhf-armhf-libvirt 16

Re: IGD pass-through failures since 4.10.

On 22.02.2022 19:52, Dr. Greg wrote: > On Fri, Feb 18, 2022 at 08:04:14AM +0100, Jan Beulich wrote: >> On 17.02.2022 21:15, Dr. Greg wrote: >>> On Mon, Feb 14, 2022 at 09:56:34AM +0100, Jan Beulich wrote: >>> In the case of the logs above, the following command sequence is being >>> executed upon