On 30/08/18 08:21, Jan Beulich wrote:
On 29.08.18 at 18:56, wrote:
>> On 28/08/18 14:33, Jan Beulich wrote:
>> On 28.08.18 at 14:14, wrote:
On 28/08/18 12:50, Jan Beulich wrote:
On 26.08.18 at 14:19, wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfi
This run is configured for baseline tests only.
flight 75140 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75140/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75136
test
This run is configured for baseline tests only.
flight 75139 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/75139/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-in
>>> On 29.08.18 at 18:56, wrote:
> On 28/08/18 14:33, Jan Beulich wrote:
> On 28.08.18 at 14:14, wrote:
>>> On 28/08/18 12:50, Jan Beulich wrote:
>>> On 26.08.18 at 14:19, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -60,6 +60,12 @@ config PV_LINEAR_P
>>> On 29.08.18 at 19:55, wrote:
> On 29/08/18 07:26, Jan Beulich wrote:
> On 29.08.18 at 01:06, wrote:
>>> Furthermore, to fix LBR handling, the first thing I'd have to do is
>>> revert this, so please leave it as it is.
>> Mind being a little more specific as to the whys here?
>
> When vmc
flight 126888 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126888/
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. 125898
test-amd64-amd64-ru
flight 126907 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126907/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
125057
Tests w
Move reference of ol1e ahead or else we see below warning.
cc1: warnings being treated as errors
grant_table.c: In function 'replace_grant_pv_mapping':
grant_table.c:142: warning: 'ol1e.l1' may be used uninitialized in this function
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/pv/grant_table.
On 2018-08-29 15:49, Juergen Gross wrote:
On 29/08/18 07:33, Steven Haigh wrote:
When playing with NUMA support recently, I noticed a host would always
hang
when trying to create a cpupool for the second NUMA node in the
system.
I was using the following commands:
# xl cpupool-create name=\"P
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 29, 2018 9:59 PM
>
> 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 suffic
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 29, 2018 1:39 AM
>
> 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 field
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 29, 2018 1:39 AM
>
> 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 function
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 29, 2018 1:39 AM
>
> 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.
>
> No functional change.
>
> Signed-off-b
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, August 29, 2018 1:39 AM
>
> 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 functi
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Sunday, August 26, 2018 8:20 PM
>
> This requires providing stubs for a few functions which are part of
> HVM code.
>
> Signed-off-by: Wei Liu
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xe
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Sunday, August 26, 2018 8:20 PM
>
> Functions are moved to hvm.c. Reorder makefile items while at it.
>
> Signed-off-by: Wei Liu
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xen
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, August 28, 2018 9:12 PM
> > +valid_mask = ((1ULL << v->domain->arch.cpuid->extd.maxphysaddr) -
> 1) &
> > + (PAGE_MASK | _PAGE_AVAIL | _PAGE_PRESENT);
>
> How did you come across this list? The only vali
> From: Wei Liu
> Sent: Sunday, August 26, 2018 8:20 PM
>
> They all incorrectly named a parameter virtual address while it should
> have been linear address.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Wei Liu
Reviewed-by: Kevin Tian
___
Xen-d
Hi,
I'm sorry this is a long email, but I wanted to explain everything
that I have tried, because it seems like quite a few different
versions of 32-bit upstream Linux kernel no longer boot as PV guest
and I'm surprised I am the first to encounter this. Probably I
have done something wrong.
I can
Hi Maintainers,
May I ask if this patch will be merged upstream or not? Our customer
is pushing us urgently with timeline for errata release and we are waiting
for official version from upstream.
Thanks
Zhenzhong
- zhenzhong.d...@oracle.com 写道：
> pci_conf_read8() needs pci mmcfg mapping to w
This run is configured for baseline tests only.
flight 75138 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75138/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 guest-start fail blocked in 75
flight 126876 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126876/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248
test-amd64-amd6
flight 126961 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126961/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 126935 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126935/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-amd64-xen-freebsd 7 xen-build-freebsdfail never pass
version targeted for testing:
fre
On Wed, 29 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 08/29/2018 12:47 AM, Stefano Stabellini wrote:
> > Add missing "CONFIG_"
>
> I would add the commit id where the bug was introduced.
>
> I will commit and add in the commit message:
>
> This build failure was introduced by commit 277
flight 126898 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126898/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
flight 126956 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126956/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-xsm
testid guest-start
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
T
flight 126919 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126919/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0fa0e56ee002cf369f7f4a1076eac52f813e03f0
baseline version:
ovmf f25cd80e4d823fa6f7d97
With not all physical cpus online (i.e. with smt=0) the output of hte
vcpu affinities is wrong, as the affinity bitmaps are capped after
nr_cpus bits, instead of using max_cpu_id.
Signed-off-by: Juergen Gross
---
tools/xl/xl_vcpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
With smt=0 some output of xl is wrong. Fix it.
Juergen Gross (2):
tools/libxl: correct vcpu affinity output with sparse physical cpu map
xen: fill topology info for online cpus only
tools/xl/xl_vcpu.c | 4 ++--
xen/common/sysctl.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
The topology information obtainable via XEN_SYSCTL_cputopoinfo is
filled rather weird: the size of the array is derived from the highest
online cpu number, while the data is set to "invalid" for not present
cpus only.
With smt=0 the information for parked threads is all zero, so it should
be best
On 8/29/18 8:43 PM, Tamas K Lengyel wrote:
> On Wed, Aug 29, 2018 at 10:42 AM Wei Liu wrote:
>>
>> On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
>> On 26.08.18 at 14:19, wrote:
There has been plan to make PV work, but it is not yet there. Provide
stubs to make it bui
On 29/08/18 07:26, Jan Beulich wrote:
On 29.08.18 at 01:06, wrote:
>> On 15/08/18 07:09, Jan Beulich wrote:
>>> @@ -96,13 +101,12 @@ __UNLIKELY_END(nsvm_hap)
>>> SPEC_CTRL_ENTRY_FROM_HVM/* Req: b=curr %rsp=regs/cpuinfo,
>>> Clob: acd */
>>> /* WARNING! `ret`, `call *`,
Uses MD5 on the host mac address, vm name and vif index to generate the last
three
bytes of the vm mac address (for each vm).
It uses the vif index to account for multiple vifs.
MD5 code is originally from the public domain (written by Colin Plumb in 1993),
files
found in xen/tools/blktap2/driver
Hi Stefano,
On 08/29/2018 12:47 AM, Stefano Stabellini wrote:
Add missing "CONFIG_"
I would add the commit id where the bug was introduced.
I will commit and add in the commit message:
This build failure was introduced by commit 277aa3523d "arm: make it
possible to disable the SMMU driver".
On Wed, Aug 29, 2018 at 10:42 AM Wei Liu wrote:
>
> On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
> > >>> On 26.08.18 at 14:19, wrote:
> > > There has been plan to make PV work, but it is not yet there. Provide
> > > stubs to make it build with !CONFIG_HVM.
> > >
> > > Signed-off-
On 26/07/18 14:07, 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 (secure)
> side here.
>
> Signed-off-by: Jan Beu
On 29/08/18 18:01, Volodymyr Babchuk wrote:
> Hi Andrew,
>
> On 29.08.18 19:22, Andrew Cooper wrote:
>> On 29/08/18 17:11, Volodymyr Babchuk wrote:
>>> Hello all,
>>>
>>> During xen hacking I often encounter white spaces at EOLs. It is quite
>>> annoying to see red marker in, say, xen/arch/arm/domc
Hi Andrew,
On 29.08.18 19:22, Andrew Cooper wrote:
On 29/08/18 17:11, Volodymyr Babchuk wrote:
Hello all,
During xen hacking I often encounter white spaces at EOLs. It is quite
annoying to see red marker in, say, xen/arch/arm/domctl.c:25
I used sed to create patch that removes all such whites
On 29/08/18 08:08, Jan Beulich wrote:
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 on
On 28/08/18 14:33, Jan Beulich wrote:
On 28.08.18 at 14:14, wrote:
>> On 28/08/18 12:50, Jan Beulich wrote:
>> On 26.08.18 at 14:19, wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -60,6 +60,12 @@ config PV_LINEAR_PT
config HVM
def_bool
On Mon, Aug 27, 2018 at 09:18:29AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, wrote:
> > There has been plan to make PV work, but it is not yet there. Provide
> > stubs to make it build with !CONFIG_HVM.
> >
> > Signed-off-by: Wei Liu
> > ---
> > xen/arch/x86/Makefile | 2 +
On Mon, Aug 27, 2018 at 09:13:04AM -0600, Jan Beulich wrote:
> >>> On 26.08.18 at 14:19, wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -4376,12 +4376,17 @@ int arch_acquire_resource(struct domain *d,
> > unsigned int type,
> >
> > switch ( type )
> > {
> > +#if
flight 126948 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126948/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, Aug 28, 2018 at 03:08:24AM -0600, Jan Beulich wrote:
> >>> On 28.08.18 at 10:45, wrote:
> > On Mon, Aug 27, 2018 at 08:29:20AM -0600, Jan Beulich wrote:
> >> >>> On 26.08.18 at 14:19, wrote:
> >> > --- a/xen/arch/x86/physdev.c
> >> > +++ b/xen/arch/x86/physdev.c
> >> > @@ -557,6 +557,7 @@
On 29/08/18 17:11, Volodymyr Babchuk wrote:
> Hello all,
>
> During xen hacking I often encounter white spaces at EOLs. It is quite
> annoying to see red marker in, say, xen/arch/arm/domctl.c:25
>
> I used sed to create patch that removes all such whitespaces. Command
> is simple:
>
> # find xen -n
Hello all,
During xen hacking I often encounter white spaces at EOLs. It is quite
annoying to see red marker in, say, xen/arch/arm/domctl.c:25
I used sed to create patch that removes all such whitespaces. Command is
simple:
# find xen -name "*.[ch]" | xargs sed -i "s/[[:space:]]*$//g"
Prob
flight 75137 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75137/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
75105
test-amd64-i386-i386-squeeze-ne
Eliminates a couple of branches in particular from the context switch
path.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -11,6 +11,7 @@
#include
+#include
#include
#include
#include
@@ -154,10 +155,15 @@ static inline unsigned long rd
On 29/08/18 15:02, Jan Beulich wrote:
> @@ -235,13 +243,58 @@ void init_or_livepatch apply_alternative
> continue;
> }
>
> -base->priv = 1;
> -
> memcpy(buf, repl, a->repl_len);
>
> /* 0xe8/0xe9 are relative branches; fix the offset. */
>
>>> On 28.08.18 at 19:39, wrote:
> @@ -76,11 +76,11 @@ static long register_guest_callback(struct
> callback_register *reg)
> switch ( reg->type )
> {
> case CALLBACKTYPE_event:
> -curr->arch.pv_vcpu.event_callback_eip= reg->address;
> +curr->arch.pv.event_callb
>>> On 28.08.18 at 19:39, 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 Cooper
Reviewed-by: Jan Beuli
On 29/08/18 15:06, Jan Beulich wrote:
> All flavors specify target_cpus_all() anyway - replace use of the hook
> by &cpu_online_map.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
ht
flight 126854 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126854/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 126683
test-armhf-armhf-libvirt 14 save
This run is configured for baseline tests only.
flight 75136 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75136/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75132
test
>>> On 29.08.18 at 15:55, wrote:
> 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 exist
>>> On 29.08.18 at 16:40, wrote:
> 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 corr
>>> On 29.08.18 at 16:42, wrote:
> 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 y
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
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 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 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
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 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
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
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
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
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
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
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
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
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
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 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
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
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
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
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 &
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/
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);
+
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:
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
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
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
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
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
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 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
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
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:
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
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
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
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
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 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
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
1 - 100 of 159 matches
Mail list logo
