flight 161175 xen-4.12-testing real [real]
flight 161194 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161175/
http://logs.test-lab.xenproject.org/osstest/logs/161194/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 161171 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161171/
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
Hi,
I observe much slower HVM start time than PVH, on Xen 4.14. It is using
qemu in (linux) stubdomain and direct kernel boot. The overall
difference is ~50s vs ~20s on some not particularly new laptop. On a
newer one I get 24s vs 6s, but I choose to debug it on the older one, as
the difference is
flight 161176 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161176/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3c13938079886e0e49031ab29a4f1ed7a4ceab68
baseline version:
ovmf 7cc8cd7b588964348013a
flight 161177 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161177/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 90320d569b830666afc369992a507a61f0668534
baseline version:
xtf 4288d41183a6a14f328504
flight 161161 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161161/
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 Wed, Apr 7, 2021 at 10:56 PM Jan Beulich wrote:
>
> On 07.04.2021 21:23, Christopher Clark wrote:
> > On Tue, Mar 30, 2021 at 7:31 AM Jan Beulich wrote:
> >>
> >> On 16.03.2021 04:56, Daniel P. Smith wrote:
> >>> To assist in reading, please find attached rendered copies of the design
> >>> do
On Mon, 5 Apr 2021, Julien Grall wrote:
> From: Julien Grall
>
> At the moment, we are computing offsets/masks for each level and
> granularity. This is a bit of waste given that we only need to
> know the offsets/masks for the granularity used by the guest.
>
> All the LPAE information can easi
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-debianhvm-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git:
flight 161179 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161179/
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 161153 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161153/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail in 161117 pass in
161153
test-amd64-amd64-xl-qemuu-deb
Hi,
On 14/04/2021 21:35, Stefano Stabellini wrote:
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:
flight 161169 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161169/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7cc8cd7b588964348013a3a01edf38c0182eca10
baseline version:
ovmf 2ad22420a710dc07e3b64
flight 161151 xen-4.12-testing real [real]
flight 161173 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161151/
http://logs.test-lab.xenproject.org/osstest/logs/161173/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
At 16:13 +0200 on 12 Apr (1618244032), Jan Beulich wrote:
> Move respective shadow code to its HVM-only source file, thus making it
> possible to exclude the hooks as well. This then shows that
> shadow_p2m_init() also isn't needed in !HVM builds.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Dee
At 16:07 +0200 on 12 Apr (1618243630), Jan Beulich wrote:
> As is the adjacent ga_to_gfn() one as well as paging_gva_to_gfn().
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
On 14/04/2021 09:12, Jan Beulich wrote:
> 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.
Wow Tulsa is vintage. Is that new enough to have nonstop_tsc ?
It's also quite possibly old e
At 18:03 +0200 on 15 Apr (1618509812), Jan Beulich wrote:
> On 15.04.2021 17:59, Tim Deegan wrote:
> > At 12:42 +0200 on 12 Apr (1618231332), Jan Beulich wrote:
> >> Some of them have entries with stale comments. Rather than correcting
> >> these comments, re-arrange how these arrays get populated,
At 13:46 +0200 on 12 Apr (1618235218), Jan Beulich wrote:
> The aspect of the function the second patch here changes has been
> puzzling me for many years. I finally thought I ought to make an
> attempt at reducing this to just a single get_page_from_l1e()
> invocation. The first patch mainly helps
On Wed, Apr 07, 2021 at 07:08:06PM +0200, Roger Pau Monné wrote:
> On Wed, Apr 07, 2021 at 05:51:14PM +0200, Jan Beulich wrote:
> > On 31.03.2021 12:32, Roger Pau Monne wrote:
> > > --- a/xen/arch/x86/hvm/irq.c
> > > +++ b/xen/arch/x86/hvm/irq.c
> > > +void hvm_gsi_execute_callbacks(unsigned int gs
On 15.04.2021 17:59, Tim Deegan wrote:
> At 12:42 +0200 on 12 Apr (1618231332), Jan Beulich wrote:
>> Some of them have entries with stale comments. Rather than correcting
>> these comments, re-arrange how these arrays get populated, shrinking
>> their sizes at the same time (by omitting trailing N
At 12:42 +0200 on 12 Apr (1618231332), Jan Beulich wrote:
> Some of them have entries with stale comments. Rather than correcting
> these comments, re-arrange how these arrays get populated, shrinking
> their sizes at the same time (by omitting trailing NULL entries: Use
> dedicated element initial
Thanks, @Jan and @Andrew
`make -C xen menuconfig` helped a lot
And indeed there a typo in the grub line
It's working now!
Thanks for helping with this question!
Atenciosamente,
*Charles Ferreira Gonçalves *
On Thu, Apr 15, 2021 at 3:01 PM Jan Beulich wrote:
> On 15.04.2021 15:55
On 15/04/2021 15:28, Jan Beulich wrote:
On 15.04.2021 16:24, Julien Grall wrote:
On 15/04/2021 15:22, Jan Beulich wrote:
On 15.04.2021 16:18, Julien Grall wrote:
On 15/04/2021 15:16, Jan Beulich wrote:
On 15.04.2021 13:58, Julien Grall wrote:
On 26/01/2021 09:52, Jan Beulich wrote:
-
flight 161167 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161167/
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
AMD Milan (Zen3) 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. The forcefully always on setting is
due to the addition o
Split the logic to attempt to setup 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é
Reviewed-by: Andrew Cooper
---
Changes since v1:
- Fix typo in commit message.
---
xen/arch/x86/cpu/amd.c
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 Jan,
On 15/04/2021 15:34, Jan Beulich wrote:
On 15.04.2021 16:30, Julien Grall wrote:
On 15/04/2021 15:25, Jan Beulich wrote:
On 15.04.2021 16:22, Julien Grall wrote:
On 15/04/2021 15:21, Jan Beulich wrote:
On 15.04.2021 13:59, Julien Grall wrote:
On 26/01/2021 09:52, Jan Beulich wrote:
On 15/04/2021 15:32, Jan Beulich wrote:
On 15.04.2021 16:21, Julien Grall wrote:
On 26/01/2021 09:53, Jan Beulich wrote:
All users have been removed in earlier changes.
This is not entirely correct given there is a still a user of...
Requested-by: Andrew Cooper
Signed-off-by: Jan Beuli
On 15.04.2021 14:09, Julien Grall wrote:
> On 26/01/2021 09:53, Jan Beulich wrote:
>> While for the original library's purposes these functions of course want
>> to be externally exposed, we don't need this, and we also don't want
>> this both to prevent unintended use and to keep the name space ti
On 15.04.2021 16:30, Julien Grall wrote:
> On 15/04/2021 15:25, Jan Beulich wrote:
>> On 15.04.2021 16:22, Julien Grall wrote:
>>> On 15/04/2021 15:21, Jan Beulich wrote:
On 15.04.2021 13:59, Julien Grall wrote:
> On 26/01/2021 09:52, Jan Beulich wrote:
>> With xen/common/decompress.h
On 15.04.2021 16:21, Julien Grall wrote:
> On 26/01/2021 09:53, Jan Beulich wrote:
>> All users have been removed in earlier changes.
>
> This is not entirely correct given there is a still a user of...
>
>>
>> Requested-by: Andrew Cooper
>> Signed-off-by: Jan Beulich
>> ---
>> v3: New.
>>
>> -
On 15/04/2021 15:25, Jan Beulich wrote:
On 15.04.2021 16:22, Julien Grall wrote:
On 15/04/2021 15:21, Jan Beulich wrote:
On 15.04.2021 13:59, Julien Grall wrote:
On 26/01/2021 09:52, Jan Beulich wrote:
With xen/common/decompress.h now agreeing in both build modes about
what STATIC expands
On 15.04.2021 16:24, Julien Grall wrote:
>
>
> On 15/04/2021 15:22, Jan Beulich wrote:
>> On 15.04.2021 16:18, Julien Grall wrote:
>>>
>>>
>>> On 15/04/2021 15:16, Jan Beulich wrote:
On 15.04.2021 13:58, Julien Grall wrote:
> On 26/01/2021 09:52, Jan Beulich wrote:
>> --- a/xen/commo
On 15.04.2021 16:22, Julien Grall wrote:
> On 15/04/2021 15:21, Jan Beulich wrote:
>> On 15.04.2021 13:59, Julien Grall wrote:
>>> On 26/01/2021 09:52, Jan Beulich wrote:
With xen/common/decompress.h now agreeing in both build modes about
what STATIC expands to, there's no need for this a
On 15/04/2021 15:22, Jan Beulich wrote:
On 15.04.2021 16:18, Julien Grall wrote:
On 15/04/2021 15:16, Jan Beulich wrote:
On 15.04.2021 13:58, Julien Grall wrote:
On 26/01/2021 09:52, Jan Beulich wrote:
--- a/xen/common/decompress.h
+++ b/xen/common/decompress.h
@@ -9,7 +9,6 @@
#
Hi,
As Dario already said, the plugin seems to work well with all the traces we
fed to it.
The largest trace was nearly 500MB, but still it had no trouble showing it.
The only minor troubles I encountered writing the plugin is with the
different data
types between KShark and XenTrace: for example
On 15/04/2021 15:21, Jan Beulich wrote:
On 15.04.2021 13:59, Julien Grall wrote:
On 26/01/2021 09:52, Jan Beulich wrote:
With xen/common/decompress.h now agreeing in both build modes about
what STATIC expands to, there's no need for this abstraction anymore.
Shouldn't you also mention "INI
On 15.04.2021 16:18, Julien Grall wrote:
>
>
> On 15/04/2021 15:16, Jan Beulich wrote:
>> On 15.04.2021 13:58, Julien Grall wrote:
>>> On 26/01/2021 09:52, Jan Beulich wrote:
--- a/xen/common/decompress.h
+++ b/xen/common/decompress.h
@@ -9,7 +9,6 @@
#define STATIC
On 15.04.2021 13:59, Julien Grall wrote:
> On 26/01/2021 09:52, Jan Beulich wrote:
>> With xen/common/decompress.h now agreeing in both build modes about
>> what STATIC expands to, there's no need for this abstraction anymore.
>
> Shouldn't you also mention "INIT" and "INITDATA" here?
Two parts:
On 26/01/2021 09:53, Jan Beulich wrote:
All users have been removed in earlier changes.
This is not entirely correct given there is a still a user of...
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/arm/efi/efi-dom0.c
+++ b/xen/arch/arm/efi/efi-dom0
On 15/04/2021 15:16, Jan Beulich wrote:
On 15.04.2021 13:58, Julien Grall wrote:
On 26/01/2021 09:52, Jan Beulich wrote:
--- a/xen/common/decompress.h
+++ b/xen/common/decompress.h
@@ -9,7 +9,6 @@
#define STATIC static
#define INIT __init
-#define INITDATA __initdata
#defin
On 15.04.2021 13:58, Julien Grall wrote:
> On 26/01/2021 09:52, Jan Beulich wrote:
>> --- a/xen/common/decompress.h
>> +++ b/xen/common/decompress.h
>> @@ -9,7 +9,6 @@
>>
>> #define STATIC static
>> #define INIT __init
>> -#define INITDATA __initdata
>>
>> #define malloc xmalloc_bytes
>
flight 161147 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161147/
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 15.04.2021 14:30, Roger Pau Monné wrote:
> On Thu, Apr 15, 2021 at 12:37:20PM +0200, Jan Beulich wrote:
>> On 15.04.2021 11:52, Roger Pau Monné wrote:
>>> On Mon, Nov 23, 2020 at 03:33:03PM +0100, Jan Beulich wrote:
--- a/tools/tests/cpu-policy/test-cpu-policy.c
+++ b/tools/tests/cpu-p
This is a note to let you know that I've just added the patch titled
xen/events: fix setting irq affinity
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
xen-events-fix-se
This is a note to let you know that I've just added the patch titled
xen/events: fix setting irq affinity
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
xen-events-fix-se
This is a note to let you know that I've just added the patch titled
xen/events: fix setting irq affinity
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
xen-events-fix-set
On 15.04.2021 15:21, Andrew Cooper wrote:
> The type is no longer appropriate for anything other than PV, and therefore
> should not retain its generic name.
>
> Fixes: 527922008bc ("x86: slim down hypercall handling when !PV32")
> Signed-off-by: Andrew Cooper
I'm not convinced this warrants a F
This is a note to let you know that I've just added the patch titled
xen/events: fix setting irq affinity
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
xen-events-fix-set
This is a note to let you know that I've just added the patch titled
xen/events: fix setting irq affinity
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
xen-events-fix-se
This is a note to let you know that I've just added the patch titled
xen/events: fix setting irq affinity
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
xen-events-fix-set
On 15.04.2021 15:55, Charles Gonçalves wrote:
> I've enabled the log_lvl=all guest_loglvl=all,
The first one is mis-spelled and needs to be "loglvl=".
> tried the xl debug-key +,
If this didn't help, did you perhaps not do a debug build of Xen?
Debug messages get completely compiled out of relea
On 15/04/2021 14:55, Charles Gonçalves wrote:
> Hello Guys,
>
> I've enabled the log_lvl=all guest_loglvl=all, tried the xl debug-key
> +, configured the build with
> ./configure --enable-debug
>
> Do I miss something?
./configure is for the userspace tools.
You want `make -C xen menuconfig` an
On Mon, Apr 12, 2021 at 08:28:45AM +0200, Juergen Gross wrote:
> The backport of upstream patch 25da4618af240fbec61 ("xen/events: don't
> unmask an event channel when an eoi is pending") introduced a
> regression for stable kernels 5.10 and older: setting IRQ affinity for
> IRQs related to interdom
On 15.04.2021 14:48, Andrew Cooper wrote:
> On 23/11/2020 14:32, Jan Beulich wrote:
>> --- a/xen/lib/x86/cpuid.c
>> +++ b/xen/lib/x86/cpuid.c
>> @@ -232,7 +232,9 @@ void x86_cpuid_policy_clear_out_of_range
>> ARRAY_SIZE(p->xstate.raw) - 1);
>> }
>>
>> -zero_leaves(p-
Hello Guys,
I've enabled the log_lvl=all guest_loglvl=all, tried the xl debug-key +,
configured the build with
./configure --enable-debug
Do I miss something?
xl info
6:15
host : xendev
release: 4.4.0-148-ge
On Wed, Apr 14, 2021 at 03:57:22PM +0200, Jan Beulich wrote:
> 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
> >>>
Hi Roger,
On 15/04/2021 14:26, Roger Pau Monné wrote:
On Wed, Apr 14, 2021 at 09:49:37AM +0100, Julien Grall wrote:
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 F
On Thu, 15 Apr 2021 02:50:53 +0200
Dario Faggioli wrote:
> 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
On Wed, Apr 14, 2021 at 09:49:37AM +0100, Julien Grall wrote:
> 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
The type is no longer appropriate for anything other than PV, and therefore
should not retain its generic name.
Fixes: 527922008bc ("x86: slim down hypercall handling when !PV32")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/pv/hypercall.c
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 binaries
where libxenguest.so is used.
According to size(1) the change is:
textdata
On 23/11/2020 14:32, Jan Beulich wrote:
> A maximum extended leaf input value with the high half different from
> 0x8000 should not be considered valid - all leaves should be cleared in
> this case.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Integrate into series.
>
> --- a/tools/tests/cpu-policy/
On Thu, Apr 01, 2021 at 12:19:16PM +0200, Jan Beulich wrote:
> Make this a separate archive member under lib/. While doing so, don't
> move latently broken x86 assembly though: Fix the constraints, such
> that properly extending inputs to 64-bit won't just be a side effect of
> needing to copy regi
flight 161159 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161159/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2ad22420a710dc07e3b644f91a5b55c09c39ecf3
baseline version:
ovmf c055be5b82d3591c531ce
On Mon, Nov 23, 2020 at 03:32:35PM +0100, Jan Beulich wrote:
> A maximum extended leaf input value with the high half different from
> 0x8000 should not be considered valid - all leaves should be cleared in
> this case.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On Thu, Apr 15, 2021 at 12:37:20PM +0200, Jan Beulich wrote:
> On 15.04.2021 11:52, Roger Pau Monné wrote:
> > On Mon, Nov 23, 2020 at 03:33:03PM +0100, Jan Beulich wrote:
> >> --- a/tools/tests/cpu-policy/test-cpu-policy.c
> >> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
> >> @@ -8,10 +8,13 @@
On Thu, Apr 15, 2021 at 11:36:18AM +0200, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
Hi Jan,
On 26/01/2021 09:53, Jan Beulich wrote:
While for the original library's purposes these functions of course want
to be externally exposed, we don't need this, and we also don't want
this both to prevent unintended use and to keep the name space tidy.
(When functions have no callers at al
Hi Jan,
On 26/01/2021 09:52, Jan Beulich wrote:
With xen/common/decompress.h now agreeing in both build modes about
what STATIC expands to, there's no need for this abstraction anymore.
Shouldn't you also mention "INIT" and "INITDATA" here?
Cheers,
Requested-by: Andrew Cooper
Signed-off-b
Hi Jan,
On 26/01/2021 09:52, Jan Beulich wrote:
With xen/common/decompress.h now agreeing in both build modes about
what STATIC expands to, there's no need for this abstraction anymore.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/decompress.h
+++ b/xe
Hi Jan,
On 26/01/2021 09:52, Jan Beulich wrote:
There's no need for this abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi Jan,
On 26/01/2021 09:51, Jan Beulich wrote:
There's no need for this abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi Jan,
On 26/01/2021 09:51, Jan Beulich wrote:
There's no need for this abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
---
v3: New.
--- a/xen/common/lzo.c
+++ b/xen/common/lzo.c
@@ -135,8 +135,8 @@
*/
#define MAX_255_COUNT
On 15.04.2021 12:04, Igor Druzhinin wrote:
> This MSR exists since Nehalem / Silvermont and is actively used by Linux,
> for instance, to improve sampling efficiency.
>
> Signed-off-by: Igor Druzhinin
Reviewed-by: Jan Beulich
Hi Jan,
On 26/01/2021 09:51, Jan Beulich wrote:
While tools/libs/guest/xg_private.h has its own (non-conflicting for our
purposes) __init, which hence needs to be #undef-ed, there's no other
need for this abstraction.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Acked-by: Julien G
On 15/04/2021 12:02, Jan Beulich wrote:
On 15.04.2021 12:26, Julien Grall wrote:
Hi Jan,
On 14/04/2021 08:03, Jan Beulich wrote:
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
On 14.04.2021 14:28, Jan Beulich wrote:
> 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
Actually I've just noticed that I can't ack thi
On 15.04.2021 12:53, Roger Pau Monné wrote:
> On Thu, Apr 15, 2021 at 11:34:55AM +0200, Jan Beulich wrote:
>> On x86, idle and other system domains are implicitly PV. While I
>> couldn't spot any cases where this is actively a problem, some cases
>> required quite close inspection to be certain the
On 15.04.2021 12:26, Julien Grall wrote:
> Hi Jan,
>
> On 14/04/2021 08:03, Jan Beulich wrote:
>> 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
On Thu, Apr 15, 2021 at 11:34:55AM +0200, Jan Beulich wrote:
> On x86, idle and other system domains are implicitly PV. While I
> couldn't spot any cases where this is actively a problem, some cases
> required quite close inspection to be certain there couldn't e.g. be
> some ASSERT_UNREACHABLE() t
On 15.04.2021 11:52, Roger Pau Monné wrote:
> On Mon, Nov 23, 2020 at 03:33:03PM +0100, Jan Beulich wrote:
>> --- a/tools/tests/cpu-policy/test-cpu-policy.c
>> +++ b/tools/tests/cpu-policy/test-cpu-policy.c
>> @@ -8,10 +8,13 @@
>> #include
>>
>> #include
>> +#include
>> #include
>> #inclu
Hi Jan,
On 14/04/2021 08:03, Jan Beulich wrote:
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
This MSR exists since Nehalem / Silvermont and is actively used by Linux,
for instance, to improve sampling efficiency.
Signed-off-by: Igor Druzhinin
---
Changes in v5:
- added Silvermont+ LBR_SELECT support
New patch in v4 as suggested by Andrew.
---
xen/arch/x86/hvm/vmx/vmx.c | 20 ++
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 is fixed
in hardware for that model and therefore it
On 01.04.2021 12:19, Jan Beulich wrote:
> Make this a separate archive member under lib/. While doing so, don't
> move latently broken x86 assembly though: Fix the constraints, such
> that properly extending inputs to 64-bit won't just be a side effect of
> needing to copy registers, and such that
On 01.04.2021 12:50, Paul Durrant wrote:
> On 01/04/2021 11:22, Roger Pau Monne wrote:
>> The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU
>> as current, as there's no support for EOI'ing interrupts on a remote
>> vCPU.
>>
>> While there also turn the unconditional assert at the t
On 01.04.2021 11:53, Jan Beulich wrote:
> The first patch was, under a different title and with a different
> approach, already part of the prior series of the same subject.
> The other two patches are new, resulting from me spotting further
> room for improvement (or so I hope).
>
> 1: latch to-b
On 01.04.2021 11:43, Jan Beulich wrote:
> So far we've taken care of just the immediate breakage caused by
> binutils 2.36. But we can also take advantage, in particular to
> avoid "manually" creating base relocations for xen.efi. Since it
> was requested and is possible with up-to-date binutils, i
On Mon, Nov 23, 2020 at 03:33:03PM +0100, Jan Beulich wrote:
> Zapping leaf data for out of range leaves is just one half of it: To
> avoid guests (bogusly or worse) inferring information from mere leaf
> presence, also shrink maximum indicators such that the respective
> trailing entry is not all
On 01.04.2021 10:33, Jan Beulich wrote:
> Except for an additional prereq Arm and x86 have the same needs here,
> and Arm can also benefit from the recent x86 side improvement. Recurse
> into arch/*/ only for a phony include target (doing nothing on Arm),
> and handle asm-offsets itself entirely lo
There are three noteworthy drawbacks:
1) The intercepts we need to enable here are CPL-independent, i.e. we
now have to emulate certain instructions for ring 0.
2) On VMX there's no intercept for SMSW, so the emulation isn't really
complete there.
3) The CR4 write intercept on SVM is lower pr
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in gnttab_populate_status_frames().
Signed-off-by: Jan Beulich
---
v3: Drop smp_wmb(). Re-base.
v2: Defer allocation to when a domain actually switches to th
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1105,7 +1105,7 @@ int arch_set_info_guest(
* update_cr3(), sh_update_cr3(), sh_walk_guest_tables(), and
* shadow_one_bit_disable() for why that is.
*/
- !is_hvm_domain(d
On x86, idle and other system domains are implicitly PV. While I
couldn't spot any cases where this is actively a problem, some cases
required quite close inspection to be certain there couldn't e.g. be
some ASSERT_UNREACHABLE() that would trigger in this case. Let's be on
the safe side and make su
1: correct is_pv_domain() when !CONFIG_PV
2: use is_pv_64bit_domain() to avoid double evaluate_nospec()
Jan
This combination doesn't really make sense (and there likely are more);
in particular even if the code built with both options set, HVM guests
wouldn't work (and I think one wouldn't be able to create one in the
first place). The alternative here would be some presumably intrusive
#ifdef-ary to get
On 26.01.2021 10:46, Jan Beulich wrote:
> Only patches 1 and 2 are strictly intended for 4.15, paralleling
> the recent Dom0 side work (and re-using many of the files
> introduced there, for the stubdom build), but ones up to at least
> patch 6 may still want considering (and 4 already has a releas
1 - 100 of 102 matches
Mail list logo
