Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年11月10日 2:30
> To: Wei Chen ; xen-devel@lists.xenproject.org
> Cc: nd ; Stefano Stabellini ; Bertrand
> Marquis ; Volodymyr Babchuk
>
> Subject: Re: [PATCH v6 07/11] xen/arm: implement FIXMAP_ADDR for MPU
> systems
>
>
>
On 10.11.2022 23:47, Andrew Cooper wrote:
> On 04/11/2022 16:18, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/viridian/viridian.c
>> +++ b/xen/arch/x86/hvm/viridian/viridian.c
>> @@ -197,7 +197,7 @@ void cpuid_viridian_leaves(const struct vcpu *v,
>> uint32_t leaf,
>> res->a =
flight 174730 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174730/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c8fb7240469b5753773da4fa5710b870b790c363
baseline version:
ovmf
flight 174724 xen-unstable real [real]
flight 174732 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174724/
http://logs.test-lab.xenproject.org/osstest/logs/174732/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi
> -Original Message-
> From: Stefano Stabellini
> Sent: Friday, November 11, 2022 4:33 AM
> To: Michal Orzel
> Cc: Jiamei Xie ; xen-devel@lists.xenproject.org; Wei
> Chen ; Bertrand Marquis
> ; jul...@xen.org; sstabell...@kernel.org
> Subject: Re: Xen Arm vpl011 UART will cause
flight 174729 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174729/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 342813a3f7794bf67405a236053f27c916804d36
baseline version:
ovmf
flight 174708 qemu-mainline real [real]
flight 174728 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174708/
http://logs.test-lab.xenproject.org/osstest/logs/174728/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Vipul,
Sorry for the late reply. From the earlier logs that you sent, it looks
like everything should be working correctly. Specifically:
vfb = ""
1 = ""
0 = ""
frontend = "/local/domain/1/device/vfb/0"
frontend-id = "1"
online = "1"
state =
flight 174706 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174706/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 174685
test-armhf-armhf-libvirt-raw 15
Hi Anthony,
Thank you for doing this, it was much needed!
Hi all,
I think if we are going to commit this series for 4.17 then I would
suggest to also commit patches 1-3 of my "introduce SPDX" series:
https://marc.info/?l=xen-devel=16656522996
They are already acked/reviewed and are zero
flight 174725 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174725/
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
On Mon, 31 Oct 2022, Bertrand Marquis wrote:
> Hi All,
>
> > On 30 Oct 2022, at 21:14, Stefano Stabellini wrote:
> >
> > On Sun, 30 Oct 2022, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 30/10/2022 14:23, Stefano Stabellini wrote:
> >>> On Fri, 28 Oct 2022, Julien Grall wrote:
> On
On 04/11/2022 16:18, Roger Pau Monne wrote:
> The current reporting of the hardware assisted APIC options is done by
> checking "virtualize APIC accesses" which is not very helpful, as that
> feature doesn't avoid a vmexit, instead it does provide some help in
> order to detect APIC MMIO accesses
On Mon, 7 Nov 2022, Wei Chen wrote:
> Hi Julien,
>
> > -Original Message-
> > From: Julien Grall
> > Sent: 2022年11月7日 18:16
> > To: Wei Chen ; xen-devel@lists.xenproject.org
> > Cc: nd ; Stefano Stabellini ; Bertrand
> > Marquis ; Volodymyr Babchuk
> >
> > Subject: Re: [PATCH v6 00/11]
On Wed, 9 Nov 2022, Julien Grall wrote:
> > > -Original Message-
> > > From: Julien Grall
> > > Sent: 2022年11月7日 3:20
> > > To: Wei Chen ; xen-devel@lists.xenproject.org
> > > Cc: nd ; Stefano Stabellini ;
> > > Bertrand
> > > Marquis ; Volodymyr Babchuk
> > > ; Jiamei Xie
> > >
flight 174704 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174704/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail REGR. vs. 174540
Tests which are
flight 174703 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 173462
On Wed, 9 Nov 2022, Michal Orzel wrote:
> Hi Jiamei,
>
> On 09/11/2022 09:25, Jiamei Xie wrote:
> >
> >
> > Hi Michal，
> >
> > Below log can be got when stating the linux guest. It says 9c09 is sbsa.
> > And 9c09 is also output
> > in bootlogd error message:
> > Serial: AMBA PL011 UART
On Thu, 10 Nov 2022, Michal Orzel wrote:
> Hi Stefano,
>
> On 10/11/2022 01:18, Stefano Stabellini wrote:
> >
> >
> > On Mon, 7 Nov 2022, Michal Orzel wrote:
> >> Hi Bertrand and Stefano,
> >>
> >> On 31/10/2022 16:00, Bertrand Marquis wrote:
> >>>
> >>>
> >>> Hi Michal,
> >>>
> On 31 Oct
On 11/10/22 11:07, Dave Hansen wrote:
On 11/10/22 07:45, Ross Philipson wrote:
dt = early_memremap(initial_dtb, map_len);
+ if (!dt) {
+ pr_warn("failed to memremap initial dtb\n");
+ return;
+ }
Are all of these new pr_warn/err()'s really
On Thu, Nov 10, 2022 at 05:31:44PM +0100, Roger Pau Monne wrote:
> The current logic in the Intel PMC driver will forcefully attach it
> when detecting any CPU on the intel_pmc_core_platform_ids array,
> even if the matching ACPI device is not present.
>
> There's no checking in pmc_core_probe()
On 11/10/22 13:07, Peter Zijlstra wrote:
On Thu, Nov 10, 2022 at 03:45:21PM +, Ross Philipson wrote:
On allocation failures, panic() was used since this seemed
to be the action taken on other failures in the modules
touched by this patch.
How is the panic() more useful than the obvious
flight 174701 xen-unstable real [real]
flight 174723 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174701/
http://logs.test-lab.xenproject.org/osstest/logs/174723/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Bertrand,
On 10/11/2022 08:46, Bertrand Marquis wrote:
On 9 Nov 2022, at 14:04, Luca Fancellu wrote:
The commit 3c2a14ea81c7 is introducing some unsupported arm features
that by default are disabled and are used for the cpufeature.c code.
As they are disabled by default, a typo in the
Hi,
On 10/11/2022 00:00, Stefano Stabellini wrote:
On Tue, 8 Nov 2022, Ayan Kumar Halder wrote:
From: Ayan Kumar Halder
Xen provides helper to atomically read/write memory (see {read,
write}_atomic()). Those helpers can only work if the address is aligned
to the size of the access (see
A debug statement got introduced and code not reindented
(as it was part of a security fix and was trying to avoid that),
however that resulted in *only* the debug statement being part of the 'if',
and everything else outside of it.
This results in some unnecessary ring checks for domains which
On Thu, Nov 10, 2022 at 03:45:21PM +, Ross Philipson wrote:
> On allocation failures, panic() was used since this seemed
> to be the action taken on other failures in the modules
> touched by this patch.
How is the panic() more useful than the obvious NULL deref that also
splats?
Concurrent access the the MSI-X control register are not serialized
with a suitable lock. For example, in msix_capability_init() access
use the pcidevs_lock() but some calls to msi_set_mask_bit() use the
interrupt descriptor lock.
This can lead to MSI-X being incorrectly disabled and subsequent
The main patch in this series is 3/3 with some preparatory patches to
simplify the implementation. To summarize:
Concurrent access the the MSI-X control register are not serialized
with a suitable lock. For example, in msix_capability_init() access
use the pcidevs_lock() but some
When setting up an MSI-X vector in msix_capability_init() the error
handling after a BAR mapping failure is different depending on whether
the first page fails or a subsequent page. There's no reason to break
working vectors so consistently use the later error handling
behaviour.
The zap_on_error
The return value was only used for WARN()s or BUG()s so it has no
functional purpose. Simplify the code by removing it.
The meaning of the return value and the purpose of the various WARNs()
and BUGs() is rather unclear. The only failure path (where an MSI-X
vector needs to be masked but the
On 22.10.2022 17:51, Carlo Nonato wrote:
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -661,7 +661,12 @@ static int p2m_create_table(struct p2m_domain *p2m,
> lpae_t *entry)
>
> ASSERT(!p2m_is_valid(*entry));
>
> -page = alloc_domheap_page(NULL, 0);
> +/* If cache
The current logic in the Intel PMC driver will forcefully attach it
when detecting any CPU on the intel_pmc_core_platform_ids array,
even if the matching ACPI device is not present.
There's no checking in pmc_core_probe() to assert that the PMC device
is present, and hence on virtualized
On 11/10/22 07:45, Ross Philipson wrote:
> dt = early_memremap(initial_dtb, map_len);
> + if (!dt) {
> + pr_warn("failed to memremap initial dtb\n");
> + return;
> + }
Are all of these new pr_warn/err()'s really adding much value? They all
look pretty
On 10.11.22 16:45, Ross Philipson wrote:
There are a number of places where early_memremap is called
but the return pointer is not checked for NULL. The call
can result in a NULL being returned so the checks must
be added.
Note that the maintainers for both the Jailhouse and Xen code
approved
While sending an earlier patch set it was discovered that there are a
number of places in early x86 code were the functions early_memremap()
and early_ioremap() are called but the returned pointer is not checked
for NULL. Since NULL can be returned for a couple of reasons, the return
value should
On 10.11.22 16:24, Yang Yingliang wrote:
In device_add(), dev_set_name() is called to allocate name, if it returns
error, the name need be freed. As comment of device_register() says, it
should use put_device() to give up the reference in the error path. So fix
this by calling put_device(), then
There are a number of places where early_ioremap is called
but the return pointer is not checked for NULL. The call
can result in a NULL being returned so the checks must
be added.
On allocation failures, panic() was used since this seemed
to be the action taken on other failures in the modules
There are a number of places where early_memremap is called
but the return pointer is not checked for NULL. The call
can result in a NULL being returned so the checks must
be added.
Note that the maintainers for both the Jailhouse and Xen code
approved of using panic() to handle allocation
Hi Anthony,
> On 10 Nov 2022, at 13:20, Anthony PERARD wrote:
>
> On Mon, Nov 07, 2022 at 08:50:09AM +0100, Michal Orzel wrote:
>> 3) Try to use CI to build and push the containers to registry
>> - it could be possible but what about local users
>
> FYI, it's already possible to build and push
On 28.10.2022 13:41, Juergen Gross wrote:
> Today all users of notifier_from_errno() and notifier_to_errno() are
> Handling the success case the same way, by using
>
> !rc ? NOTIFY_DONE : notifier_from_errno(rc)
>
> or
>
> (notifier_rc == NOTIFY_DONE) ? 0 : notifier_to_errno(notifier_rc);
>
In device_add(), dev_set_name() is called to allocate name, if it returns
error, the name need be freed. As comment of device_register() says, it
should use put_device() to give up the reference in the error path. So fix
this by calling put_device(), then the name can be freed in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-23824 / XSA-422
version 2
x86: Multiple speculative security issues
UPDATES IN VERSION 2
Change the URL referenced for the Branch Type
On Thu, Nov 10, 2022 at 02:33:35PM +0100, Roger Pau Monne wrote:
> The current logic in the Intel PMC driver will forcefully attach it
> when detecting any CPU on the intel_pmc_core_platform_ids array,
> even if the matching ACPI device is not present.
>
> There's no checking in pmc_core_probe()
The current logic in the Intel PMC driver will forcefully attach it
when detecting any CPU on the intel_pmc_core_platform_ids array,
even if the matching ACPI device is not present.
There's no checking in pmc_core_probe() to assert that the PMC device
is present, and hence on virtualized
On Mon, Nov 07, 2022 at 08:50:09AM +0100, Michal Orzel wrote:
> 3) Try to use CI to build and push the containers to registry
> - it could be possible but what about local users
FYI, it's already possible to build and push container from the CI, at
least on X86, I've made it work:
flight 174695 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174695/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 174678
flight 174690 xen-4.15-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174690/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 174572
Hello,
On 10/11/2022 11:08, Bertrand Marquis wrote:
>
>
> Hi Michal,
>
>> On 10 Nov 2022, at 07:34, Michal Orzel wrote:
>>
>> Hi Stefano,
>>
>> On 10/11/2022 01:18, Stefano Stabellini wrote:
>>>
>>>
>>> On Mon, 7 Nov 2022, Michal Orzel wrote:
Hi Bertrand and Stefano,
On
Hi Christian,
> -Original Message-
> From: Christian Lindig
> Subject: Re: [PATCH for-4.17 v3 07/15] CODING_STYLE(tools/ocaml): add
> 'make format' and remove tabs
> > On 10 Nov 2022, at 09:25, Henry Wang wrote:
> >
> > Hi Christian,
> >
> >> -Original Message-
> >> From:
Hi Michal,
> On 10 Nov 2022, at 07:34, Michal Orzel wrote:
>
> Hi Stefano,
>
> On 10/11/2022 01:18, Stefano Stabellini wrote:
>>
>>
>> On Mon, 7 Nov 2022, Michal Orzel wrote:
>>> Hi Bertrand and Stefano,
>>>
>>> On 31/10/2022 16:00, Bertrand Marquis wrote:
Hi Michal,
> On 10 Nov 2022, at 09:25, Henry Wang wrote:
>
> Hi Christian,
>
>> -Original Message-
>> From: Christian Lindig
>> Subject: Re: [PATCH for-4.17 v3 07/15] CODING_STYLE(tools/ocaml): add
>> 'make format' and remove tabs
While I understand the goal and support, this seems to be a
Hi Christian,
> -Original Message-
> From: Christian Lindig
> Subject: Re: [PATCH for-4.17 v3 07/15] CODING_STYLE(tools/ocaml): add
> 'make format' and remove tabs
> >> While I understand the goal and support, this seems to be a bit too late
> >> to do it in Xen 4.17 (we are only a
On 09.11.2022 14:22, Roger Pau Monné wrote:
> On Wed, Nov 09, 2022 at 01:02:28PM +0100, Jan Beulich wrote:
>> On 09.11.2022 12:36, Roger Pau Monné wrote:
>>> Since I don't see replies to my other comments, do you agree on
>>> returning an error then?
>>
>> No, my view there hasn't changed. I
On 09.11.2022 17:11, Andrew Cooper wrote:
> On 08/11/2022 11:38, Roger Pau Monne wrote:
>> Like on the Arm side, return -EINVAL when attempting to do a p2m
>> operation on dying domains.
>
> Honestly, I'd drop the comment about ARM. "the Arm side" has existed
> for of all of a couple of weeks.
>
Hi Jan,
> On 10 Nov 2022, at 08:18, Jan Beulich wrote:
>
> On 10.11.2022 03:48, osstest service owner wrote:
>> flight 174684 linux-5.4 real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/174684/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>>
Hi Luca,
> On 9 Nov 2022, at 14:04, Luca Fancellu wrote:
>
> The commit 3c2a14ea81c7 is introducing some unsupported arm features
> that by default are disabled and are used for the cpufeature.c code.
>
> As they are disabled by default, a typo in the Kconfig symbol they
> depend on has landed
> On 9 Nov 2022, at 02:40, Henry Wang wrote:
>
>>
>> -Original Message-
>> From: Julien Grall
>> Subject: Re: [PATCH for-4.17 v3 07/15] CODING_STYLE(tools/ocaml): add
>> 'make format' and remove tabs
>> While I understand the goal and support, this seems to be a bit too late
>> to do
On 10.11.2022 03:48, osstest service owner wrote:
> flight 174684 linux-5.4 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/174684/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-armhf-xl-credit2 18
On 09.11.2022 21:16, George Dunlap wrote:
>> On 4 Nov 2022, at 05:01, Andrew Cooper wrote:
>> On 03/11/2022 16:36, Juergen Gross wrote:
>>> The code generated for the call_handlers_*() macros needs to avoid
>>> undefined behavior when multiple handlers share the same priority.
>>> The issue is
60 matches
Mail list logo
