flight 183273 linux-linus real [real]
flight 183280 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183273/
http://logs.test-lab.xenproject.org/osstest/logs/183280/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
flight 183276 xen-unstable-smoke real [real]
flight 183279 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183276/
http://logs.test-lab.xenproject.org/osstest/logs/183279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
While working on tests for MSI-X, I did few cleanups of hw-based gitlab tests,
greatly reducing false positive messages in the test output.
After applying this series, the tests-artifacts/alpine/3.18 container needs to
be rebuilt.
Test run with container rebuilt (on my repo):
https://gitlab.com/xe
Checking /proc/interrupts is unreliable because different drivers set
different names there. Install pciutils and use lspci instead.
In fact, the /proc/interrupts content was confusing enough that
adl-pci-hvm had it wrong (MSI-X is in use there). Fix this too.
Signed-off-by: Marek Marczykowski-Gór
grep+sleep message every 1s makes job log unnecessary hard to read.
Signed-off-by: Marek Marczykowski-Górecki
---
I know I can download serial log file, but that's 3 more clicks...
---
automation/scripts/qubes-x86-64.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/automation/scripts/qub
Remove parts of initramfs for the test system (domU, and in few tests
dom0 too) that are not not working and are not really needed in this
simple system.
This makes the test log much lighter on misleading error messages.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/tests-artifacts/a
Let it be printed to the console too. QEMU and Linux messages have
different enough format that it should be possible to distinguish them.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qubes-x86-64.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/automation/scripts/qubes
Passthrough domU console log to the serial console in real time, not
only after the test. First of all, this gives domU console also in case
of test failure. But also, allows correlation between domU and dom0 or
Xen messages.
To avoid ambiguity, add log prefix with 'sed'.
Signed-off-by: Marek Mar
On Thu, 5 Oct 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
>
> Signed-off-by: Federico Serafini
> ---
> xen/common/sched/private.h | 93 --
> 1 file changed, 49 insertions(+), 44 deletions(-)
>
> diff --git a/xen/common/
On Thu, 5 Oct 2023, Nicola Vetrini wrote:
> The constant 0 is used as a null pointer constant, in
> violation of MISRA C:2012 Rule 11.9, in builds with
> CONFIG_DEBUG_LOCK_PROFILE defined.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
> ---
> Release builds should not be i
On Thu, 5 Oct 2023, Nicola Vetrini wrote:
> The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a
> compile-time check to detect non-scalar types; its usage for this
> purpose is documented in rules.rst as an exception.
>
> Furthermore, the 'access_field' and 'typeof_field' macros are
> i
On Thu, 5 Oct 2023, Luca Fancellu wrote:
> > On 5 Oct 2023, at 00:32, Stefano Stabellini wrote:
> >
> > On Wed, 4 Oct 2023, Luca Fancellu wrote:
> >>> On 4 Oct 2023, at 11:29, Nicola Vetrini
> >>> wrote:
> >>> On 04/10/2023 12:06, Luca Fancellu wrote:
> Hi Nicola,
> > On 4 Oct 2023, at
Hi,
> On Oct 6, 2023, at 06:53, Stefano Stabellini wrote:
>
> On Thu, 5 Oct 2023, Julien Grall wrote:
>> From: Julien Grall
>>
>> Per ACPI 6.5 section 5.2.25 ("Generic Timer Description Table (GTDT)"),
>> the fields "Secure EL1 Timer GSIV/Flags" are optional and an OS running
>> in non-secure
flight 183271 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183271/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183266
test-amd64-amd64-xl-qemut-win7-amd64
On Thu, 5 Oct 2023, Julien Grall wrote:
> From: Julien Grall
>
> Per ACPI 6.5 section 5.2.25 ("Generic Timer Description Table (GTDT)"),
> the fields "Secure EL1 Timer GSIV/Flags" are optional and an OS running
> in non-secure world is meant to ignore the values.
>
> However, Xen is trying to re
On 05/10/2023 23:40, Julien Grall wrote:
Hi Andrew,
On 05/10/2023 19:58, Andrew Cooper wrote:
I see this series has been committed. But it's broken in a really
fundamental way.
Thanks for pointing out. But I'd like to understand how I come to only
hear about those concerns on the series
Hi Andrew,
On 05/10/2023 19:58, Andrew Cooper wrote:
I see this series has been committed. But it's broken in a really
fundamental way.
Thanks for pointing out. But I'd like to understand how I come to only
hear about those concerns on the series after committing. Did I miss any
thread? Eve
On 05/10/2023 10:38 pm, andrew.coop...@citrix.com wrote:
> On 05/10/2023 8:43 am, Luca Fancellu wrote:
>>> On 5 Oct 2023, at 00:46, Stefano Stabellini wrote:
>>>
>>> Hi MISRA C working group (Jan, Roger, Andrew, Julien, Bertrand, George)
>>>
>>> in a recent thread Andrew pointed out that the SAF-2
flight 183272 xen-unstable-smoke real [real]
flight 183274 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183272/
http://logs.test-lab.xenproject.org/osstest/logs/183274/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On 05/10/2023 8:43 am, Luca Fancellu wrote:
>> On 5 Oct 2023, at 00:46, Stefano Stabellini wrote:
>>
>> Hi MISRA C working group (Jan, Roger, Andrew, Julien, Bertrand, George)
>>
>> in a recent thread Andrew pointed out that the SAF-2-safe tag is
>> confusing and requested a rename:
>> https://mar
On Thu, 5 Oct 2023, Luca Fancellu wrote:
> > On 5 Oct 2023, at 00:46, Stefano Stabellini wrote:
> >
> > Hi MISRA C working group (Jan, Roger, Andrew, Julien, Bertrand, George)
> >
> > in a recent thread Andrew pointed out that the SAF-2-safe tag is
> > confusing and requested a rename:
> > https
On Thu, 5 Oct 2023, Roger Pau Monné wrote:
> On Wed, Oct 04, 2023 at 03:52:54PM -0700, Stefano Stabellini wrote:
> > On Wed, 4 Oct 2023, Julien Grall wrote:
> > > > > If we want to handle such firmware, I think it would be better if we
> > > > > provide
> > > > > an hypercall that would return the
Hi Julien,
On 05/10/2023 18:54, Julien Grall wrote:
>
>
> From: Julien Grall
>
> Per ACPI 6.5 section 5.2.25 ("Generic Timer Description Table (GTDT)"),
> the fields "Secure EL1 Timer GSIV/Flags" are optional and an OS running
> in non-secure world is meant to ignore the values.
>
> However,
I see this series has been committed. But it's broken in a really
fundamental way.
This is a new extension with persistent side effects to an existing part
of the guest ABI.
Yet there doesn't appear to be any enumeration that the interface is
available to begin with. Requiring the guest to pro
From: Juergen Gross
Today xen_ram_addr_from_mapcache() will either abort() or return 0 in
case it can't find a matching entry for a pointer value. Both cases
are bad, so change that to return an invalid address instead.
Signed-off-by: Juergen Gross
---
hw/xen/xen-mapcache.c | 12 +++-
From: Juergen Gross
Add a memory region which can be used to automatically map granted
memory. It is starting at 0x8000ULL in order to be able to
distinguish it from normal RAM.
For this reason the xen.ram memory region is expanded, which has no
further impact as it is used just as a
From: Juergen Gross
Add the callbacks for mapping/unmapping guest memory via grants to the
special grant memory region.
Signed-off-by: Juergen Gross
Signed-off-by: Vikram Garhwal
---
hw/xen/xen-mapcache.c | 167 +-
softmmu/physmem.c | 11 ++-
2 fil
From: Juergen Gross
Virtio devices should never be unplugged at boot time, as they are
similar to pci passthrough devices.
Signed-off-by: Juergen Gross
Signed-off-by: Vikram Garhwal
---
hw/i386/xen/xen_platform.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/hw/i3
On 03/10/2023 00:03, Stefano Stabellini wrote:
On Mon, 2 Oct 2023, Julien Grall wrote:
On 29/09/2023 21:29, Stefano Stabellini wrote:
Now regarding whether the PPI is used. AFAICT, the secure timer PPI is still
present in the firmware tables (ACPI and DT) passed to dom0. So strictly
speaking
From: Julien Grall
Per ACPI 6.5 section 5.2.25 ("Generic Timer Description Table (GTDT)"),
the fields "Secure EL1 Timer GSIV/Flags" are optional and an OS running
in non-secure world is meant to ignore the values.
However, Xen is trying to reserve the value. When booting on Graviton
2 metal inst
On Thu, Oct 5, 2023 at 7:03 PM Jakub Kicinski wrote:
>
> On Thu, 5 Oct 2023 18:39:51 +0300 David Kahurani wrote:
> > > MAX_SKB_FRAGS can now be set via Kconfig, this allows us to create
> > > larger super-packets. Can XEN_NETBK_LEGACY_SLOTS_MAX be made relative
> > > to MAX_SKB_FRAGS, or does the
flight 183269 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183269/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183260
test-armhf-armhf-libvirt-qcow2 15 saveres
On Thu, 5 Oct 2023 18:39:51 +0300 David Kahurani wrote:
> > MAX_SKB_FRAGS can now be set via Kconfig, this allows us to create
> > larger super-packets. Can XEN_NETBK_LEGACY_SLOTS_MAX be made relative
> > to MAX_SKB_FRAGS, or does the number have to match between guest and
> > host?
>
> Historic
On Thu, Oct 05, 2023 at 09:54:26AM +0100, Julien Grall wrote:
> On 04/10/2023 22:13, Elliott Mitchell wrote:
> >>> I understand the situation is different on Arm vs x86, so if
> >>> edk2 is not supported on arm I guess it doesn't matter much whether
> >>> it's broken. It would be a much worse issu
This change was suggested by Juergen and looked okay and straightforward to me.
On Wed, Oct 4, 2023 at 9:48 PM Jakub Kicinski wrote:
>
> On Wed, 27 Sep 2023 11:29:18 +0300 David Kahurani wrote:
> > If XEN_NETBK_LEGACY_SLOTS_MAX and MAX_SKB_FRAGS have a difference of
> > more than 1, with MAX_SKB_
flight 183270 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183270/
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
Hi Andrii,
On 05/10/2023 14:30, Andrii Chepurnyi wrote:
For read operations, there's a potential issue when the data field
of the ioreq struct is partially updated in the response. To address
this, zero data field during read operations. This modification
serves as a safeguard against implementa
Do not set netback interfaces (vifs) default TX queue size to the ring size.
The TX queue size is not related to the ring size, and using the ring size (32)
as the queue size can lead to packet drops. Note the TX side of the vif
interface in the netback domain is the one receiving packets to be in
flight 183268 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183268/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183265
test-amd64-amd64-xl-qemuu-win7-amd64
For read operations, there's a potential issue when the data field
of the ioreq struct is partially updated in the response. To address
this, zero data field during read operations. This modification
serves as a safeguard against implementations that may inadvertently
partially update the data fiel
On Mon, Oct 2, 2023 at 11:12 AM Roger Pau Monne wrote:
>
> Instead let map_vcpu_info() and it's call to get_page_from_gfn()
> populate the page in the child as needed. Also remove the bogus
> copy_domain_page(): should be placed before the call to map_vcpu_info(),
> as the later can update the co
Hi George,
On 05/10/2023 10:07, George Dunlap wrote:
Following a conversation with Bob Eschleman, it was agreed that
Bobby would prefer to return to being a Reviewer.
Ideally, we would want Bobby confirm on the ML (this could be a simpler
Acked-by). In any case...
Signed-off-by: George Du
Hi,
On 05/10/2023 02:27, Henry Wang wrote:
Hi Roger,
On Oct 2, 2023, at 23:11, Roger Pau Monne wrote:
Since it was indicated that introducing specific new vCPU ops may be
beneficial independent of the introduction of a fully physical-
address-based ABI flavor, here we go. There continue to b
Hi George,
On 05/10/2023 13:42, George Dunlap wrote:
On Thu, Oct 5, 2023 at 1:11 PM Julien Grall wrote:
Hi,
While preparing to commit this series, I have noticed that there are no
Acked-by/Reviewed-by from Tamas (or at least not present in my inbox).
@Tamas, can you provide one?
I see an
On Thu, Oct 5, 2023 at 1:11 PM Julien Grall wrote:
>
> Hi,
>
> While preparing to commit this series, I have noticed that there are no
> Acked-by/Reviewed-by from Tamas (or at least not present in my inbox).
>
> @Tamas, can you provide one?
I see an "Acked-by" from Tamas two days ago.
-George
On Tue, Oct 03, 2023 at 09:46:13AM -0400, Tamas K Lengyel wrote:
> On Mon, Oct 2, 2023 at 11:12 AM Roger Pau Monne wrote:
> >
> > Instead let map_vcpu_info() and it's call to get_page_from_gfn()
> > populate the page in the child as needed. Also remove the bogus
> > copy_domain_page(): should be
Hi Julien,
> On Oct 5, 2023, at 20:30, Julien Grall wrote:
>
> (+ Henry)
Thanks.
>
> Hi Andrii,
>
> @Henry, this patch is a candidate for Xen 4.18. The fix is self-contained in
> the IOREQ code which is in tech preview. So I think the risk is limited.
Sure, with your comments below properl
(+ Henry)
Hi Andrii,
@Henry, this patch is a candidate for Xen 4.18. The fix is
self-contained in the IOREQ code which is in tech preview. So I think
the risk is limited.
On 05/10/2023 10:21, Andrii Chepurnyi wrote:
For read operations, there's a potential issue when the data field
of the i
Hi,
While preparing to commit this series, I have noticed that there are no
Acked-by/Reviewed-by from Tamas (or at least not present in my inbox).
@Tamas, can you provide one?
Cheers,
On 02/10/2023 16:11, Roger Pau Monne wrote:
Instead let map_vcpu_info() and it's call to get_page_from_gfn(
Currently the handling of events is supported either in the kernel or
userspace, but not both.
In order to support fast delivery of interrupts from the guest to the
backend, we need to handle the Queue notify part of Virtio protocol in
kernel and the rest in userspace.
Update the interrupt handle
Virtio guests send VIRTIO_MMIO_QUEUE_NOTIFY notification when they need
to notify the backend of an update to the status of the virtqueue. The
backend or another entity, polls the MMIO address for updates to know
when the notification is sent.
It works well if the backend does this polling by itse
Hello,
Now that irqfd support (backend to guest interrupt) is already merged, this
series solves the other part of the problem, i.e. ioeventfd (guest to backend
interrupt).
More details inside the commits.
--
Viresh
V1->V2:
- Increment irq_info refcnt only for valid info.
- Use u64 type for add
On 29-09-23, 07:46, Juergen Gross wrote:
> This is populated from a __u64 field. Maybe make it uint64_t?
Checkpatch warns about this, will use u64 instead.
CHECK: Prefer kernel type 'u64' over 'uint64_t'
#124: FILE: drivers/xen/privcmd.c:1097:
+ uint64_t addr;
--
viresh
flight 183266 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183266/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-install fail in 183258 pass in 183266
test-amd64-amd64-xl-qemut-debian
Add missing parameter names. No functional change.
Signed-off-by: Federico Serafini
---
xen/common/sched/private.h | 93 --
1 file changed, 49 insertions(+), 44 deletions(-)
diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h
index c516976c37
On Wed, Oct 04, 2023 at 03:52:54PM -0700, Stefano Stabellini wrote:
> On Wed, 4 Oct 2023, Julien Grall wrote:
> > > > If we want to handle such firmware, I think it would be better if we
> > > > provide
> > > > an hypercall that would return the GFN where it is currently mapped.
> > >
> > > Sure,
For read operations, there's a potential issue when the data field
of the ioreq struct is partially updated in the response. To address
this, zero data field during read operations. This modification
serves as a safeguard against implementations that may inadvertently
partially update the data fiel
Hi George,
> On Oct 5, 2023, at 17:07, George Dunlap wrote:
>
> Following a conversation with Bob Eschleman, it was agreed that
> Bobby would prefer to return to being a Reviewer.
>
> Signed-off-by: George Dunlap
> ---
> Freeze exception justification: Only documentation change.
Of course. So
Following a conversation with Bob Eschleman, it was agreed that
Bobby would prefer to return to being a Reviewer.
Signed-off-by: George Dunlap
---
Freeze exception justification: Only documentation change.
CC: Bob Eshleman
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Stefano Stabellini
On 04/10/2023 22:13, Elliott Mitchell wrote:
I understand the situation is different on Arm vs x86, so if
edk2 is not supported on arm I guess it doesn't matter much whether
it's broken. It would be a much worse issue on x86 where edk2 is
supported.
AFAIK, we have CI for x86 on EDK2 but we don
The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a
compile-time check to detect non-scalar types; its usage for this
purpose is documented in rules.rst as an exception.
Furthermore, the 'access_field' and 'typeof_field' macros are
introduced as a general way to deal with accesses to st
Rule 11.9 forbids the usage of '0' as a null pointer constant, therefore uses of
this pattern have been amended. One exception, recorded in rules.rst, is in
__ACCESS_ONCE to do a scalar type check.
The series only touches common headers, therefore it should be safe to include
in the for-4.19 branc
The constant 0 is used as a null pointer constant, in
violation of MISRA C:2012 Rule 11.9, in builds with
CONFIG_DEBUG_LOCK_PROFILE defined.
Signed-off-by: Nicola Vetrini
---
Release builds should not be impacted by this
---
xen/include/xen/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 de
Hello,
On 10/4/23 18:41, Julien Grall wrote:
> I was asking a pointer to the code in the Device Emulator (QEMU in your
> case). I am confident the code is correct in U-boot, because when using
> 'w0', the unused bits are meant to be set to zero (per the Arm Arm). But
> I am curious to know why
> > diff --git a/Documentation/arch/x86/x86_64/fred.rst
> > b/Documentation/arch/x86/x86_64/fred.rst
> > new file mode 100644
> > index ..9f57e7b91f7e
> > --- /dev/null
> > +++ b/Documentation/arch/x86/x86_64/fred.rst
> > @@ -0,0 +1,96 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
>
> On 5 Oct 2023, at 00:46, Stefano Stabellini wrote:
>
> Hi MISRA C working group (Jan, Roger, Andrew, Julien, Bertrand, George)
>
> in a recent thread Andrew pointed out that the SAF-2-safe tag is
> confusing and requested a rename:
> https://marc.info/?l=xen-devel&m=169634970821202
>
> As d
> On 5 Oct 2023, at 00:32, Stefano Stabellini wrote:
>
> On Wed, 4 Oct 2023, Luca Fancellu wrote:
>>> On 4 Oct 2023, at 11:29, Nicola Vetrini wrote:
>>> On 04/10/2023 12:06, Luca Fancellu wrote:
Hi Nicola,
> On 4 Oct 2023, at 10:56, andrew.coop...@citrix.com wrote:
> On 03/10/2023
> > This patch set enables the Intel flexible return and event delivery
> > (FRED) architecture for x86-64.
> >
>
>
> Which tree is this based on now?
>
It was based on the tip master on the day I sent the v12 patch set, i.e.,
Monday night in the US west coast.
> I tried running 'b4 diff' but i
68 matches
Mail list logo
