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
"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
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
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
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
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
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
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
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
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
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 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
+++
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
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
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
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.
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
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
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;
+
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
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
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
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:
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
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
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.
> >
> >
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
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.
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
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
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 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);
>
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
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
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
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 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
> +++
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
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
> > >
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
>>>
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
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
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
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
>>>
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
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,
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.
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 @@
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:
> --- 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
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:
> -
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:
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
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
---
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 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 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
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 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
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
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.
>>
>>
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:
>
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
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
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
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
"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
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
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
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?
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 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
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
"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 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
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 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 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
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 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
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
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:
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
96 matches
Mail list logo
