>>> On 17.08.18 at 00:04, wrote:
> On Tue, Jul 10, 2018 at 04:14:11AM -0600, Jan Beulich wrote:
>> Having noticed that VMLOAD alone is about as fast as a single of the
>> involved WRMSRs, I thought it might be a reasonable idea to also use it
>> for PV. Measurements, however, have shown that an ac
>>> On 26.07.18 at 15:43, wrote:
> On 07/26/2018 04:07 PM, Jan Beulich wrote:
>> Don't chance having Spectre v1 (including BCBS) gadgets. In some of the
>> cases the insertions are more of precautionary nature rather than there
>> provably being a gadget, but I think we should err on the safe (sec
>>> On 27.07.18 at 16:20, wrote:
> In order to mostly eliminate abuse of what Xen leaves in the RSB by
> guest level attackers, fill the RSB with almost-NULL pointers right
> before entering guest context.
>
> The placement of the initialization code is intentional: If it was put
> in e.g. hvm_en
>>> On 01.08.18 at 16:22, wrote:
> When putting CPUs to sleep permanently, we should try to put them into
> the most power conserving state possible. For now it is unclear whether,
> especially in a deep C-state, the P-state also matters, so this series only
> arranges for the C-state side of thin
>>> On 09.08.18 at 11:09, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 09 August 2018 09:02
>> To: xen-devel
>> Cc: Andrew Cooper ; Paul Durrant
>> ; George Dunlap
>> Subject: [PATCH RFC] x86/HVM: meet xentrace's expectations on emulation
>> even
>>> On 17.08.18 at 08:45, wrote:
> I'm not really convinced of the change done in v3, even less so with
> x86'es pv/domain.h not really having been suitable for inclusion in
> spec-ctrl.c (needed an extra, seemingly unrelated adjustment), but
> in the interest of getting this done, here you go.
>
>>> On 17.08.18 at 08:42, wrote:
> Restore symmetry between get_page_from_le(): pv_l1tf_check_le is
> uniformly invoked from outside of them. They're no longer getting called
> for non-present PTEs. This way the slightly odd three-way return value
> meaning of the higher level ones can also be got
>>> On 21.08.18 at 12:44, wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no". In particular, the presence
> of "xpti=" alone on the command line means nothing a
flight 126813 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126813/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 126042
test-amd64-i386-rump
On Tue, Aug 28, 2018 at 06:39:00PM +0100, Andrew Cooper wrote:
> The trailing _domain suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
> where applicable.
>
> No functional change.
>
> Signed-off-by: Andrew Co
On Tue, Aug 28, 2018 at 06:39:01PM +0100, Andrew Cooper wrote:
> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
> where applicable.
>
> No functional change.
>
> Signed-off-by: Andrew Coop
On Tue, Aug 28, 2018 at 06:39:02PM +0100, Andrew Cooper wrote:
> The trailing _domain suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
> where applicable.
>
> No functional change.
>
> Signed-off-by: Andrew Co
On Tue, Aug 28, 2018 at 06:39:03PM +0100, Andrew Cooper wrote:
> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it.
>
> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers
> where applicable.
>
> No functional change.
>
> Signed-off-by: Andrew Coop
On Tue, Aug 28, 2018 at 06:39:06PM +0100, Andrew Cooper wrote:
> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all code
> refer to the correctly-named fields. This means that the data hierachy is no
On Tue, Aug 28, 2018 at 06:39:04PM +0100, Andrew Cooper wrote:
> The suffix and prefix are redundant, and the name is curiously odd. Rename it
> to vmx_vcpu to be consistent with all the other similar structures.
What other similar structures do you have in mind?
The code changes look okay to me
On Tue, Aug 28, 2018 at 07:11:54PM +0100, Andrew Cooper wrote:
> Unlike the PRINTK/DEBUG wrappers, these go straight out to the console, rather
> than ending up in the debugtrace buffer.
>
> A number of these users are followed by domain_crash(), and future changes
> will want to combine the print
On 29/08/18 08:52, Valentin Vidic wrote:
> Switching to closed state earlier can cause the block-drbd
> script to fail with 'Device is held open by someone':
>
> root: /etc/xen/scripts/block-drbd: remove XENBUS_PATH=backend/vbd/6/51712
> kernel: [ .278235] block drbd6: State change failed: Dev
On Tue, Aug 28, 2018 at 08:59:45AM -0600, Jan Beulich wrote:
> Checking them before the grant copy means nothing as to the validity of
> the incoming request. As we shouldn't make the new data live before
> having validated it, introduce a second instance of the mapping array.
>
> Signed-off-by: J
On Tue, Aug 28, 2018 at 09:00:14AM -0600, Jan Beulich wrote:
> There's no guarantee that the mapping array doesn't cross a page
> boundary. Use a second grant copy operation if necessary.
>
> Signed-off-by: Jan Beulich
Acked-by: Wei Liu
___
Xen-devel
On Wed, Aug 29, 2018 at 10:16:09AM +0200, Juergen Gross wrote:
> Did you test whether it is okay to not change state in case the device
> is still online?
Not sure how to simulate that. Maybe using xl block-detach or something else?
--
Valentin
___
Xe
On 29/08/18 10:27, Valentin Vidic wrote:
> On Wed, Aug 29, 2018 at 10:16:09AM +0200, Juergen Gross wrote:
>> Did you test whether it is okay to not change state in case the device
>> is still online?
>
> Not sure how to simulate that. Maybe using xl block-detach or something else?
>
I think this
On Wed, Aug 29, 2018 at 10:43:48AM +0200, Juergen Gross wrote:
> I think this should be an action triggered by the frontend, not by dom0
> (xen tools will always set "online" to 0 when removing a device, AFAIK).
>
> I'm not sure this is relevant, but I realized this behavior is changed
> by your p
On 29/08/18 11:23, Valentin Vidic wrote:
> On Wed, Aug 29, 2018 at 10:43:48AM +0200, Juergen Gross wrote:
>> I think this should be an action triggered by the frontend, not by dom0
>> (xen tools will always set "online" to 0 when removing a device, AFAIK).
>>
>> I'm not sure this is relevant, but I
... rather than setting the limits up after domain_create() has completed.
This removes the common gnttab infrastructure for calculating the number of
dom0 grant frames (as the common grant table code is not an appropriate place
for it to live), opting instead to require the dom0 construction code
flight 126844 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126844/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 1
flight 126835 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 125183
test-amd64-amd64-libv
flight 126934 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126934/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen b28cd21c36288a01ae61ed4f557802abc8ee03e4
baseline version:
xen a923
On Thu, Aug 23, 2018 at 12:57:33PM +0200, Roger Pau Monné wrote:
> Hello,
>
> SeaBIOS currently fails to build with newer versions of iasl due to:
>
> Compiling IASL src/fw/ssdt-pcihp.hex
> out/src/fw/ssdt-pcihp.dsl.i 5: DefinitionBlock ("ssdt-pcihp.aml",
> "SSDT", 0x01, "BXPC", "BXSSDTPC
Some change between 36e29dd9e5..b28cd21c3 breaks build of tools/firmware (The
pv shim?):
[ 391s] Error: size of alternative.o:.data.read_mostly is 0x01
[ 391s] make[11]: ***
[/home/abuild/rpmbuild/BUILD/xen-4.12.20180828T190111.b28cd21c36/non-dbg/tools/firmware/xen-dir/xen-root/xen/Rules.mk:20
On 29/08/18 11:27, Olaf Hering wrote:
> Some change between 36e29dd9e5..b28cd21c3 breaks build of tools/firmware (The
> pv shim?):
>
> [ 391s] Error: size of alternative.o:.data.read_mostly is 0x01
> [ 391s] make[11]: ***
> [/home/abuild/rpmbuild/BUILD/xen-4.12.20180828T190111.b28cd21c36/non-db
On Wed, Aug 29, 2018 at 11:21:00AM +0100, Wei Liu wrote:
> On Thu, Aug 23, 2018 at 12:57:33PM +0200, Roger Pau Monné wrote:
> > Hello,
> >
> > SeaBIOS currently fails to build with newer versions of iasl due to:
> >
> > Compiling IASL src/fw/ssdt-pcihp.hex
> > out/src/fw/ssdt-pcihp.dsl.i 5
On 29/08/18 11:30, Andrew Cooper wrote:
> On 29/08/18 11:27, Olaf Hering wrote:
>> Some change between 36e29dd9e5..b28cd21c3 breaks build of tools/firmware
>> (The pv shim?):
>>
>> [ 391s] Error: size of alternative.o:.data.read_mostly is 0x01
>> [ 391s] make[11]: ***
>> [/home/abuild/rpmbuild/
On Mon, Aug 13, Jan Beulich wrote:
> And hence the consideration of mapping in an all zeros page
> instead. This is because of the way __hvmemul_read() /
> __hvm_copy() work: The latter doesn't tell its caller how many
> bytes it was able to read, and hence the former considers the
> entire range
On 15/08/18 16:18, Jan Beulich wrote:
>
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -554,16 +554,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
ret = -EINVAL;
if ( (d == current->domain) || /* no domain_pause() *
On Wed, Aug 29, Andrew Cooper wrote:
> Is the offending object file available to inspect?
I will try to build it locally later today.
Olaf
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lis
On 29/08/18 11:37, Olaf Hering wrote:
> On Wed, Aug 29, Andrew Cooper wrote:
>
>> Is the offending object file available to inspect?
> I will try to build it locally later today.
Actually, I've spotted the problem. Just writing a patch.
~Andrew
___
Xe
On 29/08/18 11:36, Olaf Hering wrote:
> On Mon, Aug 13, Jan Beulich wrote:
>
>> And hence the consideration of mapping in an all zeros page
>> instead. This is because of the way __hvmemul_read() /
>> __hvm_copy() work: The latter doesn't tell its caller how many
>> bytes it was able to read, and h
c/s b28cd21c3628 "x86/build: Use new .nops directive when available"
introduced a __read_mostly boolean which is included if the toolchain supports
the .nops directive.
When CONFIG_LIVEPATCH is compiled out, alternative.o is expected to be a fully
init module, and toolchain_nops_are_ideal trips th
On Wed, Aug 29, Andrew Cooper wrote:
> Architecturally speaking, handing #MC back is probably the closest we
> can get to sensible behaviour, but it is still a bug that Linux is
> touching the ballooned out page in the first place.
Well, the issue is that a read crosses a page boundary. If that w
On Wed, Aug 29, Olaf Hering wrote:
> On Wed, Aug 29, Andrew Cooper wrote:
> > Is the offending object file available to inspect?
> I will try to build it locally later today.
It is attached.
Olaf
alternative.o.gz
Description: GNU Zip compressed data
signature.asc
Description: PGP signature
_
On 29/08/18 12:00, Olaf Hering wrote:
> On Wed, Aug 29, Andrew Cooper wrote:
>
>> Architecturally speaking, handing #MC back is probably the closest we
>> can get to sensible behaviour, but it is still a bug that Linux is
>> touching the ballooned out page in the first place.
> Well, the issue is t
On 29/08/18 12:09, Andrew Cooper wrote:
> On 29/08/18 12:00, Olaf Hering wrote:
>> On Wed, Aug 29, Andrew Cooper wrote:
>>
>>> Architecturally speaking, handing #MC back is probably the closest we
>>> can get to sensible behaviour, but it is still a bug that Linux is
>>> touching the ballooned out
On 29/08/18 09:03, Wei Liu wrote:
> On Tue, Aug 28, 2018 at 06:39:04PM +0100, Andrew Cooper wrote:
>> The suffix and prefix are redundant, and the name is curiously odd. Rename
>> it
>> to vmx_vcpu to be consistent with all the other similar structures.
> What other similar structures do you have
On 29/08/18 13:09, Andrew Cooper wrote:
> On 29/08/18 12:00, Olaf Hering wrote:
>> On Wed, Aug 29, Andrew Cooper wrote:
>>
>>> Architecturally speaking, handing #MC back is probably the closest we
>>> can get to sensible behaviour, but it is still a bug that Linux is
>>> touching the ballooned out
>>> On 29.08.18 at 12:57, wrote:
> c/s b28cd21c3628 "x86/build: Use new .nops directive when available"
> introduced a __read_mostly boolean which is included if the toolchain supports
> the .nops directive.
>
> When CONFIG_LIVEPATCH is compiled out, alternative.o is expected to be a fully
> init
>>> On 29.08.18 at 13:09, wrote:
> On 29/08/18 12:00, Olaf Hering wrote:
>> On Wed, Aug 29, Andrew Cooper wrote:
>>
>>> Architecturally speaking, handing #MC back is probably the closest we
>>> can get to sensible behaviour, but it is still a bug that Linux is
>>> touching the ballooned out page i
>>> On 29.08.18 at 12:36, wrote:
> On 15/08/18 16:18, Jan Beulich wrote:
>>
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -554,16 +554,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
>
> ret = -EINVAL;
> if ( (d == cu
On Mon, Aug 27, Olaf Hering wrote:
> Since about two weeks, no released qemu can be built against xen.git#staging.
> The error looks like that:
> qemu-20180825T130857.235c82acca/include/hw/xen/xen_common.h:677:5: error: too
> many arguments to function 'xc_domain_create'
> It looks like staging
On 29/08/18 13:10, Jan Beulich wrote:
On 29.08.18 at 12:36, wrote:
>> On 15/08/18 16:18, Jan Beulich wrote:
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -554,16 +554,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>> u_domctl)
>>
>>
On 21/08/18 11:44, Jan Beulich wrote:
> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
> this then became equivalent to "xpti=no".
That was accidental, but the end result is consistent with other options.
As
As a new x86 CPU Vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a Joint Venture between AMD and Haiguang Information Technology Co.,
Ltd., and aims at providing high performance x86 processor for China
server market.
The first generation Hygon's processor(Dhyana) originates from AMD
techno
To make Xen works functionly on Hygon platforms, reuse AMD's Xen support
code path for Hygon.
There are six core performance events counters per thread, so there are
six MSRs for these counters(0-5). Also there are four legacy PMC MSRs,
they are alias of the counters(0-3).
In this version of kern
On 17/08/18 08:04, Jan Beulich wrote:
> --- a/xen/include/asm-x86/pv/domain.h
> +++ b/xen/include/asm-x86/pv/domain.h
> @@ -21,6 +21,8 @@
> #ifndef __X86_PV_DOMAIN_H__
> #define __X86_PV_DOMAIN_H__
>
> +#include
Just types? Its all you need.
~Andrew
> +
> /*
> * PCID values for the addr
>>> On 29.08.18 at 14:29, wrote:
> On 29/08/18 13:10, Jan Beulich wrote:
> On 29.08.18 at 12:36, wrote:
>>> On 15/08/18 16:18, Jan Beulich wrote:
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -554,16 +554,9 @@ long
>>> do_domctl(XEN_GUEST_HANDLE_PARAM(xen
>>> On 29.08.18 at 14:41, wrote:
> On 17/08/18 08:04, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/pv/domain.h
>> +++ b/xen/include/asm-x86/pv/domain.h
>> @@ -21,6 +21,8 @@
>> #ifndef __X86_PV_DOMAIN_H__
>> #define __X86_PV_DOMAIN_H__
>>
>> +#include
>
> Just types? Its all you need.
Th
>>> On 29.08.18 at 14:36, wrote:
> On 21/08/18 11:44, Jan Beulich wrote:
>> While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
>> parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that
>> this then became equivalent to "xpti=no".
>
> That was accidental, but the end r
On Wed, Aug 29, 2018 at 11:57:02AM +0100, Andrew Cooper wrote:
> c/s b28cd21c3628 "x86/build: Use new .nops directive when available"
> introduced a __read_mostly boolean which is included if the toolchain supports
> the .nops directive.
>
> When CONFIG_LIVEPATCH is compiled out, alternative.o is
On 17/08/18 07:42, Jan Beulich wrote:
> Restore symmetry between get_page_from_le(): pv_l1tf_check_le is
> uniformly invoked from outside of them.
I'm not sure what symmetry you are referring to.
> They're no longer getting called
> for non-present PTEs. This way the slightly odd three-way retur
On Wed, Aug 29, 2018 at 12:17:46PM +0100, Andrew Cooper wrote:
> On 29/08/18 09:03, Wei Liu wrote:
> > On Tue, Aug 28, 2018 at 06:39:04PM +0100, Andrew Cooper wrote:
> >> The suffix and prefix are redundant, and the name is curiously odd.
> >> Rename it
> >> to vmx_vcpu to be consistent with all
On Wed, Aug 29, 2018 at 02:15:12PM +0100, Wei Liu wrote:
> On Wed, Aug 29, 2018 at 11:57:02AM +0100, Andrew Cooper wrote:
> > c/s b28cd21c3628 "x86/build: Use new .nops directive when available"
> > introduced a __read_mostly boolean which is included if the toolchain
> > supports
> > the .nops di
>>> On 29.08.18 at 15:16, wrote:
> On 17/08/18 07:42, Jan Beulich wrote:
>> Restore symmetry between get_page_from_le(): pv_l1tf_check_le is
>> uniformly invoked from outside of them.
>
> I'm not sure what symmetry you are referring to.
Just look at the current state: get_page_from_l[234]e() cal
With there not being any patching done based on it, we don't need this.
Non-patching conditionals can use opt_xpti instead.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* Debug builds: Wra
On 29/08/18 14:37, Jan Beulich wrote:
> With there not being any patching done based on it, we don't need this.
> Non-patching conditionals can use opt_xpti instead.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen
1: alternatives: fully leverage automatic NOP filling
2: move quoting of __ASM_{STAC,CLAC}
3: reduce "visibility" of spec_ctrl_asm.h
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/ma
As of commit 4008c71d7a ("x86/alt: Support for automatic padding
calculations") there's no point having explict ASM_NOPn instances in
alternatives anymore - drop them. As a result also drop the asm/nops.h
inclusion from alternative.h, adding explicit inclusions in the two
remaining C files needing
Both consumers want them quoted, so quote them right away instead of
using __stringify() upon use. In the spirit of other recent additions
also make the assembly forms assembler macros, allowing the helper
#define-s to be #undef-ed subsequently.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Other than indirect_thunk_asm.h, spec_ctrl_asm.h is a header generally
needed by assembly source files only. Avoid having all C sources have a
dependency on that header (the set of assembly sources now gaining a
dependency on the C header is much smaller and hence more acceptable).
Signed-off-by:
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific ha
On 29/08/18 14:48, Jan Beulich wrote:
> As of commit 4008c71d7a ("x86/alt: Support for automatic padding
> calculations") there's no point having explict ASM_NOPn instances in
> alternatives anymore - drop them. As a result also drop the asm/nops.h
> inclusion from alternative.h, adding explicit in
Three of the four hooks are not exposed outside of vmx.c, and all of
them have only a single possible non-NULL value. So there's no reason to
use hooks here - a simple set of flag indicators is sufficient (and we
don't even need a flag for the VM entry one, as it's always
(de-)activated together th
On 29/08/18 13:53, Jan Beulich wrote:
On 29.08.18 at 14:41, wrote:
>> On 17/08/18 08:04, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/pv/domain.h
>>> +++ b/xen/include/asm-x86/pv/domain.h
>>> @@ -21,6 +21,8 @@
>>> #ifndef __X86_PV_DOMAIN_H__
>>> #define __X86_PV_DOMAIN_H__
>>>
>>> +#i
As was validly pointed out as motivation for similar Linux side changes
(https://lkml.org/lkml/2018/6/22/677), using long sequences of
directives and auxiliary instructions, like is commonly the case when
setting up an alternative patch site, gcc can be mislead into believing
an asm() to be more he
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls, makin
On Mi, 2018-08-22 at 18:15 +0300, Isaila Alexandru wrote:
> On Mi, 2018-08-22 at 16:41 +0200, Roger Pau Monné wrote:
> >
> > On Wed, Aug 22, 2018 at 05:02:43PM +0300, Alexandru Isaila wrote:
> > >
> > >
> > > This patch is focused on moving changing hvm_save_one() to save
> > > one
> > > typecod
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent pat
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
---
v2:
Signed-off-by: Jan Beulich
---
v2: Drop open-coded number from macro invocation.
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -184,7 +184,7 @@ void ctxt_switch_levelling(const struct
}
if (ctxt_switch_masking)
- ctxt_switch_masking(next);
+
Instead of loading a pointer at each use site, have a single runtime
instance of struct genapic, copying into it from the individual
instances. The individual instances can this way also be moved to .init
(also adjust apic_probe[] at this occasion).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void send_IPI_mask(const cpumask_t *mask, int vector)
{
-gena
All flavors specify target_cpus_all() anyway - replace use of the hook
by &cpu_online_map.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/genapic/delivery.c
+++ b/xen/arch/x86/genapic/delivery.c
@@ -5,12 +5,6 @@
#include
#include
-
-const cpumask_t *target_cpus_all(void)
-{
- return &
This reduces the post-init memory footprint, eliminates a pointless
level of indirection at the use sites, and allows for subsequent
alternatives call patching.
Take the opportunity and also add a name to the PowerNow! instance.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/acpi/cp
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int __cpufreq_driver_target(struct cpufr
{
unsigned int prev
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
>>> On 29.08.18 at 16:02, wrote:
> On Mi, 2018-08-22 at 18:15 +0300, Isaila Alexandru wrote:
>> On Mi, 2018-08-22 at 16:41 +0200, Roger Pau Monné wrote:
>> > If you look at vcpu_hvm in tools/libxc/xc_dom_x86.c it saves the
>> > full
>> > domain context just to get the CPU and the MTRR state of VCP
1: fix FMA scalar operand sizes
2: extend MASKMOV{Q,DQU} tests
3: support AVX512 opmask insns
4: clean up AVX2 insn use in test harness
5: correct EVEX decoding
6: generalize vector length handling for AVX512/EVEX
While I also have ready a patch emulating the basic AVX512 moves,
its prereq to wide
On 09/08/18 09:01, Jan Beulich wrote:
> According to the logic in hvm_mmio_assist_process(), 64 bits of data are
> expected with 64-bit addresses, and 32 bits of data with 32-bit ones. I
> don't think this is very reasonable, but I'm also not going to touch the
> consumer side, the more that it is
FMA insns, other than the earlier AVX additions, don't use the low
opcode bit to distinguish between single and double vector elements.
While the difference is benign for packed flavors, the scalar ones
need to use VEX.W here. Oddly enough the table entries didn't even use
simd_scalar_fp, but unifo
While deriving the first AVX512 pieces from existing code I've got the
(in the end wrong) impression that the emulation of these insns would be
broken. Besides testing that the instructions act as no-ops when the
controlling mask bits are all zero, add ones to also check that the data
merging actua
These are all VEX encoded, so the EVEX decoding logic continues to
remain unused at this point.
The new testcase is deliberately coded in assembly, as a C one would
have become almost unreadable due to the overwhelming amount of
__builtin_...() that would need to be used. After all the compiler ha
Drop the pretty pointless conditionals from code testing AVX insns and
properly use AVX2 mnemonics in code testing AVX2 insns (the test harness
is already requiring sufficiently new a compiler/assembler).
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/t
To allow for some code sharing where possible, copy VEX.L into EVEX.LR
even for VEX (or XOP) encoded insns. Make operand size determination
use this right away, at the same time adding consistency checks for the
EVEX scalar insn cases (the non-scalar ones aren't uniform enough for
the checking to b
Fix an inverted pair of checks, drop an incorrect instance of #UD
raising for non-64-bit mode, and add further generic checks.
Note: Other than SDM Vol 2 rev 067 states, EVEX.V' is _not_ ignored
outside of 64-bit mode when the field does not encode a register.
Just like EVEX. is re
flight 126861 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126861/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 126780
test-armhf-armhf-libvirt 14 sav
Hi Jan,
On 08/29/2018 03:02 PM, Jan Beulich wrote:
+#define alternative_vcall2(func, arg1, arg2) ({ \
+ALT_CALL_ARG(arg1, 1);\
+ALT_CALL_ARG(arg2, 2);\
I believe this code has the same issue Stefano recently disc
>>> On 29.08.18 at 16:22, wrote:
> On 09/08/18 09:01, Jan Beulich wrote:
>> According to the logic in hvm_mmio_assist_process(), 64 bits of data are
>> expected with 64-bit addresses, and 32 bits of data with 32-bit ones. I
>> don't think this is very reasonable, but I'm also not going to touch th
For ARM, the call to arch_domain_create() needs to have completed before
domain_max_vcpus() will return the correct upper bound.
For each arch's dom0's, drop the temporary max_vcpus parameter, and allocation
of dom0->vcpu.
With d->max_vcpus now correctly configured before evtchn_init(), the poll
On 29/08/18 14:26, Jan Beulich wrote:
On 29.08.18 at 15:16, wrote:
>> On 17/08/18 07:42, Jan Beulich wrote:
>>> Restore symmetry between get_page_from_le(): pv_l1tf_check_le is
>>> uniformly invoked from outside of them.
>> I'm not sure what symmetry you are referring to.
> Just look at the c
>>> On 29.08.18 at 16:37, wrote:
> On 08/29/2018 03:02 PM, Jan Beulich wrote:
>> +#define alternative_vcall2(func, arg1, arg2) ({ \
>> +ALT_CALL_ARG(arg1, 1);\
>> +ALT_CALL_ARG(arg2, 2);\
>
> I believe this code has
On 29/08/18 15:00, Jan Beulich wrote:
> As was validly pointed out as motivation for similar Linux side changes
> (https://lkml.org/lkml/2018/6/22/677), using long sequences of
> directives and auxiliary instructions, like is commonly the case when
> setting up an alternative patch site, gcc can be
On 29/08/18 14:59, Jan Beulich wrote:
> Three of the four hooks are not exposed outside of vmx.c, and all of
> them have only a single possible non-NULL value. So there's no reason to
> use hooks here - a simple set of flag indicators is sufficient (and we
> don't even need a flag for the VM entry
1 - 100 of 159 matches
Mail list logo
