[Xen-devel] [linux-linus test] 126888: regressions - FAIL
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-rumprun-amd64 12 guest-startfail REGR. vs. 125898 test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 125898 test-amd64-i386-xl 12 guest-start fail REGR. vs. 125898 test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 125898 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 125898 test-amd64-i386-pair 21 guest-start/debian fail REGR. vs. 125898 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-amd64-xl 12 guest-start fail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 125898 test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 125898 test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-amd64-pair21 guest-start/debian fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 125898 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125898 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-amd64-amd64-pvgrub 10 debian-di-install fail REGR. vs. 125898 test-amd64-i386-xl-raw 10 debian-di-installfail REGR. vs. 125898 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 125898 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs.
[Xen-devel] [xen-4.7-testing test] 126907: regressions - FAIL
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 which are failing intermittently (not blocking): test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 126716 pass in 126907 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail in 126716 pass in 126907 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-saverestore.2 fail in 126810 pass in 126907 test-armhf-armhf-xl-rtds 12 guest-start fail in 126810 pass in 126907 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 126810 pass in 126907 test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 126810 pass in 126907 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 126716 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail pass in 126810 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 10 debian-install fail in 126716 like 125057 test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 126810 like 125057 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125057 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125057 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125057 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 125057 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125057 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 125057 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125057 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125057 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 7ba1c7df881855422f9a475862565e94c8421b75 baseline version: xen 280a5568939c4a5832be787c8e0c23a19f30935a Last test of basis 125057 2018-07-09 08:36:04 Z 51 days Failing since125685 2018-07-30 12:39:38 Z 30 days 21 attempts Testing same since 125931 2018-08-15 22:51:23 Z 14 days 10 attempts People who touched revisions under test: Andrew Cooper Christian Lindig George Dunlap Jan
[Xen-devel] [PATCH] xen/grant: Mute gcc warning in steal_linear_address()
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.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/pv/grant_table.c b/xen/arch/x86/pv/grant_table.c index 6b7d855..5180334 100644 --- a/xen/arch/x86/pv/grant_table.c +++ b/xen/arch/x86/pv/grant_table.c @@ -167,6 +167,9 @@ static bool steal_linear_address(unsigned long linear, l1_pgentry_t *out) ol1e = *pl1e; okay = UPDATE_ENTRY(l1, pl1e, ol1e, l1e_empty(), mfn_x(gl1mfn), curr, 0); +if ( okay ) +*out = ol1e; + out_unlock: page_unlock(page); out_put: @@ -174,9 +177,6 @@ static bool steal_linear_address(unsigned long linear, l1_pgentry_t *out) out_unmap: unmap_domain_page(pl1e); -if ( okay ) -*out = ol1e; - out: return okay; } -- 1.7.3 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RFE: Detect NUMA misconfigurations and prevent machine freezes
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=\"Pool-1\" sched=\"credit2\ # xl cpupool-cpu-remove Pool-0 node:1 # xl cpupool-cpu-add Pool-1 node:1 After the last command, the system would hang - requiring a hard reset of the machine to fix. I tried a different variation with the same result: # xl cpupool-create name=\"Pool-1\" sched=\"credit2\ # xl cpupool-cpu-remove Pool-0 node:1 # xl cpupool-cpu-add Pool-1 12 It turns out that the RAM was installed sub-optimally in this machine. A partial output from 'xl info -n' shows: numa_info : node:memsizememfreedistances 0: 67584 62608 10,21 1: 0 0 21,10 A machine where we could get this working every time shows: node:memsizememfreedistances 0: 34816 30483 10,21 1: 32768 32125 21,10 As we can deduce RAM misconfigurations in this scenario, I believe we should check to ensure that RAM configuration / layout is sane *before* attempting to split the system and print a warning. This would prevent a hard system freeze in this scenario. RAM placement should not matter here. As the name already suggests cpupools do assignment of cpus. RAM allocated will be preferred taken from a local node, but this shouldn't be mandatory for success. Would it be possible to use a debug hypervisor (e.g. 4.12-unstable) for generating a verbose log (hypervisor boot parameter "loglvl=all") and sending the complete hypervisor log? I don't have a package for 4.11 or 4.12 built at all - but I did this on 4.10.2-pre (built from staging-4.10). Managed to get the same crash log when adding CPUs to Pool-1 as follows: Create the pool: (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns Add the CPUs: (XEN) Adding cpu 12 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Removing cpu 12 from runqueue 0 (XEN) Adding cpu 13 to runqueue 0 (XEN) Removing cpu 13 from runqueue 0 (XEN) Adding cpu 14 to runqueue 0 (XEN) Removing cpu 14 from runqueue 0 (XEN) Xen BUG at sched_credit2.c:3452 (XEN) Adding cpu 15 to runqueue 0 (XEN) [ Xen-4.10.2-pre x86_64 debug=n Not tainted ] (XEN) CPU:13 (XEN) RIP:e008:[] sched_credit2.c#csched2_schedule+0xf60/0x1330 (XEN) RFLAGS: 00010046 CONTEXT: hypervisor (XEN) rax: rbx: 82d080562500 rcx: fffd (XEN) rdx: 831040ae1f80 rsi: 000d rdi: 831050abfe38 (XEN) rbp: 831044ba7f30 rsp: 831050abfd20 r8: 831050ac61a0 (XEN) r9: 82d08022eee0 r10: 0001 r11: 83007dc11060 (XEN) r12: 000d r13: 831050aefec0 r14: 831050ac6180 (XEN) r15: 82d080562500 cr0: 8005003b cr4: 001526e0 (XEN) cr3: 7dc32000 cr2: 7fff9cb47838 (XEN) fsb: gsb: gss: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen code around (sched_credit2.c#csched2_schedule+0xf60/0x1330): (XEN) ff ff 0f 0b 0f 1f 40 00 <0f> 0b 0f 0b 4c 89 ef e8 d4 b6 ff ff e9 87 f1 ff (XEN) Xen stack trace from rsp=831050abfd20: (XEN)83107f5f6010 831050abfe38 002dd914464a 000d (XEN)02f8d264 8310 8310419efdd0 (XEN)831050ac6400 82d0802344fa 001bc97d2ea7 (XEN)002d9f005422 831050ac63c0 82d080562500 82d080577280 (XEN)000d 0046 0282 0082 (XEN)000d 831050ac61c8 82d080576fac 000d (XEN)83007dd7f000 831044ba8000 002dd914464a 831050ac6180 (XEN)82d080562500 82d080233eed 002d 831050ac61a0 (XEN)831050ab6010 82d080267cf5 82d0802bffe0 82d0802c4505 (XEN)002dd61b7fed 82d08023ae48 3800380b (XEN) 831050ab 82d08054bc80 82d080562500 (XEN)831050ab 82d0802375b2 82d0805771f0 82d08054c300 (XEN)82d0805771f0 000d 000d 82d08026d2d5 (XEN)83007dd7f000 83007dd7f000 83007dbae000 83107cd38000 (XEN) 83107fb0d000 82d080562500 (XEN) (XEN) 880736083fd8
Re: [Xen-devel] [PATCH v2 01/12] VMX: reduce number of posted-interrupt hooks
> 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 sufficient (and we > don't even need a flag for the VM entry one, as it's always > (de-)activated together the the vCPU blocking hook, which needs to > remain an actual function pointer). This is the more that with the > Spectre v2 workarounds indirect calls have become more expensive. > > Signed-off-by: Jan Beulich Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/7] x86/hvm: Drop hvm_{vmx,svm} shorthands
> 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 fields. This means that the data hierachy is no
> longer obscured from grep/cscope/tags/etc.
>
> Reformat one comment and switch one bool_t to bool while making
> changes.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Kevin Tian
one small note. In coverletter:
" This series started by trying to address the bug in patch 7,
and ballooned somewhat."
there is no bug per se in this patch, right?
Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/7] x86/hvm: Rename v->arch.hvm_vcpu to v->arch.hvm
> 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 functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/7] x86/vtx: Rename arch_vmx_struct to vmx_vcpu
> 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-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/7] xen/hvm: Rename d->arch.hvm_domain to d->arch.hvm
> 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 functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 09/23] x86/pt: make it build with !CONFIG_HVM
> 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 Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 10/23] x86/pt: split out HVM functions from vtd.c
> 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.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/6] VMX: correct PDPTE load checks
> 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 valid bits are Present, PWT > and PCD, while the upper nibble of control bits is documented as ignored > rather than reserved. Agree that PWT/PCD should be added to mask too. _PAGE_AVAIL is right here standing for ignored bits. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 01/23] x86: change name of parameter for various invlpg functions
> 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-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Problems booting 32-bit PV; just me or more widespread?
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 cannot get any of the Ubuntu packaged 32-bit mainline kernels after v4.13.16 that are found at http://kernel.ubuntu.com/~kernel-ppa/mainline/ to boot in 32-bit PV mode. All of them from v4.14.0rc1 onwards crash on xl create either saying "error: no XEN note found." or else immediately producing a kernel panic like: . . . [ 0.114370] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [ 0.114382] futex hash table entries: 256 (order: 2, 16384 bytes) [ 0.114423] pinctrl core: initialized pinctrl subsystem [ 0.134326] RTC time: 165:165:165, date: 165/165/65 [ 0.134442] NET: Registered protocol family 16 [ 0.134457] xen:grant_table: Grant tables using version 1 layout [ 0.134502] Grant table initialized [ 0.134544] audit: initializing netlink subsys (disabled) [ 0.134611] audit: type=2000 audit(1535307799.132:1): state=initialized audit_enabled=0 res=1 [ 0.134678] EISA bus registered [ 0.136019] PCI: setting up Xen PCI frontend stub [ 0.136073] BUG: unable to handle kernel paging request at edc21fd9 [ 0.136084] IP: eisa_bus_probe+0x19/0x36 [ 0.136089] *pdpt = 01ee6027 *pde = 29cc6067 *pte = [ 0.136100] Oops: [#1] SMP [ 0.136105] Modules linked in: [ 0.136111] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-33-generic #36-Ubuntu [ 0.136120] EIP: eisa_bus_probe+0x19/0x36 [ 0.136125] EFLAGS: 00010246 CPU: 0 [ 0.136130] EAX: edc21fd9 EBX: ECX: 01e0d000 EDX: 0200 [ 0.136138] ESI: c1d0d452 EDI: c1dd34a4 EBP: e9c89f24 ESP: e9c89f24 [ 0.136145] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: e021 [ 0.136154] CR0: 80050033 CR2: edc21fd9 CR3: 01e1 CR4: 00042660 [ 0.136166] Call Trace: [ 0.136173] do_one_initcall+0x49/0x174 [ 0.136179] ? parse_args+0x143/0x390 [ 0.136187] ? set_debug_rodata+0x14/0x14 [ 0.136193] kernel_init_freeable+0x149/0x1c5 [ 0.136201] ? rest_init+0xa0/0xa0 [ 0.136207] kernel_init+0xd/0xf0 [ 0.136213] ret_from_fork+0x2e/0x38 [ 0.14] Code: ff b8 df 43 ae c1 e8 35 1b 88 ff e8 20 12 88 ff c9 c3 3e 8d 74 26 00 55 b9 04 00 00 00 31 d2 b8 d9 ff 0f 00 89 e5 e8 35 8d 35 ff <8b> 10 81 fa 45 49 53 41 75 0a c7 05 a0 76 ed c1 01 00 00 00 e8 [ 0.14] EIP: eisa_bus_probe+0x19/0x36 SS:ESP: e021:e9c89f24 [ 0.14] CR2: edc21fd9 [ 0.14] ---[ end trace 8c00b3cb7d4f06ba ]--- [ 0.140013] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 (that one was from the currently-packaged linux-image-generic in Ubuntu 18.04 LTS). amd64 kernels work no problem. On the host I'm running Xen 4.10.1 with up to date XSAs. The guests are booted by either 32-bit or 64-bit pvgrub2 but to take that out of the picture I copied the kernels and initramfs files to the host and tried direct kernel boot. In that case I get: $ sudo xl create -c /var/tmp/debtest1.conf Parsing config from /var/tmp/debtest1.conf xc: error: panic: xc_dom_core.c:702: xc_dom_find_loader: no loader found: Invalid kernel libxl: error: libxl_dom.c:718:libxl__build_dom: xc_dom_parse_image failed: No such file or directory libxl: error: libxl_create.c:1264:domcreate_rebuild_done: Domain 43:cannot (re-)build domain: -3 libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 43:Non-existant domain libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 43:Unable to destroy guest libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 43:Destruction of domain failed The "No such file or directory" is strange as the file does exist at the correct path. I can only think that the previous "Invalid kernel" causes that. I then began to wonder what the situation was like in Debian. 32-bit Debian stable works fine, but that's a 4.9.x kernel. That works both from pvgrub2 and from direct kernel boot. A kernel based on 4.9.17 is available in stretch-backports so I tried that (linux-image-4.17.0-0.bpo.3-686). That behaves as above (either "No XEN note" from pvgrub2 or "Invalid kernel" from xl create). I then used the procedure described in the Debian Kernel Handbook (https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-kernel-org-package) to build a kernel from https://git.kernel.org/torvalds/t/linux-4.19-rc1.tar.gz. That also fails to boot in the same way. So, my investigations so far suggest that everything from v4.14.0 onwards will not boot as a 32-bit PV guest. Is this a known issue, or did I do something wrong? As I say, if it were an upstream kernel issue then I am surprised I am the first to encounter it, but perhaps the use of more modern kernel versions and 32-bit PV is quite low. If this is not a known issue then perhaps I can git bisect to find what broke this, or perform any other
[Xen-devel] 答复: [PATCH RESEND v3 2/2] x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling acpi_parse_dmar()
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 work on multiple pci > segments system such as HPE Superdome-Flex. > > Move acpi_mmcfg_init() call in acpi_boot_init() before calling > acpi_parse_dmar() so that when pci_conf_read8() is called in > acpi_parse_dev_scope(), we already have the mapping set up. > > mmio_ro_ranges initialization is also moved ahead as it's the only > dependency of pci_mmcfg_arch_enable() need to be moved. Also > checked codes between the old and new call sites to ensure we > don't break anything. > > Furthermore MMCFG will continue to not work this early (or > more precisely not at all until Dom0 boot has progressed far > enough) if the range(s) isn't/aren't marked reserved in E820. > > Signed-off-by: Zhenzhong Duan > Tested-by: Gopalasetty, Manoj > Reviewed-by: Roger Pau Monné > --- > xen/arch/x86/acpi/boot.c |2 ++ > xen/arch/x86/setup.c |8 +++- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c > index 8e6c96d..e89c2e9 100644 > --- a/xen/arch/x86/acpi/boot.c > +++ b/xen/arch/x86/acpi/boot.c > @@ -724,6 +724,8 @@ int __init acpi_boot_init(void) > > acpi_table_parse(ACPI_SIG_HPET, acpi_parse_hpet); > > + acpi_mmcfg_init(); > + > acpi_dmar_init(); > > erst_init(); > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index d5cc584..eabb011 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -1493,6 +1493,9 @@ void __init noreturn __start_xen(unsigned long > mbi_p) > > generic_apic_probe(); > > +mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", > + RANGESETF_prettyprint_hex); > + > acpi_boot_init(); > > if ( smp_found_config ) > @@ -1525,9 +1528,6 @@ void __init noreturn __start_xen(unsigned long > mbi_p) > /* Low mappings were only needed for some BIOS table parsing. */ > zap_low_mappings(); > > -mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", > - RANGESETF_prettyprint_hex); > - > init_apic_mappings(); > > normalise_cpu_order(); > @@ -1598,8 +1598,6 @@ void __init noreturn __start_xen(unsigned long > mbi_p) > > vesa_mtrr_init(); > > -acpi_mmcfg_init(); > - > early_msi_init(); > > iommu_setup();/* setup iommu if available */ > -- > 1.7.3 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 75138: tolerable FAIL
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 75134 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stopfail blocked in 75134 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail like 75134 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail like 75134 test-amd64-amd64-xl-pvshim 12 guest-start fail like 75134 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75134 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 75134 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail like 75134 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail like 75134 test-armhf-armhf-xl-rtds 12 guest-start fail like 75134 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail like 75134 test-armhf-armhf-libvirt 12 guest-start fail like 75134 test-armhf-armhf-xl-midway 12 guest-start fail like 75134 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail like 75134 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail like 75134 test-armhf-armhf-xl-credit2 12 guest-start fail like 75134 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 75134 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 75134 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 75134 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 75134 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 75134 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail like 75134 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuu19b599f7664b2ebfd0f405fb79c14dd241557452 baseline version: qemuu025573be71dab8d7885b787a6ca52d6d9bbfd75c Last test of basis75134 2018-08-28 14:18:16 Z1 days Testing same since75138 2018-08-29 14:56:08 Z0 days1 attempts People who touched revisions under test: Juan Quintela Markus Armbruster Peter Maydell Peter Xu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvhv2-amd
[Xen-devel] [xen-unstable-smoke test] 126961: tolerable all pass - PUSHED
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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 66235dd9f014e46b125c0f461c2f18a799de4d25 baseline version: xen 55924f9d923b51ce8ed6d2ecc7a3644a8562e8d9 Last test of basis 126956 2018-08-29 17:00:31 Z0 days Testing same since 126961 2018-08-29 20:03:42 Z0 days1 attempts People who touched revisions under test: Julien Grall Stefano Stabellini Stefano Stabellini jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 55924f9d92..66235dd9f0 66235dd9f014e46b125c0f461c2f18a799de4d25 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 126935: tolerable FAIL - PUSHED
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: freebsd 382458ed568f4213f38d121feedf23e44254eab7 baseline version: freebsd 7cbaa4254c0f10f7c00014ce9591ca60abfa57fb Last test of basis 126761 2018-08-27 09:19:01 Z2 days Testing same since 126935 2018-08-29 09:23:47 Z0 days1 attempts People who touched revisions under test: andrew brd cy gallatin imp jhb kevans kib lwhsu markj mckusick mw np philip jobs: build-amd64-freebsd-againpass build-amd64-freebsd pass build-amd64-xen-freebsd fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/freebsd.git 7cbaa4254c0..382458ed568 382458ed568f4213f38d121feedf23e44254eab7 -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: fix SMMU driver build
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 277aa3523d "arm: make it possible > to disable the SMMU driver". Thank you! > > > > Signed-off-by: Stefano Stabellini > > --- > > xen/drivers/passthrough/arm/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/xen/drivers/passthrough/arm/Makefile > > b/xen/drivers/passthrough/arm/Makefile > > index 0156431..b3efcfd 100644 > > --- a/xen/drivers/passthrough/arm/Makefile > > +++ b/xen/drivers/passthrough/arm/Makefile > > @@ -1,2 +1,2 @@ > > obj-y += iommu.o > > -obj-$(ARM_SMMU) += smmu.o > > +obj-$(CONFIG_ARM_SMMU) += smmu.o > > > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 126898: regressions - FAIL
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 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a version targeted for testing: libvirt 6c5f6cdab95c7c98b8a0ee6a7e6ccbab450ed7fc baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 85 days Failing since123840 2018-06-06 04:19:28 Z 84 days 65 attempts Testing same since 126898 2018-08-28 23:06:35 Z0 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bing Niu Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Clementine Hayat Cole Robinson Dan Kenigsberg Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jim Fehlig Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Lubomir Rintel Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Marek Marczykowski-Górecki Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Roman Bolshakov Shi Lei Shichangkuo Shivaprasad G Bhat Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský Vitaly Kuznetsov w00251574 Weilun Zhu xinhua.Cao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
[Xen-devel] [xen-unstable-smoke test] 126956: tolerable all pass - PUSHED
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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 55924f9d923b51ce8ed6d2ecc7a3644a8562e8d9 baseline version: xen 70c0144f924aea141574390faa5b35900e97a1a3 Last test of basis 126948 2018-08-29 14:01:13 Z0 days Testing same since 126956 2018-08-29 17:00:31 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 70c0144f92..55924f9d92 55924f9d923b51ce8ed6d2ecc7a3644a8562e8d9 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-xsm
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 Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: 2923b27e54242acf27fd16b299e102117c82f52f Bug not present: acb1872577b346bd15ab3a3f8dff780d6cca4b70 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/126957/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-xsm.guest-start.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-xsm.guest-start --summary-out=tmp/126957.bisection-summary --basis-template=125898 --blessings=real,real-bisect linux-linus test-amd64-i386-xl-xsm guest-start Searching for failure / basis pass: 126682 fail [host=albana0] / 125898 [host=albana1] 125702 [host=pinot0] 125676 ok. Failure / basis pass flights: 126682 / 125676 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) 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 Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 2923b27e54242acf27fd16b299e102117c82f52f c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 4f080070a9809bde857851e68a3aeff0c4b9b6a6 3a2b8525b883baa87fe89b3da58f5c09fa599b99 Basis pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#acb1872577b346bd15ab3a3f8dff780d6cca4b70-2923b27e54242acf27fd16b299e102117c82f52f git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60 git://xenbits.xen.org/qemu-xen.git#43139135a8938de44f66333831d3a8655d07663a-4f080070a9809bde857851e68a3aeff0c4b9b6a6 git://xenbits.xen.org/xen.git#e3f667bc5f51d0aa44357a64ca134cd952679c81-3a2b8525b883baa87fe89b3da58f5c09fa599b99 adhoc-revtuple-generator: tree discontiguous: linux-2.6 adhoc-revtuple-generator: tree discontiguous: qemu-xen From git://cache:9419/git://xenbits.xen.org/xen 55924f9d92..66235dd9f0 staging-> origin/staging Loaded 1003 nodes in revision graph Searching for test results: 125167 [host=italia0] 125242 [host=italia0] 125285 [host=italia0] 125401 [host=debina0] 125501 [host=rimava1] 125551 [host=baroque1] 125520 [host=debina1] 125585 [host=joubertin1] 125648 [host=elbling1] 125639 [host=fiano1] 125657 [host=albana1] 125676 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 125702 [host=pinot0] 125898 [host=albana1] 125921 blocked irrelevant 126069 blocked irrelevant 126202 blocked irrelevant 126310 [host=albana1] 126412 blocked irrelevant 126550 fail irrelevant 126682 fail 2923b27e54242acf27fd16b299e102117c82f52f c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 4f080070a9809bde857851e68a3aeff0c4b9b6a6 3a2b8525b883baa87fe89b3da58f5c09fa599b99 126927 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 4f080070a9809bde857851e68a3aeff0c4b9b6a6 29fd98e425346d9e15913eae6d079ddfc835d54c 126902 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a e3f667bc5f51d0aa44357a64ca134cd952679c81 126917 pass acb1872577b346bd15ab3a3f8dff780d6cca4b70 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 4f080070a9809bde857851e68a3aeff0c4b9b6a6 3dd454c6c694409aaedd4ed075d6aeace2dd8391 126905 fail 2923b27e54242acf27fd16b299e102117c82f52f c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 4f080070a9809bde857851e68a3aeff0c4b9b6a6
[Xen-devel] [ovmf test] 126919: all pass - PUSHED
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 f25cd80e4d823fa6f7d970d9f0ddb935327446ba Last test of basis 126874 2018-08-28 17:14:43 Z1 days Testing same since 126919 2018-08-29 05:34:58 Z0 days1 attempts People who touched revisions under test: Carsey, Jaben Jaben Carsey jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git f25cd80e4d..0fa0e56ee0 0fa0e56ee002cf369f7f4a1076eac52f813e03f0 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] fix smt=0 fallout
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(-) -- 2.16.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] xen: fill topology info for online cpus only
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 to return "invalid" information for offline cpus.
On a dual core system without this patch xl info -n will print:
cpu_topology :
cpu:coresocket node
0: 000
1: 000
2: 100
while with this patch the output is:
cpu_topology :
cpu:coresocket node
0: 000
2: 100
Signed-off-by: Juergen Gross
---
xen/common/sysctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 8e83c33a16..6cef6d310b 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -358,7 +358,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
num_cpus = ti->num_cpus;
for ( i = 0; i < num_cpus; ++i )
{
-if ( cpu_present(i) )
+if ( cpu_online(i) )
{
cputopo.core = cpu_to_core(i);
cputopo.socket = cpu_to_socket(i);
--
2.16.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/23] x86: monitor.o is currently HVM only
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 build with !CONFIG_HVM.
Signed-off-by: Wei Liu
---
xen/arch/x86/Makefile | 2 +-
xen/include/asm-x86/monitor.h | 14 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 9b9b63a..43f9189 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -45,7 +45,7 @@ obj-y += microcode_amd.o
obj-y += microcode_intel.o
obj-y += microcode.o
obj-y += mm.o x86_64/mm.o
-obj-y += monitor.o
+obj-$(CONFIG_HVM) += monitor.o
obj-y += mpparse.o
obj-y += nmi.o
obj-y += numa.o
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 4988903..09f7f8a 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -99,10 +99,24 @@ static inline uint32_t
arch_monitor_get_capabilities(struct domain *d)
int arch_monitor_domctl_event(struct domain *d,
struct xen_domctl_monitor_op *mop);
+#ifdef CONFIG_HVM
+
int arch_monitor_init_domain(struct domain *d);
void arch_monitor_cleanup_domain(struct domain *d);
+#else
+
+static inline int arch_monitor_init_domain(struct domain *d)
+{
+return 0;
+}
+
+static inline void arch_monitor_cleanup_domain(struct domain *d)
+{}
+
+#endif
>>>
>>> Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
>>> in vm_event_domctl() then better be put in an #ifdef instead?
>>
>> I didn't do that because that was common to both ARM and x86.
>>
>> But now looking at the ARM counterpart, it is not supported either. When
>> it is eventually supported on ARM, it will be likely to be dependent on
>> CONFIG_HVM anyway. So I think I can put XEN_DOMCTL_VM_EVENT_OP_MONITOR
>> under CONFIG_HVM.
>>
>
> It is not that it is not supported, it is that it's not (yet) needed.
> I think it would be better to have ifdef CONFIG_HVM only in code
> that's reached on x86 and not common ones.
FWIW, I agree with Tamas here.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] SVM: limit GIF=0 region
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 *`, `jmp *` not safe before this point. */ >>> >>> -STGI >>> -GLOBAL(svm_stgi_label) >>> +sti >> Nack. As indicated in v1, moving this breaks SPEC_CTRL_ENTRY_FROM_HVM >> (Even if there is an unexpected bug on the VT-x side of things which >> needs fixing differently). > Well, this increases the pressure to fix the issue. I very much > expect that fix to also take care of the code here. It was > therefore intentional that I did only the technically necessary > adjustments in v2. > > I would, btw, likely have tried to find time to look into fixing > that issue, but so far I was under the impression that you are > planning to, and since you've written the code I thought you'd > likely also be in a better position to do so. Its somewhere in the massive pile of still-security work that needs doing. It is not the most urgent of the still-security work to do, partly because this protection is currently in place. Top of the list, and most important, is still the toolstack CPUID/MSR interactions so we can feasibly tell a guest what it needs to know WRT L1TF. > >> 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 vmcb->virt_ext.fields.lbr_enable is clear and DEBUGCTL.LBR is set, the hypervisor must atomically switch the 5 LBR MSRs inside the critical region. Usage of DEBUGCTL.LBR is broken on pre-lbrv hardware (gen 1/2 svm?), and when suitably (mis)configured by nested virt. Other bugs include Xen's LBR setting leaking into guests. > From a purely formal pov, Boris'es R-b allows me to put the change in > as is. I'm not overly happy to do the requested change, but I > certainly will, provided - once again - I understand the reason. > > Furthermore, please don't forget that the more we delay > especially #MC, the more likely it becomes that a system will > crash in a far less obvious way than by logging an #MC. #MC's only get raised after the bank registers have been updated, so even if a shutdown occurs, the data will be captured by the firmware after reset. As for non-deferrable #MC's, a couple of extra stack/msr/vcpu references in the critical region doesn't alter the chances. We were never going to survive, or won't trigger a new one. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] libxl: made vm mac address assignment deterministic
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/drivers/.
Reported-by: George Dunlap
Signed-off-by: Joshua Perrett
---
tools/libxl/Makefile| 2 +-
tools/libxl/libxl_nic.c | 59 +--
tools/libxl/md5.c | 266
tools/libxl/md5.h | 26 +
4 files changed, 346 insertions(+), 7 deletions(-)
create mode 100644 tools/libxl/md5.c
create mode 100644 tools/libxl/md5.h
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 6da342ed61..6e7db11367 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -142,7 +142,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o
libxl_pci.o \
libxl_9pfs.o libxl_domain.o libxl_vdispl.o \
libxl_pvcalls.o libxl_vsnd.o libxl_vkb.o $(LIBXL_OBJS-y)
LIBXL_OBJS += libxl_genid.o
-LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
+LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o md5.o
LIBXL_TESTS += timedereg
LIBXL_TESTS_PROGS = $(LIBXL_TESTS) fdderegrace
diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
index 01b711b84e..37de5ffb04 100644
--- a/tools/libxl/libxl_nic.c
+++ b/tools/libxl/libxl_nic.c
@@ -17,6 +17,16 @@
#include "libxl_internal.h"
+#include
+
+#include "md5.h"
+
+#include
+#include
+#include
+#include
+#include
+
int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
const char *mac, libxl_device_nic *nic)
{
@@ -53,8 +63,36 @@ int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
return rc;
}
+static int libxl__get_host_mac(unsigned char *buf)
+{
+int success = -1;
+struct ifaddrs *iface_list;
+if (getifaddrs(_list) == 0) {
+for (struct ifaddrs *iface = iface_list;
+iface != NULL; iface = iface->ifa_next) {
+if (iface->ifa_addr && iface->ifa_addr->sa_family == AF_PACKET) {
+struct sockaddr_ll *s = (struct sockaddr_ll *)iface->ifa_addr;
+if (s->sll_halen == 6) {
+for (int i = 0; i < 6; i++) {
+buf[i] = s->sll_addr[i];
+}
+if(buf[0] || buf[1] || buf[2] || buf[3] || buf[4] ||
buf[5]) {
+success = 0;
+break;
+}
+}
+}
+}
+freeifaddrs(iface_list);
+} else {
+perror("ERROR: getifaddrs\n");
+}
+return success;
+}
+
static int libxl__device_nic_setdefault(libxl__gc *gc, uint32_t domid,
-libxl_device_nic *nic, bool hotplug)
+libxl_device_nic *nic, const char
*name,
+const int nic_index, bool hotplug)
{
int rc;
@@ -65,11 +103,20 @@ static int libxl__device_nic_setdefault(libxl__gc *gc,
uint32_t domid,
if (!nic->model) return ERROR_NOMEM;
}
if (libxl__mac_is_default(>mac)) {
-const uint8_t *r;
-libxl_uuid uuid;
+uint8_t r[16];
+
+uint8_t hostmac[6] = {0};
+
+if(libxl__get_host_mac(hostmac)) {
+perror("WARNING: failed to get host mac address\n");
+}
-libxl_uuid_generate();
-r = libxl_uuid_bytearray();
+MD5_CTX ctx;
+MD5Init();
+MD5Update(, hostmac, sizeof(hostmac));
+MD5Update(, (uint8_t *) name, strlen(name));
+MD5Update(, (uint8_t *) _index, sizeof(nic_index));
+MD5Final(r, );
nic->mac[0] = 0x00;
nic->mac[1] = 0x16;
@@ -478,7 +525,7 @@ int libxl__device_nic_set_devids(libxl__gc *gc,
libxl_domain_config *d_config,
* but qemu needs the nic information to be complete.
*/
ret = libxl__device_nic_setdefault(gc, domid, _config->nics[i],
- false);
+ d_config->c_info.name, i, false);
if (ret) {
LOGD(ERROR, domid, "Unable to set nic defaults for nic %d", i);
goto out;
diff --git a/tools/libxl/md5.c b/tools/libxl/md5.c
new file mode 100644
index 00..88ea13938a
--- /dev/null
+++ b/tools/libxl/md5.c
@@ -0,0 +1,266 @@
+/* start - public domain MD5 implementation */
+/*
+ * This code implements the MD5 message-digest algorithm.
+ * The algorithm is due to Ron Rivest. This code was
+ * written by Colin Plumb in 1993, no copyright is claimed.
+ * This code is in the public domain; do with it what you wish.
+ *
+ * Equivalent code is available from RSA Data Security, Inc.
+ * This code has been tested against that, and is equivalent,
+ * except that you don't
Re: [Xen-devel] [PATCH] xen/arm: fix SMMU driver build
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". Signed-off-by: Stefano Stabellini --- xen/drivers/passthrough/arm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile index 0156431..b3efcfd 100644 --- a/xen/drivers/passthrough/arm/Makefile +++ b/xen/drivers/passthrough/arm/Makefile @@ -1,2 +1,2 @@ obj-y += iommu.o -obj-$(ARM_SMMU) += smmu.o +obj-$(CONFIG_ARM_SMMU) += smmu.o -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/23] x86: monitor.o is currently HVM only
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-by: Wei Liu
> > > ---
> > > xen/arch/x86/Makefile | 2 +-
> > > xen/include/asm-x86/monitor.h | 14 ++
> > > 2 files changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > > index 9b9b63a..43f9189 100644
> > > --- a/xen/arch/x86/Makefile
> > > +++ b/xen/arch/x86/Makefile
> > > @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
> > > obj-y += microcode_intel.o
> > > obj-y += microcode.o
> > > obj-y += mm.o x86_64/mm.o
> > > -obj-y += monitor.o
> > > +obj-$(CONFIG_HVM) += monitor.o
> > > obj-y += mpparse.o
> > > obj-y += nmi.o
> > > obj-y += numa.o
> > > diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> > > index 4988903..09f7f8a 100644
> > > --- a/xen/include/asm-x86/monitor.h
> > > +++ b/xen/include/asm-x86/monitor.h
> > > @@ -99,10 +99,24 @@ static inline uint32_t
> > > arch_monitor_get_capabilities(struct domain *d)
> > > int arch_monitor_domctl_event(struct domain *d,
> > >struct xen_domctl_monitor_op *mop);
> > >
> > > +#ifdef CONFIG_HVM
> > > +
> > > int arch_monitor_init_domain(struct domain *d);
> > >
> > > void arch_monitor_cleanup_domain(struct domain *d);
> > >
> > > +#else
> > > +
> > > +static inline int arch_monitor_init_domain(struct domain *d)
> > > +{
> > > +return 0;
> > > +}
> > > +
> > > +static inline void arch_monitor_cleanup_domain(struct domain *d)
> > > +{}
> > > +
> > > +#endif
> >
> > Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
> > in vm_event_domctl() then better be put in an #ifdef instead?
>
> I didn't do that because that was common to both ARM and x86.
>
> But now looking at the ARM counterpart, it is not supported either. When
> it is eventually supported on ARM, it will be likely to be dependent on
> CONFIG_HVM anyway. So I think I can put XEN_DOMCTL_VM_EVENT_OP_MONITOR
> under CONFIG_HVM.
>
It is not that it is not supported, it is that it's not (yet) needed.
I think it would be better to have ifdef CONFIG_HVM only in code
that's reached on x86 and not common ones.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86: assorted array_index_nospec() insertions
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 Beulich I'm still not convinced by the update_domain_cpuid_info() change. It is a BCBS gadget, but is restricted to the toolstack only which can get at all the interesting data via legitimate means, and also not long for this world. Everything else LGTM. Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Dangling whitespaces in xen code
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/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" >>> >>> Problem is that patch is quite big: >>> >>> 285 files changed, 1463 insertions(+), 1463 deletions(-) >>> >>> So what is the best way to publish this fix? I can just send it to ML >>> as one patch. There is no functional changes, so should I add >>> maintainers? >>> >> >> There are more files than that. By my count, its: >> >> 307 files changed, 1586 insertions(+), 1586 deletions(-) > I tried to fix only *.c and *.h files. With COPYINGs, READMEs, > makefiles, and so on I got > > 309 files changed, 1599 insertions(+), 1599 deletions(-) > > >> In the past, it has been the view that fixing this all in one go might >> be too intrusive to people developing series. Then again, since the >> last time this was discussed, we've switched from hg to git as a base >> VCS, and git rebase has no issues coping with trailing whitespace >> changes. > > Also there is --ignore-space-change and --ignore-whitespace, so > developers and maintainers will be able to rebase changes without much > effort. > >> We've been fixing it as we go, but it is very slow going. I've got half >> a mind to suggest that we just commit a single fix and call it done... > I can't find a better solution. At first I though to fix them manually > in places where I see them. But then, why should I include fixes for > some files and not include for others? How to chose which files should > be fixed and which - not? So, I think it is better to fix all in > single commit. > > Another solution that I can see is to ask maintainers to provide > patches for own subsystems. Getting the fix into the tree is trivial, and most easily done by one of the committers, if the community can agree that its a sensible thing to do. FWIW, +1 to getting it fixed and removing the problem completely. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Dangling whitespaces in xen code
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 whitespaces. Command is simple: # find xen -name "*.[ch]" | xargs sed -i "s/[[:space:]]*$//g" Problem is that patch is quite big: 285 files changed, 1463 insertions(+), 1463 deletions(-) So what is the best way to publish this fix? I can just send it to ML as one patch. There is no functional changes, so should I add maintainers? There are more files than that. By my count, its: 307 files changed, 1586 insertions(+), 1586 deletions(-) I tried to fix only *.c and *.h files. With COPYINGs, READMEs, makefiles, and so on I got 309 files changed, 1599 insertions(+), 1599 deletions(-) In the past, it has been the view that fixing this all in one go might be too intrusive to people developing series. Then again, since the last time this was discussed, we've switched from hg to git as a base VCS, and git rebase has no issues coping with trailing whitespace changes. Also there is --ignore-space-change and --ignore-whitespace, so developers and maintainers will be able to rebase changes without much effort. We've been fixing it as we go, but it is very slow going. I've got half a mind to suggest that we just commit a single fix and call it done... I can't find a better solution. At first I though to fix them manually in places where I see them. But then, why should I include fixes for some files and not include for others? How to chose which files should be fixed and which - not? So, I think it is better to fix all in single commit. Another solution that I can see is to ask maintainers to provide patches for own subsystems. -- Volodymyr Babchuk ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH 0/5] x86: more power-efficient CPU parking
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 only >> arranges for the C-state side of things (plus some cleanup). >> >> 1: x86/cpuidle: replace a pointless NULL check >> 2: x86/idle: re-arrange dead-idle handling >> 3: x86/cpuidle: push parked CPUs into deeper sleep states when possible >> 4: x86/cpuidle: clean up Cx dumping >> 5: x86: place non-parked CPUs into wait-for-SIPI state after offlining I don't have a problem in principle, but I'm afraid that you're going to need either positive documentation, or a positive statement from Intel and AMD that wait-for-SIPI is the most power efficient state to park a CPU in. At a guess, I'd expect that wait-for-SIPI isn't an optimised state (because the vendors wouldn't expect hardware to be in this state after boot), and from the various discussions around L1TF, there are definitely differences between wait-for-SIPI and mwait. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 21/23] x86: expose CONFIG_HVM
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 y + prompt "HVM / PVH support" + ---help--- +Interfaces to support HVM and PVH guests. >> This definitely needs more than a single line... >> + +If unsure, say Y. + config SHADOW_PAGING >>> No double blank lines please. >>> >>> My previously voiced reservations wrt the shim remain. I continue >>> to disagree with Andrew that the symbol needs to be visible in a >>> shim-only config, and I continue to demand as a minimum that the >>> default here be N in that case if the symbol really is to remain visible. >> Conditionally influencing the default is fine. Hiding the symbol is not. >> >> To be very very clear, I will nack/revert any patch which tries to >> insert a dependency here. I find your reasoning to be wrong, and >> sufficiently short sighted and detrimental to users, that I'm not going >> to let the patch in. > Since iirc you didn't respond to my most recent comment on v1 here, > I would have very much hoped you'd explain your position a little > better than just claiming that the symbol becoming invisible with a > dependency added is a bad thing. I'm certainly open to (good) > arguments, but I'm not accepting a plain statement without proper > explanation. I'm not sure how to put this any more clearly. Our users cannot read *your* mind when they are trying to use `make menuconfig`. Since our users are not experts in Xen, the lack of an HVM option is going to cause confusion and questions to mailing lists/IRC, rather than the realisation that (obviously?) they needed to disable PV_SHIM_EXCLUSIVE first. It does not matter if people accidentally select both options, because they'll end up with the same build as exists today, and a fractionally larger than necessary hypervisor. It does matter that people can sensibly navigate the menu without unnecessary confusion. Finally (and minor in comparison), from the point of view of keeping our interfaces clean, we'll want Randconfig to occasionally test with both of them enabled. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/23] x86: monitor.o is currently HVM only
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 +-
> > xen/include/asm-x86/monitor.h | 14 ++
> > 2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > index 9b9b63a..43f9189 100644
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -45,7 +45,7 @@ obj-y += microcode_amd.o
> > obj-y += microcode_intel.o
> > obj-y += microcode.o
> > obj-y += mm.o x86_64/mm.o
> > -obj-y += monitor.o
> > +obj-$(CONFIG_HVM) += monitor.o
> > obj-y += mpparse.o
> > obj-y += nmi.o
> > obj-y += numa.o
> > diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> > index 4988903..09f7f8a 100644
> > --- a/xen/include/asm-x86/monitor.h
> > +++ b/xen/include/asm-x86/monitor.h
> > @@ -99,10 +99,24 @@ static inline uint32_t
> > arch_monitor_get_capabilities(struct domain *d)
> > int arch_monitor_domctl_event(struct domain *d,
> >struct xen_domctl_monitor_op *mop);
> >
> > +#ifdef CONFIG_HVM
> > +
> > int arch_monitor_init_domain(struct domain *d);
> >
> > void arch_monitor_cleanup_domain(struct domain *d);
> >
> > +#else
> > +
> > +static inline int arch_monitor_init_domain(struct domain *d)
> > +{
> > +return 0;
> > +}
> > +
> > +static inline void arch_monitor_cleanup_domain(struct domain *d)
> > +{}
> > +
> > +#endif
>
> Wouldn't the entire XEN_DOMCTL_VM_EVENT_OP_MONITOR case
> in vm_event_domctl() then better be put in an #ifdef instead?
I didn't do that because that was common to both ARM and x86.
But now looking at the ARM counterpart, it is not supported either. When
it is eventually supported on ARM, it will be likely to be dependent on
CONFIG_HVM anyway. So I think I can put XEN_DOMCTL_VM_EVENT_OP_MONITOR
under CONFIG_HVM.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 11/23] x86: XENMEM_resource_ioreq_server is HVM only
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 )
> > {
> > +#ifdef CONFIG_HVM
> > case XENMEM_resource_ioreq_server:
> > {
> > ioservid_t ioservid = id;
> > unsigned int i;
> >
> > rc = -EINVAL;
> > +if ( !is_hvm_domain(d) )
> > +break;
> > +
> > +rc = -EINVAL;
> > if ( id != (unsigned int)ioservid )
> > break;
>
> Since this is the only caller of hvm_get_ioreq_server_frame(),
> adding an is_hvm_domain() check here means the one inside
> the function becomes redundant - it should be dropped or
> converted to an ASSERT() imo. Furthermore if the check is to
> remain here, please drop the redundant assignment of rc.
A general principle I have been sticking to is the common code should
make sure guest type specific function should only be called when
necessary by using is_hvm/pv_*. Restructuring the code like that makes
DCE work effectively.
That means a lot of the checks in hvm_/pv_ functions should lifted out
and turned into ASSERT.
For this patch, is_hvm_domain in the case branch will remain and the one
in hvm_get_ioreq_server_frame will be turned into ASSERT.
Wei.
>
> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 126948: tolerable all pass - PUSHED
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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 70c0144f924aea141574390faa5b35900e97a1a3 baseline version: xen b28cd21c36288a01ae61ed4f557802abc8ee03e4 Last test of basis 126887 2018-08-28 20:01:07 Z0 days Testing same since 126948 2018-08-29 14:01:13 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git b28cd21c36..70c0144f92 70c0144f924aea141574390faa5b35900e97a1a3 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI
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 @@ ret_t do_physdev_op(int cmd,
> >> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >> >
> >> > ret = pci_mmcfg_reserved(info.address, info.segment,
> >> > info.start_bus, info.end_bus,
> >> > info.flags);
> >> > +#ifdef CONFIG_HAS_VPCI
> >> > if ( !ret && has_vpci(currd) )
> >> > {
> >> > /*
> >> > @@ -567,6 +568,7 @@ ret_t do_physdev_op(int cmd,
> >> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >> >info.start_bus,
> >> > info.end_bus,
> >> >info.segment);
> >> > }
> >> > +#endif
> >>
> >> Perhaps better to make has_vpci() evaluate to false in that case,
> >> and once again rely on DCE?
> >
> > But then that goes back to your previous argument that it creates
> > disconnection between emulation_flags_ok and has_*. If we want to change
> > has_vpci I would also need to change emulation_flags_ok. Is that what
> > you prefer?
>
> Hmm, I see. Utilizing DCE here seems pretty desirable. Perhaps
> emulation_flags_ok() should be switched to use derived constants
> rather than the raw public interface ones. The HVM-only ones
> then would simply become constant zero when !HVM, allowing
> emulation_flags_ok() as well as the has_*() macros to be left alone
> and DCE still be utilized.
I have written a new patch to introduce a set of internal flags. It did
work as expected.
Also dropped this patch from the queue.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Dangling whitespaces in xen code
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 -name "*.[ch]" | xargs sed -i "s/[[:space:]]*$//g" > > Problem is that patch is quite big: > > 285 files changed, 1463 insertions(+), 1463 deletions(-) > > So what is the best way to publish this fix? I can just send it to ML > as one patch. There is no functional changes, so should I add > maintainers? > There are more files than that. By my count, its: 307 files changed, 1586 insertions(+), 1586 deletions(-) for the Xen subtree, and 725 files changed, 5183 insertions(+), 5183 deletions(-) for the entire tree. In the past, it has been the view that fixing this all in one go might be too intrusive to people developing series. Then again, since the last time this was discussed, we've switched from hg to git as a base VCS, and git rebase has no issues coping with trailing whitespace changes. We've been fixing it as we go, but it is very slow going. I've got half a mind to suggest that we just commit a single fix and call it done... ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Dangling whitespaces in xen code
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" Problem is that patch is quite big: 285 files changed, 1463 insertions(+), 1463 deletions(-) So what is the best way to publish this fix? I can just send it to ML as one patch. There is no functional changes, so should I add maintainers? -- Volodymyr Babchuk ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-squeeze test] 75137: tolerable FAIL
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-netboot-pygrub 10 debian-di-install fail like 75105 test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 75105 test-amd64-i386-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 75105 baseline version: flight 75105 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-squeeze-netboot-pygrubfail test-amd64-i386-amd64-squeeze-netboot-pygrub fail test-amd64-amd64-i386-squeeze-netboot-pygrub fail test-amd64-i386-i386-squeeze-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86: use alternatives for FS/GS base accesses
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 rdfsbase(voi
{
unsigned long base;
-if ( cpu_has_fsgsbase )
-return __rdfsbase();
-
-rdmsrl(MSR_FS_BASE, base);
+alternative_io("mov %[msr], %%ecx\n\t"
+ "rdmsr\n\t"
+ "shl $32, %%rdx\n\t"
+ "or %%rdx, %[res]",
+ /* rdfsbase rax */
+ ".byte 0xf3, 0x48, 0x0f, 0xae, 0xc0",
+ X86_FEATURE_FSGSBASE,
+ [res] "=" (base),
+ [msr] "i" (MSR_FS_BASE) : "rcx", "rdx");
return base;
}
@@ -166,10 +172,15 @@ static inline unsigned long rdgsbase(voi
{
unsigned long base;
-if ( cpu_has_fsgsbase )
-return __rdgsbase();
-
-rdmsrl(MSR_GS_BASE, base);
+alternative_io("mov %[msr], %%ecx\n\t"
+ "rdmsr\n\t"
+ "shl $32, %%rdx\n\t"
+ "or %%rdx, %[res]",
+ /* rdgsbase rax */
+ ".byte 0xf3, 0x48, 0x0f, 0xae, 0xc8",
+ X86_FEATURE_FSGSBASE,
+ [res] "=" (base),
+ [msr] "i" (MSR_GS_BASE) : "rcx", "rdx");
return base;
}
@@ -178,59 +189,58 @@ static inline unsigned long rdgsshadow(v
{
unsigned long base;
-if ( cpu_has_fsgsbase )
-{
-asm volatile ( "swapgs" );
-base = __rdgsbase();
-asm volatile ( "swapgs" );
-}
-else
-rdmsrl(MSR_SHADOW_GS_BASE, base);
+alternative_io("mov %[msr], %%ecx\n\t"
+ "rdmsr\n\t"
+ "shl $32, %%rdx\n\t"
+ "or %%rdx, %[res]",
+ /* Wrapping RDGSBASE in a pair of SWAPGS. */
+ "swapgs\n\t"
+ ".byte 0xf3, 0x48, 0x0f, 0xae, 0xc8\n\t" /* rdgsbase rax */
+ "swapgs",
+ X86_FEATURE_FSGSBASE,
+ [res] "=" (base),
+ [msr] "i" (MSR_SHADOW_GS_BASE) : "rcx", "rdx");
return base;
}
static inline void wrfsbase(unsigned long base)
{
-if ( cpu_has_fsgsbase )
-#ifdef HAVE_AS_FSGSBASE
-asm volatile ( "wrfsbase %0" :: "r" (base) );
-#else
-asm volatile ( ".byte 0xf3, 0x48, 0x0f, 0xae, 0xd0" :: "a" (base) );
-#endif
-else
-wrmsrl(MSR_FS_BASE, base);
+alternative_input("mov %[msr], %%ecx\n\t"
+ "mov %[val], %%rdx\n\t"
+ "shr $32, %%rdx\n\t"
+ "wrmsr",
+ /* wrfsbase rax */
+ ".byte 0xf3, 0x48, 0x0f, 0xae, 0xd0",
+ X86_FEATURE_FSGSBASE,
+ [val] "a" (base), [msr] "i" (MSR_FS_BASE) : "rcx",
"rdx");
}
static inline void wrgsbase(unsigned long base)
{
-if ( cpu_has_fsgsbase )
-#ifdef HAVE_AS_FSGSBASE
-asm volatile ( "wrgsbase %0" :: "r" (base) );
-#else
-asm volatile ( ".byte 0xf3, 0x48, 0x0f, 0xae, 0xd8" :: "a" (base) );
-#endif
-else
-wrmsrl(MSR_GS_BASE, base);
+alternative_input("mov %[msr], %%ecx\n\t"
+ "mov %[val], %%rdx\n\t"
+ "shr $32, %%rdx\n\t"
+ "wrmsr",
+ /* wrgsbase rax */
+ ".byte 0xf3, 0x48, 0x0f, 0xae, 0xd8",
+ X86_FEATURE_FSGSBASE,
+ [val] "a" (base), [msr] "i" (MSR_GS_BASE) : "rcx",
"rdx");
}
static inline void wrgsshadow(unsigned long base)
{
-if ( cpu_has_fsgsbase )
-{
-asm volatile ( "swapgs\n\t"
-#ifdef HAVE_AS_FSGSBASE
- "wrgsbase %0\n\t"
- "swapgs"
- :: "r" (base) );
-#else
- ".byte 0xf3, 0x48, 0x0f, 0xae, 0xd8\n\t"
- "swapgs"
- :: "a" (base) );
-#endif
-}
-else
-wrmsrl(MSR_SHADOW_GS_BASE, base);
+alternative_input("mov %[msr], %%ecx\n\t"
+ "mov %[val], %%rdx\n\t"
+ "shr $32, %%rdx\n\t"
+ "wrmsr",
+ /* Wrapping WRGSBASE in a pair of SWAPGS. */
+ "swapgs\n\t"
+ ".byte 0xf3, 0x48, 0x0f, 0xae, 0xd8\n\t" /* wrgsbase rax
*/
+ "swapgs",
+ X86_FEATURE_FSGSBASE,
+ [val] "a" (base),
+ [msr] "i" (MSR_SHADOW_GS_BASE) : "rcx", "rdx");
}
DECLARE_PER_CPU(uint64_t, efer);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/12] x86: infrastructure to allow converting certain indirect calls to direct ones
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. */
> if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
> -*(int32_t *)(buf + 1) += repl - orig;
> +{
> +/*
> + * Detect the special case of indirect-to-direct branch patching:
> + * - replacement is a direct CALL/JMP (opcodes 0xE8/0xE9; already
> + * checked above),
> + * - replacement's displacement is -5 (pointing back at the very
> + * insn, which makes no sense in a real replacement insn),
> + * - original is an indirect CALL/JMP (opcodes 0xFF/2 or 0xFF/4)
> + * using RIP-relative addressing.
> + * Some function targets may not be available when we come here
> + * the first time. Defer patching of those until the post-presmp-
> + * initcalls re-invocation.
Which calls? That smells like a bug which should be fixed rather than
worked around. As for the other complexity here...
> If at that point the target pointer is
> + * still NULL, insert "UD2; UD0" (for ease of recognition)
> instead
> + * of CALL/JMP.
> + */
> +if ( a->cpuid == X86_FEATURE_ALWAYS &&
> + *(int32_t *)(buf + 1) == -5 &&
> + a->orig_len >= 6 &&
> + orig[0] == 0xff &&
> + orig[1] == (*buf & 1 ? 0x25 : 0x15) )
> +{
> +long disp = *(int32_t *)(orig + 2);
> +const uint8_t *dest = *(void **)(orig + 6 + disp);
> +
> +if ( dest )
> +{
> +disp = dest - (orig + 5);
> +ASSERT(disp == (int32_t)disp);
> +*(int32_t *)(buf + 1) = disp;
> +}
> +else if ( force )
> +{
> +buf[0] = 0x0f;
> +buf[1] = 0x0b;
> +buf[2] = 0x0f;
> +buf[3] = 0xff;
> +buf[4] = 0xff;
> +}
> +else
> +continue;
> +}
> +else if ( force && system_state < SYS_STATE_active )
> +ASSERT_UNREACHABLE();
> +else
> +*(int32_t *)(buf + 1) += repl - orig;
> +}
> +else if ( force && system_state < SYS_STATE_active )
> +ASSERT_UNREACHABLE();
> /* RIP-relative addressing is easy to check for in VEX-encoded
> insns. */
> else if ( a->repl_len >= 8 &&
>(*buf & ~1) == 0xc4 &&
> @@ -149,6 +150,203 @@ extern void alternative_instructions(voi
> /* Use this macro(s) if you need more than one output parameter. */
> #define ASM_OUTPUT2(a...) a
>
> +/*
> + * Machinery to allow converting indirect to direct calls, when the called
> + * function is determined once at boot and later never changed.
> + */
> +
> +#define ALT_CALL_arg1 "rdi"
> +#define ALT_CALL_arg2 "rsi"
> +#define ALT_CALL_arg3 "rdx"
> +#define ALT_CALL_arg4 "rcx"
> +#define ALT_CALL_arg5 "r8"
> +#define ALT_CALL_arg6 "r9"
> +
> +#define ALT_CALL_ARG(arg, n) \
> +register typeof((arg) ? (arg) : 0) a ## n ## _ \
> +asm ( ALT_CALL_arg ## n ) = (arg)
> +#define ALT_CALL_NO_ARG(n) \
> +register unsigned long a ## n ## _ asm ( ALT_CALL_arg ## n )
> +
> +#define ALT_CALL_NO_ARG6 ALT_CALL_NO_ARG(6)
> +#define ALT_CALL_NO_ARG5 ALT_CALL_NO_ARG(5); ALT_CALL_NO_ARG6
> +#define ALT_CALL_NO_ARG4 ALT_CALL_NO_ARG(4); ALT_CALL_NO_ARG5
> +#define ALT_CALL_NO_ARG3 ALT_CALL_NO_ARG(3); ALT_CALL_NO_ARG4
> +#define ALT_CALL_NO_ARG2 ALT_CALL_NO_ARG(2); ALT_CALL_NO_ARG3
> +#define ALT_CALL_NO_ARG1 ALT_CALL_NO_ARG(1); ALT_CALL_NO_ARG2
> +
> +/*
> + * Unfortunately ALT_CALL_NO_ARG() above can't use a fake initializer (to
> + * suppress "uninitialized variable" warnings), as various versions of gcc
> + * older than 8.1 fall on the nose in various ways with that (always because
> + * of some other construct elsewhere in the same function needing to use the
> + * same hard register). Otherwise the asm() below could uniformly use "+r"
> + * output constraints, making unnecessary all these ALT_CALL_OUT macros.
> + */
> +#define ALT_CALL0_OUT "=r" (a1_), "=r" (a2_), "=r" (a3_), \
> + "=r" (a4_), "=r" (a5_), "=r" (a6_)
> +#define ALT_CALL1_OUT "+r" (a1_), "=r" (a2_), "=r" (a3_), \
> + "=r" (a4_), "=r" (a5_), "=r" (a6_)
> +#define ALT_CALL2_OUT "+r" (a1_), "+r" (a2_), "=r" (a3_), \
> + "=r" (a4_), "=r" (a5_), "=r" (a6_)
> +#define ALT_CALL3_OUT "+r" (a1_), "+r" (a2_), "+r" (a3_), \
> + "=r" (a4_), "=r" (a5_), "=r" (a6_)
> +#define ALT_CALL4_OUT "+r" (a1_),
Re: [Xen-devel] [PATCH 2/7] x86/pv: Rename v->arch.pv_vcpu to v->arch.pv
>>> 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_callback_eip= reg->address;
Would you mind dropping the stray extra blanks? Also further down
in this same file.
In any event
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/7] x86/pv: Rename d->arch.pv_domain to d->arch.pv
>>> 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 Beulich I've long wanted to do this, but didn't dare to with the discussions we had during PVHv1 development, where some suggestions of mine to shorten names like this weren't really liked. So - thanks! Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 07/12] x86/genapic: drop .target_cpus() hook
On 29/08/18 15:06, Jan Beulich wrote: > All flavors specify target_cpus_all() anyway - replace use of the hook > by _online_map. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 126854: tolerable FAIL - PUSHED
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 saverestore-support-checkfail like 126683 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 126683 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 126683 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 126683 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 126683 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 126683 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 126683 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 126683 build-amd64-xen-xsm-freebsd 7 xen-build-freebsdfail never pass build-amd64-xen-freebsd 7 xen-build-freebsdfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 36e29dd9e580cb0f847f5ac1e72afdb5febe3e99 baseline version: xen a923919797c39d51ea0b808ea691bed20fe8e072 Last test of basis 126683 2018-08-26 06:47:14 Z3 days Failing since126778 2018-08-27 13:52:39 Z2 days2 attempts Testing same since 126854 2018-08-28 12:14:33 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Doug Goldstein Ian Jackson Jan Beulich Kevin Tian Paul Durrant Razvan Cojocaru Wei Liu Zhenzhong Duan jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-amd64-xen-freebsd fail build-amd64-xen-xsm-freebsd fail build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev
[Xen-devel] [ovmf baseline-only test] 75136: tolerable FAIL
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-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75132 version targeted for testing: ovmf f965b772fcc4bdc5f207998126d93d80c085d5f5 baseline version: ovmf 033949a810cd9cb4a604cf09af503459ea1d66dc Last test of basis75132 2018-08-27 23:55:19 Z1 days Testing same since75136 2018-08-28 17:21:28 Z0 days1 attempts People who touched revisions under test: Eric Dong Star Zeng jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit f965b772fcc4bdc5f207998126d93d80c085d5f5 Author: Eric Dong Date: Tue Aug 21 14:44:41 2018 +0800 MdeModulePkg/PiSmmCore: Check valid memory range. Call BS.AllocatePages in DXE driver and call SMM FreePages with the address of the buffer allocated in the DXE driver. SMM FreePages success and add a non-SMRAM range into SMM heap list. This is not an expected behavior. SMM FreePages should return error for this case and not free the pages. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1098 Change-Id: Ie5ffa1ac62c558aa418a8a3d7d0e8158b846e13b Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong Reviewed-by: Star Zeng commit 17da1b91089d1da8a0b9fbbb8d29e4586fa13e46 Author: Star Zeng Date: Fri Jul 13 10:29:24 2018 +0800 MdeModulePkg: Update SMBIOS PCDs to 3.2.0 REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1099 Cc: Liming Gao Cc: Dandan Bi Cc: Michael D Kinney Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Dandan Bi commit cfcca3c2de361bddeacef57183ab970ab35cc49e Author: Star Zeng Date: Fri Jul 13 10:28:34 2018 +0800 MdePkg SmBios.h: Add SMBIOS 3.2.0 definitions REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1099 Add SMBIOS 3.2.0 definitions according to www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf. Processor Information (Type 4): - SMBIOSCR00163: add socket LGA2066 - SMBIOSCR00173: add Intel Core i9 - SMBIOSCR00176: add new processor sockets Port Connector Information (Type 8): - SMBIOSCR00168: add USB Type-C System Slots (Type 9): - SMBIOSCR00164: add "unavailable" to current usage field - SMBIOSCR00167: add support for PCIe bifurcation Memory Device (Type 17): - SMBIOSCR00162: add support for NVDIMMs - SMBIOSCR00166: extend support for NVDIMMs and add support for logical memory type - SMBIOSCR00172: rename "Configured Memory Clock Speed" to "Configured Memory Speed" - SMBIOSCR00174: add new memory technology value (Intel Persistent Memory, 3D XPoint) IPMI Device Information (Type 38): - SMBIOSCR00171: add SSIF Management Controller Host Interface (Type 42) - SMBIOSCR00175: fix structure data parsing issue V2: Add missing update to MISC_PORT_TYPE and SMBIOS_TABLE_TYPE9. Cc: Liming Gao Cc: Dandan Bi Cc: Michael D Kinney Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Dandan Bi Reviewed-by: Liming Gao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 00/12] x86: indirect call overhead reduction
>>> 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 exists to abstract from e.g.
> vendor specific hardware details, and hence the pointers used never
> change once set. Here we can use alternatives patching to get rid of
> the indirection.
>
> From patch 2 onwards dependencies exist on earlier, yet to be reviewed
Oh, this was definitely meant to be "From patch 3 onwards ...".
Jan
> patches ("x86/alternatives: fully leverage automatic NOP filling" as well
> as the "x86: improve PDX <-> PFN and alike translations" series at the
> very least). I nevertheless wanted to enable a first round of review of
> the series, the more that some of the patches (not just initial ones)
> could perhaps be taken irrespective of those dependencies. The first
> two of the three genapic patches, otoh, are entirely independent and
> could go in right away afaict if they were ack-ed.
>
> Further areas where indirect calls could be eliminated (and that I've put
> on my todo list in case the general concept here is deemed reasonable)
> are IOMMU, vPMU, and XSM. For some of these, the ARM side would
> need dealing with as well - I'm not sure whether replacing indirect calls
> by direct ones is worthwhile there as well; if not, the wrappers would
> simply need to become function invocations in the ARM case (as was
> already asked for in the IOMMU case).
>
> 01: VMX: reduce number of posted-interrupt hooks
> 02: x86/alternatives: allow using assembler macros in favor of C ones
> 03: x86: infrastructure to allow converting certain indirect calls to direct
> ones
> 04: x86/HVM: patch indirect calls through hvm_funcs to direct ones
> 05: x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones
> 06: x86: patch ctxt_switch_masking() indirect call to direct one
> 07: x86/genapic: drop .target_cpus() hook
> 08: x86/genapic: remove indirection from genapic hook accesses
> 09: x86/genapic: patch indirect calls to direct ones
> 10: x86/cpuidle: patch some indirect calls to direct ones
> 11: cpufreq: convert to a single post-init driver (hooks) instance
> 12: cpufreq: patch target() indirect call to direct one
>
> Jan
>
>
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
>>> 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 correctly configured before evtchn_init(), the poll mask > can be constructed suitably for the domain, rather than for the worst-case > setting. > > Due to the evtchn_init() fixes, it no longer calls domain_max_vcpus(), and > ARM's two implementations of vgic_max_vcpus() no longer need work around the > out-of-order call. > > From this point on, d->max_vcpus and d->vcpus[] are valid for any domain which > can be looked up by domid. > > The XEN_DOMCTL_max_vcpus hypercall is modified to reject any call attempt with > max != d->max_vcpus, which does match the older semantics (not that it is > obvious from the code). The logic to allocate d->vcpu[] is dropped, but at > this point the hypercall still needs making to allocate each vcpu. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich in principle, but as said before the lack of renaming of the domctl makes my ack dependent upon some other REST maintainer agreeing with your position there (the more that you've added the comment to the implementation rather than the public header). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: re-arrange get_page_from_le() vs pv_l1tf_check_le
>>> 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 you are referring to. >> Just look at the current state: get_page_from_l[234]e() call >> pv_l1tf_check_l[234]e(), but get_page_from_l1e() in the >> same situation. Instead alloc_l1_table() does. > > I'm afraid that I can't even parse this, but I think I've got the point. > > IMO, it would be clearer for the commit message to read "is now now > uniformly invoked". Oh, yes, the "now" should have been there. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 01/12] VMX: reduce number of posted-interrupt hooks
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 one, as it's always > (de-)activated together the the vCPU blocking hook, which needs to > remain an actual function pointer). This is the more that with the > Spectre v2 workarounds indirect calls have become more expensive. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 02/12] x86/alternatives: allow using assembler macros in favor of C ones
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 mislead into believing
> an asm() to be more heavy weight than it really is. By presenting it
> with an assembler macro invocation instead, this can be avoided.
>
> Initially I wanted to outright change the C macros ALTERNATIVE() and
> ALTERNATIVE_2() to invoke the respective assembler ones, but doing so
> would require quite a bit of cleanup of some use sites, because of the
> exra necessary quoting combined with the need that each assembler macro
> argument must consist of just a single string literal. We can consider
> working towards that subsequently.
>
> For now, set the stage of using the assembler macros here by providing a
> new generated header, being the slightly massaged pre-processor output
> of (for now just) alternative-asm.h. The massaging is primarily to be
> able to properly track the build dependency: For this, we need the C
> compiler to see the inclusion, which means we shouldn't directly use an
> asm(". include ...") directive.
>
> The dependency added to asm-offsets.s is not a true one; it's just the
> easiest approach I could think of to make sure the new header gets
> generated early on, without having to fiddle with xen/Makefile (and
> introducing some x86-specific construct there).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/12] x86: infrastructure to allow converting certain indirect calls to direct ones
>>> 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 the same issue Stefano recently discovered on
> the SMCCC.
>
> Using explicit register variable will not reserve the register. So if
> arg* is a function call, the register you have just assigned will get
> clobbered (see [1]).
>
> The solution to this is evaluating all the arguments before declaring
> the variable with explicit registers. See the patch [2] for an example.
Oh, I see - I should have made the connection when reading through
that part of the gcc doc the other day. The current construct is safe
for all current uses, but I agree I'd better follow the model you point
out.
>> --- a/xen/include/xen/lib.h
>> +++ b/xen/include/xen/lib.h
>> @@ -66,6 +66,10 @@
>>
>> #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
>>
>> +#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x
>> +#define count_va_arg(args...) \
>> +count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0)
>
> We have a similar function in SMCCC where only the arguments except the
> first one (Function ID) and last one (Result pointer). I believe
> different context will require different way to count argument in order
> to keep the code readable.
>
> So I am not entirely sure if there are a benefit to have this function
> in common.
From an initial look it seemed to me that the SMCCC code could be
converted to use the macros here. In any event, other than the
macros used there the ones here are generic in that they simply
could arguments, without and special treatment of any of them.
Hence the generic name and placement.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: re-arrange get_page_from_le() vs pv_l1tf_check_le
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 current state: get_page_from_l[234]e() call > pv_l1tf_check_l[234]e(), but get_page_from_l1e() in the > same situation. Instead alloc_l1_table() does. I'm afraid that I can't even parse this, but I think I've got the point. IMO, it would be clearer for the commit message to read "is now now uniformly invoked". > >>> 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 rid of. >>> >>> Introduce local variables holding the page table entries processed, and >>> use them throughout the loop bodies instead of re-reading them from the >>> page table several times. >>> >>> Signed-off-by: Jan Beulich >> With at least the above query resolved, Reviewed-by: Andrew Cooper >> , but a style recommendation. > Thanks, but please let me know if the above clarifies this. > >>> @@ -1396,8 +1369,7 @@ static int alloc_l1_table(struct page_in >>> if ( ret ) >>> goto out; >>> } >>> - >>> -switch ( ret = get_page_from_l1e(pl1e[i], d, d) ) >>> +else switch ( ret = get_page_from_l1e(pl1e[i], d, d) ) >> else switch isn't a usual construct (here and in ptwr_emulated_update). >> I was expecting the misleading indentation warning to trigger, but GCC >> 8.2 does appear to be happy. > Presumably because then it would also trigger for "else if". The difference is that "else if" is a very common idiom. > >> Still, for code clarity, I'd suggest adding braces to the and indenting >> the switch statement. > At first I meant to do so, then decided against because of the extra > code churn in both places where I've chosen this approach (also > making looking at the patch itself less difficult). Would you be okay > with the re-indentation done in a separate follow-up patch? Yeah - thats fine. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
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 mask
can be constructed suitably for the domain, rather than for the worst-case
setting.
Due to the evtchn_init() fixes, it no longer calls domain_max_vcpus(), and
ARM's two implementations of vgic_max_vcpus() no longer need work around the
out-of-order call.
From this point on, d->max_vcpus and d->vcpus[] are valid for any domain which
can be looked up by domid.
The XEN_DOMCTL_max_vcpus hypercall is modified to reject any call attempt with
max != d->max_vcpus, which does match the older semantics (not that it is
obvious from the code). The logic to allocate d->vcpu[] is dropped, but at
this point the hypercall still needs making to allocate each vcpu.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: George Dunlap
CC: Konrad Rzeszutek Wilk
CC: Tim Deegan
CC: Wei Liu
v2:
* Allocate in domain_create() rather than arch_domain_create().
* Retain domain_max_vcpus().
v3:
* Only drop the GIC_INVALID case in vgic_max_vcpus().
* Leave a note concerning the new behaviour of XEN_DOMCTL_max_vcpus in the
interim before it gets deleted.
---
xen/arch/arm/domain_build.c | 8 +---
xen/arch/arm/setup.c| 2 +-
xen/arch/arm/vgic.c | 11 +--
xen/arch/arm/vgic/vgic.c| 9 -
xen/arch/x86/dom0_build.c | 8 +---
xen/arch/x86/setup.c| 2 +-
xen/common/domain.c | 18 ++
xen/common/domctl.c | 46 -
xen/common/event_channel.c | 3 +--
xen/include/xen/domain.h| 2 +-
10 files changed, 33 insertions(+), 76 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6900a93..9ceb33d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -72,14 +72,8 @@ unsigned int __init dom0_max_vcpus(void)
return opt_dom0_max_vcpus;
}
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0,
- unsigned int max_vcpus)
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
{
-dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
-if ( !dom0->vcpu )
-return NULL;
-dom0->max_vcpus = max_vcpus;
-
return alloc_vcpu(dom0, 0, 0);
}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 048d5f3..01b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -854,7 +854,7 @@ void __init start_xen(unsigned long boot_phys_offset,
dom0_cfg.max_vcpus = dom0_max_vcpus();
dom0 = domain_create(0, _cfg, true);
-if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0, dom0_cfg.max_vcpus) == NULL) )
+if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
panic("Error creating domain 0");
if ( construct_dom0(dom0) != 0)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 7a2c455..5a4f082 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -669,16 +669,7 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
unsigned int vgic_max_vcpus(const struct domain *d)
{
-/*
- * Since evtchn_init would call domain_max_vcpus for poll_mask
- * allocation when the vgic_ops haven't been initialised yet,
- * we return MAX_VIRT_CPUS if d->arch.vgic.handler is null.
- */
-if ( !d->arch.vgic.handler )
-return MAX_VIRT_CPUS;
-else
-return min_t(unsigned int, MAX_VIRT_CPUS,
- d->arch.vgic.handler->max_vcpus);
+return min_t(unsigned int, MAX_VIRT_CPUS, d->arch.vgic.handler->max_vcpus);
}
/*
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 832632a..3272952 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -955,15 +955,6 @@ unsigned int vgic_max_vcpus(const struct domain *d)
switch ( d->arch.vgic.version )
{
-case GIC_INVALID:
-/*
- * Since evtchn_init would call domain_max_vcpus for poll_mask
- * allocation before the VGIC has been initialised, we need to
- * return some safe value in this case. As this is for allocation
- * purposes, go with the maximum value.
- */
-vgic_vcpu_limit = MAX_VIRT_CPUS;
-break;
case GIC_V2:
vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
break;
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index b42eac3..423fdec 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -199,17 +199,11 @@ unsigned int __init dom0_max_vcpus(void)
return max_vcpus;
}
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0,
- unsigned int max_vcpus)
+struct vcpu *__init alloc_dom0_vcpu0(struct domain
Re: [Xen-devel] [PATCH RFC] x86/HVM: meet xentrace's expectations on emulation event data
>>> 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 the
>> consumer side, the more that it is anyway not very helpful for the code
>> here to only ever supply 32 bits of data (despite the field being 64
>> bits wide, and having been even in the 32-bit days of Xen).
>>
>> Signed-off-by: Jan Beulich
>> ---
>> RFC: Untested; solely based on the observation of "(no data)" in a trace
>> where it was entirely unclear why no data would have been available.
>> I just so happened that the guest had more than 4Gb of memory, and
>> hence addresses were not representable as 32-bit values.
>
> Unfortunately, I don't think this helps much.
>
> From what I can tell, xentrace_format doesn't understand the TRC_64_FLAG
> versions of these events at all, and xenalyze uses:
>
> union {
> struct {
> unsigned int gpa;
> unsigned int data;
> } x32;
> struct {
> unsigned long long gpa;
> unsigned int data;
> } x64;
> } *r = (typeof(r))h->d;
>
> to pull the data back out. AFAICT, this matches what Xen is currently
> writing, and is equally wrong.
Are you sure? You've not quoted the relevant other half:
union {
unsigned event;
struct {
unsigned minor:8,
x64:1,
write:2;
};
} mevt = { .event = ri->event };
with the check then being
if(mevt.x64) {
If what consumer and producer matched in (good or bad) behavior,
I'd expect "(no data)" to not appear here, but it was definitely
observed (on an older Xen version) by Olaf.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/12] x86: infrastructure to allow converting certain indirect calls to direct ones
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 discovered on
the SMCCC.
Using explicit register variable will not reserve the register. So if
arg* is a function call, the register you have just assigned will get
clobbered (see [1]).
The solution to this is evaluating all the arguments before declaring
the variable with explicit registers. See the patch [2] for an example.
+ALT_CALL_NO_ARG3; \
+(void)sizeof(func(arg1, arg2)); \
+(void)alternative_callN(2, int, func);\
+})
[...]
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -66,6 +66,10 @@
#define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
+#define count_va_arg_(dot, a1, a2, a3, a4, a5, a6, a7, a8, x, ...) x > +#define count_va_arg(args...) \
+count_va_arg_(., ## args, 8, 7, 6, 5, 4, 3, 2, 1, 0)
We have a similar function in SMCCC where only the arguments except the
first one (Function ID) and last one (Result pointer). I believe
different context will require different way to count argument in order
to keep the code readable.
So I am not entirely sure if there are a benefit to have this function
in common.
Cheers,
[1]
https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html#Local-Register-Variables
[2] https://lists.xen.org/archives/html/xen-devel/2018-08/msg02139.html
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 126861: tolerable FAIL - PUSHED
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 saverestore-support-checkfail like 126780 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 126780 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 126780 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 126780 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuu19b599f7664b2ebfd0f405fb79c14dd241557452 baseline version: qemuu025573be71dab8d7885b787a6ca52d6d9bbfd75c Last test of basis 126780 2018-08-27 14:07:00 Z2 days Testing same since 126861 2018-08-28 13:50:16 Z1 days1 attempts People who touched revisions under test: Juan Quintela Markus Armbruster Peter Maydell Peter Xu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amdfail
[Xen-devel] [PATCH v2 6/6] x86emul: generalize vector length handling for AVX512/EVEX
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 be done in a central place like this).
Note that the broadcast case is not handled here, but will be taken care
of elsewhere (in just a single place rather than at least two).
Signed-off-by: Jan Beulich
---
v2: Don't raise #UD in simd_scalar_opc case when EVEX.W != low-opcode-bit.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -191,14 +191,14 @@ enum simd_opsize {
* Ordinary packed integers:
* - 64 bits without prefix 66 (MMX)
* - 128 bits with prefix 66 (SSEn)
- * - 128/256 bits depending on VEX.L (AVX)
+ * - 128/256/512 bits depending on VEX.L/EVEX.LR (AVX+)
*/
simd_packed_int,
/*
* Ordinary packed/scalar floating point:
* - 128 bits without prefix or with prefix 66 (SSEn)
- * - 128/256 bits depending on VEX.L (AVX)
+ * - 128/256/512 bits depending on VEX.L/EVEX.LR (AVX+)
* - 32 bits with prefix F3 (scalar single)
* - 64 bits with prefix F2 (scalar doubgle)
*/
@@ -207,14 +207,14 @@ enum simd_opsize {
/*
* Packed floating point:
* - 128 bits without prefix or with prefix 66 (SSEn)
- * - 128/256 bits depending on VEX.L (AVX)
+ * - 128/256/512 bits depending on VEX.L/EVEX.LR (AVX+)
*/
simd_packed_fp,
/*
* Single precision packed/scalar floating point:
* - 128 bits without prefix (SSEn)
- * - 128/256 bits depending on VEX.L, no prefix (AVX)
+ * - 128/256/512 bits depending on VEX.L/EVEX.LR (AVX+)
* - 32 bits with prefix F3 (scalar)
*/
simd_single_fp,
@@ -228,7 +228,7 @@ enum simd_opsize {
/*
* Scalar floating point:
- * - 32/64 bits depending on VEX.W
+ * - 32/64 bits depending on VEX.W/EVEX.W
*/
simd_scalar_vexw,
@@ -2818,6 +2818,9 @@ x86_decode(
opcode |= b | MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
+if ( !evex.mbs )
+evex.lr = vex.l;
+
if ( !(d & ModRM) )
break;
@@ -3148,7 +3151,7 @@ x86_decode(
}
/* fall through */
case vex_66:
-op_bytes = 16 << vex.l;
+op_bytes = 16 << evex.lr;
break;
default:
op_bytes = 0;
@@ -3172,9 +3175,17 @@ x86_decode(
case simd_any_fp:
switch ( vex.pfx )
{
-default: op_bytes = 16 << vex.l; break;
-case vex_f3: op_bytes = 4; break;
-case vex_f2: op_bytes = 8; break;
+default:
+op_bytes = 16 << evex.lr;
+break;
+case vex_f3:
+generate_exception_if(evex.mbs && evex.w, EXC_UD);
+op_bytes = 4;
+break;
+case vex_f2:
+generate_exception_if(evex.mbs && !evex.w, EXC_UD);
+op_bytes = 8;
+break;
}
break;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 5/6] x86emul: correct EVEX decoding
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 required to be 0b in that case, EVEX.V'
is required to be 1 there.
Also rename the bcst field to br, as #UD generation for individual insns
will need to consider both of its possible meanings.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -650,7 +650,7 @@ union evex {
uint8_t w:1;
uint8_t opmsk:3;
uint8_t RX:1;
-uint8_t bcst:1;
+uint8_t br:1;
uint8_t lr:2;
uint8_t z:1;
};
@@ -2760,13 +2760,11 @@ x86_decode(
evex.raw[1] = vex.raw[1];
evex.raw[2] = insn_fetch_type(uint8_t);
-generate_exception_if(evex.mbs || !evex.mbz, EXC_UD);
+generate_exception_if(!evex.mbs || evex.mbz, EXC_UD);
+generate_exception_if(!evex.opmsk && evex.z, EXC_UD);
if ( !mode_64bit() )
-{
-generate_exception_if(!evex.RX, EXC_UD);
evex.R = 1;
-}
vex.opcx = evex.opcx;
break;
@@ -3404,6 +3402,7 @@ x86_emulate(
d = (d & ~DstMask) | DstMem;
/* Becomes a normal DstMem operation from here on. */
case DstMem:
+generate_exception_if(ea.type == OP_MEM && evex.z, EXC_UD);
if ( state->simd_size )
{
generate_exception_if(lock_prefix, EXC_UD);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 4/6] x86emul: clean up AVX2 insn use in test harness
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/tests/x86_emulator/test_x86_emulator.c
@@ -2071,11 +2071,6 @@ int main(int argc, char **argv)
rc = x86_emulate(, );
if ( rc != X86EMUL_OKAY || !check_eip(vmovdqu_from_mem) )
goto fail;
-#if 0 /* Don't use AVX2 instructions for now */
-asm ( "vpcmpeqb %%ymm2, %%ymm2, %%ymm2\n\t"
- "vpcmpeqb %%ymm4, %%ymm2, %%ymm0\n\t"
- "vpmovmskb %%ymm0, %0" : "=r" (rc) );
-#else
asm ( "vextractf128 $1, %%ymm4, %%xmm3\n\t"
"vpcmpeqb %%xmm2, %%xmm2, %%xmm2\n\t"
"vpcmpeqb %%xmm4, %%xmm2, %%xmm0\n\t"
@@ -2083,7 +2078,6 @@ int main(int argc, char **argv)
"vpmovmskb %%xmm0, %0\n\t"
"vpmovmskb %%xmm1, %1" : "=r" (rc), "=r" (i) );
rc |= i << 16;
-#endif
if ( rc != 0x )
goto fail;
printf("okay\n");
@@ -2755,11 +2749,6 @@ int main(int argc, char **argv)
rc = x86_emulate(, );
if ( rc != X86EMUL_OKAY || !check_eip(vlddqu) )
goto fail;
-#if 0 /* Don't use AVX2 instructions for now */
-asm ( "vpcmpeqb %%ymm2, %%ymm2, %%ymm2\n\t"
- "vpcmpeqb %%ymm4, %%ymm2, %%ymm0\n\t"
- "vpmovmskb %%ymm0, %0" : "=r" (rc) );
-#else
asm ( "vextractf128 $1, %%ymm4, %%xmm3\n\t"
"vpcmpeqb %%xmm2, %%xmm2, %%xmm2\n\t"
"vpcmpeqb %%xmm4, %%xmm2, %%xmm0\n\t"
@@ -2767,7 +2756,6 @@ int main(int argc, char **argv)
"vpmovmskb %%xmm0, %0\n\t"
"vpmovmskb %%xmm1, %1" : "=r" (rc), "=r" (i) );
rc |= i << 16;
-#endif
if ( ~rc )
goto fail;
printf("okay\n");
@@ -2806,15 +2794,9 @@ int main(int argc, char **argv)
{
decl_insn(vmovntdqa);
-#if 0 /* Don't use AVX2 instructions for now */
asm volatile ( "vpxor %%ymm4, %%ymm4, %%ymm4\n"
put_insn(vmovntdqa, "vmovntdqa (%0), %%ymm4")
:: "c" (NULL) );
-#else
-asm volatile ( "vpxor %xmm4, %xmm4, %xmm4\n"
- put_insn(vmovntdqa,
-".byte 0xc4, 0xe2, 0x7d, 0x2a, 0x21") );
-#endif
set_insn(vmovntdqa);
memset(res, 0x55, 96);
@@ -2823,19 +2805,9 @@ int main(int argc, char **argv)
rc = x86_emulate(, );
if ( rc != X86EMUL_OKAY || !check_eip(vmovntdqa) )
goto fail;
-#if 0 /* Don't use AVX2 instructions for now */
asm ( "vpcmpeqb %%ymm2, %%ymm2, %%ymm2\n\t"
"vpcmpeqb %%ymm4, %%ymm2, %%ymm0\n\t"
"vpmovmskb %%ymm0, %0" : "=r" (rc) );
-#else
-asm ( "vextractf128 $1, %%ymm4, %%xmm3\n\t"
- "vpcmpeqb %%xmm2, %%xmm2, %%xmm2\n\t"
- "vpcmpeqb %%xmm4, %%xmm2, %%xmm0\n\t"
- "vpcmpeqb %%xmm3, %%xmm2, %%xmm1\n\t"
- "vpmovmskb %%xmm0, %0\n\t"
- "vpmovmskb %%xmm1, %1" : "=r" (rc), "=r" (i) );
-rc |= i << 16;
-#endif
if ( ~rc )
goto fail;
printf("okay\n");
@@ -3161,12 +3133,7 @@ int main(int argc, char **argv)
asm volatile ( "vpxor %%xmm1, %%xmm1, %%xmm1\n\t"
"vpinsrd $0b00, %1, %%xmm1, %%xmm2\n\t"
-#if 0 /* Don't use AVX2 instructions for now */
put_insn(vpmaskmovd, "vpmaskmovd %%xmm1, %%xmm2, (%0)")
-#else
- put_insn(vpmaskmovd,
-".byte 0xc4, 0xe2, 0x69, 0x8e, 0x0a")
-#endif
:: "d" (NULL), "r" (~0) );
memset(res + MMAP_SZ / sizeof(*res) - 8, 0xdb, 32);
@@ -3200,14 +3167,8 @@ int main(int argc, char **argv)
asm volatile ( "vpxor %%xmm1, %%xmm1, %%xmm1\n\t"
"vpcmpeqd %%xmm0, %%xmm0, %%xmm0\n\t"
-#if 0 /* Don't use AVX2 instructions for now */
"vpblendd $0b0011, %%xmm0, %%xmm1, %%xmm2\n\t"
put_insn(vpmaskmovq, "vpmaskmovq %%xmm1, %%xmm2, (%0)")
-#else
- ".byte 0xc4, 0xe3, 0x71, 0x02, 0xd0, 0b0011\n\t"
- put_insn(vpmaskmovq,
-".byte 0xc4, 0xe2, 0xe9, 0x8e, 0x0a")
-#endif
:: "d" (NULL) );
memset(res + MMAP_SZ / sizeof(*res) - 8, 0xdb, 32);
@@ -3221,11 +3182,7 @@ int main(int argc, char **argv)
res + MMAP_SZ / sizeof(*res) - 4, 8) )
goto fail;
-#if 0 /* Don't use AVX2 instructions for now */
asm volatile ( "vpermq $0b0001, %ymm2, %ymm2" );
-#else
-asm volatile ( ".byte 0xc4, 0xe3, 0xfd, 0x00, 0xd2, 0b0001" );
-#endif
memset(res, 0xdb, 32);
set_insn(vpmaskmovq);
regs.edx
[Xen-devel] [PATCH v2 3/6] x86emul: support AVX512 opmask insns
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 has
no underlying type (yet) that could be operated on without builtins,
other than the vector types used for "normal" SIMD insns.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -16,6 +16,8 @@ FMA := fma4 fma
SG := avx2-sg
TESTCASES := blowfish $(SIMD) $(FMA) $(SG)
+OPMASK := avx512f avx512dq avx512bw
+
blowfish-cflags := ""
blowfish-cflags-x86_32 := "-mno-accumulate-outgoing-args -Dstatic="
@@ -51,6 +53,10 @@ xop-vecs := $(avx-vecs)
xop-ints := 1 2 4 8
xop-flts := $(avx-flts)
+avx512f-opmask-vecs := 2
+avx512dq-opmask-vecs := 1
+avx512bw-opmask-vecs := 4 8
+
# For AVX and later, have the compiler avoid XMM0 to widen coverage of
# the VEX. checks in the emulator. For 3DNow!, however, force SSE
# use for floating point operations, to avoid mixing MMX and FPU register
@@ -80,9 +86,13 @@ $(1)-cflags := \
$(foreach flt,$($(1)-flts), \
"-D_$(vec)x$(idx)f$(flt) -m$(1:-sg=) $(call non-sse,$(1)) -Os
-DVEC_MAX=$(vec) -DIDX_SIZE=$(idx) -DFLOAT_SIZE=$(flt)")))
endef
+define opmask-defs
+$(1)-opmask-cflags := $(foreach vec,$($(1)-opmask-vecs), "-D_$(vec) -m$(1) -Os
-DSIZE=$(vec)")
+endef
$(foreach flavor,$(SIMD) $(FMA),$(eval $(call simd-defs,$(flavor
$(foreach flavor,$(SG),$(eval $(call simd-sg-defs,$(flavor
+$(foreach flavor,$(OPMASK),$(eval $(call opmask-defs,$(flavor
$(addsuffix .h,$(TESTCASES)): %.h: %.c testcase.mk Makefile
rm -f $@.new $*.bin
@@ -100,6 +110,22 @@ $(addsuffix .h,$(TESTCASES)): %.h: %.c t
)
mv $@.new $@
+$(addsuffix -opmask.h,$(OPMASK)): %.h: opmask.S testcase.mk Makefile
+ rm -f $@.new $*.bin
+ $(foreach arch,$(filter-out $(XEN_COMPILE_ARCH),x86_32)
$(XEN_COMPILE_ARCH), \
+ for cflags in $($*-cflags) $($*-cflags-$(arch)); do \
+ $(MAKE) -f testcase.mk TESTCASE=$* XEN_TARGET_ARCH=$(arch)
$*-cflags="$$cflags" all; \
+ prefix=$(shell echo $(subst -,_,$*) | sed -e
's,^\([0-9]\),_\1,'); \
+ flavor=$$(echo $${cflags} | sed -e 's, .*,,' -e 'y,-=,__,') ; \
+ (echo 'static const unsigned int __attribute__((section(".test,
\"ax\", @progbits #")))' \
+ "$${prefix}_$(arch)$${flavor}[] = {"; \
+od -v -t x $*.bin | sed -e 's/^[0-9]* /0x/' -e 's/ /, 0x/g' -e
's/$$/,/'; \
+echo "};") >>$@.new; \
+ rm -f $*.bin; \
+ done; \
+ )
+ mv $@.new $@
+
$(addsuffix .c,$(SIMD)):
ln -sf simd.c $@
@@ -145,4 +171,4 @@ x86-emulate.o test_x86_emulator.o wrappe
x86-emulate.o: x86_emulate/x86_emulate.c
x86-emulate.o: HOSTCFLAGS += -D__XEN_TOOLS__
-test_x86_emulator.o: $(addsuffix .h,$(TESTCASES))
+test_x86_emulator.o: $(addsuffix .h,$(TESTCASES)) $(addsuffix
-opmask.h,$(OPMASK))
--- /dev/null
+++ b/tools/tests/x86_emulator/opmask.S
@@ -0,0 +1,144 @@
+#ifdef __i386__
+# define R(x) e##x
+# define DATA(x) x
+#else
+# if SIZE == 8
+# define R(x) r##x
+# else
+# define R(x) e##x
+# endif
+# define DATA(x) x(%rip)
+#endif
+
+#if SIZE == 1
+# define _(x) x##b
+#elif SIZE == 2
+# define _(x) x##w
+# define WIDEN(x) x##bw
+#elif SIZE == 4
+# define _(x) x##d
+# define WIDEN(x) x##wd
+#elif SIZE == 8
+# define _(x) x##q
+# define WIDEN(x) x##dq
+#endif
+
+.macro check res1:req, res2:req, line:req
+_(kmov) %\res1, DATA(out)
+#if SIZE < 8 || !defined(__i386__)
+_(kmov) %\res2, %R(dx)
+cmp DATA(out), %R(dx)
+#else
+sub $8, %esp
+kmovq %\res2, (%esp)
+pop %ecx
+pop %edx
+cmp DATA(out), %ecx
+jne 0f
+cmp DATA(out+4), %edx
+0:
+#endif
+je1f
+mov $\line, %eax
+ret
+1:
+.endm
+
+.text
+.globl _start
+_start:
+_(kmov) DATA(in1), %k1
+#if SIZE < 8 || !defined(__i386__)
+mov DATA(in2), %R(ax)
+_(kmov) %R(ax), %k2
+#else
+_(kmov) DATA(in2), %k2
+#endif
+
+_(kor)%k1, %k2, %k3
+_(kand) %k1, %k2, %k4
+_(kandn) %k3, %k4, %k5
+_(kxor) %k1, %k2, %k6
+check k5, k6, __LINE__
+
+_(knot) %k6, %k3
+_(kxnor) %k1, %k2, %k4
+check k3, k4, __LINE__
+
+_(kshiftl)$1, %k1, %k3
+_(kshiftl)$2, %k3, %k4
+_(kshiftl)$3, %k1, %k5
+check k4, k5, __LINE__
+
+_(kshiftr)$1, %k1, %k3
+_(kshiftr)$2, %k3, %k4
+_(kshiftr)$3, %k1, %k5
+check k4, k5, __LINE__
+
+_(kortest)%k6, %k6
+jnbe 1f
+mov $__LINE__, %eax
+ret
+1:
+
+_(kxor)
[Xen-devel] [PATCH v2 2/6] x86emul: extend MASKMOV{Q,DQU} tests
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 actually works.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -2626,7 +2626,7 @@ int main(int argc, char **argv)
printf("skipped\n");
#endif
-printf("%-40s", "Testing maskmovq (zero mask)...");
+printf("%-40s", "Testing maskmovq %mm4,%mm4...");
if ( stack_exec && cpu_has_sse )
{
decl_insn(maskmovq);
@@ -2639,12 +2639,25 @@ int main(int argc, char **argv)
rc = x86_emulate(, );
if ( rc != X86EMUL_OKAY || !check_eip(maskmovq) )
goto fail;
+
+asm volatile ( "pcmpeqb %mm3, %mm3\n\t"
+ "punpcklbw %mm3, %mm4\n" );
+memset(res, 0x55, 24);
+
+set_insn(maskmovq);
+regs.edi = (unsigned long)(res + 2);
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(maskmovq) ||
+ memcmp(res, res + 4, 8) ||
+ res[2] != 0xff55ff55 || res[3] != 0xff55ff55 )
+goto fail;
+
printf("okay\n");
}
else
printf("skipped\n");
-printf("%-40s", "Testing maskmovdqu (zero mask)...");
+printf("%-40s", "Testing maskmovdqu %xmm3,%xmm3...");
if ( stack_exec && cpu_has_sse2 )
{
decl_insn(maskmovdqu);
@@ -2653,9 +2666,24 @@ int main(int argc, char **argv)
put_insn(maskmovdqu, "maskmovdqu %xmm3, %xmm3") );
set_insn(maskmovdqu);
+regs.edi = 0;
rc = x86_emulate(, );
if ( rc != X86EMUL_OKAY || !check_eip(maskmovdqu) )
goto fail;
+
+asm volatile ( "pcmpeqb %xmm4, %xmm4\n\t"
+ "punpcklbw %xmm4, %xmm3\n" );
+memset(res, 0x55, 48);
+
+set_insn(maskmovdqu);
+regs.edi = (unsigned long)(res + 4);
+rc = x86_emulate(, );
+if ( rc != X86EMUL_OKAY || !check_eip(maskmovdqu) ||
+ memcmp(res, res + 8, 16) ||
+ res[4] != 0xff55ff55 || res[5] != 0xff55ff55 ||
+ res[6] != 0xff55ff55 || res[7] != 0xff55ff55 )
+goto fail;
+
printf("okay\n");
}
else
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 1/6] x86emul: fix FMA scalar operand sizes
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 uniformly used simd_packed_fp (implying the
distinction was by [VEX-encoded] opcode prefix).
Split simd_scalar_fp into simd_scalar_opc and simd_scalar_vexw, and
correct
Also correct the scalar insn comments (they only ever use XMM registers
as operands).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -224,7 +224,13 @@ enum simd_opsize {
* - 32 bits with low opcode bit clear (scalar single)
* - 64 bits with low opcode bit set (scalar double)
*/
-simd_scalar_fp,
+simd_scalar_opc,
+
+/*
+ * Scalar floating point:
+ * - 32/64 bits depending on VEX.W
+ */
+simd_scalar_vexw,
/*
* 128 bits of integer or floating point data, with no further
@@ -407,7 +413,7 @@ static const struct ext0f38_table {
[0x13] = { .simd_size = simd_other, .two_op = 1 },
[0x14 ... 0x16] = { .simd_size = simd_packed_fp },
[0x17] = { .simd_size = simd_packed_int, .two_op = 1 },
-[0x18 ... 0x19] = { .simd_size = simd_scalar_fp, .two_op = 1 },
+[0x18 ... 0x19] = { .simd_size = simd_scalar_opc, .two_op = 1 },
[0x1a] = { .simd_size = simd_128, .two_op = 1 },
[0x1c ... 0x1e] = { .simd_size = simd_packed_int, .two_op = 1 },
[0x20 ... 0x25] = { .simd_size = simd_other, .two_op = 1 },
@@ -427,9 +433,30 @@ static const struct ext0f38_table {
[0x8c] = { .simd_size = simd_other },
[0x8e] = { .simd_size = simd_other, .to_mem = 1 },
[0x90 ... 0x93] = { .simd_size = simd_other, .vsib = 1 },
-[0x96 ... 0x9f] = { .simd_size = simd_packed_fp },
-[0xa6 ... 0xaf] = { .simd_size = simd_packed_fp },
-[0xb6 ... 0xbf] = { .simd_size = simd_packed_fp },
+[0x96 ... 0x98] = { .simd_size = simd_packed_fp },
+[0x99] = { .simd_size = simd_scalar_vexw },
+[0x9a] = { .simd_size = simd_packed_fp },
+[0x9b] = { .simd_size = simd_scalar_vexw },
+[0x9c] = { .simd_size = simd_packed_fp },
+[0x9d] = { .simd_size = simd_scalar_vexw },
+[0x9e] = { .simd_size = simd_packed_fp },
+[0x9f] = { .simd_size = simd_scalar_vexw },
+[0xa6 ... 0xa8] = { .simd_size = simd_packed_fp },
+[0xa9] = { .simd_size = simd_scalar_vexw },
+[0xaa] = { .simd_size = simd_packed_fp },
+[0xab] = { .simd_size = simd_scalar_vexw },
+[0xac] = { .simd_size = simd_packed_fp },
+[0xad] = { .simd_size = simd_scalar_vexw },
+[0xae] = { .simd_size = simd_packed_fp },
+[0xaf] = { .simd_size = simd_scalar_vexw },
+[0xb6 ... 0xb8] = { .simd_size = simd_packed_fp },
+[0xb9] = { .simd_size = simd_scalar_vexw },
+[0xba] = { .simd_size = simd_packed_fp },
+[0xbb] = { .simd_size = simd_scalar_vexw },
+[0xbc] = { .simd_size = simd_packed_fp },
+[0xbd] = { .simd_size = simd_scalar_vexw },
+[0xbe] = { .simd_size = simd_packed_fp },
+[0xbf] = { .simd_size = simd_scalar_vexw },
[0xc8 ... 0xcd] = { .simd_size = simd_other },
[0xdb] = { .simd_size = simd_packed_int, .two_op = 1 },
[0xdc ... 0xdf] = { .simd_size = simd_packed_int },
@@ -454,7 +481,7 @@ static const struct ext0f3a_table {
[0x04 ... 0x05] = { .simd_size = simd_packed_fp, .two_op = 1 },
[0x06] = { .simd_size = simd_packed_fp },
[0x08 ... 0x09] = { .simd_size = simd_packed_fp, .two_op = 1 },
-[0x0a ... 0x0b] = { .simd_size = simd_scalar_fp },
+[0x0a ... 0x0b] = { .simd_size = simd_scalar_opc },
[0x0c ... 0x0d] = { .simd_size = simd_packed_fp },
[0x0e ... 0x0f] = { .simd_size = simd_packed_int },
[0x14 ... 0x17] = { .simd_size = simd_none, .to_mem = 1, .two_op = 1 },
@@ -476,13 +503,13 @@ static const struct ext0f3a_table {
[0x5c ... 0x5f] = { .simd_size = simd_packed_fp, .four_op = 1 },
[0x60 ... 0x63] = { .simd_size = simd_packed_int, .two_op = 1 },
[0x68 ... 0x69] = { .simd_size = simd_packed_fp, .four_op = 1 },
-[0x6a ... 0x6b] = { .simd_size = simd_scalar_fp, .four_op = 1 },
+[0x6a ... 0x6b] = { .simd_size = simd_scalar_opc, .four_op = 1 },
[0x6c ... 0x6d] = { .simd_size = simd_packed_fp, .four_op = 1 },
-[0x6e ... 0x6f] = { .simd_size = simd_scalar_fp, .four_op = 1 },
+[0x6e ... 0x6f] = { .simd_size = simd_scalar_opc, .four_op = 1 },
[0x78 ... 0x79] = { .simd_size = simd_packed_fp, .four_op = 1 },
-[0x7a ... 0x7b] = { .simd_size = simd_scalar_fp, .four_op = 1 },
+[0x7a ... 0x7b] = { .simd_size = simd_scalar_opc, .four_op = 1 },
[0x7c ... 0x7d] = { .simd_size = simd_packed_fp, .four_op = 1 },
-[0x7e ... 0x7f] = { .simd_size = simd_scalar_fp, .four_op = 1 },
+[0x7e ... 0x7f] = { .simd_size = simd_scalar_opc, .four_op = 1 },
[0xcc] = { .simd_size = simd_other },
Re: [Xen-devel] [PATCH RFC] x86/HVM: meet xentrace's expectations on emulation event data
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 anyway not very helpful for the code
> here to only ever supply 32 bits of data (despite the field being 64
> bits wide, and having been even in the 32-bit days of Xen).
>
> Signed-off-by: Jan Beulich
> ---
> RFC: Untested; solely based on the observation of "(no data)" in a trace
> where it was entirely unclear why no data would have been available.
> I just so happened that the guest had more than 4Gb of memory, and
> hence addresses were not representable as 32-bit values.
Unfortunately, I don't think this helps much.
From what I can tell, xentrace_format doesn't understand the TRC_64_FLAG
versions of these events at all, and xenalyze uses:
union {
struct {
unsigned int gpa;
unsigned int data;
} x32;
struct {
unsigned long long gpa;
unsigned int data;
} x64;
} *r = (typeof(r))h->d;
to pull the data back out. AFAICT, this matches what Xen is currently
writing, and is equally wrong.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/6] x86emul: fixes, improvements, and beginnings of AVX512 support
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 widen respective fields in HVM code to allow for 64 byte
operand sizes has a dependency on the "x86/HVM: implement memory
read caching" series, which looks to be stalled, and I prefer to avoid
posting further patches with dependencies on stalled series.
Some support beyond moves is also mostly ready, but it's not quite
enough yet to enable testing that code in the harness, and I'd rather
not post code that I haven't pushed through the harness yet. The
partial testing I've been doing means, however, that in particular the
last two patches here have been tested already, even if no such
testing would be possible for others until further patches actually get
posted.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v17 13/13] x86/domctl: Don't pause the whole domain if only getting vcpu state
>>> 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 VCPU#0. Do >> > you think you could switch this code to use the newly introduced >> > machinery to save a single instance of a specific type? >> Sure, I will add a tool patch at the end of the series > > Is this urgent to be in this series? If not I will add a new patch > after it is all in. Considering the problems that there have been with this series, anything to help build confidence in things still working for all cases would help here, so I'm pretty glad Roger thought of this, and while I wouldn't make it as strong as "the series can't go in without this", I'd still much prefer if you too the time. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 10/12] x86/cpuidle: patch some indirect calls to direct ones
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
(from where cpuidle_init_cpu() runs the first time) the pointers need to
start out as NULL.
Signed-off-by: Jan Beulich
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -102,8 +102,6 @@ bool lapic_timer_init(void)
return true;
}
-static uint64_t (*__read_mostly tick_to_ns)(uint64_t) = acpi_pm_tick_to_ns;
-
void (*__read_mostly pm_idle_save)(void);
unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER - 1;
integer_param("max_cstate", max_cstate);
@@ -289,9 +287,9 @@ static uint64_t acpi_pm_ticks_elapsed(ui
return ((0x - t1) + t2 +1);
}
-uint64_t (*__read_mostly cpuidle_get_tick)(void) = get_acpi_pm_tick;
-static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t)
-= acpi_pm_ticks_elapsed;
+uint64_t (*__read_mostly cpuidle_get_tick)(void);
+static uint64_t (*__read_mostly tick_to_ns)(uint64_t);
+static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t);
static void print_acpi_power(uint32_t cpu, struct acpi_processor_power *power)
{
@@ -547,7 +545,7 @@ void update_idle_stats(struct acpi_proce
struct acpi_processor_cx *cx,
uint64_t before, uint64_t after)
{
-int64_t sleep_ticks = ticks_elapsed(before, after);
+int64_t sleep_ticks = alternative_call(ticks_elapsed, before, after);
/* Interrupts are disabled */
spin_lock(>stat_lock);
@@ -555,7 +553,8 @@ void update_idle_stats(struct acpi_proce
cx->usage++;
if ( sleep_ticks > 0 )
{
-power->last_residency = tick_to_ns(sleep_ticks) / 1000UL;
+power->last_residency = alternative_call(tick_to_ns, sleep_ticks) /
+1000UL;
cx->time += sleep_ticks;
}
power->last_state = >states[0];
@@ -635,7 +634,7 @@ static void acpi_processor_idle(void)
if ( cx->type == ACPI_STATE_C1 || local_apic_timer_c2_ok )
{
/* Get start time (ticks) */
-t1 = cpuidle_get_tick();
+t1 = alternative_call(cpuidle_get_tick);
/* Trace cpu idle entry */
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
@@ -644,7 +643,7 @@ static void acpi_processor_idle(void)
/* Invoke C2 */
acpi_idle_do_entry(cx);
/* Get end time (ticks) */
-t2 = cpuidle_get_tick();
+t2 = alternative_call(cpuidle_get_tick);
trace_exit_reason(irq_traced);
/* Trace cpu idle exit */
TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,
@@ -666,7 +665,7 @@ static void acpi_processor_idle(void)
lapic_timer_off();
/* Get start time (ticks) */
-t1 = cpuidle_get_tick();
+t1 = alternative_call(cpuidle_get_tick);
/* Trace cpu idle entry */
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
@@ -717,7 +716,7 @@ static void acpi_processor_idle(void)
}
/* Get end time (ticks) */
-t2 = cpuidle_get_tick();
+t2 = alternative_call(cpuidle_get_tick);
/* recovering TSC */
cstate_restore_tsc();
@@ -827,11 +826,20 @@ int cpuidle_init_cpu(unsigned int cpu)
{
unsigned int i;
-if ( cpu == 0 && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
+if ( cpu == 0 && system_state < SYS_STATE_active )
{
-cpuidle_get_tick = get_stime_tick;
-ticks_elapsed = stime_ticks_elapsed;
-tick_to_ns = stime_tick_to_ns;
+if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
+{
+cpuidle_get_tick = get_stime_tick;
+ticks_elapsed = stime_ticks_elapsed;
+tick_to_ns = stime_tick_to_ns;
+}
+else
+{
+cpuidle_get_tick = get_acpi_pm_tick;
+ticks_elapsed = acpi_pm_ticks_elapsed;
+tick_to_ns = acpi_pm_tick_to_ns;
+}
}
acpi_power = xzalloc(struct acpi_processor_power);
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -778,7 +778,7 @@ static void mwait_idle(void)
if (!(lapic_timer_reliable_states & (1 << cstate)))
lapic_timer_off();
- before = cpuidle_get_tick();
+ before = alternative_call(cpuidle_get_tick);
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->type, before, exp, pred);
update_last_cx_stat(power, cx, before);
@@ -786,7 +786,7 @@ static void mwait_idle(void)
if (cpu_is_haltable(cpu))
mwait_idle_with_hints(eax, MWAIT_ECX_INTERRUPT_BREAK);
- after = cpuidle_get_tick();
+
[Xen-devel] [PATCH v2 12/12] cpufreq: patch target() indirect call to direct one
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_freq = policy->cur;
-retval = cpufreq_driver.target(policy, target_freq, relation);
+retval = alternative_call(cpufreq_driver.target,
+ policy, target_freq, relation);
if ( retval == 0 )
TRACE_2D(TRC_PM_FREQ_CHANGE, prev_freq/1000, policy->cur/1000);
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 11/12] cpufreq: convert to a single post-init driver (hooks) instance
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/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -53,8 +53,6 @@ enum {
struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS];
-static struct cpufreq_driver acpi_cpufreq_driver;
-
static bool __read_mostly acpi_pstate_strict;
boolean_param("acpi_pstate_strict", acpi_pstate_strict);
@@ -355,7 +353,7 @@ static void feature_detect(void *info)
if ( cpu_has_aperfmperf )
{
policy->aperf_mperf = 1;
-acpi_cpufreq_driver.getavg = get_measured_perf;
+cpufreq_driver.getavg = get_measured_perf;
}
eax = cpuid_eax(6);
@@ -593,7 +591,7 @@ acpi_cpufreq_cpu_init(struct cpufreq_pol
policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
break;
case ACPI_ADR_SPACE_FIXED_HARDWARE:
-acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
+cpufreq_driver.get = get_cur_freq_on_cpu;
policy->cur = get_cur_freq_on_cpu(cpu);
break;
default:
@@ -635,7 +633,7 @@ static int acpi_cpufreq_cpu_exit(struct
return 0;
}
-static struct cpufreq_driver acpi_cpufreq_driver = {
+static const struct cpufreq_driver __initconstrel acpi_cpufreq_driver = {
.name = "acpi-cpufreq",
.verify = acpi_cpufreq_verify,
.target = acpi_cpufreq_target,
@@ -656,7 +654,7 @@ static int __init cpufreq_driver_init(vo
return ret;
}
-__initcall(cpufreq_driver_init);
+presmp_initcall(cpufreq_driver_init);
int cpufreq_cpu_init(unsigned int cpuid)
{
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -52,8 +52,6 @@
#define ARCH_CPU_FLAG_RESUME 1
-static struct cpufreq_driver powernow_cpufreq_driver;
-
static void transition_pstate(void *pstate)
{
wrmsrl(MSR_PSTATE_CTRL, *(unsigned int *)pstate);
@@ -215,7 +213,7 @@ static void feature_detect(void *info)
if ( cpu_has_aperfmperf )
{
policy->aperf_mperf = 1;
-powernow_cpufreq_driver.getavg = get_measured_perf;
+cpufreq_driver.getavg = get_measured_perf;
}
edx = cpuid_edx(CPUID_FREQ_VOLT_CAPABILITIES);
@@ -347,7 +345,8 @@ static int powernow_cpufreq_cpu_exit(str
return 0;
}
-static struct cpufreq_driver powernow_cpufreq_driver = {
+static const struct cpufreq_driver __initconstrel powernow_cpufreq_driver = {
+.name = "powernow",
.verify = powernow_cpufreq_verify,
.target = powernow_cpufreq_target,
.init = powernow_cpufreq_cpu_init,
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -64,7 +64,7 @@ int do_get_pm_info(struct xen_sysctl_get
case PMSTAT_PX:
if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) )
return -ENODEV;
-if ( !cpufreq_driver )
+if ( !cpufreq_driver.init )
return -ENODEV;
if ( !pmpt || !(pmpt->perf.init & XEN_PX_INIT) )
return -EINVAL;
@@ -255,16 +255,16 @@ static int get_cpufreq_para(struct xen_s
return ret;
op->u.get_para.cpuinfo_cur_freq =
-cpufreq_driver->get ? cpufreq_driver->get(op->cpuid) : policy->cur;
+cpufreq_driver.get ? cpufreq_driver.get(op->cpuid) : policy->cur;
op->u.get_para.cpuinfo_max_freq = policy->cpuinfo.max_freq;
op->u.get_para.cpuinfo_min_freq = policy->cpuinfo.min_freq;
op->u.get_para.scaling_cur_freq = policy->cur;
op->u.get_para.scaling_max_freq = policy->max;
op->u.get_para.scaling_min_freq = policy->min;
-if ( cpufreq_driver->name[0] )
+if ( cpufreq_driver.name[0] )
strlcpy(op->u.get_para.scaling_driver,
-cpufreq_driver->name, CPUFREQ_NAME_LEN);
+cpufreq_driver.name, CPUFREQ_NAME_LEN);
else
strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -172,7 +172,7 @@ int cpufreq_add_cpu(unsigned int cpu)
if ( !(perf->init & XEN_PX_INIT) )
return -EINVAL;
-if (!cpufreq_driver)
+if (!cpufreq_driver.init)
return 0;
if (per_cpu(cpufreq_cpu_policy, cpu))
@@ -239,7 +239,7 @@ int cpufreq_add_cpu(unsigned int cpu)
policy->cpu = cpu;
per_cpu(cpufreq_cpu_policy, cpu) = policy;
-ret = cpufreq_driver->init(policy);
+ret = cpufreq_driver.init(policy);
if (ret) {
free_cpumask_var(policy->cpus);
xfree(policy);
@@ -298,7 +298,7 @@ err1:
cpumask_clear_cpu(cpu, cpufreq_dom->map);
if (cpumask_empty(policy->cpus)) {
-cpufreq_driver->exit(policy);
+cpufreq_driver.exit(policy);
free_cpumask_var(policy->cpus);
xfree(policy);
}
@@ -362,7 +362,7 @@ int cpufreq_del_cpu(unsigned int cpu)
[Xen-devel] [PATCH v2 09/12] x86/genapic: patch indirect calls to direct ones
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)
{
-genapic.send_IPI_mask(mask, vector);
+alternative_vcall(genapic.send_IPI_mask, mask, vector);
}
void send_IPI_self(int vector)
{
-genapic.send_IPI_self(vector);
+alternative_vcall(genapic.send_IPI_self, vector);
}
/*
--- a/xen/include/asm-x86/mach-generic/mach_apic.h
+++ b/xen/include/asm-x86/mach-generic/mach_apic.h
@@ -15,8 +15,18 @@
#define TARGET_CPUS ((const typeof(cpu_online_map) *)_online_map)
#define init_apic_ldr (genapic.init_apic_ldr)
#define clustered_apic_check (genapic.clustered_apic_check)
-#define cpu_mask_to_apicid (genapic.cpu_mask_to_apicid)
-#define vector_allocation_cpumask(cpu) (genapic.vector_allocation_cpumask(cpu))
+#define cpu_mask_to_apicid(mask) ({ \
+ /* \
+* There are a number of places where the address of a local variable \
+* gets passed here. The use of ?: in alternative_call() triggers an
\
+* "address of ... is always true" warning in such a case with at least
\
+* gcc 7 and 8. Hence the seemingly pointless local variable here. \
+*/ \
+ const cpumask_t *m_ = (mask); \
+ alternative_call(genapic.cpu_mask_to_apicid, m_); \
+})
+#define vector_allocation_cpumask(cpu) \
+ alternative_call(genapic.vector_allocation_cpumask, cpu)
static inline void enable_apic_mode(void)
{
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 07/12] x86/genapic: drop .target_cpus() hook
All flavors specify target_cpus_all() anyway - replace use of the hook
by _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 _online_map;
-}
-
/*
* LOGICAL FLAT DELIVERY MODE (multicast via bitmask to <= 8 logical APIC IDs).
*/
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -169,7 +169,6 @@ static const struct genapic apic_x2apic_
.int_dest_mode = 0 /* physical delivery */,
.init_apic_ldr = init_apic_ldr_x2apic_phys,
.clustered_apic_check = clustered_apic_check_x2apic,
-.target_cpus = target_cpus_all,
.vector_allocation_cpumask = vector_allocation_cpumask_phys,
.cpu_mask_to_apicid = cpu_mask_to_apicid_phys,
.send_IPI_mask = send_IPI_mask_x2apic_phys,
@@ -182,7 +181,6 @@ static const struct genapic apic_x2apic_
.int_dest_mode = 1 /* logical delivery */,
.init_apic_ldr = init_apic_ldr_x2apic_cluster,
.clustered_apic_check = clustered_apic_check_x2apic,
-.target_cpus = target_cpus_all,
.vector_allocation_cpumask = vector_allocation_cpumask_x2apic_cluster,
.cpu_mask_to_apicid = cpu_mask_to_apicid_x2apic_cluster,
.send_IPI_mask = send_IPI_mask_x2apic_cluster,
--- a/xen/include/asm-x86/genapic.h
+++ b/xen/include/asm-x86/genapic.h
@@ -33,7 +33,6 @@ struct genapic {
int int_dest_mode;
void (*init_apic_ldr)(void);
void (*clustered_apic_check)(void);
- const cpumask_t *(*target_cpus)(void);
const cpumask_t *(*vector_allocation_cpumask)(int cpu);
unsigned int (*cpu_mask_to_apicid)(const cpumask_t *cpumask);
void (*send_IPI_mask)(const cpumask_t *mask, int vector);
@@ -51,7 +50,6 @@ struct genapic {
extern const struct genapic *genapic;
extern const struct genapic apic_default;
-const cpumask_t *target_cpus_all(void);
void send_IPI_self_legacy(uint8_t vector);
void init_apic_ldr_flat(void);
@@ -64,7 +62,6 @@ const cpumask_t *vector_allocation_cpuma
.int_dest_mode = 1 /* logical delivery */, \
.init_apic_ldr = init_apic_ldr_flat, \
.clustered_apic_check = clustered_apic_check_flat, \
- .target_cpus = target_cpus_all, \
.vector_allocation_cpumask = vector_allocation_cpumask_flat, \
.cpu_mask_to_apicid = cpu_mask_to_apicid_flat, \
.send_IPI_mask = send_IPI_mask_flat, \
@@ -80,7 +77,6 @@ const cpumask_t *vector_allocation_cpuma
.int_dest_mode = 0 /* physical delivery */, \
.init_apic_ldr = init_apic_ldr_phys, \
.clustered_apic_check = clustered_apic_check_phys, \
- .target_cpus = target_cpus_all, \
.vector_allocation_cpumask = vector_allocation_cpumask_phys, \
.cpu_mask_to_apicid = cpu_mask_to_apicid_phys, \
.send_IPI_mask = send_IPI_mask_phys, \
--- a/xen/include/asm-x86/mach-generic/mach_apic.h
+++ b/xen/include/asm-x86/mach-generic/mach_apic.h
@@ -12,7 +12,7 @@
/* The following are dependent on APIC delivery mode (logical vs. physical). */
#define INT_DELIVERY_MODE (genapic->int_delivery_mode)
#define INT_DEST_MODE (genapic->int_dest_mode)
-#define TARGET_CPUS (genapic->target_cpus())
+#define TARGET_CPUS ((const typeof(cpu_online_map) *)_online_map)
#define init_apic_ldr (genapic->init_apic_ldr)
#define clustered_apic_check (genapic->clustered_apic_check)
#define cpu_mask_to_apicid (genapic->cpu_mask_to_apicid)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 08/12] x86/genapic: remove indirection from genapic hook accesses
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/apic.c
+++ b/xen/arch/x86/apic.c
@@ -944,8 +944,8 @@ void __init x2apic_bsp_setup(void)
force_iommu = 1;
-genapic = apic_x2apic_probe();
-printk("Switched to APIC driver %s.\n", genapic->name);
+genapic = *apic_x2apic_probe();
+printk("Switched to APIC driver %s.\n", genapic.name);
if ( !x2apic_enabled )
{
--- a/xen/arch/x86/genapic/bigsmp.c
+++ b/xen/arch/x86/genapic/bigsmp.c
@@ -42,7 +42,7 @@ static __init int probe_bigsmp(void)
return def_to_bigsmp;
}
-const struct genapic apic_bigsmp = {
+const struct genapic __initconstrel apic_bigsmp = {
APIC_INIT("bigsmp", probe_bigsmp),
GENAPIC_PHYS
};
--- a/xen/arch/x86/genapic/default.c
+++ b/xen/arch/x86/genapic/default.c
@@ -20,7 +20,7 @@ static __init int probe_default(void)
return 1;
}
-const struct genapic apic_default = {
+const struct genapic __initconstrel apic_default = {
APIC_INIT("default", probe_default),
GENAPIC_FLAT
};
--- a/xen/arch/x86/genapic/probe.c
+++ b/xen/arch/x86/genapic/probe.c
@@ -15,11 +15,9 @@
#include
#include
-extern const struct genapic apic_bigsmp;
+struct genapic __read_mostly genapic;
-const struct genapic *__read_mostly genapic;
-
-const struct genapic *apic_probe[] __initdata = {
+const struct genapic *const __initconstrel apic_probe[] = {
_bigsmp,
_default, /* must be last */
NULL,
@@ -36,11 +34,11 @@ void __init generic_bigsmp_probe(void)
* - we find more than 8 CPUs in acpi LAPIC listing with xAPIC support
*/
- if (!cmdline_apic && genapic == _default)
+ if (!cmdline_apic && genapic.name == apic_default.name)
if (apic_bigsmp.probe()) {
- genapic = _bigsmp;
+ genapic = apic_bigsmp;
printk(KERN_INFO "Overriding APIC driver with %s\n",
- genapic->name);
+ genapic.name);
}
}
@@ -50,7 +48,7 @@ static int __init genapic_apic_force(con
for (i = 0; apic_probe[i]; i++)
if (!strcmp(apic_probe[i]->name, str)) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
rc = 0;
}
@@ -66,18 +64,18 @@ void __init generic_apic_probe(void)
record_boot_APIC_mode();
check_x2apic_preenabled();
- cmdline_apic = changed = (genapic != NULL);
+ cmdline_apic = changed = !!genapic.name;
for (i = 0; !changed && apic_probe[i]; i++) {
if (apic_probe[i]->probe()) {
changed = 1;
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
}
}
if (!changed)
- genapic = _default;
+ genapic = apic_default;
- printk(KERN_INFO "Using APIC driver %s\n", genapic->name);
+ printk(KERN_INFO "Using APIC driver %s\n", genapic.name);
}
/* These functions can switch the APIC even after the initial ->probe() */
@@ -88,9 +86,9 @@ int __init mps_oem_check(struct mp_confi
for (i = 0; apic_probe[i]; ++i) {
if (apic_probe[i]->mps_oem_check(mpc,oem,productid)) {
if (!cmdline_apic) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
printk(KERN_INFO "Switched to APIC driver
`%s'.\n",
- genapic->name);
+ genapic.name);
}
return 1;
}
@@ -104,9 +102,9 @@ int __init acpi_madt_oem_check(char *oem
for (i = 0; apic_probe[i]; ++i) {
if (apic_probe[i]->acpi_madt_oem_check(oem_id, oem_table_id)) {
if (!cmdline_apic) {
- genapic = apic_probe[i];
+ genapic = *apic_probe[i];
printk(KERN_INFO "Switched to APIC driver
`%s'.\n",
- genapic->name);
+ genapic.name);
}
return 1;
}
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -163,7 +163,7 @@ static void send_IPI_mask_x2apic_cluster
local_irq_restore(flags);
}
-static const struct genapic apic_x2apic_phys = {
+static const struct genapic __initconstrel apic_x2apic_phys = {
APIC_INIT("x2apic_phys", NULL),
.int_delivery_mode =
[Xen-devel] [PATCH v2 06/12] x86: patch ctxt_switch_masking() indirect call to direct one
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); + alternative_vcall(ctxt_switch_masking, next); } bool_t opt_cpu_info; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 05/12] x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones
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: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -111,10 +111,15 @@ static void vlapic_clear_irr(int vector,
vlapic_clear_vector(vector, >regs->data[APIC_IRR]);
}
-static int vlapic_find_highest_irr(struct vlapic *vlapic)
+static void sync_pir_to_irr(struct vcpu *v)
{
if ( hvm_funcs.sync_pir_to_irr )
-hvm_funcs.sync_pir_to_irr(vlapic_vcpu(vlapic));
+alternative_vcall(hvm_funcs.sync_pir_to_irr, v);
+}
+
+static int vlapic_find_highest_irr(struct vlapic *vlapic)
+{
+sync_pir_to_irr(vlapic_vcpu(vlapic));
return vlapic_find_highest_vector(>regs->data[APIC_IRR]);
}
@@ -143,7 +148,7 @@ bool vlapic_test_irq(const struct vlapic
return false;
if ( hvm_funcs.test_pir &&
- hvm_funcs.test_pir(const_vlapic_vcpu(vlapic), vec) )
+ alternative_call(hvm_funcs.test_pir, const_vlapic_vcpu(vlapic), vec) )
return true;
return vlapic_test_vector(vec, >regs->data[APIC_IRR]);
@@ -165,10 +170,10 @@ void vlapic_set_irq(struct vlapic *vlapi
vlapic_clear_vector(vec, >regs->data[APIC_TMR]);
if ( hvm_funcs.update_eoi_exit_bitmap )
-hvm_funcs.update_eoi_exit_bitmap(target, vec, trig);
+alternative_vcall(hvm_funcs.update_eoi_exit_bitmap, target, vec, trig);
if ( hvm_funcs.deliver_posted_intr )
-hvm_funcs.deliver_posted_intr(target, vec);
+alternative_vcall(hvm_funcs.deliver_posted_intr, target, vec);
else if ( !vlapic_test_and_set_irr(vec, vlapic) )
vcpu_kick(target);
}
@@ -448,7 +453,7 @@ void vlapic_EOI_set(struct vlapic *vlapi
vlapic_clear_vector(vector, >regs->data[APIC_ISR]);
if ( hvm_funcs.handle_eoi )
-hvm_funcs.handle_eoi(vector);
+alternative_vcall(hvm_funcs.handle_eoi, vector);
vlapic_handle_EOI(vlapic, vector);
@@ -1429,8 +1434,7 @@ static int lapic_save_regs(struct domain
for_each_vcpu ( d, v )
{
-if ( hvm_funcs.sync_pir_to_irr )
-hvm_funcs.sync_pir_to_irr(v);
+sync_pir_to_irr(v);
s = vcpu_vlapic(v);
if ( (rc = hvm_save_entry(LAPIC_REGS, v->vcpu_id, h, s->regs)) != 0 )
@@ -1531,7 +1535,8 @@ static int lapic_load_regs(struct domain
lapic_load_fixup(s);
if ( hvm_funcs.process_isr )
-hvm_funcs.process_isr(vlapic_find_highest_isr(s), v);
+alternative_vcall(hvm_funcs.process_isr,
+ vlapic_find_highest_isr(s), v);
vlapic_adjust_i8259_target(d);
lapic_rearm(s);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2336,12 +2336,6 @@ static struct hvm_function_table __initd
.nhvm_vcpu_vmexit_event = nvmx_vmexit_event,
.nhvm_intr_blocked= nvmx_intr_blocked,
.nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
-.update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
-.process_isr = vmx_process_isr,
-.deliver_posted_intr = vmx_deliver_posted_intr,
-.sync_pir_to_irr = vmx_sync_pir_to_irr,
-.test_pir = vmx_test_pir,
-.handle_eoi = vmx_handle_eoi,
.nhvm_hap_walk_L1_p2m = nvmx_hap_walk_L1_p2m,
.enable_msr_interception = vmx_enable_msr_interception,
.is_singlestep_supported = vmx_is_singlestep_supported,
@@ -2469,26 +2463,23 @@ const struct hvm_function_table * __init
setup_ept_dump();
}
-if ( !cpu_has_vmx_virtual_intr_delivery )
+if ( cpu_has_vmx_virtual_intr_delivery )
{
-vmx_function_table.update_eoi_exit_bitmap = NULL;
-vmx_function_table.process_isr = NULL;
-vmx_function_table.handle_eoi = NULL;
-}
-else
+vmx_function_table.update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap;
+vmx_function_table.process_isr = vmx_process_isr;
+vmx_function_table.handle_eoi = vmx_handle_eoi;
vmx_function_table.virtual_intr_delivery_enabled = true;
+}
if ( cpu_has_vmx_posted_intr_processing )
{
alloc_direct_apic_vector(_intr_vector,
pi_notification_interrupt);
if ( iommu_intpost )
alloc_direct_apic_vector(_wakeup_vector, pi_wakeup_interrupt);
-}
-else
-{
-vmx_function_table.deliver_posted_intr = NULL;
-vmx_function_table.sync_pir_to_irr = NULL;
-vmx_function_table.test_pir = NULL;
+
+vmx_function_table.deliver_posted_intr = vmx_deliver_posted_intr;
+vmx_function_table.sync_pir_to_irr = vmx_sync_pir_to_irr;
+vmx_function_table.test_pir= vmx_test_pir;
}
if ( cpu_has_vmx_tsc_scaling )
[Xen-devel] [PATCH v2 04/12] x86/HVM: patch indirect calls through hvm_funcs to direct ones
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 patch.
Signed-off-by: Jan Beulich
---
v2: Drop open-coded numbers from macro invocations. Re-base.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2031,7 +2031,7 @@ static int hvmemul_write_msr(
static int hvmemul_wbinvd(
struct x86_emulate_ctxt *ctxt)
{
-hvm_funcs.wbinvd_intercept();
+alternative_vcall(hvm_funcs.wbinvd_intercept);
return X86EMUL_OKAY;
}
@@ -2049,7 +2049,7 @@ static int hvmemul_get_fpu(
struct vcpu *curr = current;
if ( !curr->fpu_dirtied )
-hvm_funcs.fpu_dirty_intercept();
+alternative_vcall(hvm_funcs.fpu_dirty_intercept);
else if ( type == X86EMUL_FPU_fpu )
{
const typeof(curr->arch.xsave_area->fpu_sse) *fpu_ctxt =
@@ -2166,7 +2166,7 @@ static void hvmemul_put_fpu(
{
curr->fpu_dirtied = false;
stts();
-hvm_funcs.fpu_leave(curr);
+alternative_vcall(hvm_funcs.fpu_leave, curr);
}
}
}
@@ -2328,7 +2328,8 @@ static int _hvm_emulate_one(struct hvm_e
if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
{
hvmemul_ctxt->intr_shadow = new_intr_shadow;
-hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
+alternative_vcall(hvm_funcs.set_interrupt_shadow,
+ curr, new_intr_shadow);
}
if ( hvmemul_ctxt->ctxt.retire.hlt &&
@@ -2465,7 +2466,8 @@ void hvm_emulate_init_once(
memset(hvmemul_ctxt, 0, sizeof(*hvmemul_ctxt));
-hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(curr);
+hvmemul_ctxt->intr_shadow =
+alternative_call(hvm_funcs.get_interrupt_shadow, curr);
hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -272,12 +272,12 @@ void hvm_set_rdtsc_exiting(struct domain
struct vcpu *v;
for_each_vcpu ( d, v )
-hvm_funcs.set_rdtsc_exiting(v, enable);
+alternative_vcall(hvm_funcs.set_rdtsc_exiting, v, enable);
}
void hvm_get_guest_pat(struct vcpu *v, u64 *guest_pat)
{
-if ( !hvm_funcs.get_guest_pat(v, guest_pat) )
+if ( !alternative_call(hvm_funcs.get_guest_pat, v, guest_pat) )
*guest_pat = v->arch.hvm_vcpu.pat_cr;
}
@@ -302,7 +302,7 @@ int hvm_set_guest_pat(struct vcpu *v, u6
return 0;
}
-if ( !hvm_funcs.set_guest_pat(v, guest_pat) )
+if ( !alternative_call(hvm_funcs.set_guest_pat, v, guest_pat) )
v->arch.hvm_vcpu.pat_cr = guest_pat;
return 1;
@@ -342,7 +342,7 @@ bool hvm_set_guest_bndcfgs(struct vcpu *
/* nothing, best effort only */;
}
-return hvm_funcs.set_guest_bndcfgs(v, val);
+return alternative_call(hvm_funcs.set_guest_bndcfgs, v, val);
}
/*
@@ -502,7 +502,8 @@ void hvm_migrate_pirqs(struct vcpu *v)
static bool hvm_get_pending_event(struct vcpu *v, struct x86_event *info)
{
info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
-return hvm_funcs.get_pending_event(v, info);
+
+return alternative_call(hvm_funcs.get_pending_event, v, info);
}
void hvm_do_resume(struct vcpu *v)
@@ -1683,7 +1684,7 @@ void hvm_inject_event(const struct x86_e
}
}
-hvm_funcs.inject_event(event);
+alternative_vcall(hvm_funcs.inject_event, event);
}
int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,
@@ -2270,7 +2271,7 @@ int hvm_set_cr0(unsigned long value, boo
(!rangeset_is_empty(d->iomem_caps) ||
!rangeset_is_empty(d->arch.ioport_caps) ||
has_arch_pdevs(d)) )
-hvm_funcs.handle_cd(v, value);
+alternative_vcall(hvm_funcs.handle_cd, v, value);
hvm_update_cr(v, 0, value);
@@ -3512,7 +3513,8 @@ int hvm_msr_read_intercept(unsigned int
goto gp_fault;
/* If ret == 0 then this is not an MCE MSR, see other MSRs. */
ret = ((ret == 0)
- ? hvm_funcs.msr_read_intercept(msr, msr_content)
+ ? alternative_call(hvm_funcs.msr_read_intercept,
+ msr, msr_content)
: X86EMUL_OKAY);
break;
}
@@ -3672,7 +3674,8 @@ int hvm_msr_write_intercept(unsigned int
goto gp_fault;
/* If ret == 0 then this is not an MCE MSR, see other MSRs. */
ret = ((ret == 0)
- ? hvm_funcs.msr_write_intercept(msr, msr_content)
+ ? alternative_call(hvm_funcs.msr_write_intercept,
+ msr, msr_content)
: X86EMUL_OKAY);
break;
}
@@ -3864,7 +3867,7 @@ void hvm_hypercall_page_initialise(struc
void
Re: [Xen-devel] [PATCH v17 13/13] x86/domctl: Don't pause the whole domain if only getting vcpu state
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 > > > typecode from one vcpu and now that the save functions get data > > > from a > > > single vcpu we can pause the specific vcpu instead of the domain. > > With this infrastructure added allowing to save a single instance > > of > > a > > specific device I wonder if you would like to add a user to the > > code > > in the tree. > > > > 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 VCPU#0. Do > > you think you could switch this code to use the newly introduced > > machinery to save a single instance of a specific type? > Sure, I will add a tool patch at the end of the series Hi Roger, Is this urgent to be in this series? If not I will add a new patch after it is all in. Thanks, Alex > > > > > > > > > > > > > Signed-off-by: Alexandru Isaila > > > > > > --- > > > Changes since V15: > > > - Moved pause/unpause calls into hvm_save_one() > > > - Re-add the loop in hvm_save_one(). > > > --- > > > xen/arch/x86/domctl.c | 2 -- > > > xen/arch/x86/hvm/save.c | 12 ++-- > > > 2 files changed, 10 insertions(+), 4 deletions(-) > > > > > > diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c > > > index 8fbbf3a..cb53980 100644 > > > --- a/xen/arch/x86/domctl.c > > > +++ b/xen/arch/x86/domctl.c > > > @@ -591,12 +591,10 @@ long arch_do_domctl( > > > !is_hvm_domain(d) ) > > > break; > > > > > > -domain_pause(d); > > > ret = hvm_save_one(d, domctl->u.hvmcontext_partial.type, > > > domctl- > > > >u.hvmcontext_partial.instance, > > > domctl->u.hvmcontext_partial.buffer, > > > >u.hvmcontext_partial.bufsz); > > > -domain_unpause(d); > > > > > > if ( !ret ) > > > copyback = true; > > > diff --git a/xen/arch/x86/hvm/save.c b/xen/arch/x86/hvm/save.c > > > index 49741e0..2d35f17 100644 > > > --- a/xen/arch/x86/hvm/save.c > > > +++ b/xen/arch/x86/hvm/save.c > > > @@ -149,12 +149,15 @@ int hvm_save_one(struct domain *d, unsigned > > > int typecode, unsigned int instance, > > > instance >= d->max_vcpus ) > > > return -ENOENT; > > > ctxt.size = hvm_sr_handlers[typecode].size; > > > -if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU ) > > > -ctxt.size *= d->max_vcpus; > > This chunk seems to belong to a different patch? > > > > The change just mentions pausing a vpcu instead of the whole > > domain, > > but the size of the save context doesn't depend on whether the > > whole > > domain is paused vs a single vcpu is paused. > Right, git rebase did not report any error so it tricked me. I will > have that removed from this patch. > > Thanks, > Alex > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 03/12] x86: infrastructure to allow converting certain indirect calls to direct ones
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, making necessary a second passs through the
alternative patching code. Therefore some adjustments beyond the
recognition of the new special pattern are necessary there.
Note that patching such sites more than once is not supported (and the
supplied macros also don't provide any means to do so).
Signed-off-by: Jan Beulich
---
v2: Introduce and use count_va_arg(). Don't omit middle operand from
?: in ALT_CALL_ARG(). Re-base.
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -177,8 +177,9 @@ text_poke(void *addr, const void *opcode
* APs have less capabilities than the boot processor are not handled.
* Tough. Make sure you disable such features by hand.
*/
-void init_or_livepatch apply_alternatives(struct alt_instr *start,
- struct alt_instr *end)
+static void init_or_livepatch _apply_alternatives(struct alt_instr *start,
+ struct alt_instr *end,
+ bool force)
{
struct alt_instr *a, *base;
@@ -217,6 +218,13 @@ void init_or_livepatch apply_alternative
if ( ALT_ORIG_PTR(base) != orig )
base = a;
+/* Skip patch sites already handled during the first pass. */
+if ( a->priv )
+{
+ASSERT(force);
+continue;
+}
+
/* If there is no replacement to make, see about optimising the nops.
*/
if ( !boot_cpu_has(a->cpuid) )
{
@@ -224,7 +232,7 @@ void init_or_livepatch apply_alternative
if ( base->priv )
continue;
-base->priv = 1;
+a->priv = 1;
/* Nothing useful to do? */
if ( toolchain_nops_are_ideal || a->pad_len <= 1 )
@@ -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. */
if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
-*(int32_t *)(buf + 1) += repl - orig;
+{
+/*
+ * Detect the special case of indirect-to-direct branch patching:
+ * - replacement is a direct CALL/JMP (opcodes 0xE8/0xE9; already
+ * checked above),
+ * - replacement's displacement is -5 (pointing back at the very
+ * insn, which makes no sense in a real replacement insn),
+ * - original is an indirect CALL/JMP (opcodes 0xFF/2 or 0xFF/4)
+ * using RIP-relative addressing.
+ * Some function targets may not be available when we come here
+ * the first time. Defer patching of those until the post-presmp-
+ * initcalls re-invocation. If at that point the target pointer is
+ * still NULL, insert "UD2; UD0" (for ease of recognition) instead
+ * of CALL/JMP.
+ */
+if ( a->cpuid == X86_FEATURE_ALWAYS &&
+ *(int32_t *)(buf + 1) == -5 &&
+ a->orig_len >= 6 &&
+ orig[0] == 0xff &&
+ orig[1] == (*buf & 1 ? 0x25 : 0x15) )
+{
+long disp = *(int32_t *)(orig + 2);
+const uint8_t *dest = *(void **)(orig + 6 + disp);
+
+if ( dest )
+{
+disp = dest - (orig + 5);
+ASSERT(disp == (int32_t)disp);
+*(int32_t *)(buf + 1) = disp;
+}
+else if ( force )
+{
+buf[0] = 0x0f;
+buf[1] = 0x0b;
+buf[2] = 0x0f;
+buf[3] = 0xff;
+buf[4] = 0xff;
+}
+else
+continue;
+}
+else if ( force && system_state < SYS_STATE_active )
+ASSERT_UNREACHABLE();
+else
+*(int32_t *)(buf + 1) += repl - orig;
+}
+else if ( force && system_state < SYS_STATE_active )
+ASSERT_UNREACHABLE();
/* RIP-relative addressing is easy to check for in VEX-encoded insns.
*/
else if ( a->repl_len >= 8 &&
(*buf & ~1) == 0xc4 &&
@@ -249,12 +302,21 @@ void init_or_livepatch apply_alternative
(buf[4 - (*buf & 1)] & ~0x38) == 0x05 )
*(int32_t *)(buf + 5 - (*buf & 1)) += repl - orig;
+a->priv = 1;
+
add_nops(buf + a->repl_len, total_len - a->repl_len);
text_poke(orig, buf, total_len);
}
}
-static bool
[Xen-devel] [PATCH v2 02/12] x86/alternatives: allow using assembler macros in favor of C ones
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 heavy weight than it really is. By presenting it
with an assembler macro invocation instead, this can be avoided.
Initially I wanted to outright change the C macros ALTERNATIVE() and
ALTERNATIVE_2() to invoke the respective assembler ones, but doing so
would require quite a bit of cleanup of some use sites, because of the
exra necessary quoting combined with the need that each assembler macro
argument must consist of just a single string literal. We can consider
working towards that subsequently.
For now, set the stage of using the assembler macros here by providing a
new generated header, being the slightly massaged pre-processor output
of (for now just) alternative-asm.h. The massaging is primarily to be
able to properly track the build dependency: For this, we need the C
compiler to see the inclusion, which means we shouldn't directly use an
asm(". include ...") directive.
The dependency added to asm-offsets.s is not a true one; it's just the
easiest approach I could think of to make sure the new header gets
generated early on, without having to fiddle with xen/Makefile (and
introducing some x86-specific construct there).
Signed-off-by: Jan Beulich
---
v2: Re-base.
--- a/.gitignore
+++ b/.gitignore
@@ -293,6 +293,7 @@ xen/.config.old
xen/System.map
xen/arch/arm/asm-offsets.s
xen/arch/arm/xen.lds
+xen/arch/x86/asm-macros.i
xen/arch/x86/asm-offsets.s
xen/arch/x86/boot/mkelf32
xen/arch/x86/xen.lds
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -215,9 +215,22 @@ $(TARGET).efi: prelink-efi.o $(note_file
efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o:
$(BASEDIR)/arch/x86/efi/built_in.o
efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: ;
-asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
+asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(BASEDIR)/include/asm-x86/asm-macros.h
$(CC) $(filter-out -Wa$(comma)% -flto,$(CFLAGS)) -S -o $@ $<
+asm-macros.i: CFLAGS += -D__ASSEMBLY__ -P
+
+$(BASEDIR)/include/asm-x86/asm-macros.h: asm-macros.i Makefile
+ echo '#if 0' >$@.new
+ echo '.if 0' >>$@.new
+ echo '#endif' >>$@.new
+ echo 'asm ( ".include \"$@\"" );' >>$@.new
+ echo '#if 0' >>$@.new
+ echo '.endif' >>$@.new
+ cat $< >>$@.new
+ echo '#endif' >>$@.new
+ $(call move-if-changed,$@.new,$@)
+
xen.lds: xen.lds.S
$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
@@ -237,6 +250,7 @@ efi/mkreloc: efi/mkreloc.c
.PHONY: clean
clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
+ rm -f asm-macros.i $(BASEDIR)/include/asm-x86/asm-macros.*
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
--- /dev/null
+++ b/xen/arch/x86/asm-macros.c
@@ -0,0 +1 @@
+#include
--- a/xen/include/asm-x86/alternative.h
+++ b/xen/include/asm-x86/alternative.h
@@ -1,11 +1,12 @@
#ifndef __X86_ALTERNATIVE_H__
#define __X86_ALTERNATIVE_H__
+#ifdef __ASSEMBLY__
#include
-
-#ifndef __ASSEMBLY__
+#else
#include
#include
+#include
struct __packed alt_instr {
int32_t orig_offset; /* original instruction */
@@ -26,14 +27,6 @@ extern void add_nops(void *insns, unsign
extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
extern void alternative_instructions(void);
-asm ( ".macro mknops nr_bytes\n\t"
-#ifdef HAVE_AS_NOPS_DIRECTIVE
- ".nops \\nr_bytes, " __stringify(ASM_NOP_MAX) "\n\t"
-#else
- ".skip \\nr_bytes, 0x90\n\t"
-#endif
- ".endm\n\t" );
-
#define alt_orig_len "(.LXEN%=_orig_e - .LXEN%=_orig_s)"
#define alt_pad_len"(.LXEN%=_orig_p - .LXEN%=_orig_e)"
#define alt_total_len "(.LXEN%=_orig_p - .LXEN%=_orig_s)"
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/2] x86: report use of PCID together with reporting XPTI status
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__ >>> >>> +#include >> Just types? Its all you need. > That's all I need for my addition, but prior to this the header wasn't > usable without first having included some other headers. > get_pcid_bits() de-references struct vcpu, so sched.h _is_ needed > (and should have been there before). Ok. Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 01/12] VMX: reduce number of posted-interrupt hooks
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 the the vCPU blocking hook, which needs to
remain an actual function pointer). This is the more that with the
Spectre v2 workarounds indirect calls have become more expensive.
Signed-off-by: Jan Beulich
---
v2: Set PI_CSW_TO instead of PI_CSW_FROM in vmx_pi_hooks_deassign().
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -77,6 +77,10 @@ static int vmx_msr_read_intercept(unsign
static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content);
static void vmx_invlpg(struct vcpu *v, unsigned long vaddr);
+/* Values for domain's ->arch.hvm_domain.pi_ops.flags. */
+#define PI_CSW_FROM (1u << 0)
+#define PI_CSW_TO (1u << 1)
+
struct vmx_pi_blocking_vcpu {
struct list_head list;
spinlock_t lock;
@@ -329,8 +333,7 @@ void vmx_pi_hooks_assign(struct domain *
* This can make sure the PI (especially the NDST feild) is
* in proper state when we call vmx_vcpu_block().
*/
-d->arch.hvm_domain.pi_ops.switch_from = vmx_pi_switch_from;
-d->arch.hvm_domain.pi_ops.switch_to = vmx_pi_switch_to;
+d->arch.hvm_domain.pi_ops.flags = PI_CSW_FROM | PI_CSW_TO;
for_each_vcpu ( d, v )
{
@@ -346,7 +349,6 @@ void vmx_pi_hooks_assign(struct domain *
}
d->arch.hvm_domain.pi_ops.vcpu_block = vmx_vcpu_block;
-d->arch.hvm_domain.pi_ops.do_resume = vmx_pi_do_resume;
}
/* This function is called when pcidevs_lock is held */
@@ -383,8 +385,7 @@ void vmx_pi_hooks_deassign(struct domain
* 'switch_to' hook function.
*/
d->arch.hvm_domain.pi_ops.vcpu_block = NULL;
-d->arch.hvm_domain.pi_ops.switch_from = NULL;
-d->arch.hvm_domain.pi_ops.do_resume = NULL;
+d->arch.hvm_domain.pi_ops.flags = PI_CSW_TO;
for_each_vcpu ( d, v )
vmx_pi_unblock_vcpu(v);
@@ -934,8 +935,8 @@ static void vmx_ctxt_switch_from(struct
vmx_restore_host_msrs();
vmx_save_dr(v);
-if ( v->domain->arch.hvm_domain.pi_ops.switch_from )
-v->domain->arch.hvm_domain.pi_ops.switch_from(v);
+if ( v->domain->arch.hvm_domain.pi_ops.flags & PI_CSW_FROM )
+vmx_pi_switch_from(v);
}
static void vmx_ctxt_switch_to(struct vcpu *v)
@@ -943,8 +944,8 @@ static void vmx_ctxt_switch_to(struct vc
vmx_restore_guest_msrs(v);
vmx_restore_dr(v);
-if ( v->domain->arch.hvm_domain.pi_ops.switch_to )
-v->domain->arch.hvm_domain.pi_ops.switch_to(v);
+if ( v->domain->arch.hvm_domain.pi_ops.flags & PI_CSW_TO )
+vmx_pi_switch_to(v);
}
@@ -4330,8 +4331,8 @@ bool vmx_vmenter_helper(const struct cpu
if ( nestedhvm_vcpu_in_guestmode(curr) && vcpu_nestedhvm(curr).stale_np2m
)
return false;
-if ( curr->domain->arch.hvm_domain.pi_ops.do_resume )
-curr->domain->arch.hvm_domain.pi_ops.do_resume(curr);
+if ( curr->domain->arch.hvm_domain.pi_ops.vcpu_block )
+vmx_pi_do_resume(curr);
if ( !cpu_has_vmx_vpid )
goto out;
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -80,20 +80,13 @@ struct hvm_ioreq_server {
* and actually has a physical device assigned .
*/
struct hvm_pi_ops {
-/* Hook into ctx_switch_from. */
-void (*switch_from)(struct vcpu *v);
-
-/* Hook into ctx_switch_to. */
-void (*switch_to)(struct vcpu *v);
+unsigned int flags;
/*
* Hook into arch_vcpu_block(), which is called
* from vcpu_block() and vcpu_do_poll().
*/
void (*vcpu_block)(struct vcpu *);
-
-/* Hook into the vmentry path. */
-void (*do_resume)(struct vcpu *v);
};
#define MAX_NR_IOREQ_SERVERS 8
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] x86/alternatives: fully leverage automatic NOP filling
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 inclusions in the two
> remaining C files needing them.
>
> While touching it also move the CR4_PV32_RESTORE definition out of the
> SMAP-specific conditional into a more general one.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 00/12] x86: indirect call overhead reduction
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 hardware details, and hence the pointers used never
change once set. Here we can use alternatives patching to get rid of
the indirection.
From patch 2 onwards dependencies exist on earlier, yet to be reviewed
patches ("x86/alternatives: fully leverage automatic NOP filling" as well
as the "x86: improve PDX <-> PFN and alike translations" series at the
very least). I nevertheless wanted to enable a first round of review of
the series, the more that some of the patches (not just initial ones)
could perhaps be taken irrespective of those dependencies. The first
two of the three genapic patches, otoh, are entirely independent and
could go in right away afaict if they were ack-ed.
Further areas where indirect calls could be eliminated (and that I've put
on my todo list in case the general concept here is deemed reasonable)
are IOMMU, vPMU, and XSM. For some of these, the ARM side would
need dealing with as well - I'm not sure whether replacing indirect calls
by direct ones is worthwhile there as well; if not, the wrappers would
simply need to become function invocations in the ARM case (as was
already asked for in the IOMMU case).
01: VMX: reduce number of posted-interrupt hooks
02: x86/alternatives: allow using assembler macros in favor of C ones
03: x86: infrastructure to allow converting certain indirect calls to direct
ones
04: x86/HVM: patch indirect calls through hvm_funcs to direct ones
05: x86/HVM: patch vINTR indirect calls through hvm_funcs to direct ones
06: x86: patch ctxt_switch_masking() indirect call to direct one
07: x86/genapic: drop .target_cpus() hook
08: x86/genapic: remove indirection from genapic hook accesses
09: x86/genapic: patch indirect calls to direct ones
10: x86/cpuidle: patch some indirect calls to direct ones
11: cpufreq: convert to a single post-init driver (hooks) instance
12: cpufreq: patch target() indirect call to direct one
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 3/3] x86: reduce "visibility" of spec_ctrl_asm.h
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: Jan Beulich Acked-by: Andrew Cooper --- a/xen/include/asm-x86/asm_defns.h +++ b/xen/include/asm-x86/asm_defns.h @@ -326,6 +326,8 @@ static always_inline void stac(void) "call cr4_pv32_restore", X86_FEATURE_XEN_SMEP, \ "call cr4_pv32_restore", X86_FEATURE_XEN_SMAP +#include + #endif #ifdef CONFIG_PERF_COUNTERS @@ -368,6 +370,4 @@ static always_inline void stac(void) 4: .p2align 2; \ .popsection -#include - #endif /* __X86_ASM_DEFNS_H__ */ --- a/xen/include/asm-x86/spec_ctrl.h +++ b/xen/include/asm-x86/spec_ctrl.h @@ -20,6 +20,13 @@ #ifndef __X86_SPEC_CTRL_H__ #define __X86_SPEC_CTRL_H__ +/* Encoding of cpuinfo.spec_ctrl_flags */ +#define SCF_use_shadow (1 << 0) +#define SCF_ist_wrmsr (1 << 1) +#define SCF_ist_rsb(1 << 2) + +#ifndef __ASSEMBLY__ + #include #include #include @@ -91,6 +98,7 @@ static always_inline void spec_ctrl_exit :: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" ); } +#endif /* __ASSEMBLY__ */ #endif /* !__X86_SPEC_CTRL_H__ */ /* --- a/xen/include/asm-x86/spec_ctrl_asm.h +++ b/xen/include/asm-x86/spec_ctrl_asm.h @@ -20,13 +20,9 @@ #ifndef __X86_SPEC_CTRL_ASM_H__ #define __X86_SPEC_CTRL_ASM_H__ -/* Encoding of cpuinfo.spec_ctrl_flags */ -#define SCF_use_shadow (1 << 0) -#define SCF_ist_wrmsr (1 << 1) -#define SCF_ist_rsb(1 << 2) - #ifdef __ASSEMBLY__ #include +#include /* * Saving and restoring MSR_SPEC_CTRL state is a little tricky. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/3] x86: move quoting of __ASM_{STAC,CLAC}
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
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -189,26 +189,33 @@ void ret_from_intr(void);
#endif
/* "Raw" instruction opcodes */
-#define __ASM_CLAC .byte 0x0f,0x01,0xca
-#define __ASM_STAC .byte 0x0f,0x01,0xcb
+#define __ASM_CLAC ".byte 0x0f,0x01,0xca"
+#define __ASM_STAC ".byte 0x0f,0x01,0xcb"
#ifdef __ASSEMBLY__
-#define ASM_STAC ALTERNATIVE "", __stringify(__ASM_STAC), X86_FEATURE_XEN_SMAP
-#define ASM_CLAC ALTERNATIVE "", __stringify(__ASM_CLAC), X86_FEATURE_XEN_SMAP
+.macro ASM_STAC
+ALTERNATIVE "", __ASM_STAC, X86_FEATURE_XEN_SMAP
+.endm
+.macro ASM_CLAC
+ALTERNATIVE "", __ASM_CLAC, X86_FEATURE_XEN_SMAP
+.endm
#else
static always_inline void clac(void)
{
/* Note: a barrier is implicit in alternative() */
-alternative("", __stringify(__ASM_CLAC), X86_FEATURE_XEN_SMAP);
+alternative("", __ASM_CLAC, X86_FEATURE_XEN_SMAP);
}
static always_inline void stac(void)
{
/* Note: a barrier is implicit in alternative() */
-alternative("", __stringify(__ASM_STAC), X86_FEATURE_XEN_SMAP);
+alternative("", __ASM_STAC, X86_FEATURE_XEN_SMAP);
}
#endif
+#undef __ASM_STAC
+#undef __ASM_CLAC
+
#ifdef __ASSEMBLY__
.macro SAVE_ALL op, compat=0
.ifeqs "\op", "CLAC"
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/3] x86/alternatives: fully leverage automatic NOP filling
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 them.
While touching it also move the CR4_PV32_RESTORE definition out of the
SMAP-specific conditional into a more general one.
Signed-off-by: Jan Beulich
---
v3: Re-base.
v2: Re-base.
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#define MAX_PATCH_LEN (255-1)
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -207,7 +208,7 @@ unsigned int flush_area_local(const void
c->x86_clflush_size && c->x86_cache_size && sz &&
((sz >> 10) < c->x86_cache_size) )
{
-alternative(ASM_NOP3, "sfence", X86_FEATURE_CLFLUSHOPT);
+alternative("", "sfence", X86_FEATURE_CLFLUSHOPT);
for ( i = 0; i < sz; i += c->x86_clflush_size )
alternative_input(".byte " __stringify(NOP_DS_PREFIX) ";"
" clflush %0",
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -193,30 +193,19 @@ void ret_from_intr(void);
#define __ASM_STAC .byte 0x0f,0x01,0xcb
#ifdef __ASSEMBLY__
-#define ASM_STAC\
-ALTERNATIVE __stringify(ASM_NOP3), \
-__stringify(__ASM_STAC), X86_FEATURE_XEN_SMAP
-
-#define ASM_CLAC\
-ALTERNATIVE __stringify(ASM_NOP3), \
-__stringify(__ASM_CLAC), X86_FEATURE_XEN_SMAP
-
-#define CR4_PV32_RESTORE\
-ALTERNATIVE_2 __stringify(ASM_NOP5),\
-"call cr4_pv32_restore", X86_FEATURE_XEN_SMEP, \
-"call cr4_pv32_restore", X86_FEATURE_XEN_SMAP
-
+#define ASM_STAC ALTERNATIVE "", __stringify(__ASM_STAC), X86_FEATURE_XEN_SMAP
+#define ASM_CLAC ALTERNATIVE "", __stringify(__ASM_CLAC), X86_FEATURE_XEN_SMAP
#else
static always_inline void clac(void)
{
/* Note: a barrier is implicit in alternative() */
-alternative(ASM_NOP3, __stringify(__ASM_CLAC), X86_FEATURE_XEN_SMAP);
+alternative("", __stringify(__ASM_CLAC), X86_FEATURE_XEN_SMAP);
}
static always_inline void stac(void)
{
/* Note: a barrier is implicit in alternative() */
-alternative(ASM_NOP3, __stringify(__ASM_STAC), X86_FEATURE_XEN_SMAP);
+alternative("", __stringify(__ASM_STAC), X86_FEATURE_XEN_SMAP);
}
#endif
@@ -325,6 +314,11 @@ static always_inline void stac(void)
subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp
.endm
+#define CR4_PV32_RESTORE \
+ALTERNATIVE_2 "", \
+"call cr4_pv32_restore", X86_FEATURE_XEN_SMEP, \
+"call cr4_pv32_restore", X86_FEATURE_XEN_SMAP
+
#endif
#ifdef CONFIG_PERF_COUNTERS
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -72,7 +72,7 @@ static always_inline void spec_ctrl_ente
barrier();
info->spec_ctrl_flags |= SCF_use_shadow;
barrier();
-asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_SC_MSR_IDLE)
+asm volatile ( ALTERNATIVE("", "wrmsr", X86_FEATURE_SC_MSR_IDLE)
:: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" );
}
@@ -87,7 +87,7 @@ static always_inline void spec_ctrl_exit
*/
info->spec_ctrl_flags &= ~SCF_use_shadow;
barrier();
-asm volatile ( ALTERNATIVE(ASM_NOP3, "wrmsr", X86_FEATURE_SC_MSR_IDLE)
+asm volatile ( ALTERNATIVE("", "wrmsr", X86_FEATURE_SC_MSR_IDLE)
:: "a" (val), "c" (MSR_SPEC_CTRL), "d" (0) : "memory" );
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/3] x86: assorted assembly related cleanup
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/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: drop NO_XPTI synthetic feature
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-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86: drop NO_XPTI synthetic feature
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: Wrap frequently to stress-test the wrap logic. */
#ifdef NDEBUG
@@ -180,7 +181,7 @@ unsigned int flush_area_local(const void
*/
invpcid_flush_one(PCID_PV_PRIV, addr);
invpcid_flush_one(PCID_PV_USER, addr);
-if ( !cpu_has_no_xpti )
+if ( opt_xpti )
{
invpcid_flush_one(PCID_PV_PRIV | PCID_PV_XPTI, addr);
invpcid_flush_one(PCID_PV_USER | PCID_PV_XPTI, addr);
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -789,7 +789,7 @@ static int setup_cpu_root_pgt(unsigned i
unsigned int off;
int rc;
-if ( cpu_has_no_xpti )
+if ( !opt_xpti )
return 0;
rpt = alloc_xen_pagetable();
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -865,11 +865,6 @@ void __init init_speculation_mitigations
if ( opt_xpti == -1 )
xpti_init_default(caps);
-if ( opt_xpti == 0 )
-setup_force_cpu_cap(X86_FEATURE_NO_XPTI);
-else
-setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
-
l1tf_calculations(caps);
/*
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -111,7 +111,6 @@
#define cpu_has_cpuid_faulting boot_cpu_has(X86_FEATURE_CPUID_FAULTING)
#define cpu_has_aperfmperf boot_cpu_has(X86_FEATURE_APERFMPERF)
#define cpu_has_lfence_dispatch boot_cpu_has(X86_FEATURE_LFENCE_DISPATCH)
-#define cpu_has_no_xpti boot_cpu_has(X86_FEATURE_NO_XPTI)
#define cpu_has_xen_lbr boot_cpu_has(X86_FEATURE_XEN_LBR)
enum _cache_type {
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -30,6 +30,5 @@ XEN_CPUFEATURE(SC_MSR_PV, (FSCAPIN
XEN_CPUFEATURE(SC_MSR_HVM, (FSCAPINTS+0)*32+17) /* MSR_SPEC_CTRL used by
Xen for HVM */
XEN_CPUFEATURE(SC_RSB_PV, (FSCAPINTS+0)*32+18) /* RSB overwrite needed
for PV */
XEN_CPUFEATURE(SC_RSB_HVM, (FSCAPINTS+0)*32+19) /* RSB overwrite needed
for HVM */
-XEN_CPUFEATURE(NO_XPTI, (FSCAPINTS+0)*32+20) /* XPTI mitigation not in
use */
XEN_CPUFEATURE(SC_MSR_IDLE, (FSCAPINTS+0)*32+21) /* (SC_MSR_PV ||
SC_MSR_HVM) && default_xen_spec_ctrl */
XEN_CPUFEATURE(XEN_LBR, (FSCAPINTS+0)*32+22) /* Xen uses
MSR_DEBUGCTL.LBR */
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: re-arrange get_page_from_le() vs pv_l1tf_check_le
>>> 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() call pv_l1tf_check_l[234]e(), but get_page_from_l1e() in the same situation. Instead alloc_l1_table() does. >> 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 rid of. >> >> Introduce local variables holding the page table entries processed, and >> use them throughout the loop bodies instead of re-reading them from the >> page table several times. >> >> Signed-off-by: Jan Beulich > > With at least the above query resolved, Reviewed-by: Andrew Cooper > , but a style recommendation. Thanks, but please let me know if the above clarifies this. >> @@ -1396,8 +1369,7 @@ static int alloc_l1_table(struct page_in >> if ( ret ) >> goto out; >> } >> - >> -switch ( ret = get_page_from_l1e(pl1e[i], d, d) ) >> +else switch ( ret = get_page_from_l1e(pl1e[i], d, d) ) > > else switch isn't a usual construct (here and in ptwr_emulated_update). > I was expecting the misleading indentation warning to trigger, but GCC > 8.2 does appear to be happy. Presumably because then it would also trigger for "else if". > Still, for code clarity, I'd suggest adding braces to the and indenting > the switch statement. At first I meant to do so, then decided against because of the extra code churn in both places where I've chosen this approach (also making looking at the patch itself less difficult). Would you be okay with the re-indentation done in a separate follow-up patch? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/alt: Fix build when CONFIG_LIVEPATCH is disabled
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 directive. > > > > When CONFIG_LIVEPATCH is compiled out, alternative.o is expected to be a > > fully > > init module, and toolchain_nops_are_ideal trips the build system check: > > > > Error: size of alternative.o:.data.read_mostly is 0x01 > > /local/xen.git/xen/Rules.mk:206: recipe for target 'alternative.init.o' > > failed > > make[3]: *** [alternative.init.o] Error 12 > > > > Introduce init_or_livepatch_read_mostly and switch the annotation for > > toolchain_nops_are_ideal. > > > > Reported-by: Olaf Hering > > Signed-off-by: Andrew Cooper > > Reviewed-by: Wei Liu Reviewed-by: Konrad Rzeszutek Wilk Thank you! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/7] x86/vtx: Rename arch_vmx_struct to vmx_vcpu
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 the other similar structures.
> > What other similar structures do you have in mind?
>
> Most relevantly, {vmx,svm}_domain, but {pv,hvm}_{domain,vcpu} as well.
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: re-arrange get_page_from_le() vs pv_l1tf_check_le
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 return value > meaning of the higher level ones can also be got rid of. > > Introduce local variables holding the page table entries processed, and > use them throughout the loop bodies instead of re-reading them from the > page table several times. > > Signed-off-by: Jan Beulich With at least the above query resolved, Reviewed-by: Andrew Cooper , but a style recommendation. > @@ -1396,8 +1369,7 @@ static int alloc_l1_table(struct page_in > if ( ret ) > goto out; > } > - > -switch ( ret = get_page_from_l1e(pl1e[i], d, d) ) > +else switch ( ret = get_page_from_l1e(pl1e[i], d, d) ) else switch isn't a usual construct (here and in ptwr_emulated_update). I was expecting the misleading indentation warning to trigger, but GCC 8.2 does appear to be happy. Still, for code clarity, I'd suggest adding braces to the and indenting the switch statement. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/alt: Fix build when CONFIG_LIVEPATCH is disabled
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 expected to be a fully > init module, and toolchain_nops_are_ideal trips the build system check: > > Error: size of alternative.o:.data.read_mostly is 0x01 > /local/xen.git/xen/Rules.mk:206: recipe for target 'alternative.init.o' > failed > make[3]: *** [alternative.init.o] Error 12 > > Introduce init_or_livepatch_read_mostly and switch the annotation for > toolchain_nops_are_ideal. > > Reported-by: Olaf Hering > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: fix "xpti=" and "pv-l1tf=" yet again
>>> 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 result is consistent with other options.
>
> As with spec-ctrl, if someone wants to start making fine-grain control,
> they should specify everything. There is a reason why the
>
> **WARNING: Any use of this option may interfere with heuristics. Use
> with extreme care.**
>
> disclaimer exists.
As said ...
>> In particular, the presence
>> of "xpti=" alone on the command line means nothing as to which
>> default is to be overridden; "xpti=no-dom0" ought to have no effect
>> for DomU-s (and vice versa), as this is distinct from both
>> "xpti=no-dom0,domu" and "xpti=no-dom0,no-domu".
... here, the current behavior is pretty counterintuitive. I'm also
curious to know how this is "consistent with other options" - can
you give two or three examples at least?
>> Here as well as for "pv-l1tf=" I think there's no way around tracking
>> the "use default" state separately for Dom0 and DomU-s. Introduce
>> individual bits for this, and convert the variables' types (back) to
>> uint8_t.
>
> The code below is getting unmanageably complicated. Given that its all
> slowpath operations, I think switching to 4 separate int8_t's would be
> better than trying to multiplex several tristates into the same byte.
> It would also remove all of the constants.
I can do that; it simply seemed more intrusive a change that way.
>> Additionally the earlier change claimed to have got rid of the
>> 'parameter "xpti" has invalid value "", rc=-22!' log message for "xpti"
>> alone on the command line, which wasn't the case (the option took effect
>> nevertheless). Fix this as well.
>
> The earlier change did do what the patch claimed, to the best of my
> knowledge. Can you explain what is apparently still broken, because its
> not clear from this description?
The earlier commit claims the log message went away, which is not
the case according to the testing that I had done with various
option combinations while putting together this change. Hence this
-else
+else if ( *s )
rc = -EINVAL;
break;
change in both of the handlers
>> Finally also support a "default" sub-option for "pv-l1tf=", just like
>> "xpti=" does.
>
> No. Having "default" was a mistake for xpti= I would have objected to
> if I'd noticed it.
>
> The default is not specifying the option in the first place.
> "foo=default" is entirely redundant,
It is not. I've said so a number of times before: You need a way
to go back to the default when you want to override a stored
portion of the command line that you can't edit while booting (as
is minimally the case for xen.efi, which takes the command line
out of a config file).
>and worse, in combination with your
> "Make "spec-ctrl=no" a global disable of all mitigations" patch:
>
> "spec-ctrl=0 $FOO=default" and
> "$FOO=default spec-ctrl=0"
>
> now result in different things happening.
And validly so: Order of options matters.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/2] x86: report use of PCID together with reporting XPTI status
>>> 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. That's all I need for my addition, but prior to this the header wasn't usable without first having included some other headers. get_pcid_bits() de-references struct vcpu, so sched.h _is_ needed (and should have been there before). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
>>> 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_domctl_t)
>>> u_domctl)
>>>
>>> ret = -EINVAL;
>>> if ( (d == current->domain) || /* no domain_pause() */
>>> - (max > domain_max_vcpus(d)) )
>>> + (max != d->max_vcpus) ) /* max_vcpus set up in
>>> createdomain
>>> */
>>> break;
>>>
>>> -/* Until Xenoprof can dynamically grow its vcpu-s array... */
>>> -if ( d->xenoprof )
>>> -{
>>> -ret = -EAGAIN;
>>> -break;
>>> -}
>>> -
>>> /* Needed, for example, to ensure writable p.t. state is
>>> synced. */
>>> domain_pause(d);
>>>
>>> @@ -581,38 +574,8 @@ long
>>> do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>>> u_domctl)
>>> }
>>> }
>>>
>>> -/* We cannot reduce maximum VCPUs. */
>>> -ret = -EINVAL;
>>> -if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL)
>>> )xc_domain_max_vcpus
>>> -goto maxvcpu_out;
>>> -
>>> -/*
>>> - * For now don't allow increasing the vcpu count from a
>>> non-zero
>>> - * value: This code and all readers of d->vcpu would otherwise
>>> need
>>> - * to be converted to use RCU, but at present there's no tools
>>> side
>>> - * code path that would issue such a request.
>>> - */
>>> -ret = -EBUSY;
>>> -if ( (d->max_vcpus > 0) && (max > d->max_vcpus) )
>>> -goto maxvcpu_out;
>>> -
>>> ret = -ENOMEM;
>>> online = cpupool_domain_cpumask(d);
>>> -if ( max > d->max_vcpus )
>>> -{
>>> -struct vcpu **vcpus;
>>> -
>>> -BUG_ON(d->vcpu != NULL);
>>> -BUG_ON(d->max_vcpus != 0);
>>> -
>>> -if ( (vcpus = xzalloc_array(struct vcpu *, max)) == NULL )
>>> -goto maxvcpu_out;
>>> -
>>> -/* Install vcpu array /then/ update max_vcpus. */
>>> -d->vcpu = vcpus;
>>> -smp_wmb();
>>> -d->max_vcpus = max;
>>> -}
>>>
>>> for ( i = 0; i < max; i++ )
>>> {
>> With all of this dropped, I think the domctl should be renamed. By
>> dropping its "max" input at the same time, there would then also
>> no longer be a need to check that the value matches what was
>> stored during domain creation.
> I'm still looking to eventually delete the hypercall, but we need to be
> able to clean up all domain/vcpu allocations without calling
> complete_domain_destroy, or rearrange the entry logic so
> complete_domain_destroy() can be reused for a domain which isn't
> currently in the domlist.
>
> Unfortunately, I think this is going to be fairly complicated, I think.
Especially when we expect this to take some time, I think it would
be quite helpful for the domctl to actually say what it does until
then, rather than retaining its current (then misleading) name.
>>> Renaming the domctl means renaming xc_domain_max_vcpus(), and the
>>> python/ocaml stubs, the latter of which does have external users.
>> This is an option, but the libxc and higher layer functions could as well
>> be left alone, perhaps with a comment added to the function you name
>> explaining why its name doesn't match the domctl it uses.
>
> And what good will that do? You'll now have inconsistent naming, which
> is worse.
>
> Its either all or nothing, and there are several good reasons to not
> change everything. I definitely don't think renaming the infrastructure
> is a constructive use of my time, or anyone elses for that matter.
>
> I'm open to the idea of leaving a comment by the implementation of
> XEN_DOMCTL_max_vcpus: explaining its change in behaviour, but I think
> that the extent of what is reasonable to do here.
Well, I'll leave it to the other REST maintainers then.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/2] x86: report use of PCID together with reporting XPTI status
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 address spaces of 64-bit pv domains: > * > @@ -59,6 +61,8 @@ int pv_vcpu_initialise(struct vcpu *v); > void pv_domain_destroy(struct domain *d); > int pv_domain_initialise(struct domain *d); > > +bool xpti_pcid_enabled(void); > + > #else /* !CONFIG_PV */ > > #include > > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
