[Xen-devel] [libvirt test] 105805: regressions - FAIL
flight 105805 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/105805/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 105785 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105785 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105785 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105785 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass version targeted for testing: libvirt ec94e14b681a671776c8d7ca962d3d7ed5aca5b7 baseline version: libvirt 723fef99c0e29d1a327aaea4cef477609f6ccbc2 Last test of basis 105785 2017-02-14 04:20:10 Z1 days Testing same since 105805 2017-02-15 04:21:42 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Jim Fehlig Jiri Denemark Ján Tomko Tomáš Golembiovský jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopsfail build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairfail test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd 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,
Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display
On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote: On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote: Hi, Konrad! Thank you for reviewing this. On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote: On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This is the ABI for the two halves of a para-virtualized display driver. This protocol aims to provide a unified protocol which fits more sophisticated use-cases than a framebuffer device can handle. At the moment basic functionality is supported with the intention to extend: o multiple dynamically allocated/destroyed framebuffers o buffers of arbitrary sizes o better configuration options including multiple display support Note: existing fbif can be used together with displif running at the same time, e.g. on Linux one provides framebuffer and another DRM/KMS Future extensions to the existing protocol may include: o allow display/connector cloning o allow allocating objects other than display buffers o add planes/overlays support o support scaling o support rotation == Rationale for introducing this protocol instead of using the existing fbif: == 1. In/out event sizes o fbif - 40 octets o displif - 40 octets This is only the initial version of the displif protocol which means that there could be requests which will not fit (WRT introducing some GPU related functionality later on). In that case we cannot alter fbif sizes as we need to be backward compatible an will be forced to handle those apart of fbif. 2. Shared page Displif doesn't use anything like struct xenfb_page, but DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct xendispl_resp) which is a better and more common way. Output events use a shared page which only has in_cons and in_prod and all the rest is used for incoming events. Here struct xenfb_page could probably be used as is despite the fact that it only has a half of a page for incoming events which is only 50 events. (consider something like 60Hz display) 3. Amount of changes. fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE events, so it looks like it is easier to get fb support into displif .. would it make sense to reserve some of those values (2, 3) in the XENDISPL_OP_ values? So that if this happens there is a nice fit in there? Thought looking at the structure there is no easy way to 'overlay' the xenfb_out_event structure as it is missing the 'id'. I guess one can get creative. Or you could swap positions of 'id' and 'type'? And then it would fit much nicer? yeap, in order no one needs to be creative, why not explicitly define those? Anyways, it won't be possible to simply lay the structures from fbif on top of displif (different structure, size, workflow etc.), what is more that would give some room to find workarounds, rather than have well defined solution. BTW, there was an attempt [1] to update fbdev to meet modern application needs. If we decide to add FBDEV functionality into this protocol, then I can re-use already proven to work solution from [1] into DISPLIF, but defining structures and events to fit the current protocol. I was thinking that since the size of the structure is 64bytes you have enough space to jam in the old structures too. yes, I understand your intention Naturally the driver would need adjustments as it offsets of where this goes are all wrong. exactly What do you think? so, what is the decision? Options: 1) Leave the protocol as is, if need be it can be extended later 2) Implement something similar to [1] 3) Give room for workarounds and reserve XENDISPL_OP_XXX for what current fbif uses than vice versa. displif at the moment has 6 requests and 1 event, multiple connector support, etc. Changes since v2: * updated XenStore configuration template/pattern * added "Recovery flow" to state diagram description * renamed gref_directory_start to gref_directory * added missing "versions" and "version" string constants Changes since v1: * fixed xendispl_event_page padding size * added versioning support * explicitly define value types for XenStore fields * text decoration re-work * added offsets to ASCII box notation Changes since initial: * DRM changed to DISPL, protocol made generic * major re-work addressing issues raised for sndif Signed-off-by: Oleksandr Grytsov Signed-off-by: Oleksandr Andrushchenko --- xen/include/public/io/displif.h | 778 1 file changed, 778 insertions(+) create mode 100644 xen/include/public/io/displif.h diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h new file mode 100644 index ..849f27fe5f1d --- /dev/null +++ b/xen/include/public/io/displif.h @@ -0,0 +1,778 @@ +/**
Re: [Xen-devel] [PATCH 1/1] xen/arm: Add pl011 uart support in Xen for guest domains
Hi Konrad, Thanks for the feedback. On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 06, 2017 at 11:39:08PM +0530, Bhupinder Thakur wrote: >> As per "VM System Specification for ARM Processors", there is a requirement >> for Xen to support guest console >> over pl011 UART, which is SBSA compliant. The changes in this patch >> implement the pl011 emulation in Xen >> and a new pl011 console support in xenconsoled. > > Heya! > > Got a couple of pointers for this RFC patch. > > This patch should be broken up. That is the first patch > should be the one that brings in the HVM_PARAM changes along > with documentation on how this would work on non-ARM systems. Since this feature is ARM specific, there are two options: 1. Define the HVM params only for ARM and keep the code which is using these HVM params in the toolstack/xenconsoled under __arm__ flag 2. Define the HVM params independent of the architecture but essentially return 0/NULL on get of these HVM params for x86 architecture. The code which is using these HVM params can then check for the returned value and take the action accordingly. In this case, the code is architecture agnostic. Which is the preferred option? > The second patch would implement this in the generic > code (in xen/common/event_channel.c) - perhaps via an > secondary function that is NOP on x86 but not so on ARM? > > Then another patch that fleshes out the emulation code in > the hypervisor, then the one in console code, and lastly > in libxl to turn this on/off. > Is it preferable to keep the pl011 emulation feature under its own feature CONFIG flag so that it can be compiled off across Xen/toolstack/console? > > From a short glance I would recommend you also: > - Include a doc which explains how pl011 UART works, >or at least a link. > > - Remove the #if 0 > > - Rip out the debug printk code. > > - Fix the tab/spaces alignment to match the code > > - Don't hardcode paths. They should be gathered from >envionment variables (like the rest of xenconsoled does) > > - If you remove the VM_PARAM_MEMORY_EVENT_ you also need to >rev up the version field. > I will incorporate these review comments. > - Include a knob in libxl to define whether the guest has >this emulation enabled or not. And if it is disabled >then the code in hypervisor should not emulate it. > Since the guest is unaware whether it is using an emulated pl011, is it required to have a knob to enable/disable this feature? I am planning to add a new console type "pl011" in addition to "pv" and "serial" and user can connect to any of those consoles. So a guest, which has let us say both HVC and pl011 consoles enabled, user can connect to any of the consoles. > - Return code for MMIO shouldn't be 1, but rather the proper >#defines. > > - The vpl011_cons_intf_s looks very weird. It looks like it >is missing an design document as well? That is should there >be a header in include/xen/public/ file? > >Should vpl011.h be in include/xen/public/ ? If so you need >a different license for that file. > I will try to move this header file in the same folder where vpl011.c is. > Thanks! Regards, Bhupinder ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 105803: regressions - trouble: blocked/broken/fail/pass
flight 105803 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 host-build-prep fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail in 105795 REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-bootfail in 105795 REGR. vs. 59254 test-armhf-armhf-xl 6 xen-bootfail in 105795 REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-bootfail in 105795 REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-bootfail in 105795 REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-bootfail in 105795 REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail in 105795 REGR. vs. 59254 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail pass in 105795 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail pass in 105795 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-installfail REGR. vs. 59254 test-armhf-armhf-xl-rtds 6 xen-bootfail in 105795 REGR. vs. 59254 test-armhf-armhf-libvirt-raw 6 xen-boot fail in 105795 baseline untested test-armhf-armhf-xl-vhd 6 xen-boot fail in 105795 baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail in 105795 never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail in 105795 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linux747ae0a96f1a78b35c5a3d93ad37a16655e16340 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 587 days Failing since 59348 2015-07-10 04:24:05 Z 586 days 275 attempts Testing same since 105795 2017-02-14 15:48:07 Z0 days2 attempts 7580 people
[Xen-devel] [qemu-mainline baseline-only test] 68560: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 68560 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68560/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-amd 6 xen-boot fail REGR. vs. 68559 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 68559 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 68559 test-armhf-armhf-libvirt 15 guest-start/debian.repeat fail REGR. vs. 68559 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 68559 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail blocked in 68559 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 68559 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 68559 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68559 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-installfail like 68559 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 2 hosts-allocate broken never pass build-arm64-pvops 2 hosts-allocate broken never pass build-arm64-xsm 2 hosts-allocate broken never pass build-arm64-xsm 3 capture-logs broken never pass build-arm64 3 capture-logs broken never pass build-arm64-pvops 3 capture-logs broken never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuu5dae13cd71f0755a1395b5a4cde635b8a6ee3f58 baseline version: qemuuec7a9bd5bb2c46c60cc0ec9b9d9f2ce404226ec0 Last test of basis68559 2017-02-14 15:44:10 Z0 days Testing same since68560 2017-02-14 23:17:13 Z0 days1 attempts People who touched revisions under test: Peter Maydell Richard Henderson Stafford Horne jobs: build-amd64-xsm pass build-arm6
Re: [Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base
On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote: > The KVM segment_base function is confusing. This patch replaces integers > with appropriate flags, simplify constructs and add comments. It could pay to put this first in the series, but last is probably fine, too. > > Signed-off-by: Thomas Garnier > --- > Based on next-20170213 > --- > arch/x86/kvm/vmx.c | 26 ++ > 1 file changed, 18 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index 99167f20bc34..edb8326108dd 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -2062,25 +2062,35 @@ static unsigned long segment_base(u16 selector) > struct desc_struct *d; > unsigned long table_base; This should go away IMO. It should be struct desc_struct *table; > + table_base = get_current_gdt_rw_vaddr(); Then this can go away, too, and you can stop having the silly get_current_gdt_rw_vaddr() function at all. > + d = (struct desc_struct *)table_base + (selector >> 3); And this cast goes away too. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 105799: trouble: blocked/broken/fail/pass
flight 105799 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105799/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 3 host-install(3)broken REGR. vs. 105756 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105756 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105756 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105756 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105756 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105756 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105756 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105756 test-amd64-amd64-xl-rtds 9 debian-install fail like 105756 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass build-arm64-xsm 5 xen-buildfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen bdbc25b8722cc1e3921858530f8ac484892156d3 baseline version: xen 6f6d3b10ec8168e2a78cf385d89803397f116397 Last test of basis 105756 2017-02-13 01:58:50 Z1 days Failing since105766 2017-02-13 11:44:46 Z1 days5 attempts Testing same since 105799 2017-02-14 19:16:03 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Boris Ostrovsky Chao Gao Ian Jackson Jan Beulich Juergen Gross Kevin Tian Roger Pau Monne Roger Pau Monné Sergey Dyasli Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm
Re: [Xen-devel] [PATCH 20/28] ARM: vITS: handle MAPD command
On Mon, 30 Jan 2017, Andre Przywara wrote:
> The MAPD command maps a device by associating a memory region for
> storing ITTEs with a certain device ID.
> We just store the given guest physical address in the device table.
> We don't map the device tables permanently, as their alignment
> requirement is only 256 Bytes, thus making mapping of several tables
> complicated. We map the device tables on demand when we need them later.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/vgic-v3-its.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index e6523a3..5be40d8 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -289,6 +289,27 @@ static int its_handle_mapc(struct virt_its *its,
> uint64_t *cmdptr)
> return ret;
> }
>
> +static int its_handle_mapd(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +int size = its_cmd_get_size(cmdptr);
> +bool valid = its_cmd_get_validbit(cmdptr);
> +paddr_t itt_addr = its_cmd_mask_field(cmdptr, 2, 0, 52) & GENMASK(51, 8);
please see alpine.DEB.2.10.1611081649530.3491@sstabellini-ThinkPad-X260
> +if ( !its->dev_table )
> +return -1;
> +
> +spin_lock(&its->its_lock);
> +if ( valid )
> +its->dev_table[devid] = DEV_TABLE_ENTRY(itt_addr, size + 1);
> +else
> +its->dev_table[devid] = 0;
> +
> +spin_unlock(&its->its_lock);
> +
> +return 0;
> +}
> +
> #define ITS_CMD_BUFFER_SIZE(baser) baser) & 0xff) + 1) << 12)
>
> static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -318,6 +339,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct
> virt_its *its,
> case GITS_CMD_MAPC:
> its_handle_mapc(its, cmdptr);
> break;
> +case GITS_CMD_MAPD:
> +its_handle_mapd(its, cmdptr);
> + break;
> case GITS_CMD_SYNC:
> /* We handle ITS commands synchronously, so we ignore SYNC. */
> break;
> --
> 2.9.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 105795: regressions - FAIL
flight 105795 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105795/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-rtds 9 debian-installfail REGR. vs. 59254 test-armhf-armhf-libvirt-raw 6 xen-bootfail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linux747ae0a96f1a78b35c5a3d93ad37a16655e16340 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 586 days Failing since 59348 2015-07-10 04:24:05 Z 585 days 274 attempts Testing same since 105795 2017-02-14 15:48:07 Z0 days1 attempts 7580 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops
Re: [Xen-devel] [PATCH 17/28] ARM: vITS: handle CLEAR command
On Mon, 30 Jan 2017, Andre Przywara wrote:
> This introduces the ITS command handler for the CLEAR command, which
> clears the pending state of an LPI.
> This removes a not-yet injected, but already queued IRQ from a VCPU.
>
> Signed-off-by: Andre Przywara
Please see alpine.DEB.2.10.1611081608580.3491@sstabellini-ThinkPad-X260
> ---
> xen/arch/arm/vgic-v3-its.c | 35 +--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 982c51d..48eb924 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -129,8 +129,8 @@ static void put_devid_evid(struct virt_its *its, struct
> vits_itte *itte)
> * protect the ITTs with their less-than-page-size granularity.
> * Takes and drops the its_lock.
> */
> -bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
> - struct vcpu **vcpu, uint32_t *vlpi)
> +static bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
> + struct vcpu **vcpu, uint32_t *vlpi)
> {
> struct vits_itte *itte;
> int collid;
> @@ -214,6 +214,34 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
> #define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
> #define its_cmd_get_validbit(cmd) its_cmd_mask_field(cmd, 2, 63, 1)
>
> +static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
> +{
> +uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +uint32_t eventid = its_cmd_get_id(cmdptr);
> +struct pending_irq *pirq;
> +struct vcpu *vcpu;
> +uint32_t vlpi;
> +
> +if ( !read_itte(its, devid, eventid, &vcpu, &vlpi) )
> +return -1;
> +
> +/* Remove a pending, but not yet injected guest IRQ. */
> +pirq = lpi_to_pending(vcpu, vlpi, false);
> +if ( pirq )
> +{
> +clear_bit(GIC_IRQ_GUEST_QUEUED, &pirq->status);
> +gic_remove_from_queues(vcpu, vlpi);
> +
> +/* Mark this pending IRQ struct as availabe again. */
> +if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, &pirq->status) )
> +pirq->irq = 0;
> +}
> +
> +clear_bit(vlpi - LPI_OFFSET, vcpu->arch.vgic.pendtable);
> +
> +return 0;
> +}
> +
> #define ITS_CMD_BUFFER_SIZE(baser) baser) & 0xff) + 1) << 12)
>
> static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -234,6 +262,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct
> virt_its *its,
> cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
> switch (its_cmd_get_command(cmdptr))
> {
> +case GITS_CMD_CLEAR:
> +its_handle_clear(its, cmdptr);
> +break;
> case GITS_CMD_SYNC:
> /* We handle ITS commands synchronously, so we ignore SYNC. */
> break;
> --
> 2.9.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v2 14/26] ARM: vGICv3: introduce basic ITS emulation bits
On Thu, 22 Dec 2016, Andre Przywara wrote:
> Create a new file to hold the emulation code for the ITS widget.
> For now we emulate the memory mapped ITS registers and provide a stub
> to introduce the ITS command handling framework (but without actually
> emulating any commands at this time).
>
> Signed-off-by: Andre Przywara
Please see alpine.DEB.2.10.1611081507410.3491@sstabellini-ThinkPad-X260
> ---
> xen/arch/arm/Makefile | 1 +
> xen/arch/arm/vgic-its.c | 377
> ++
> xen/arch/arm/vgic-v3.c| 9 -
> xen/include/asm-arm/gic_v3_defs.h | 19 ++
> 4 files changed, 397 insertions(+), 9 deletions(-)
> create mode 100644 xen/arch/arm/vgic-its.c
>
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 80c2951..346454d 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -45,6 +45,7 @@ obj-y += traps.o
> obj-y += vgic.o
> obj-y += vgic-v2.o
> obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
> +obj-$(CONFIG_HAS_ITS) += vgic-its.o
> obj-y += vm_event.o
> obj-y += vtimer.o
> obj-y += vpsci.o
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> new file mode 100644
> index 000..e5e9ae4
> --- /dev/null
> +++ b/xen/arch/arm/vgic-its.c
> @@ -0,0 +1,377 @@
> +/*
> + * xen/arch/arm/vgic-its.c
> + *
> + * ARM Interrupt Translation Service (ITS) emulation
> + *
> + * Andre Przywara
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Data structure to describe a virtual ITS */
> +struct virt_its {
> +struct domain *d;
> +struct host_its *hw_its;
> +spinlock_t vcmd_lock; /* protects the virtual command buffer */
> +uint64_t cbaser;
> +uint64_t *cmdbuf;
> +int cwriter;
> +int creadr;
> +spinlock_t its_lock;/* protects the collection and device tables
> */
> +uint64_t baser0, baser1;
> +uint16_t *coll_table;
> +int max_collections;
> +uint64_t *dev_table;
> +int max_devices;
> +bool enabled;
> +};
> +
> +/* An Interrupt Translation Table Entry: this is indexed by a
> + * DeviceID/EventID pair and is located in guest memory.
> + */
> +struct vits_itte
> +{
> +uint32_t vlpi;
> +uint16_t collection;
> +};
> +
> +/**
> + * Functions that handle ITS commands *
> + **/
> +
> +static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
> + int word, int shift, int size)
> +{
> +return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
> +}
> +
> +#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0, 0, 8)
> +#define its_cmd_get_deviceid(cmd) its_cmd_mask_field(cmd, 0, 32, 32)
> +#define its_cmd_get_size(cmd) its_cmd_mask_field(cmd, 1, 0, 5)
> +#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1, 0, 32)
> +#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
> +#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2, 0, 16)
> +#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
> +#define its_cmd_get_validbit(cmd) its_cmd_mask_field(cmd, 2, 63, 1)
> +
> +#define ITS_CMD_BUFFER_SIZE(baser) baser) & 0xff) + 1) << 12)
> +
> +static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> +uint32_t writer)
> +{
> +uint64_t *cmdptr;
> +
> +if ( !its->cmdbuf )
> +return -1;
> +
> +if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
> +return -1;
> +
> +spin_lock(&its->vcmd_lock);
> +
> +while ( its->creadr != writer )
> +{
> +cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
> +switch (its_cmd_get_command(cmdptr))
> +{
> +case GITS_CMD_SYNC:
> +/* We handle ITS commands synchronously, so we ignore SYNC. */
> + break;
> +default:
> +gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS command %ld\n",
> + its_cmd_get_command(cmdptr));
> +break;
> +}
> +
> +its->creadr += ITS_CMD_SIZE;
> +if ( its->creadr == ITS_CMD_BUFFER_SIZE(its->cbaser) )
> +its->creadr = 0;
> +}
> +
Re: [Xen-devel] [PATCH 13/28] ARM: vGICv3: handle virtual LPI pending and property tables
On Mon, 30 Jan 2017, Andre Przywara wrote:
> Allow a guest to provide the address and size for the memory regions
> it has reserved for the GICv3 pending and property tables.
> We sanitise the various fields of the respective redistributor
> registers and map those pages into Xen's address space to have easy
> access.
>
> Signed-off-by: Andre Przywara
Please give a look at
alpine.DEB.2.10.1610281619240.9978@sstabellini-ThinkPad-X260
> xen/arch/arm/vgic-v3.c | 220
> +++
> xen/arch/arm/vgic.c | 4 +
> xen/include/asm-arm/domain.h | 8 +-
> xen/include/asm-arm/vgic.h | 24 -
> 4 files changed, 233 insertions(+), 23 deletions(-)
>
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index b0653c2..c6db2d7 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -20,12 +20,14 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -229,12 +231,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu
> *v, mmio_info_t *info,
> goto read_reserved;
>
> case VREG64(GICR_PROPBASER):
> -/* LPI's not implemented */
> -goto read_as_zero_64;
> +if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> +*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
> +return 1;
>
> case VREG64(GICR_PENDBASER):
> -/* LPI's not implemented */
> -goto read_as_zero_64;
> +if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> +*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
> +*r &= ~GICR_PENDBASER_PTZ; /* WO, reads as 0 */
> +return 1;
>
> case 0x0080:
> goto read_reserved;
> @@ -302,11 +307,6 @@ bad_width:
> domain_crash_synchronous();
> return 0;
>
> -read_as_zero_64:
> -if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> -*r = 0;
> -return 1;
> -
> read_as_zero_32:
> if ( dabt.size != DABT_WORD ) goto bad_width;
> *r = 0;
> @@ -331,11 +331,179 @@ read_unknown:
> return 1;
> }
>
> +static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
> +int field_shift,
> +uint64_t (*sanitise_fn)(uint64_t))
> +{
> +uint64_t field = (reg & field_mask) >> field_shift;
> +
> +field = sanitise_fn(field) << field_shift;
> +
> +return (reg & ~field_mask) | field;
> +}
> +
> +/* We want to avoid outer shareable. */
> +static uint64_t vgic_sanitise_shareability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_OuterShareable:
> +return GIC_BASER_InnerShareable;
> +default:
> +return field;
> +}
> +}
> +
> +/* Avoid any inner non-cacheable mapping. */
> +static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_CACHE_nCnB:
> +case GIC_BASER_CACHE_nC:
> +return GIC_BASER_CACHE_RaWb;
> +default:
> +return field;
> +}
> +}
> +
> +/* Non-cacheable or same-as-inner are OK. */
> +static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
> +{
> +switch (field) {
> +case GIC_BASER_CACHE_SameAsInner:
> +case GIC_BASER_CACHE_nC:
> +return field;
> +default:
> +return GIC_BASER_CACHE_nC;
> +}
> +}
> +
> +static uint64_t sanitize_propbaser(uint64_t reg)
> +{
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
> + GICR_PROPBASER_SHAREABILITY_SHIFT,
> + vgic_sanitise_shareability);
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
> + GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
> + vgic_sanitise_inner_cacheability);
> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
> + GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
> + vgic_sanitise_outer_cacheability);
> +
> +reg &= ~GICR_PROPBASER_RES0_MASK;
> +return reg;
> +}
> +
> +static uint64_t sanitize_pendbaser(uint64_t reg)
> +{
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
> + GICR_PENDBASER_SHAREABILITY_SHIFT,
> + vgic_sanitise_shareability);
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
> + GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
> + vgic_sanitise_inner_cacheability);
> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
> + GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
> + vgic_sanitise_outer_cacheability);
> +
> +reg &= ~GICR_PEND
Re: [Xen-devel] [PATCH 14/28] ARM: vGICv3: Handle disabled LPIs
On Mon, 30 Jan 2017, Andre Przywara wrote:
> If a guest disables an LPI, we do not forward this to the associated
> host LPI to avoid queueing commands to the host ITS command queue.
> So it may happen that an LPI fires nevertheless on the host. In this
> case we can bail out early, but have to save the pending state on the
> virtual side.
>
> Signed-off-by: Andre Przywara
Please see alpine.DEB.2.10.1701051422020.2866@sstabellini-ThinkPad-X260
> xen/arch/arm/gic-v3-lpi.c | 8
> xen/arch/arm/vgic-v3.c | 12
> xen/include/asm-arm/vgic.h | 6 ++
> 3 files changed, 26 insertions(+)
>
> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> index d270053..ade8b69 100644
> --- a/xen/arch/arm/gic-v3-lpi.c
> +++ b/xen/arch/arm/gic-v3-lpi.c
> @@ -124,6 +124,14 @@ void do_LPI(unsigned int lpi)
>
> put_domain(d);
>
> +/*
> + * We keep all host LPIs enabled, so check if it's disabled on the guest
> + * side and just record this LPI in the virtual pending table in this
> case.
> + * The guest picks it up once it gets enabled again.
> + */
> +if ( !vgic_can_inject_lpi(vcpu, hlpi.virt_lpi) )
> +return;
> +
> vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
> }
>
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index c6db2d7..de625bf 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -498,6 +498,18 @@ bool vgic_lpi_is_enabled(struct domain *d, uint32_t vlpi)
> return d->arch.vgic.proptable[vlpi - LPI_OFFSET] & LPI_PROP_ENABLED;
> }
>
> +bool vgic_can_inject_lpi(struct vcpu *vcpu, uint32_t vlpi)
> +{
> +if ( vlpi >= vcpu->domain->arch.vgic.nr_lpis )
> +return false;
> +
> +if ( vgic_lpi_is_enabled(vcpu->domain, vlpi) )
> +return true;
> +
> +set_bit(vlpi - LPI_OFFSET, vcpu->arch.vgic.pendtable);
> +return false;
> +}
> +
> static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
>uint32_t gicr_reg,
>register_t r)
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index a882fe8..e71b18b 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -323,6 +323,7 @@ int vgic_v3_init(struct domain *d, int *mmio_count);
> #ifdef CONFIG_HAS_GICV3
> extern int vgic_lpi_get_priority(struct domain *d, uint32_t vlpi);
> extern bool vgic_lpi_is_enabled(struct domain *d, uint32_t vlpi);
> +extern bool vgic_can_inject_lpi(struct vcpu *v, uint32_t vlpi);
> #else
> static inline int vgic_lpi_get_priority(struct domain *d, uint32_t vlpi)
> {
> @@ -333,6 +334,11 @@ static inline bool vgic_lpi_is_enabled(struct domain *d,
> uint32_t vlpi)
> {
> return false;
> }
> +
> +static inline bool vgic_can_inject_lpi(struct vcpu *v, uint32_t vlpi)
> +{
> +return false;
> +}
> #endif
>
> extern int domain_vgic_register(struct domain *d, int *mmio_count);
> --
> 2.9.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0
On 14/02/2017 22:47, Tamas K Lengyel wrote: > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) XSM Framework v1.0.0 initialized > (XEN) Flask: 128 avtab hash slots, 394 rules. > (XEN) Flask: 128 avtab hash slots, 394 rules. > (XEN) Flask: 5 users, 3 roles, 43 types, 2 bools > (XEN) Flask: 12 classes, 394 rules > (XEN) Flask: Starting in enforcing mode. > (XEN) xstate: size: 0x340 and states: 0x7 > (XEN) Intel machine check reporting enabled > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Platform timer is 14.318MHz HPET > (XEN) Detected 3392.326 MHz processor. > (XEN) Initing memory sharing. > (XEN) alt table 82d0802d3f38 -> 82d0802d5564 > (XEN) PCI: MCFG configuration 0: base e000 segment buses 00 - 3f > (XEN) PCI: Not using MCFG for segment bus 00-3f > (XEN) > (XEN) > (XEN) Panic on CPU 0: > (XEN) Couldn't enable IOMMU and iommu=required/force > (XEN) > (XEN) > (XEN) Reboot in five seconds... > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. > > As seen in the command line iommu is not set to required or forced. > Yet Xen thinks it is set to required/force. Has anyone else run into > this issue? This area is a rats nest :( The problem is that the APIC setup has chosen to use the x2apic_cluster driver, which in the Xen code depends on x2APIC, which depends on interrupt remapping, which depends on an IOMMU. (I could have sworn we fixed this before), but the bug is that the APIC setup shouldn't choose any of the x2apic modes if there isn't an interrupt remapping capable IOMMU. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 12/28] ARM: GICv3: enable ITS and LPIs on the host
On Mon, 30 Jan 2017, Andre Przywara wrote:
> Now that the host part of the ITS code is in place, we can enable the
> ITS and also LPIs on each redistributor to get the show rolling.
> At this point there would be no LPIs mapped, as guests don't know about
> the ITS yet.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/gic-v3-its.c | 34 --
> xen/arch/arm/gic-v3.c | 19 +++
> 2 files changed, 51 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index f073ab5..2a7093f 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -62,6 +62,28 @@ static int its_send_command(struct host_its *hw_its, const
> void *its_cmd)
> return 0;
> }
>
> +/* Wait for an ITS to finish processing all commands. */
> +static int gicv3_its_wait_commands(struct host_its *hw_its)
> +{
> +s_time_t deadline = NOW() + MILLISECS(1000);
> +uint64_t readp, writep;
> +
> +do {
> +spin_lock(&hw_its->cmd_lock);
> +readp = readq_relaxed(hw_its->its_base + GITS_CREADR) & BUFPTR_MASK;
> +writep = readq_relaxed(hw_its->its_base + GITS_CWRITER) &
> BUFPTR_MASK;
> +spin_unlock(&hw_its->cmd_lock);
> +
> +if ( readp == writep )
> +return 0;
> +
> +cpu_relax();
> +udelay(1);
> +} while ( NOW() <= deadline );
> +
> +return -ETIMEDOUT;
> +}
I hope we won't have anything like this after the initialization is
completed. In fact, if this is called only at initialization, do we need
the spin lock?
> static uint64_t encode_rdbase(struct host_its *hw_its, int cpu, uint64_t reg)
> {
> reg &= ~GENMASK(51, 16);
> @@ -161,6 +183,10 @@ int gicv3_its_setup_collection(int cpu)
> ret = its_send_cmd_sync(its, cpu);
> if ( ret )
> return ret;
> +
> +ret = gicv3_its_wait_commands(its);
> +if ( ret )
> +return ret;
Just do
return gicv3_its_wait_commands(its);
as for the other cases
> }
>
> return 0;
> @@ -367,6 +393,10 @@ int gicv3_its_init(struct host_its *hw_its)
> return -ENOMEM;
> writeq_relaxed(0, hw_its->its_base + GITS_CWRITER);
>
> +/* Now enable interrupt translation and command processing on that ITS.
> */
> +reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
> +writel_relaxed(reg | GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
> +
> /*
> * We issue the collection mapping calls upon initialising the
> * redistributors, which for CPU 0 happens before the ITS gets
> initialised
> @@ -381,7 +411,7 @@ int gicv3_its_init(struct host_its *hw_its)
> if ( ret )
> return ret;
>
> -return 0;
> +return gicv3_its_wait_commands(hw_its);
> }
>
> static void remove_mapped_guest_device(struct its_devices *dev)
> @@ -424,7 +454,7 @@ int gicv3_its_map_host_events(struct host_its *its,
> if ( ret )
> return ret;
>
> -return 0;
> +return gicv3_its_wait_commands(its);
> }
>
> int gicv3_its_map_guest_device(struct domain *d, int host_devid,
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 5f825a6..23cf33d 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -647,6 +647,21 @@ static int gicv3_rdist_init_lpis(void __iomem *
> rdist_base)
> return gicv3_its_setup_collection(smp_processor_id());
> }
>
> +/* Enable LPIs on this redistributor (only useful when the host has an ITS.
> */
> +static bool gicv3_enable_lpis(void)
> +{
> +uint32_t val;
> +
> +val = readl_relaxed(GICD_RDIST_BASE + GICR_TYPER);
> +if ( !(val & GICR_TYPER_PLPIS) )
> +return false;
> +
> +val = readl_relaxed(GICD_RDIST_BASE + GICR_CTLR);
> +writel_relaxed(val | GICR_CTLR_ENABLE_LPIS, GICD_RDIST_BASE + GICR_CTLR);
> +
> +return true;
> +}
> +
> static int __init gicv3_populate_rdist(void)
> {
> int i;
> @@ -755,6 +770,10 @@ static int gicv3_cpu_init(void)
> if ( gicv3_enable_redist() )
> return -ENODEV;
>
> +/* If the host has any ITSes, enable LPIs now. */
> +if ( !list_empty(&host_its_list) )
> +gicv3_enable_lpis();
> +
> /* Set priority on PPI and SGI interrupts */
> priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI << 8 |
> GIC_PRI_IPI);
> --
> 2.9.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 105796: tolerable FAIL - PUSHED
flight 105796 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105796/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105787 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105787 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105787 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105787 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105787 test-amd64-amd64-xl-rtds 9 debian-install fail like 105787 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass build-arm64 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass version targeted for testing: qemuu5dae13cd71f0755a1395b5a4cde635b8a6ee3f58 baseline version: qemuuec7a9bd5bb2c46c60cc0ec9b9d9f2ce404226ec0 Last test of basis 105787 2017-02-14 10:14:42 Z0 days Testing same since 105796 2017-02-14 16:14:51 Z0 days1 attempts People who touched revisions under test: Peter Maydell Richard Henderson Stafford Horne jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386
[Xen-devel] Unable to boot Xen 4.8 with iommu=0
Hi all, I'm having some strange issues with Xen 4.8 when I try to boot with iommu disabled. (XEN) Xen version 4.8.0 (root@lan) (gcc (Debian 5.4.1-4) 5.4.1 20161202) debug=n Tue Feb 14 15:32:55 MST 2017 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.02~beta3-4 (XEN) Command line: placeholder dom0_mem=4096M,max:4096M dom0_max_vcpus=4 dom0_vcpus_pin=true hap_1gb=false hap_2mb=false altp2m=1 com1=115200,8n1,amt loglvl=all guest_loglvl=all console=com1 flask_enforcing=1 iommu=0 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 3 MBR signatures (XEN) Found 3 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 0008f000 (usable) (XEN) 0008f000 - 000a (reserved) (XEN) 000e - 0010 (reserved) (XEN) 0010 - 2000 (usable) (XEN) 2000 - 2020 (reserved) (XEN) 2020 - 4000 (usable) (XEN) 4000 - 4020 (reserved) (XEN) 4020 - 7a556000 (usable) (XEN) 7a556000 - 7a5a5000 (ACPI NVS) (XEN) 7a5a5000 - 7a5ae000 (ACPI data) (XEN) 7a5ae000 - 7a6a1000 (reserved) (XEN) 7a6a1000 - 7a6a3000 (usable) (XEN) 7a6a3000 - 7a8c2000 (reserved) (XEN) 7a8c2000 - 7a8c3000 (usable) (XEN) 7a8c3000 - 7a8d3000 (reserved) (XEN) 7a8d3000 - 7a8f1000 (ACPI NVS) (XEN) 7a8f1000 - 7a915000 (reserved) (XEN) 7a915000 - 7a958000 (ACPI NVS) (XEN) 7a958000 - 7ab78000 (reserved) (XEN) 7ab78000 - 7ad0 (usable) (XEN) 7ad0 - 7b00 (reserved) (XEN) 7b80 - 7fa0 (reserved) (XEN) fed1c000 - fed4 (reserved) (XEN) ff00 - 0001 (reserved) (XEN) 0001 - 00047e60 (usable) (XEN) ACPI: RSDP 000F0450, 0024 (r2 INTEL) (XEN) ACPI: XSDT 7A5A5070, 0064 (r1 INTEL DQ67SW1072009 AMI 10013) (XEN) ACPI: FACP 7A5ACB50, 00F4 (r4 INTEL DQ67SW1072009 AMI 10013) (XEN) ACPI: DSDT 7A5A5168, 79E1 (r2 INTEL DQ67SW 16 INTL 20051117) (XEN) ACPI: FACS 7A8D7F80, 0040 (XEN) ACPI: APIC 7A5ACC48, 0092 (r3 INTEL DQ67SW1072009 AMI 10013) (XEN) ACPI: TCPA 7A5ACCE0, 0032 (r2 INTEL DQ67SW 1 MSFT 113) (XEN) ACPI: SSDT 7A5ACD18, 01D6 (r1 INTEL DQ67SW 1 MSFT 301) (XEN) ACPI: MCFG 7A5ACEF0, 003C (r1 INTEL DQ67SW1072009 MSFT 97) (XEN) ACPI: HPET 7A5ACF30, 0038 (r1 INTEL DQ67SW1072009 AMI.4) (XEN) ACPI: ASF! 7A5ACF68, 00A0 (r32 INTEL DQ67SW 1 TFSMF4240) (XEN) ACPI: DMAR 7A5AD008, 00E8 (r1 INTEL DQ67SW 1 INTL1) (XEN) System RAM: 16264MB (16654784kB) (XEN) No NUMA configuration found (XEN) Faking a node at -00047e60 (XEN) Domain heap initialised (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 42 (0x2a), Stepping 7 (raw 000206a7) (XEN) found SMP MP-table at 000fda00 (XEN) DMI 2.6 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (32 bits) (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - 7a8d7f80/, using 32 (XEN) ACPI: wakeup_vec[7a8d7f8c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee0 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x00] address[0xfec0] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec0, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed0 (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) Switched to APIC driver x2apic_cluster. (XEN) XSM Framework v1.0.0 initialized (XEN) Flask: 128 avtab hash slots, 394 rules. (XEN) Flask: 128 avtab hash slots, 394 rules. (XEN) Flask: 5 users, 3 roles, 43 types, 2 bools (XEN) Flask: 12 classes, 394 rules (XEN) Flask: Starting in enforcing mode. (XEN) x
Re: [Xen-devel] [PATCH 2/2] x86: package up context switch hook pointers
On 02/14/2017 05:29 AM, Jan Beulich wrote: They're all solely dependent on guest type, so we don't need to repeat all the same four pointers in every vCPU control structure. Instead use static const structures, and store pointers to them in the domain control structure. Since touching it anyway, take the opportunity and move schedule_tail() into the only C file needing it. Signed-off-by: Jan Beulich Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/28] arm64: Dom0 ITS emulation
On Mon, 13 Feb 2017, Vijay Kilari wrote:
> Hi Andre,
>
> I tried your patch series on HW. Dom0 boots but no LPIs are coming to Dom0.
> So I made below patch to consider segment ID in generating devid,
> I see below panic from _xmalloc().
>
> Complete log is here
> http://pastebin.com/btythn2V
>
> diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
> index 6e02de4..72ffe9f 100644
> --- a/xen/arch/arm/physdev.c
> +++ b/xen/arch/arm/physdev.c
> @@ -17,6 +17,7 @@
> int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> struct physdev_manage_pci manage;
> + struct physdev_pci_device_add pci_add;
> u32 devid;
> int ret;
>
> @@ -33,6 +34,19 @@ int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> cmd ==
> PHYSDEVOP_manage_pci_add);
>
> return ret;
> + case PHYSDEVOP_pci_device_add:
> +if ( copy_from_guest(&pci_add, arg, 1) != 0 )
> +return -EFAULT;
> +devid = pci_add.seg << 16 | pci_add.bus << 8 | pci_add.devfn;
> +
> +printk("In %s calling gicv3_its_map_device for S: %d B:
> %d F:%d DEVID %u\n",
> +__func__, pci_add.seg,pci_add.bus, pci_add.devfn, devid);
> +/* Allocate an ITS device table with space for 32 MSIs */
> +ret = gicv3_its_map_guest_device(hardware_domain, devid, devid,
> 5,
> + cmd == PHYSDEVOP_pci_device_add);
> +
> +return ret;
> }
Hi Vijay, thanks for testing the series. Instead of implementing
PHYSDEVOP_pci_device_add here, could you call gicv3_its_map_guest_device
for each device statically from a Cavium specific platform file under
xen/arch/arm/platforms?
Once we'll have a clearer idea about how to implement which hypercalls,
we'll do this properly.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 68559: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 68559 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68559/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 68557 test-amd64-amd64-i386-pvgrub 9 debian-di-install fail REGR. vs. 68557 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 14 guest-saverestore fail REGR. vs. 68557 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 68557 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 68557 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68557 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-installfail like 68557 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2 hosts-allocate broken never pass build-arm64 2 hosts-allocate broken never pass build-arm64-xsm 2 hosts-allocate broken never pass build-arm64-pvops 3 capture-logs broken never pass build-arm64-xsm 3 capture-logs broken never pass build-arm64 3 capture-logs broken never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuuec7a9bd5bb2c46c60cc0ec9b9d9f2ce404226ec0 baseline version: qemuu305e6c8a2ff7a6e3f4942b50e853230f18eeb5a9 Last test of basis68557 2017-02-14 09:14:19 Z0 days Testing same since68559 2017-02-14 15:44:10 Z0 days1 attempts People who touched revisions under test: Amit Shah Ashijeet Acharya Dr. David Alan Gilbert Halil Pasic Li Zhijian Pavel Butsykin Peter Maydell zhanghailiang jobs: build-amd64-xsm pass build-arm64-xs
Re: [Xen-devel] [DOC v9] PV Calls protocol design
On Tue, 14 Feb 2017, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 13, 2017 at 11:46:40AM -0800, Stefano Stabellini wrote: > > Changes in v9: > > - specify max-page-order must be >= 1 > > - clarifications > > - add "Expanding the protocol" > > - add padding after out_error > > - add "Why ring.h is not needed" > > Reviewed-by: Konrad Rzeszutek Wilk Thanks! For your convenience: --- docs: add PV Calls Protocol Signed-off-by: Stefano Stabellini Reviewed-by: Konrad Rzeszutek Wilk diff --git a/docs/misc/pvcalls.markdown b/docs/misc/pvcalls.markdown new file mode 100644 index 000..d3f7f20 --- /dev/null +++ b/docs/misc/pvcalls.markdown @@ -0,0 +1,1092 @@ +# PV Calls Protocol version 1 + +## Glossary + +The following is a list of terms and definitions used in the Xen +community. If you are a Xen contributor you can skip this section. + +* PV + + Short for paravirtualized. + +* Dom0 + + First virtual machine that boots. In most configurations Dom0 is + privileged and has control over hardware devices, such as network + cards, graphic cards, etc. + +* DomU + + Regular unprivileged Xen virtual machine. + +* Domain + + A Xen virtual machine. Dom0 and all DomUs are all separate Xen + domains. + +* Guest + + Same as domain: a Xen virtual machine. + +* Frontend + + Each DomU has one or more paravirtualized frontend drivers to access + disks, network, console, graphics, etc. The presence of PV devices is + advertized on XenStore, a cross domain key-value database. Frontends + are similar in intent to the virtio drivers in Linux. + +* Backend + + A Xen paravirtualized backend typically runs in Dom0 and it is used to + export disks, network, console, graphics, etcs, to DomUs. Backends can + live both in kernel space and in userspace. For example xen-blkback + lives under drivers/block in the Linux kernel and xen_disk lives under + hw/block in QEMU. Paravirtualized backends are similar in intent to + virtio device emulators. + +* VMX and SVM + + On Intel processors, VMX is the CPU flag for VT-x, hardware + virtualization support. It corresponds to SVM on AMD processors. + + + +## Rationale + +PV Calls is a paravirtualized protocol that allows the implementation of +a set of POSIX functions in a different domain. The PV Calls frontend +sends POSIX function calls to the backend, which implements them and +returns a value to the frontend and acts on the function call. + +This version of the document covers networking function calls, such as +connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but +the protocol is meant to be easily extended to cover different sets of +calls. Unimplemented commands return ENOTSUP. + +PV Calls provide the following benefits: +* full visibility of the guest behavior on the backend domain, allowing + for inexpensive filtering and manipulation of any guest calls +* excellent performance + +Specifically, PV Calls for networking offer these advantages: +* guest networking works out of the box with VPNs, wireless networks and + any other complex configurations on the host +* guest services listen on ports bound directly to the backend domain IP + addresses +* localhost becomes a secure host wide network for inter-VMs + communications + + +## Design + +### Why Xen? + +PV Calls are part of an effort to create a secure runtime environment +for containers (Open Containers Initiative images to be precise). PV +Calls are based on Xen, although porting them to other hypervisors is +possible. Xen was chosen because of its security and isolation +properties and because it supports PV guests, a type of virtual machines +that does not require hardware virtualization extensions (VMX on Intel +processors and SVM on AMD processors). This is important because PV +Calls is meant for containers and containers are often run on top of +public cloud instances, which do not support nested VMX (or SVM) as of +today (early 2017). Xen PV guests are lightweight, minimalist, and do +not require machine emulation: all properties that make them a good fit +for this project. + +### Xenstore + +The frontend and the backend connect via [xenstore] to +exchange information. The toolstack creates front and back nodes with +state of [XenbusStateInitialising]. The protocol node name +is **pvcalls**. There can only be one PV Calls frontend per domain. + + Frontend XenBus Nodes + +version + Values: + + Protocol version, chosen among the ones supported by the backend + (see **versions** under [Backend XenBus Nodes]). Currently the + value must be "1". + +port + Values: + + The identifier of the Xen event channel used to signal activity + in the command ring. + +ring-ref + Values: + + The Xen grant reference granting permission for the backend to map + the sole page in a single page sized command ring. + + Backend XenBus Nodes + +versions + Values: + + List of comma separated protocol versions suppor
Re: [Xen-devel] [DOC v5] Xen transport for 9pfs
On Tue, 14 Feb 2017, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 13, 2017 at 11:47:26AM -0800, Stefano Stabellini wrote:
>
> Reviewed-by: Konrad Rzeszutek Wilk
Thank you! For your convenience:
---
docs: add Xen transport for 9pfs
Signed-off-by: Stefano Stabellini
Reviewed-by: Konrad Rzeszutek Wilk
diff --git a/docs/misc/9pfs.markdown b/docs/misc/9pfs.markdown
new file mode 100644
index 000..7f13831
--- /dev/null
+++ b/docs/misc/9pfs.markdown
@@ -0,0 +1,419 @@
+# Xen transport for 9pfs version 1
+
+## Background
+
+9pfs is a network filesystem protocol developed for Plan 9. 9pfs is very
+simple and describes a series of commands and responses. It is
+completely independent from the communication channels, in fact many
+clients and servers support multiple channels, usually called
+"transports". For example the Linux client supports tcp and unix
+sockets, fds, virtio and rdma.
+
+
+### 9pfs protocol
+
+This document won't cover the full 9pfs specification. Please refer to
+this [paper] and this [website] for a detailed description of it.
+However it is useful to know that each 9pfs request and response has the
+following header:
+
+struct header {
+ uint32_t size;
+ uint8_t id;
+ uint16_t tag;
+} __attribute__((packed));
+
+0 4 57
++-+--++
+| size |id|tag |
++-+--++
+
+- *size*
+The size of the request or response.
+
+- *id*
+The 9pfs request or response operation.
+
+- *tag*
+Unique id that identifies a specific request/response pair. It is used
+to multiplex operations on a single channel.
+
+It is possible to have multiple requests in-flight at any given time.
+
+
+## Rationale
+
+This document describes a Xen based transport for 9pfs, in the
+traditional PV frontend and backend format. The PV frontend is used by
+the client to send commands to the server. The PV backend is used by the
+9pfs server to receive commands from clients and send back responses.
+
+The transport protocol supports multiple rings up to the maximum
+supported by the backend. The size of every ring is also configurable
+and can span multiple pages, up to the maximum supported by the backend
+(although it cannot be more than 2MB). The design is to exploit
+parallelism at the vCPU level and support multiple outstanding requests
+simultaneously.
+
+This document does not cover the 9pfs client/server design or
+implementation, only the transport for it.
+
+
+## Xenstore
+
+The frontend and the backend connect via xenstore to exchange
+information. The toolstack creates front and back nodes with state
+[XenbusStateInitialising]. The protocol node name is **9pfs**.
+
+Multiple rings are supported for each frontend and backend connection.
+
+### Backend XenBus Nodes
+
+Backend specific properties, written by the backend, read by the
+frontend:
+
+versions
+ Values:
+
+ List of comma separated protocol versions supported by the backend.
+ For example "1,2,3". Currently the value is just "1", as there is
+ only one version. N.B.: this is the version of the Xen trasport
+ protocol, not the version of 9pfs supported by the server.
+
+max-rings
+ Values:
+
+ The maximum supported number of rings per frontend.
+
+max-ring-page-order
+ Values:
+
+ The maximum supported size of a memory allocation in units of
+ log2n(machine pages), e.g. 1 = 2 pages, 2 == 4 pages, etc. It
+ must be at least 1.
+
+Backend configuration nodes, written by the toolstack, read by the
+backend:
+
+path
+ Values:
+
+ Host filesystem path to share.
+
+tag
+ Values:
+
+ Alphanumeric tag that identifies the 9pfs share. The client needs
+ to know the tag to be able to mount it.
+
+security-model
+ Values: "none"
+
+ *none*: files are stored using the same credentials as they are
+ created on the guest (no user ownership squash or remap)
+ Only "none" is supported in this version of the protocol.
+
+### Frontend XenBus Nodes
+
+version
+ Values:
+
+ Protocol version, chosen among the ones supported by the backend
+ (see **versions** under [Backend XenBus Nodes]). Currently the
+ value must be "1".
+
+num-rings
+ Values:
+
+ Number of rings. It needs to be lower or equal to max-rings.
+
+event-channel- (event-channel-0, event-channel-1, etc)
+ Values:
+
+ The identifier of the Xen event channel used to signal activity
+ in the ring buffer. One for each ring.
+
+ring-ref (ring-ref0, ring-ref1, etc)
+ Values:
+
+ The Xen grant reference granting permission for the backend to
+ map a page with information to setup a share ring. One for each
Re: [Xen-devel] [PATCH 05/28] ARM: GICv3 ITS: map ITS command buffer
On Tue, 14 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 02/14/2017 12:59 AM, Stefano Stabellini wrote: > > On Mon, 30 Jan 2017, Andre Przywara wrote: > > > static int its_map_baser(void __iomem *basereg, uint64_t regc, int > > > nr_items) > > > @@ -150,6 +191,11 @@ int gicv3_its_init(struct host_its *hw_its) > > > } > > > } > > > > > > +hw_its->cmd_buf = its_map_cbaser(hw_its); > > > +if ( !hw_its->cmd_buf ) > > > +return -ENOMEM; > > > +writeq_relaxed(0, hw_its->its_base + GITS_CWRITER); > > > > Why this new write? > > This was requested by me. From the spec (8.19.5 in ARM IHI 0069C), the > reset value of GITS_CWRITER is unknown. So we have to reset the register > to 0 otherwise the ITS may try to read invalid command as soon as it has > been enabled. > > FWIW, GITS_CREADR was reset to 0 by the ITS when GITS_CBASER has > successfully been written (see 8.19.2). All right, thanks ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/28] ARM: GICv3: forward pending LPIs to guests
On Mon, 30 Jan 2017, Andre Przywara wrote:
> Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
> number to get this IRQ injected.
> Iterate our two-level LPI table to find this information quickly when
> the host takes an LPI. Call the existing injection function to let the
> GIC emulation deal with this interrupt.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/gic-v3-lpi.c | 41 +
> xen/arch/arm/gic.c| 6 --
> xen/include/asm-arm/irq.h | 8
> 3 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> index 8f6e7f3..d270053 100644
> --- a/xen/arch/arm/gic-v3-lpi.c
> +++ b/xen/arch/arm/gic-v3-lpi.c
> @@ -86,6 +86,47 @@ uint64_t gicv3_get_redist_address(int cpu, bool use_pta)
> return per_cpu(redist_id, cpu) << 16;
> }
>
> +/*
> + * Handle incoming LPIs, which are a bit special, because they are
> potentially
> + * numerous and also only get injected into guests. Treat them specially
> here,
> + * by just looking up their target vCPU and virtual LPI number and hand it
> + * over to the injection function.
> + */
> +void do_LPI(unsigned int lpi)
> +{
> +struct domain *d;
> +union host_lpi *hlpip, hlpi;
> +struct vcpu *vcpu;
> +
> +WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
> +
> +hlpip = gic_get_host_lpi(lpi);
> +if ( !hlpip )
> +return;
> +
> +hlpi.data = read_u64_atomic(&hlpip->data);
> +
> +/* We may have mapped more host LPIs than the guest actually asked for.
> */
> +if ( !hlpi.virt_lpi )
> +return;
> +
> +d = get_domain_by_id(hlpi.dom_id);
> +if ( !d )
> +return;
> +
> +if ( hlpi.vcpu_id >= d->max_vcpus )
> +{
> +put_domain(d);
> +return;
> +}
> +
> +vcpu = d->vcpu[hlpi.vcpu_id];
> +
> +put_domain(d);
> +
> +vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
put_domain should be here
> +}
> +
> uint64_t gicv3_lpi_allocate_pendtable(void)
> {
> uint64_t reg;
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index bd3c032..7286e5d 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -700,8 +700,10 @@ void gic_interrupt(struct cpu_user_regs *regs, int
> is_fiq)
> local_irq_enable();
> do_IRQ(regs, irq, is_fiq);
> local_irq_disable();
> -}
> -else if (unlikely(irq < 16))
> +} else if ( is_lpi(irq) )
> +{
> +do_LPI(irq);
> +} else if ( unlikely(irq < 16) )
> {
> do_sgi(regs, irq);
> }
> diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
> index 8f7a167..ee47de8 100644
> --- a/xen/include/asm-arm/irq.h
> +++ b/xen/include/asm-arm/irq.h
> @@ -34,6 +34,14 @@ struct irq_desc *__irq_to_desc(int irq);
>
> void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq);
>
> +#ifdef CONFIG_HAS_ITS
> +void do_LPI(unsigned int irq);
> +#else
> +static inline void do_LPI(unsigned int irq)
> +{
> +}
> +#endif
> +
> #define domain_pirq_to_irq(d, pirq) (pirq)
>
> bool_t is_assignable_irq(unsigned int irq);
> --
> 2.9.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 05/28] ARM: GICv3 ITS: map ITS command buffer
Hi Stefano, On 02/14/2017 12:59 AM, Stefano Stabellini wrote: On Mon, 30 Jan 2017, Andre Przywara wrote: static int its_map_baser(void __iomem *basereg, uint64_t regc, int nr_items) @@ -150,6 +191,11 @@ int gicv3_its_init(struct host_its *hw_its) } } +hw_its->cmd_buf = its_map_cbaser(hw_its); +if ( !hw_its->cmd_buf ) +return -ENOMEM; +writeq_relaxed(0, hw_its->its_base + GITS_CWRITER); Why this new write? This was requested by me. From the spec (8.19.5 in ARM IHI 0069C), the reset value of GITS_CWRITER is unknown. So we have to reset the register to 0 otherwise the ITS may try to read invalid command as soon as it has been enabled. FWIW, GITS_CREADR was reset to 0 by the ITS when GITS_CBASER has successfully been written (see 8.19.2). Cheers, -- Julien Grall IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 10/28] ARM: GICv3: introduce separate pending_irq structs for LPIs
On Mon, 30 Jan 2017, Andre Przywara wrote:
> For the same reason that allocating a struct irq_desc for each
> possible LPI is not an option, having a struct pending_irq for each LPI
> is also not feasible. However we actually only need those when an
> interrupt is on a vCPU (or is about to be injected).
> Maintain a list of those structs that we can use for the lifecycle of
> a guest LPI. We allocate new entries if necessary, however reuse
> pre-owned entries whenever possible.
> I added some locking around this list here, however my gut feeling is
> that we don't need one because this a per-VCPU structure anyway.
> If someone could confirm this, I'd be grateful.
> Teach the existing VGIC functions to find the right pointer when being
> given a virtual LPI number.
>
> Signed-off-by: Andre Przywara
Please address past comments, specifically use a data structure per
domain, rather than per-vcpu. Also please move to a more efficient data
structure, such as an hashtable or a tree.
> xen/arch/arm/gic.c | 3 +++
> xen/arch/arm/vgic-v3.c | 3 +++
> xen/arch/arm/vgic.c | 64
> +---
> xen/include/asm-arm/domain.h | 2 ++
> xen/include/asm-arm/vgic.h | 14 ++
> 5 files changed, 83 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index a5348f2..bd3c032 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -509,6 +509,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
> struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
> irq_set_affinity(p->desc, cpumask_of(v_target->processor));
> }
> +/* If this was an LPI, mark this struct as available again. */
> +if ( is_lpi(p->irq) )
> +p->irq = 0;
> }
> }
> }
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 1fadb00..b0653c2 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -1426,6 +1426,9 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
> if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
> v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;
>
> +spin_lock_init(&v->arch.vgic.pending_lpi_list_lock);
> +INIT_LIST_HEAD(&v->arch.vgic.pending_lpi_list);
> +
> return 0;
> }
>
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 364d5f0..7e3440f 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -31,6 +31,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, int rank)
> {
> @@ -61,7 +63,7 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v,
> unsigned int irq)
> return vgic_get_rank(v, rank);
> }
>
> -static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
> +void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
> {
> INIT_LIST_HEAD(&p->inflight);
> INIT_LIST_HEAD(&p->lr_queue);
> @@ -244,10 +246,14 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v,
> unsigned int virq)
>
> static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
> {
> -struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
> +struct vgic_irq_rank *rank;
> unsigned long flags;
> int priority;
>
> +if ( is_lpi(virq) )
> +return vgic_lpi_get_priority(v->domain, virq);
> +
> +rank = vgic_rank_irq(v, virq);
> vgic_lock_rank(v, rank, flags);
> priority = rank->priority[virq & INTERRUPT_RANK_MASK];
> vgic_unlock_rank(v, rank, flags);
> @@ -446,13 +452,63 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum
> gic_sgi_mode irqmode,
> return true;
> }
>
> +/*
> + * Holding struct pending_irq's for each possible virtual LPI in each domain
> + * requires too much Xen memory, also a malicious guest could potentially
> + * spam Xen with LPI map requests. We cannot cover those with (guest
> allocated)
> + * ITS memory, so we use a dynamic scheme of allocating struct pending_irq's
> + * on demand.
> + */
> +struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi,
> + bool allocate)
> +{
> +struct lpi_pending_irq *lpi_irq, *empty = NULL;
> +
> +spin_lock(&v->arch.vgic.pending_lpi_list_lock);
> +list_for_each_entry(lpi_irq, &v->arch.vgic.pending_lpi_list, entry)
> +{
> +if ( lpi_irq->pirq.irq == lpi )
> +{
> +spin_unlock(&v->arch.vgic.pending_lpi_list_lock);
> +return &lpi_irq->pirq;
> +}
> +
> +if ( lpi_irq->pirq.irq == 0 && !empty )
> +empty = lpi_irq;
> +}
> +
> +if ( !allocate )
> +{
> +spin_unlock(&v->arch.vgic.pending_lpi_list_lock);
> +return NULL;
> +}
> +
> +if ( !empty )
> +{
> +empty = xzalloc(struct lpi_pending_irq);
> +vgic_init_pending_irq(&empty->pirq, lp
Re: [Xen-devel] [PATCH v3] displif: add ABI for para-virtual display
On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote: > Hi, Konrad! > > Thank you for reviewing this. > > On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote: > > On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote: > > > From: Oleksandr Andrushchenko > > > > > > This is the ABI for the two halves of a para-virtualized > > > display driver. > > > > > > This protocol aims to provide a unified protocol which fits more > > > sophisticated use-cases than a framebuffer device can handle. At the > > > moment basic functionality is supported with the intention to extend: > > >o multiple dynamically allocated/destroyed framebuffers > > >o buffers of arbitrary sizes > > >o better configuration options including multiple display support > > > > > > Note: existing fbif can be used together with displif running at the > > > same time, e.g. on Linux one provides framebuffer and another DRM/KMS > > > > > > Future extensions to the existing protocol may include: > > >o allow display/connector cloning > > >o allow allocating objects other than display buffers > > >o add planes/overlays support > > >o support scaling > > >o support rotation > > > > > > == > > > Rationale for introducing this protocol instead of > > > using the existing fbif: > > > == > > > > > > 1. In/out event sizes > > >o fbif - 40 octets > > >o displif - 40 octets > > > This is only the initial version of the displif protocol > > > which means that there could be requests which will not fit > > > (WRT introducing some GPU related functionality > > > later on). In that case we cannot alter fbif sizes as we need to > > > be backward compatible an will be forced to handle those > > > apart of fbif. > > > > > > 2. Shared page > > > Displif doesn't use anything like struct xenfb_page, but > > > DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct > > > xendispl_resp) which is a better and more common way. > > > Output events use a shared page which only has in_cons and in_prod > > > and all the rest is used for incoming events. Here struct xenfb_page > > > could probably be used as is despite the fact that it only has a half > > > of a page for incoming events which is only 50 events. (consider > > > something like 60Hz display) > > > > > > 3. Amount of changes. > > > fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE > > > events, so it looks like it is easier to get fb support into displif > > .. would it make sense to reserve some of those values (2, 3) > > in the XENDISPL_OP_ values? So that if this happens there is a nice > > fit in there? Thought looking at the structure there is no easy > > way to 'overlay' the xenfb_out_event structure as it is missing the 'id'. > > > > I guess one can get creative. > > > > Or you could swap positions of 'id' and 'type'? And then it would fit much > > nicer? > yeap, in order no one needs to be creative, why not > explicitly define those? > Anyways, it won't be possible to simply lay the structures from > fbif on top of displif (different structure, size, workflow etc.), > what is more that would give some room to find workarounds, rather than > have well defined solution. BTW, there was an attempt [1] to update > fbdev to meet modern application needs. If we decide to add FBDEV > functionality into this protocol, then I can re-use already > proven to work solution from [1] into DISPLIF, but defining > structures and events to fit the current protocol. I was thinking that since the size of the structure is 64bytes you have enough space to jam in the old structures too. Naturally the driver would need adjustments as it offsets of where this goes are all wrong. > What do you think? > > > than vice versa. displif at the moment has 6 requests and 1 event, > > > multiple connector support, etc. > > > > > > Changes since v2: > > > * updated XenStore configuration template/pattern > > > * added "Recovery flow" to state diagram description > > > * renamed gref_directory_start to gref_directory > > > * added missing "versions" and "version" string constants > > > > > > Changes since v1: > > > * fixed xendispl_event_page padding size > > > * added versioning support > > > * explicitly define value types for XenStore fields > > > * text decoration re-work > > > * added offsets to ASCII box notation > > > > > > Changes since initial: > > > * DRM changed to DISPL, protocol made generic > > > * major re-work addressing issues raised for sndif > > > > > > Signed-off-by: Oleksandr Grytsov > > > Signed-off-by: Oleksandr Andrushchenko > > > --- > > > xen/include/public/io/displif.h | 778 > > > > > > 1 file changed, 778 insertions(+) > > > create mode 100644 xen/include/public/io/displif.h > > > > > > diff --git a/xen/include/public/io/displif.h > > > b/xen/i
Re: [Xen-devel] STAO spec in xen.git
On Tue, Feb 14, 2017 at 09:02:14PM +0100, Olaf Hering wrote: > On Tue, Feb 14, Stefano Stabellini wrote: > > > Interestingly, my "git am" is unable to apply those patches. Does it > > work for you? I cannot see anything wrong with them, but they don't > > work. If the problem is that they are too large, please send the files > > as attachments. > > Its the '\ No newline at end of file' at the end. Not sure if diff > should not procude it, or if patch should handle it. I assume an > attachment would create the same error because there is no newline for > some reason. > Better to just push to a branch for us to fetch. Wei. > > Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document
Hi Stefano, On 02/14/2017 06:20 PM, Stefano Stabellini wrote: On Tue, 14 Feb 2017, Julien Grall wrote: Hi Stefano, On 02/13/2017 07:59 PM, Stefano Stabellini wrote: On Mon, 13 Feb 2017, Julien Grall wrote: Hi Stefano, On 10/02/17 01:01, Stefano Stabellini wrote: On Fri, 3 Feb 2017, Edgar E. Iglesias wrote: A possible hack could be to allocate a chunk of DDR dedicated for PCI DMA. PCI DMA devs could be locked in to only be able to access this mem + MSI doorbell. Guests can still screw each other up but at least it becomes harder to read/write directly from each others OS memory. It may not be worth the effort though Actually, we do have the swiotlb in Dom0, which can be used to bounce DMA requests over a buffer that has been previously setup to be DMA safe using an hypercall. That is how the swiotlb is used on x86. On ARM it is used to issue cache flushes via hypercall, but it could be adapted to do both. It would degrade performance, due to the additional memcpy, but it would work, I believe. A while ago, Globallogic suggested to use direct memory mapping for the guest to allow guest using DMA on platform not supporting SMMU. I believe we can use the same trick on platform where SMMUs can not distinguish PCI devices. Yes, that would work, but only on platforms with a very limited number of guests. However, it might still be a very common use-case on a platform such as the Zynq MPSoC. Can you explain why you think this could only work with limited number of guests? Because the memory regions would need to be mapped 1:1, right? Correct. In your case, the DMA buffer would have to be contiguous in the memory. And often devices have less than 4G DMA addresses limitations? Many platform has more than 4GB of memory today, I would be surprised if devices still have this 32-bit DMA address limitation. But maybe I am wrong here. If it that is the case, you would still need to have memory freed below 4GB for the swiotlb. I can see how it could work well with 1-4 guests, but I don't think it could work in a typical server environment with many more guests. Or am I missing something? I expect all servers to be SBSA compliant and AFAICT the SBSA mandates an SMMU for I/O virtualization (see 8.6 in ARM-DEN-0029 v3.0). Furthermore, for embedded the cost of using swiotlb might not be acceptable (you add an extra copy). In the server case, I would not bother to support properly platform with broken SMMU. For embedded, I think it would be acceptable to have direct mapping. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor
On Tue, Feb 14, 2017 at 12:11 PM, Stefano Stabellini wrote: > On Tue, 14 Feb 2017, Julien Grall wrote: >> > > > 10. Domains on which the monitor privileged call feature is enabled >> > > > (which is by default disabled for all domains) should not be able to >> > > > issue firmware calls via SMCs/HVCs so that such calls reach the >> > > > firmware directly. Xen should not bounce such calls to the firmware >> > > > on >> > > > behalf of the domain. Xen should not alter the state of the domain >> > > > automatically (ie. incrementing PC). These calls should be >> > > > exclusively >> > > > transfered to the monitor subscriber for further processing. >> > > > Hypercalls, virtual PSCI calls, virtual CPU services calls and >> > > > virtual >> > > > ARM architecture service calls remain unaffected. >> > > > >> > > > Does that work for you? >> > > >> > > It works iff hypercalls, virtual psci calls and virtual CPU services >> > > can be denied with XSM. If that's not the case, then no, in that case >> > > all those HVC calls that would be bounced to the firmware need to be >> > > hooked into the monitor system as well. Ideally as soon as they are >> > > being introduced to the Xen codebase. >> > >> > I don't think we have XSM hooks for all of those today, but I think >> > everybody would agree that it is be a good idea to have them. >> >> I disagree here. If you add XSM hook in vPSCI, it means you will allow the >> user to deny CPU bring up. In this case, what is the point to have a guest >> with multiple CPUs? >> >> Regarding forwarding to the monitor app, this is very similar to MMIO region >> emulated by either Xen or QEMU (in x86 case) they cannot be forwarded. Are >> you >> going to add XSM in the MMIO emulation too? Are you going to emulate the >> vITS/vGIC/vUART/pl011 in the monitor app? > > Let's talk about your two concerns separately, because they are > separate points. > > > I won't go into the merits of the comparison between firmware calls and > x86 MMIO region emulation. However, I think that forwarding firmware > calls events to the monitor is fine. It allows new potential use-cases > for Xen, without affecting any of the current use-cases, given that > firmware calls forwarding would need to be enabled separately. > > In regards to XSM hooks for vPSCI, after looking at the code, it is true > that there aren't any XSM hooks even for the corresponding PV vcpu_op > hypercalls (used for PV guests on x86). Introducing them might not be as > obvious as I thought. But I don't think we actually need XSM for this. > > > Firstly, we need to distinguish between SMC/HVC calls that result in > platform and TEE calls (the main topic of this thread), and SMC/HVC > calls that result in virtual PSCI CPU operations and Xen hypercalls > (do_trap_psci and do_trap_hypercall). The first set of calls is bounced > to the firmware, while the second set of calls is emulated/virtualized. > > Clearly, the first set of calls would need to be forwarded to the > monitor. I don't think that the second set of calls need to be forwarded > or filtered, because they actually do not result in any firmware calls. > Once the user enables "firmware calls forwarding to the monitor", we > could just leave the virtual PSCI cpu ops and hypercalls implemented as > they are today. We just need to write down in a document what SMC/HVC > calls get forwarded to the monitor once the user enabled the appropriate > option. Correct, calls that are emulated by Xen itself don't need to be forwarded to the monitor app. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall
On Mon, 30 Jan 2017, Andre Przywara wrote:
> To get MSIs from devices forwarded to a CPU, we need to name the device
> and its MSIs by mapping them to an ITS.
> Since this involves queueing commands to the ITS command queue, we can't
> really afford to do this during the guest's runtime, as this would open
> up a denial-of-service attack vector.
> So we require every device with MSI interrupts to be mapped explicitly by
> Dom0. For Dom0 itself we can just use the existing PCI physdev_op
> hypercalls, which the existing Linux kernel issues already.
> So upon receipt of this hypercall we map the device to the hardware ITS
> and prepare it to be later mapped by the virtual ITS by using the very
> same device ID (for Dom0 only).
> Also we ask for mapping 32 LPIs to cover 32 MSIs that the device may
> use.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/physdev.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
> index 27bbbda..6e02de4 100644
> --- a/xen/arch/arm/physdev.c
> +++ b/xen/arch/arm/physdev.c
> @@ -9,11 +9,32 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
>
>
> int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> +struct physdev_manage_pci manage;
> +u32 devid;
> +int ret;
> +
> +switch (cmd)
> +{
> +case PHYSDEVOP_manage_pci_add:
> +case PHYSDEVOP_manage_pci_remove:
> +if ( copy_from_guest(&manage, arg, 1) != 0 )
> +return -EFAULT;
You need to check that current is the hardware domain first.
> +devid = manage.bus << 8 | manage.devfn;
> +/* Allocate an ITS device table with space for 32 MSIs */
Please explain why 32
> +ret = gicv3_its_map_guest_device(hardware_domain, devid, devid,
> 5,
> + cmd ==
> PHYSDEVOP_manage_pci_add);
> +
> +return ret;
> +}
> +
> gdprintk(XENLOG_DEBUG, "PHYSDEVOP cmd=%d: not implemented\n", cmd);
> return -ENOSYS;
> }
> --
> 2.9.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 08/28] ARM: GICv3 ITS: introduce host LPI array
On Mon, 30 Jan 2017, Andre Przywara wrote:
> The number of LPIs on a host can be potentially huge (millions),
> although in practise will be mostly reasonable. So prematurely allocating
> an array of struct irq_desc's for each LPI is not an option.
> However Xen itself does not care about LPIs, as every LPI will be injected
> into a guest (Dom0 for now).
> Create a dense data structure (8 Bytes) for each LPI which holds just
> enough information to determine the virtual IRQ number and the VCPU into
> which the LPI needs to be injected.
> Also to not artificially limit the number of LPIs, we create a 2-level
> table for holding those structures.
> This patch introduces functions to initialize these tables and to
> create, lookup and destroy entries for a given LPI.
> We allocate and access LPI information in a way that does not require
> a lock.
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/gic-v3-its.c| 80 -
> xen/arch/arm/gic-v3-lpi.c| 187
> ++-
> xen/include/asm-arm/atomic.h | 6 +-
> xen/include/asm-arm/gic.h| 5 ++
> xen/include/asm-arm/gic_v3_its.h | 9 ++
> 5 files changed, 282 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 4a3a394..f073ab5 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -83,6 +83,20 @@ static int its_send_cmd_sync(struct host_its *its, int cpu)
> return its_send_command(its, cmd);
> }
>
> +static int its_send_cmd_mapti(struct host_its *its,
> + uint32_t deviceid, uint32_t eventid,
> + uint32_t pintid, uint16_t icid)
> +{
> +uint64_t cmd[4];
> +
> +cmd[0] = GITS_CMD_MAPTI | ((uint64_t)deviceid << 32);
> +cmd[1] = eventid | ((uint64_t)pintid << 32);
> +cmd[2] = icid;
> +cmd[3] = 0x00;
> +
> +return its_send_command(its, cmd);
> +}
> +
> static int its_send_cmd_mapc(struct host_its *its, int collection_id, int
> cpu)
> {
> uint64_t cmd[4];
> @@ -111,6 +125,19 @@ static int its_send_cmd_mapd(struct host_its *its,
> uint32_t deviceid,
> return its_send_command(its, cmd);
> }
>
> +static int its_send_cmd_inv(struct host_its *its,
> +uint32_t deviceid, uint32_t eventid)
> +{
> +uint64_t cmd[4];
> +
> +cmd[0] = GITS_CMD_INV | ((uint64_t)deviceid << 32);
> +cmd[1] = eventid;
> +cmd[2] = 0x00;
> +cmd[3] = 0x00;
> +
> +return its_send_command(its, cmd);
> +}
> +
> /* Set up the (1:1) collection mapping for the given host CPU. */
> int gicv3_its_setup_collection(int cpu)
> {
> @@ -359,13 +386,47 @@ int gicv3_its_init(struct host_its *hw_its)
>
> static void remove_mapped_guest_device(struct its_devices *dev)
> {
> +int i;
> +
> if ( dev->hw_its )
> its_send_cmd_mapd(dev->hw_its, dev->host_devid, 0, 0, false);
>
> +for ( i = 0; i < dev->eventids / 32; i++ )
> +gicv3_free_host_lpi_block(dev->hw_its, dev->host_lpis[i]);
> +
> xfree(dev->itt_addr);
> +xfree(dev->host_lpis);
> xfree(dev);
> }
>
> +/*
> + * On the host ITS @its, map @nr_events consecutive LPIs.
> + * The mapping connects a device @devid and event @eventid pair to LPI @lpi,
> + * increasing both @eventid and @lpi to cover the number of requested LPIs.
> + */
> +int gicv3_its_map_host_events(struct host_its *its,
> + int devid, int eventid, int lpi,
> + int nr_events)
> +{
> +int i, ret;
> +
> +for ( i = 0; i < nr_events; i++ )
> +{
> +ret = its_send_cmd_mapti(its, devid, eventid + i, lpi + i, 0);
> +if ( ret )
> +return ret;
> +ret = its_send_cmd_inv(its, devid, eventid + i);
> +if ( ret )
> +return ret;
> +}
> +
> +ret = its_send_cmd_sync(its, 0);
> +if ( ret )
> +return ret;
> +
> +return 0;
> +}
> +
> int gicv3_its_map_guest_device(struct domain *d, int host_devid,
> int guest_devid, int bits, bool valid)
> {
> @@ -373,7 +434,7 @@ int gicv3_its_map_guest_device(struct domain *d, int
> host_devid,
> struct its_devices *dev, *temp;
> struct rb_node **new = &d->arch.vgic.its_devices.rb_node, *parent = NULL;
> struct host_its *hw_its;
> -int ret;
> +int ret, i;
>
> /* check for already existing mappings */
> spin_lock(&d->arch.vgic.its_devices_lock);
> @@ -430,10 +491,19 @@ int gicv3_its_map_guest_device(struct domain *d, int
> host_devid,
> goto out_unlock;
> }
>
> +dev->host_lpis = xzalloc_array(uint32_t, BIT(bits) / 32);
> +if ( !dev->host_lpis )
> +{
> +xfree(dev);
> +xfree(itt_addr);
> +return -ENOMEM;
> +}
> +
> ret = its_send_cmd_mapd(hw_its, host_devid, bits - 1,
> virt_to_maddr(itt_addr), true);
> if ( ret )
>
Re: [Xen-devel] STAO spec in xen.git
On Tue, Feb 14, Stefano Stabellini wrote: > Interestingly, my "git am" is unable to apply those patches. Does it > work for you? I cannot see anything wrong with them, but they don't > work. If the problem is that they are too large, please send the files > as attachments. Its the '\ No newline at end of file' at the end. Not sure if diff should not procude it, or if patch should handle it. I assume an attachment would create the same error because there is no newline for some reason. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 3/4] x86: Make the GDT remapping read-only on 64-bit
This patch makes the GDT remapped pages read-only to prevent corruption.
This change is done only on 64-bit.
The native_load_tr_desc function was adapted to correctly handle a
read-only GDT. The LTR instruction always writes to the GDT TSS entry.
This generates a page fault if the GDT is read-only. This change checks
if the current GDT is a remap and swap GDTs as needed. This function was
tested by booting multiple machines and checking hibernation works
properly.
KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
per-cpu variable was removed for functions to fetch the original GDT.
Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
expected. For testing, VMs were started and restored on multiple
configurations.
Signed-off-by: Thomas Garnier
---
Based on next-20170213
---
arch/x86/include/asm/desc.h | 51
arch/x86/include/asm/processor.h | 1 +
arch/x86/kernel/cpu/common.c | 28 +-
arch/x86/kvm/svm.c | 4 +---
arch/x86/kvm/vmx.c | 15
5 files changed, 75 insertions(+), 24 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 5d4ba1311737..15b2a86c9267 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -57,6 +57,17 @@ static inline unsigned long get_cpu_gdt_rw_vaddr(unsigned
int cpu)
return (unsigned long)get_cpu_gdt_rw(cpu);
}
+/* Provide the current original GDT */
+static inline struct desc_struct *get_current_gdt_rw(void)
+{
+ return this_cpu_ptr(&gdt_page)->gdt;
+}
+
+static inline unsigned long get_current_gdt_rw_vaddr(void)
+{
+ return (unsigned long)get_current_gdt_rw();
+}
+
/* Get the fixmap index for a specific processor */
static inline unsigned int get_cpu_gdt_ro_index(int cpu)
{
@@ -233,11 +244,6 @@ static inline void native_set_ldt(const void *addr,
unsigned int entries)
}
}
-static inline void native_load_tr_desc(void)
-{
- asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
-}
-
static inline void native_load_gdt(const struct desc_ptr *dtr)
{
asm volatile("lgdt %0"::"m" (*dtr));
@@ -258,6 +264,41 @@ static inline void native_store_idt(struct desc_ptr *dtr)
asm volatile("sidt %0":"=m" (*dtr));
}
+/*
+ * The LTR instruction marks the TSS GDT entry as busy. On 64-bit, the GDT is
+ * a read-only remapping. To prevent a page fault, the GDT is switched to the
+ * original writeable version when needed.
+ */
+#ifdef CONFIG_X86_64
+static inline void native_load_tr_desc(void)
+{
+ struct desc_ptr gdt;
+ int cpu = raw_smp_processor_id();
+ bool restore = 0;
+ struct desc_struct *fixmap_gdt;
+
+ native_store_gdt(&gdt);
+ fixmap_gdt = get_cpu_gdt_ro(cpu);
+
+ /*
+* If the current GDT is the read-only fixmap, swap to the original
+* writeable version. Swap back at the end.
+*/
+ if (gdt.address == (unsigned long)fixmap_gdt) {
+ load_direct_gdt(cpu);
+ restore = 1;
+ }
+ asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
+ if (restore)
+ load_fixmap_gdt(cpu);
+}
+#else
+static inline void native_load_tr_desc(void)
+{
+ asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
+}
+#endif
+
static inline unsigned long native_store_tr(void)
{
unsigned long tr;
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index c441d1f7e275..6ea9e419a856 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -706,6 +706,7 @@ extern struct desc_ptr early_gdt_descr;
extern void cpu_set_gdt(int);
extern void switch_to_new_gdt(int);
+extern void load_direct_gdt(int);
extern void load_fixmap_gdt(int);
extern void load_percpu_segment(int);
extern void cpu_init(void);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 2853a42ded2d..bdf521383900 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -444,13 +444,31 @@ void load_percpu_segment(int cpu)
load_stack_canary_segment();
}
+/* On 64-bit the GDT remapping is read-only */
+#ifdef CONFIG_X86_64
+#define PAGE_FIXMAP_GDT PAGE_KERNEL_RO
+#else
+#define PAGE_FIXMAP_GDT PAGE_KERNEL
+#endif
+
/* Setup the fixmap mapping only once per-processor */
static inline void setup_fixmap_gdt(int cpu)
{
__set_fixmap(get_cpu_gdt_ro_index(cpu),
-__pa(get_cpu_gdt_rw(cpu)), PAGE_KERNEL);
+__pa(get_cpu_gdt_rw(cpu)), PAGE_FIXMAP_GDT);
}
+/* Load the original GDT from the per-cpu structure */
+void load_direct_gdt(int cpu)
+{
+ struct desc_ptr gdt_descr;
+
+ gdt_descr.address = (long)get_cpu_gdt_rw(cpu);
+ gdt_descr.size = GDT_SIZE - 1;
+ load_gdt(&gdt_descr);
+}
+EXPORT_SYMBOL_GPL(load_direct_gdt);
+
/* Load a fixmap remapping of the per-cpu GDT */
void load_fi
[Xen-devel] [PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size
This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.
It will allow GDT remapping in the Fixmap section. The current
MODULES_END static address does not provide enough space for the kernel
to support a large number of processors.
Signed-off-by: Thomas Garnier
---
Based on next-20170213
---
arch/x86/include/asm/fixmap.h | 8
arch/x86/include/asm/pgtable_64_types.h | 3 ---
arch/x86/kernel/module.c| 1 +
arch/x86/mm/dump_pagetables.c | 1 +
arch/x86/mm/kasan_init_64.c | 1 +
5 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 8554f960e21b..20231189e0e3 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -132,6 +132,14 @@ enum fixed_addresses {
extern void reserve_top_address(unsigned long reserve);
+/* On 64-bit, the module sections ends with the start of the fixmap */
+#ifdef CONFIG_X86_64
+#define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+#define MODULES_END __fix_to_virt(__end_of_fixed_addresses + 1)
+#define MODULES_LEN (MODULES_END - MODULES_VADDR)
+#endif /* CONFIG_X86_64 */
+
+
#define FIXADDR_SIZE (__end_of_permanent_fixed_addresses << PAGE_SHIFT)
#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 3a264200c62f..de8bace10200 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -66,9 +66,6 @@ typedef struct { pteval_t pte; } pte_t;
#define VMEMMAP_START __VMEMMAP_BASE
#endif /* CONFIG_RANDOMIZE_MEMORY */
#define VMALLOC_END(VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
-#define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
-#define MODULES_END _AC(0xff00, UL)
-#define MODULES_LEN (MODULES_END - MODULES_VADDR)
#define ESPFIX_PGD_ENTRY _AC(-2, UL)
#define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
#define EFI_VA_START( -4 * (_AC(1, UL) << 30))
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 477ae806c2fa..fad61caac75e 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#if 0
#define DEBUGP(fmt, ...) \
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 8aa6bea1cd6c..90170415f08a 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -19,6 +19,7 @@
#include
#include
+#include
/*
* The dumper groups pagetable entries of the same type into one, and for
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 0493c17b8a51..34f167cf3316 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -8,6 +8,7 @@
#include
#include
+#include
extern pgd_t early_level4_pgt[PTRS_PER_PGD];
extern struct range pfn_mapped[E820_X_MAX];
--
2.11.0.483.g087da7b7c-goog
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/4] x86: Remap GDT tables in the Fixmap section
Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section (PAGE_OFFSET).
This patch relocates the GDT table for each processor inside the
Fixmap section. The space is reserved based on number of supported
processors.
For consistency, the remapping is done by default on 32 and 64-bit.
Each processor switches to its remapped GDT at the end of
initialization. For hibernation, the main processor returns with the
original GDT and switches back to the remapping at completion.
This patch was tested on both architectures. Hibernation and KVM were
both tested specially for their usage of the GDT.
Signed-off-by: Thomas Garnier
---
Based on next-20170213
---
arch/x86/entry/vdso/vma.c | 2 +-
arch/x86/include/asm/desc.h | 33 +
arch/x86/include/asm/fixmap.h | 4
arch/x86/include/asm/processor.h | 1 +
arch/x86/include/asm/stackprotector.h | 2 +-
arch/x86/kernel/acpi/sleep.c | 2 +-
arch/x86/kernel/apm_32.c | 6 +++---
arch/x86/kernel/cpu/common.c | 26 --
arch/x86/kernel/setup_percpu.c| 2 +-
arch/x86/kernel/smpboot.c | 2 +-
arch/x86/platform/efi/efi_32.c| 4 ++--
arch/x86/power/cpu.c | 7 +--
arch/x86/xen/enlighten.c | 2 +-
arch/x86/xen/smp.c| 2 +-
drivers/lguest/x86/core.c | 6 +++---
drivers/pnp/pnpbios/bioscalls.c | 10 +-
16 files changed, 83 insertions(+), 28 deletions(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 572cee3fccff..9c8bd4cfcc6e 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -353,7 +353,7 @@ static void vgetcpu_cpu_init(void *arg)
d.p = 1;/* Present */
d.d = 1;/* 32-bit */
- write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, &d,
DESCTYPE_S);
+ write_gdt_entry(get_cpu_gdt_rw(cpu), GDT_ENTRY_PER_CPU, &d, DESCTYPE_S);
}
static int vgetcpu_online(unsigned int cpu)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 12080d87da3b..5d4ba1311737 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
@@ -45,11 +46,35 @@ struct gdt_page {
DECLARE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page);
-static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu)
+/* Provide the original GDT */
+static inline struct desc_struct *get_cpu_gdt_rw(unsigned int cpu)
{
return per_cpu(gdt_page, cpu).gdt;
}
+static inline unsigned long get_cpu_gdt_rw_vaddr(unsigned int cpu)
+{
+ return (unsigned long)get_cpu_gdt_rw(cpu);
+}
+
+/* Get the fixmap index for a specific processor */
+static inline unsigned int get_cpu_gdt_ro_index(int cpu)
+{
+ return FIX_GDT_REMAP_BEGIN + cpu;
+}
+
+/* Provide the fixmap address of the remapped GDT */
+static inline struct desc_struct *get_cpu_gdt_ro(int cpu)
+{
+ unsigned int idx = get_cpu_gdt_ro_index(cpu);
+ return (struct desc_struct *)__fix_to_virt(idx);
+}
+
+static inline unsigned long get_cpu_gdt_ro_vaddr(int cpu)
+{
+ return (unsigned long)get_cpu_gdt_ro(cpu);
+}
+
#ifdef CONFIG_X86_64
static inline void pack_gate(gate_desc *gate, unsigned type, unsigned long
func,
@@ -174,7 +199,7 @@ static inline void set_tssldt_descriptor(void *d, unsigned
long addr, unsigned t
static inline void __set_tss_desc(unsigned cpu, unsigned int entry, void *addr)
{
- struct desc_struct *d = get_cpu_gdt_table(cpu);
+ struct desc_struct *d = get_cpu_gdt_rw(cpu);
tss_desc tss;
/*
@@ -202,7 +227,7 @@ static inline void native_set_ldt(const void *addr,
unsigned int entries)
set_tssldt_descriptor(&ldt, (unsigned long)addr, DESC_LDT,
entries * LDT_ENTRY_SIZE - 1);
- write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_LDT,
+ write_gdt_entry(get_cpu_gdt_rw(cpu), GDT_ENTRY_LDT,
&ldt, DESC_LDT);
asm volatile("lldt %w0"::"q" (GDT_ENTRY_LDT*8));
}
@@ -244,7 +269,7 @@ static inline unsigned long native_store_tr(void)
static inline void native_load_tls(struct thread_struct *t, unsigned int cpu)
{
- struct desc_struct *gdt = get_cpu_gdt_table(cpu);
+ struct desc_struct *gdt = get_cpu_gdt_rw(cpu);
unsigned int i;
for (i = 0; i < GDT_ENTRY_TLS_ENTRIES; i++)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 20231189e0e3..4c11425d856c 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86
[Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base
The KVM segment_base function is confusing. This patch replaces integers
with appropriate flags, simplify constructs and add comments.
Signed-off-by: Thomas Garnier
---
Based on next-20170213
---
arch/x86/kvm/vmx.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 99167f20bc34..edb8326108dd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2062,25 +2062,35 @@ static unsigned long segment_base(u16 selector)
struct desc_struct *d;
unsigned long table_base;
unsigned long v;
+ u32 high32;
- if (!(selector & ~3))
+ if (!(selector & ~SEGMENT_RPL_MASK))
return 0;
- table_base = get_current_gdt_rw_vaddr();
-
- if (selector & 4) { /* from ldt */
+ /* LDT selector */
+ if ((selector & SEGMENT_TI_MASK) == SEGMENT_LDT) {
u16 ldt_selector = kvm_read_ldt();
- if (!(ldt_selector & ~3))
+ if (!(ldt_selector & ~SEGMENT_RPL_MASK))
return 0;
table_base = segment_base(ldt_selector);
+ } else {
+ table_base = get_current_gdt_rw_vaddr();
}
- d = (struct desc_struct *)(table_base + (selector & ~7));
+
+ d = (struct desc_struct *)table_base + (selector >> 3);
v = get_desc_base(d);
#ifdef CONFIG_X86_64
- if (d->s == 0 && (d->type == 2 || d->type == 9 || d->type == 11))
- v |= ((unsigned long)((struct ldttss_desc64 *)d)->base3) << 32;
+ /*
+* Extend the virtual address if we have a system descriptor entry for
+* LDT or TSS (available or busy).
+*/
+ if (d->s == 0 && (d->type == DESC_LDT || d->type == DESC_TSS ||
+ d->type == 11/*Busy TSS */)) {
+ high32 = ((struct ldttss_desc64 *)d)->base3;
+ v |= (u64)high32 << 32;
+ }
#endif
return v;
}
--
2.11.0.483.g087da7b7c-goog
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC v9] PV Calls protocol design
On Mon, Feb 13, 2017 at 11:46:40AM -0800, Stefano Stabellini wrote: > Changes in v9: > - specify max-page-order must be >= 1 > - clarifications > - add "Expanding the protocol" > - add padding after out_error > - add "Why ring.h is not needed" Reviewed-by: Konrad Rzeszutek Wilk ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [DOC v5] Xen transport for 9pfs
On Mon, Feb 13, 2017 at 11:47:26AM -0800, Stefano Stabellini wrote: Reviewed-by: Konrad Rzeszutek Wilk > Changes in v5: > - add padding after out_prod > - add "Why ring.h is not needed" > - specify max-ring-page-order >= 1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor
On Tue, 14 Feb 2017, Julien Grall wrote: > > > > 10. Domains on which the monitor privileged call feature is enabled > > > > (which is by default disabled for all domains) should not be able to > > > > issue firmware calls via SMCs/HVCs so that such calls reach the > > > > firmware directly. Xen should not bounce such calls to the firmware on > > > > behalf of the domain. Xen should not alter the state of the domain > > > > automatically (ie. incrementing PC). These calls should be exclusively > > > > transfered to the monitor subscriber for further processing. > > > > Hypercalls, virtual PSCI calls, virtual CPU services calls and virtual > > > > ARM architecture service calls remain unaffected. > > > > > > > > Does that work for you? > > > > > > It works iff hypercalls, virtual psci calls and virtual CPU services > > > can be denied with XSM. If that's not the case, then no, in that case > > > all those HVC calls that would be bounced to the firmware need to be > > > hooked into the monitor system as well. Ideally as soon as they are > > > being introduced to the Xen codebase. > > > > I don't think we have XSM hooks for all of those today, but I think > > everybody would agree that it is be a good idea to have them. > > I disagree here. If you add XSM hook in vPSCI, it means you will allow the > user to deny CPU bring up. In this case, what is the point to have a guest > with multiple CPUs? > > Regarding forwarding to the monitor app, this is very similar to MMIO region > emulated by either Xen or QEMU (in x86 case) they cannot be forwarded. Are you > going to add XSM in the MMIO emulation too? Are you going to emulate the > vITS/vGIC/vUART/pl011 in the monitor app? Let's talk about your two concerns separately, because they are separate points. I won't go into the merits of the comparison between firmware calls and x86 MMIO region emulation. However, I think that forwarding firmware calls events to the monitor is fine. It allows new potential use-cases for Xen, without affecting any of the current use-cases, given that firmware calls forwarding would need to be enabled separately. In regards to XSM hooks for vPSCI, after looking at the code, it is true that there aren't any XSM hooks even for the corresponding PV vcpu_op hypercalls (used for PV guests on x86). Introducing them might not be as obvious as I thought. But I don't think we actually need XSM for this. Firstly, we need to distinguish between SMC/HVC calls that result in platform and TEE calls (the main topic of this thread), and SMC/HVC calls that result in virtual PSCI CPU operations and Xen hypercalls (do_trap_psci and do_trap_hypercall). The first set of calls is bounced to the firmware, while the second set of calls is emulated/virtualized. Clearly, the first set of calls would need to be forwarded to the monitor. I don't think that the second set of calls need to be forwarded or filtered, because they actually do not result in any firmware calls. Once the user enables "firmware calls forwarding to the monitor", we could just leave the virtual PSCI cpu ops and hypercalls implemented as they are today. We just need to write down in a document what SMC/HVC calls get forwarded to the monitor once the user enabled the appropriate option. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v15 01/10] x86: add "w" flag to .init.data section definition
On 14/02/17 18:33, Daniel Kiper wrote: > init.data section is clearly writable, so, add "w" flag to its > definition in xen/arch/x86/boot/x86_64.S. > > Signed-off-by: Daniel Kiper Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor
On Tue, Feb 14, 2017 at 11:06 AM, Julien Grall wrote: > Hi, > > > On 02/13/2017 10:14 PM, Stefano Stabellini wrote: >> >> On Mon, 13 Feb 2017, Tamas K Lengyel wrote: >>> >>> On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini >>> wrote: On Mon, 13 Feb 2017, Tamas K Lengyel wrote: > > On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini > wrote: >> >> On Mon, 13 Feb 2017, Tamas K Lengyel wrote: >>> >>> On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall >>> wrote: On 13/02/17 16:59, Tamas K Lengyel wrote: > > > On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall > > wrote: >> >> >> Hi Tamas, >> >> >> On 13/02/17 16:20, Tamas K Lengyel wrote: >>> >>> >>> >>> On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk >>> wrote: Hello, This e-mail is sort of follow-up to the two threads: [1] (my thread about TEE interaction) and [2] (Edgar's thread regarding handling SMC calls in platform_hvc). I want to discuss more broad topic there. Obviously, there are growing number of SMC users and current state of SMC handling in Xen satisfies nobody. My team wants to handle SMCs in secure way, Xilinx wants to forward some calls directly to Secure Monitor, while allowing to handle other in userspace, etc. My proposition is to gather all requirements to SMC (and HVC) handling in one place (e.g. in this mail thread). After we' will have clear picture of what we want, we will be able to develop some solution, that will satisfy us all. At least, I hope so :) Also I want to remind, that there are ARM document called "SMC Calling Convention" [3]. According to it, any aarch64 hypervisor "must implement the Standard Secure and Hypervisor Service calls". At this moment XEN does not conform to this. So, lets get started with the requirements: 0. There are no much difference between SMC and HVC handling (at least according to SMCCC). 1. Hypervisor should at least provide own UUID and version while called by SMC/HVC 2. Hypervisor should forward some calls from dom0 directly to Secure Monitor (Xilinx use case) 3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM architecture service calls, etc. 4. Hypervisor should handle TEE calls in a secure way (e.g. no untrusted handlers in Dom0 userspace). 5. Hypervisor should support multiple TEEs (at least at compilation time). 6. Hypervisor should do this as fast as possible (DRM playback use case). 7. All domains (including dom0) should be handled in the same way. 8. Not all domains will have right to issue certain SMCs. 9. Hypervisor will issue own SMCs in some cases. >>> >>> >>> >>> >>> 10. Domains on which the monitor privileged call feature is >>> enabled >>> (which is by default disabled for all domains) should not be able >>> to >>> issue SMCs such that it reaches the firmware directly. Xen should >>> not >>> bounce such calls to the firmware on behalf of the domain. Xen >>> should >>> not alter the state of the domain automatically (ie. incrementing >>> PC). >>> These calls should be exclusively transfered to the monitor >>> subscriber >>> for further processing. HVC calls need not be included in the >>> monitor >>> forwarding as long as the HVC call can be governed by XSM. >> >> >> >> >> This should not be a strong requirement. Whilst in your use case >> you want >> to >> forward all the SMCs to the monitor app, there are use case where >> Xen >> would >> need to emulate SMCs on the behalf of the guest. For instance see >> PSCI >> (arch/arm/vpsci.c). > > > > In my usecases it is a strong requirement. What happens when the > monitor system is disabled is beyond my concerns - Xen can emulate > or > forward the call as it wishes. But when the monitor application is > in > use - in my usecase - it needs to be i
[Xen-devel] [xen-unstable-smoke test] 105797: tolerable trouble: broken/fail/pass - PUSHED
flight 105797 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105797/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen-buildfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
build-arm64-pvops 5 kernel-build fail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen bdbc25b8722cc1e3921858530f8ac484892156d3
baseline version:
xen 909c219944e944f086ec0a89938a7397e2aa4cb0
Last test of basis 105792 2017-02-14 15:01:05 Z0 days
Testing same since 105797 2017-02-14 17:02:33 Z0 days1 attempts
People who touched revisions under test:
Roger Pau Monne
Roger Pau Monné
Wei Liu
jobs:
build-amd64 pass
build-arm64 fail
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsfail
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
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 :
+ branch=xen-unstable-smoke
+ revision=bdbc25b8722cc1e3921858530f8ac484892156d3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
bdbc25b8722cc1e3921858530f8ac484892156d3
+ branch=xen-unstable-smoke
+ revision=bdbc25b8722cc1e3921858530f8ac484892156d3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xbdbc25b8722cc1e3921858530f8ac484892156d3 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumpr
Re: [Xen-devel] STAO spec in xen.git
On Tue, Feb 14, Stefano Stabellini wrote: > Also, I tried to do the same conversion with my copy of Libreoffice and > the FODT files produced are significantly different from yours, which > means, even if we use FODT docs, we are probably going to be unable to > send changes as meaningful text patches. I guess one would be able to use vi to make further adjustments. So far I have not tried to apply what git send-email produced, it would be a dead-end anyway :-) Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
On Tue, 14 Feb 2017, Boris Ostrovsky wrote:
> On 02/13/2017 12:03 PM, Paul Durrant wrote:
> > Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> > for restricting device emulators (such as QEMU) to a limited set of
> > hypervisor operations, and being able to audit those operations in the
> > kernel of the domain in which they run.
> >
> > This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.
> >
> > NOTE: There is no requirement for user-space code to bounce data through
> > locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
> > privcmd has enough information to lock the original buffers
> > directly.
> >
> > [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2
> >
> > Signed-off-by: Paul Durrant
>
>
> Stefano,
>
> Are you OK with ARM changes?
Yes:
Acked-by: Stefano Stabellini
Thanks for CC'ing me, I missed the patch.
>
>
> > ---
> > Cc: Boris Ostrovsky
> > Cc: Juergen Gross
> >
> > v3:
> > - Add module parameters for max number of dm_op buffers and max buffer
> > size
> > - Fix arm build
> > - Fix commit comment to reflect re-worked patch
> >
> > v2:
> > - Lock the user pages rather than bouncing through kernel memory
> > ---
> > arch/arm/xen/enlighten.c | 1 +
> > arch/arm/xen/hypercall.S | 1 +
> > arch/arm64/xen/hypercall.S | 1 +
> > arch/x86/include/asm/xen/hypercall.h | 7 ++
> > drivers/xen/privcmd.c| 139
> > +++
> > include/uapi/xen/privcmd.h | 13
> > include/xen/arm/hypercall.h | 1 +
> > include/xen/interface/hvm/dm_op.h| 32
> > include/xen/interface/xen.h | 1 +
> > 9 files changed, 196 insertions(+)
> > create mode 100644 include/xen/interface/hvm/dm_op.h
> >
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 11d9f28..81e3217 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -457,4 +457,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> > EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
> > EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> > EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> > EXPORT_SYMBOL_GPL(privcmd_call);
> > diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> > index a648dfc..b0b80c0 100644
> > --- a/arch/arm/xen/hypercall.S
> > +++ b/arch/arm/xen/hypercall.S
> > @@ -92,6 +92,7 @@ HYPERCALL1(tmem_op);
> > HYPERCALL1(platform_op_raw);
> > HYPERCALL2(multicall);
> > HYPERCALL2(vm_assist);
> > +HYPERCALL3(dm_op);
> >
> > ENTRY(privcmd_call)
> > stmdb sp!, {r4}
> > diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> > index 947830a..401ceb7 100644
> > --- a/arch/arm64/xen/hypercall.S
> > +++ b/arch/arm64/xen/hypercall.S
> > @@ -84,6 +84,7 @@ HYPERCALL1(tmem_op);
> > HYPERCALL1(platform_op_raw);
> > HYPERCALL2(multicall);
> > HYPERCALL2(vm_assist);
> > +HYPERCALL3(dm_op);
> >
> > ENTRY(privcmd_call)
> > mov x16, x0
> > diff --git a/arch/x86/include/asm/xen/hypercall.h
> > b/arch/x86/include/asm/xen/hypercall.h
> > index a12a047..f6d20f6 100644
> > --- a/arch/x86/include/asm/xen/hypercall.h
> > +++ b/arch/x86/include/asm/xen/hypercall.h
> > @@ -472,6 +472,13 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg)
> > return _hypercall2(int, xenpmu_op, op, arg);
> > }
> >
> > +static inline int
> > +HYPERVISOR_dm_op(
> > + domid_t dom, unsigned int nr_bufs, void *bufs)
> > +{
> > + return _hypercall3(int, dm_op, dom, nr_bufs, bufs);
> > +}
> > +
> > static inline void
> > MULTI_fpu_taskswitch(struct multicall_entry *mcl, int set)
> > {
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index 5e5c7ae..a33f17e 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -22,6 +22,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -32,6 +33,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -43,6 +45,17 @@ MODULE_LICENSE("GPL");
> >
> > #define PRIV_VMA_LOCKED ((void *)1)
> >
> > +unsigned int privcmd_dm_op_max_num = 16;
> > +module_param_named(dm_op_max_nr_bufs, privcmd_dm_op_max_num, uint, 0644);
> > +MODULE_PARM_DESC(dm_op_max_nr_bufs,
> > +"Maximum number of buffers per dm_op hypercall");
> > +
> > +unsigned int privcmd_dm_op_buf_max_size = XEN_PAGE_SIZE;
> > +module_param_named(dm_op_buf_max_size, privcmd_dm_op_buf_max_size, uint,
> > + 0644);
> > +MODULE_PARM_DESC(dm_op_buf_max_size,
> > +"Maximum size of a dm_op hypercall buffer");
> > +
> > static int privcmd_vma_range_is_mapped(
> > struct vm_area_struct *vma,
> > unsigned long addr,
> > @@ -548,6 +561,128 @@ static long privcmd_ioctl_mmap_batch(void __user
> > *udata, int version)
> > goto out;
> > }
Re: [Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms
On Tue, Feb 14, 2017 at 07:33:24PM +0100, Daniel Kiper wrote: > This way Xen can be loaded on EFI platforms using GRUB2 and > other boot loaders which support multiboot2 protocol. > > Signed-off-by: Daniel Kiper I am posting diff between v14 and v15 for your convenience. diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index 5147204..eb738d4 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -394,10 +394,18 @@ __start: /* EFI IA-32 platforms are not supported. */ cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx) +/* + * Here we should zap vga_text_buffer. However, we can disable + * VGA updates in simpler and more reliable way later. + */ je .Lmb2_efi_ia_32 /* Bootloader shutdown EFI x64 boot services. */ cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%ecx) +/* + * Here we should zap vga_text_buffer. However, we can disable + * VGA updates in simpler and more reliable way later. + */ je .Lmb2_no_bs /* Is it the end of Multiboot2 information? */ diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c index 2127cce..17da050 100644 --- a/xen/arch/x86/efi/stub.c +++ b/xen/arch/x86/efi/stub.c @@ -34,10 +34,10 @@ void __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle, * not be directly supported by C compiler. */ asm volatile( -"call *%2 \n" +"call *%3 \n" "0: hlt \n" "jmp 0b \n" - : "+c" (StdErr) : "d" (err), "rm" (StdErr->OutputString) + : "+c" (StdErr), "=d" (StdErr) : "1" (err), "rm" (StdErr->OutputString) : "rax", "r8", "r9", "r10", "r11", "memory"); unreachable(); ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 105790: regressions - FAIL
flight 105790 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105790/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 105756 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 105756 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105756 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105756 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105756 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-xtf-amd64-amd64-11 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-21 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-rumprun 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-41 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-31 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-xtf-amd64-amd64-51 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 bu
[Xen-devel] [PATCH v15 10/10] x86: add multiboot2 protocol support for relocatable images
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
(suggested by Doug Goldstein).
v9 - suggestions/fixes:
- use .L labels instead of numeric ones in multiboot2 data scanning loop
(suggested by Jan Beulich).
v4 - suggestions/fixes:
- do not get Xen image load base address from
multiboot2 information in x86_64 code
(suggested by Jan Beulich),
- improve label names
(suggested by Jan Beulich),
- improve comments,
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- use %esi and %r15d instead of %ebp to store
Xen image load base address,
- rename some types and constants,
- reformat xen/include/xen/multiboot2.h
(suggested by Konrad Rzeszutek Wilk),
- improve comments,
- improve commit message
(suggested by Konrad Rzeszutek Wilk).
---
xen/arch/x86/boot/head.S | 16
xen/arch/x86/x86_64/asm-offsets.c |1 +
xen/include/xen/multiboot2.h | 13 +
3 files changed, 30 insertions(+)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index ebcc28b..b2601a7 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
/* Align modules at page boundry. */
mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+ sym_offs(start), /* Min load address. */ \
+ 0x, /* The end of image max load address (4 GiB -
1). */ \
+ 0x20, /* Load address alignment (2 MiB). */ \
+ MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
/* Console flags tag. */
mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -390,6 +397,15 @@ __start:
cmp %edi,MB2_fixed_total_size(%ebx)
jbe trampoline_bios_setup
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne .Lmb2_mem_lower
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp .Lmb2_next_tag
+
+.Lmb2_mem_lower:
/* Get mem_lower from Multiboot2 information. */
cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
cmove MB2_mem_lower(%ecx),%edx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c
b/xen/arch/x86/x86_64/asm-offsets.c
index 87e573a..85639e4 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -174,6 +174,7 @@ void __dummy__(void)
OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
OFFSET(MB2_tag_type, multiboot2_tag_t, type);
OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t,
load_base_addr);
OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index a3e3119..5acd225 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
#define MULTIBOOT2_HEADER_TAG_EFI_BS7
#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32 8
#define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64 9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE 10
/* Header tag flags. */
#define MULTIBOOT2_HEADER_TAG_REQUIRED 0
#define MULTIBOOT2_HEADER_TAG_OPTIONAL 1
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH 2
+
/* Header console tag console_flags. */
#define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
#define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
@@ -90,6 +96,7 @@
#define MULTIBOOT2_TAG_TYPE_EFI_BS 18
#define MULTIBOOT2_TAG_TYPE_EFI32_IH19
#define MULTIBOOT2_TAG_TYPE_EFI64_IH20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR 21
/* Multiboot 2 tag alignment. */
#define MULTIBOOT2_TAG_ALIGN8
@@ -120,6 +127,12 @@ typedef struct {
typedef struct {
u32 type;
u32 size;
+u32 load_base_addr;
+} multiboot2_tag_loa
[Xen-devel] [PATCH v15 09/10] x86/boot: rename sym_phys() to sym_offs()
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan Beulich
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v8 - suggestions/fixes:
- improve commit message
(suggested by Jan Beulich).
---
xen/arch/x86/boot/head.S | 38 +++---
xen/arch/x86/boot/trampoline.S |2 +-
xen/arch/x86/boot/wakeup.S |4 ++--
xen/arch/x86/boot/x86_64.S | 18 +-
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 4fbf776..ebcc28b 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,9 +12,9 @@
.text
.code32
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
-#define sym_esi(sym) sym_phys(sym)(%esi)
-#define sym_fs(sym) %fs:sym_phys(sym)
+#define sym_offs(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym) sym_offs(sym)(%esi)
+#define sym_fs(sym) %fs:sym_offs(sym)
#define BOOT_CS320x0008
#define BOOT_CS640x0010
@@ -97,7 +97,7 @@ multiboot2_header_start:
/* EFI64 Multiboot2 entry point. */
mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
- sym_phys(__efi64_mb2_start)
+ sym_offs(__efi64_mb2_start)
/* Multiboot2 header end tag. */
mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -119,7 +119,7 @@ multiboot2_header_start:
gdt_boot_descr:
.word 7*8-1
gdt_boot_base:
-.long sym_phys(trampoline_gdt)
+.long sym_offs(trampoline_gdt)
.long 0 /* Needed for 64-bit lgdt */
vga_text_buffer:
@@ -131,23 +131,23 @@ efi_platform:
.section .init.text, "ax", @progbits
bad_cpu:
-add $sym_phys(.Lbad_cpu_msg),%esi # Error message
+add $sym_offs(.Lbad_cpu_msg),%esi # Error message
jmp .Lget_vtb
not_multiboot:
-add $sym_phys(.Lbad_ldr_msg),%esi # Error message
+add $sym_offs(.Lbad_ldr_msg),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_st:
-add $sym_phys(.Lbad_ldr_nst),%esi # Error message
+add $sym_offs(.Lbad_ldr_nst),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_ih:
-add $sym_phys(.Lbad_ldr_nih),%esi # Error message
+add $sym_offs(.Lbad_ldr_nih),%esi # Error message
jmp .Lget_vtb
.Lmb2_no_bs:
-add $sym_phys(.Lbad_ldr_nbs),%esi # Error message
+add $sym_offs(.Lbad_ldr_nbs),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lmb2_efi_ia_32:
-add $sym_phys(.Lbad_efi_msg),%esi # Error message
+add $sym_offs(.Lbad_efi_msg),%esi # Error message
xor %edi,%edi # No VGA text buffer
jmp .Lsend_chr
.Lget_vtb:
@@ -358,7 +358,7 @@ __start:
cli
/* Load default Xen image load base address. */
-mov $sym_phys(__image_base__),%esi
+mov $sym_offs(__image_base__),%esi
/* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
xor %edx,%edx
@@ -538,8 +538,8 @@ trampoline_setup:
jnz 1f
/* Initialize BSS (no nasty surprises!). */
-mov $sym_phys(__bss_start),%edi
-mov $sym_phys(__bss_end),%ecx
+mov $sym_offs(__bss_start),%edi
+mov $sym_offs(__bss_end),%ecx
push%fs
pop %es
sub %edi,%ecx
@@ -612,22 +612,22 @@ trampoline_setup:
/* Apply relocations to bootstrap trampoline. */
mov sym_fs(trampoline_phys),%edx
-mov $sym_phys(__trampoline_rel_start),%edi
+mov $sym_offs(__trampoline_rel_start),%edi
1:
mov %fs:(%edi),%eax
add %edx,%fs:(%edi,%eax)
add $4,%edi
-cmp $sym_phys(__trampoline_rel_stop),%edi
+cmp $sym_offs(__trampoline_rel_stop),%edi
jb 1b
/* Patch in the trampoline segment. */
shr $4,%edx
-mov $sym_phys(__trampoline_seg_start),%edi
+mov $sym_offs(__trampoline_seg_start),%edi
1:
mov %fs:(%edi),%eax
mov %dx,%fs:(%edi,%eax)
add $4,%edi
-cmp $sym_phys(__trampoline_seg_stop),%edi
+cmp $sym_offs(__trampoline_seg_stop),%edi
jb 1b
/* Do not parse command line on EFI platform here. */
@@ -653,7 +653,7 @@ trampoline_setup:
push%eax
/* Copy bootstrap trampoline to low memory, below 1MB. */
-mov $sym_phys(trampoline_star
[Xen-devel] [PATCH v15 07/10] x86/setup: use XEN_IMG_OFFSET instead of...
..calculating its value during runtime. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Reviewed-by: Doug Goldstein --- xen/arch/x86/setup.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 525ce7a..a5ce926 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -943,7 +943,6 @@ void __init noreturn __start_xen(unsigned long mbi_p) l4_pgentry_t *pl4e; l3_pgentry_t *pl3e; l2_pgentry_t *pl2e; -uint64_t load_start; int i, j, k; /* Select relocation address. */ @@ -957,9 +956,8 @@ void __init noreturn __start_xen(unsigned long mbi_p) * with a barrier(). After this we must *not* modify static/global * data until after we have switched to the relocated pagetables! */ -load_start = (unsigned long)_start - XEN_VIRT_START; barrier(); -move_memory(e + load_start, load_start, _end - _start, 1); +move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1); /* Walk initial pagetables, relocating page directory entries. */ pl4e = __va(__pa(idle_pg_table)); -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v15 08/10] x86: make Xen early boot code relocatable
Every multiboot protocol (regardless of version) compatible image must specify its load address (in ELF or multiboot header). Multiboot protocol compatible loader have to load image at specified address. However, there is no guarantee that the requested memory region (in case of Xen it starts at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a RAM and it is free (legacy BIOS platforms are merciful for Xen but I found at least one EFI platform on which Xen load address conflicts with EFI boot services; it is Dell PowerEdge R820 with latest firmware). To cope with that problem we must make Xen early boot code relocatable and help boot loader to relocate image in proper way by suggesting, not requesting specific load addresses as it is right now, allowed address ranges. This patch does former. It does not add multiboot2 protocol interface which is done in "x86: add multiboot2 protocol support for relocatable images" patch. This patch changes following things: - %esi register is used as a storage for Xen image load base address; it is mostly unused in early boot code and preserved during C functions calls in 32-bit mode, - %fs is used as base for Xen data relative addressing in 32-bit code if it is possible; %esi is used for that thing during error printing because it is not always possible to properly and efficiently initialize %fs. Signed-off-by: Daniel Kiper --- v13 - suggestions/fixes: - move gdt_boot_descr to .init.data section (suggested by Jan Beulich). v12 - suggestions/fixes: - store Xen image load base address directly into %esi, - store Xen image load base address after x86_32_switch (suggested by Doug Goldstein), - improve commit message. v8 - suggestions/fixes: - use shld instead of mov and shr in BOOT_FS segment descriptor base address initialization (suggested by Jan Beulich), - simplify code updating frame addresses in page tables (suggested by Jan Beulich), - print Xen image base addresses using "%#lx" format (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v6 - suggestions/fixes: - leave static mapping of first 16 MiB in l2_identmap as is (suggested by Jan Beulich), - use xen_phys_start instead of xen_img_load_base_addr (suggested by Daniel Kiper and Jan Beulich), - simplify BOOT_FS segment descriptor base address initialization (suggested by Jan Beulich), - fix BOOT_FS segment limit (suggested by Jan Beulich), - do not rename sym_phys in this patch (suggested by Jan Beulich), - rename esi_offset/fs_offset to sym_esi/sym_fs respectively (suggested by Jan Beulich), - use add instead of lea in assembly error printing code (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - improve commit message (suggested by Jan Beulich), - various minor cleanups and fixes (suggested by Jan Beulich). v4 - suggestions/fixes: - do not relocate Xen image if boot loader did work for us (suggested by Andrew Cooper and Jan Beulich), - initialize xen_img_load_base_addr in EFI boot code too, - properly initialize trampoline_xen_phys_start, - calculate Xen image load base address in x86_64 code ourselves, (suggested by Jan Beulich), - change how and when Xen image base address is printed, - use %fs instead of %esi for relative addressing (suggested by Andrew Cooper and Jan Beulich), - create esi_offset and fs_offset() macros in assembly, - calculate mkelf32 argument automatically, - optimize and cleanup code, - improve comments, - improve commit message. v3 - suggestions/fixes: - improve segment registers initialization (suggested by Jan Beulich), - simplify Xen image load base address calculation (suggested by Jan Beulich), - use %esi and %r15d instead of %ebp to store Xen image load base address, - use %esi instead of %fs for relative addressing; this way we get shorter and simpler code, - rename some variables and constants (suggested by Jan Beulich), - improve comments (suggested by Konrad Rzeszutek Wilk), - improve commit message (suggested by Jan Beulich). --- xen/arch/x86/boot/head.S | 170 - xen/arch/x86/boot/trampoline.S|5 ++ xen/arch/x86/boot/x86_64.S| 21 +++-- xen/arch/x86/setup.c | 14 +-- xen/arch/x86/x86_64/asm-offsets.c |3 + xen/include/asm-x86/page.h|2 +- 6 files changed, 158 insertions(+), 57 deletions(-) diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S index fca0cef..4fbf776 100644 --- a/xen/arch/x86/boot/head.S +++ b/xen/arch/x86/boot/head.S @@ -13,12 +13,15 @@ .code32 #define sym_phys(sym) ((sym) - __XEN_VIRT_START) +#define sym_esi(sym) sym_phys(sym)(%esi) +#define sym_fs(sym) %fs:sym_
[Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms
This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper --- v15 - suggestions/fixes: - rearrange inline assembly arguments in xen/arch/x86/efi/stub.c:efi_multiboot2() (suggested by Jan Beulich), - improve comments in error handling in legacy BIOS Multiboot2 scanning loop (suggested by Jan Beulich). v14 - suggestions/fixes: - mark .init.data section as writable; by the way we must change similar definition in xen/arch/x86/boot/x86_64.S because otherwise compiler complains about section types conflicts (suggested by Jan Beulich), - use %r15 instead of %r15d (suggested by Jan Beulich), - remove redundant add from UEFI stack alignment (suggested by Jan Beulich), - use "mov (%rsp),%rdi" instead of "pop %rdi/push %rdi" (suggested by Jan Beulich), - return void instead of paddr_t from efi_multiboot2() and then simplify a bit trampoline setup assembly (suggested by Jan Beulich), - remove "(XEN)" from efi_multiboot2() stub error messages (suggested by Jan Beulich), - move err from inline assembly OutputOperands to InputOperands in stub.c:efi_multiboot2(); this way we avoid following compile time error: stub.c: In function ‘efi_multiboot2’: stub.c:36:5: error: read-only variable ‘err’ used as ‘asm’ output asm volatile( ^~~ issue was introduced by changing err type to "static const CHAR16 __initconst"; potentially we can revert this change but move to InputOperands looks better IMO; even if we are not able to specify %rdx in Clobbers; simply we do not care because next instruction after call is hlt (discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga), - take into account MBI_SPACE_MIN in ASSERT((trampoline_end - trampoline_start) < ...) (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v13 - suggestions/fixes: - move vga_text_buffer and efi_platform to .init.data section (suggested by Jan Beulich), - reduce number of error branches in EFI code in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - rename run_bs label to .Lrun_bs (suggested by Jan Beulich), - align the stack as UEFI spec requires (suggested by Jan Beulich), - change trampoline region memory layout (suggested by Jan Beulich), - revert changes in efi_arch_pre_exit_boot() (suggested by Jan Beulich), - relocate_trampoline() must set trampoline_phys for all bootloaders; otherwise fallback allocator is always used if Xen was loaded with Multiboot2 protocol, - change err type in efi_multiboot2() to "static const CHAR16 __initconst" (suggested by Jan Beulich), - change asm "g" constraint to "rm" in efi_multiboot2() (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich and Doug Goldstein). v12 - suggestions/fixes: - rename __efi64_start to __efi64_mb2_start (suggested by Andrew Cooper), - use efi_arch_memory_setup() machinery as trampoline et consortes main memory allocator (suggested by Doug Goldstein), - allocate space for mbi struct in efi_arch_memory_setup() too; this thing was not taken into account in earlier releases, - revert trampoline et consortes fallback memory allocator code in efi_arch_process_memory_map() to current upstream state (suggested by Doug Goldstein), - further simplify efi_arch_pre_exit_boot() code, - call efi_arch_memory_setup() from efi_multiboot2() (suggested by Doug Goldstein), - fix asembly call argument in xen/arch/x86/efi/stub.c (suggested by Andrew Cooper), - add ASSERT() for trampoline size (suggested by Doug Goldstein), - add KB() macro (suggested by Doug Goldstein), - improve comments (suggested by Andrew Cooper and Doug Goldstein). v10 - suggestions/fixes: - replace ljmpl with lretq (suggested by Andrew Cooper), - introduce efi_platform to increase code readability (suggested by Andrew Cooper). v9 - suggestions/fixes: - use .L labels instead of numeric ones in multiboot2 data scanning loops (suggested by Jan Beulich). v8 - suggestions/fixes: - use __bss_start(%rip)/__bss_end(%rip) instead of of .startof.(.bss)(%rip)/$.sizeof.(.bss) because latter is not tested extensively in different built environments yet (suggested by Andrew Cooper), - fix multiboot2 data scanning loop in x86_32 code (suggested by Jan Beulich), - add check for extra mem for mbi data if Xen is loaded via multiboot2 protocol on EFI platform (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich). v7 - suggestions/fixes: - do not allocate twice memory for trampoline if we were loaded via multiboo
[Xen-devel] [PATCH v15 01/10] x86: add "w" flag to .init.data section definition
init.data section is clearly writable, so, add "w" flag to its definition in xen/arch/x86/boot/x86_64.S. Signed-off-by: Daniel Kiper --- xen/arch/x86/boot/x86_64.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S index 139b2ca..4d507fb 100644 --- a/xen/arch/x86/boot/x86_64.S +++ b/xen/arch/x86/boot/x86_64.S @@ -186,7 +186,7 @@ GLOBAL(idle_pg_table) GLOBAL(__page_tables_end) /* Init pagetables. Enough page directories to map into the bottom 1GB. */ -.section .init.data, "a", @progbits +.section .init.data, "aw", @progbits .align PAGE_SIZE, 0 GLOBAL(l2_bootmap) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v15 03/10] efi: build xen.gz with EFI code
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v14 - suggestions/fixes:
- at least GNU Make 4.1 does not build efi/buildid.o if nothing
depends on it; so, add "boot.init.o: buildid.o" dependency to
force efi/buildid.o on some versions of make; I hope that this
small change does not invalidate Acked-by/Reviewed-by; however,
I am dropping Tested-by
(discovered by Konrad Rzeszutek Wilk and Marcos Matsunaga).
v6 - suggestions/fixes:
- improve efi_enabled() checks in efi_runtime_call()
(suggested by Jan Beulich).
v5 - suggestions/fixes:
- properly calculate efi symbol address in
xen/arch/x86/xen.lds.S (I hope that this
change does not invalidate Jan's ACK).
v4 - suggestions/fixes:
- functions should return -ENOSYS instead
of -EOPNOTSUPP if EFI runtime services
are not available
(suggested by Jan Beulich),
- remove stale bits from xen/arch/x86/Makefile
(suggested by Jan Beulich).
v3 - suggestions/fixes:
- check for EFI platform in EFI code
(suggested by Jan Beulich),
- fix Makefiles
(suggested by Jan Beulich),
- improve commit message
(suggested by Jan Beulich).
v2 - suggestions/fixes:
- build EFI code only if it is supported in a given build environment
(suggested by Jan Beulich).
---
xen/arch/x86/Makefile |2 +-
xen/arch/x86/efi/Makefile | 14 ++
xen/arch/x86/xen.lds.S|4 ++--
xen/common/efi/boot.c |3 +++
xen/common/efi/runtime.c |9 +
5 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 007dced..08e9f7b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -219,6 +219,6 @@ efi/mkreloc: efi/mkreloc.c
clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
- rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi
efi/disabled efi/mkreloc
+ rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..3edff1c 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,16 @@
CFLAGS += -fshort-wchar
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
efi := y$(shell rm -f disabled)
efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c
check.c 2>disabled && echo y))
efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o);
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
%.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
-stub.o: $(extra-y)
+boot.init.o: buildid.o
+
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7676de9..b0b1c9b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,10 +270,10 @@ SECTIONS
.pad : {
. = ALIGN(MB(16));
} :text
-#else
- efi = .;
#endif
+ efi = DEFINED(efi) ? efi : .;
+
/* Sections to be discarded */
/DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 3e5e4ab..df8c702 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -125
[Xen-devel] [PATCH v15 06/10] x86: change default load address from 1 MiB to 2 MiB
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load address from 1 MiB to 2 MiB. This way page table
code will be nice and easy. Hence, there is a chance that it will be
less error prone too... :-)))
Additionally, drop first 2 MiB mapping from Xen image mapping.
It is no longer needed.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
v8 - suggestions/fixes:
- drop first 2 MiB mapping from Xen image mapping
(suggested by Jan Beulich),
- improve commit message.
v7 - suggestions/fixes:
- minor cleanups
(suggested by Jan Beulich).
---
xen/arch/x86/Makefile |2 +-
xen/arch/x86/Rules.mk |3 +++
xen/arch/x86/boot/head.S |8
xen/arch/x86/boot/x86_64.S |5 +++--
xen/arch/x86/setup.c |3 ++-
xen/arch/x86/xen.lds.S |2 +-
6 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 08e9f7b..e5b840e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -90,7 +90,7 @@ all_symbols =
endif
$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
- ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
+ ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET)
$(XEN_IMG_OFFSET) \
`$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) .
__2M_rwdata_end$$/0x\1/p'`
ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 72be8b2..568657e 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,12 @@
# x86-specific definitions
+XEN_IMG_OFFSET := 0x20
+
CFLAGS += -I$(BASEDIR)/include
CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst
$(BASEDIR)/,,$(CURDIR))/$@))'
# Prevent floating-point variables from creeping into Xen.
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index eb738d4..fca0cef 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -519,14 +519,6 @@ trampoline_setup:
mov %eax,sym_phys(boot_tsc_stamp)
mov %edx,sym_phys(boot_tsc_stamp+4)
-/*
- * During boot, hook 4kB mappings of first 2MB of memory into L2.
- * This avoids mixing cachability for the legacy VGA region, and is
- * corrected when Xen relocates itself.
- */
-mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
-mov %edi,sym_phys(l2_xenmap)
-
/* Apply relocations to bootstrap trampoline. */
mov sym_phys(trampoline_phys),%edx
mov $sym_phys(__trampoline_rel_start),%edi
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 4d507fb..f9d1022 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -121,8 +121,9 @@ GLOBAL(l2_identmap)
* page.
*/
GLOBAL(l2_xenmap)
-idx = 0
-.rept 8
+.quad 0
+idx = 1
+.rept 7
.quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) +
(PAGE_HYPERVISOR | _PAGE_PSE)
idx = idx + 1
.endr
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e1b6590..525ce7a 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -999,7 +999,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
* Undo the temporary-hooking of the l1_identmap. __2M_text_start
* is contained in this PTE.
*/
-BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+BUG_ON(using_2M_mapping() &&
+ l2_table_offset((unsigned long)_erodata) ==
l2_table_offset((unsigned long)_stext));
*pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 76e18ab..6039496 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -55,7 +55,7 @@ SECTIONS
__2M_text_start = .; /* Start of 2M superpages, mapped RX. */
#endif
- . = __XEN_VIRT_START + MB(1);
+ . = __XEN_VIRT_START + XEN_IMG_OFFSET;
_start = .;
.text : {
_stext = .;/* Text and read-only data */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v15 04/10] efi: create new early memory allocator
There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB address and we should not allocate a memory from below of it. So, I tried to use mem_lower address calculated by GRUB2. However, this solution works only on some machines. There are machines in the wild (e.g. Dell PowerEdge R820) which uses first ~640 KiB for boot services code or data... :-((( Hence, we need new memory allocator for Xen EFI boot code which is quite simple and generic and could be used by place_string() and efi_arch_allocate_mmap_buffer(). I think about following solutions: 1) We could use native EFI allocation functions (e.g. AllocatePool() or AllocatePages()) to get memory chunk. However, later (somewhere in __start_xen()) we must copy its contents to safe place or reserve it in e820 memory map and map it in Xen virtual address space. This means that the code referring to Xen command line, loaded modules and EFI memory map, mostly in __start_xen(), will be further complicated and diverge from legacy BIOS cases. Additionally, both former things have to be placed below 4 GiB because their addresses are stored in multiboot_info_t structure which has 32-bit relevant members. 2) We may allocate memory area statically somewhere in Xen code which could be used as memory pool for early dynamic allocations. Looks quite simple. Additionally, it would not depend on EFI at all and could be used on legacy BIOS platforms if we need it. However, we must carefully choose size of this pool. We do not want increase Xen binary size too much and waste too much memory but also we must fit at least memory map on x86 EFI platforms. As I saw on small machine, e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more than 200 entries. Every entry on x86-64 platform is 40 bytes in size. So, it means that we need more than 8 KiB for EFI memory map only. Additionally, if we use this memory pool for Xen and modules command line storage (it would be used when xen.efi is executed as EFI application) then we should add, I think, about 1 KiB. In this case, to be on safe side, we should assume at least 64 KiB pool for early memory allocations. Which is about 4 times of our earlier calculations. However, during discussion on Xen-devel Jan Beulich suggested that just in case we should use 1 MiB memory pool like it is in original place_string() implementation. So, let's use 1 MiB as it was proposed. If we think that we should not waste unallocated memory in the pool on running system then we can mark this region as __initdata and move all required data to dynamically allocated places somewhere in __start_xen(). 2a) We could put memory pool into .bss.page_aligned section. Then allocate memory chunks starting from the lowest address. After init phase we can free unused portion of the memory pool as in case of .init.text or .init.data sections. This way we do not need to allocate any space in image file and freeing of unused area in the memory pool is very simple. Now #2a solution is implemented because it is quite simple and requires limited number of changes, especially in __start_xen(). New allocator is quite generic and can be used on ARM platforms too. Though it is not enabled on ARM yet due to lack of some prereq. List of them is placed before ebmalloc code. Signed-off-by: Daniel Kiper Acked-by: Jan Beulich Acked-by: Julien Grall Reviewed-by: Doug Goldstein Tested-by: Doug Goldstein --- v11 - suggestions/fixes: - #ifdef only EBMALLOC_SIZE from ebmalloc machinery (suggested by Jan Beulich). v10 - suggestions/fixes: - remove unneeded ARM free_ebmalloc_unused_mem() stub. v9 - suggestions/fixes: - call free_ebmalloc_unused_mem() from efi_init_memory() instead of xen/arch/arm/setup.c:init_done() (suggested by Jan Beulich), - improve comments. v8 - suggestions/fixes: - disable whole ebmalloc machinery on ARM platforms, - add comment saying what should be done before enabling ebmalloc on ARM, (suggested by Julien Grall), - move ebmalloc code before efi-boot.h inclusion and remove unneeded forward declaration (suggested by Jan Beulich), - remove free_ebmalloc_unused_mem() call from xen/arch/arm/setup.c:init_done() (suggested by Julien Grall), - improve commit message. v7 - suggestions/fixes: - enable most of ebmalloc machinery on ARM platforms (suggested by Jan Beulich), - remove unneeded cast (suggested by Jan Beulich), - wrap long line (suggested by Jan Beulich), - improve commit message. v6 - suggestions/fixes: - optimize ebmalloc allocator, - move ebmalloc machinery to xen/common/efi/boot.c (suggested by Jan Beulich), - enforce PAGE_SIZE
[Xen-devel] [PATCH v15 02/10] x86: add multiboot2 protocol support
Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper Reviewed-by: Jan Beulich Reviewed-by: Doug Goldstein Reviewed-by: Andrew Cooper Tested-by: Doug Goldstein --- v13 - suggestions/fixes: - add Emacs file-local variables (suggested by Andrew Cooper). v12 - suggestions/fixes: - replace TABs with spaces in xen/include/xen/multiboot2.h (suggested by Doug Goldstein). v9 - suggestions/fixes: - use .L label instead of numeric one in multiboot2 data scanning loop; I hope that this change does not invalidate Jan's Reviewed-by (suggested by Jan Beulich). v8 - suggestions/fixes: - use sizeof(/) instead of sizeof() if it is possible (suggested by Jan Beulich). v7 - suggestions/fixes: - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively (suggested by Jan Beulich), - initialize mbi_out->flags using "|=" instead of "=" (suggested by Jan Beulich), - use sizeof(*mmap_dst) instead of sizeof(memory_map_t) if it makes sense (suggested by Jan Beulich). v6 - suggestions/fixes: - properly index multiboot2_tag_mmap_t.entries[] (suggested by Jan Beulich), - do not index mbi_out_mods[] beyond its end (suggested by Andrew Cooper), - reduce number of casts (suggested by Andrew Cooper and Jan Beulich), - add braces to increase code readability (suggested by Andrew Cooper). v5 - suggestions/fixes: - check multiboot2_tag_mmap_t.entry_size before multiboot2_tag_mmap_t.entries[] use (suggested by Jan Beulich), - properly index multiboot2_tag_mmap_t.entries[] (suggested by Jan Beulich), - use "type name[]" instad of "type name[0]" in xen/include/xen/multiboot2.h (suggested by Jan Beulich), - remove unneeded comment (suggested by Jan Beulich). v4 - suggestions/fixes: - avoid assembly usage in xen/arch/x86/boot/reloc.c, - fix boundary check issue and optimize for() loops in mbi2_mbi(), - move to stdcall calling convention, - remove unneeded typeof() from ALIGN_UP() macro (suggested by Jan Beulich), - add and use NULL definition in xen/arch/x86/boot/reloc.c (suggested by Jan Beulich), - do not read data beyond the end of multiboot2 information in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - add :req to some .macro arguments (suggested by Jan Beulich), - use cmovcc if possible, - add .L to multiboot2_header_end label (suggested by Jan Beulich), - add .L to multiboot2_proto label (suggested by Jan Beulich), - improve label names (suggested by Jan Beulich). v3 - suggestions/fixes: - reorder reloc() arguments (suggested by Jan Beulich), - remove .L from multiboot2 header labels (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk), - take into account alignment when skipping multiboot2 fixed part (suggested by Konrad Rzeszutek Wilk), - create modules data if modules count != 0 (suggested by Jan Beulich), - improve macros (suggested by Jan Beulich), - reduce number of casts (suggested by Jan Beulich), - use const if possible (suggested by Jan Beulich), - drop static and __used__ attribute from reloc() (suggested by Jan Beulich), - remove isolated/stray __packed attribute from multiboot2_memory_map_t type definition (suggested by Jan Beulich), - reformat xen/include/xen/multiboot2.h (suggested by Konrad Rzeszutek Wilk), - improve comments (suggested by Konrad Rzeszutek Wilk), - remove hard tabs (suggested by Jan Beulich and Konrad Rzeszutek Wilk). v2 - suggestions/fixes: - generate multiboot2 header using macros (suggested by Jan Beulich), - improve comments (suggested by Jan Beulich), - simplify assembly in xen/arch/x86/boot/head.S (suggested by Jan Beulich), - do not include include/xen/compiler.h in xen/arch/x86/boot/reloc.c (suggested by Jan Beulich), - do not read data beyond the end of multiboot2 information (suggested by Jan Beulich). v2 - not fixed yet: - dynamic dependency generation for xen/arch/x86/boot/reloc.S; this requires more work; I am not sure that it pays because potential patch requires more changes than addition of just multiboot2.h to Makefile (suggested by Jan Beulich), - isolated/stray __packed attribute usage for multiboot2_memory_map_t (suggested by Jan Beulich). --- xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 107 ++- xen/arch/x86/boot/reloc.c | 154 +++-- xen/arch/x86/x86_64/asm-offsets.c |9 ++ xen/include/xen/multiboot2.h | 169 + 5 files changed, 432 ins
[Xen-devel] [PATCH v15 00/10] x86: multiboot2 protocol support
Hi, I am sending fifteenth version of multiboot2 protocol support for legacy BIOS and EFI platforms. This patch series release contains fixes for all known/confirmed issues. The final goal is xen.efi binary file which could be loaded by EFI loader, multiboot (v1) protocol (only on legacy BIOS platforms) and multiboot2 protocol. This way we will have: - smaller Xen code base, - one code base for xen.gz and xen.efi, - one build method for xen.gz and xen.efi; xen.efi will be extracted from xen(-syms) file using objcopy or special custom tool, - xen.efi build will not so strongly depend on a given GCC and binutils version. Here is short list of changes since v14: - new patch: 1, - changed patch: 5. If you are not interested in this patch series at all please drop me a line and I will remove you from distribution list. Daniel xen/arch/x86/Makefile |4 +- xen/arch/x86/Rules.mk |3 + xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 578 ++ xen/arch/x86/boot/reloc.c | 154 +- xen/arch/x86/boot/trampoline.S|7 +- xen/arch/x86/boot/wakeup.S|4 +- xen/arch/x86/boot/x86_64.S| 46 +++ xen/arch/x86/efi/Makefile | 14 +- xen/arch/x86/efi/efi-boot.h | 60 +++-- xen/arch/x86/efi/stub.c | 39 ++ xen/arch/x86/setup.c | 24 ++-- xen/arch/x86/x86_64/asm-offsets.c | 15 +++ xen/arch/x86/xen.lds.S| 13 +- xen/common/efi/boot.c | 64 + xen/common/efi/runtime.c |9 ++ xen/include/asm-x86/config.h |5 + xen/include/asm-x86/page.h|2 +- xen/include/xen/config.h |1 + xen/include/xen/multiboot2.h | 182 ++ 20 files changed, 1103 insertions(+), 124 deletions(-) Daniel Kiper (10): x86: add "w" flag to .init.data section definition x86: add multiboot2 protocol support efi: build xen.gz with EFI code efi: create new early memory allocator x86: add multiboot2 protocol support for EFI platforms x86: change default load address from 1 MiB to 2 MiB x86/setup: use XEN_IMG_OFFSET instead of... x86: make Xen early boot code relocatable x86/boot: rename sym_phys() to sym_offs() x86: add multiboot2 protocol support for relocatable images ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] STAO spec in xen.git
On Tue, 14 Feb 2017, Olaf Hering wrote: > On Tue, Jan 17, Stefano Stabellini wrote: > > > On Tue, 17 Jan 2017, Olaf Hering wrote: > > > On Fri, Jan 13, Julien Grall wrote: > > > > > > > Regarding the format. Does ODT will allow git to do proper diff? > > > > > > There is flat ODT, "Safe as ..." and pick the better format from the > > > pulldown menu. > > > > Sounds like a good idea. Can you submit a patch? > > Done, see 'docs: convert from binary to ASCII'. > > For some reason results of 'git rm' are not noticed by > get-maintainer.pl, see xen-devel for a copy of the removal. Interestingly, my "git am" is unable to apply those patches. Does it work for you? I cannot see anything wrong with them, but they don't work. If the problem is that they are too large, please send the files as attachments. Also, I tried to do the same conversion with my copy of Libreoffice and the FODT files produced are significantly different from yours, which means, even if we use FODT docs, we are probably going to be unable to send changes as meaningful text patches. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document
On Tue, 14 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 02/13/2017 07:59 PM, Stefano Stabellini wrote: > > On Mon, 13 Feb 2017, Julien Grall wrote: > >> Hi Stefano, > >> > >> On 10/02/17 01:01, Stefano Stabellini wrote: > >>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote: > A possible hack could be to allocate a chunk of DDR dedicated for PCI > DMA. > PCI DMA devs could be locked in to only be able to access this mem + MSI > doorbell. > Guests can still screw each other up but at least it becomes harder to > read/write directly from each others OS memory. > It may not be worth the effort though > >>> > >>> Actually, we do have the swiotlb in Dom0, which can be used to bounce > >>> DMA requests over a buffer that has been previously setup to be DMA safe > >>> using an hypercall. That is how the swiotlb is used on x86. On ARM it is > >>> used to issue cache flushes via hypercall, but it could be adapted to do > >>> both. It would degrade performance, due to the additional memcpy, but it > >>> would work, I believe. > >> > >> A while ago, Globallogic suggested to use direct memory mapping for the > >> guest > >> to allow guest using DMA on platform not supporting SMMU. > >> > >> I believe we can use the same trick on platform where SMMUs can not > >> distinguish PCI devices. > > > > Yes, that would work, but only on platforms with a very limited number > > of guests. However, it might still be a very common use-case on a > > platform such as the Zynq MPSoC. > > Can you explain why you think this could only work with limited number > of guests? Because the memory regions would need to be mapped 1:1, right? And often devices have less than 4G DMA addresses limitations? I can see how it could work well with 1-4 guests, but I don't think it could work in a typical server environment with many more guests. Or am I missing something? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor
Hi, On 02/13/2017 10:14 PM, Stefano Stabellini wrote: On Mon, 13 Feb 2017, Tamas K Lengyel wrote: On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini wrote: On Mon, 13 Feb 2017, Tamas K Lengyel wrote: On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini wrote: On Mon, 13 Feb 2017, Tamas K Lengyel wrote: On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall wrote: On 13/02/17 16:59, Tamas K Lengyel wrote: On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall wrote: Hi Tamas, On 13/02/17 16:20, Tamas K Lengyel wrote: On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk wrote: Hello, This e-mail is sort of follow-up to the two threads: [1] (my thread about TEE interaction) and [2] (Edgar's thread regarding handling SMC calls in platform_hvc). I want to discuss more broad topic there. Obviously, there are growing number of SMC users and current state of SMC handling in Xen satisfies nobody. My team wants to handle SMCs in secure way, Xilinx wants to forward some calls directly to Secure Monitor, while allowing to handle other in userspace, etc. My proposition is to gather all requirements to SMC (and HVC) handling in one place (e.g. in this mail thread). After we' will have clear picture of what we want, we will be able to develop some solution, that will satisfy us all. At least, I hope so :) Also I want to remind, that there are ARM document called "SMC Calling Convention" [3]. According to it, any aarch64 hypervisor "must implement the Standard Secure and Hypervisor Service calls". At this moment XEN does not conform to this. So, lets get started with the requirements: 0. There are no much difference between SMC and HVC handling (at least according to SMCCC). 1. Hypervisor should at least provide own UUID and version while called by SMC/HVC 2. Hypervisor should forward some calls from dom0 directly to Secure Monitor (Xilinx use case) 3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM architecture service calls, etc. 4. Hypervisor should handle TEE calls in a secure way (e.g. no untrusted handlers in Dom0 userspace). 5. Hypervisor should support multiple TEEs (at least at compilation time). 6. Hypervisor should do this as fast as possible (DRM playback use case). 7. All domains (including dom0) should be handled in the same way. 8. Not all domains will have right to issue certain SMCs. 9. Hypervisor will issue own SMCs in some cases. 10. Domains on which the monitor privileged call feature is enabled (which is by default disabled for all domains) should not be able to issue SMCs such that it reaches the firmware directly. Xen should not bounce such calls to the firmware on behalf of the domain. Xen should not alter the state of the domain automatically (ie. incrementing PC). These calls should be exclusively transfered to the monitor subscriber for further processing. HVC calls need not be included in the monitor forwarding as long as the HVC call can be governed by XSM. This should not be a strong requirement. Whilst in your use case you want to forward all the SMCs to the monitor app, there are use case where Xen would need to emulate SMCs on the behalf of the guest. For instance see PSCI (arch/arm/vpsci.c). In my usecases it is a strong requirement. What happens when the monitor system is disabled is beyond my concerns - Xen can emulate or forward the call as it wishes. But when the monitor application is in use - in my usecase - it needs to be in exclusive control. If that breaks an in-guest application, that is acceptable in my usecase. As soon as there is another usecase that would need to support such an application while the monitor system is enabled, the monitor system can be fine-tuned for those needs to allow Xen to emulate. I've said it many times, I have nothing against doing that, but as I don't need it I won't be able to spend time implementing it. Right, as I wrote in the other thread, I think we should be able to find a way to satisfy Tamas' requirement as well as all the others. Of course, once you enable the "forward all SMCs to monitor" mode, some of the other requirements might not be met anymore, but that's acceptable because they are for different use-cases. Let me remind you that this discussion is not about what you implemented but what is a sensible design to fit everyone. I also never ask you to implement anything. Another valid use case is Xen handling power management for device assigned to the guest and having the monitor app acting as a "Trusted App". Regarding the HVC call governed by XSM. I think this is the wrong way to g. As it was mentioned a couple of time HVC is a valid conduit for Secure monitor call. You should not deny them on the basis that your monitor app is not able to handle it properly. A better way would be to have a list of Secure Monitor Call (HVC/SMC) that should be forwarded to the monitor app. I disagree. XSM needs to be in complete control of all hypercalls. Whether denying some of them will break an
Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
On 14/02/17 17:45, Andrew Cooper wrote:
> On 14/02/17 17:42, George Dunlap wrote:
>> On 13/02/17 11:00, Andrew Cooper wrote:
>>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might
>>> be
>>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
>>> backpointer.
>>>
>>> However, plenty of hardware has a physical address width less that 44 bits,
>>> and the code added in shadow_domain_init() is a straight assignment. This
>>> causes gfn_bits to be increased beyond the physical address width on most
>>> Intel consumer hardware (typically a width of 39, which is the number
>>> reported
>>> to the guest via CPUID).
>>>
>>> If the guest intentionally creates a PTE referencing a physical address
>>> between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
>>> address. However, the shadow code accepts the PTE, shadows it, and the
>>> virtual address works normally.
>>>
>>> Introduce paging_max_paddr_bits() to calculate the largest guest physical
>>> address supportable by the paging infrastructure, and update
>>> recalculate_cpuid_policy() to take this into account when clamping the
>>> guests
>>> cpuid_policy to reality. Remove gfn_bits and rework its users in terms of a
>>> guests maxphysaddr.
>>>
>>> Signed-off-by: Andrew Cooper
>>> ---
>>> CC: Jan Beulich
>>> CC: Tim Deegan
>>> CC: George Dunlap
>>> CC: Jun Nakajima
>>> CC: Kevin Tian
>>>
>>> v2:
>>> * Introduce paging_max_paddr_bits() rather than moving paging logic into
>>>recalculate_cpuid_policy().
>>> * Rewrite half of the commit message.
>>> ---
>>> xen/arch/x86/cpuid.c| 7 +++
>>> xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
>>> xen/arch/x86/mm/guest_walk.c| 3 ++-
>>> xen/arch/x86/mm/hap/hap.c | 2 --
>>> xen/arch/x86/mm/p2m.c | 3 ++-
>>> xen/arch/x86/mm/shadow/common.c | 10 --
>>> xen/arch/x86/mm/shadow/multi.c | 3 ++-
>>> xen/include/asm-x86/domain.h| 3 ---
>>> xen/include/asm-x86/paging.h| 16
>>> 9 files changed, 26 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
>>> index e0a387e..3378f7a 100644
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -6,6 +6,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>>>
>>> cpuid_featureset_to_policy(fs, p);
>>>
>>> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>>> p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
>>> -d->arch.paging.gfn_bits + PAGE_SHIFT);
>>> -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
>>> -(p->basic.pae || p->basic.pse36) ? 36 :
>>> 32);
>>> +paging_max_paddr_bits(d));
>>> +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
>>>
>>> p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>>
>>> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
>>> index 9c61b5b..774a11f 100644
>>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>>> @@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
>>> }
>>>
>>> if ( (gpa & ~PAGE_MASK) ||
>>> - (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
>>> + (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
>>> {
>>> vmfail_invalid(regs);
>>> return X86EMUL_OKAY;
>>> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
>>> index a67fd5a..5ad8cf6 100644
>>> --- a/xen/arch/x86/mm/guest_walk.c
>>> +++ b/xen/arch/x86/mm/guest_walk.c
>>> @@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain
>>> *p2m,
>>> /* If this guest has a restricted physical address space then the
>>> * target GFN must fit within it. */
>>> if ( !(rc & _PAGE_PRESENT)
>>> - && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
>>> + && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
>>> + (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )
>> This pattern, of taking a gfn and shifting it by
>> (cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
>> several times; it seems like for both clarity and avoiding mistakes, it
>> would be better if it were put into a macro.
>>
>> Everything else looks good to me. (No opinion on the other questions
>> raised so far.)
>
> static inline unsigned int gfn_bits(const struct domain *d)
> {
> return d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT;
> }
>
> ?
>
> I do like that idea. It would certainly make all of the callsites more
> readable.
>
> I can happily fold that change in if others agree.
I was thinking of going further:
static inline bool guest_gfn_valid(domain *d, gfn_t gfn)
{
return !!(gfn_x(gfn) >> (d->arch.cp
Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
On 14/02/17 17:49, George Dunlap wrote:
> On 14/02/17 17:45, Andrew Cooper wrote:
>> On 14/02/17 17:42, George Dunlap wrote:
>>> On 13/02/17 11:00, Andrew Cooper wrote:
XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which
might be
lower than the real maxphysaddr, to avoid overflowing the superpage shadow
backpointer.
However, plenty of hardware has a physical address width less that 44 bits,
and the code added in shadow_domain_init() is a straight assignment. This
causes gfn_bits to be increased beyond the physical address width on most
Intel consumer hardware (typically a width of 39, which is the number
reported
to the guest via CPUID).
If the guest intentionally creates a PTE referencing a physical address
between 39 and 44 bits, the result should be #PF[RSVD] for using the
virtual
address. However, the shadow code accepts the PTE, shadows it, and the
virtual address works normally.
Introduce paging_max_paddr_bits() to calculate the largest guest physical
address supportable by the paging infrastructure, and update
recalculate_cpuid_policy() to take this into account when clamping the
guests
cpuid_policy to reality. Remove gfn_bits and rework its users in terms of
a
guests maxphysaddr.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
CC: Jun Nakajima
CC: Kevin Tian
v2:
* Introduce paging_max_paddr_bits() rather than moving paging logic into
recalculate_cpuid_policy().
* Rewrite half of the commit message.
---
xen/arch/x86/cpuid.c| 7 +++
xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
xen/arch/x86/mm/guest_walk.c| 3 ++-
xen/arch/x86/mm/hap/hap.c | 2 --
xen/arch/x86/mm/p2m.c | 3 ++-
xen/arch/x86/mm/shadow/common.c | 10 --
xen/arch/x86/mm/shadow/multi.c | 3 ++-
xen/include/asm-x86/domain.h| 3 ---
xen/include/asm-x86/paging.h| 16
9 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index e0a387e..3378f7a 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
cpuid_featureset_to_policy(fs, p);
-p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
-d->arch.paging.gfn_bits + PAGE_SHIFT);
-p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
-(p->basic.pae || p->basic.pse36) ? 36 :
32);
+paging_max_paddr_bits(d));
+p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 9c61b5b..774a11f 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
}
if ( (gpa & ~PAGE_MASK) ||
- (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
+ (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
{
vmfail_invalid(regs);
return X86EMUL_OKAY;
diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index a67fd5a..5ad8cf6 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain
*p2m,
/* If this guest has a restricted physical address space then the
* target GFN must fit within it. */
if ( !(rc & _PAGE_PRESENT)
- && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
+ && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
+ (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )
>>> This pattern, of taking a gfn and shifting it by
>>> (cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
>>> several times; it seems like for both clarity and avoiding mistakes, it
>>> would be better if it were put into a macro.
>>>
>>> Everything else looks good to me. (No opinion on the other questions
>>> raised so far.)
>> static inline unsigned int gfn_bits(const struct domain *d)
>> {
>> return d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT;
>> }
>>
>> ?
>>
>> I do like that idea. It would certainly make all of the callsites more
>> readable.
>>
>> I can happily fo
Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
On 14/02/17 17:42, George Dunlap wrote:
> On 13/02/17 11:00, Andrew Cooper wrote:
>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might
>> be
>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
>> backpointer.
>>
>> However, plenty of hardware has a physical address width less that 44 bits,
>> and the code added in shadow_domain_init() is a straight assignment. This
>> causes gfn_bits to be increased beyond the physical address width on most
>> Intel consumer hardware (typically a width of 39, which is the number
>> reported
>> to the guest via CPUID).
>>
>> If the guest intentionally creates a PTE referencing a physical address
>> between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
>> address. However, the shadow code accepts the PTE, shadows it, and the
>> virtual address works normally.
>>
>> Introduce paging_max_paddr_bits() to calculate the largest guest physical
>> address supportable by the paging infrastructure, and update
>> recalculate_cpuid_policy() to take this into account when clamping the guests
>> cpuid_policy to reality. Remove gfn_bits and rework its users in terms of a
>> guests maxphysaddr.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Tim Deegan
>> CC: George Dunlap
>> CC: Jun Nakajima
>> CC: Kevin Tian
>>
>> v2:
>> * Introduce paging_max_paddr_bits() rather than moving paging logic into
>>recalculate_cpuid_policy().
>> * Rewrite half of the commit message.
>> ---
>> xen/arch/x86/cpuid.c| 7 +++
>> xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
>> xen/arch/x86/mm/guest_walk.c| 3 ++-
>> xen/arch/x86/mm/hap/hap.c | 2 --
>> xen/arch/x86/mm/p2m.c | 3 ++-
>> xen/arch/x86/mm/shadow/common.c | 10 --
>> xen/arch/x86/mm/shadow/multi.c | 3 ++-
>> xen/include/asm-x86/domain.h| 3 ---
>> xen/include/asm-x86/paging.h| 16
>> 9 files changed, 26 insertions(+), 23 deletions(-)
>>
>> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
>> index e0a387e..3378f7a 100644
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -6,6 +6,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>>
>> cpuid_featureset_to_policy(fs, p);
>>
>> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>> p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
>> -d->arch.paging.gfn_bits + PAGE_SHIFT);
>> -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
>> -(p->basic.pae || p->basic.pse36) ? 36 : 32);
>> +paging_max_paddr_bits(d));
>> +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
>>
>> p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
>> index 9c61b5b..774a11f 100644
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
>> }
>>
>> if ( (gpa & ~PAGE_MASK) ||
>> - (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
>> + (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
>> {
>> vmfail_invalid(regs);
>> return X86EMUL_OKAY;
>> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
>> index a67fd5a..5ad8cf6 100644
>> --- a/xen/arch/x86/mm/guest_walk.c
>> +++ b/xen/arch/x86/mm/guest_walk.c
>> @@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>> /* If this guest has a restricted physical address space then the
>> * target GFN must fit within it. */
>> if ( !(rc & _PAGE_PRESENT)
>> - && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
>> + && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
>> + (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )
> This pattern, of taking a gfn and shifting it by
> (cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
> several times; it seems like for both clarity and avoiding mistakes, it
> would be better if it were put into a macro.
>
> Everything else looks good to me. (No opinion on the other questions
> raised so far.)
static inline unsigned int gfn_bits(const struct domain *d)
{
return d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT;
}
?
I do like that idea. It would certainly make all of the callsites more
readable.
I can happily fold that change in if others agree.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL
On Tue, Feb 14, 2017 at 02:57:42PM +, Julien Grall wrote:
> Hi,
>
> On 01/26/2017 09:11 PM, Julien Grall wrote:
> > Hi,
> >
> > On 26/01/2017 19:01, Boris Ostrovsky wrote:
> > > On 01/26/2017 12:18 PM, Ian Jackson wrote:
> > > > Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684:
> > > > regressions - FAIL"):
> > > > > On 01/26/2017 08:23 AM, osstest service owner wrote:
> > > > > > flight 104684 linux-linus real [real]
> > > > > > http://logs.test-lab.xenproject.org/osstest/logs/104684/
> > > > > >
> > > > > > Regressions :-(
> > > > > >
> > > > > > Tests which did not succeed and are blocking,
> > > > > > including tests which could not be run:
> > > > > > test-armhf-armhf-xl 6 xen-boot fail REGR. vs.
> > > > > > 59254
> > > > ...
> > > > > I don't see why ARM tests fail. But then I also don't see (in the
> > > > > serial
> > > > > log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
> > > > > but there it nothing coming to the console from it.
> > > > Yes.
> > > >
> > > > Unfortunately the osstest bisector is having some trouble with this
> > > > because the basis revision combination includes Xen f3a7ca02400d which
> > > > is ancient and doesn't build now on armhf, although it built before.
> > > > (I think the difference is that the compiler has been updated by
> > > > Debian.)
> > > >
> > > > Since there is no output from Xen, I think this must be a problem with
> > > > the Xen image, not anything to do with Linux.
> > > >
> > > > The history for this test is here:
> > > >
> > > > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus
> > > >
> > > >
> > > > In xen-unstable, there is what looks like a different failure:
> > > >
> > > > http://logs.test-lab.xenproject.org/osstest/logs/104681/test-armhf-armhf-xl/serial-arndale-westfield.log
> > > >
> > > >
> > > > The machine in 104684 is cubietruck-metzinger which seems fine:
> > > >
> > > > http://logs.test-lab.xenproject.org/osstest/results/host/cubietruck-metzinger.html
> > > >
> > >
> > > I am probably not interpreting results correctly but 104684 looks like
> > > failed to me:
> > >
> > > http://logs.test-lab.xenproject.org/osstest/logs/104684/test-armhf-armhf-xl/info.html
> > >
> > >
> > > And 104681's failure looks exactly like 104684.
> >
> > I agree here. I think Ian got confused because the cubietruck is used to
> > build Xen.
> >
> > > >
> > > > Here are the histories on the linux-linus and xen-unstable branches:
> > > >
> > > > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus
> > > >
> > > >
> > > > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable
> > > >
> > > >
> > > > I think there may be a host-specific bug in ARM in xen-unstable ?
> >
> > So the problem with linux-linus is the path in the DeviceTree for the
> > serial has been changed by commit 5d99cc5 "ARM: dts: exynos: Move
> > Exynos5250 and Exynos5420 nodes under soc". Before the path was
> > /serial@12C2, now it is /soc/serial@12C2.
> >
> > From my understanding, osstest is testing 3.18 and onwards. Correct?
> >
> > If so, all the device tree we care have the same alias name to the
> > serial node. I would use it to get avoid specific command line option
> > depending on the kernel.
> >
> > Replacing on xen command line "dtuart=/serial@12C2" by
> > "dtuart=serial0" will allow Xen to be able to use again the console.
>
> I have looked at osstest git [1] and was not able to find where the
> configuration for the Arndale.
>
> Can someone knowing Osstest look at it? This would unblock linux-linus test
> on ARM.
>
(test-lab)liuw@osstest:~/testing.git$ ./mg-hosts showprops | grep DTUART | grep
arndale
arndale-bluewater XenDTUARTPath /serial@12C2
arndale-lakeside XenDTUARTPath /serial@12C2
arndale-metrocentre XenDTUARTPath /serial@12C2
arndale-westfield XenDTUARTPath /serial@12C2
That's a property of this kind of hosts in osstest. It needs to be
updated by the administrator (Ian).
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
On 13/02/17 11:00, Andrew Cooper wrote:
> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be
> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
> backpointer.
>
> However, plenty of hardware has a physical address width less that 44 bits,
> and the code added in shadow_domain_init() is a straight assignment. This
> causes gfn_bits to be increased beyond the physical address width on most
> Intel consumer hardware (typically a width of 39, which is the number reported
> to the guest via CPUID).
>
> If the guest intentionally creates a PTE referencing a physical address
> between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
> address. However, the shadow code accepts the PTE, shadows it, and the
> virtual address works normally.
>
> Introduce paging_max_paddr_bits() to calculate the largest guest physical
> address supportable by the paging infrastructure, and update
> recalculate_cpuid_policy() to take this into account when clamping the guests
> cpuid_policy to reality. Remove gfn_bits and rework its users in terms of a
> guests maxphysaddr.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Tim Deegan
> CC: George Dunlap
> CC: Jun Nakajima
> CC: Kevin Tian
>
> v2:
> * Introduce paging_max_paddr_bits() rather than moving paging logic into
>recalculate_cpuid_policy().
> * Rewrite half of the commit message.
> ---
> xen/arch/x86/cpuid.c| 7 +++
> xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
> xen/arch/x86/mm/guest_walk.c| 3 ++-
> xen/arch/x86/mm/hap/hap.c | 2 --
> xen/arch/x86/mm/p2m.c | 3 ++-
> xen/arch/x86/mm/shadow/common.c | 10 --
> xen/arch/x86/mm/shadow/multi.c | 3 ++-
> xen/include/asm-x86/domain.h| 3 ---
> xen/include/asm-x86/paging.h| 16
> 9 files changed, 26 insertions(+), 23 deletions(-)
>
> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index e0a387e..3378f7a 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>
> cpuid_featureset_to_policy(fs, p);
>
> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
> p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
> -d->arch.paging.gfn_bits + PAGE_SHIFT);
> -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
> -(p->basic.pae || p->basic.pse36) ? 36 : 32);
> +paging_max_paddr_bits(d));
> +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
>
> p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 9c61b5b..774a11f 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
> }
>
> if ( (gpa & ~PAGE_MASK) ||
> - (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
> + (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
> {
> vmfail_invalid(regs);
> return X86EMUL_OKAY;
> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
> index a67fd5a..5ad8cf6 100644
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
> /* If this guest has a restricted physical address space then the
> * target GFN must fit within it. */
> if ( !(rc & _PAGE_PRESENT)
> - && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
> + && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
> + (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )
This pattern, of taking a gfn and shifting it by
(cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
several times; it seems like for both clarity and avoiding mistakes, it
would be better if it were put into a macro.
Everything else looks good to me. (No opinion on the other questions
raised so far.)
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling
At 06:37 -0700 on 13 Feb (1486967832), Jan Beulich wrote: > >>> On 13.02.17 at 14:19, wrote: > > -tss = mem_alloc(128, 128); > > -memset(tss, 0, 128); > > +tss = mem_alloc(TSS_SIZE, TSS_SIZE); > > tss = mem_alloc(TSS_SIZE, 128); > > is sufficient here, as I've noticed (only) while reviewing Roger's > series v4 of which did trigger the creation of this patch. I've made > the change locally for now. Should Xen check the alignment when the param gets written? Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling
Hi, At 06:19 -0700 on 13 Feb (1486966797), Jan Beulich wrote: > The present way of setting this up is flawed: Leaving the I/O bitmap > pointer at zero means that the interrupt redirection bitmap lives > outside (ahead of) the allocated space of the TSS. Similarly setting a > TSS limit of 255 when only 128 bytes get allocated means that 128 extra > bytes may be accessed by the CPU during I/O port access processing. > > Introduce a new HVM param to set the allocated size of the TSS, and > have the hypervisor actually take care of setting namely the I/O bitmap > pointer. Both this and the segment limit now take the allocated size > into account. > > Signed-off-by: Jan Beulich This looks pretty good to me. Once the question below is resolved, Reviewed-by: Tim Deegan > --- > TBD: Do we really want to re-init the TSS every time we are about to > use it? No - I think we should init it when the guest writes the param(s) and leave it at that. Hvmloader marks it as reserved so the guest should know better than to write to it, and we can't protect it against all the possible ways the guest could break itself. If you do want to re-init it more often, then I think it would still be better to legacy guests' (lack of a) size limit once, when the guest writes the base param. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] RFC v2: Scope of Vulnerabilities for which XSAs are issued
Here is version two, with minor revisions based on comments from version 1. Please give any feedback by 28 February. Thanks! Issuing advisories has a cost: It costs the security team significant amounts of time to craft and send the advisories; it costs many of our downstreams time to apply, build, and test patches; and it costs many of our users time to decide whether to do an update, and if so, to test and deploy it. Given this, the Xen Project Security Team wants to clarify when they should issue an advisory or not: the Xen Security Response Process only mentions "'vulnerabilities", without specifying what constitutes a vulnerability. We would like guidelines from the community about what sorts of issues should be considered security issues (and thus will have advisories issued). This is the second version; the first version was pretty well received. If you want input, now is the time to speak up. Most of it is just encoding long-established practice. But there are two key changes and / or clarifications that deserve attention and discussion: * Criteria 2c: Leaking of mundane information from Xen or dom0 will not be considered a security issue unless it may contain sensitive guest or user data * Criteria 4: If no operating systems are vulnerable to a bug, no advisory will be issued. --- # Scope of vulnerabilities covered by this process All security issues are bugs, but not all bugs are security issues. This section is meant to be a guide from the Xen community to the Xen security response team regarding which bugs should have advisories issued for them. Discoverers are encouraged to err on the side of caution and report any potential vulnerabilities to the security team. These guidelines are not meant to be set in stone; if they do not fit your needs as a user, please raise the issue on xen-devel. Every potential vulnerability will have a source context, an effect, and a target effect context. For instance, a bug may allow a guest user (source context) to escalate their privileges (effect) to that of the guest kernel (target context); or it may allow a guest administrator (source context) to severely degrade the disk performance (effect) of another guest (target context). Only the following source/target context pairs will be considered vulnerabilities: 1a. The source is the guest userspace, guest kernel, or QEMU stubdomain, and the target is the hypervisor, dom0 and toolstack. 1b. The source is the guest userspace, guest kernel, or QEMU stubdomain, and the target is another guest. 1c. The source is guest userspace, and the target is the guest kernel, or other guest userspace processes. This means, for instance, that bug which allows a guest kernel to perform a DoS on itself will not be considered a security vulnerability. It also means, at the moment, that the security team will not issue advisories for highly disaggregated environments. Only some effects are considered vulnerabilities; and whether they are vulnerabilities depends on the target context: 2a. Privilege escalation: causing arbitrary code to be run in the target context. This will be considered a vulnerability in all cases above (1a-c). 2b. Denial of service: Causing termination of or significant degradation of performance in the target context. This will be considered a vulnerability in all cases above (1a-c). 2c. Information leakage: The attacker in the source context is able to obtain information from the target context. This will be considered a vulnerability in all cases in 1b and 1c. It will only be considered a vulnerability in the case of 1a if information obtained is considered sensitive in and of itself: for example, host administrator passwords or information about other users on the host. In particular, information leakage from Xen, domain 0, or the toolstack to an unprivileged guest will *not* be considered a vulnerability unless there is a chance that that information may contain information from a guest, or other sensitive information from domain 0. For instance, copying uninitialized data from Xen's stack will generally be considered a vulnerability, because it may contain stale guest data. But if it can be shown that the data copied will always be Xen-internal information (for instance, pointers or other internal structures), then an advisory will not be issued. This is the case even if that information could be useful in making another exploit more effective (for instance, if it exposed virtual addresses of sensitive data structures). 3. The security team will only issue advisories for certain configurations. Bugs in Xen features listed as "experimental" or "tech preview" will not have advisories issued for them. Bugs in QEMU will only have advisories issued when configured as described in docs/misc/qemu-xen-security. 4. The security team will only issue an advisory if there is a known combination of software in which the vulnerability can be exploited. In most cases, the software
Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
On 02/13/2017 12:03 PM, Paul Durrant wrote:
> Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> for restricting device emulators (such as QEMU) to a limited set of
> hypervisor operations, and being able to audit those operations in the
> kernel of the domain in which they run.
>
> This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.
>
> NOTE: There is no requirement for user-space code to bounce data through
> locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
> privcmd has enough information to lock the original buffers
> directly.
>
> [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2
>
> Signed-off-by: Paul Durrant
Stefano,
Are you OK with ARM changes?
-boris
> ---
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
>
> v3:
> - Add module parameters for max number of dm_op buffers and max buffer
> size
> - Fix arm build
> - Fix commit comment to reflect re-worked patch
>
> v2:
> - Lock the user pages rather than bouncing through kernel memory
> ---
> arch/arm/xen/enlighten.c | 1 +
> arch/arm/xen/hypercall.S | 1 +
> arch/arm64/xen/hypercall.S | 1 +
> arch/x86/include/asm/xen/hypercall.h | 7 ++
> drivers/xen/privcmd.c| 139
> +++
> include/uapi/xen/privcmd.h | 13
> include/xen/arm/hypercall.h | 1 +
> include/xen/interface/hvm/dm_op.h| 32
> include/xen/interface/xen.h | 1 +
> 9 files changed, 196 insertions(+)
> create mode 100644 include/xen/interface/hvm/dm_op.h
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 11d9f28..81e3217 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -457,4 +457,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
> EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index a648dfc..b0b80c0 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -92,6 +92,7 @@ HYPERCALL1(tmem_op);
> HYPERCALL1(platform_op_raw);
> HYPERCALL2(multicall);
> HYPERCALL2(vm_assist);
> +HYPERCALL3(dm_op);
>
> ENTRY(privcmd_call)
> stmdb sp!, {r4}
> diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> index 947830a..401ceb7 100644
> --- a/arch/arm64/xen/hypercall.S
> +++ b/arch/arm64/xen/hypercall.S
> @@ -84,6 +84,7 @@ HYPERCALL1(tmem_op);
> HYPERCALL1(platform_op_raw);
> HYPERCALL2(multicall);
> HYPERCALL2(vm_assist);
> +HYPERCALL3(dm_op);
>
> ENTRY(privcmd_call)
> mov x16, x0
> diff --git a/arch/x86/include/asm/xen/hypercall.h
> b/arch/x86/include/asm/xen/hypercall.h
> index a12a047..f6d20f6 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -472,6 +472,13 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg)
> return _hypercall2(int, xenpmu_op, op, arg);
> }
>
> +static inline int
> +HYPERVISOR_dm_op(
> + domid_t dom, unsigned int nr_bufs, void *bufs)
> +{
> + return _hypercall3(int, dm_op, dom, nr_bufs, bufs);
> +}
> +
> static inline void
> MULTI_fpu_taskswitch(struct multicall_entry *mcl, int set)
> {
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 5e5c7ae..a33f17e 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -32,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -43,6 +45,17 @@ MODULE_LICENSE("GPL");
>
> #define PRIV_VMA_LOCKED ((void *)1)
>
> +unsigned int privcmd_dm_op_max_num = 16;
> +module_param_named(dm_op_max_nr_bufs, privcmd_dm_op_max_num, uint, 0644);
> +MODULE_PARM_DESC(dm_op_max_nr_bufs,
> + "Maximum number of buffers per dm_op hypercall");
> +
> +unsigned int privcmd_dm_op_buf_max_size = XEN_PAGE_SIZE;
> +module_param_named(dm_op_buf_max_size, privcmd_dm_op_buf_max_size, uint,
> +0644);
> +MODULE_PARM_DESC(dm_op_buf_max_size,
> + "Maximum size of a dm_op hypercall buffer");
> +
> static int privcmd_vma_range_is_mapped(
> struct vm_area_struct *vma,
> unsigned long addr,
> @@ -548,6 +561,128 @@ static long privcmd_ioctl_mmap_batch(void __user
> *udata, int version)
> goto out;
> }
>
> +static int lock_pages(
> + struct privcmd_dm_op_buf kbufs[], unsigned int num,
> + struct page *pages[], unsigned int nr_pages)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < num; i++) {
> + unsigned int requested;
> + int pinned;
> +
> + requested = DIV_ROUND_UP(
> + offset_in_page(kbufs[i].uptr) + kbufs[
Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document
Hi Stefano, On 02/13/2017 07:59 PM, Stefano Stabellini wrote: > On Mon, 13 Feb 2017, Julien Grall wrote: >> Hi Stefano, >> >> On 10/02/17 01:01, Stefano Stabellini wrote: >>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote: A possible hack could be to allocate a chunk of DDR dedicated for PCI DMA. PCI DMA devs could be locked in to only be able to access this mem + MSI doorbell. Guests can still screw each other up but at least it becomes harder to read/write directly from each others OS memory. It may not be worth the effort though >>> >>> Actually, we do have the swiotlb in Dom0, which can be used to bounce >>> DMA requests over a buffer that has been previously setup to be DMA safe >>> using an hypercall. That is how the swiotlb is used on x86. On ARM it is >>> used to issue cache flushes via hypercall, but it could be adapted to do >>> both. It would degrade performance, due to the additional memcpy, but it >>> would work, I believe. >> >> A while ago, Globallogic suggested to use direct memory mapping for the guest >> to allow guest using DMA on platform not supporting SMMU. >> >> I believe we can use the same trick on platform where SMMUs can not >> distinguish PCI devices. > > Yes, that would work, but only on platforms with a very limited number > of guests. However, it might still be a very common use-case on a > platform such as the Zynq MPSoC. Can you explain why you think this could only work with limited number of guests? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY
These two patches don't apply anymore. Please rebase. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/4] build/printf: fix incorrect format specifiers
On Tue, Feb 14, 2017 at 12:30:55PM +, Roger Pau Monne wrote: > The following incorrect format specifiers and incorrect number of parameters > passed to printf like functions are reported by clang: > > mce.c:601:18: error: data argument not used by format string > [-Werror,-Wformat-extra-args] > smp_processor_id()); > ^ > > xenpm.c:102:23: error: data argument not used by format string > [-Werror,-Wformat-extra-args] > what, argv[argc > 1]); > ^ > > libxl_internal.c:25:69: error: data argument not used by format string > [-Werror,-Wformat-extra-args] > libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L); > ^ > libxl_internal.c:24:17: note: expanded from macro 'L' > func, (unsigned long)nmemb, (unsigned long)size > ^ > libxl_internal.c:26:21: error: data argument not used by format string > [-Werror,-Wformat-extra-args] > fprintf(stderr, L); > ^ > libxl_internal.c:24:17: note: expanded from macro 'L' > func, (unsigned long)nmemb, (unsigned long)size > ^ > > This patch contains the fixes for them and enables -Wformat for clang. > > Signed-off-by: Roger Pau Monné > Acked-by: Andrew Cooper > --- > NB: FWIW, there's a way to disable extra arguments checks > (-Wno-format-extra-args), that would prevent us from having to apply some of > the changes here. However, given that there are not that many occurrences, I > would rather leave the full checks of Wformat enabled. > > NB2: this has only been tested with a FreeBSD clang build (3.8.0), and only > against the components that build on FreeBSD (ie: no qemu-trad, and certainly > no blktap). > --- Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt
Hi,
Ping? As Ian mentioned earlier, without this series it is not possible
to build Xen tools for ARM64 in osstest.
Cheers,
On 02/08/2017 07:50 PM, Julien Grall wrote:
Hi,
On 24/01/17 22:19, David Scott wrote:
On 24 Jan 2017, at 11:35, Ian Jackson wrote:
Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no
ocamlopt"):
Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
package lacks ocamlopt.
...
This does not actually fix the real problem. I'm unsure how to fix it
properly, for the following reasons:
Can I have some input from ocaml folks ?
The first ARM64 boxes in the Xen Project test lab are in principle now
online, but this bug is stopping osstest actually getting as far as
trying to boot Xen.
ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
`ocamlc'. However our ocaml Makefiles seem to explicitly call
$(OCAMLOPT) in some places and and $(OCAMLC) in others.
I’m terrible at reading m4 and am really bad with autoconf so I may have
got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`? Where
`ocamlc`: outputs bytecode, and is a bytecode executable itself
`ocamlc.opt`: outputs bytecode, and is a native code executable itself
`ocamlopt`: outputs native code, and is a bytecode executable itself
`ocamlopt.opt`: outputs native code, and is a native code executable itself
Both `ocamlc` and `ocamlc.opt` should be interchangeable: same command-line
arguments, exactly the same output. Same for `ocamlopt` and `ocamlopt.opt`.
I _think_ the m4 is looking for `ocamlc.opt` because it’s an optimised native
(therefore faster) version of `ocamlc`. It should be fine to set `OCAMLC`
to either.
The tools/ocaml/Makefile.rules does contain rules for both bytecode outputs
(e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe *.cmi
can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).
I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it refers
directly to *.cmxa files which are native-code only— I don’t see how that
could work for bytecode outputs.
Do you have a link to the build failure?
Here a link for the build failure:
http://logs.test-lab.xenproject.org/osstest/logs/105644/build-arm64/5.ts-xen-build.log
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
At 16:04 + on 14 Feb (1487088291), Andrew Cooper wrote:
> Hmm ok. With the other bugfix of not dropping the first line, this hunk
> is now simply:
>
> @@ -504,7 +505,7 @@ void recalculate_cpuid_policy(struct domain *d)
>
> p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
> p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
> -d->arch.paging.gfn_bits + PAGE_SHIFT);
> +paging_max_paddr_bits(d));
> p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
> (p->basic.pae || p->basic.pse36) ? 36 :
> 32);
That looks good to me. Reviewed-by: Tim Deegan
> >> @@ -360,6 +361,21 @@ void paging_dump_vcpu_info(struct vcpu *v);
> >> int paging_set_allocation(struct domain *d, unsigned int pages,
> >>bool *preempted);
> >>
> >> +/* Maxphysaddr supportable by the paging infrastructure. */
> >> +static inline unsigned int paging_max_paddr_bits(const struct domain *d)
> >> +{
> >> +unsigned int bits = paging_mode_hap(d) ? hap_paddr_bits : paddr_bits;
> >> +
> >> +if ( !IS_ENABLED(BIGMEM) && paging_mode_shadow(d) &&
> >> + (!is_pv_domain(d) || opt_allow_superpage) )
> >> +{
> >> +/* Shadowed superpages store GFNs in 32-bit page_info fields. */
> >> +bits = min(bits, 32U + PAGE_SHIFT);
> >> +}
> >> +
> >> +return bits;
> >> +}
> > Does this really need to be an inline function? With the overall goal
> > of not including every header everywhere, I particularly dislike the
> > need to include xen/kconfig.h here for things to build.
>
> It is not on a critically path, but it seems wasteful to force something
> this small to be out of line.
It could be a macro, too. FWIW I agree with you that a static inline
is best.
Cheers,
Tim.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 105792: tolerable trouble: broken/fail/pass - PUSHED
flight 105792 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105792/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen-buildfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
build-arm64-pvops 5 kernel-build fail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 909c219944e944f086ec0a89938a7397e2aa4cb0
baseline version:
xen 62c7b99a10793738db1007f6750cf79057625f2c
Last test of basis 105788 2017-02-14 11:01:40 Z0 days
Testing same since 105792 2017-02-14 15:01:05 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
jobs:
build-amd64 pass
build-arm64 fail
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsfail
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
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 :
+ branch=xen-unstable-smoke
+ revision=909c219944e944f086ec0a89938a7397e2aa4cb0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
909c219944e944f086ec0a89938a7397e2aa4cb0
+ branch=xen-unstable-smoke
+ revision=909c219944e944f086ec0a89938a7397e2aa4cb0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x909c219944e944f086ec0a89938a7397e2aa4cb0 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://
Re: [Xen-devel] [PATCH biosdevname]: handle dom0 on AMD systems
Hello,
and ping.
Olaf
On Wed, Aug 17, Olaf Hering wrote:
> Starting with xen-4.7 cpuid() will return with the hypervisor bit set
> in a dom0 when running on an AMD system. As a result biosdevname
> thinks it runs in a guest and does nothing. Detect a dom0 by looking
> into xenfs. This works with classic xenlinux based kernels and with
> pvops based kernels.
>
> Signed-off-by: Olaf Hering
>
> ---
> src/bios_dev_name.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> --- a/src/bios_dev_name.c
> +++ b/src/bios_dev_name.c
> @@ -133,6 +133,31 @@ cpuid (u_int32_t eax, u_int32_t ecx)
> }
>
> /*
> + Starting with xen-4.7 cpuid will return with the hypervisor bit set
> + on AMD systems. This breaks biosdevname and network interface names.
> + Instead of relying on cpuid check for dom0 in xenfs.
> +*/
> +static int
> +running_in_dom0(void)
> +{
> +size_t len = 0;
> +char buf[16];
> +FILE *f = fopen("/proc/xen/capabilities", "r");
> +
> +if (!f)
> +return 0;
> +memset(buf, 0, sizeof(buf));
> +len = fread(&buf, 1, sizeof(buf) - 1, f);
> +fclose(f);
> +while(len && --len && len < sizeof(buf)) {
> +if (buf[len] == '\n')
> +buf[len] = '\0';
> +}
> +len = !strcmp("control_d", buf);
> +return len;
> +}
> +
> +/*
>Algorithm suggested by:
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458
> */
> @@ -144,7 +171,11 @@ running_in_virtual_machine (void)
>
> ecx = cpuid (eax, ecx);
> if (ecx & 0x8000U)
> +{
> + if (running_in_dom0())
> + return 0;
> return 1;
> +}
> return 0;
> }
>
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] STAO spec in xen.git
On Tue, Jan 17, Stefano Stabellini wrote: > On Tue, 17 Jan 2017, Olaf Hering wrote: > > On Fri, Jan 13, Julien Grall wrote: > > > > > Regarding the format. Does ODT will allow git to do proper diff? > > > > There is flat ODT, "Safe as ..." and pick the better format from the > > pulldown menu. > > Sounds like a good idea. Can you submit a patch? Done, see 'docs: convert from binary to ASCII'. For some reason results of 'git rm' are not noticed by get-maintainer.pl, see xen-devel for a copy of the removal. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] docs: convert XENV from odt to fodt
Fixes c33b5f013d ("Add XENV to docs/misc")
Signed-off-by: Olaf Hering
---
docs/misc/xen-env-table-spec.fodt | 852 ++
1 file changed, 852 insertions(+)
diff --git a/docs/misc/xen-env-table-spec.fodt
b/docs/misc/xen-env-table-spec.fodt
new file mode 100644
index 00..ccde7a6981
--- /dev/null
+++ b/docs/misc/xen-env-table-spec.fodt
@@ -0,0 +1,852 @@
+
+
+http://www.w3.org/1999/xlink";
xmlns:dc="http://purl.org/dc/elements/1.1/";
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0"
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0"
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0"
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0"
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0"
xmlns:math="http://www.w3.org/1998/Math/MathML";
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0"
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0"
xmlns:config="urn:oas
is:names:tc:opendocument:xmlns:config:1.0"
xmlns:ooo="http://openoffice.org/2004/office";
xmlns:ooow="http://openoffice.org/2004/writer";
xmlns:oooc="http://openoffice.org/2004/calc";
xmlns:dom="http://www.w3.org/2001/xml-events";
xmlns:xforms="http://www.w3.org/2002/xforms";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:rpt="http://openoffice.org/2005/report";
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2"
xmlns:xhtml="http://www.w3.org/1999/xhtml";
xmlns:grddl="http://www.w3.org/2003/g/data-view#";
xmlns:officeooo="http://openoffice.org/2009/office";
xmlns:tableooo="http://openoffice.org/2009/table";
xmlns:drawooo="http://openoffice.org/2010/draw";
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0"
xmlns:formx="urn:openoffice:names:
experimental:ooxml-odf-interop:xmlns:form:1.0"
xmlns:css3t="http://www.w3.org/TR/css3-text/"; office:version="1.2"
office:mimetype="application/vnd.oasis.opendocument.text">
+ LibreOffice/5.2.3.3$Linux_X86_64
LibreOffice_project/20m0$Build-3
+
+
+ 0
+ 2342
+ 17861
+ 7788
+ true
+ false
+
+
+ view2
+ 3041
+ 3464
+ 2342
+ 0
+ 20202
+ 7786
+ 1
+ 1
+ false
+ 228
+ false
+
+
+
+
+ false
+ true
+ true
+ true
+ 0
+ true
+ true
+
+ false
+ false
+ true
+ false
+ true
+ false
+ true
+ true
+ true
+ true
+ true
+ false
+ true
+ true
+ false
+ false
+ true
+ false
+ true
+ true
+ false
+
+ false
+ false
+ true
+ false
+ true
+
+ true
+ false
+ true
+ false
+ false
+ 1430233
+ false
+ false
+ true
+ false
+ true
+ true
+ false
+ false
+ 0
+ false
+ true
+ high-resolution
+ false
+ false
+ false
+ false
+ true
+ true
+
+ true
+ false
+ false
+ false
+ true
+ false
+ false
+ false
+
+ true
+ true
+ 1362860
+ true
+ 1
+ true
+ false
+ false
+ 0
+ false
+ false
+
+
+ false
+
+
+
+
+ http://openoffice.org/2004/office";
xmlns:xlink="http://www.w3.org/1999/xlink"/>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
[Xen-devel] [PATCH 1/4] docs: convert STAO from odt to fodt
Fixes 140b31a8de ("Add STAO spec to docs/misc")
Signed-off-by: Olaf Hering
---
docs/misc/status-override-table-spec.fodt | 707 ++
1 file changed, 707 insertions(+)
diff --git a/docs/misc/status-override-table-spec.fodt
b/docs/misc/status-override-table-spec.fodt
new file mode 100644
index 00..a831b7323b
--- /dev/null
+++ b/docs/misc/status-override-table-spec.fodt
@@ -0,0 +1,707 @@
+
+
+http://www.w3.org/1999/xlink";
xmlns:dc="http://purl.org/dc/elements/1.1/";
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0"
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0"
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0"
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0"
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0"
xmlns:math="http://www.w3.org/1998/Math/MathML";
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0"
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0"
xmlns:config="urn:oas
is:names:tc:opendocument:xmlns:config:1.0"
xmlns:ooo="http://openoffice.org/2004/office";
xmlns:ooow="http://openoffice.org/2004/writer";
xmlns:oooc="http://openoffice.org/2004/calc";
xmlns:dom="http://www.w3.org/2001/xml-events";
xmlns:xforms="http://www.w3.org/2002/xforms";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:rpt="http://openoffice.org/2005/report";
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2"
xmlns:xhtml="http://www.w3.org/1999/xhtml";
xmlns:grddl="http://www.w3.org/2003/g/data-view#";
xmlns:officeooo="http://openoffice.org/2009/office";
xmlns:tableooo="http://openoffice.org/2009/table";
xmlns:drawooo="http://openoffice.org/2010/draw";
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0"
xmlns:formx="urn:openoffice:names:
experimental:ooxml-odf-interop:xmlns:form:1.0"
xmlns:css3t="http://www.w3.org/TR/css3-text/"; office:version="1.2"
office:mimetype="application/vnd.oasis.opendocument.text">
+ LibreOffice/5.2.3.3$Linux_X86_64
LibreOffice_project/20m0$Build-3
+
+
+ 0
+ 2342
+ 17861
+ 7788
+ true
+ false
+
+
+ view2
+ 3041
+ 3464
+ 2342
+ 0
+ 20202
+ 7786
+ 1
+ 1
+ false
+ 228
+ false
+
+
+
+
+ false
+ true
+ true
+ true
+ 0
+ true
+ true
+
+ false
+ false
+ true
+ false
+ true
+ false
+ true
+ true
+ true
+ true
+ true
+ false
+ true
+ true
+ false
+ false
+ true
+ false
+ true
+ true
+ false
+
+ false
+ false
+ true
+ false
+ true
+
+ true
+ false
+ true
+ false
+ false
+ 803236
+ false
+ false
+ true
+ false
+ true
+ true
+ false
+ false
+ 0
+ false
+ true
+ high-resolution
+ false
+ false
+ false
+ false
+ true
+ true
+
+ true
+ false
+ false
+ false
+ true
+ false
+ false
+ false
+
+ true
+ true
+ 720138
+ true
+ 1
+ true
+ false
+ false
+ 0
+ false
+ false
+
+
+ false
+
+
+
+
+ http://openoffice.org/2004/office";
xmlns:xlink="http://www.w3.org/1999/xlink"/>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ACPI Specification for Status Override
Table
+
+ Specification: LINARO-0002
+ Authors: Al
Stone
[Xen-devel] [PATCH 4/4] docs: remove odt variant of XENV
Signed-off-by: Olaf Hering
---
docs/misc/xen-env-table-spec.odt | Bin 19204 -> 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/docs/misc/xen-env-table-spec.odt b/docs/misc/xen-env-table-spec.odt
deleted file mode 100644
index
c8de7ca7d8e7d00dabe9d7bebef1e8117e47f95e..
GIT binary patch
literal 0
HcmV?d1
literal 19204
zcmeFZbBu36(=Ix;ZQHhI_Sm*QTZ)u>b_
z-C5POo~L>#%7B8Q0Rce)0bys-OY4uaz)=DL0sTk*bphE~*_pX|I+__dI@(&97`a+G
z*fajNH)U`za+&8Ox*pir~Np0{V|&{WGR&>1Jna
zZ)9cb!sz6fPjIZK>yYDg5RBifIxv1WmSJs
zP*8Aka`N)>ii(QL%F3#$s_N+In3$N@*x0zZxOjVegO~vzECDdq0AxD=x+4JB6+q+;
zAol{$_yQOL04zZO?l1s5|SMpYdLHvuAA0Wlqbgu0W&`jfP#v#i$h+>Z0)9za3&MS4FVdk|38e_1_r
zRX7SL83$BN0qRGunL?>b;`aA<03YIc*y^53Q;y2bJZe@(qu&AmOSx_!WZ>FF
zDMEFoI;%IcabFt?)3ep;mwoSj!!K`uEu5pV3@Q?%*)OWrcaZ9=2U>h_7fygxWR%v>05Cn>Suegibks
zt09B!uLG37^tzk3@HR42uzuamy4g=QE?Zk`;cJX`tLZ*<9BY+~Gj8D;47Y5j6v3O$
zzKiX>PCci-F2Aj|H7lRJU7l^`VZI-y+RES%E?nGe;Q^{xpH;E6e$-#T{VRTdURXXZ
zg5i8jp27=qatiEK%)txZ>RNH&?rhv&)AstU0DN7F?teMFch>FP)jUGFOeM?IT*E@H
zrFRp~-T*xOw%-;FEZGK2v;aPT0|#u&oHh*Xzbcs2ZCW;dE<&XOoN%?Pv60}%s+zt#
zvIP71U(K4h1^TXi5e;>pt28K^5DyBg07qGMGr%zunDGAZvo9miijY|IF#QLIh!R1y
zo`&_@L1`a{FZs|WET`WqCA;r&0A^iP;8Eb5K0!W2CWxlsQFg&QgVk@O;s!5p!?&tG
zC{0@}RlUD`;TAQ^V;O!6<47>Q%*9{0{0yRvT32yyWw8KR>AtHNT`hl*zLD>EnbaFp
zDSVl>tcI34EbGk2)n~J*b5a(06?Lh2YZ{!@tcnkL6}2fjFvNJt?96EUZ8-Cp-KR?c=!DF^kgU|m=$>ru5z)Ug+Ck9{`}T2>31DYR=OF6oLLhoJ|J1b>egC1rs|D%hOlG*KxffbwFxldTkuBO;cw?5FwfmoRy
zSl;iAiXt#3uTyVKouZ8`SQmm_7kJAg*5uLDQJUuCzlY|J%I>TlSeV&GCnXcPw1!Rt
zxE(GVqJ$8URc(OX@ZDQy6SghhAgB6;u4NCNt*ve@t+z4D-xa^F=@=__e+IV)My?m$
zZH|DBl$UOGv)FopuppaMuy}!vMn%rjfk#IzTm8XI03xT(0SjMU1|MTfk3Foa_m}CM
zwRXB)i@beTb@Xo&=^BuZY`v`?$FpzIjNXp?dS^4Ws|*O<8d+7zxal95eFO&8p$KN@
zKK_8Oi@iPqUwuF$cgJrt-FzGSyiB&RqJyP-OEv=jXOla`p@rpuI8o%k@~q;djw<5e
z+@yke)(@6kFGs=mmNH(AGNZsp|_eDdC!QLkGG+S}tkYt}~W+KD|toRKeMeNt$XsPQY?I`^rj5x`SV
zs|>pLGb$haq+^w!rjS{;;CZcJlR8gk@pgLNfz;`4YlG}c^sjGw_5I|m_6t*}?7@^`
zmfNCcogoHKz4`w7n{ZWD|GBmkT*F~{1z#3g7OI3YOBIJ~0>^uuxSxVGY?(tf$z5ty
zd<@X(>gr|L`?0pWo(N9;ynMX8j0WiE04`P!zgzt4>gI0!UUvrEZ60mfT2mgdDKnxn
zm}L1I(pUza=(Z;X0q;AjH;0p7g$7z$U66Pfx3%=Mb=x`sb0-@+_n(RHE}P3o+P!Z`
z&2CsY+BxKDx=1WxftSQFWEyHS9`l%Js4^;OCVM}(r9EA(uD;ga4nMmyBhR0leIM5M
z+5R;(Gke|K`a0V>U2ZO}mzc*%vW6iUCDbB$%Jds>kto*~4m-MEKR<^GoDQvPFX~~B
zdp?gdA72`mwDArzbAZnEpNpTJp465)jJ_@9o1Nl=sfP{7q>;zJM$lJ6XP4gBzj=KS
z+>La$eSd>_#uKy!)L!88~RBlQYh3zOHm)Ff|zKxpzXQ%fohyZK{C
zeyG~6=#9F2VAAh(G@Sf9*?vfv^zXBaF`Tk6BI%OpsCUa@z+^Hkq-qVWfxa-rXNha2
z7w>2WtR&qq(r@)}xWyD%M@fohhc|GgNl%fCxucG=bHKbPe=(m#xP*d}EEjzB$P7KI
zMzdj%sf$E$rihQW95y6uWcO2<(ZL@FNm`jsW;F8wz+6dxpwzbgQ_?1Tug!;bG!7i}
zNIiA1MsyrrK$qX1?Tk|DOp|5QupTc8F~?PuEi2+1ql1o@ZvR}U7jt{z!{woM#M&j6
z6^>(@nob{6N=?3!#)|EeU>p-R*9e7jU`d2XutJ&0n!3gvQzNHEX%>F5GZ8f!xk7*<
z&q$$J;TYw7osc=$I2yo{nrvHtcv<0ru$?+jaJ$_tV*LuS6t*KKnL=ZJ(e;8Gy~h~H
zA&IFEGssWQ%%uB>QB2NL$2qRrWyJcS=$i&e=1v}hg+Fw#O{Pyq9ZjH?c?x#kL%`_#
zoM?0-Ebvx%Xkl;1kMCpLLWlh}4EY(~7ZE{Y;Z?d)Ek(&?e&)f-oPU`Yf%R3jRPa?A
zspD+N=-b^FpiNYg>StgUt}s?b&eb82ZD%ypr;Wv)DF+*?kEl1)bRlj>$(j%p#-T2|
zCq8;`FCiA3svu4=j1gl?mIB^yLEEN&V7U`j=blB9Cqcp_84s|+K&FU7^`Sv$G_cc3
z=8HXgP%FJN-5Ld-5xvV9)w*&9Uq}e<=8{^{kSU^j;Btq)S|pKACYwsGkAFPh*xlL3
z7?IH%A*8;N$(8ZUpvouYPd-G>^sS+0Ft`!emBNYqeA#lSY1-R#FxVv8^2HSx<6xSn
zQB)8VdZ^*A#%p7Rj2K-pczFMH>x3ETR=Tc2qaV_@%W)9A{7`PI_h*Xh;OvW@Gr$s~SM23ZvBzTz>wv_iry)=Vnjx8zV7{SR+-VpWVA&E`BU%DOJ>X%0f
zC~qY+MV?X>42=>O=!ty3HqIi2x^>Zh7n?GLdY3E?wJpUjtL7AG8xv(>Ih@iMsT!5!
zDl}`4Ar$In^-Y=q*PC{!lu2dqSX&g6KaCU0hUCgMdWGn0iNE^|#ussN(H#*`bwEc>
z=+yZ5IeaJayS%gh{>N?jd@zmfOzblP9i3kJ(=H0l{C<=6#}lE-oY
z-I8D&6WBM4#Z>|)s%>Ud3WwhINvC?^jJdJ1I}Nd%&p@@vGRco-!e%4P;6Nz!USbr4Df
z&84R0lsQfkggEVwt}~(4pfL*SU;-0Dv5b`!_$thJxA1-)>STwZ{*#KJugwv#*aAk4iZg-QzE(C(D5{P*aZQG$M<^v?hAy~dpg@&TfWV&md)PcOuae=@9$kBl-_+;
z{6A}lHP3+FKEKz`_xG2N!^6Yfe}~^rmp8!I;oHFPva6;>N5`fsI{GpCvg;9%0MF-f
zZpUF&JbF(s&!KJY`|#sya&vQXvd3T+WOO%pr$!?F6wuUmO!x-r9jz1p`kV0T$J^m@
zVzuWp8L|k{vA(O#4^Sr2b=|X*Px$2n_^j!H?6bZ8vG4&56uqc_V(!^{@A>)oU+RAf
zKsny}N3jOnn=;y7*Ly!*?H|{CpDpZW+b1_Ah##w{{rjM+gEn>_+-WT1_kZ#yRNy@b
zoB68}eD7-2(a_PMwWW2#p~2~g)tbiJmYprLW8TxTv9oK*hRge{06bc0aB;Pa^IWpB
zx_BY(-q+z&cK_`B7=C<`8>{W^*|9+A4}+<;_v(X%b{_lLH;)vzh>fwuFyP^GU#7O_`>D`z=0cK(8enc`)(Ea{!Ae02@
zbmLxPY%<-awoP;XZwnLAuKcIN*5d6WaH4Jh4
z=d|?z^j|7t>;ZkENz$Q$Qp$!5qg7N?Y+1flRYhxJE_WfhdLd~^Xx089Pm=PX99roR
z4{xh-uC@vn8rFK&c|~C?ZLe%{hSA6cY47ASl7-P>^$IR#BD|_*c~qN}pce%b%YLR!
zP&?f6RPYY8QA@;FSi3xO7P@N{iiVbhwCY*8%G5=o%laDyWDl}DYsi?CapB1_<@<+{
zp(jv=q2v?^QuWjU-(I=n%wA2yVY7}qay5y=#MQvCM$L?bp}p=3gS)0#OjUebX4T{9
z6>I7HxZr%S&~Pedh*Vh8kPs_jB)1rnLuBL#a^!p6`v}GQB09?A;Zv|PmnihXAf!kt
zb%ao1Q4uH_WD>r@6z9?U5R}PafhMRa5Mr*>KP=N=L{Q$KVSy}Z&^gG)31T6K?jgke
zS4=#jNXA%nN@6N#p#=(2Bz4%Lg9YVitZb#S=6N{eEg^(d9>h{1^Ki446qZ5#qoJFT
z@kpf{bb8RKGD+kCtj2M?q5Q;#4FiLi53EVz(Q92ltvIi
zNU5w3=1fVadm|IGtn~4oBooZ+-*Vr7$<0;j$fy`xvCXm|n|z(u1^K!4v(3vw6IsD}
zvf5S)WKnX3)+}nm1?Gpzg5@X2bx$LitI42v*b#ShfqiphMbpdhREOD^4~U({29AZu
zVF{#g#K$5V|3E$TWKKP+~!s
zKxrtG$d^e?t6;7wr_zvXTh1%Qw2X;S$&(j}&Hf#JuP;PyNQ}gW1czW1Cx2tGV&c-I
zomhcujQab-Dr-C!p`spKgS3wb&4hP~w=&YDuR7oCbXC*J1L|H_?{o)F
z$Hv2^4r8A@Y
[Xen-devel] [PATCH 3/4] docs: remove odt variant of STAO
Signed-off-by: Olaf Hering
---
docs/misc/status-override-table-spec.odt | Bin 20206 -> 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/docs/misc/status-override-table-spec.odt
b/docs/misc/status-override-table-spec.odt
deleted file mode 100644
index
4ea576b2c248a70445a6a5be751055bc03205092..
GIT binary patch
literal 0
HcmV?d1
literal 20206
zcmeFYQ;;uA3@|t+eXm4+AVQlDZVQ0(e
zYHPw^XXs?%#9(J{YHMO=>|$eT>&)P6>h7%Ye=>#;MD6%a1O)USWBoIxV(wyNWNT<)
z?ZoK(zeEOmTeAoSIdOOx9GHJ9@RAZDO8@3jARu5MDA0e>UeLQE5D+Mkf{cnNGcz*}
z508k5h_tk{ii(Q1wzjdcv6YpTlarH|mlv=J0MZ-)V*x<11)$plaGe2U9sn92fRyh#
zgFk>Z5Wp1*;EMpLhHPp@YzapLB;o)vi2$WkfLc00CktR0yKS1VW0kUNm%eA8v1gbI
zaLU?u&pj|L09cm*dH$=@j5c*o_4V}^c3-CT12P8y
zeS>4A{Z~~(e+xzdCF6jqDM0<`b@Rkc$MkLe9H4XNu6Y5_JAc=?4Cq@23=Iv9P0UP9
zO)V`gZEbB0F5M4p0;V<|Cw2kzJ5MwFfR%&irDMRx@yq%dVE6oW`vP!ubaZ`veQ^GK
z`1kw#=Kb^zaP{!>`1ttn^7Hcc{qytl&(DDWfBb*m1L!5r^FToO&5|O5D(;)tKJQ*=
z9IH3}Rn44W>LG!uE1td%KSKGpBivpWsZ%@48~BPp(E^((NS{f&0@Ab2Ke)Thfi6e_Kl??R0VE
zeDd)*ALtC$&Wt98l{$%9q?#S#w?`;
z4dB(eg5Bw4!7UBKzUcRRc@hQ12WIDW#IE>`JO(C@_R)8Syz-}1XEX2GyR+GcrKN0f
z3v5ut#lXn(N*rRHT*)%7-`#hJ?^)B61LfY=a~z`!BBQfc+Gn2p>sZ@jjr`Kd?C?rW
z8}N}@6?^YmFXuSZpM4Aj!>13{BQMk%XG5FArjZeGOf}_A?7?;y(>vtxMMtkgDNCP>
zRYo}e9LcmZHAVy?*U$!Ui+XozpRb+zRs64$!y?!nHrB@r6+dsvf$xvv$NkHZ=cX{`
zbcu_l3;g!=*A6AYk#VNp?JHd%tk0v*oH@wPize4gL5uB4rp2A;;s@b3T*Xc1sRM~mS1+t+Bmi+zVz$x`S1kG03w>PSyqsu$)O@My|O9|Ai@
z`t`_^HsQ5hOr5XqmA&`XUD9*awHxHh8UkYfC4O;SS{ftp
z>pEfHkE0RP(W7&HJ8Lh(pZag?o>gDjU6YMZ=OW#&@`iI*pry>I~N6pL5)7G=|8_2+#zD~}$G|f&%7ID+b&9zr2
zCpY(IrYDQ(r7K6y&d1NErK`2Ot*NuUx2YEa(6@D4Tj$o+dg{4H@7lGa=h^I8-`m#G
z!uwhq>0ZaNs6vWm1}hwze5v)D3qz2sCi6`tdFT3X!|#`E^&1;T8^XCl0O1>q6d(R+
z%G~dUA0GpeX)3|m;$#w49NhSU2xYMjk>LK?PCqBZ6M$}3AJ^yHRTA!6-QLgEbCzG9
z&*$!SNFV(S>i)%kHN{cwZ8WEwmJ&CIsLrs?VLVeFW-aHm#;ok
zU9Zq72=wAWlVK5JCXPj9YAMBpHhmoGQGI^<_*h@UzA$zxx5wS@&#bMitS#Kvo4u`e
zkJq1`v8`X({`p%?Ssf3<`j3;)VT817VC$Y_hhP&#EoltS0G4KxR){b21Uq@n&Uu`F=L^K!Vh|qiD#W-p}0E01#~{P+k~W?XNE
z-T>v_Ih}6Geaaeim$NV+1zVDVB_{h_gDZ1Ot4Z2#ZuW9lXoyr36`6`BQ_Vx5CPA6N5s(q_R@jrE(lz
zBzR_Mby>An&grG(oGt?#vL=)`cj0Q{b9q7E{$a(C*R9Iiyz=g0Ml}Vt)>YiW
z2C4*kg)er4xTv1>(?yyK!0(?WLl9qC-oH3csiPrR)h#?Lp&UhS1lJ8
zGD>97=nBjlfph|DJVyw!yuTu(bL1itM1d4$c!Cpzmkf=3N#S-w!^g1*6fp^!5qJf3
zS}-Yzg%d;xvfpFts7hhP9MAJpm*J*mcy-I+EN%(SjHN0y?r}tfa83Ssc7oL8CT&fP
zirPjQU^GLuQrY(2`b{{dJh(j~vP6JzMuI9nf$(bCM!I&%8q|egWjs#uiE?PEh=~!VQ=cIV^Mr6#ttN7JY@=t0P@PD
z)^zaVNYtBnaumq`^ZCYO0edbA5htNtF$?qOnqo%UnDMMoS~E*>K1?MidfHTwR;?Ab
z$xE`l2}P@r%9<4g93f~4GjKoJ#`|7&>UB5A&m*iG&0b$K+Mm@{)<9zS{brB%6P0TV
zr{X0s@LVx_;Z8JAR!k`O$kD8U$XDA{4<_TIb=R@7Fx0`N{3~QtZ&|c0Dm@t?*5Ta$?58P?OgvC_|HG(JRryLuoRk#n!KhM)Cxpca3Mo$*WFIO`nt(-(lG~`vSFQ?58wSs7v3Dx*N|sbEQ%$&}
zRM$oap=pKw78t&|Oeuu)^3G4jwW$2h`FogReLU*`AOqe^E)88BeZ4&GoGoqL+upVk
z<|cN&CeJdjtI_4dC%N128Wn9s0=&OZuC1;gUXY)p$bHd=Mx8Eo;zJ~W}Bsn?GZK@t!WITRYS(h^)$Xk{23Z5SD-p^|)o
zBlZRHew;qpo%j#lu>p_N=cX*50y=jqOoXg8X5saHz^GYFk_(M
z7?H0af8g9F@d#DNl2;M5<4BhgxlH6Jv=s`ACvU?Wco}r_0OD?bZI#-q_gd
z+@!GD5crU&gp2^x|644UVme|yUn5gVQBP4
zOe;f2bDeKH+;2CgiNnu5J$vPsWnDn@I*WXVND73Nro}Z#IW!U3qPsD@+cuW6M}4>b
zEGK;PF!s^3RsY-R)kYR#UoP+ZkH=@&#?Hn>Nz9i1KM-Q8r`^%fz{JJH1z7p|;<)4S
zc=gQG`FI?vOLO(h?CxoNTIsW$t<~vjW&3>1YqOix*Os8gUHgS_N_l&laA0bVWRHd9
zo$QVsusIJwsyaID$Sc<@7Kz?W5zg{G(%jJX
ze)NJ!`>Lka`uXa&zO%cotF@uAzP{ew*U{Vve}A*f_xAa<)9n2E8yB~W*6p_L@9y62
zI_Gw8SI76!P;*aLS4U4qB0G!N$-#@|I%}ii>^n@aiJqfS(4j&M=!;R$uNaHM`^_mC
zXQJMaJxsa-dz9#~EwdgzZzsW@Tl}3-+A5sP?(ytm>`OStorIfl8i>DcjUAw55+!IV
zDEq^24pVg5u^GYjk$h^u;M0Gkwu+w5VmaZ9t2m33R)I2rZHYknoUqVAJn0n*2auJN
zAjCGiK(Z2(u@IDL$Qc?2$nC(|@rd#z_noq(qoty0A~hnCPM1@S_dNwx?5M^qBsC_m
z4I>lKM4)Fw7d5ooNz*eLX)2pS6-j5MeHbKbA{+PjF`4bSSWI*0Pt)Tf^Be8cSN2~N
zCo?1)MWShSF!t}z&Kwj+75t+V(9_E0u$JUE~j?9m{t!t)sU~{|j%3*kZS%%R#%lv(C4p2fIH(-_5%hwb!qyh%Ya%
zFNj{Bh@Lw=KVCpZdz&51ZL6K^d_Gl=rd>@dpN>8aPDMT28SP6MRxYKb++M$XAej(O
z7iH``o@YN~+O{%2Z$5Kca!zm3#4CyAA--?8C5BE
z6wm$){7reEj`D3zG8#l>|*QhBNrp99~-7GL+nn0cVQj5bPkQs|*z+
zrRu27w(exlP%f^7$#O7A6l^a*B`9(^mP`>^QK&@TGESjoP>j}&f;HYTLIqQ;sT#{A
zcE^+wAO6eUi^`oDnpjRz5m^j7GHkiPeD>3ZDKo>qi`G|Kp?%44=fNyVE
zv>N8*!1@SYtB_N5@WIc3gfuXSEfH{>tN)f&}J!C)(I&&{E96Sgdh=06D2XG!vWCNJw%(o}eL2qym
z)S&hziby65o>VYbxK~7Yeqk{(u9i_|Je9))2tBx5Fj_!IHkt|u^%z=9J5_^3wMb$L
zn#J^mhi;;Z!Ky@nz2sg!TRh#tEYk42Mt?8}4upb0orGy(Gt>eNFf}#mfr`H;jK@NN
z(q%M+hC04Q2+X`(Ak#b&Ji%0VU@EW%LLoo$a7_XnRag?(6IuoFFO={`A>rBdMgweW
z&F2@BB40m~BT(dfV}{YB#1;sX59*fl{vr3tv2r=O4*gKxcGSrg0LfImwofP%n(?X>
zleo~JxTej6JuDIOHr5GE(Ib*qgk>pR%Ov>fWDwo|o)=1$;R6?mCmPP-G^Xg~
z!+{|0z@@?wAbsH5cz@;~Lc=~)iY8U}OT>(OYN8SMeL7{x{qH*r9s>Ph?qe*hK|glS
z!Bjxf3u1!Zut0gd#3F*4@$_Fb;hqB!X{N}al#$}lU7c4E(~S7VZXLC@
zG)hv?#WUW^RIH9FDbr?=g?%Sya0j4HJZhDR1J1D1CJ2rKBQ*ROrj3~cuE1dUi5Ulu
zSVin*9-*1Y$>y4)Ujj=3A{JRVTZEh}Rb$7GH
zX^|)4Rg8mk&Jqi8$V15O(v7F<2ZadO35VFLNTf6ho$w^eAoDP%(WE@KVL3AslVxe7
z!}eW~wF=21KiCcZNfAYHGbz~mzl2$J;^=O{Imd0}T)4HC=-|#|5!?oDN)&{XpE#Aw
z8yh$$fe%Bnxfxlr_WHSm+`9`mj->Ix1-#3`q|HtX7Cd-eU>I`}-v_+>=AcfKc1}f{
z
[Xen-devel] [PATCH 0/4] docs: convert from binary to ASCII
The odt files should have been saved as Flat XML via 'Save as ...'. git send-email warns about lines longer than 998 chars. Hopefully all involved mail services have no silly limits. Olaf Olaf Hering (4): docs: convert STAO from odt to fodt docs: convert XENV from odt to fodt docs: remove odt variant of STAO docs: remove odt variant of XENV docs/misc/status-override-table-spec.fodt | 707 + docs/misc/status-override-table-spec.odt | Bin 20206 -> 0 bytes docs/misc/xen-env-table-spec.fodt | 852 ++ docs/misc/xen-env-table-spec.odt | Bin 19204 -> 0 bytes 4 files changed, 1559 insertions(+) create mode 100644 docs/misc/status-override-table-spec.fodt delete mode 100644 docs/misc/status-override-table-spec.odt create mode 100644 docs/misc/xen-env-table-spec.fodt delete mode 100644 docs/misc/xen-env-table-spec.odt ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor
On 13/02/17 16:59, Tamas K Lengyel wrote: On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall wrote: Hi Tamas, On 13/02/17 16:20, Tamas K Lengyel wrote: On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk wrote: Hello, This e-mail is sort of follow-up to the two threads: [1] (my thread about TEE interaction) and [2] (Edgar's thread regarding handling SMC calls in platform_hvc). I want to discuss more broad topic there. Obviously, there are growing number of SMC users and current state of SMC handling in Xen satisfies nobody. My team wants to handle SMCs in secure way, Xilinx wants to forward some calls directly to Secure Monitor, while allowing to handle other in userspace, etc. My proposition is to gather all requirements to SMC (and HVC) handling in one place (e.g. in this mail thread). After we' will have clear picture of what we want, we will be able to develop some solution, that will satisfy us all. At least, I hope so :) Also I want to remind, that there are ARM document called "SMC Calling Convention" [3]. According to it, any aarch64 hypervisor "must implement the Standard Secure and Hypervisor Service calls". At this moment XEN does not conform to this. So, lets get started with the requirements: 0. There are no much difference between SMC and HVC handling (at least according to SMCCC). 1. Hypervisor should at least provide own UUID and version while called by SMC/HVC 2. Hypervisor should forward some calls from dom0 directly to Secure Monitor (Xilinx use case) 3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM architecture service calls, etc. 4. Hypervisor should handle TEE calls in a secure way (e.g. no untrusted handlers in Dom0 userspace). 5. Hypervisor should support multiple TEEs (at least at compilation time). 6. Hypervisor should do this as fast as possible (DRM playback use case). 7. All domains (including dom0) should be handled in the same way. 8. Not all domains will have right to issue certain SMCs. 9. Hypervisor will issue own SMCs in some cases. 10. Domains on which the monitor privileged call feature is enabled (which is by default disabled for all domains) should not be able to issue SMCs such that it reaches the firmware directly. Xen should not bounce such calls to the firmware on behalf of the domain. Xen should not alter the state of the domain automatically (ie. incrementing PC). These calls should be exclusively transfered to the monitor subscriber for further processing. HVC calls need not be included in the monitor forwarding as long as the HVC call can be governed by XSM. This should not be a strong requirement. Whilst in your use case you want to forward all the SMCs to the monitor app, there are use case where Xen would need to emulate SMCs on the behalf of the guest. For instance see PSCI (arch/arm/vpsci.c). In my usecases it is a strong requirement. What happens when the monitor system is disabled is beyond my concerns - Xen can emulate or forward the call as it wishes. But when the monitor application is in use - in my usecase - it needs to be in exclusive control. If that breaks an in-guest application, that is acceptable in my usecase. As soon as there is another usecase that would need to support such an application while the monitor system is enabled, the monitor system can be fine-tuned for those needs to allow Xen to emulate. I've said it many times, I have nothing against doing that, but as I don't need it I won't be able to spend time implementing it. Let me remind you that this discussion is not about what you implemented but what is a sensible design to fit everyone. I also never ask you to implement anything. Another valid use case is Xen handling power management for device assigned to the guest and having the monitor app acting as a "Trusted App". Regarding the HVC call governed by XSM. I think this is the wrong way to g. As it was mentioned a couple of time HVC is a valid conduit for Secure monitor call. You should not deny them on the basis that your monitor app is not able to handle it properly. A better way would be to have a list of Secure Monitor Call (HVC/SMC) that should be forwarded to the monitor app. I disagree. XSM needs to be in complete control of all hypercalls. Whether denying some of them will break an application or not is not Xen's concern. That is up to me as a user of Xen and XSM. If Xen overrides a XSM policy because we hard-coded HVCs that pass-through, that is a huge security policy violation. So even if we make a list of HVCs that should also fall under the monitor privileged call umbrella, it should still not override XSM. So since I would not be looking to emulate anything that gets forwarded as a result of an HVC call, XSM works for me just fine as the only thing I would do anyway is deny them. So why would that list help when I might as well just make my list more efficiently using XSM? Again, why do you want to handle SMC and HVC differently given they are both a conduit fo
Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function
On 14/02/17 14:46, Waiman Long wrote: > On 02/14/2017 04:39 AM, Peter Zijlstra wrote: >> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote: >>> It is the address of &steal_time that will exceed the 32-bit limit. >> That seems extremely unlikely. That would mean we have more than 4G >> worth of per-cpu variables declared in the kernel. > I have some doubt about if the compiler is able to properly use > RIP-relative addressing for this. Anyway, it seems like constraints > aren't allowed for asm() when not in the function context, at least for > the the compiler that I am using (4.8.5). So it is a moot point. You can work the issue of not having parameters in a plain asm() statement by using an asm-offset, stringizing it, and have C put the string fragments back together. "cmpb $0, " STR(STEAL_TIME_preempted) "(%rax);" ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr
On 13/02/17 12:36, Jan Beulich wrote:
On 13.02.17 at 12:00, wrote:
>> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>>
>> cpuid_featureset_to_policy(fs, p);
>>
>> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>> p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
>> -d->arch.paging.gfn_bits + PAGE_SHIFT);
>> -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
>> -(p->basic.pae || p->basic.pse36) ? 36 : 32);
>> +paging_max_paddr_bits(d));
>> +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
> The re-write of the commit message doesn't appear to have
> resulted in the PAE/PSE36 part being explained any better. I'm
> also unconvinced that exposing namely PSE36 to a guest
> with less than 36 physical address bits would be compatible with
> old OSes not knowing of CPUID leaf 0x8008 yet - they
> would legitimately assume 36 bits. The same presumably also
> goes for PAE.
Hmm ok. With the other bugfix of not dropping the first line, this hunk
is now simply:
@@ -504,7 +505,7 @@ void recalculate_cpuid_policy(struct domain *d)
p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
-d->arch.paging.gfn_bits + PAGE_SHIFT);
+paging_max_paddr_bits(d));
p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
(p->basic.pae || p->basic.pse36) ? 36 :
32);
>
>> @@ -360,6 +361,21 @@ void paging_dump_vcpu_info(struct vcpu *v);
>> int paging_set_allocation(struct domain *d, unsigned int pages,
>>bool *preempted);
>>
>> +/* Maxphysaddr supportable by the paging infrastructure. */
>> +static inline unsigned int paging_max_paddr_bits(const struct domain *d)
>> +{
>> +unsigned int bits = paging_mode_hap(d) ? hap_paddr_bits : paddr_bits;
>> +
>> +if ( !IS_ENABLED(BIGMEM) && paging_mode_shadow(d) &&
>> + (!is_pv_domain(d) || opt_allow_superpage) )
>> +{
>> +/* Shadowed superpages store GFNs in 32-bit page_info fields. */
>> +bits = min(bits, 32U + PAGE_SHIFT);
>> +}
>> +
>> +return bits;
>> +}
> Does this really need to be an inline function? With the overall goal
> of not including every header everywhere, I particularly dislike the
> need to include xen/kconfig.h here for things to build.
It is not on a critically path, but it seems wasteful to force something
this small to be out of line.
As for kconfig.h, it is tiny. What is the problem with adding it here?
We already pull generated/autoconf.h into everything via xen/config.h
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor
Hi Tamas, On 13/02/17 16:20, Tamas K Lengyel wrote: On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk wrote: Hello, This e-mail is sort of follow-up to the two threads: [1] (my thread about TEE interaction) and [2] (Edgar's thread regarding handling SMC calls in platform_hvc). I want to discuss more broad topic there. Obviously, there are growing number of SMC users and current state of SMC handling in Xen satisfies nobody. My team wants to handle SMCs in secure way, Xilinx wants to forward some calls directly to Secure Monitor, while allowing to handle other in userspace, etc. My proposition is to gather all requirements to SMC (and HVC) handling in one place (e.g. in this mail thread). After we' will have clear picture of what we want, we will be able to develop some solution, that will satisfy us all. At least, I hope so :) Also I want to remind, that there are ARM document called "SMC Calling Convention" [3]. According to it, any aarch64 hypervisor "must implement the Standard Secure and Hypervisor Service calls". At this moment XEN does not conform to this. So, lets get started with the requirements: 0. There are no much difference between SMC and HVC handling (at least according to SMCCC). 1. Hypervisor should at least provide own UUID and version while called by SMC/HVC 2. Hypervisor should forward some calls from dom0 directly to Secure Monitor (Xilinx use case) 3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM architecture service calls, etc. 4. Hypervisor should handle TEE calls in a secure way (e.g. no untrusted handlers in Dom0 userspace). 5. Hypervisor should support multiple TEEs (at least at compilation time). 6. Hypervisor should do this as fast as possible (DRM playback use case). 7. All domains (including dom0) should be handled in the same way. 8. Not all domains will have right to issue certain SMCs. 9. Hypervisor will issue own SMCs in some cases. 10. Domains on which the monitor privileged call feature is enabled (which is by default disabled for all domains) should not be able to issue SMCs such that it reaches the firmware directly. Xen should not bounce such calls to the firmware on behalf of the domain. Xen should not alter the state of the domain automatically (ie. incrementing PC). These calls should be exclusively transfered to the monitor subscriber for further processing. HVC calls need not be included in the monitor forwarding as long as the HVC call can be governed by XSM. This should not be a strong requirement. Whilst in your use case you want to forward all the SMCs to the monitor app, there are use case where Xen would need to emulate SMCs on the behalf of the guest. For instance see PSCI (arch/arm/vpsci.c). Another valid use case is Xen handling power management for device assigned to the guest and having the monitor app acting as a "Trusted App". Regarding the HVC call governed by XSM. I think this is the wrong way to g. As it was mentioned a couple of time HVC is a valid conduit for Secure monitor call. You should not deny them on the basis that your monitor app is not able to handle it properly. A better way would be to have a list of Secure Monitor Call (HVC/SMC) that should be forwarded to the monitor app. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function
On Tue, Feb 14, 2017 at 09:46:17AM -0500, Waiman Long wrote:
> On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
> > On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
> >> It is the address of &steal_time that will exceed the 32-bit limit.
> > That seems extremely unlikely. That would mean we have more than 4G
> > worth of per-cpu variables declared in the kernel.
>
> I have some doubt about if the compiler is able to properly use
> RIP-relative addressing for this.
Its not RIP relative, &steal_time lives in the .data..percpu section and
is absolute in that.
> Anyway, it seems like constraints
> aren't allowed for asm() when not in the function context, at least for
> the the compiler that I am using (4.8.5). So it is a moot point.
Well kvm_steal_time is (host/guest) ABI anyway, so the offset is fixed
and hard-coding it isn't a problem.
$ readelf -s defconfig-build/vmlinux | grep steal_time
100843: 00017ac064 OBJECT WEAK DEFAULT 35 steal_time
$ objdump -dr defconfig-build/vmlinux | awk '/[<][^>]*[>]:/ { o=0 }
/[<]__raw_callee_save___kvm_vcpu_is_preempted[>]:/ {o=1} { if (o) print $0 }'
810b4480 <__raw_callee_save___kvm_vcpu_is_preempted>:
810b4480: 55 push %rbp
810b4481: 48 89 e5mov%rsp,%rbp
810b4484: 48 8b 04 fd 00 94 46mov-0x7db96c00(,%rdi,8),%rax
810b448b: 82
810b4488: R_X86_64_32S __per_cpu_offset
810b448c: 80 b8 d0 7a 01 00 00cmpb $0x0,0x17ad0(%rax)
810b448e: R_X86_64_32S steal_time+0x10
810b4493: 0f 95 c0setne %al
810b4496: 5d pop%rbp
810b4497: c3 retq
And as you'll note, the displacement is correct and 'small'.
The below relies on the 'extra' cast in PVOP_CALL_ARG1() to extend the
argument to 64bit on the call side of things.
---
arch/x86/kernel/kvm.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 099fcba..2c854b8 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -589,6 +589,7 @@ static void kvm_wait(u8 *ptr, u8 val)
local_irq_restore(flags);
}
+#ifdef CONFIG_X86_32
__visible bool __kvm_vcpu_is_preempted(int cpu)
{
struct kvm_steal_time *src = &per_cpu(steal_time, cpu);
@@ -597,6 +598,26 @@ __visible bool __kvm_vcpu_is_preempted(int cpu)
}
PV_CALLEE_SAVE_REGS_THUNK(__kvm_vcpu_is_preempted);
+#else
+
+extern bool __raw_callee_save___kvm_vcpu_is_preempted(int cpu);
+
+asm(
+".pushsection .text;"
+".global __raw_callee_save___kvm_vcpu_is_preempted;"
+".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
+"__raw_callee_save___kvm_vcpu_is_preempted:"
+FRAME_BEGIN
+"movq __per_cpu_offset(,%rdi,8), %rax;"
+"cmpb $0, 16+steal_time(%rax);"
+"setne %al;"
+FRAME_END
+"ret;"
+".popsection"
+);
+
+#endif
+
/*
* Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
*/
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Make it compiler under Xen 4.7.
> -Original Message- [snip] > > Thank you. Keep in mind that it will likely break against > > older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h > > I'm not sure you actually need to include that directly. I was going to try > just > adding the 'want compat' defines and seeing if I could make it work. I think > it > *should* work since all we do for upstream QEMU is add those defines into > the configure cmd line IIRC. I pushed modified patches into the master and console branches. Hopefully it should now build ok for you. Paul ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 04/24] x86: refactor psr: implement CPU init and free flow.
On Mon, Feb 13, 2017 at 02:32:16PM +0800, Yi Sun wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
>
> Signed-off-by: Yi Sun
> ---
> v7:
> - initialize 'l3_cat'.
> - fix typo.
> - correct criteria to call 'free_feature' in cpu_fini_work. Only when
> CPU_STARTING has been done and all CPUs are offline, 'free_feature'
> can be called.
> - remove 'free_feature in 'psr_free' because 'psr_free' should only free
> resources allocated in 'psr_cpu_prepare'. But resources allocated in
> 'psr_cpu_prepare' will not be freed to simplify things.
> ---
> xen/arch/x86/cpuid.c| 6 --
> xen/arch/x86/psr.c | 170
> +++-
> xen/include/asm-x86/processor.h | 7 ++
> 3 files changed, 175 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index e0a387e..e3e92dd 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -34,12 +34,6 @@ static void cpuid_leaf(uint32_t leaf, struct cpuid_leaf
> *data)
> cpuid(leaf, &data->a, &data->b, &data->c, &data->d);
> }
>
> -static void cpuid_count_leaf(uint32_t leaf, uint32_t subleaf,
> - struct cpuid_leaf *data)
> -{
> -cpuid_count(leaf, subleaf, &data->a, &data->b, &data->c, &data->d);
> -}
> -
> static void sanitise_featureset(uint32_t *fs)
> {
> /* for_each_set_bit() uses unsigned longs. Extend with zeroes. */
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index 5acd9ca..9a2b717 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Terminology:
> @@ -35,6 +36,9 @@
> #define PSR_CAT(1<<1)
> #define PSR_CDP(1<<2)
>
> +#define CAT_CBM_LEN_MASK 0x1f
> +#define CAT_COS_MAX_MASK 0x
> +
> /*
> * Per SDM chapter 'Cache Allocation Technology: Cache Mask Configuration',
> * the MSRs ranging from 0C90H through 0D0FH (inclusive), enables support for
> @@ -136,11 +140,84 @@ struct psr_assoc {
>
> struct psr_cmt *__read_mostly psr_cmt;
>
> +static struct psr_socket_info *__read_mostly socket_info;
> +
> static unsigned int opt_psr;
> static unsigned int __initdata opt_rmid_max = 255;
> +static unsigned int __read_mostly opt_cos_max = MAX_COS_REG_CNT;
> static uint64_t rmid_mask;
> static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
>
> +/*
> + * Declare global feature list entry for every feature to facilitate the
> + * feature list creation. It will be allocated in psr_cpu_prepare() and
> + * inserted into feature list in cpu_init_work(). It is protected by
> + * cpu_add_remove_lock spinlock.
> + */
> +static struct feat_node *feat_l3_cat;
> +
> +/* Common functions. */
> +static void free_feature(struct psr_socket_info *info)
> +{
> +struct feat_node *feat, *next;
> +
> +if ( !info )
> +return;
> +
> +/*
> + * Free resources of features. But we do not free global feature list
> + * entry, like feat_l3_cat. Although it may cause a few memory leak,
> + * it is OK simplify things.
> + */
> +list_for_each_entry_safe(feat, next, &info->feat_list, list)
> +{
> +__clear_bit(feat->feature, &info->feat_mask);
> +list_del(&feat->list);
> +xfree(feat);
> +}
> +}
> +
> +/* L3 CAT functions implementation. */
> +static void l3_cat_init_feature(struct cpuid_leaf regs,
> +struct feat_node *feat,
> +struct psr_socket_info *info)
> +{
> +struct psr_cat_hw_info l3_cat = { };
> +unsigned int socket;
> +
> +/* No valid value so do not enable feature. */
> +if ( !regs.a || !regs.d )
> +return;
> +
> +l3_cat.cbm_len = (regs.a & CAT_CBM_LEN_MASK) + 1;
> +l3_cat.cos_max = min(opt_cos_max, regs.d & CAT_COS_MAX_MASK);
> +
> +/* cos=0 is reserved as default cbm(all bits within cbm_len are 1). */
> +feat->cos_reg_val[0] = (1ull << l3_cat.cbm_len) - 1;
> +
> +feat->feature = PSR_SOCKET_L3_CAT;
> +ASSERT(!test_bit(PSR_SOCKET_L3_CAT, &info->feat_mask));
> +__set_bit(PSR_SOCKET_L3_CAT, &info->feat_mask);
> +
> +feat->info.l3_cat_info = l3_cat;
> +
> +info->nr_feat++;
> +
> +/* Add this feature into list. */
> +list_add_tail(&feat->list, &info->feat_list);
> +
> +socket = cpu_to_socket(smp_processor_id());
> +if ( !opt_cpu_info )
> +return;
> +
> +printk(XENLOG_INFO "L3 CAT: enabled on socket %u, cos_max:%u,
> cbm_len:%u\n",
> + socket, feat->info.l3_cat_info.cos_max,
> + feat->info.l3_cat_info.cbm_len);
> +}
> +
> +static const struct feat_ops l3_cat_ops = {
> +};
> +
> static void __init parse_psr_bool(char *s, char *value, char *feature,
>unsigned int mask)
> {
> @@ -180,6 +257,9 @@ static void __init parse_psr_param(char *s)
>
Re: [Xen-devel] [PATCH] x86/mm: Alter is_xen_fixed_mfn() to use mfn_t
Hi Andrew, On 02/07/2017 06:57 PM, Andrew Cooper wrote: The predicate is common between x86 and ARM, and is unlikley to be different/ NIT: s/unlikley/unlikely/ on other architectures. Drop the arch declarations and introduce a common static inline in xen/mm.h instead. Signed-off-by: Andrew Cooper Acked-by: Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 01/24] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document
On Mon, Feb 13, 2017 at 02:32:13PM +0800, Yi Sun wrote: > This patch creates CAT and CDP feature document in doc/features/. It describes > key points to implement L3 CAT/CDP and L2 CAT which is described in details in > Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION > FEATURES". > > Signed-off-by: Yi Sun > --- > v7: > - correct typo. > - replace application/VM to domain. > - amend description of `feat_mask` to make it clearer. > - update revision. > - other minor fixes. You forgot to include in the 'Areas of improvement' the issues I described. > --- > docs/features/intel_psr_cat_cdp.pandoc | 454 > + > 1 file changed, 454 insertions(+) > create mode 100644 docs/features/intel_psr_cat_cdp.pandoc > > diff --git a/docs/features/intel_psr_cat_cdp.pandoc > b/docs/features/intel_psr_cat_cdp.pandoc > new file mode 100644 > index 000..65736cc > --- /dev/null > +++ b/docs/features/intel_psr_cat_cdp.pandoc > @@ -0,0 +1,454 @@ > +% Intel Cache Allocation Technology and Code and Data Prioritization Features > +% Revision 1.0 ?? 1.6 surely .. snip.. > +# Areas for improvement > + > +N/A Here. > + > +# Known issues > + > +N/A > + > +# References > + > +"INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION FEATURES" > [Intel® 64 and IA-32 Architectures Software Developer Manuals, > vol3](http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html) > + > +# History > + > + > +Date Revision Version Notes > +-- --- > +2016-08-12 1.0 Xen 4.9 Design document written > +2017-02-13 1.6 Xen 4.9 Design document written It was not written at 1.6. It was changed. And you enumerate what was changed. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling
On 14/02/17 08:55, Jan Beulich wrote:
On 13.02.17 at 19:26, wrote:
>> On 13/02/17 13:19, Jan Beulich wrote:
>>> ---
>>> TBD: Do we really want to re-init the TSS every time we are about to
>>> use it? This can happen quite often during boot, especially while
>>> grub is running.
>> The only case we need worry about is if the guest manually writes to the
>> area covered by the vm86 tss. I think, looking at the logic, that we
>> properly restore the old %tr when re-entering protected mode, so we
>> aren't at risk of having the vm86 tss on the leaving-side of a hardware
>> task switch.
> Yes. But that's the whole point of the question: The guest could
> equally well write to the TSS manually right after we've initialized
> it. And it only harms itself by doing so, hence we could as well
> init the TSS on a less frequently executed path.
Per this patch (I think) we initialise it each time the guest tries to
clear CR0.PE
Unless the VM86_TSS location is below the 1MB boundary, the guest can't
actually clobber it.
As an alternative, if you don't reinitialise each time, when would you
do so?
>
>> We have lasted thus far without, but given the issues recently
>> identified, the only safe conclusion to be drawn is that this
>> functionality hasn't been used in anger.
>>
>> For sensible performance, we need to keep the IO bitmap clear to avoid
>> taking the #GP emulation path.
>>
>> For correct behaviour, we need the entire software bitmap to be 0.
> This one is just for reasonable performance too, afaict. If faulting,
> just like with port accesses, we'd emulate the INT $nn.
Does that actually work? Upon re-injection of the event, won't hardware
follow the same bad path which caused the #GP fault to start with?
>
>>> +void hvm_prepare_vm86_tss(struct vcpu *v, uint32_t base, uint32_t limit)
>>> +{
>>> +/*
>>> + * If the provided area is large enough to cover at least the ISA port
>>> + * range, keep the bitmaps outside the base structure. For rather small
>>> + * areas (namely relevant for guests having been migrated from older
>>> + * Xen versions), maximize interrupt vector and port coverage by
>>> pointing
>>> + * the I/O bitmap at 0x20 (which puts the interrupt redirection bitmap
>>> + * right at zero), accepting accesses to port 0x235 (represented by
>>> bit 5
>>> + * of byte 0x46) to trigger #GP (which will simply result in the access
>>> + * being handled by the emulator via a slightly different path than it
>>> + * would be anyway). Be sure to include one extra byte at the end of
>>> the
>>> + * I/O bitmap (hence the missing "- 1" in the comparison is not an
>>> + * off-by-one mistake), which we deliberately don't fill with all ones.
>>> + */
>>> +uint16_t iomap = (limit >= sizeof(struct tss32) + (0x100 / 8) + (0x400
>>> / 8)
>>> + ? sizeof(struct tss32) : 0) + (0x100 / 8);
>>> +
>>> +ASSERT(limit >= sizeof(struct tss32) - 1);
>>> +hvm_copy_to_guest_phys(base, NULL, limit + 1, v);
>>> +hvm_copy_to_guest_phys(base + offsetof(struct tss32, iomap),
>>> + &iomap, sizeof(iomap), v);
>> This should be linear rather than phys.
> Strictly speaking yes, but since we're running with an ident map,
> it doesn't matter. And I'd prefer not to have to introduce a vcpu
> parameter to the linear copy function, as that would mean quite
> a few changes elsewhere. Would you be okay with me just
> attaching a respective comment here?
Ok.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()
Hi Jan,
On 02/14/2017 10:51 AM, Jan Beulich wrote:
On 07.02.17 at 00:32, wrote:
Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
added a assertion that intack.vector is the highest priority vector. But
according to the osstest, the assertion failed sometimes. More discussion can
be found in the thread
(https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.html).
The assertion failure is hard to reproduce. In order to root cause issue, this
patch is to add logs to dump PIR and vIRR when failure takes place. It should
be reverted once the root cause is found.
Julien, could you add a note on the 4.9 tracking list for us to not
forget to revert this (or at least add NDEBUG conditionals) the
latest in the RC phase?
I have added a note in the 4.9 tracking list.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 105786: regressions - trouble: blocked/broken/fail/pass
flight 105786 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105786/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 105778 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail in 105778 pass in 105786 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-rtds 9 debian-installfail REGR. vs. 59254 test-armhf-armhf-libvirt-raw 6 xen-bootfail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: linux7089db84e356562f8ba737c29e472cc42d530dbc baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 586 days Failing since 59348 2015-07-10 04:24:05 Z 585 days 273 attempts Testing same since 105757 2017-02-13 03:57:45 Z1 days4 attempts 7580 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops
Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
On Tue, Feb 14, 2017 at 03:39:00PM +, Paul Durrant wrote: > > -Original Message- > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > Sent: 14 February 2017 15:32 > > To: Paul Durrant > > Cc: xen-de...@lists.xenproject.org > > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later) > > > > On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote: > > > > -Original Message- > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > > > Sent: 14 February 2017 15:16 > > > > To: Paul Durrant > > > > Cc: xen-de...@lists.xenproject.org > > > > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and > > later) > > > > > > > > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote: > > > > > > -Original Message- > > > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > > > > > Sent: 10 February 2017 21:52 > > > > > > To: Paul Durrant ; xen- > > > > de...@lists.xenproject.org > > > > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and > > later) > > > > > > > > > > > > Hey! > > > > > > > > > > > > This patch lets me compile this emulator under Xen 4.7. > > > > > > > > > > > > It probably can be done better (#ifdef magic?) but for right > > > > > > now this gets me past the compile errors. > > > > > > > > > > > > BTW, are there any other outstanding patches against this tree? > > > > > > > > > > > > > > > > This is still my private project, although if it's generally useful > > > > > then > > maybe it > > > > can be adopted as part of the Xen project? > > > > > > > > It is a nice project! > > > > > > > > > > Glad you find it useful :-) > > > > > > > By 'adopted' you mean being built as part of xen.git (like minios.git?) > > > > - > > and > > > > all of those requirements? > > > > > > > > > > Something like that, then it can be incorporated as an option into the xen > > build and we can make sure any dependency issues like this are caught in > > future. > > > > > > I guess I'd probably make the 'console' branch master in a more official > > repo... I could even look at adding the necessary tooling into libxl to > > kick it off > > too :-) > > > > Oooh, and what kind of bribe^H^H^H^H incentive should I send your way? > > > > A time machine? :-) Analog or digital? Amazon.co.uk does have a nice list of 'Timex' ones :-) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: 14 February 2017 15:32 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later) > > On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote: > > > -Original Message- > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > > Sent: 14 February 2017 15:16 > > > To: Paul Durrant > > > Cc: xen-de...@lists.xenproject.org > > > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and > later) > > > > > > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote: > > > > > -Original Message- > > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > > > > Sent: 10 February 2017 21:52 > > > > > To: Paul Durrant ; xen- > > > de...@lists.xenproject.org > > > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and > later) > > > > > > > > > > Hey! > > > > > > > > > > This patch lets me compile this emulator under Xen 4.7. > > > > > > > > > > It probably can be done better (#ifdef magic?) but for right > > > > > now this gets me past the compile errors. > > > > > > > > > > BTW, are there any other outstanding patches against this tree? > > > > > > > > > > > > > This is still my private project, although if it's generally useful then > maybe it > > > can be adopted as part of the Xen project? > > > > > > It is a nice project! > > > > > > > Glad you find it useful :-) > > > > > By 'adopted' you mean being built as part of xen.git (like minios.git?) - > and > > > all of those requirements? > > > > > > > Something like that, then it can be incorporated as an option into the xen > build and we can make sure any dependency issues like this are caught in > future. > > > > I guess I'd probably make the 'console' branch master in a more official > repo... I could even look at adding the necessary tooling into libxl to kick > it off > too :-) > > Oooh, and what kind of bribe^H^H^H^H incentive should I send your way? > A time machine? :-) Paul > > > > Paul > > > > > > > > > > For the benefit of the list, there are two branches in > > > http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git > > > > > > > > - The 'master' branch is a very basic standalone device emulator. It > serves > > > as boilerplate for emulation of a single PCI device. > > > > > > > > - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using > > > libVNCServer which can potentially be used with an HVM guest with PV > > > network and storage drivers, thus removing the need to use QEMU. > demu is > > > a small and constrained piece of code and thus presents a much smaller > > > attack surface. The original intention was also to run it in a 'console > service > > > domain' to further contain damage it was successfully attacked. > > > > > > > > It's likely that I will patch the code further once my current work on > > > libxendevicemodel is done (following acceptance of my recent privcmd > > > patches). > > > > > > > > > > > > > > Cheers, > > > > > > > > Paul > > > > > > > > > > > > > > demu.c | 7 ++- > > > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > > > > > Konrad Rzeszutek Wilk (1): > > > > > Make it compiler under Xen 4.7. > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 105787: tolerable FAIL - PUSHED
flight 105787 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105787/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105781 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105781 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105781 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105781 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105781 test-amd64-amd64-xl-rtds 9 debian-install fail like 105781 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass build-arm64 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass version targeted for testing: qemuuec7a9bd5bb2c46c60cc0ec9b9d9f2ce404226ec0 baseline version: qemuu305e6c8a2ff7a6e3f4942b50e853230f18eeb5a9 Last test of basis 105781 2017-02-14 01:16:33 Z0 days Testing same since 105787 2017-02-14 10:14:42 Z0 days1 attempts People who touched revisions under test: Amit Shah Ashijeet Acharya Dr. David Alan Gilbert Halil Pasic Li Zhijian Pavel Butsykin Peter Maydell zhanghailiang jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf
Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote: > > -Original Message- > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > Sent: 14 February 2017 15:16 > > To: Paul Durrant > > Cc: xen-de...@lists.xenproject.org > > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later) > > > > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote: > > > > -Original Message- > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > > > > Sent: 10 February 2017 21:52 > > > > To: Paul Durrant ; xen- > > de...@lists.xenproject.org > > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later) > > > > > > > > Hey! > > > > > > > > This patch lets me compile this emulator under Xen 4.7. > > > > > > > > It probably can be done better (#ifdef magic?) but for right > > > > now this gets me past the compile errors. > > > > > > > > BTW, are there any other outstanding patches against this tree? > > > > > > > > > > This is still my private project, although if it's generally useful then > > > maybe it > > can be adopted as part of the Xen project? > > > > It is a nice project! > > > > Glad you find it useful :-) > > > By 'adopted' you mean being built as part of xen.git (like minios.git?) - > > and > > all of those requirements? > > > > Something like that, then it can be incorporated as an option into the xen > build and we can make sure any dependency issues like this are caught in > future. > > I guess I'd probably make the 'console' branch master in a more official > repo... I could even look at adding the necessary tooling into libxl to kick > it off too :-) Oooh, and what kind of bribe^H^H^H^H incentive should I send your way? > > Paul > > > > > > > For the benefit of the list, there are two branches in > > http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git > > > > > > - The 'master' branch is a very basic standalone device emulator. It > > > serves > > as boilerplate for emulation of a single PCI device. > > > > > > - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using > > libVNCServer which can potentially be used with an HVM guest with PV > > network and storage drivers, thus removing the need to use QEMU. demu is > > a small and constrained piece of code and thus presents a much smaller > > attack surface. The original intention was also to run it in a 'console > > service > > domain' to further contain damage it was successfully attacked. > > > > > > It's likely that I will patch the code further once my current work on > > libxendevicemodel is done (following acceptance of my recent privcmd > > patches). > > > > > > > > > > Cheers, > > > > > > Paul > > > > > > > > > > > demu.c | 7 ++- > > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > > > Konrad Rzeszutek Wilk (1): > > > > Make it compiler under Xen 4.7. > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86: package up context switch hook pointers
On 14/02/17 10:29, Jan Beulich wrote:
> They're all solely dependent on guest type, so we don't need to repeat
> all the same four pointers in every vCPU control structure. Instead use
> static const structures, and store pointers to them in the domain
> control structure.
>
> Since touching it anyway, take the opportunity and move schedule_tail()
> into the only C file needing it.
>
> Signed-off-by: Jan Beulich
+1. This has been a niggle on my todo list for ages.
> @@ -2066,6 +2073,15 @@ static void __context_switch(void)
> per_cpu(curr_vcpu, cpu) = n;
> }
>
> +/*
> + * Schedule tail *should* be a terminal function pointer, but leave a
> bugframe
> + * around just incase it returns, to save going back into the context
> + * switching code and leaving a far more subtle crash to diagnose.
> + */
> +#define schedule_tail(vcpu) do { \
> +(((vcpu)->domain->arch.ctxt_switch->tail)(vcpu)); \
> +BUG();\
> +} while (0)
schedule_tail() is used only twice. I'd suggest dropping it entirely
and calling the ->tail() function pointer normally, rather than hiding
it this.
Upon reviewing, this patch, don't we also need a ->same() call in the
continue_same() path in the previous patch?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
