On 2024-02-19 16:14, Nicola Vetrini wrote:
The cache clearing and invalidation helpers in x86 and Arm didn't
comply with MISRA C Rule 17.7: "The value returned by a function
having non-void return type shall be used". On Arm they
were always returning 0, while some in x86 returned -EOPNOTSUPP
On 22.02.2024 19:03, Tamas K Lengyel wrote:
> On Thu, Feb 22, 2024 at 5:06 AM Jan Beulich wrote:
>> On 22.02.2024 10:05, Roger Pau Monne wrote:
>>> The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
>>> can be achieved with an atomic increment, which is both simpler to
On 23.02.2024 02:32, Stefano Stabellini wrote:
> On Tue, 24 Oct 2023, Jan Beulich wrote:
>> On 24.10.2023 00:05, Stefano Stabellini wrote:
>>> On Mon, 23 Oct 2023, Jan Beulich wrote:
On 23.10.2023 17:23, Simone Ballarin wrote:
> On 23/10/23 15:34, Jan Beulich wrote:
>> On 18.10.2023
On Wed, Jan 10, 2024 at 04:51:31PM +0800, Pierre-Eric Pelloux-Prayer wrote:
>
>
> Le 09/01/2024 à 17:50, Pierre-Eric Pelloux-Prayer a écrit :
> >
> >
> > Le 19/12/2023 à 08:53, Huang Rui a écrit :
> >> From: Antonio Caggiano
> >>
> >> Support BLOB resources creation, mapping and unmapping by
On 2024/2/23 08:23, Stefano Stabellini wrote:
> On Fri, 5 Jan 2024, Jiqian Chen wrote:
>> In PVH dom0, the gsis don't get registered, but the gsi of
>> a passthrough device must be configured for it to be able to be
>> mapped into a domU.
>>
>> When assign a device to passthrough, proactively
On 2024/2/23 08:40, Stefano Stabellini wrote:
> On Fri, 12 Jan 2024, Jiqian Chen wrote:
>> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
>> a passthrough device by using gsi, see
>> xen_pt_realize->xc_physdev_map_pirq and
>> pci_add_dm_done->xc_physdev_map_pirq. Then
flight 184729 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184729/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184723
On Tue, 24 Oct 2023, Jan Beulich wrote:
> On 24.10.2023 00:05, Stefano Stabellini wrote:
> > On Mon, 23 Oct 2023, Jan Beulich wrote:
> >> On 23.10.2023 17:23, Simone Ballarin wrote:
> >>> On 23/10/23 15:34, Jan Beulich wrote:
> On 18.10.2023 16:18, Simone Ballarin wrote:
> > ---
On Thu, 15 Feb 2024, Nicola Vetrini wrote:
> Certain macros are allowed to violate the Rule, since their meaning and
> intended use is well-known to all Xen developers.
>
> Variadic macros that rely on the GCC extension for removing a trailing
> comma when token pasting the variable argument are
On Tue, 20 Feb 2024, Roger Pau Monne wrote:
> When running as PVH or HVM Linux will use holes in the memory map as scratch
> space to map grants, foreign domain pages and possibly miscellaneous other
> stuff. However the usage of such memory map holes for Xen purposes can be
> problematic. The
On Tue, 20 Feb 2024, Anthony PERARD wrote:
> Current issues with this test are:
> - when the job timeout, the log file is lost as there is no chance to
> run the `mv` command.
> - GitLab job log is limited in size, so one usually have to download
> the artifacts, which may be missing.
>
>
On Fri, 12 Jan 2024, Jiqian Chen wrote:
> On PVH dom0, the gsis don't get registered, but
> the gsi of a passthrough device must be configured for it to
> be able to be mapped into a hvm domU.
> On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
> passthrough devices to register gsi when dom0
On Fri, 12 Jan 2024, Jiqian Chen wrote:
> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
> a passthrough device by using gsi, see
> xen_pt_realize->xc_physdev_map_pirq and
> pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
> will call into Xen, but in hvm_physdev_op,
On Fri, 9 Feb 2024, Stewart Hildebrand wrote:
> On 1/12/24 01:13, Jiqian Chen wrote:
> > When a device has been reset on dom0 side, the vpci on Xen
> > side won't get notification, so the cached state in vpci is
> > all out of date compare with the real device state.
> > To solve that problem, add
On Fri, 5 Jan 2024, Jiqian Chen wrote:
> In PVH dom0, it uses the linux local interrupt mechanism,
> when it allocs irq for a gsi, it is dynamic, and follow
> the principle of applying first, distributing first. And
> the irq number is alloced from small to large, but the
> applying gsi number is
On Fri, 5 Jan 2024, Jiqian Chen wrote:
> In PVH dom0, the gsis don't get registered, but the gsi of
> a passthrough device must be configured for it to be able to be
> mapped into a domU.
>
> When assign a device to passthrough, proactively setup the gsi
> of the device during that process.
>
>
On Fri, 5 Jan 2024, Jiqian Chen wrote:
> When device on dom0 side has been reset, the vpci on Xen side
> won't get notification, so that the cached state in vpci is
> all out of date with the real device state.
> To solve that problem, add a new function to clear all vpci
> device state when
Hi Zewei,
Did you manage to make progress on this issue?
I apologize for answering so late, but this email fell through the
cracks,
Cheers,
Stefano
On Mon, 20 Nov 2023, ZHANG Zewei wrote:
> INTERNAL & PARTNERS
>
>
> Hi，Xen-devel：
>
> We are trying to implement the igpu sharing
flight 184725 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184725/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-credit1 22 guest-start/debian.repeat fail in 184722 pass
in 184725
flight 184730 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184730/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 22/02/2024 4:55 pm, Jan Beulich wrote:
> On 22.02.2024 17:44, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/include/asm/alternative.h
>> +++ b/xen/arch/x86/include/asm/alternative.h
>> @@ -167,9 +167,25 @@ extern void alternative_branches(void);
>> #define ALT_CALL_arg5 "r8"
>> #define
On Thu, Feb 22, 2024 at 5:06 AM Jan Beulich wrote:
>
> On 22.02.2024 10:05, Roger Pau Monne wrote:
> > The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
> > can be achieved with an atomic increment, which is both simpler to read, and
> > avoid any need for a loop.
> >
>
On 22.02.2024 17:44, Roger Pau Monne wrote:
> --- a/xen/arch/x86/include/asm/alternative.h
> +++ b/xen/arch/x86/include/asm/alternative.h
> @@ -167,9 +167,25 @@ extern void alternative_branches(void);
> #define ALT_CALL_arg5 "r8"
> #define ALT_CALL_arg6 "r9"
>
> +#ifdef CONFIG_CC_IS_CLANG
>
The current code for alternative calls uses the caller parameter types as the
types for the register variables that serve as function parameters:
uint8_t foo;
[...]
alternative_call(myfunc, foo);
Would expand roughly into:
register unint8_t a1_ asm("rdi") = foo;
register unsigned long a2_
Juergen Gross, le jeu. 22 févr. 2024 17:06:09 +0100, a ecrit:
> On 16.02.24 17:31, Juergen Gross wrote:
> > Extend the config files of the Xenstore stubdoms to include XENBUS
> > and 9PFRONT items in order to support file based logging.
> >
> > Signed-off-by: Juergen Gross
> > Reviewed-by: Jason
flight 184728 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184728/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
Hi Stefano,
On 15/02/2024 01:08, Stefano Stabellini wrote:
On Wed, 31 Jan 2024, Luca Fancellu wrote:
This serie is enabling the xen-analysis tool to parse and substitute correctly
a deviation tag put at the end of the line containing a deviation to be
deviated.
Before this serie the only way
On 16.02.24 17:31, Juergen Gross wrote:
Extend the config files of the Xenstore stubdoms to include XENBUS
and 9PFRONT items in order to support file based logging.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Samuel, are you fine with this patch?
Juergen
---
On 22.02.2024 15:43, Nicola Vetrini wrote:
>>> In passing it should be noted that the header ordering in
>>> x86/alternative.c is not the one usually prescribed, so that may be
>>> taken care of as well.
>>
>> I'm afraid I don't understand this remark.
>>
>
> I just meant to say that this
>
>
On 22.02.2024 15:33, George Dunlap wrote:
> On Tue, Feb 20, 2024 at 12:25 AM Jan Beulich wrote:
>> On 06.02.2024 02:20, George Dunlap wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -3021,6 +3021,9 @@ const struct hvm_function_table * __init
>>>
--- a/xen/arch/arm/include/asm/page.h
+++ b/xen/arch/arm/include/asm/page.h
@@ -123,6 +123,7 @@
#ifndef __ASSEMBLY__
+#include
This is a no-go, imo (also on x86): Adding this include here
effectively
means that nearly every CU will have a dependency on that header,
no
matter that
On 2/22/24 01:22, Chen, Jiqian wrote:
> Hi Stewart,
>
> On 2024/2/10 02:02, Stewart Hildebrand wrote:
>> On 1/12/24 01:13, Jiqian Chen wrote:
>>> When a device has been reset on dom0 side, the vpci on Xen
>>> side won't get notification, so the cached state in vpci is
>>> all out of date compare
On Tue, Feb 20, 2024 at 12:25 AM Jan Beulich wrote:
>
> On 06.02.2024 02:20, George Dunlap wrote:
> > --- /dev/null
> > +++ b/docs/designs/nested-svm-cpu-features.md
> > @@ -0,0 +1,110 @@
> > +# Nested SVM (AMD) CPUID requirements
> > +
> > +The first step in making nested SVM production-ready is
Dear all,
We are detecting several issues with USB port virtualization with the Xen
hypervisor.
- We cannot do PCI passthrough of the PCI usb bus on a Windows 10 1607 64-bit
virtual machine. The bad result is a Windows blue screen.
- When we use the passthrough functionality on a Windows 21H2
On 21.02.2024 16:46, Nicola Vetrini wrote:
> On 2024-02-21 13:08, Nicola Vetrini wrote:
>> On 2024-02-20 09:14, Nicola Vetrini wrote:
>>> On 2024-02-20 08:45, Jan Beulich wrote:
On 19.02.2024 16:14, Nicola Vetrini wrote:
> The cache clearing and invalidation helpers in x86 and Arm didn't
flight 184727 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184727/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 184723 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184723/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail in
184720 pass in 184723
On Mon, Feb 19, 2024 at 11:56 PM Jan Beulich wrote:
>
> On 06.02.2024 02:20, George Dunlap wrote:
> > Changeset ef3e8db8068 ("x86/hvm: Corrections and improvements to
> > unhandled vmexit logging") introduced a printk to the default path of
> > the switch statement in
On 22.02.2024 12:00, George Dunlap wrote:
> On Thu, Feb 22, 2024 at 5:50 PM Jan Beulich wrote:
>>
>> On 22.02.2024 10:30, George Dunlap wrote:
>>> On Wed, Feb 21, 2024 at 6:52 PM Jan Beulich wrote:
>> But then of course Andrew may know of reasons why all of this is done
>> in
Hi Roger,
On 22/02/2024 09:05, Roger Pau Monne wrote:
The usage of a cmpxchg loop in hpet_get_channel() is unnecessary, as the same
can be achieved with an atomic increment, which is both simpler to read, and
avoid any need for a loop.
Note there can be a small divergence in the channel
Hi Roger,
On 22/02/2024 09:05, Roger Pau Monne wrote:
The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
can be achieved with an atomic increment, which is both simpler to read, and
avoid any need for a loop.
The cmpxchg usage is likely a remnant of 32bit support,
On 22.02.2024 11:58, Roger Pau Monné wrote:
> On Thu, Feb 22, 2024 at 11:10:54AM +0100, Jan Beulich wrote:
>> On 22.02.2024 10:05, Roger Pau Monne wrote:
>>> The usage of a cmpxchg loop in hpet_get_channel() is unnecessary, as the
>>> same
>>> can be achieved with an atomic increment, which is
On Thu, Feb 22, 2024 at 5:50 PM Jan Beulich wrote:
>
> On 22.02.2024 10:30, George Dunlap wrote:
> > On Wed, Feb 21, 2024 at 6:52 PM Jan Beulich wrote:
> But then of course Andrew may know of reasons why all of this is done
> in calculate_host_policy() in the first place, rather than
On 22.02.2024 11:50, Roger Pau Monné wrote:
> On Thu, Feb 22, 2024 at 11:32:14AM +0100, Jan Beulich wrote:
>> On 21.02.2024 18:03, Roger Pau Monne wrote:
>>> The above can be worked around by using an union when defining the register
>>> variables, so that `di` becomes:
>>>
>>> register union {
On Thu, Feb 22, 2024 at 11:10:54AM +0100, Jan Beulich wrote:
> On 22.02.2024 10:05, Roger Pau Monne wrote:
> > The usage of a cmpxchg loop in hpet_get_channel() is unnecessary, as the
> > same
> > can be achieved with an atomic increment, which is both simpler to read, and
> > avoid any need for
On Thu, Feb 22, 2024 at 11:32:14AM +0100, Jan Beulich wrote:
> On 21.02.2024 18:03, Roger Pau Monne wrote:
> > The current code for alternative calls uses the caller parameter types as
> > the
> > types for the register variables that serve as function parameters:
> >
> > uint8_t foo;
> > [...]
On 21.02.2024 18:03, Roger Pau Monne wrote:
> The current code for alternative calls uses the caller parameter types as the
> types for the register variables that serve as function parameters:
>
> uint8_t foo;
> [...]
> alternative_call(myfunc, foo);
>
> Would expand roughly into:
>
> register
On Thu, Feb 22, 2024 at 8:28 AM Juergen Gross wrote:
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > build-arm64-pvops 6 kernel-build fail in 184721 REGR. vs.
> > 184719
>
> Log says:
>
> gcc: internal compiler error: Segmentation
On 22.02.2024 10:05, Roger Pau Monne wrote:
> The usage of a cmpxchg loop in hpet_get_channel() is unnecessary, as the same
> can be achieved with an atomic increment, which is both simpler to read, and
> avoid any need for a loop.
>
> Note there can be a small divergence in the channel returned
On 22.02.2024 10:05, Roger Pau Monne wrote:
> The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
> can be achieved with an atomic increment, which is both simpler to read, and
> avoid any need for a loop.
>
> The cmpxchg usage is likely a remnant of 32bit support, which
On 22.02.24 10:49, Roger Pau Monné wrote:
On Wed, Feb 21, 2024 at 10:53:49PM +, Julien Grall wrote:
Hi George,
On 21/02/2024 02:55, George Dunlap wrote:
On Mon, Feb 19, 2024 at 6:38 PM Jan Beulich wrote:
On 19.02.2024 11:31, Roger Pau Monné wrote:
On Mon, Feb 19, 2024 at 06:01:54PM
On 22.02.2024 10:30, George Dunlap wrote:
> On Wed, Feb 21, 2024 at 6:52 PM Jan Beulich wrote:
But then of course Andrew may know of reasons why all of this is done
in calculate_host_policy() in the first place, rather than in HVM
policy calculation.
>>>
>>> It sounds like maybe
On Wed, Feb 21, 2024 at 10:53:49PM +, Julien Grall wrote:
> Hi George,
>
> On 21/02/2024 02:55, George Dunlap wrote:
> > On Mon, Feb 19, 2024 at 6:38 PM Jan Beulich wrote:
> > >
> > > On 19.02.2024 11:31, Roger Pau Monné wrote:
> > > > On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap
On Wed, Feb 21, 2024 at 6:52 PM Jan Beulich wrote:
> >> But then of course Andrew may know of reasons why all of this is done
> >> in calculate_host_policy() in the first place, rather than in HVM
> >> policy calculation.
> >
> > It sounds like maybe you're confusing host_policy with
> >
Hello,
Following series replace a couple of cmpxchg loops with an atomic inc.
The usage of such loops probably dates back to 32bit support, which
didn't have an instruction to do an atomic 64bit addition.
Thanks, Roger.
Roger Pau Monne (2):
x86/memsharing: use an atomic add instead of a
The usage of a cmpxchg loop in hpet_get_channel() is unnecessary, as the same
can be achieved with an atomic increment, which is both simpler to read, and
avoid any need for a loop.
Note there can be a small divergence in the channel returned if next_channel
overflows, but returned channel will
The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
can be achieved with an atomic increment, which is both simpler to read, and
avoid any need for a loop.
The cmpxchg usage is likely a remnant of 32bit support, which didn't have an
instruction to do an atomic 64bit add,
On 2024-02-15 14:06, Nicola Vetrini wrote:
Certain macros are allowed to violate the Rule, since their meaning and
intended use is well-known to all Xen developers.
Variadic macros that rely on the GCC extension for removing a trailing
comma when token pasting the variable argument are
On Wed, Feb 21, 2024 at 06:03:31PM +0100, Roger Pau Monne wrote:
> The current code for alternative calls uses the caller parameter types as the
> types for the register variables that serve as function parameters:
>
> uint8_t foo;
> [...]
> alternative_call(myfunc, foo);
>
> Would expand
On 22.02.24 09:21, osstest service owner wrote:
flight 184722 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184722/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build
flight 184722 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184722/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail in 184721 REGR. vs. 184719
Tests which are
61 matches
Mail list logo
