flight 185941 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185941/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2727231b0a6fb4c043479d132df4d36cf9f751c2
baseline version:
ovmf
flight 185940 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185940/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185936
Hi Julien,
On 5/7/2024 10:35 PM, Julien Grall wrote:
Hi,
On 06/05/2024 06:17, Henry Wang wrote:
On 5/1/2024 9:58 PM, Anthony PERARD wrote:
On Wed, Apr 24, 2024 at 11:34:39AM +0800, Henry Wang wrote:
Increase number of spi to 160 i.e. gic_number_lines() for Xilinx
ZynqMP - 32.
This was done
On Tue, 7 May 2024, Julien Grall wrote:
> Hi Stefano,
>
> On 03/05/2024 20:07, Stefano Stabellini wrote:
> > On Fri, 3 May 2024, Julien Grall wrote:
>
> [...]
>
> > > So are you saying that from Xen point of view, you are expecting no
> > > difference
> > > between 256 and 512. And therefore
Hi Henry,
On 06/05/2024 09:32, Henry Wang wrote:
On 5/1/2024 4:13 AM, Julien Grall wrote:
Hi Henry,
On 30/04/2024 04:50, Henry Wang wrote:
On 4/25/2024 10:28 PM, Julien Grall wrote:
Thanks for your feeedback. After checking the b8577547236f commit
message I think I now understand your
flight 185939 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185939/
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 07/05/2024 17:55, Edgar E. Iglesias wrote:
On Tue, May 7, 2024 at 11:57 AM Julien Grall wrote:
Hi Julien,
Hi Edgar,
The reason I choose FUNC for the start of the symbol is because these
symbols contain
executable code (not only a table of pointers to code somewhere else)
and the ELF
On Thu, May 2, 2024 at 10:02 PM Stefano Stabellini
wrote:
>
> On Thu, 2 May 2024, Edgar E. Iglesias wrote:
> > On Thu, May 2, 2024 at 8:53 PM Stefano Stabellini
> > wrote:
> > >
> > > +Xenia
> > >
> > > On Thu, 2 May 2024, Edgar E. Iglesias wrote:
> > > > On Wed, May 1, 2024 at 11:24 PM Stefano
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-457
Linux/xen-netback: Memory leak due to missing cleanup function
ISSUE DESCRIPTION
=
In netback, xennet_alloc_one_rx_buffer() failed to call the
appropriate clean-up function,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2024-2201 / XSA-456
version 3
x86: Native Branch History Injection
UPDATES IN VERSION 3
Issues were found with the original code changes.
On Tue, May 7, 2024 at 11:57 AM Julien Grall wrote:
>
> Hi,
>
> On 06/05/2024 13:54, Edgar E. Iglesias wrote:
> > On Sat, May 4, 2024 at 2:14 AM Stefano Stabellini
> > wrote:
> >>
> >> On Wed, 1 May 2024, Edgar E. Iglesias wrote:
> >>> From: "Edgar E. Iglesias"
> >>>
> >>> Use the generic
On Tue, May 07, 2024, Mickaël Salaün wrote:
> > Actually, potential bad/crazy idea. Why does the _host_ need to define
> > policy?
> > Linux already knows what assets it wants to (un)protect and when. What's
> > missing
> > is a way for the guest kernel to effectively deprivilege and
On 20/02/2024 10:51, Jan Beulich wrote:
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)
This only lifts the mapcache variable up. Whether we populate the
mapcache for a domain is unchanged in this patch.
Is it? I wonder because of ...
I agree, the commit message doesn't completely reflect the changes below.
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -843,6
> On 20/02/2024 10:28, Jan Beulich wrote:
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
flight 185936 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185936/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185929
On 07/05/2024 3:45 pm, Roger Pau Monné wrote:
> On Tue, May 07, 2024 at 03:31:19PM +0100, Andrew Cooper wrote:
>> On 07/05/2024 3:24 pm, Roger Pau Monné wrote:
>>> On Tue, May 07, 2024 at 02:45:40PM +0100, Andrew Cooper wrote:
Ever since Xen 4.14, there has been a latent bug with migration.
On Tue, May 07, 2024 at 03:31:19PM +0100, Andrew Cooper wrote:
> On 07/05/2024 3:24 pm, Roger Pau Monné wrote:
> > On Tue, May 07, 2024 at 02:45:40PM +0100, Andrew Cooper wrote:
> >> Ever since Xen 4.14, there has been a latent bug with migration.
> >>
> >> While some toolstacks can level the
Hi,
On 06/05/2024 06:17, Henry Wang wrote:
On 5/1/2024 9:58 PM, Anthony PERARD wrote:
On Wed, Apr 24, 2024 at 11:34:39AM +0800, Henry Wang wrote:
Increase number of spi to 160 i.e. gic_number_lines() for Xilinx
ZynqMP - 32.
This was done to allocate and assign IRQs to a running domain.
On 07/05/2024 3:24 pm, Roger Pau Monné wrote:
> On Tue, May 07, 2024 at 02:45:40PM +0100, Andrew Cooper wrote:
>> Ever since Xen 4.14, there has been a latent bug with migration.
>>
>> While some toolstacks can level the features properly, they don't shink
>> feat.max_subleaf when all features
On Tue, May 07, 2024 at 01:32:00PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, May 07, 2024 at 12:08:06PM +0100, Andrew Cooper wrote:
> > `xl devd` has been observed leaking /var/log/xldevd.log into children.
> >
> > Link: https://github.com/QubesOS/qubes-issues/issues/8292
> >
On 07/05/2024 3:23 pm, Marek Marczykowski-Górecki wrote:
> On Tue, May 07, 2024 at 03:15:48PM +0100, Andrew Cooper wrote:
>> On 07/05/2024 12:32 pm, Marek Marczykowski-Górecki wrote:
>>> On Tue, May 07, 2024 at 12:08:06PM +0100, Andrew Cooper wrote:
`xl devd` has been observed leaking
On Tue, May 07, 2024 at 02:45:40PM +0100, Andrew Cooper wrote:
> Ever since Xen 4.14, there has been a latent bug with migration.
>
> While some toolstacks can level the features properly, they don't shink
> feat.max_subleaf when all features have been dropped. This is because
> we *still* have
On Tue, May 07, 2024 at 03:15:48PM +0100, Andrew Cooper wrote:
> On 07/05/2024 12:32 pm, Marek Marczykowski-Górecki wrote:
> > On Tue, May 07, 2024 at 12:08:06PM +0100, Andrew Cooper wrote:
> >> `xl devd` has been observed leaking /var/log/xldevd.log into children.
> >>
> >> Link:
Hi Michal,
int __init process_shm(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
{
@@ -249,32 +290,10 @@ int __init process_shm(struct domain *d, struct
kernel_info *kinfo,
if (
On 07/05/2024 12:32 pm, Marek Marczykowski-Górecki wrote:
> On Tue, May 07, 2024 at 12:08:06PM +0100, Andrew Cooper wrote:
>> `xl devd` has been observed leaking /var/log/xldevd.log into children.
>>
>> Link: https://github.com/QubesOS/qubes-issues/issues/8292
>> Reported-by: Demi Marie Obenour
Hi Michal,
>>
@@ -440,6 +431,26 @@ int __init process_shm_node(const void *fdt, int
node, uint32_t address_cells,
device_tree_get_reg(, address_cells, address_cells, ,
);
size = dt_next_cell(size_cells, );
+if ( !IS_ALIGNED(paddr, PAGE_SIZE)
On 07/05/2024 15:57, Luca Fancellu wrote:
>
>
> Hi Michal,
>
>>>
>>> +static int __init handle_shared_mem_bank(struct domain *d, paddr_t gbase,
>>> + bool owner_dom_io,
>>> + const char *role_str,
>>> +
On 07/05/2024 15:44, Luca Fancellu wrote:
>
>
> Hi Michal,
>
> Thanks for your review.
>
>> On 6 May 2024, at 14:24, Michal Orzel wrote:
>>
>> Hi Luca,
>>
>> On 23/04/2024 10:25, Luca Fancellu wrote:
>>>
>>>
>>> The current static shared memory code is using bootinfo banks when it
>>>
Hi Michal,
>>
>> +static int __init handle_shared_mem_bank(struct domain *d, paddr_t gbase,
>> + bool owner_dom_io,
>> + const char *role_str,
>> + const struct membank
Hello,
Please could we request a CVE for "xen-netfront: Add missing
skb_mark_for_recycle" which is 037965402a010898d34f4e35327d22c0a95cd51f
in Linus' tree.
This is a kernel memory leak trigger-able from unprivileged userspace.
I can't see any evidence of this fix having been assigned a CVE thus
Ever since Xen 4.14, there has been a latent bug with migration.
While some toolstacks can level the features properly, they don't shink
feat.max_subleaf when all features have been dropped. This is because
we *still* have not completed the toolstack side work for full CPU Policy
objects.
As a
Hi Michal,
Thanks for your review.
> On 6 May 2024, at 14:24, Michal Orzel wrote:
>
> Hi Luca,
>
> On 23/04/2024 10:25, Luca Fancellu wrote:
>>
>>
>> The current static shared memory code is using bootinfo banks when it
>> needs to find the number of borrower, so every time
Hi Julien,
> On 7 May 2024, at 14:20, Julien Grall wrote:
>
> Hi Luca,
>
> On 23/04/2024 09:25, Luca Fancellu wrote:
>> From: Penny Zheng
>> We are doing foreign memory mapping for static shared memory, and
>> there is a great possibility that it could be super mapped.
>
> Is this because we
Hi Luca,
On 23/04/2024 09:25, Luca Fancellu wrote:
From: Penny Zheng
We are doing foreign memory mapping for static shared memory, and
there is a great possibility that it could be super mapped.
Is this because we are mapping more than one page at the time? Can you
point me to the code?
Hi Jan,
On 06/05/2024 07:42, Jan Beulich wrote:
Of course those calculations depend on
what people choose as actual values, but giving an upper bound being a
power of 2 may at least serve as a hint to them.
This is rather a weak hint. If you want to encourage users to chose a
power-of-2
Hi Stefano,
On 03/05/2024 20:07, Stefano Stabellini wrote:
On Fri, 3 May 2024, Julien Grall wrote:
[...]
So are you saying that from Xen point of view, you are expecting no difference
between 256 and 512. And therefore you would be happy if to backport patches
if someone find differences
This makes tests to use patched QEMU, to actually test the new behavior.
---
Config.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Config.mk b/Config.mk
index a962f095ca16..5e220a1284e4 100644
--- a/Config.mk
+++ b/Config.mk
@@ -220,8 +220,8 @@ endif
OVMF_UPSTREAM_URL
The arch_msix struct had a single "warned" field with a domid for which
warning was issued. Upcoming patch will need similar mechanism for few
more warnings, so change it to save a bit field of issued warnings.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jan Beulich
---
Changes in
/dev/mem access doesn't work in dom0 in lockdown and in stubdomain.
Simulate this environment with removing /dev/mem device node. Full test
for lockdown and stubdomain will come later, when all requirements will
be in place.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
For testing, switch to my containers registry that includes containers
rebuilt with changes in this series.
---
automation/gitlab-ci/build.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index
Switch to a wifi card that has registers on a MSI-X page. This tests the
"x86/hvm: Allow writes to registers on the same page as MSI-X table"
feature. Switch it only for HVM test, because MSI-X adjacent write is
not supported on PV.
This requires also including drivers and firmware in system for
This series includes changes to make MSI-X working with Linux stubdomain and
especially Intel Wifi 6 AX210 card. This takes care of remaining reasons for
QEMU to access /dev/mem, but also the Intel Wifi card violating spec by putting
some registers on the same page as the MSI-X table.
Besides the
Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers
on the same page as MSI-X table. Device model (especially one in
stubdomain) cannot really handle those, as direct writes to that page is
refused (page is on the mmio_ro_ranges list). Instead, extend
msixtbl_mmio_ops to handle
Hi Luca,
On 23/04/2024 10:25, Luca Fancellu wrote:
>
>
> From: Penny Zheng
>
> We are doing foreign memory mapping for static shared memory, and
> there is a great possibility that it could be super mapped.
> But today, p2m_put_l3_page could not handle superpages.
>
> This commits implements
On 07/05/2024 12:50 pm, Roger Pau Monné wrote:
> On Tue, May 07, 2024 at 12:29:57PM +0100, Andrew Cooper wrote:
>> Ever since Xen 4.14, there has been a latent bug with migration.
>>
>> While some toolstacks can level the features properly, they don't shink
>> feat.max_subleaf when all features
On Tue, May 07, 2024 at 12:29:57PM +0100, Andrew Cooper wrote:
> Ever since Xen 4.14, there has been a latent bug with migration.
>
> While some toolstacks can level the features properly, they don't shink
> feat.max_subleaf when all features have been dropped. This is because
> we *still* have
On Tue, May 07, 2024 at 12:08:06PM +0100, Andrew Cooper wrote:
> `xl devd` has been observed leaking /var/log/xldevd.log into children.
>
> Link: https://github.com/QubesOS/qubes-issues/issues/8292
> Reported-by: Demi Marie Obenour
> Signed-off-by: Andrew Cooper
> ---
> CC: Anthony PERARD
>
Ever since Xen 4.14, there has been a latent bug with migration.
While some toolstacks can level the features properly, they don't shink
feat.max_subleaf when all features have been dropped. This is because
we *still* have not completed the toolstack side work for full CPU Policy
objects.
As a
Hi Julien,
On Fri, May 3, 2024 at 4:25 PM Julien Grall wrote:
>
> Hi Jens,
>
> On 03/05/2024 14:54, Jens Wiklander wrote:
> >>> +static int ffa_setup_irq_callback(struct notifier_block *nfb,
> >>> + unsigned long action, void *hcpu)
> >>> +{
> >>> +unsigned
`xl devd` has been observed leaking /var/log/xldevd.log into children.
Link: https://github.com/QubesOS/qubes-issues/issues/8292
Reported-by: Demi Marie Obenour
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
CC: Demi Marie Obenour
CC: Marek Marczykowski-Górecki
Also
flight 185934 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185934/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185908
test-amd64-amd64-libvirt 15
flight 185930 linux-linus real [real]
flight 185938 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185930/
http://logs.test-lab.xenproject.org/osstest/logs/185938/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi,
On 06/05/2024 13:54, Edgar E. Iglesias wrote:
On Sat, May 4, 2024 at 2:14 AM Stefano Stabellini
wrote:
On Wed, 1 May 2024, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Use the generic xen/linkage.h macros to annotate code symbols
and add missing annotations.
Signed-off-by:
flight 185937 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185937/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 987bea6525d70cd01649472c93d19f89d41d83a2
baseline version:
ovmf
On Mon, May 06, 2024 at 06:34:53PM GMT, Sean Christopherson wrote:
> On Mon, May 06, 2024, Mickaël Salaün wrote:
> > On Fri, May 03, 2024 at 07:03:21AM GMT, Sean Christopherson wrote:
> > > > ---
> > > >
> > > > Changes since v1:
> > > > * New patch. Making user space aware of Heki properties was
During the review process for the v1 of the dynamic dtbo series, some
issues of the existing code were identified. Discussions of them can
be found in [1] (for the first patch) and [2] (for the second patch).
Since the main part of the remaining dynamic dtbo series requires more
rework, just send
Fix the name mismatch in the xl dt-overlay command, the
command name should be "dt-overlay" instead of "dt_overlay".
Fix the exit code of the dt-overlay command, use EXIT_FAILURE
instead of ERROR_FAIL.
Fixes: 61765a07e3d8 ("tools/xl: Add new xl command overlay for device tree
overlay support")
If CONFIG_DEBUG=y, below assertion will be triggered:
(XEN) Assertion 'rw_is_locked(_host_lock)' failed at
drivers/passthrough/device_tree.c:146
(XEN) [ Xen-4.19-unstable arm64 debug=y Not tainted ]
(XEN) CPU:0
(XEN) PC: 0a257418 iommu_remove_dt_device+0x8c/0xd4
(XEN)
flight 185935 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185935/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1c0d4ae2c0fd24164873947c2e262c499ecf13b5
baseline version:
ovmf
60 matches
Mail list logo
