flight 161136 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161136/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 161141 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161141/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c055be5b82d3591c531ced88965523dfdbe1b9ae
baseline version:
ovmf 037090cb7c0063bcb7788
flight 161150 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161150/
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 161125 linux-5.4 real [real]
flight 161154 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161125/
http://logs.test-lab.xenproject.org/osstest/logs/161154/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armh
Add a debian build container with cross-gcc for arm32 installed.
Add build jobs to cross-compile Xen-only for arm32.
Signed-off-by: Stefano Stabellini
Acked-by: Wei Liu
---
Rebased on top of staging, using the new "hypervisor_only" option.
---
.../debian/unstable-arm32-gcc.dockerfile | 2
On Wed, 2021-04-14 at 15:07 -0400, Steven Rostedt wrote:
> On Wed, 14 Apr 2021 19:11:19 +0100
> Andrew Cooper wrote:
>
> > Where the plugin (ought to) live depends heavily on whether we
> > consider
> > the trace format a stable ABI or not.
>
> Agreed. Like the VMware plugin to handle ESX traces
flight 161124 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow219 guest-localmigrate/x10 fail REGR. vs. 159418
Tests which ar
On Wed, 2021-04-14 at 21:05 +0100, Andrew Cooper wrote:
> On 14/04/2021 14:43, Steven Rostedt wrote:
> >
> > What I would envision how this would work, is that you would
> > produce a
> > set of tracing files. One for each guest (including Dom0), and one
> > for the
> > Xen hypervisor itself. The
On Wed, 2021-04-14 at 11:07 +0100, Andrew Cooper wrote:
> On 13/04/2021 16:46, Steven Rostedt wrote:
> In a Xen system, dom0 is just a VM, and particularly on larger servers,
> may not be as many vcpus as the system has logical threads.
>
> This causes major problems for `perf` support under Xen,
On 14/04/2021 12:41, Jan Beulich wrote:
On 14.04.2021 06:40, Igor Druzhinin wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2915,14 +2915,16 @@ static const struct lbr_info {
}, nh_lbr[] = {
{ MSR_IA32_LASTINTFROMIP, 1 },
{ MSR_IA32_LASTINTTOIP,
On Thu, 15 Apr 2021 00:11:32 +0200
Dario Faggioli wrote:
> Yes, basically, we can say that a Xen system has "its own trace-cmd".
> It's called `xentrace`, you run it from Dom0 and you get a (binary)
> file which contains a bunch of events.
>
> Not that differently from a trace-cmd's "trace.dat
On Tue, 2021-04-13 at 11:46 -0400, Steven Rostedt wrote:
> On Tue, 13 Apr 2021 16:28:36 +0200
> Giuseppe Eletto wrote:
> >
> > In fact, KernelShark is a well known tool for graphical
> > visualization
> > Linux kernel traces, obtained via "ftrace" and "trace-cmd". Anyway
> > thanks
> > to its mod
On Wed, 2021-04-14 at 19:11 +0100, Andrew Cooper wrote:
> On 14/04/2021 18:31, Dario Faggioli wrote:
> > > A couple of questions. Which Xen libraries do you currently use
> > > map
> > > the
> > > frames?
> > >
> > Err... If I understood the question none, as the plugin loads and
> > parses a fil
flight 161121 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
On Wed, 14 Apr 2021, Luca Fancellu wrote:
> > On 14 Apr 2021, at 14:45, Julien Grall wrote:
> >
> > Hi Luca,
> >
> > On 14/04/2021 12:29, Luca Fancellu wrote:
> >>> On 14 Apr 2021, at 12:16, Julien Grall wrote:
> >>>
> >>> Hi Luca,
> >>>
> >>> On 14/04/2021 10:14, Luca Fancellu wrote:
>
On 14/04/2021 14:43, Steven Rostedt wrote:
>> This causes major problems for `perf` support under Xen, which assumes
>> that the kernel's idea of CPUs matches that of the system.
> Things are different with KernelShark.
That is very encouraging to hear.
>> When rendering a trace including Xen dat
On Wed, 14 Apr 2021 19:11:19 +0100
Andrew Cooper wrote:
> Where the plugin (ought to) live depends heavily on whether we consider
> the trace format a stable ABI or not.
Agreed. Like the VMware plugin to handle ESX traces. It's internal and not
published as the API is not stable.
But if it ever
On 14/04/2021 18:31, Dario Faggioli wrote:
> On Tue, 2021-04-13 at 16:33 +0100, Andrew Cooper wrote:
>> On 13/04/2021 15:28, Giuseppe Eletto wrote:
>>> You will need the development version of KernelShark, available
>>> here:
>>> https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git
>>>
>
On Wed, 2021-04-14 at 12:25 +0300, Yordan Karadzhov (VMware) wrote:
> It is great to see such progress in the development of the Xen
> plugin.
>
> Can you share with us what are your plans for continuing this work.
> Is
> this a first prototype of the plugin, or it is an almost final
> version?
>
flight 161117 xen-unstable real [real]
flight 161140 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161117/
http://logs.test-lab.xenproject.org/osstest/logs/161140/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Tue, 2021-04-13 at 16:33 +0100, Andrew Cooper wrote:
> On 13/04/2021 15:28, Giuseppe Eletto wrote:
> >
> > You will need the development version of KernelShark, available
> > here:
> > https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git
> >
> > A screenshot of the plugin in action
On Wed, Apr 14, 2021 at 04:05:20PM +0200, Jan Beulich wrote:
> On 14.04.2021 15:37, Roger Pau Monné wrote:
> > On Wed, Apr 14, 2021 at 12:28:43PM +0200, Jan Beulich wrote:
> >> On 31.03.2021 12:33, Roger Pau Monne wrote:
> >>> ---
> >>> xen/arch/x86/hvm/svm/intr.c | 3 -
> >>> xen/arch/x86/hvm
On 14.04.2021 15:37, Roger Pau Monné wrote:
> On Wed, Apr 14, 2021 at 12:28:43PM +0200, Jan Beulich wrote:
>> On 31.03.2021 12:33, Roger Pau Monne wrote:
>>> ---
>>> xen/arch/x86/hvm/svm/intr.c | 3 -
>>> xen/arch/x86/hvm/vmx/intr.c | 59 --
>>> xen/arch/x86/hvm/vpt.c| 334 +
On 14.04.2021 15:25, Andrew Cooper wrote:
> On 14/04/2021 14:05, Andrew Cooper wrote:
>> On 14/04/2021 13:57, Jan Beulich wrote:
>>> On 14.04.2021 13:04, Roger Pau Monne wrote:
@@ -264,6 +265,38 @@ struct cpuid_policy
};
uint32_t nc:8, :4, apic_id_size:4, :1
On 13.04.2021 16:01, Roger Pau Monne wrote:
> @@ -944,3 +945,130 @@ bool xc_cpu_policy_is_compatible(xc_interface *xch,
> const xc_cpu_policy_t host,
>
> return false;
> }
> +
> +static uint64_t level_msr(unsigned int index, uint64_t val1, uint64_t val2)
> +{
> +uint64_t val = val1 & v
> On 14 Apr 2021, at 14:45, Julien Grall wrote:
>
> Hi Luca,
>
> On 14/04/2021 12:29, Luca Fancellu wrote:
>>> On 14 Apr 2021, at 12:16, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 14/04/2021 10:14, Luca Fancellu wrote:
Among the common and arm codebase there are few cases where
>
Hi Luca,
On 14/04/2021 12:29, Luca Fancellu wrote:
On 14 Apr 2021, at 12:16, Julien Grall wrote:
Hi Luca,
On 14/04/2021 10:14, Luca Fancellu wrote:
Among the common and arm codebase there are few cases where
the hardware_domain variable is checked to see if the current
domain is equal to the
On Wed, 14 Apr 2021 11:07:33 +0100
Andrew Cooper wrote:
> On 13/04/2021 16:46, Steven Rostedt wrote:
> > Hi Giuseppe,
> >
> > On Tue, 13 Apr 2021 16:28:36 +0200
> > Giuseppe Eletto wrote:
> >
> >> Hello,
> >> I want to share with you a new plugin developed by me, under the
> >> supervision of
On 14/04/2021 14:24, Jan Beulich wrote:
> On 14.04.2021 15:05, Andrew Cooper wrote:
>> On 14/04/2021 13:57, Jan Beulich wrote:
>>> On 14.04.2021 13:04, Roger Pau Monne wrote:
@@ -264,6 +265,38 @@ struct cpuid_policy
};
uint32_t nc:8, :4, apic_id_size:4, :16;
On Wed, Apr 14, 2021 at 12:28:43PM +0200, Jan Beulich wrote:
> On 31.03.2021 12:33, Roger Pau Monne wrote:
> > ---
> > xen/arch/x86/hvm/svm/intr.c | 3 -
> > xen/arch/x86/hvm/vmx/intr.c | 59 --
> > xen/arch/x86/hvm/vpt.c| 334 ++
> > xen/include/
On 13.04.2021 16:01, Roger Pau Monne wrote:
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -925,3 +925,22 @@ int xc_cpu_policy_update_msrs(xc_interface *xch,
> xc_cpu_policy_t policy,
>
> return rc;
> }
> +
> +bool xc_cpu_policy_is_compatible(xc_interf
On 13.04.2021 16:01, Roger Pau Monne wrote:
> Such helper is based on the existing functions to fetch a CPUID and
> MSR policies, but uses the xc_cpu_policy_t type to return the data to
> the caller.
>
> Note some helper functions are introduced, those are split from
> xc_cpu_policy_get_system bec
flight 161102 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161102/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 14/04/2021 14:05, Andrew Cooper wrote:
> On 14/04/2021 13:57, Jan Beulich wrote:
>> On 14.04.2021 13:04, Roger Pau Monne wrote:
>>> @@ -264,6 +265,38 @@ struct cpuid_policy
>>> };
>>> uint32_t nc:8, :4, apic_id_size:4, :16;
>>> uint32_t /* d */:32;
>>> +
>>
On 14.04.2021 15:05, Andrew Cooper wrote:
> On 14/04/2021 13:57, Jan Beulich wrote:
>> On 14.04.2021 13:04, Roger Pau Monne wrote:
>>> @@ -264,6 +265,38 @@ struct cpuid_policy
>>> };
>>> uint32_t nc:8, :4, apic_id_size:4, :16;
>>> uint32_t /* d */:32;
>>> +
>>
On 14/04/2021 13:57, Jan Beulich wrote:
> On 14.04.2021 13:04, Roger Pau Monne wrote:
>> @@ -264,6 +265,38 @@ struct cpuid_policy
>> };
>> uint32_t nc:8, :4, apic_id_size:4, :16;
>> uint32_t /* d */:32;
>> +
>> +uint64_t :64, :64; /* Leaf 0x800
On 14.04.2021 13:04, Roger Pau Monne wrote:
> @@ -264,6 +265,38 @@ struct cpuid_policy
> };
> uint32_t nc:8, :4, apic_id_size:4, :16;
> uint32_t /* d */:32;
> +
> +uint64_t :64, :64; /* Leaf 0x8009. */
> +uint64_t :64, :64; /* Leaf
On 14/04/2021 13:45, Jan Beulich wrote:
> On 14.04.2021 14:33, Andrew Cooper wrote:
>> On 14/04/2021 12:04, Roger Pau Monne wrote:
>>> --- a/tools/misc/xen-cpuid.c
>>> +++ b/tools/misc/xen-cpuid.c
>>> @@ -178,6 +178,11 @@ static const char *const str_7a1[32] =
>>> [ 4] = "avx-vnni", [ 5]
On 14.04.2021 14:33, Andrew Cooper wrote:
> On 14/04/2021 12:04, Roger Pau Monne wrote:
>> --- a/tools/misc/xen-cpuid.c
>> +++ b/tools/misc/xen-cpuid.c
>> @@ -178,6 +178,11 @@ static const char *const str_7a1[32] =
>> [ 4] = "avx-vnni", [ 5] = "avx512-bf16",
>> };
>>
>> +static const c
On 14/04/2021 12:04, Roger Pau Monne wrote:
> Milan AMD CPUs
I'd suggest "AMD Milan (Zen3) CPUs" for people who don't know the AMD
codenames inside/out.
> have an LFENCE Always Serializing CPUID bit in leaf
> 8021.eax.
Its probably worth noting that this is because of SEV-SNP, which is a
he
On 13.04.2021 19:25, Igor Druzhinin wrote:
> Version 5 is backwards compatible with version 3. This allows to enable
> vPMU on Ice Lake CPUs.
>
> Signed-off-by: Igor Druzhinin
Acked-by: Jan Beulich
On 14.04.2021 06:40, Igor Druzhinin wrote:
> LBR, C-state MSRs should correspond to Ice Lake desktop according to
> SDM rev. 74 for both models.
>
> Ice Lake-SP is known to expose IF_PSCHANGE_MC_NO in IA32_ARCH_CAPABILITIES MSR
> (as advisory tells and Whitley SDP confirms) which means the erratum
On Wed, Apr 14, 2021 at 12:07:02PM +0200, Jan Beulich wrote:
>On 14.04.2021 02:55, Chao Gao wrote:
>> According to Intel VT-d SPEC rev3.3 Section 6.5, Register-based Invalidation
>> isn't supported by Intel VT-d version 6 and beyond.
>>
>> This hardware change impacts following two scenarios: admi
On 14.04.2021 06:40, Igor Druzhinin wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2915,14 +2915,16 @@ static const struct lbr_info {
> }, nh_lbr[] = {
> { MSR_IA32_LASTINTFROMIP, 1 },
> { MSR_IA32_LASTINTTOIP, 1 },
> -{ MSR_C2_LASTBR
> On 14 Apr 2021, at 12:16, Julien Grall wrote:
>
> Hi Luca,
>
> On 14/04/2021 10:14, Luca Fancellu wrote:
>> Among the common and arm codebase there are few cases where
>> the hardware_domain variable is checked to see if the current
>> domain is equal to the hardware_domain, change this cas
On 14/04/2021 10:14, Luca Fancellu wrote:
This patch adds a comment in create_domUs() right before
domain_create() to explain the importance of the pre-increment
operator on the variable max_init_domid, to ensure that the
domid 0 is allocated only during start_xen() function by the
create_dom0
Hi Luca,
On 14/04/2021 10:14, Luca Fancellu wrote:
Among the common and arm codebase there are few cases where
the hardware_domain variable is checked to see if the current
domain is equal to the hardware_domain, change this cases to
use is_hardware_domain() function instead. >
Signed-off-by: Lu
On 14/04/2021 12:04, Roger Pau Monne wrote:
> Split the logic to attempt to setup the LFENCE to be dispatch
"the LFENCE instruction", or drop "the".
> serializing on AMD into a helper, so it can be shared with Hygon.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Reviewed
Milan AMD CPUs have an LFENCE Always Serializing CPUID bit in leaf
8021.eax. Previous AMD versions used to have a user settable bit
in DE_CFG MSR to select whether LFENCE was dispatch serializing, which
Xen always attempts to set.
In order to support this new CPUID bit move the LFENCE_DISPATCH
Split the logic to attempt to setup the LFENCE to be dispatch
serializing on AMD into a helper, so it can be shared with Hygon.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/amd.c | 62 ++--
xen/arch/x86/cpu/cpu.h | 1
Hello,
The following patches aim to add support for the LFENCE always
serializing CPUID bit found in leaf 8021.eax. In order to do that
the featureset needs to be expanded to support leaf 8021.eax.
Thanks, Roger.
Roger Pau Monne (2):
x86/amd: split LFENCE dispatch serializing setup log
HI Stefano,
> On 13 Apr 2021, at 1:27 am, Stefano Stabellini wrote:
>
> On Mon, 12 Apr 2021, Rahul Singh wrote:
>> Hi Stefano,
>>
>>> On 10 Apr 2021, at 1:27 am, Stefano Stabellini
>>> wrote:
>>>
>>> On Tue, 6 Apr 2021, Stefano Stabellini wrote:
On Mon, 5 Apr 2021, Julien Grall wrote:
>
On 31.03.2021 12:33, Roger Pau Monne wrote:
> No longer add vPT timers to lists on specific vCPUs, since there's no
> need anymore to check if timer interrupts have been injected on return
> to HVM guest.
>
> Such change allows to get rid of virtual timers vCPU migration, and
> also cleanup some o
On 31.03.2021 12:33, Roger Pau Monne wrote:
> ---
> xen/arch/x86/hvm/svm/intr.c | 3 -
> xen/arch/x86/hvm/vmx/intr.c | 59 --
> xen/arch/x86/hvm/vpt.c| 334 ++
> xen/include/asm-x86/hvm/vpt.h | 5 +-
> 4 files changed, 143 insertions(+), 258 del
Hi Luca,
> On 14 Apr 2021, at 10:14, Luca Fancellu wrote:
>
> This patch prevents the dom0 to be loaded skipping its
> building and going forward to build domUs when the dom0
> kernel is not found and at least one domU is present.
>
> Signed-off-by: Luca Fancellu
> Reviewed-by: Julien Grall
R
Hi Luca,
> On 14 Apr 2021, at 10:14, Luca Fancellu wrote:
>
> This patch adds a comment in create_domUs() right before
> domain_create() to explain the importance of the pre-increment
> operator on the variable max_init_domid, to ensure that the
> domid 0 is allocated only during start_xen() fun
Hi Luca,
> On 14 Apr 2021, at 10:14, Luca Fancellu wrote:
>
> Among the common and arm codebase there are few cases where
> the hardware_domain variable is checked to see if the current
> domain is equal to the hardware_domain, change this cases to
> use is_hardware_domain() function instead.
>
Hi Luca,
> On 14 Apr 2021, at 10:14, Luca Fancellu wrote:
>
> Move dom0 create and start from setup.c to a dedicated
> function in domain_build.c.
>
> With this change, the function construct_dom0() is not
> used outside of domain_build.c anymore.
> So it is now a static function.
>
> No funct
On 13/04/2021 16:46, Steven Rostedt wrote:
> Hi Giuseppe,
>
> On Tue, 13 Apr 2021 16:28:36 +0200
> Giuseppe Eletto wrote:
>
>> Hello,
>> I want to share with you a new plugin developed by me, under the
>> supervision of Dario Faggioli, which allows the new version of KernelShark
>> (the v2-beta) t
On 14.04.2021 02:55, Chao Gao wrote:
> According to Intel VT-d SPEC rev3.3 Section 6.5, Register-based Invalidation
> isn't supported by Intel VT-d version 6 and beyond.
>
> This hardware change impacts following two scenarios: admin can disable
> queued invalidation via 'qinval' cmdline and use r
flight 161129 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161129/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 264aa183ad85b2779b27d1312724a291259ccc9f
baseline version:
xen 935d
Hi Giuseppe,
It is great to see such progress in the development of the Xen plugin.
Can you share with us what are your plans for continuing this work. Is
this a first prototype of the plugin, or it is an almost final version?
I was also thinking that maybe you can prepare a short tutorial on
This patch prevents the dom0 to be loaded skipping its
building and going forward to build domUs when the dom0
kernel is not found and at least one domU is present.
Signed-off-by: Luca Fancellu
Reviewed-by: Julien Grall
---
v3 changes:
- Rephrase documentation
---
docs/features/dom0less.pandoc
This patch adds a comment in create_domUs() right before
domain_create() to explain the importance of the pre-increment
operator on the variable max_init_domid, to ensure that the
domid 0 is allocated only during start_xen() function by the
create_dom0() and not on any other possible code path to t
Among the common and arm codebase there are few cases where
the hardware_domain variable is checked to see if the current
domain is equal to the hardware_domain, change this cases to
use is_hardware_domain() function instead.
Signed-off-by: Luca Fancellu
---
v4 changes:
- removed unneeded check f
Move dom0 create and start from setup.c to a dedicated
function in domain_build.c.
With this change, the function construct_dom0() is not
used outside of domain_build.c anymore.
So it is now a static function.
No functional changes intended.
Signed-off-by: Luca Fancellu
Reviewed-by: Julien Gral
This is the v2 of xen/arm: Prevent Dom0 to be loaded when using dom0less
previously pushed.
The aim of this serie is to prevent the creation and run of the domain 0 (Dom0)
when the system configuration to be used is dom0less, that is when the device
tree declares at least one domU and no Dom0.
Ch
Hi Roger,
On 14/04/2021 09:05, Roger Pau Monné wrote:
On Tue, Apr 13, 2021 at 06:12:10PM +0100, Julien Grall wrote:
Hi Roger,
On 12/04/2021 11:49, Roger Pau Monné wrote:
On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/pass
On 14.04.2021 10:28, Roger Pau Monné wrote:
> On Wed, Apr 14, 2021 at 09:08:53AM +0200, Jan Beulich wrote:
>> On 13.04.2021 19:12, Julien Grall wrote:
>>> On 12/04/2021 11:49, Roger Pau Monné wrote:
On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
> --- a/xen/include/xen/vpci.h
Hi Jan,
On 14/04/2021 08:08, Jan Beulich wrote:
On 13.04.2021 19:12, Julien Grall wrote:
On 12/04/2021 11:49, Roger Pau Monné wrote:
On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -91,6 +91,7 @@ struct vpci {
On Wed, Apr 14, 2021 at 09:08:53AM +0200, Jan Beulich wrote:
> On 13.04.2021 19:12, Julien Grall wrote:
> > On 12/04/2021 11:49, Roger Pau Monné wrote:
> >> On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
> >>> --- a/xen/include/xen/vpci.h
> >>> +++ b/xen/include/xen/vpci.h
> >>> @@ -9
According to Intel VT-d SPEC rev3.3 Section 6.5, Register-based Invalidation
isn't supported by Intel VT-d version 6 and beyond.
This hardware change impacts following two scenarios: admin can disable
queued invalidation via 'qinval' cmdline and use register-based interface;
VT-d switches to regis
On 13.04.2021 15:17, Andrew Cooper wrote:
> Do you have actual numbers from these experiments?
Attached is the collected raw output from a number of systems.
> I've seen your patch
> from the thread, but at a minimum its missing some hunks adding new
> CPUID bits.
It's not missing hunks - these
On Tue, Apr 13, 2021 at 06:12:10PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 12/04/2021 11:49, Roger Pau Monné wrote:
> > On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
> > > diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> > > index 705137f8be..1b4735
Am Wed, 14 Apr 2021 07:46:24 +0200
schrieb Juergen Gross :
> What about dropping the "xg_" prefix from the filenames?
None of the other moved files where renamed during the move.
But sure, if this the single blocking issue, why not.
Olaf
pgpdu6l7NZxZT.pgp
Description: Digitale Signatur von O
On 14.04.2021 07:46, Juergen Gross wrote:
> On 13.04.21 19:20, Olaf Hering wrote:
>> Move all save/restore related code from libxenguest.so into a separate
>> library libxensaverestore.so. The only consumer is libxl-save-helper.
>> There is no need to have the moved code mapped all the time in bina
On 13.04.2021 19:12, Julien Grall wrote:
> On 12/04/2021 11:49, Roger Pau Monné wrote:
>> On Fri, Apr 09, 2021 at 05:00:41PM +0100, Rahul Singh wrote:
>>> --- a/xen/include/xen/vpci.h
>>> +++ b/xen/include/xen/vpci.h
>>> @@ -91,6 +91,7 @@ struct vpci {
>>> /* FIXME: currently there's no s
On 13.04.2021 20:19, Julien Grall wrote:
> On 08/04/2021 13:23, Jan Beulich wrote:
>> There is a difference in generated code: xzalloc_bytes() forces
>> SMP_CACHE_BYTES alignment. I think we not only don't need this here, but
>> actually don't want it.
>
> So I think moving to xmalloc_flex_struct(
flight 161093 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161093/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow219 guest-localmigrate/x10 fail REGR. vs. 159418
Tests which ar
79 matches
Mail list logo
