Hi Jan,
On 2022/9/27 15:37, Jan Beulich wrote:
On 20.09.2022 11:12, Wei Chen wrote:
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -50,9 +50,28 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
bool numa_off;
s8 acpi_numa = 0;
-int srat_disabled(void)
+int __init
> 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
>> struct pci_raw_op
Hello:
This series was applied to netdev/net-next.git (master)
by Jakub Kicinski :
On Fri, 23 Sep 2022 17:39:00 +0100 you wrote:
> struct ubuf_info is large but not all fields are needed for all
> cases. We have limited space in io_uring for it and large ubuf_info
> prevents some struct embedding
flight 173360 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173360/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 173339
Tests which did not succeed,
flight 173358 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173358/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 173349
test-armhf-armhf-xl-rtds
flight 173353 linux-5.4 real [real]
flight 173359 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173353/
http://logs.test-lab.xenproject.org/osstest/logs/173359/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386
flight 173349 xen-unstable real [real]
flight 173357 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173349/
http://logs.test-lab.xenproject.org/osstest/logs/173357/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Wed, Sep 28, 2022 at 06:32:20PM +0200, Juergen Gross wrote:
> I can do that.
Thx!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
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 slot
for CPUHP_AP_ONLINE_DYN is found (q
flight 173356 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173356/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b7213bbd59833fb0786c83a28df5f8244602ab5e
baseline version:
ovmf 3c0d567c3719675b9d8ec
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 slot
> for CPUHP_AP_ONLINE_DYN is found (quite improbable, but in theory possib
flight 173343 qemu-mainline real [real]
flight 173355 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173343/
http://logs.test-lab.xenproject.org/osstest/logs/173355/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
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 invocations. Furthermore without
> (further) locking by cal
Hi Roger,
> On 28 Sep 2022, at 16:11, Roger Pau Monne wrote:
>
> While correct from a code point of view, the usage of the const
> attribute for the domain parameter of gic_iomem_deny_access() is at
> least partially bogus. Contents of the domain structure (the iomem
> rangeset) is modified by
flight 173354 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173354/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3c0d567c3719675b9d8ecf07c31706d96467e31b
baseline version:
ovmf f4d539007c706ad9a563f
While correct from a code point of view, the usage of the const
attribute for the domain parameter of gic_iomem_deny_access() is at
least partially bogus. Contents of the domain structure (the iomem
rangeset) is modified by the function. Such modifications succeed
because right now the iomem rang
Hi Xenia. Please see below.
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 arguments
> [...]
> - macro p
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 for the first time, which
results in the recalculat
Hello,
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 a prereq for the actual fix.
Thanks, Roger.
Ro
On 28.09.22 13:22, Borislav Petkov wrote:
On Wed, Sep 28, 2022 at 01:14:11PM +0200, Juergen Gross wrote:
No, we don't.
Using basically your patch, but with
+ mtrr_online = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+ "x86/mtrr:online",
+
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 guests with encrypted
memory, as for such guests we c
On 28.09.2022 15:08, Roger Pau Monné wrote:
> On Wed, Sep 28, 2022 at 12:45:13PM +0200, Jan Beulich wrote:
>> On 28.09.2022 12:08, Roger Pau Monné wrote:
>>> On Wed, Sep 28, 2022 at 10:01:26AM +0200, Jan Beulich wrote:
On 27.09.2022 17:39, Roger Pau Monne wrote:
> --- a/xen/include/xen/ioc
flight 173345 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173345/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 173325
test-armhf-armhf-libvirt-raw 15 saveresto
On Wed, Sep 28, 2022 at 12:45:13PM +0200, Jan Beulich wrote:
> On 28.09.2022 12:08, Roger Pau Monné wrote:
> > On Wed, Sep 28, 2022 at 10:01:26AM +0200, Jan Beulich wrote:
> >> On 27.09.2022 17:39, Roger Pau Monne wrote:
> >>> memory_type_changed() is currently only implemented for Intel EPT, and
>
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 hypercall number, to control the flavor of the
buffers used for ev
On 27.09.2022 18:08, Jan Beulich wrote:
> On 27.09.2022 17:53, Roger Pau Monné wrote:
>> On Tue, Sep 27, 2022 at 04:15:19PM +0200, Jan Beulich wrote:
>>> @@ -127,7 +128,7 @@ static int __init extract_lsb_from_nodes
>>> if ( spdx >= epdx )
>>> continue;
>>> bitfield |=
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 invocations. Furthermore without
(further) locking by callers, return values are stale anyway by the time
they can be evaluate
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 hypercall number, to control the flavor of
>> the
>> buffers used for every individual hypercall.
On Wed, Sep 28, 2022 at 01:14:11PM +0200, Juergen Gross wrote:
> No, we don't.
>
> Using basically your patch, but with
>
> + mtrr_online = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
> + "x86/mtrr:online",
> +
On 28.09.22 12:48, Borislav Petkov wrote:
On Wed, Sep 28, 2022 at 08:16:53AM +0200, Juergen Gross wrote:
Are sure the hotplug notifier doesn't get called in the boot and in the
It doesn't because it gets registered after smp_init()...
resume cases?
... but it gets called during resume beca
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 hypercall number, to control the flavor of the
> buffers used for every individual hypercall. This would likely involve the
> introduction of a n
flight 173339 linux-linus real [real]
flight 173352 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173339/
http://logs.test-lab.xenproject.org/osstest/logs/173352/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Wed, Sep 28, 2022 at 08:16:53AM +0200, Juergen Gross wrote:
> > Are sure the hotplug notifier doesn't get called in the boot and in the
It doesn't because it gets registered after smp_init()...
> > resume cases?
... but it gets called during resume because by that time the notifier
has been r
On 28.09.2022 12:08, Roger Pau Monné wrote:
> On Wed, Sep 28, 2022 at 10:01:26AM +0200, Jan Beulich wrote:
>> On 27.09.2022 17:39, 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 i
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 guests with encrypted
memory, as for such guests we cannot perform the page table walks nece
On 12.09.22 11:10, Juergen Gross wrote:
On 11.09.22 12:16, Borislav Petkov wrote:
On Thu, Sep 08, 2022 at 10:49:07AM +0200, Juergen Gross wrote:
diff --git a/arch/x86/include/asm/cacheinfo.h b/arch/x86/include/asm/cacheinfo.h
index 86b2e0dcc4bf..1aeafa9888f7 100644
--- a/arch/x86/include/asm/ca
On Wed, Sep 28, 2022 at 10:01:26AM +0200, Jan Beulich wrote:
> On 27.09.2022 17:39, 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 c
On 27.09.2022 09:02, Juergen Gross wrote:
> On 26.09.22 17:52, Jan Beulich wrote:
>> On 26.09.2022 10:33, Juergen Gross wrote:
>>> On 26.09.22 09:53, Jan Beulich wrote:
On 23.09.2022 10:20, Juergen Gross wrote:
> My favorite solution would be some kind of buffer address qualifier for
flight 173347 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173347/
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 1
On 27.09.2022 17:39, 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
flight 173338 xen-unstable real [real]
flight 173348 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173338/
http://logs.test-lab.xenproject.org/osstest/logs/173348/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
41 matches
Mail list logo
