Re: [PATCH 1/6] xen/hvm: Convert hap_capabilities into a bitfield

On Wed, Feb 21, 2024 at 3:23 PM Jan Beulich wrote: > > On 21.02.2024 08:02, George Dunlap wrote: > > On Mon, Feb 19, 2024 at 9:36 PM Jan Beulich wrote: > >> On 06.02.2024 02:20, George Dunlap wrote: > >>> --- a/xen/arch/x86/hvm/vmx/vmcs.c > >>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c > >>> @@ -113,8

Re: [PATCH 1/6] xen/hvm: Convert hap_capabilities into a bitfield

On 21.02.2024 08:02, George Dunlap wrote: > On Mon, Feb 19, 2024 at 9:36 PM Jan Beulich wrote: >> On 06.02.2024 02:20, George Dunlap wrote: >>> --- a/xen/arch/x86/hvm/vmx/vmcs.c >>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >>> @@ -113,8 +113,8 @@ static int cf_check parse_ept_param_runtime(const char

Re: [PATCH 3/6] xen/hvm: Move other hvm_function_table booleans into the caps bitfield

On Tue, Feb 20, 2024 at 12:08 AM Jan Beulich wrote: > > On 06.02.2024 02:20, George Dunlap wrote: > > --- a/xen/arch/x86/include/asm/hvm/hvm.h > > +++ b/xen/arch/x86/include/asm/hvm/hvm.h > > @@ -86,20 +86,19 @@ struct hvm_vcpu_nonreg_state { > > struct hvm_function_table { > > const char

Re: [PATCH 2/2] almost fully ignore zero-size flush requests

On 21.02.2024 03:32, George Dunlap wrote: > On Tue, Feb 20, 2024 at 4:26 PM Jan Beulich wrote: +if ( (cflush->offset | cflush->length) > PAGE_SIZE || >>> >>> This is confusing. I understand you are trying to force the compiler to >>> optimize. But is it really worth it? After all, the

Re: [PATCH 2/6] svm: Improve type of cpu_has_svm_feature

On Mon, Feb 19, 2024 at 11:24 PM Jan Beulich wrote: > > On 06.02.2024 02:20, George Dunlap wrote: > > --- a/xen/arch/x86/include/asm/hvm/svm/svm.h > > +++ b/xen/arch/x86/include/asm/hvm/svm/svm.h > > @@ -38,7 +38,10 @@ extern u32 svm_feature_flags; > > #define SVM_FEATURE_SSS 19 /* NPT

Re: [PATCH 2/6] svm: Improve type of cpu_has_svm_feature

On Mon, Feb 19, 2024 at 10:03 PM Jan Beulich wrote: > > On 06.02.2024 02:20, George Dunlap wrote: > > The "effective type" of the cpu_has_svm_feature macro is effectively > > an unsigned log with one bit set (or not); at least one place someone > > felt compelled to do a !! to make sure that they

Re: [XEN v5 1/3] xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option

On 20.02.2024 16:22, Ayan Kumar Halder wrote: > On 20/02/2024 12:33, Jan Beulich wrote: >> On 20.02.2024 13:17, Ayan Kumar Halder wrote: >>> --- a/SUPPORT.md >>> +++ b/SUPPORT.md >>> @@ -101,6 +101,18 @@ Extension to the GICv3 interrupt controller to support >>> MSI. >>> >>> Status:

Re: [PATCH 1/6] xen/hvm: Convert hap_capabilities into a bitfield

On Mon, Feb 19, 2024 at 9:36 PM Jan Beulich wrote: > > On 06.02.2024 02:20, George Dunlap wrote: > > hvm_function_table is an internal structure; rather than manually > > |-ing and &-ing bits, just make it a boolean bitfield and let the > > compiler do all the work. This makes everything easier

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

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

[ovmf test] 184717: all pass - PUSHED

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

Re: [PATCH V3] libxl: Add "grant_usage" parameter for virtio disk devices

On Thu, Feb 15, 2024 at 11:07 PM Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko > > Allow administrators to control whether Xen grant mappings for > the virtio disk devices should be used. By default (when new > parameter is not specified), the existing behavior is retained > (we

Re: Stats on Xen tarball downloads

On Mon, Feb 19, 2024 at 6:38 PM Jan Beulich wrote: > > On 19.02.2024 11:31, Roger Pau Monné wrote: > > On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap wrote: > >> One of the questions we had with respect to changing our release > >> practice (for instance, making the process more

Re: Stats on Xen tarball downloads

On Mon, Feb 19, 2024 at 11:34 PM Elliott Mitchell wrote: > > On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap wrote: > > > > Looking at the *non*-4.18 downloads, nearly all of them have user > > agents that make it clear they're part of automated build systems: > > user agents like curl

[PATCH v13.3 01/14] vpci: use per-domain PCI lock to protect vpci structure

From: Oleksandr Andrushchenko Use the per-domain PCI read/write lock to protect the presence of the pci device vpci field. This lock can be used (and in a few cases is used right away) so that vpci removal can be performed while holding the lock in write mode. Previously such removal could race

Re: [PATCH 2/2] almost fully ignore zero-size flush requests

On Tue, Feb 20, 2024 at 4:26 PM Jan Beulich wrote: > >> +if ( (cflush->offset | cflush->length) > PAGE_SIZE || > > > > This is confusing. I understand you are trying to force the compiler to > > optimize. But is it really worth it? After all, the rest of operation > > will outweight this

Re: [PATCH v2] Constify some parameters

On Wed, Feb 14, 2024 at 5:48 PM Frediano Ziglio wrote: > > Make clear they are not changed in the functions. > > Signed-off-by: Frediano Ziglio > Reviewed-by: Jan Beulich Sched bits: Acked-by: George Dunlap

[xen-unstable test] 184712: tolerable FAIL - PUSHED

flight 184712 xen-unstable real [real] flight 184715 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184712/ http://logs.test-lab.xenproject.org/osstest/logs/184715/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on Arm

On Tue, 20 Feb 2024, Anthony PERARD wrote: > The "linux-arm-xen" tree currently point to Linux 5.4.17 + 3 commits: > 69117aaf07f7 ("xen/privcmd: replace kcalloc() by kvcalloc() when allocating > empty pages") > bca5bc0229a6 ("xen/privcmd: fix error handling in mmap-resource processing") >

Re: [PATCH v4 07/30] xen/asm-generic: introdure nospec.h

On Mon, 2024-02-19 at 13:18 +0100, Jan Beulich wrote: > On 19.02.2024 12:59, Oleksii wrote: > > Hi Julien, > > > > On Sun, 2024-02-18 at 18:30 +, Julien Grall wrote: > > > Hi Oleksii, > > > > > > Title: Typo s/introdure/introduce/ > > > > > > On 05/02/2024 15:32, Oleksii Kurochko wrote: > >

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

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

Re: [PATCH v4 02/30] xen/riscv: use some asm-generic headers

On Wed, 2024-02-14 at 11:03 +0100, Jan Beulich wrote: > On 14.02.2024 10:54, Oleksii wrote: > > On Mon, 2024-02-12 at 16:03 +0100, Jan Beulich wrote: > > > On 05.02.2024 16:32, Oleksii Kurochko wrote: > > > >  As [PATCH v6 0/9] Introduce generic headers > > > >  ( > > > >

XEN SOCIAL TOMORROW (21st Feb 2024)!

A reminder our Xen Project social is tomorrow! Connect with the community and your fellow peers - Food and drinks will be provided. *If you haven't already, please reply to me directly if you're interested in attending to anticipate food orders.* *Location:* The Portland Arms 129 Chesterton Rd

[PATCH RFC] x86/xen: attempt to inflate the memory balloon on PVH

When running as PVH or HVM Linux will use holes in the memory map as scratch space to map grants, foreign domain pages and possibly miscellaneous other stuff. However the usage of such memory map holes for Xen purposes can be problematic. The request of holesby Xen happen quite early in the

Re: [PATCH v1 03/21] Xen headers: correct typos

20.02.2024 11:52, Manos Pitsidianakis пишет: Correct typos automatically found with the `typos` tool Signed-off-by: Manos Pitsidianakis --- include/hw/xen/interface/arch-x86/xen-x86_64.h | 2 +- include/hw/xen/interface/arch-x86/xen.h| 2 +-

Re: [PATCH 4/4] xen-blkfront: atomically update queue limits

On Tue, Feb 20, 2024 at 01:35:07PM +0100, Roger Pau Monné wrote: > On Tue, Feb 20, 2024 at 09:49:35AM +0100, Christoph Hellwig wrote: > > Pass the initial queue limits to blk_mq_alloc_disk and use the > > blkif_set_queue_limits API to update the limits on reconnect. > > Allocating queue_limits on

Re: [PATCH 1/4] xen-blkfront: set max_discard/secure erase limits to UINT_MAX

On Tue, Feb 20, 2024 at 12:39:59PM +0100, Roger Pau Monné wrote: > On Tue, Feb 20, 2024 at 09:49:32AM +0100, Christoph Hellwig wrote: > > Currently xen-blkfront set the max discard limit to the capacity of > > the device, which is suboptimal when the capacity changes. Just set > > it to UINT_MAX,

Re: [PATCH] xen: move BUG_ON(), WARN_ON(), ASSERT(), ASSERT_UNREACHABLE() to xen/bug.h

On 2/2/24 13:03, Oleksii Kurochko wrote: Move the macros mentioned in the commit subject to their appropriate locations. Additionally, eliminate the dependency of xen/lib.h from xen/bug.h and include "xen/bug.h" in files where xen/bug.h macros are utilized. Most of the changes were made because

Re: [XEN v5 1/3] xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option

Hi Jan, On 20/02/2024 12:33, Jan Beulich wrote: On 20.02.2024 13:17, Ayan Kumar Halder wrote: There can be situations when the registers cannot be emulated to their full functionality. This can be due to the complexity involved. In such cases, one can emulate those registers as RAZ/WI for

Re: [PATCH v2] xen/lib: introduce generic find next bit operations

Hi Shawn, Could you please take a look at the patch and PPC-related changes ( xen/arch/ppc/include/asm/bitops.h )? Thanks in advance. ~ Oleksii On Fri, 2024-02-09 at 18:58 +0100, Oleksii Kurochko wrote: > find-next-bit.c is common for Arm64, PPC and RISCV64, > so it is moved to xen/lib. > >

Re: [PATCH] xen: move BUG_ON(), WARN_ON(), ASSERT(), ASSERT_UNREACHABLE() to xen/bug.h

Hello Shawn, Could you please take a look at the patch and PPC-related changes in xen/arch/ppc/include/asm/time.h ? Thanks in advance. ~ Oleksii On Fri, 2024-02-02 at 20:03 +0200, Oleksii Kurochko wrote: > Move the macros mentioned in the commit subject to their appropriate > locations. >

Re: [XEN PATCH] x86/uaccess: add attribute noreturn to __{get,put}_user_bad()

On 20.02.2024 14:35, Federico Serafini wrote: > __get_user_bad() and __put_user_bad() are undefined symbols used > to assert the unreachability of a program point: > a call to one of such functions is optimized away if it is considered > unreachable by the compiler. Otherwise, a linker error is

Re: [PATCH v9 6/7] xen/ppc: switch PPC to use asm-generic/device.h

Hello Shawn, Would you mind taking a look at this patch? Thanks in advance. Best regards, Oleksii On Fri, 2024-02-16 at 13:39 +0100, Oleksii Kurochko wrote: > Signed-off-by: Oleksii Kurochko > --- > Changed in V8: >  - nothing changed. only rebase. > --- > Changes in V7: >  - newly

Re: [PATCH v9 2/7] xen/asm-generic: introduce stub header monitor.h

Oleksii On Fri, 2024-02-16 at 13:39 +0100, Oleksii Kurochko wrote: > The header is shared between several archs so it is > moved to asm-generic. > > Switch partly Arm and PPC to asm-generic/monitor.h and only > arch_monitor_get_capabilities() left in arch-specific/monitor.h. > > Signed-off-by:

[OSSTEST PATCH] ap-common: Switch to Linux 6.1 by default on Arm

The "linux-arm-xen" tree currently point to Linux 5.4.17 + 3 commits: 69117aaf07f7 ("xen/privcmd: replace kcalloc() by kvcalloc() when allocating empty pages") bca5bc0229a6 ("xen/privcmd: fix error handling in mmap-resource processing") f0f0e602f7c9 ("xen/privcmd: drop "pages" parameter

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

flight 184711 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184711/ 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

[XEN PATCH] automation: Rework "build-each-commit-gcc" test

Current issues with this test are: - when the job timeout, the log file is lost as there is no chance to run the `mv` command. - GitLab job log is limited in size, so one usually have to download the artifacts, which may be missing. Use $GITLAB_CI to detect when the script is run as part of a

[XEN PATCH] x86/uaccess: add attribute noreturn to __{get,put}_user_bad()

__get_user_bad() and __put_user_bad() are undefined symbols used to assert the unreachability of a program point: a call to one of such functions is optimized away if it is considered unreachable by the compiler. Otherwise, a linker error is reported. In accordance with the purpose of such

[xen-unstable test] 184709: tolerable FAIL

flight 184709 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184709/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-installfail pass in 184705 Tests which did not succeed,

Re: [PATCH 4/4] xen-blkfront: atomically update queue limits

On Tue, Feb 20, 2024 at 09:49:35AM +0100, Christoph Hellwig wrote: > Pass the initial queue limits to blk_mq_alloc_disk and use the > blkif_set_queue_limits API to update the limits on reconnect. Allocating queue_limits on the stack might be a bit risky, as I fear this struct is likely to grow?

Re: [XEN v5 1/3] xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option

On 20.02.2024 13:17, Ayan Kumar Halder wrote: > There can be situations when the registers cannot be emulated to their full > functionality. This can be due to the complexity involved. In such cases, one > can emulate those registers as RAZ/WI for example. We call them as partial > emulation. > >

Re: [PATCH 2/2] almost fully ignore zero-size flush requests

On 20.02.2024 12:52, Julien Grall wrote: > Hi Jan, > > On 20/02/2024 08:26, Jan Beulich wrote: >> On 19.02.2024 23:22, Julien Grall wrote: >>> Title: I would add 'gnttab:' to clarify which subsystem you are modifying. >> >> That's how I actually have it here; it's not clear to me why I lost the

Re: [PATCH] build: make sure build fails when running kconfig fails

On 20.02.2024 12:18, Anthony PERARD wrote: > On Tue, Feb 20, 2024 at 09:43:56AM +0100, Jan Beulich wrote: >> Because of using "-include", failure to (re)build auto.conf (with >> auto.conf.cmd produced as a secondary target) won't stop make from >> continuing the build. Arrange for it being

[XEN v5 2/3] xen/arm: arm64: Add emulation of Debug Data Transfer Registers

From: Michal Orzel Currently, if user enables HVC_DCC config option in Linux, it invokes access to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on arm32). As these registers are not emulated, Xen injects an undefined exception to the guest and Linux crashes. To prevent

[XEN v5 3/3] xen/arm: arm32: Add emulation of Debug Data Transfer Registers

When user enables HVC_DCC config option in Linux, it invokes access to debug transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen injects an undefined exception to the guest and Linux crashes. To prevent this crash, introduce a partial emulation of DBGDTRTXINT as RAZ/WI and

[XEN v5 0/3] xen/arm: Add emulation of Debug Data Transfer Registers

Hi, Refer https://lore.kernel.org/all/alpine.DEB.2.22.394.2312071341540.1265976@ubuntu-linux-20-04-desktop/T/ for the previous discussion on this issue. Also, the linux earlycon hvc driver has been fixed. See

[XEN v5 1/3] xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option

There can be situations when the registers cannot be emulated to their full functionality. This can be due to the complexity involved. In such cases, one can emulate those registers as RAZ/WI for example. We call them as partial emulation. Some registers are non-optional and as such there is

Re: [PATCH 3/4] xen-blkfront: don't redundantly set max_sements in blkif_recover

On Tue, Feb 20, 2024 at 09:49:34AM +0100, Christoph Hellwig wrote: > blkif_set_queue_limits already sets the max_sements limits, so don't do > it a second time. Also remove a comment about a long fixe bug in > blk_mq_update_nr_hw_queues. > > Signed-off-by: Christoph Hellwig Acked-by: Roger Pau

Re: [PATCH 2/2] almost fully ignore zero-size flush requests

Hi Jan, On 20/02/2024 08:26, Jan Beulich wrote: On 19.02.2024 23:22, Julien Grall wrote: Title: I would add 'gnttab:' to clarify which subsystem you are modifying. That's how I actually have it here; it's not clear to me why I lost the prefix when sending. On 05/02/2024 11:03, Jan Beulich

Re: [PATCH 2/4] xen-blkfront: rely on the default discard granularity

On Tue, Feb 20, 2024 at 09:49:33AM +0100, Christoph Hellwig wrote: > The block layer now sets the discard granularity to the physical > block size default. Take advantage of that in xen-blkfront and only > set the discard granularity if explicitly specified. > > Signed-off-by: Christoph Hellwig

Re: [PATCH 1/4] xen-blkfront: set max_discard/secure erase limits to UINT_MAX

On Tue, Feb 20, 2024 at 09:49:32AM +0100, Christoph Hellwig wrote: > Currently xen-blkfront set the max discard limit to the capacity of > the device, which is suboptimal when the capacity changes. Just set > it to UINT_MAX, which has the same effect except and is simpler. Extra 'except' in the

Re: [PATCH v9 7/7] xen/asm-generic: fold struct devarch into struct dev

On 16.02.2024 13:39, Oleksii Kurochko wrote: > The current patch is a follow-up to the patch titled: > xen/asm-generic: introduce generic device.h > Also, a prerequisite for this patch is, without which a compilation > error will occur: > xen/arm: switch Arm to use asm-generic/device.h

Re: [PATCH] build: make sure build fails when running kconfig fails

On Tue, Feb 20, 2024 at 09:43:56AM +0100, Jan Beulich wrote: > Because of using "-include", failure to (re)build auto.conf (with > auto.conf.cmd produced as a secondary target) won't stop make from > continuing the build. Arrange for it being possible to drop the - from > Rules.mk, requiring that

Re: [PATCH v2 (resend) 13/27] x86: Add a boot option to enable and disable the direct map

On 16.01.2024 20:25, Elias El Yandouzi wrote: > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -799,6 +799,18 @@ that enabling this option cannot guarantee anything > beyond what underlying > hardware guarantees (with, where available and known to Xen,

[libvirt test] 184708: tolerable FAIL - PUSHED

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

Re: [PATCH v2 (resend) 12/27] x86/mapcache: Initialise the mapcache for the idle domain

On 16.01.2024 20:25, Elias El Yandouzi wrote: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -750,9 +750,16 @@ int arch_domain_create(struct domain *d, > > spin_lock_init(>arch.e820_lock); > > +if ( (rc = mapcache_domain_init(d)) != 0) > +{ > +

Re: [PATCH v9 7/7] xen/asm-generic: fold struct devarch into struct dev

Hi Oleksii, On 20/02/2024 10:45, Oleksii wrote: Hi Julien, On Mon, 2024-02-19 at 19:00 +, Julien Grall wrote: Hi, On 16/02/2024 12:39, Oleksii Kurochko wrote: The current patch is a follow-up to the patch titled: xen/asm-generic: introduce generic device.h Also, a prerequisite for

Re: [PATCH v2 (resend) 11/27] x86: Lift mapcache variable to the arch level

On 16.01.2024 20:25, Elias El Yandouzi wrote: > From: Wei Liu > > It is going to be needed by HVM and idle domain as well, because without > the direct map, both need a mapcache to map pages. > > This only lifts the mapcache variable up. Whether we populate the > mapcache for a domain is

Re: [PATCH v9 7/7] xen/asm-generic: fold struct devarch into struct dev

Hi Julien, On Mon, 2024-02-19 at 19:00 +, Julien Grall wrote: > Hi, > > On 16/02/2024 12:39, Oleksii Kurochko wrote: > > The current patch is a follow-up to the patch titled: > > xen/asm-generic: introduce generic device.h > > Also, a prerequisite for this patch is, without which a

Re: [PATCH v2 (resend) 10/27] x86/pv: Map L4 page table for shim domain

On 16.01.2024 20:25, Elias El Yandouzi wrote: > From: Hongyan Xia > > The root page table is allocated from the domheap and isn't > mapped by default. Map it on demand to build pv shim domain. > > Signed-off-by: Hongyan Xia > Signed-off-by: Elias El Yandouzi The patch looks correct as is, so

Re: [PATCH v2 (resend) 09/27] x86/pv: Rewrite how building PV dom0 handles domheap mappings

On 16.01.2024 20:25, Elias El Yandouzi wrote: > --- a/xen/arch/x86/pv/dom0_build.c > +++ b/xen/arch/x86/pv/dom0_build.c > @@ -382,6 +382,10 @@ int __init dom0_construct_pv(struct domain *d, > l3_pgentry_t *l3tab = NULL, *l3start = NULL; > l2_pgentry_t *l2tab = NULL, *l2start = NULL; >

Re: [PATCH v6 02/15] xen/arm: add initial support for LLC coloring on arm64

Hi Carlo, On 20/02/2024 09:16, Carlo Nonato wrote: Hi Julien On Tue, Feb 20, 2024 at 12:06 AM Julien Grall wrote: Hi, On 14/02/2024 13:52, Carlo Nonato wrote: On Wed, Feb 14, 2024 at 11:14 AM Michal Orzel wrote: diff --git a/xen/arch/arm/include/asm/processor.h

Re: [PATCH v2 (resend) 08/27] x86/pv: Domheap pages should be mapped while relocating initrd

On 16.01.2024 20:25, Elias El Yandouzi wrote: > From: Wei Liu > > Xen shouldn't use domheap page as if they were xenheap pages. Map and > unmap pages accordingly. The title could to with mentioning Dom0. Since it's already a little long, the mentioning of domheap pages could be left to the

Re: [PATCH v2 (resend) 07/27] x86: Map/unmap pages in restore_all_guests

On 16.01.2024 20:25, Elias El Yandouzi wrote: > From: Hongyan Xia > > Before, it assumed the pv cr3 could be accessed via a direct map. This > is no longer true. There are a number of terminology issues here, starting with the title: Unlike (iirc) in an earlier version, no mapping/unmapping

Re: [PATCH v6 02/15] xen/arm: add initial support for LLC coloring on arm64

Hi Julien On Tue, Feb 20, 2024 at 12:06 AM Julien Grall wrote: > > Hi, > > On 14/02/2024 13:52, Carlo Nonato wrote: > > On Wed, Feb 14, 2024 at 11:14 AM Michal Orzel wrote: > >>> diff --git a/xen/arch/arm/include/asm/processor.h > >>> b/xen/arch/arm/include/asm/processor.h > >>> index

Re: [XEN v4 2/3] xen/arm: arm64: Add emulation of Debug Data Transfer Registers

Hi Julien, On 19/02/2024 19:48, Julien Grall wrote: > > > Hi Michal, > > On 19/02/2024 15:43, Michal Orzel wrote: > >> On 19/02/2024 15:45, Ayan Kumar Halder wrote: >>> >>> On 06/02/2024 19:05, Julien Grall wrote: Hi Ayan, >>> Hi Julien/Michal, On 31/01/2024 12:10, Ayan Kumar

Re: [PATCH v4 0/8] limit passing around of cpu_user_regs

On 20.02.2024 09:51, Jan Beulich wrote: > Unlike (synchronous) exception handlers, interrupt handlers don't normally > have a need to know the outer context's register state. Similarly, the vast > majority of key handlers has no need for such. > > 1: serial: fake IRQ-regs context in poll handlers

[PATCH v4 8/8] consolidate do_bug_frame() / bug_fn_t

The type not being used in do_bug_frame() is suspicious. Apparently that's solely because the type uses a pointer-to-const parameter, when so far run_in_exception_handler() wanted functions taking pointer- to-non-const. Expand use of const, in turn requiring common code's do_bug_frame() as well as

[PATCH v4 7/8] x86/APIC: drop regs parameter from direct vector handler functions

The only place it was needed is in the spurious handler, and there we can use get_irq_regs() instead. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -1322,7 +1322,7 @@ int reprogram_timer(s_time_t timeout) return apic_tmict ||

[PATCH v4 6/8] IRQ: drop regs parameter from handler functions

It's simply not needed anymore. Note how Linux made this change many years ago already, in 2.6.19 (late 2006, see [1]). Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Acked-by: Julien Grall [1] https://git.kernel.org/torvalds/c/7d12e780e003f93433d49ce78cfedf4b4c52adc5 --- v2: Arm build

[PATCH v4 5/8] serial: drop serial_[rt]x_interrupt()'s regs parameter

They're simply not needed anymore. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- v4: Re-base over changes earlier in the series. v2: Setting of IRQ regs split off to an earlier patch. --- a/xen/drivers/char/cadence-uart.c +++ b/xen/drivers/char/cadence-uart.c @@ -51,7 +51,7 @@

[PATCH v4 4/8] PV-shim: drop pv_console_rx()'s regs parameter

It's not needed anymore. This is in preparation of dropping the register parameters from IRQ handler functions. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- a/xen/arch/x86/guest/xen/xen.c +++ b/xen/arch/x86/guest/xen/xen.c @@ -181,7 +181,7 @@ static void cf_check

[PATCH v4 3/8] serial: drop serial_rx_fn's regs parameter

It's simply not needed anymore. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- v2: Re-base over earlier (new/split) patches. --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -526,7 +526,7 @@ static void switch_serial_input(void) printk("\n"); } -static

[PATCH v1 03/21] Xen headers: correct typos

Correct typos automatically found with the `typos` tool Signed-off-by: Manos Pitsidianakis --- include/hw/xen/interface/arch-x86/xen-x86_64.h | 2 +- include/hw/xen/interface/arch-x86/xen.h| 2 +- include/hw/xen/interface/event_channel.h | 2 +-

[PATCH v4 2/8] keyhandler: drop regs parameter from handle_keyregs()

In preparation for further removal of regs parameters, drop it here. In the two places where it's actually needed, retrieve IRQ context if available, or else guest context. Suggested-by: Andrew Cooper Signed-off-by: Jan Beulich Reviewed-by: Julien Grall --- As an alternative to the new boolean

[PATCH v4 1/8] serial: fake IRQ-regs context in poll handlers

In preparation of dropping the register parameters from serial_[rt]x_interrupt() and in turn from IRQ handler functions, register state needs making available another way for the few key handlers which need it. Fake IRQ-like state. Signed-off-by: Jan Beulich --- The use of guest_cpu_user_regs()

[PATCH v4 0/8] limit passing around of cpu_user_regs

Unlike (synchronous) exception handlers, interrupt handlers don't normally have a need to know the outer context's register state. Similarly, the vast majority of key handlers has no need for such. 1: serial: fake IRQ-regs context in poll handlers 2: keyhandler: drop regs parameter from

[PATCH 4/4] xen-blkfront: atomically update queue limits

Pass the initial queue limits to blk_mq_alloc_disk and use the blkif_set_queue_limits API to update the limits on reconnect. Signed-off-by: Christoph Hellwig --- drivers/block/xen-blkfront.c | 41 1 file changed, 23 insertions(+), 18 deletions(-) diff --git

[PATCH 3/4] xen-blkfront: don't redundantly set max_sements in blkif_recover

blkif_set_queue_limits already sets the max_sements limits, so don't do it a second time. Also remove a comment about a long fixe bug in blk_mq_update_nr_hw_queues. Signed-off-by: Christoph Hellwig --- drivers/block/xen-blkfront.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-)

[PATCH 1/4] xen-blkfront: set max_discard/secure erase limits to UINT_MAX

Currently xen-blkfront set the max discard limit to the capacity of the device, which is suboptimal when the capacity changes. Just set it to UINT_MAX, which has the same effect except and is simpler. Signed-off-by: Christoph Hellwig --- drivers/block/xen-blkfront.c | 6 ++ 1 file changed,

[PATCH 2/4] xen-blkfront: rely on the default discard granularity

The block layer now sets the discard granularity to the physical block size default. Take advantage of that in xen-blkfront and only set the discard granularity if explicitly specified. Signed-off-by: Christoph Hellwig --- drivers/block/xen-blkfront.c | 4 ++-- 1 file changed, 2 insertions(+),

convert xen-blkfront to atomic queue limit updates

Hi all, this series converts xen-blkfront to the new atomic queue limits update API in the block tree. I don't have a Xen setup so this is compile tested only. Diffstat: xen-blkfront.c | 53 +++-- 1 file changed, 27 insertions(+), 26

Re: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.3

On 20/02/24 09:31, Jan Beulich wrote: On 20.02.2024 09:16, Federico Serafini wrote: On 19/02/24 16:06, Jan Beulich wrote: On 19.02.2024 15:59, Federico Serafini wrote: On 19/02/24 14:43, Jan Beulich wrote: On 19.02.2024 14:24, Federico Serafini wrote: Update ECLAIR configuration to consider

[PATCH] build: make sure build fails when running kconfig fails

Because of using "-include", failure to (re)build auto.conf (with auto.conf.cmd produced as a secondary target) won't stop make from continuing the build. Arrange for it being possible to drop the - from Rules.mk, requiring that the include be skipped for tools-only targets. Note that relying on

Re: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.3

On 20.02.2024 09:16, Federico Serafini wrote: > On 19/02/24 16:06, Jan Beulich wrote: >> On 19.02.2024 15:59, Federico Serafini wrote: >>> On 19/02/24 14:43, Jan Beulich wrote: On 19.02.2024 14:24, Federico Serafini wrote: > Update ECLAIR configuration to consider safe switch clauses

Re: [PATCH 2/2] almost fully ignore zero-size flush requests

On 19.02.2024 23:22, Julien Grall wrote: > Title: I would add 'gnttab:' to clarify which subsystem you are modifying. That's how I actually have it here; it's not clear to me why I lost the prefix when sending. > On 05/02/2024 11:03, Jan Beulich wrote: >> Along the line with observations in the

Re: [XEN PATCH] automation/eclair: add deviation for MISRA C:2012 Rule 16.3

On 19/02/24 16:06, Jan Beulich wrote: On 19.02.2024 15:59, Federico Serafini wrote: On 19/02/24 14:43, Jan Beulich wrote: On 19.02.2024 14:24, Federico Serafini wrote: Update ECLAIR configuration to consider safe switch clauses ending with __{get,put}_user_bad(). Update

Re: [XEN PATCH] xen: cache clearing and invalidation helpers refactoring

On 2024-02-20 08:45, Jan Beulich wrote: On 19.02.2024 16:14, Nicola Vetrini wrote: The cache clearing and invalidation helpers in x86 and Arm didn't comply with MISRA C Rule 17.7: "The value returned by a function having non-void return type shall be used". On Arm they were always returning 0,