On 28.02.2023 08:36, Xenia Ragiadakou wrote:
>
> On 2/27/23 17:25, Jan Beulich wrote:
>> On 24.02.2023 19:50, Xenia Ragiadakou wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/hvm/vmx/pi.h
>>> @@ -0,0 +1,78 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * pi.h: VMX Posted Interrupts
>
Before trying to create a dom0less guest, check that max_init_domid
increment will generate a valid domain ID, lower than
DOMID_FIRST_RESERVED.
Signed-off-by: Bertrand Marquis
---
xen/arch/arm/domain_build.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen
On 27/02/2023 16:57, Jan Beulich wrote:
>
>
> On 27.02.2023 16:46, Michal Orzel wrote:
>> On 27/02/2023 16:00, Jan Beulich wrote:
>>> On 27.02.2023 15:46, Michal Orzel wrote:
On 27/02/2023 14:54, Jan Beulich wrote:
> On 27.02.2023 14:41, Michal Orzel wrote:
>> On 27/02/2023 11:10,
On Tue, Feb 28, 2023 at 08:49:09AM +0100, Thomas Huth wrote:
> On 27/02/2023 21.12, Michael S. Tsirkin wrote:
> > On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
> > > I feel like we should have separate deprecation entries for the
> > > i686 host support, and for qemu-system-i3
On 28.02.2023 09:14, Michal Orzel wrote:
>
>
> On 27/02/2023 16:57, Jan Beulich wrote:
>>
>>
>> On 27.02.2023 16:46, Michal Orzel wrote:
>>> On 27/02/2023 16:00, Jan Beulich wrote:
On 27.02.2023 15:46, Michal Orzel wrote:
> On 27/02/2023 14:54, Jan Beulich wrote:
>> On 27.02.2023 14:
On 27.02.2023 20:43, Andrew Cooper wrote:
> On 09/09/2022 3:30 pm, Jan Beulich wrote:
>> Gcc12 takes issue with core_parking_remove()'s
>>
>> for ( ; i < cur_idle_nums; ++i )
>> core_parking_cpunum[i] = core_parking_cpunum[i + 1];
>>
>> complaining that the right hand side array access is
flight 178706 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 178042
test-amd64-amd64-qe
On 28/02/2023 6:44 am, Joe Jin wrote:
> Hi,
>
> We encountered a vcpu-set issue on old xen, when I tried to confirm
> if xen upstream xen has the same issue I find neither my upstream build
> nor ubuntu 22.04 xen-hypervisor-4.16 work.
>
> I can add vcpus(8->16) to my guest but I can not reduce vcpu
On Mon, Feb 27, 2023 at 10:21:14AM -1000, Richard Henderson wrote:
> On 2/27/23 10:12, Michael S. Tsirkin wrote:
> > On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
> > > I feel like we should have separate deprecation entries for the
> > > i686 host support, and for qemu-system
On Tue, Feb 28, 2023 at 03:19:20AM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 28, 2023 at 08:49:09AM +0100, Thomas Huth wrote:
> > On 27/02/2023 21.12, Michael S. Tsirkin wrote:
> > > On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
> > > > I feel like we should have separate
On Mon, Feb 27, 2023 at 10:21:14AM -1000, Richard Henderson wrote:
> > Removing support for building on 32 bit systems seems like a pity - it's
> > one of a small number of ways to run 64 bit binaries on 32 bit systems,
> > and the maintainance overhead is quite small.
>
> It's not that small.
Me
On Tue, Feb 28, 2023 at 08:39:49AM +0100, Thomas Huth wrote:
> On 27/02/2023 19.38, Daniel P. Berrangé wrote:
> > On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote:
> > > We're struggling quite badly with our CI minutes on the shared
> > > gitlab runners, so we urgently need to think of w
On Tue, Feb 28, 2023 at 08:59:52AM +, Daniel P. Berrangé wrote:
> On Tue, Feb 28, 2023 at 03:19:20AM -0500, Michael S. Tsirkin wrote:
> > On Tue, Feb 28, 2023 at 08:49:09AM +0100, Thomas Huth wrote:
> > > On 27/02/2023 21.12, Michael S. Tsirkin wrote:
> > > > On Mon, Feb 27, 2023 at 11:50:07AM
Gcc12 takes issue with core_parking_remove()'s
for ( ; i < cur_idle_nums; ++i )
core_parking_cpunum[i] = core_parking_cpunum[i + 1];
complaining that the right hand side array access is past the bounds of
1. Clearly the compiler can't know that cur_idle_nums can only ever be
zero in t
On 28/02/2023 10.03, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 08:59:52AM +, Daniel P. Berrangé wrote:
On Tue, Feb 28, 2023 at 03:19:20AM -0500, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 08:49:09AM +0100, Thomas Huth wrote:
On 27/02/2023 21.12, Michael S. Tsirkin wrote:
On
On 28.02.2023 07:44, Joe Jin wrote:
> Hi,
>
> We encountered a vcpu-set issue on old xen, when I tried to confirm
> if xen upstream xen has the same issue I find neither my upstream build
> nor ubuntu 22.04 xen-hypervisor-4.16 work.
>
> I can add vcpus(8->16) to my guest but I can not reduce vcpu
On Tue, Feb 28, 2023 at 10:14:52AM +0100, Thomas Huth wrote:
> On 28/02/2023 10.03, Michael S. Tsirkin wrote:
> > On Tue, Feb 28, 2023 at 08:59:52AM +, Daniel P. Berrangé wrote:
> > > On Tue, Feb 28, 2023 at 03:19:20AM -0500, Michael S. Tsirkin wrote:
> > > > On Tue, Feb 28, 2023 at 08:49:09AM
Marking a DRHD as controlling an IGD isn't very sensible without
checking that at the very least it's a graphics device that lives at
:00:02.0. Re-use the reading of the class-code to control both the
clearing of "gfx_only" and the setting of "igd_drhd_address".
Signed-off-by: Jan Beulich
---
On Tue, Feb 28, 2023 at 09:40:49AM +, Daniel P. Berrangé wrote:
> On Tue, Feb 28, 2023 at 10:14:52AM +0100, Thomas Huth wrote:
> > On 28/02/2023 10.03, Michael S. Tsirkin wrote:
> > > On Tue, Feb 28, 2023 at 08:59:52AM +, Daniel P. Berrangé wrote:
> > > > On Tue, Feb 28, 2023 at 03:19:20AM
On Tue, Feb 28, 2023 at 10:37:00AM +0100, Jan Beulich wrote:
> On 28.02.2023 07:44, Joe Jin wrote:
> > We encountered a vcpu-set issue on old xen, when I tried to confirm
> > if xen upstream xen has the same issue I find neither my upstream build
> > nor ubuntu 22.04 xen-hypervisor-4.16 work.
> >
On Mon, 2023-02-27 at 15:23 +0100, Jan Beulich wrote:
> On 24.02.2023 12:31, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/common/bug.c
> > @@ -0,0 +1,109 @@
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +
> On 27 Feb 2023, at 15:41, Juergen Gross wrote:
>
> There are some macros defined multiple times in tools. Use only
> a single header file for defining those macros and drop the copies.
>
> V2:
> - add patch 1 (Andrew Cooper)
>
> Juergen Gross (4):
> tools: rename xen-tools/libs.h file to
"Michael S. Tsirkin" writes:
> On Tue, Feb 28, 2023 at 09:40:49AM +, Daniel P. Berrangé wrote:
>> On Tue, Feb 28, 2023 at 10:14:52AM +0100, Thomas Huth wrote:
>> > On 28/02/2023 10.03, Michael S. Tsirkin wrote:
>> > > On Tue, Feb 28, 2023 at 08:59:52AM +, Daniel P. Berrangé wrote:
>> > >
On 28.02.2023 11:30, Oleksii wrote:
> On Mon, 2023-02-27 at 15:23 +0100, Jan Beulich wrote:
>> On 24.02.2023 12:31, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/common/bug.c
>>> @@ -0,0 +1,109 @@
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>
On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
> The question to answer: Is 32 bit x86 worth its upkeep? Two
> sub-questions: 1. Is it worth the human attention? 2. Is it worth
> (scarce!) CI minutes?
3. Is it worth arguing about?
--
MST
Hi Bertrand,
On 28/02/2023 09:08, Bertrand Marquis wrote:
>
>
> Before trying to create a dom0less guest, check that max_init_domid
> increment will generate a valid domain ID, lower than
> DOMID_FIRST_RESERVED.
>
> Signed-off-by: Bertrand Marquis
> ---
> xen/arch/arm/domain_build.c | 3 +++
>
On 28/02/2023 11.51, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
The question to answer: Is 32 bit x86 worth its upkeep? Two
sub-questions: 1. Is it worth the human attention? 2. Is it worth
(scarce!) CI minutes?
3. Is it worth arguing about?
On Tue, Feb 28, 2023 at 12:12:22PM +0100, Thomas Huth wrote:
> On 28/02/2023 11.51, Michael S. Tsirkin wrote:
> > On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
> > > The question to answer: Is 32 bit x86 worth its upkeep? Two
> > > sub-questions: 1. Is it worth the human atten
On Tue, Feb 28, 2023 at 06:24:02AM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 28, 2023 at 12:12:22PM +0100, Thomas Huth wrote:
> > On 28/02/2023 11.51, Michael S. Tsirkin wrote:
> > > On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
> > > > The question to answer: Is 32 bit x8
"Michael S. Tsirkin" writes:
> On Tue, Feb 28, 2023 at 11:39:39AM +0100, Markus Armbruster wrote:
>> The question to answer: Is 32 bit x86 worth its upkeep? Two
>> sub-questions: 1. Is it worth the human attention? 2. Is it worth
>> (scarce!) CI minutes?
>
> 3. Is it worth arguing about?
If it
On Tue, Feb 28, 2023 at 12:34:19PM +0100, Markus Armbruster wrote:
> If it's not worth arguing, then we merge Thomas's patch.
I don't mind but it's just a doc patch isn't it? If what we want to do
is to stop doing make check on a 32 bit container and just to do
make then let's patch the relevant y
On Tue, Feb 28, 2023 at 09:01:46AM +, Daniel P. Berrangé wrote:
> If we're merely wanting to drop CI support, we can do that any time and
> deprecation is not required/expected. We should only be using deprecation
> where we're explicitly intending that the code will cease to work.
Good point
On 28/2/23 09:59, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 10:21:14AM -1000, Richard Henderson wrote:
On 2/27/23 10:12, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 ho
Gcc12 takes issue with core_parking_remove()'s
for ( ; i < cur_idle_nums; ++i )
core_parking_cpunum[i] = core_parking_cpunum[i + 1];
complaining that the right hand side array access is past the bounds of
1. Clearly the compiler can't know that cur_idle_nums can only ever be
zero in t
Hi Julien,
On Sat, 2023-02-25 at 16:47 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > Since the generic version of bug.h stuff was introduced use
> >
> > instead of unnecessary
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V3:
>
Hi MIchal,
> On 28 Feb 2023, at 12:10, Michal Orzel wrote:
>
> Hi Bertrand,
>
> On 28/02/2023 09:08, Bertrand Marquis wrote:
>>
>>
>> Before trying to create a dom0less guest, check that max_init_domid
>> increment will generate a valid domain ID, lower than
>> DOMID_FIRST_RESERVED.
>>
>> Si
flight 178726 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178726/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-coresched-amd64-xl broken
test-amd64-coresched-amd64-xl 5 host-in
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> When initializing the FF-A mediator map the RX and TX buffers shared with
> the SPMC.
>
> These buffer are later used to to transmit data that cannot be passed in
> registers only.
>
> Adds a check that the SP supports the needed F
On Sat, 2023-02-25 at 16:47 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > Since the generic version of bug.h stuff was introduced use
> >
> > instead of unnecessary
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V3:
> > * Update
On Mon, 2023-02-27 at 15:29 +0100, Jan Beulich wrote:
> On 24.02.2023 12:31, Oleksii Kurochko wrote:
> > Since the generic version of bug.h stuff was introduced use
> >
> > instead of unnecessary
>
> You keep saying "unnecessary" here, but that's not really correct.
> Including asm/bug.h alone s
On 28.02.2023 14:07, Oleksii wrote:
> On Sat, 2023-02-25 at 16:47 +, Julien Grall wrote:
>> On 24/02/2023 11:31, Oleksii Kurochko wrote:
>>> --- a/xen/arch/arm/include/asm/bug.h
>>> +++ b/xen/arch/arm/include/asm/bug.h
>>> @@ -1,6 +1,8 @@
>>> #ifndef __ARM_BUG_H__
>>> #define __ARM_BUG_H__
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
> PMU virtualization is not dependent on the hardware virtualization support.
> Rename {svm,vmx}_vpmu_initialise to {amd,core2}_vpmu_initialise because
> the {svm,vmx} prefix is misleading.
>
> Take the opportunity to remove the also misleading comment
On 28/02/2023 12:38, Oleksii wrote:
Hi Julien,
Hi,
On Sat, 2023-02-25 at 16:47 +, Julien Grall wrote:
Hi Oleksii,
On 24/02/2023 11:31, Oleksii Kurochko wrote:
Since the generic version of bug.h stuff was introduced use
instead of unnecessary
Signed-off-by: Oleksii Kurochko
---
C
Hi Bertrand,
On Fri, Feb 24, 2023 at 4:27 PM Bertrand Marquis
wrote:
>
> HI Jens,
>
> > On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
> >
> > Adds a BUILD_BUG_ON() to assert the dependency on 4k pages in the FF-A
> > mediator.
> >
> > Signed-off-by: Jens Wiklander
>
> NIT: I would s/note/enfo
Hi,
On Mon, Feb 27, 2023 at 4:00 PM Julien Grall wrote:
>
> Hi,
>
> On 27/02/2023 14:48, Bertrand Marquis wrote:
> >> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
> >>
> >> Adds support for the FF-A function FFA_ID_GET to return the ID of the
> >> calling client.
> >>
> >> Signed-off-by: Jens
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
> This change aims to render the control interface of MSR intercepts identical
> between SVM and VMX code, so that the control of the MSR intercept in common
> code can be done through an hvm_funcs callback.
>
> Create two new functions:
> - svm_set_msr
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
> --- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
> @@ -644,18 +644,8 @@ static inline int vmx_write_guest_msr(struct vcpu *v,
> uint32_t msr,
> return 0;
> }
>
> -
> -/* MSR intercept bitmap infrast
On 28.02.2023 15:31, Jan Beulich wrote:
> On 27.02.2023 08:56, Xenia Ragiadakou wrote:
>> --- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
>> +++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
>> @@ -644,18 +644,8 @@ static inline int vmx_write_guest_msr(struct vcpu *v,
>> uint32_t msr,
>> return 0;
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
> Add hvm_funcs hooks for {set,clear}_msr_intercept() for controlling the msr
> intercept in common vpmu code.
What is this going to buy us? All calls ...
> --- a/xen/arch/x86/cpu/vpmu_amd.c
> +++ b/xen/arch/x86/cpu/vpmu_amd.c
> @@ -165,9 +165,9 @@ sta
Hi Jan,
On 2/28/23 16:20, Jan Beulich wrote:
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
This change aims to render the control interface of MSR intercepts identical
between SVM and VMX code, so that the control of the MSR intercept in common
code can be done through an hvm_funcs callback.
Cr
On 2/28/23 16:34, Jan Beulich wrote:
On 28.02.2023 15:31, Jan Beulich wrote:
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
--- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
+++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h
@@ -644,18 +644,8 @@ static inline int vmx_write_guest_msr(struct vcpu *v,
uin
Hi Julien,
On Sat, 2023-02-25 at 16:49 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > The following changes were made:
> > * make GENERIC_BUG_FRAME mandatory for ARM
>
> I have asked in patch #1 but will ask it again because I think this
> should b
On 28.02.2023 16:05, Xenia Ragiadakou wrote:
> On 2/28/23 16:20, Jan Beulich wrote:
>> On 27.02.2023 08:56, Xenia Ragiadakou wrote:
>>> This change aims to render the control interface of MSR intercepts identical
>>> between SVM and VMX code, so that the control of the MSR intercept in common
>>> c
On 2/28/23 17:10, Jan Beulich wrote:
On 28.02.2023 16:05, Xenia Ragiadakou wrote:
On 2/28/23 16:20, Jan Beulich wrote:
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
This change aims to render the control interface of MSR intercepts identical
between SVM and VMX code, so that the control of th
flight 178733 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178733/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeatfail like 178422
test-amd64-i386-libvirt-xsm 15 migrate-s
On 2/28/23 12:49 AM, Andrew Cooper wrote:
> On 28/02/2023 6:44 am, Joe Jin wrote:
>> Hi,
>>
>> We encountered a vcpu-set issue on old xen, when I tried to confirm
>> if xen upstream xen has the same issue I find neither my upstream build
>> nor ubuntu 22.04 xen-hypervisor-4.16 work.
>>
>> I can add
On 2/28/23 2:24 AM, Anthony PERARD wrote:
> On Tue, Feb 28, 2023 at 10:37:00AM +0100, Jan Beulich wrote:
>> On 28.02.2023 07:44, Joe Jin wrote:
>>> We encountered a vcpu-set issue on old xen, when I tried to confirm
>>> if xen upstream xen has the same issue I find neither my upstream build
>>> nor
On Tue, 2023-02-28 at 14:30 +0100, Jan Beulich wrote:
> On 28.02.2023 14:07, Oleksii wrote:
> > On Sat, 2023-02-25 at 16:47 +, Julien Grall wrote:
> > > On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/arm/include/asm/bug.h
> > > > +++ b/xen/arch/arm/include/asm/bug.h
> > > >
flight 178776 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178776/
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 28.02.2023 16:17, Xenia Ragiadakou wrote:
> On 2/28/23 17:10, Jan Beulich wrote:
>> On 28.02.2023 16:05, Xenia Ragiadakou wrote:
>>> On 2/28/23 16:20, Jan Beulich wrote:
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
> --- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
> +++ b/xen/arch/x86
On 31.08.2022 16:11, Volodymyr Babchuk wrote:
> There are number of cases where pcidevs_lock() is used to protect
> something that is not related to PCI devices per se.
>
> Probably pcidev_lock in these places should be replaced with some
> other lock.
>
> This patch is not intended to be merged
On Mon, 2023-02-27 at 15:46 +0100, Jan Beulich wrote:
> On 24.02.2023 12:31, Oleksii Kurochko wrote:
> > The following changes were made:
> > * Make GENERIC_BUG_FRAME mandatory for X86
> > * Update asm/bug.h using generic implementation in
> > * Change prototype of debugger_trap_fatal() in asm/deb
On 31.08.2022 16:10, Volodymyr Babchuk wrote:
> This lock protects alldevs_list of struct pci_seg. As this, it should
> be used when we are adding, removing on enumerating PCI devices
> assigned to a PCI segment.
>
> Radix tree that stores PCI segment has own locking mechanism, also
> pci_seg stru
On 28.02.2023 17:28, Oleksii wrote:
> On Mon, 2023-02-27 at 15:46 +0100, Jan Beulich wrote:
>> On 24.02.2023 12:31, Oleksii Kurochko wrote:
>>> --- a/xen/arch/x86/include/asm/debugger.h
>>> +++ b/xen/arch/x86/include/asm/debugger.h
>>> @@ -14,9 +14,9 @@
>>>
>>> /* Returns true if GDB handled the
On 31.08.2022 16:11, Volodymyr Babchuk wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -203,10 +203,14 @@ static struct msi_desc *msixtbl_addr_to_desc(
>
> nr_entry = (addr - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
>
> +pcidev_lock(entry->pdev);
> list_fo
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> The FF-A specification defines framework messages sent as direct
> requests when certain events occurs. For instance when a VM (guest) is
> created or destroyed. Only SPs which have subscribed to these events
> will receive them. An
On 28.01.2023 02:32, Stefano Stabellini wrote:
> On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
>> As pci devices are refcounted now and all list that store them are
>> protected by separate locks, we can safely drop global pcidevs_lock.
>>
>> Signed-off-by: Volodymyr Babchuk
>
> Up until this pat
On 2/27/23 23:00, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 10:21:14AM -1000, Richard Henderson wrote:
Removing support for building on 32 bit systems seems like a pity - it's
one of a small number of ways to run 64 bit binaries on 32 bit systems,
and the maintainance overhead is quite s
On 31.08.2022 16:11, Volodymyr Babchuk wrote:
> Prior to this change, lifetime of pci_dev objects was protected by global
> pcidevs_lock(). We are going to get if of this lock, so we need some
> other mechanism to ensure that those objects will not disappear under
> feet of code that access them. R
Hi Julien,
On Sat, 2023-02-25 at 17:05 +, Julien Grall wrote:
>
>
> On 25/02/2023 16:49, Julien Grall wrote:
> > Hi Oleksii,
> >
> > On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > > The following changes were made:
> > > * make GENERIC_BUG_FRAME mandatory for ARM
> >
> > I have asked in
Hi Julien,
On Sat, 2023-02-25 at 16:42 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 24/02/2023 11:31, Oleksii Kurochko wrote:
> > A large part of the content of the bug.h is repeated among all
> > architectures, so it was decided to create a new config
> > CONFIG_GENERIC_BUG_FRAME.
> >
> > Th
Currently it's impossible to get CPU's microcode revision after late
loading without looking into Xen logs which is not always convenient.
Leverage xenhypfs to expose struct cpu_signature in a new cpuinfo dir.
The tree structure is:
/
cpuinfo/
cpu-signature
microcode-rev
I've split the patch into 3 parts. And now I'm using xenhypfs instead of
introducing another platform op. That's my first attempt at xenhypfs and
the patch itself is of RFC quality. Open questions are where to put the
new code and if it's possible to come up with a better hypfs functions.
Sergey D
As a wrapper for XENPF_get_cpu_version platform op.
Signed-off-by: Sergey Dyasli
---
tools/include/xenctrl.h | 1 +
tools/libs/ctrl/xc_misc.c | 20
2 files changed, 21 insertions(+)
diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
index 23037874d3..8aa747dc
Add an option to xen-ucode tool to print the currently loaded ucode
version and also print it during usage info. Print CPU signature and
processor flags as well. The raw data comes from cpuinfo directory in
xenhypfs and from XENPF_get_cpu_version platform op.
Example output:
Intel:
Curre
Hi Oleksii,
On 28/02/2023 15:09, Oleksii wrote:
On Sat, 2023-02-25 at 16:49 +, Julien Grall wrote:
Hi Oleksii,
On 24/02/2023 11:31, Oleksii Kurochko wrote:
The following changes were made:
* make GENERIC_BUG_FRAME mandatory for ARM
I have asked in patch #1 but will ask it again because
On 28/02/2023 17:21, Oleksii wrote:
Hi Julien,
Hi Oleksii,
On Sat, 2023-02-25 at 17:05 +, Julien Grall wrote:
On 25/02/2023 16:49, Julien Grall wrote:
Hi Oleksii,
On 24/02/2023 11:31, Oleksii Kurochko wrote:
The following changes were made:
* make GENERIC_BUG_FRAME mandatory for ARM
On 28/02/2023 17:21, Oleksii wrote:
Hi Julien,
Hi Oleksii,
+
+ for ( i = 0, b = region->frame[id].bugs;
+ i < region->frame[id].n_bugs; b++, i++ )
+ {
+ if ( bug_loc(b) == pc )
+ {
+ bug = b;
+
Base image "archlinux/base" isn't available anymore,
https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030181.html
But instead of switching to archlinux/archlinux, we will use the
official image from Docker. Main difference is that the first one is
updated daily while the se
Ask docker to check if there's an update of the base image to avoid
using an old container cached locally.
Signed-off-by: Anthony PERARD
---
automation/build/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/build/Makefile b/automation/build/Makefile
index f
On 28/02/2023 6:22 pm, Anthony PERARD wrote:
> Ask docker to check if there's an update of the base image to avoid
> using an old container cached locally.
>
> Signed-off-by: Anthony PERARD
Acked-by: Andrew Cooper
I've lost count of how many times I've fallen over this.
On 28/02/2023 6:16 pm, Anthony PERARD wrote:
> Base image "archlinux/base" isn't available anymore,
>
> https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030181.html
>
> But instead of switching to archlinux/archlinux, we will use the
> official image from Docker. Main differ
flight 178789 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178789/
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 28/02/2023 10.01, Daniel P. Berrangé wrote:
On Tue, Feb 28, 2023 at 08:39:49AM +0100, Thomas Huth wrote:
On 27/02/2023 19.38, Daniel P. Berrangé wrote:
On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote:
We're struggling quite badly with our CI minutes on the shared
gitlab runners,
On 2/28/23 16:58, Jan Beulich wrote:
On 27.02.2023 08:56, Xenia Ragiadakou wrote:
Add hvm_funcs hooks for {set,clear}_msr_intercept() for controlling the msr
intercept in common vpmu code.
What is this going to buy us? All calls ...
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/
On Tue, 2023-02-28 at 18:01 +, Julien Grall wrote:
> On 28/02/2023 17:21, Oleksii wrote:
> > Hi Julien,
>
> Hi Oleksii,
> > > > +
> > > > + for ( i = 0, b = region->frame[id].bugs;
> > > > + i < region->frame[id].n_bugs; b++, i++ )
> > > > + {
> > > > +
On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote:
> Well, without CI, I assume that the code will bitrot quite fast (considering
> that there are continuous improvements to TCG, for example).
We have lots of hosts which we don't test with CI. They don't bitrot
because people do testing
flight 178802 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178802/
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
flight 178753 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 178042
test-amd64-amd64-qe
flight 178771 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178771/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 178616
test-amd64-i386-xl-qemuu-win7-amd64
On Tue, 28 Feb 2023, Anthony PERARD wrote:
> Ask docker to check if there's an update of the base image to avoid
> using an old container cached locally.
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Stefano Stabellini
> ---
> automation/build/Makefile | 2 +-
> 1 file changed, 1 insertion(+
On Tue, 28 Feb 2023, Anthony PERARD wrote:
> Base image "archlinux/base" isn't available anymore,
>
> https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030181.html
>
> But instead of switching to archlinux/archlinux, we will use the
> official image from Docker. Main differe
On 28/02/2023 22.32, Michael S. Tsirkin wrote:
On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote:
Well, without CI, I assume that the code will bitrot quite fast (considering
that there are continuous improvements to TCG, for example).
We have lots of hosts which we don't test with C
Le 27/02/2023 à 23:29, Rick Edgecombe a écrit :
> The x86 Control-flow Enforcement Technology (CET) feature includes a new
> type of memory called shadow stack. This shadow stack memory has some
> unusual properties, which requires some core mm changes to function
> properly.
>
> One of these un
"Michael S. Tsirkin" writes:
> On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote:
>> Well, without CI, I assume that the code will bitrot quite fast (considering
>> that there are continuous improvements to TCG, for example).
>
> We have lots of hosts which we don't test with CI. They
On Wed, Mar 1, 2023, 12:36 AM Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, Feb 28, 2023 at 09:05:16PM +0100, Thomas Huth wrote:
> >> Well, without CI, I assume that the code will bitrot quite fast
> (considering
> >> that there are continuous improvements to TCG, for exa
96 matches
Mail list logo
