Hi Jan,
On 2022/9/27 16:19, Jan Beulich wrote:
On 20.09.2022 11:12, Wei Chen wrote:
There are some codes in x86/numa.c can be shared by common
architectures to implememnt NUMA support. Just like some
variables and functions to check and store NUMA memory map.
And some variables and functions to
Hi Jan,
On 2022/9/27 17:39, Jan Beulich wrote:
It's the comment which is wrong - it wasn't updated in Linux commit
54413927f022 ("x86-64: x86_64-make-the-numa-hash-function-nodemap-allocation
fix fix"). Our code was cloned from Linux'es. In fact when memory is not
contiguous, too small a shift v
On 28.09.2022 15:32, dpsmith.dev wrote:
> On 9/28/22 06:38, Jan Beulich wrote:
>> For quite some time we've been talking about replacing the present virtual
>> address based hypercall interface with one using physical addresses. This
>> is in
>> particular a prerequisite to being able to support
On 28.09.2022 16:27, Roger Pau Monné wrote:
> On Wed, Sep 28, 2022 at 02:12:30PM +0200, Jan Beulich wrote:
>> While for some of the functions there's locking involved, the acquiring
>> and releasing of a lock doesn't alter program state when comparing
>> "before" and "after" the function invocation
Hi Jan,
On 2022/9/27 23:48, Jan Beulich wrote:
On 20.09.2022 11:12, Wei Chen wrote:
+static bool __init nodes_cover_memory(void)
+{
+unsigned int i;
+
+for ( i = 0; ; i++ )
+{
+int err;
+bool found;
+unsigned int j;
+paddr_t start, end;
+
+/*
On 28.09.22 18:32, Juergen Gross wrote:
On 28.09.22 18:12, Borislav Petkov wrote:
On Wed, Sep 28, 2022 at 03:43:56PM +0200, Juergen Gross wrote:
Would you feel better with adding a new enum member CPUHP_AP_CACHECTRL_ONLINE?
This would avoid a possible source of failure during resume in case no
flight 173361 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173361/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 173358
test-amd64-amd64-xl-qemut-win7-amd64
On 29.09.22 07:36, Ajay Kaher wrote:
On 13/09/22, 7:05 PM, "Vitaly Kuznetsov" wrote:
Thanks Vitaly for your response.
1. we have multiple objects of struct pci_raw_ops, 2. adding 'priority' field
to struct pci_raw_ops
doesn't seems to be appropriate as need to take decision which object of
1: re-connect VCPUOP_send_nmi for 32-bit guests
2: wire up VCPUOP_register_vcpu_time_memory_area for 32-bit guests
As to 4.17: Patch 1 addresses a recently introduced regression, while
the issue patch 2 addresses has been there effectively forever (so
cannot really be viewed as a regression).
Jan
With the "inversion" of VCPUOP handling, processing arch-specific ones
first, the forwarding of this sub-op from the (common) compat handler to
(common) non-compat one did no longer have the intended effect. It now
needs forwarding between the arch-specific handlers.
Fixes: 8a96c0ea7999 ("xen: mov
Forever sinced its introduction VCPUOP_register_vcpu_time_memory_area
was available only to native domains. Linux, for example, would attempt
to use it irrespective of guest bitness (including in its so called
PVHVM mode) as long as it finds XEN_PVCLOCK_TSC_STABLE_BIT set (which we
set only for clo
Adding pointer to 'qemu-user-static'.
Signed-off-by: Anthony PERARD
---
Notes:
v2:
- reword to point out that it's an x86 thing
automation/build/README.md | 13 +
1 file changed, 13 insertions(+)
diff --git a/automation/build/README.md b/automation/build/README.md
index 00
Like done previously for the hypervisor and elsewhere.
1: suppress GNU ld 2.39 warning about RWX load segments
2: silence GNU ld 2.39 warning about executable stacks
Jan
We cannot really avoid such and we're also not really at risk because of
them, as we control page table permissions ourselves rather than relying
on a loader of some sort.
Signed-off-by: Jan Beulich
--- a/build/common.mk
+++ b/build/common.mk
@@ -20,9 +20,15 @@ COMMON_FLAGS := -pipe -I$(ROOT)/in
While for C files the compiler is supposed to arrange for emitting
respective information, for assembly sources we're responsible ourselves.
For the new use of cc-option to work we cannot pass -S to the compiler
anymore. We need the compiler to actually invoke the assembler, so switch
to using -c.
On 27.09.2022 17:47, Andrew Cooper wrote:
> This breaks all Clang builds, as demostrated by Gitlab CI.
>
> Contrary to the description in ecd6b9759919, -no-pie is not even an option
> passed to the linker. GCC's actual behaviour is to inhibit the passing of
> -pie to the linker, as well as select
On 28.09.2022 16:11, Roger Pau Monne wrote:
> memory_type_changed() is currently only implemented for Intel EPT, and
> results in the invalidation of EMT attributes on all the entries in
> the EPT page tables. Such invalidation causes EPT_MISCONFIG vmexits
> when the guest tries to access any gfns
On 28.09.2022 16:11, Roger Pau Monne wrote:
> The current calls to memory_type_changed() are wider than strictly
> necessary. Move them inside the iocap handlers and also limit to only
> issue them when required.
>
> I would really like to get some feedback on the Arm change, since this
> is now
Hi Juergen，
On 2022/9/28 21:03, Juergen Gross wrote:
On 28.09.22 14:06, Jan Beulich wrote:
On 28.09.2022 12:58, Andrew Cooper wrote:
On 28/09/2022 11:38, Jan Beulich wrote:
What about an alternative model allowing to use most of the current
hypercalls unmodified?
We could add a new hyperc
On Mon, Sep 26, 2022 at 02:47:55PM +0200, Jan Beulich wrote:
> On 26.09.2022 14:43, Marek Marczykowski-Górecki wrote:
> > On Thu, Sep 22, 2022 at 08:00:00PM +0200, Jan Beulich wrote:
> >> On 22.09.2022 18:05, Anthony PERARD wrote:
> >>> WARNING: Notes missing at the beginning of the meeting.
> >>>
On Thu, Sep 29, 2022 at 12:14:10PM +0200, Jan Beulich wrote:
> On 28.09.2022 16:11, Roger Pau Monne wrote:
> > The current calls to memory_type_changed() are wider than strictly
> > necessary. Move them inside the iocap handlers and also limit to only
> > issue them when required.
> >
> > I would
Hi Roger and Jan,
> -Original Message-
> From: Roger Pau Monné
> Subject: For 4.17 (was: Re: [PATCH v3 0/2] Move calls to
> memory_type_changed())
>
> On Thu, Sep 29, 2022 at 12:14:10PM +0200, Jan Beulich wrote:
> > On 28.09.2022 16:11, Roger Pau Monne wrote:
> > > The current calls to m
On Thu, Sep 29, 2022 at 11:51:03AM +0200, Jan Beulich wrote:
> With the "inversion" of VCPUOP handling, processing arch-specific ones
> first, the forwarding of this sub-op from the (common) compat handler to
> (common) non-compat one did no longer have the intended effect. It now
> needs forwardin
Hi Anthony,
> -Original Message-
> From: Anthony PERARD
> Subject: [XEN PATCH v2] automation: Information about running containers
> for a different arch
>
> Adding pointer to 'qemu-user-static'.
>
> Signed-off-by: Anthony PERARD
I didn't see the for-4.17 tag in the title but I assume
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: [PATCH 1/2][4.17] x86: re-connect VCPUOP_send_nmi for 32-bit
> guests
>
> With the "inversion" of VCPUOP handling, processing arch-specific ones
> first, the forwarding of this sub-op from the (common) compat handler to
> (commo
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: [PATCH 2/2][4.17?] x86: wire up
> VCPUOP_register_vcpu_time_memory_area for 32-bit guests
>
> Forever sinced its introduction VCPUOP_register_vcpu_time_memory_area
> was available only to native domains. Linux, for example, woul
On 28.09.2022 15:03, Juergen Gross wrote:
> On 28.09.22 14:06, Jan Beulich wrote:
>> On 28.09.2022 12:58, Andrew Cooper wrote:
>>> On 28/09/2022 11:38, Jan Beulich wrote:
As an alternative I'd like to propose the introduction of a bit (or
multiple
ones, see below) augmenting the hyp
On 29.09.2022 13:10, Henry Wang wrote:
>> -Original Message-
>> From: Roger Pau Monné
>>
>> On Thu, Sep 29, 2022 at 12:14:10PM +0200, Jan Beulich wrote:
>>> On 28.09.2022 16:11, Roger Pau Monne wrote:
The current calls to memory_type_changed() are wider than strictly
necessary.
On Thu, Sep 29, 2022 at 11:51:40AM +0200, Jan Beulich wrote:
> Forever sinced its introduction VCPUOP_register_vcpu_time_memory_area
> was available only to native domains. Linux, for example, would attempt
> to use it irrespective of guest bitness (including in its so called
> PVHVM mode) as long
On 29.09.2022 12:57, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 26, 2022 at 02:47:55PM +0200, Jan Beulich wrote:
>> On 26.09.2022 14:43, Marek Marczykowski-Górecki wrote:
>>> On Thu, Sep 22, 2022 at 08:00:00PM +0200, Jan Beulich wrote:
On 22.09.2022 18:05, Anthony PERARD wrote:
> WARN
On 29.09.2022 13:11, Roger Pau Monné wrote:
> On Thu, Sep 29, 2022 at 11:51:03AM +0200, Jan Beulich wrote:
>> With the "inversion" of VCPUOP handling, processing arch-specific ones
>> first, the forwarding of this sub-op from the (common) compat handler to
>> (common) non-compat one did no longer h
On Thu, Sep 29, 2022 at 01:44:28PM +0200, Jan Beulich wrote:
> On 29.09.2022 12:57, Marek Marczykowski-Górecki wrote:
> > On Mon, Sep 26, 2022 at 02:47:55PM +0200, Jan Beulich wrote:
> >> On 26.09.2022 14:43, Marek Marczykowski-Górecki wrote:
> >>> On Thu, Sep 22, 2022 at 08:00:00PM +0200, Jan Beul
On 29.09.2022 13:37, Roger Pau Monné wrote:
> On Thu, Sep 29, 2022 at 11:51:40AM +0200, Jan Beulich wrote:
>> Forever sinced its introduction VCPUOP_register_vcpu_time_memory_area
>> was available only to native domains. Linux, for example, would attempt
>> to use it irrespective of guest bitness (
Hi Han,
> On 29 Sep 2022, at 12:13, Jan Beulich wrote:
>
> On 28.09.2022 16:11, Roger Pau Monne wrote:
>> memory_type_changed() is currently only implemented for Intel EPT, and
>> results in the invalidation of EMT attributes on all the entries in
>> the EPT page tables. Such invalidation cause
On 29.09.2022 09:43, Wei Chen wrote:
> On 2022/9/27 16:19, Jan Beulich wrote:
>> On 20.09.2022 11:12, Wei Chen wrote:
>>> +nodes_used++;
>>> +if ( epdx > memtop )
>>> +memtop = epdx;
>>> +}
>>> +
>>> +if ( nodes_used <= 1 )
>>> +i = BITS_PER_LONG - 1;
>>
On 29.09.2022 10:21, Wei Chen wrote:
> On 2022/9/27 23:48, Jan Beulich wrote:
>> On 20.09.2022 11:12, Wei Chen wrote:
>>> --- a/xen/drivers/acpi/Kconfig
>>> +++ b/xen/drivers/acpi/Kconfig
>>> @@ -7,4 +7,5 @@ config ACPI_LEGACY_TABLES_LOOKUP
>>>
>>> config ACPI_NUMA
>>> bool
>>> + select
On 29.09.22 13:32, Jan Beulich wrote:
On 28.09.2022 15:03, Juergen Gross wrote:
On 28.09.22 14:06, Jan Beulich wrote:
On 28.09.2022 12:58, Andrew Cooper wrote:
On 28/09/2022 11:38, Jan Beulich wrote:
As an alternative I'd like to propose the introduction of a bit (or multiple
ones, see below)
On 29.09.22 13:52, Roger Pau Monné wrote:
On Thu, Sep 29, 2022 at 01:44:28PM +0200, Jan Beulich wrote:
On 29.09.2022 12:57, Marek Marczykowski-Górecki wrote:
On Mon, Sep 26, 2022 at 02:47:55PM +0200, Jan Beulich wrote:
On 26.09.2022 14:43, Marek Marczykowski-Górecki wrote:
On Thu, Sep 22, 202
On 9/29/22 04:16, Jan Beulich wrote:
On 28.09.2022 15:32, dpsmith.dev wrote:
On 9/28/22 06:38, Jan Beulich wrote:
For quite some time we've been talking about replacing the present virtual
address based hypercall interface with one using physical addresses. This is in
particular a prerequisite
On 29.09.2022 14:26, Juergen Gross wrote:
> On 29.09.22 13:32, Jan Beulich wrote:
>> Finally - in how far are we concerned of PV guests using linear
>> addresses for hypercall buffers? I ask because I don't think the model
>> lends itself to use also for the PV guest interfaces.
>
> Good question.
On 29.09.22 14:58, Jan Beulich wrote:
On 29.09.2022 14:26, Juergen Gross wrote:
On 29.09.22 13:32, Jan Beulich wrote:
Finally - in how far are we concerned of PV guests using linear
addresses for hypercall buffers? I ask because I don't think the model
lends itself to use also for the PV guest
On 26.09.2022 16:22, Tamas K Lengyel wrote:
> On Mon, Sep 26, 2022 at 10:12 AM Jan Beulich wrote:
>> On 22.09.2022 22:48, Tamas K Lengyel wrote:
>>> --- a/xen/arch/x86/cpu/vpmu.c
>>> +++ b/xen/arch/x86/cpu/vpmu.c
>>> @@ -376,57 +376,24 @@ void vpmu_save(struct vcpu *v)
>>> vpmu->last_pcpu = p
Hi Roberto,
On 9/28/22 17:11, Roberto Bagnara wrote:
On 9/26/22 10:50, Xenia Ragiadakou wrote:
On 9/18/22 16:02, Roberto Bagnara wrote:
The question is on the interpretation of Rule 20.7. Are parenthesis
required by Rule 20.7 in the following cases:
- macro parameters used as function argumen
At present we use a mix of Makefile and Kconfig driven capability checks for
tool chain components involved in the building of the hypervisor. What approach
is used where is in some part a result of the relatively late introduction of
Kconfig into the build system, but in other places also simply
Hi Anthony,
On 29/09/2022 11:51, Anthony PERARD wrote:
>
>
> Adding pointer to 'qemu-user-static'.
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Michal Orzel
~Michal
This is integration of https://github.com/connojd/xue into mainline Xen.
This patch series includes several patches that I made in the process, some are
very loosely related.
The driver developed by Connor supports console via USB3 debug capability. The
capability is designed to operate mostly ind
Re-use rmrr= parameter handling code to handle common device reserved
memory.
Move MAX_USER_RMRR_PAGES limit enforcement to apply only to
user-configured ranges, but not those from internal callers.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Kevin Tian
---
Changes in v8:
- move add_
Similar to the EHCI driver - save/restore relevant BAR and command
register, re-configure DbC on resume and stop/start timer.
On resume trigger sending anything that was queued in the meantime.
Save full BAR value, instead of just the address part, to ease restoring
on resume.
Signed-off-by: Marek
On Thu, Sep 29, 2022 at 9:07 AM Jan Beulich wrote:
> On 26.09.2022 16:22, Tamas K Lengyel wrote:
> > On Mon, Sep 26, 2022 at 10:12 AM Jan Beulich wrote:
> >> On 22.09.2022 22:48, Tamas K Lengyel wrote:
> >>> --- a/xen/arch/x86/cpu/vpmu.c
> >>> +++ b/xen/arch/x86/cpu/vpmu.c
> >>> @@ -376,57 +376,
On 29.09.2022 16:28, Tamas K Lengyel wrote:
> On Thu, Sep 29, 2022 at 9:07 AM Jan Beulich wrote:
>
>> On 26.09.2022 16:22, Tamas K Lengyel wrote:
>>> On Mon, Sep 26, 2022 at 10:12 AM Jan Beulich wrote:
On 22.09.2022 22:48, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++
On Tue, Sep 27, 2022 at 04:14:21PM +0200, Jan Beulich wrote:
> extract_lsb_from_nodes() accumulates "memtop" from all PDXes one past
> the covered ranges. Hence the maximum address which can validly by used
> to index the node map is one below this value, and we may currently set
> up a node map wi
On Mon, 19 Sep 2022, Michal Orzel wrote:
> At the moment, the information about allocating static shared memory
> region is only printed during the debug build. This information can also
> be helpful for the end user (which may not be the same as the person
> building the package), so switch to pri
On Thu, 29 Sep 2022, Michal Orzel wrote:
> Hi Anthony,
>
> On 29/09/2022 11:51, Anthony PERARD wrote:
> >
> >
> > Adding pointer to 'qemu-user-static'.
> >
> > Signed-off-by: Anthony PERARD
>
> Reviewed-by: Michal Orzel
Acked-by: Stefano Stabellini
On 24.08.2022 15:27, Matias Ezequiel Vara Larsen wrote:
> The purpose of this RFC is to get feedback about a new acquire resource that
> exposes vcpu statistics for a given domain. The current mechanism to get those
> statistics is by querying the hypervisor. This mechanism relies on a hypercall
>
Hi Elliott,
Thanks!
Any input from your side on this issue will be really helpful.
Looking forward to hearing from you asap.
Regards,
Vipul Kumar
On Tue, Sep 27, 2022 at 11:47 PM Vipul Suneja wrote:
> Hi Elliott,
>
> Thanks!
>
> As per the link you shared, VNC & SDL are two ways to get GUI di
flight 173362 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173362/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 173347
Tests which
On 29/09/2022 17:22, osstest service owner wrote:
> flight 173362 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/173362/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64-xsm
flight 173367 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173367/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 173347
Tests which
flight 173363 qemu-mainline real [real]
flight 173371 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173363/
http://logs.test-lab.xenproject.org/osstest/logs/173371/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-ar
flight 173370 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173370/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 173347
Tests which
This fixes EFI table processing in Xen dom0 and adds ESRT support in
that configuration.
Changes since v3:
- Check location of all configuration tables, not just the ESRT.
- Move most Xen-specific code to drivers/xen/.
- Allow configuration tables to be in EFI_ACPI_RECLAIM_MEMORY.
Demi Marie Obe
Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
Xen before Linux gets to start using it. Therefore, Linux under Xen
must not use EFI tables from such memory. Most of the remaining EFI
memory types are
fwupd requires access to the EFI System Resource Table (ESRT) to
discover which firmware can be updated by the OS. Currently, Linux does
not expose the ESRT when running as a Xen dom0. Therefore, it is not
possible to use fwupd in a Xen dom0, which is a serious problem for e.g.
Qubes OS.
Before
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced:
flight 173364 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173364/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173360
test-armhf-armhf-libvirt 16 saver
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年9月29日 20:21
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v5 5/6] xen/x86: move NUMA scan n
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2022年9月29日 20:14
> To: Wei Chen
> Cc: nd ; Andrew Cooper ; Roger Pau
> Monné ; Wei Liu ; George Dunlap
> ; Julien Grall ; Stefano
> Stabellini ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v5 2/6] xen/x86: move generically
Hi Jan,
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 2022年9月27日 22:14
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ; Roger
> Pau Monné
> Subject: [PATCH] x86/NUMA: correct off-by-1 in node map size calculation
>
> extract_lsb_from_nodes
flight 173375 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173375/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 173347
Tests which
flight 173380 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173380/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 173347
Tests which
On 30.09.2022 03:40, Wei Chen wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2022年9月29日 20:21
>>
>> On 29.09.2022 10:21, Wei Chen wrote:
>>> On 2022/9/27 23:48, Jan Beulich wrote:
On 20.09.2022 11:12, Wei Chen wrote:
> --- a/xen/drivers/acpi/Kconfig
> +++ b/xen/dri
While an oversight in 9982fe275ba4 ("arm/vgic: drop const attribute
from gic_iomem_deny_access()"), the issue really became apparent only
when iomem_deny_access() was switched to have a non-const first
parameter.
Fixes: c4e5cc2ccc5b ("x86/ept: limit calls to memory_type_changed()")
Reported-by: An
On 29.09.2022 18:25, Andrew Cooper wrote:
> On 29/09/2022 17:22, osstest service owner wrote:
>> flight 173362 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/173362/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests whic
On 30.09.2022 01:02, Demi Marie Obenour wrote:
> Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> Xen before Linux gets to start using it. Therefore, Linux under Xen
> must not use EFI tables from s
74 matches
Mail list logo
