Re: [Xen-devel] [PATCH 4/9] x86/vvmx: Remove unnecessary VMX operand reads
> From: Euan Harris [mailto:euan.har...@citrix.com]
> Sent: Friday, October 27, 2017 1:03 AM
>
> * vpid is never used in nvmx_handle_invept() so there is no point in
>reading it.
I think you meant nvmx_handle_invvpid
>
> * vmptrst's operand is the memory address to which to write the VMCS
>pointer. gpa is the pointer to write. Reading the address into
>gpa is meaningless.
>
> Signed-off-by: Euan Harris
> ---
> xen/arch/x86/hvm/vmx/vvmx.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c
> b/xen/arch/x86/hvm/vmx/vvmx.c
> index df84592490..32c07eca3d 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1801,7 +1801,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs
> *regs)
> unsigned long gpa = 0;
> int rc;
>
> -rc = decode_vmx_inst(regs, &decode, &gpa, 0);
> +rc = decode_vmx_inst(regs, &decode, NULL, 0);
> if ( rc != X86EMUL_OKAY )
> return rc;
>
> @@ -1992,10 +1992,9 @@ int nvmx_handle_invept(struct cpu_user_regs
> *regs)
> int nvmx_handle_invvpid(struct cpu_user_regs *regs)
> {
> struct vmx_inst_decoded decode;
> -unsigned long vpid;
> int ret;
>
> -if ( (ret = decode_vmx_inst(regs, &decode, &vpid, 0)) != X86EMUL_OKAY )
> +if ( (ret = decode_vmx_inst(regs, &decode, NULL, 0)) != X86EMUL_OKAY )
> return ret;
>
> switch ( reg_read(regs, decode.op[1].reg_idx) )
> --
> 2.13.6
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/9] x86/vvmx: Read instruction operands correctly on VM exit
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, October 27, 2017 1:59 AM
>
> On 26/10/17 18:03, Euan Harris wrote:
> > decode_vmx_inst() does not read instruction operands correctly on VM
> exit:
> >
> > * It incorrectly uses vmx_inst_info's address_size field to calculate
> >the sizes of the exit-causing instruction's operands. The sizes of
> >the operands are specified in the SDM and might depend on whether
> the
> >guest is running in 32-bit or 64-bit mode, but they have nothing to do
> >with the address_size field.
> >
> > * It includes its own segmentation logic, duplicating code elsewhere.
> >This segmentation logic is also incorrect and will raise #GP fault
> >rather than a #SS fault in response to an invalid memory access
> >through the stack segment.
> >
> > Patches 1-6 (up to 'Remove operand decoding from decode_vmx_inst()')
> > refactor decode_vmx_inst() in preparation for fixing the bugs mentioned
> > above. They remove unnecessary code and extract the logic for reading
> > operands from decode_vmx_inst() into a new operand_read() function.
> > These patches should not cause any functional changes.
> >
> > Patch 7 ('Use correct sizes when reading operands') replaces the incorrect
> > operand size calculations based on address_size with the correct sizes
> > from the SDM.
> >
> > Patches 8 and 9 add new hvm_copy_{to,from}_guest_virt() helpers and
> use
> > them to read memory operands in place of the incorrect segmentation
> > logic in decode_vmx_inst().
> >
> > Euan Harris (9):
> > x86/vvmx: Remove enum vmx_regs_enc
> > x86/vvmx: Unify operands in struct vmx_inst_decoded
> > x86/vvmx: Extract operand reading logic into operand_read()
> > x86/vvmx: Remove unnecessary VMX operand reads
> > x86/vvmx: Replace direct calls to reg_read() with operand_read()
> > x86/vvmx: Remove operand reading from decode_vmx_inst()
> > x86/vvmx: Use correct sizes when reading operands
> > x86/hvm: Add hvm_copy_{to,from}_guest_virt() helpers
> > x86/vvmx: Use hvm_copy_{to,from}_guest_virt() to read operands
>
> All Reviewed-by: Andrew Cooper . I've
> noticed a few trivial style issues which can be fixed up on commit if
> there are no other issues.
>
Acked-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] USB Passthrough: Incorrect device detected in Domain U
Hello, I'm trying USB passthrough on x86 and ARM platforms. I've taken the USB frontend and backend code from When I passthrough a certain USB device it shows up in the device list of Dom-u, I've verified this with "xl usb-list Dom-u". When I switch to Dom-u, this USB device does not show up instead a USB device with different address is showing up all the time. *** Dom-0 ** root@salvator-x-xen-dom0:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 005: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Command "xl usbctrl-attach dom-u version=2 ports" is creating USB controller but with the following error. root@salvator-x-xen-dom0:~# xl usbctrl-attach dom-u version=2 ports=8 [ 2000.019717] rcar_gen3_thermal e61a8000.thermal: Can't register thermal zone [ 2000.026768] xen-pvusb: urb-ring-ref 0, conn-ring-ref 0, event-channel 7 [ 2000.033565] xen-pvusb: Dom3 provided bogus ring requests (0x720d0d0d - 0x0 = 1913457933). Halting ring processing on dev=0x0 [ 2000.034177] xen-pvusb: urb-ring-ref 0, conn-ring-ref 0, event-channel 7 libxl: error: libxl_device.c:1074:device_backend_callback: unable to add device with path /local/domain/0/backend/vusb/3/0 libxl: error: libxl.c:2009:device_addrm_aocomplete: unable to add vusb with id 0 libxl_device_usbctrl_add failed. root@salvator-x-xen-dom0:~# xl usbdev-attach Domain hostbus=5 hostaddr=5 [ 5024.235683] rroot@salvator-x-xen-dom0:~# car_gen3_thermal e61a8000.thermal: Can't register thermal zone root@salvator-x-xen-dom0:~# root@salvator-x-xen-dom0:~# root@salvator-x-xen-dom0:~# root@salvator-x-xen-dom0:~# xl usb-list dom-u Devid Type BE state usb-ver ports 0 pv 0 4 2 8 Port 1: Bus 005 Device 005 Port 2: Port 3: Port 4: Port 5: Port 6: Port 7: Port 8: root@salvator-x-xen-dom0:~# xl console 3 *** Dom-U ** [ 3165.172553] vusb vusb-0: Xen USB2.0 Virtual Host Controller [ 3165.172588] vusb vusb-0: new USB bus registered, assigned bus number 1 [ 3165.173363] hub 1-0:1.0: USB hub found [ 3165.173401] hub 1-0:1.0: 8 ports detected root@salvator-x-xen-dom0:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub I'm not sure why a different USB device is getting attached to domain U. Any help is really appreciated. Kernel version: 4.6 Xen version: 4.8 Thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] USB Passthrough: Incorrect device detected in Domain U
On 02/11/17 07:57, Rakesh Awanti wrote: > Hello, > > I'm trying USB passthrough on x86 and ARM platforms. I've taken the USB > frontend and backend code from So from where? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] USB Passthrough: Incorrect device detected in Domain U
>> Hello, >> >> I'm trying USB passthrough on x86 and ARM platforms. I've taken the USB >> frontend and backend code from >So from where? https://lists.xen.org/archives/html/xen-devel/2015-02/msg03245.html Apologies for the missing link. From: Juergen Gross Sent: Thursday, November 2, 2017 1:03:43 PM To: Rakesh Awanti; xen-devel@lists.xen.org Subject: Re: [Xen-devel] USB Passthrough: Incorrect device detected in Domain U On 02/11/17 07:57, Rakesh Awanti wrote: > Hello, > > I'm trying USB passthrough on x86 and ARM platforms. I've taken the USB > frontend and backend code from So from where? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document
On Wed, Nov 1, 2017 at 10:15 AM, Andre Przywara wrote: > Hi, > > On 01/11/17 04:31, Christoffer Dall wrote: >> On Wed, Nov 1, 2017 at 9:58 AM, Stefano Stabellini >> wrote: >> >> [] > > Christoffer, many thanks for answering this! > I think we have a lot of assumptions about the whole VGIC life cycle > floating around, but it would indeed be good to get some numbers behind it. > I would be all too happy to trace some workloads on Xen again and > getting some metrics, though this sounds time consuming if done properly. > > Do you have any numbers on VGIC performance available somewhere? > I ran the full set of workloads and micro numbers that I've used for my papers with/without the optimization, and couldn't find a measurable difference. -Christoffer ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document
On Wed, Nov 1, 2017 at 10:54 PM, Stefano Stabellini wrote: [...] > >> > The suggestion of using this model in Xen was made in the past already. >> > I always objected for the reason that we don't actually know how many >> > LRs the hardware provides, potentially very many, and it is expensive >> > and needless to read/write them all every time on entry/exit. >> > >> > I would prefer to avoid that, but I'll be honest: I can be convinced >> > that that model of handling LRs is so much simpler that it is worth it. >> > I am more concerned about the future maintainance of a separate new >> > driver developed elsewhere. >> >> I think this LR topic should have been covered in that other email. >> >> Beside being a strong supporter of the KISS principle in general, I >> believe in case of the GIC emulation we should avoid (premature) >> optimizations like the plague, as there are quite some corner cases in >> any VGIC, and handling all of them explicitly with some hacks will not >> fly (been there, done that). >> So I can just support Christoffer's point: having an architecture >> compliant VGIC emulation in an maintainable manner requires a >> straight-forward and clear design. Everything else should be secondary, >> and can be evaluated later, if there are good reasons (numbers!). > > The reason why I stated the above is that I ran the numbers back in the > day and reading or writing LRs on an XGene was so slow that it made > sense to avoid it as much as possible. But maybe things have changed if > Christoffer also ran the numbers and managed to demonstrate the > opposite. Accessing LRs on GICv2 is terrible indeed, and we already optimize it as much as it makes sense. It's just that with the current KVM code base reading/writing the same value almost never happens, so there's no more room (in practice) for optimization. Also, note with GICv3 the cost goes down a lot, and potentially also for other integrations of GICv2. -Christoffer ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 115471: regressions - FAIL
flight 115471 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/115471/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 6 xen-install fail in 115401 pass in 115471 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail in 115401 pass in 115471 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail in 115401 pass in 115471 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 115401 pass in 115471 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 115401 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail pass in 115450 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114644 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114644 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114644 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114644 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114644 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 114644 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 114644 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: xen bb2c1a1cc98a22e2d4c14b18421aa7be6c2adf0d baseline version: xen 24fb44e971a62b345c7b6ca3c03b454a1e150abe Last test of basis 114644 2017-10-17 10:49:11 Z 15 days Failing since114670 2017-10-18 05:03:38 Z 15 days 24 attempts Testing same since 115314 2017-10-28 05:53:13 Z5 days 10 attempts People who touched revisions under test: Andre Przywara Andrew Cooper Anthony PERARD Bhupinder Thaku
[Xen-devel] d0v0 Unhandled general protection fault with 4.9.x on brand new hardware
Hi everyone, I need to address an issue that prevents me from running Xen on new hardware. It's an HPE DL360 Gen10 with double Xeon Silver 4108 CPU and 256GB ECC DDR4 RDIMM. It happens with both CentOS6 and CentOS7. When I try to boot with Xen kernel 4.9.58-29.el6, I get the following error at boot time (I can read it from the serial console): (XEN) Brought up 32 CPUs (XEN) ACPI sleep modes: S3 (XEN) VPMU: disabled (XEN) mcheck_poll: Machine check polling timer started. (XEN) Dom0 has maximum 1240 PIRQs (XEN) NX (Execute Disable) protection active (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x26a (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 003fdc00->003fe000 (1012299 pages to be allocated) (XEN) Init. ramdisk: 00403b04b000->00403fdff200 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: 8100->826a (XEN) Init. ramdisk: -> (XEN) Phys-Mach map: 0080->00800080 (XEN) Start info:826a->826a04b4 (XEN) Page tables: 826a1000->826b8000 (XEN) Boot stack:826b8000->826b9000 (XEN) TOTAL: 8000->8280 (XEN) ENTRY ADDRESS: 821a9180 (XEN) Dom0 has maximum 32 VCPUs (XEN) Scrubbing Free RAM on 2 nodes using 16 CPUs (XEN) .done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 300kB init memory. mapping kernel into physical memory about to get started... (XEN) d0v0 Unhandled general protection fault fault/trap [#13, ec=] (XEN) domain_crash_sync called from entry.S: fault at 82d08022f983 create_bounce_frame+0x12b/0x13a (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) [ Xen-4.6.6-3.el6 x86_64 debug=n Not tainted ] (XEN) CPU:0 (XEN) RIP:e033:[] (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest (d0v0) (XEN) rax: 02ff rbx: 8217a1a0 rcx: (XEN) rdx: rsi: 02ff rdi: 00042660 (XEN) rbp: 82003dc8 rsp: 82003d80 r8: 82003e0c (XEN) r9: 82003e08 r10: r11: (XEN) r12: 82003e04 r13: 82003e00 r14: 82003dfc (XEN) r15: 82003df8 cr0: 80050033 cr4: 003526e0 (XEN) cr3: 003fde007000 cr2: (XEN) ds: es: fs: gs: ss: e02b cs: e033 (XEN) Guest stack trace from rsp=82003d80: (XEN) 8103cf38 (XEN)0001e030 00010046 82003dc8 e02b (XEN)8103cf28 82003e48 821bbd3e 82199890 (XEN)8219a090 82199890 8219a090 82003e38 (XEN)00100800 0a88 02ff0240 8217a1a0 (XEN)8217a1a0 82673000 82003f20 (XEN) 82003e78 821bb684 0100 (XEN)037f82673000 82003f20 0100 82003e88 (XEN)821bc371 82003e98 821bc3a7 82003ef8 (XEN)821b73e7 0010 82003f08 82003ec8 (XEN)82003e88 8114b100 (XEN) 82003f28 (XEN)821aa0c6 b013b3f5b0133a3e (XEN)821a97ac 82003f38 821a9386 82003ff8 (XEN)821b0dc6 03010032 0005 (XEN) (XEN) (XEN) (XEN) ffd83a831fc9cbf5 (XEN)0005065400100800 0001 (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. So far I tried (to no avail): - installing older Xen kernel version (4.9.39-29.el6 and 4.9.25-27.el6) - installing older Xen version (4.6.3-15.el6) instead of the current one (4.6.6-3.el6) - disabling Hypertreading - disabling NUMA - changing several dom0_mem=,max: configurations (from 512M up to to 20G) - changing several BIOS options including power profiles etc. I read that someone else with a similar problem solved by setting some parameters in the kernel command line, but I have no clue. Can you help me? Thanks
Re: [Xen-devel] [PATCH v3 for-next 4/4] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN
At 14:03 + on 01 Nov (1509544996), Julien Grall wrote: > Most of the users of page_to_mfn and mfn_to_page are either overriding > the macros to make them work with mfn_t or use mfn_x/_mfn because the > rest of the function use mfn_t. > > So make __page_to_mfn and __mfn_to_page return mfn_t by default. > > Only reasonable clean-ups are done in this patch because it is > already quite big. So some of the files now override page_to_mfn and > mfn_to_page to avoid using mfn_t. > > Lastly, domain_page_to_mfn is also converted to use mfn_t given that > most of the callers are now switched to _mfn(domain_page_to_mfn(...)). > > Signed-off-by: Julien Grall Acked-by: Tim Deegan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 115477: regressions - FAIL
flight 115477 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/115477/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 114507 build-amd64-xsm 6 xen-buildfail REGR. vs. 114507 build-i386-xsm6 xen-buildfail REGR. vs. 114507 build-amd64 6 xen-buildfail REGR. vs. 114507 build-armhf 6 xen-buildfail REGR. vs. 114507 build-armhf-xsm 6 xen-buildfail REGR. vs. 114507 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qcow2 1 build-check(1) blocked n/a 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 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-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 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-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 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-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 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 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 b
Re: [Xen-devel] Commit moratorium to staging
On Wed, Nov 01, 2017 at 04:17:10PM +, Roger Pau Monné wrote: > On Wed, Nov 01, 2017 at 02:07:48PM +, Ian Jackson wrote: > > * Affected hosts differ from unaffected hosts according to cpuid. > > Roger has repro'd the bug on an unaffected host by masking out > > certain cpuid bits. There are 6 implicated bits and he is working > > to narrow that down. > > I'm currently trying to narrow this down and make sure the above is > accurate. So I was wrong with this, I guess I've run the tests on the wrong host. Even when masking the different cpuid bits in the guest the tests still succeeds. AFAICT the test fail or succeed reliably depending on the host hardware. I don't really have many ideas about what to do next, but I think it would be useful to create a manual osstest flight that runs the win16 job in all the different hosts in the colo. I would also capture the normal information that Xen collects after each test (xl info, /proc/cpuid, serial logs...). Is there anything else not captured by ts-logs-capture that would be interesting in order to help debug the issue? Regards, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-wheezy test] 72404: all pass
flight 72404 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72404/ Perfect :-) All tests in this flight passed as required baseline version: flight 72354 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass test-amd64-i386-i386-wheezy-netboot-pvgrub pass test-amd64-i386-amd64-wheezy-netboot-pygrub pass test-amd64-amd64-i386-wheezy-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/5] xen: add grant interface version dependent constants to gnttab_ops
Instead of having multiple variables with constants like
grant_table_version or grefs_per_grant_frame add those to struct
gnttab_ops and access them just via the gnttab_interface pointer.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 73 ---
1 file changed, 43 insertions(+), 30 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index db6a1b9efd11..573e7fe9b147 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -78,6 +78,14 @@ static union {
/*This is a structure of function pointers for grant table*/
struct gnttab_ops {
/*
+* Version of the grant interface.
+*/
+ unsigned int version;
+ /*
+* Grant refs per grant frame.
+*/
+ unsigned int grefs_per_grant_frame;
+ /*
* Mapping a list of frames for storing grant entries. Frames parameter
* is used to store grant table address when grant table being setup,
* nr_gframes is the number of frames to map grant table. Returning
@@ -134,9 +142,6 @@ static const struct gnttab_ops *gnttab_interface;
/* This reflects status of grant entries, so act as a global value. */
static grant_status_t *grstatus;
-static int grant_table_version;
-static int grefs_per_grant_frame;
-
static struct gnttab_free_callback *gnttab_free_callback_list;
static int gnttab_expand(unsigned int req_entries);
@@ -636,19 +641,26 @@ void gnttab_cancel_free_callback(struct
gnttab_free_callback *callback)
}
EXPORT_SYMBOL_GPL(gnttab_cancel_free_callback);
+static unsigned int gnttab_frames(unsigned int frames, unsigned int align)
+{
+ return (frames * gnttab_interface->grefs_per_grant_frame + align - 1) /
+ align;
+}
+
static int grow_gnttab_list(unsigned int more_frames)
{
unsigned int new_nr_grant_frames, extra_entries, i;
unsigned int nr_glist_frames, new_nr_glist_frames;
+ unsigned int grefs_per_frame;
- BUG_ON(grefs_per_grant_frame == 0);
+ BUG_ON(gnttab_interface == NULL);
+ grefs_per_frame = gnttab_interface->grefs_per_grant_frame;
new_nr_grant_frames = nr_grant_frames + more_frames;
- extra_entries = more_frames * grefs_per_grant_frame;
+ extra_entries = more_frames * grefs_per_frame;
- nr_glist_frames = (nr_grant_frames * grefs_per_grant_frame + RPP - 1) /
RPP;
- new_nr_glist_frames =
- (new_nr_grant_frames * grefs_per_grant_frame + RPP - 1) / RPP;
+ nr_glist_frames = gnttab_frames(nr_grant_frames, RPP);
+ new_nr_glist_frames = gnttab_frames(new_nr_grant_frames, RPP);
for (i = nr_glist_frames; i < new_nr_glist_frames; i++) {
gnttab_list[i] = (grant_ref_t *)__get_free_page(GFP_ATOMIC);
if (!gnttab_list[i])
@@ -656,12 +668,12 @@ static int grow_gnttab_list(unsigned int more_frames)
}
- for (i = grefs_per_grant_frame * nr_grant_frames;
-i < grefs_per_grant_frame * new_nr_grant_frames - 1; i++)
+ for (i = grefs_per_frame * nr_grant_frames;
+i < grefs_per_frame * new_nr_grant_frames - 1; i++)
gnttab_entry(i) = i + 1;
gnttab_entry(i) = gnttab_free_head;
- gnttab_free_head = grefs_per_grant_frame * nr_grant_frames;
+ gnttab_free_head = grefs_per_frame * nr_grant_frames;
gnttab_free_count += extra_entries;
nr_grant_frames = new_nr_grant_frames;
@@ -1013,8 +1025,8 @@ EXPORT_SYMBOL_GPL(gnttab_unmap_refs_sync);
static unsigned int nr_status_frames(unsigned int nr_grant_frames)
{
- BUG_ON(grefs_per_grant_frame == 0);
- return (nr_grant_frames * grefs_per_grant_frame + SPP - 1) / SPP;
+ BUG_ON(gnttab_interface == NULL);
+ return gnttab_frames(nr_grant_frames, SPP);
}
static int gnttab_map_frames_v1(xen_pfn_t *frames, unsigned int nr_gframes)
@@ -1142,6 +1154,9 @@ static int gnttab_map(unsigned int start_idx, unsigned
int end_idx)
}
static const struct gnttab_ops gnttab_v1_ops = {
+ .version= 1,
+ .grefs_per_grant_frame = XEN_PAGE_SIZE /
+ sizeof(struct grant_entry_v1),
.map_frames = gnttab_map_frames_v1,
.unmap_frames = gnttab_unmap_frames_v1,
.update_entry = gnttab_update_entry_v1,
@@ -1151,6 +1166,9 @@ static const struct gnttab_ops gnttab_v1_ops = {
};
static const struct gnttab_ops gnttab_v2_ops = {
+ .version= 2,
+ .grefs_per_grant_frame = XEN_PAGE_SIZE /
+ sizeof(union grant_entry_v2),
.map_frames = gnttab_map_frames_v2,
.unmap_frames = gnttab_unmap_frames_v2,
.update_entry = gnttab_update_entry_v2,
@@ -1167,18 +1185
[Xen-devel] [PATCH v2 1/5] xen: re-introduce support for grant v2 interface
The grant v2 support was removed from the kernel with
commit 438b33c7145ca8a5131a30c36d8f59bce119a19a ("xen/grant-table:
remove support for V2 tables") as the higher memory footprint of v2
grants resulted in less grants being possible for a kernel compared
to the v1 grant interface.
As machines with more than 16TB of memory are expected to be more
common in the near future support of grant v2 is mandatory in order
to be able to run a Xen pv domain at any memory location.
So re-add grant v2 support basically by reverting above commit.
Signed-off-by: Juergen Gross
---
arch/arm/xen/grant-table.c | 9 +-
arch/x86/xen/grant-table.c | 60 -
drivers/xen/grant-table.c | 312 -
include/xen/grant_table.h | 30 -
4 files changed, 398 insertions(+), 13 deletions(-)
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
index e43791829ace..91cf08ba1e95 100644
--- a/arch/arm/xen/grant-table.c
+++ b/arch/arm/xen/grant-table.c
@@ -45,7 +45,14 @@ void arch_gnttab_unmap(void *shared, unsigned long
nr_gframes)
return;
}
-int arch_gnttab_init(unsigned long nr_shared)
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+ unsigned long max_nr_gframes,
+ grant_status_t **__shared)
+{
+ return -ENOSYS;
+}
+
+int arch_gnttab_init(unsigned long nr_shared, unsigned long nr_status)
{
return 0;
}
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 809b6c812654..92ccc718152d 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -49,7 +49,7 @@
static struct gnttab_vm_area {
struct vm_struct *area;
pte_t **ptes;
-} gnttab_shared_vm_area;
+} gnttab_shared_vm_area, gnttab_status_vm_area;
int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
unsigned long max_nr_gframes,
@@ -73,16 +73,43 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned
long nr_gframes,
return 0;
}
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+ unsigned long max_nr_gframes,
+ grant_status_t **__shared)
+{
+ grant_status_t *shared = *__shared;
+ unsigned long addr;
+ unsigned long i;
+
+ if (shared == NULL)
+ *__shared = shared = gnttab_status_vm_area.area->addr;
+
+ addr = (unsigned long)shared;
+
+ for (i = 0; i < nr_gframes; i++) {
+ set_pte_at(&init_mm, addr, gnttab_status_vm_area.ptes[i],
+ mfn_pte(frames[i], PAGE_KERNEL));
+ addr += PAGE_SIZE;
+ }
+
+ return 0;
+}
+
void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
{
+ pte_t **ptes;
unsigned long addr;
unsigned long i;
+ if (shared == gnttab_status_vm_area.area->addr)
+ ptes = gnttab_status_vm_area.ptes;
+ else
+ ptes = gnttab_shared_vm_area.ptes;
+
addr = (unsigned long)shared;
for (i = 0; i < nr_gframes; i++) {
- set_pte_at(&init_mm, addr, gnttab_shared_vm_area.ptes[i],
- __pte(0));
+ set_pte_at(&init_mm, addr, ptes[i], __pte(0));
addr += PAGE_SIZE;
}
}
@@ -102,12 +129,35 @@ static int arch_gnttab_valloc(struct gnttab_vm_area
*area, unsigned nr_frames)
return 0;
}
-int arch_gnttab_init(unsigned long nr_shared)
+static void arch_gnttab_vfree(struct gnttab_vm_area *area)
{
+ free_vm_area(area->area);
+ kfree(area->ptes);
+}
+
+int arch_gnttab_init(unsigned long nr_shared, unsigned long nr_status)
+{
+ int ret;
+
if (!xen_pv_domain())
return 0;
- return arch_gnttab_valloc(&gnttab_shared_vm_area, nr_shared);
+ ret = arch_gnttab_valloc(&gnttab_shared_vm_area, nr_shared);
+ if (ret < 0)
+ return ret;
+
+ /*
+* Always allocate the space for the status frames in case
+* we're migrated to a host with V2 support.
+*/
+ ret = arch_gnttab_valloc(&gnttab_status_vm_area, nr_status);
+ if (ret < 0)
+ goto err;
+
+ return 0;
+err:
+ arch_gnttab_vfree(&gnttab_shared_vm_area);
+ return -ENOMEM;
}
#ifdef CONFIG_XEN_PVH
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 2c6a9114d332..65c4bdb0b463 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -71,6 +71,7 @@ struct grant_frames xen_auto_xlat_grant_frames;
static union {
struct grant_entry_v1 *v1;
+ union grant_entry_v2 *v2;
void *addr;
} gnttab_shared;
@@ -121,6 +122,29 @@ struct gnttab_ops {
* by bit operations.
*/
int (*query_foreign_access)(grant_ref_t ref);
+ /*
+* Grant a domain to access a range of bytes within the page referred by
[Xen-devel] [PATCH v2 0/5] xen: grant table interface v2 support
In order to support Linux to run as a pv guest on machines with huge memory (>16TB) or as a hvm guest with more than 16TB of memory the kernel has to support grant table interface v2, as v1 is limited to 32 bit frame numbers. This series re-adds that support (it has been removed in 2015) and restricts usage of v2 to the features of v1 in order to support migration to hosts which only support v1. V2 is selected only in the following cases: - the user has specified v2 via module parameter - in a pv guest if the maximum possible memory address of the host is above 16TB (memory hotplug taken into account) - in a hvm guest if the maximum guest memory address is above 16TB (again with memory hotplug taken into account) Changes in V2: - patch 2: remove update_trans_entry() from gnttab_ops (Boris Ostrovsky) - added new patch 4 - patch 5: use cpuid on pv and max_possible_pfn on hvm for version select Juergen Gross (5): xen: re-introduce support for grant v2 interface xen: limit grant v2 interface to the v1 functionality xen: add grant interface version dependent constants to gnttab_ops xen: update arch/x86/include/asm/xen/cpuid.h xen: select grant interface version arch/arm/xen/grant-table.c | 9 +- arch/x86/include/asm/xen/cpuid.h | 42 +-- arch/x86/xen/grant-table.c | 60 +- drivers/xen/grant-table.c| 244 +++ include/xen/grant_table.h| 5 +- 5 files changed, 318 insertions(+), 42 deletions(-) -- 2.12.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/5] xen: limit grant v2 interface to the v1 functionality
As there is currently no user for sub-page grants or transient grants
remove that functionality. This at once makes it possible to switch
from grant v2 to grant v1 without restrictions, as there is no loss of
functionality other than the limited frame number width related to
the switch.
Signed-off-by: Juergen Gross
---
V2:
- remove update_trans_entry() from gnttab_ops (Boris Ostrovsky)
---
drivers/xen/grant-table.c | 150 --
include/xen/grant_table.h | 25
2 files changed, 175 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 65c4bdb0b463..db6a1b9efd11 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -122,29 +122,6 @@ struct gnttab_ops {
* by bit operations.
*/
int (*query_foreign_access)(grant_ref_t ref);
- /*
-* Grant a domain to access a range of bytes within the page referred by
-* an available grant entry. Ref parameter is reference of a grant entry
-* which will be sub-page accessed, domid is id of grantee domain, frame
-* is frame address of subpage grant, flags is grant type and flag
-* information, page_off is offset of the range of bytes, and length is
-* length of bytes to be accessed.
-*/
- void (*update_subpage_entry)(grant_ref_t ref, domid_t domid,
-unsigned long frame, int flags,
-unsigned page_off, unsigned length);
- /*
-* Redirect an available grant entry on domain A to another grant
-* reference of domain B, then allow domain C to use grant reference
-* of domain B transitively. Ref parameter is an available grant entry
-* reference on domain A, domid is id of domain C which accesses grant
-* entry transitively, flags is grant type and flag information,
-* trans_domid is id of domain B whose grant entry is finally accessed
-* transitively, trans_gref is grant entry transitive reference of
-* domain B.
-*/
- void (*update_trans_entry)(grant_ref_t ref, domid_t domid, int flags,
- domid_t trans_domid, grant_ref_t trans_gref);
};
struct unmap_refs_callback_data {
@@ -292,122 +269,6 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned
long frame,
}
EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
-static void gnttab_update_subpage_entry_v2(grant_ref_t ref, domid_t domid,
- unsigned long frame, int flags,
- unsigned page_off, unsigned length)
-{
- gnttab_shared.v2[ref].sub_page.frame = frame;
- gnttab_shared.v2[ref].sub_page.page_off = page_off;
- gnttab_shared.v2[ref].sub_page.length = length;
- gnttab_shared.v2[ref].hdr.domid = domid;
- wmb();
- gnttab_shared.v2[ref].hdr.flags =
- GTF_permit_access | GTF_sub_page | flags;
-}
-
-int gnttab_grant_foreign_access_subpage_ref(grant_ref_t ref, domid_t domid,
- unsigned long frame, int flags,
- unsigned page_off,
- unsigned length)
-{
- if (flags & (GTF_accept_transfer | GTF_reading |
-GTF_writing | GTF_transitive))
- return -EPERM;
-
- if (gnttab_interface->update_subpage_entry == NULL)
- return -ENOSYS;
-
- gnttab_interface->update_subpage_entry(ref, domid, frame, flags,
- page_off, length);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage_ref);
-
-int gnttab_grant_foreign_access_subpage(domid_t domid, unsigned long frame,
- int flags, unsigned page_off,
- unsigned length)
-{
- int ref, rc;
-
- ref = get_free_entries(1);
- if (unlikely(ref < 0))
- return -ENOSPC;
-
- rc = gnttab_grant_foreign_access_subpage_ref(ref, domid, frame, flags,
-page_off, length);
- if (rc < 0) {
- put_free_entry(ref);
- return rc;
- }
-
- return ref;
-}
-EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_subpage);
-
-bool gnttab_subpage_grants_available(void)
-{
- return gnttab_interface->update_subpage_entry != NULL;
-}
-EXPORT_SYMBOL_GPL(gnttab_subpage_grants_available);
-
-static void gnttab_update_trans_entry_v2(grant_ref_t ref, domid_t domid,
-int flags, domid_t trans_domid,
-grant_ref_t trans_gref)
-{
- gnttab_shared.v2[ref].transitive.trans_domid = trans_domid;
- gnttab_shared.v2[ref].transitive.gref = trans_gref;
- gnttab_shared.v2[ref].hdr.do
[Xen-devel] [PATCH v2 5/5] xen: select grant interface version
Grant v2 will be needed in cases where a frame number in the grant
table can exceed 32 bits. For PV guests this is a host feature, while
for HVM guests this is a guest feature.
So select grant v2 in case frame numbers can be larger than 32 bits
and grant v1 else.
For testing purposes add a way to specify the grant interface version
via a boot parameter.
Signed-off-by: Juergen Gross
---
V2:
- use cpuid on pv and max_possible_pfn on hvm for version select
---
drivers/xen/grant-table.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 573e7fe9b147..fa152832e0e6 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -33,6 +33,7 @@
#define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
+#include
#include
#include
#include
@@ -43,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -52,6 +54,9 @@
#include
#include
#include
+#ifdef CONFIG_X86
+#include
+#endif
#include
#include
@@ -68,6 +73,8 @@ static int gnttab_free_count;
static grant_ref_t gnttab_free_head;
static DEFINE_SPINLOCK(gnttab_list_lock);
struct grant_frames xen_auto_xlat_grant_frames;
+static unsigned int xen_gnttab_version;
+module_param_named(version, xen_gnttab_version, uint, 0);
static union {
struct grant_entry_v1 *v1;
@@ -1177,12 +1184,36 @@ static const struct gnttab_ops gnttab_v2_ops = {
.query_foreign_access = gnttab_query_foreign_access_v2,
};
+static bool gnttab_need_v2(void)
+{
+#ifdef CONFIG_X86
+ uint32_t base, width;
+
+ if (xen_pv_domain()) {
+ base = xen_cpuid_base();
+ if (cpuid_eax(base) < 5)
+ return false; /* Information not available, use V1. */
+ width = cpuid_ebx(base + 5) &
+ XEN_CPUID_MACHINE_ADDRESS_WIDTH_MASK;
+ return width > 32 + PAGE_SHIFT;
+ }
+#endif
+ return !!(max_possible_pfn >> 32);
+}
+
static void gnttab_request_version(void)
{
- int rc;
+ long rc;
struct gnttab_set_version gsv;
- gsv.version = 1;
+ if (gnttab_need_v2())
+ gsv.version = 2;
+ else
+ gsv.version = 1;
+
+ /* Boot parameter overrides automatic selection. */
+ if (xen_gnttab_version >= 1 && xen_gnttab_version <= 2)
+ gsv.version = xen_gnttab_version;
rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
if (rc == 0 && gsv.version == 2)
--
2.12.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 4/5] xen: update arch/x86/include/asm/xen/cpuid.h
Update arch/x86/include/asm/xen/cpuid.h from the Xen tree to get newest definitions. Signed-off-by: Juergen Gross --- arch/x86/include/asm/xen/cpuid.h | 42 ++-- 1 file changed, 32 insertions(+), 10 deletions(-) diff --git a/arch/x86/include/asm/xen/cpuid.h b/arch/x86/include/asm/xen/cpuid.h index 3bdd10d71223..a9630104f1c4 100644 --- a/arch/x86/include/asm/xen/cpuid.h +++ b/arch/x86/include/asm/xen/cpuid.h @@ -74,21 +74,43 @@ #define XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD (1u<<0) /* + * Leaf 4 (0x4x03) + * Sub-leaf 0: EAX: bit 0: emulated tsc + * bit 1: host tsc is known to be reliable + * bit 2: RDTSCP instruction available + * EBX: tsc_mode: 0=default (emulate if necessary), 1=emulate, + *2=no emulation, 3=no emulation + TSC_AUX support + * ECX: guest tsc frequency in kHz + * EDX: guest tsc incarnation (migration count) + * Sub-leaf 1: EAX: tsc offset low part + * EBX: tsc offset high part + * ECX: multiplicator for tsc->ns conversion + * EDX: shift amount for tsc->ns conversion + * Sub-leaf 2: EAX: host tsc frequency in kHz + */ + +/* * Leaf 5 (0x4x04) * HVM-specific features - * EAX: Features - * EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag) + * Sub-leaf 0: EAX: Features + * Sub-leaf 0: EBX: vcpu id (iff EAX has XEN_HVM_CPUID_VCPU_ID_PRESENT flag) */ - -/* Virtualized APIC registers */ -#define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) -/* Virtualized x2APIC accesses */ -#define XEN_HVM_CPUID_X2APIC_VIRT (1u << 1) +#define XEN_HVM_CPUID_APIC_ACCESS_VIRT (1u << 0) /* Virtualized APIC registers */ +#define XEN_HVM_CPUID_X2APIC_VIRT (1u << 1) /* Virtualized x2APIC accesses */ /* Memory mapped from other domains has valid IOMMU entries */ #define XEN_HVM_CPUID_IOMMU_MAPPINGS (1u << 2) -/* vcpu id is present in EBX */ -#define XEN_HVM_CPUID_VCPU_ID_PRESENT (1u << 3) +#define XEN_HVM_CPUID_VCPU_ID_PRESENT (1u << 3) /* vcpu id is present in EBX */ + +/* + * Leaf 6 (0x4x05) + * PV-specific parameters + * Sub-leaf 0: EAX: max available sub-leaf + * Sub-leaf 0: EBX: bits 0-7: max machine address width + */ + +/* Max. address width in bits taking memory hotplug into account. */ +#define XEN_CPUID_MACHINE_ADDRESS_WIDTH_MASK (0xffu << 0) -#define XEN_CPUID_MAX_NUM_LEAVES 4 +#define XEN_CPUID_MAX_NUM_LEAVES 5 #endif /* __XEN_PUBLIC_ARCH_X86_CPUID_H__ */ -- 2.12.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Commit moratorium to staging
> -Original Message- > From: Roger Pau Monne > Sent: 02 November 2017 09:15 > To: Roger Pau Monne > Cc: Ian Jackson ; Lars Kurth > ; Wei Liu ; Julien Grall > ; Paul Durrant ; > committ...@xenproject.org; xen-devel > Subject: Re: [Xen-devel] Commit moratorium to staging > > On Wed, Nov 01, 2017 at 04:17:10PM +, Roger Pau Monné wrote: > > On Wed, Nov 01, 2017 at 02:07:48PM +, Ian Jackson wrote: > > > * Affected hosts differ from unaffected hosts according to cpuid. > > > Roger has repro'd the bug on an unaffected host by masking out > > > certain cpuid bits. There are 6 implicated bits and he is working > > > to narrow that down. > > > > I'm currently trying to narrow this down and make sure the above is > > accurate. > > So I was wrong with this, I guess I've run the tests on the wrong > host. Even when masking the different cpuid bits in the guest the > tests still succeeds. > > AFAICT the test fail or succeed reliably depending on the host > hardware. I don't really have many ideas about what to do next, but I > think it would be useful to create a manual osstest flight that runs > the win16 job in all the different hosts in the colo. I would also > capture the normal information that Xen collects after each test (xl > info, /proc/cpuid, serial logs...). > > Is there anything else not captured by ts-logs-capture that would be > interesting in order to help debug the issue? Does the shutdown reliably complete prior to migrate and then only fail intermittently after a localhost migrate? It might be useful to know what cpuid info is seen by the guest before and after migrate. Another datapoint... does the shutdown fail if you insert a delay of a couple of minutes between the migrate and the shutdown? Paul > > Regards, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: support priv-mapping in an HVM tools domain
> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 01 November 2017 18:19 > To: Juergen Gross ; Paul Durrant > ; x...@kernel.org; xen- > de...@lists.xenproject.org; linux-ker...@vger.kernel.org > Cc: Thomas Gleixner ; Ingo Molnar > ; H. Peter Anvin > Subject: Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain > > On 11/01/2017 11:37 AM, Juergen Gross wrote: > > > > TBH I like V1 better, too. > > > > Boris, do you feel strong about the #ifdef part? > > Having looked at what this turned into I now like V1 better too ;-) > > Sorry, Paul. That's ok. Are you happy with v1 as-is or do you want me to submit a v3 with any tweaks? Paul > > > -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] d0v0 Unhandled general protection fault with 4.9.x on brand new hardware
On 02/11/17 08:56, Francesco De Francesco wrote: > Hi everyone, > > I need to address an issue that prevents me from running Xen on new > hardware. It's an HPE DL360 Gen10 with double Xeon Silver 4108 CPU and > 256GB ECC DDR4 RDIMM. It happens with both CentOS6 and CentOS7. > > When I try to boot with Xen kernel 4.9.58-29.el6, I get the following > error at boot time (I can read it from the serial console): > > (XEN) Brought up 32 CPUs > (XEN) ACPI sleep modes: S3 > (XEN) VPMU: disabled > (XEN) mcheck_poll: Machine check polling timer started. > (XEN) Dom0 has maximum 1240 PIRQs > (XEN) NX (Execute Disable) protection active > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x26a > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 003fdc00->003fe000 (1012299 pages > to be allocated) > (XEN) Init. ramdisk: 00403b04b000->00403fdff200 > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: 8100->826a > (XEN) Init. ramdisk: -> > (XEN) Phys-Mach map: 0080->00800080 > (XEN) Start info: 826a->826a04b4 > (XEN) Page tables: 826a1000->826b8000 > (XEN) Boot stack: 826b8000->826b9000 > (XEN) TOTAL: 8000->8280 > (XEN) ENTRY ADDRESS: 821a9180 > (XEN) Dom0 has maximum 32 VCPUs > (XEN) Scrubbing Free RAM on 2 nodes using 16 CPUs > (XEN) > .done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch > input to Xen) > (XEN) Freed 300kB init memory. > mapping kernel into physical memory > about to get started... > (XEN) d0v0 Unhandled general protection fault fault/trap [#13, ec=] > (XEN) domain_crash_sync called from entry.S: fault at 82d08022f983 > create_bounce_frame+0x12b/0x13a > (XEN) Domain 0 (vcpu#0) crashed on cpu#0: > (XEN) [ Xen-4.6.6-3.el6 x86_64 debug=n Not tainted ] > (XEN) CPU: 0 > (XEN) RIP: e033:[] > (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest (d0v0) > (XEN) rax: 02ff rbx: 8217a1a0 rcx: > (XEN) rdx: rsi: 02ff rdi: 00042660 > (XEN) rbp: 82003dc8 rsp: 82003d80 r8: 82003e0c > (XEN) r9: 82003e08 r10: r11: > (XEN) r12: 82003e04 r13: 82003e00 r14: 82003dfc > (XEN) r15: 82003df8 cr0: 80050033 cr4: 003526e0 > (XEN) cr3: 003fde007000 cr2: > (XEN) ds: es: fs: gs: ss: e02b cs: e033 > (XEN) Guest stack trace from rsp=82003d80: > (XEN) 8103cf38 > (XEN) 0001e030 00010046 82003dc8 e02b > (XEN) 8103cf28 82003e48 821bbd3e 82199890 > (XEN) 8219a090 82199890 8219a090 82003e38 > (XEN) 00100800 0a88 02ff0240 8217a1a0 > (XEN) 8217a1a0 82673000 82003f20 > (XEN) 82003e78 821bb684 0100 > (XEN) 037f82673000 82003f20 0100 82003e88 > (XEN) 821bc371 82003e98 821bc3a7 82003ef8 > (XEN) 821b73e7 0010 82003f08 82003ec8 > (XEN) 82003e88 8114b100 > (XEN) 82003f28 > (XEN) 821aa0c6 b013b3f5b0133a3e > (XEN) 821a97ac 82003f38 821a9386 82003ff8 > (XEN) 821b0dc6 03010032 0005 > (XEN) > (XEN) > (XEN) > (XEN) ffd83a831fc9cbf5 > (XEN) 0005065400100800 0001 > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. So your dom0 crashed very early before trap handlers have been set up. Can you please try to find matching source lines for suspected kernel addresses in above stack trace and for the guest's RIP: for all addresses starting with "81" you should try the addr2line tool to obtain that information. This will
Re: [Xen-devel] Commit moratorium to staging
On Thu, Nov 02, 2017 at 09:20:10AM +, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 02 November 2017 09:15 > > To: Roger Pau Monne > > Cc: Ian Jackson ; Lars Kurth > > ; Wei Liu ; Julien Grall > > ; Paul Durrant ; > > committ...@xenproject.org; xen-devel > > Subject: Re: [Xen-devel] Commit moratorium to staging > > > > On Wed, Nov 01, 2017 at 04:17:10PM +, Roger Pau Monné wrote: > > > On Wed, Nov 01, 2017 at 02:07:48PM +, Ian Jackson wrote: > > > > * Affected hosts differ from unaffected hosts according to cpuid. > > > > Roger has repro'd the bug on an unaffected host by masking out > > > > certain cpuid bits. There are 6 implicated bits and he is working > > > > to narrow that down. > > > > > > I'm currently trying to narrow this down and make sure the above is > > > accurate. > > > > So I was wrong with this, I guess I've run the tests on the wrong > > host. Even when masking the different cpuid bits in the guest the > > tests still succeeds. > > > > AFAICT the test fail or succeed reliably depending on the host > > hardware. I don't really have many ideas about what to do next, but I > > think it would be useful to create a manual osstest flight that runs > > the win16 job in all the different hosts in the colo. I would also > > capture the normal information that Xen collects after each test (xl > > info, /proc/cpuid, serial logs...). > > > > Is there anything else not captured by ts-logs-capture that would be > > interesting in order to help debug the issue? > > Does the shutdown reliably complete prior to migrate and then only fail > intermittently after a localhost migrate? AFAICT yes, but it can also be added to the test in order to be sure. > It might be useful to know what cpuid info is seen by the guest before and > after migrate. Is there anyway to get that from windows in an automatic way? If not I could test that with a Debian guest. In fact it might even be a good thing for Linux based guest to be added to the regular migration tests in order to make sure cpuid bits don't change across migrations. > Another datapoint... does the shutdown fail if you insert a delay of a couple > of minutes between the migrate and the shutdown? Sometimes, after a variable number of calls to xl shutdown ... the guest usually ends up shutting down. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] ALSA: vsnd: Add Xen para-virtualized frontend driver
On Oct 30 2017 15:33, Oleksandr Andrushchenko wrote: This is an attempt to summarize previous discussions on Xen para-virtual sound driver. A first attempt has been made to upstream the driver [1] which brought number of fundamental questions, one of the biggest ones was that the frontend driver has no means to synchronize its period elapsed event with the host driver, but uses software emulation on the guest side [2] with a timer. In order to address this a change to the existing Xen para-virtual sound protocol [3] was proposed to fill this gap [4] and remove emulation: 1. Introduced a new event channel from back to front 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS, to be used for sending snd_pcm_period_elapsed at frontend (in Linux implementation, sent in bytes, not frames to make the protocol generic and consistent) 3. New request for playback/capture control (XENSND_OP_TRIGGER) with start/pause/stop/resume sub-ops. Along with these changes other comments on the driver were addressed, e.g. split into smaller chunks, moved the driver from misc to xen etc. [5]. Hope, this helps to get the full picture of what was discussed and makes it possible to move forward: if the approach seems ok, then I'll start upstreaming the changes to the sndif protocol and then will send the updated version of the driver for the further review. This message has below line in its header. > In-Reply-To: This field is defined in RFC822[1], and recent mail clients use this header field to associate the message to a message which the field indicates. This results in a series of messages, so-called 'message thread'. Iwai-san would like you to start a new message thread for your topic. Would you please post this message again without the header field? Generally, receiving no reactions means that readers/reviewers don't get enough information for your idea yet. (Of course, there's a probability that your work attracts no one...) In this case, submitting more resources is better, rather than requesting comments to them. For instance, you can point links to backend/frontend implementation as para-virtualization drivers which use the new feature of interface, if you did work for it. Indicating procedure to use a series of your work is better for test, if possible. [1] https://www.ietf.org/rfc/rfc0822.txt Regards Takashi Sakamoto ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] d0v0 Unhandled general protection fault with 4.9.x on brand new hardware
do I have to run addr2line on my vmlinux image? 2017-11-02 10:31 GMT+01:00 Juergen Gross : > On 02/11/17 08:56, Francesco De Francesco wrote: > > Hi everyone, > > > > I need to address an issue that prevents me from running Xen on new > > hardware. It's an HPE DL360 Gen10 with double Xeon Silver 4108 CPU and > > 256GB ECC DDR4 RDIMM. It happens with both CentOS6 and CentOS7. > > > > When I try to boot with Xen kernel 4.9.58-29.el6, I get the following > > error at boot time (I can read it from the serial console): > > > > (XEN) Brought up 32 CPUs > > (XEN) ACPI sleep modes: S3 > > (XEN) VPMU: disabled > > (XEN) mcheck_poll: Machine check polling timer started. > > (XEN) Dom0 has maximum 1240 PIRQs > > (XEN) NX (Execute Disable) protection active > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Xen kernel: 64-bit, lsb, compat32 > > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x26a > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > > (XEN) Dom0 alloc.: 003fdc00->003fe000 (1012299 pages > > to be allocated) > > (XEN) Init. ramdisk: 00403b04b000->00403fdff200 > > (XEN) VIRTUAL MEMORY ARRANGEMENT: > > (XEN) Loaded kernel: 8100->826a > > (XEN) Init. ramdisk: -> > > (XEN) Phys-Mach map: 0080->00800080 > > (XEN) Start info:826a->826a04b4 > > (XEN) Page tables: 826a1000->826b8000 > > (XEN) Boot stack:826b8000->826b9000 > > (XEN) TOTAL: 8000->8280 > > (XEN) ENTRY ADDRESS: 821a9180 > > (XEN) Dom0 has maximum 32 VCPUs > > (XEN) Scrubbing Free RAM on 2 nodes using 16 CPUs > > (XEN) > > > .done. > > (XEN) Initial low memory virq threshold set at 0x4000 pages. > > (XEN) Std. Loglevel: All > > (XEN) Guest Loglevel: All > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch > > input to Xen) > > (XEN) Freed 300kB init memory. > > mapping kernel into physical memory > > about to get started... > > (XEN) d0v0 Unhandled general protection fault fault/trap [#13, ec=] > > (XEN) domain_crash_sync called from entry.S: fault at 82d08022f983 > > create_bounce_frame+0x12b/0x13a > > (XEN) Domain 0 (vcpu#0) crashed on cpu#0: > > (XEN) [ Xen-4.6.6-3.el6 x86_64 debug=n Not tainted ] > > (XEN) CPU:0 > > (XEN) RIP:e033:[] > > (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest (d0v0) > > (XEN) rax: 02ff rbx: 8217a1a0 rcx: > > > (XEN) rdx: rsi: 02ff rdi: > 00042660 > > (XEN) rbp: 82003dc8 rsp: 82003d80 r8: > 82003e0c > > (XEN) r9: 82003e08 r10: r11: > > > (XEN) r12: 82003e04 r13: 82003e00 r14: > 82003dfc > > (XEN) r15: 82003df8 cr0: 80050033 cr4: > 003526e0 > > (XEN) cr3: 003fde007000 cr2: > > (XEN) ds: es: fs: gs: ss: e02b cs: e033 > > (XEN) Guest stack trace from rsp=82003d80: > > (XEN) > 8103cf38 > > (XEN)0001e030 00010046 82003dc8 > e02b > > (XEN)8103cf28 82003e48 821bbd3e > 82199890 > > (XEN)8219a090 82199890 8219a090 > 82003e38 > > (XEN)00100800 0a88 02ff0240 > 8217a1a0 > > (XEN)8217a1a0 82673000 82003f20 > > > (XEN) 82003e78 821bb684 > 0100 > > (XEN)037f82673000 82003f20 0100 > 82003e88 > > (XEN)821bc371 82003e98 821bc3a7 > 82003ef8 > > (XEN)821b73e7 0010 82003f08 > 82003ec8 > > (XEN)82003e88 8114b100 > > > (XEN) > 82003f28 > > (XEN)821aa0c6 > b013b3f5b0133a3e > > (XEN)821a97ac 82003f38 821a9386 > 82003ff8 > > (XEN)821b0dc6 03010032 0005 > > > (XEN) > > > (XEN) > > > (XEN) > > > (XEN) > ffd83a831fc9cbf5 > > (XEN)0005065400100800 0001 > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. > > So
Re: [Xen-devel] [RFC] ALSA: vsnd: Add Xen para-virtualized frontend driver
On 11/02/2017 11:44 AM, Takashi Sakamoto wrote: On Oct 30 2017 15:33, Oleksandr Andrushchenko wrote: This is an attempt to summarize previous discussions on Xen para-virtual sound driver. A first attempt has been made to upstream the driver [1] which brought number of fundamental questions, one of the biggest ones was that the frontend driver has no means to synchronize its period elapsed event with the host driver, but uses software emulation on the guest side [2] with a timer. In order to address this a change to the existing Xen para-virtual sound protocol [3] was proposed to fill this gap [4] and remove emulation: 1. Introduced a new event channel from back to front 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS, to be used for sending snd_pcm_period_elapsed at frontend (in Linux implementation, sent in bytes, not frames to make the protocol generic and consistent) 3. New request for playback/capture control (XENSND_OP_TRIGGER) with start/pause/stop/resume sub-ops. Along with these changes other comments on the driver were addressed, e.g. split into smaller chunks, moved the driver from misc to xen etc. [5]. Hope, this helps to get the full picture of what was discussed and makes it possible to move forward: if the approach seems ok, then I'll start upstreaming the changes to the sndif protocol and then will send the updated version of the driver for the further review. This message has below line in its header. > In-Reply-To: This field is defined in RFC822[1], and recent mail clients use this header field to associate the message to a message which the field indicates. This results in a series of messages, so-called 'message thread'. Iwai-san would like you to start a new message thread for your topic. Would you please post this message again without the header field? of course, sorry about that Generally, receiving no reactions means that readers/reviewers don't get enough information for your idea yet. (Of course, there's a probability that your work attracts no one...) In this case, submitting more resources is better, rather than requesting comments to them. For instance, you can point links to backend/frontend implementation as para-virtualization drivers which use the new feature of interface, if you did work for it. Indicating procedure to use a series of your work is better for test, if possible. will do [1] https://www.ietf.org/rfc/rfc0822.txt Regards Takashi Sakamoto Thank you, Oleksandr ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Commit moratorium to staging
> -Original Message- > From: Roger Pau Monne > Sent: 02 November 2017 09:42 > To: Paul Durrant > Cc: Ian Jackson ; Lars Kurth > ; Wei Liu ; Julien Grall > ; committ...@xenproject.org; xen-devel de...@lists.xenproject.org> > Subject: Re: [Xen-devel] Commit moratorium to staging > > On Thu, Nov 02, 2017 at 09:20:10AM +, Paul Durrant wrote: > > > -Original Message- > > > From: Roger Pau Monne > > > Sent: 02 November 2017 09:15 > > > To: Roger Pau Monne > > > Cc: Ian Jackson ; Lars Kurth > > > ; Wei Liu ; Julien Grall > > > ; Paul Durrant ; > > > committ...@xenproject.org; xen-devel de...@lists.xenproject.org> > > > Subject: Re: [Xen-devel] Commit moratorium to staging > > > > > > On Wed, Nov 01, 2017 at 04:17:10PM +, Roger Pau Monné wrote: > > > > On Wed, Nov 01, 2017 at 02:07:48PM +, Ian Jackson wrote: > > > > > * Affected hosts differ from unaffected hosts according to cpuid. > > > > > Roger has repro'd the bug on an unaffected host by masking out > > > > > certain cpuid bits. There are 6 implicated bits and he is working > > > > > to narrow that down. > > > > > > > > I'm currently trying to narrow this down and make sure the above is > > > > accurate. > > > > > > So I was wrong with this, I guess I've run the tests on the wrong > > > host. Even when masking the different cpuid bits in the guest the > > > tests still succeeds. > > > > > > AFAICT the test fail or succeed reliably depending on the host > > > hardware. I don't really have many ideas about what to do next, but I > > > think it would be useful to create a manual osstest flight that runs > > > the win16 job in all the different hosts in the colo. I would also > > > capture the normal information that Xen collects after each test (xl > > > info, /proc/cpuid, serial logs...). > > > > > > Is there anything else not captured by ts-logs-capture that would be > > > interesting in order to help debug the issue? > > > > Does the shutdown reliably complete prior to migrate and then only fail > intermittently after a localhost migrate? > > AFAICT yes, but it can also be added to the test in order to be sure. > > > It might be useful to know what cpuid info is seen by the guest before and > after migrate. > > Is there anyway to get that from windows in an automatic way? If not I > could test that with a Debian guest. In fact it might even be a good > thing for Linux based guest to be added to the regular migration tests > in order to make sure cpuid bits don't change across migrations. > I found this for windows: https://www.cpuid.com/downloads/cpu-z/cpu-z_1.81-en.exe It can generate a text or html report as well as being run interactively. But you may get more mileage from using a debian HVM guest. I guess it may also be useful is we can get a scan of available MSRs and content before and after migrate too. > > Another datapoint... does the shutdown fail if you insert a delay of a > > couple > of minutes between the migrate and the shutdown? > > Sometimes, after a variable number of calls to xl shutdown ... the > guest usually ends up shutting down. > Hmm. I wonder whether the guest is actually healthy after the migrate. One could imagine a situation where the storage device model (IDE in our case I guess) gets stuck in some way but recovers after a timeout in the guest storage stack. Thus, if you happen to try shut down while it is still stuck Windows starts trying to shut down but can't. Try after the timeout though and it can. In the past we did make attempts to support Windows without PV drivers in XenServer but xenrt would never reliably pass VM lifecycle tests using emulated devices. That was with qemu trad, but I wonder whether upstream qemu is actually any better particularly if using older device models such as IDE and RTL8139 (which are probably largely unmodified from trad). Paul > Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] xen: Add support for initializing 16550 UART using ACPI
Currently, Xen supports only DT based initialization of 16550 UART.
This patch adds support for initializing 16550 UART using ACPI SPCR table.
Signed-off-by: Bhupinder Thakur
---
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
xen/drivers/char/ns16550.c | 57 +
xen/include/xen/8250-uart.h | 1 +
2 files changed, 58 insertions(+)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index e0f8199..b3f6d85 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1538,6 +1538,63 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
DT_DEVICE_END
#endif /* HAS_DEVICE_TREE */
+
+#ifdef CONFIG_ACPI
+#include
+
+static int __init ns16550_acpi_uart_init(const void *data)
+{
+struct ns16550 *uart;
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **)&spcr);
+
+if ( ACPI_FAILURE(status) )
+{
+printk("ns16550: Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+uart = &ns16550_com[0];
+
+ns16550_init_common(uart);
+
+uart->baud = BAUD_AUTO;
+uart->data_bits = 8;
+uart->parity= spcr->parity;
+uart->stop_bits = spcr->stop_bits;
+uart->io_base = spcr->serial_port.address;
+uart->irq = spcr->interrupt;
+uart->reg_width = spcr->serial_port.bit_width/8;
+uart->reg_shift = 0;
+uart->io_size = UART_MAX_REGinterrupt, spcr->interrupt_type);
+
+uart->vuart.base_addr = uart->io_base;
+uart->vuart.size = uart->io_size;
+uart->vuart.data_off = UART_THR vuart.status_off = UART_LSRvuart.status = UART_LSR_THRE|UART_LSR_TEMT;
+
+/* Register with generic serial driver. */
+serial_register_uart(uart - ns16550_com, &ns16550_driver, uart);
+
+return 0;
+}
+
+ACPI_DEVICE_START(ns16550c, "16550 COMPAT UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_16550_COMPATIBLE,
+.init = ns16550_acpi_uart_init,
+ACPI_DEVICE_END
+ACPI_DEVICE_START(ns16550s, "16550 SUBSET UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_16550_SUBSET,
+.init = ns16550_acpi_uart_init,
+ACPI_DEVICE_END
+
+#endif
/*
* Local variables:
* mode: C
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index 5c3bac3..1b3e137 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -35,6 +35,7 @@
#define UART_USR 0x1f/* Status register (DW) */
#define UART_DLL 0x00/* divisor latch (ls) (DLAB=1) */
#define UART_DLM 0x01/* divisor latch (ms) (DLAB=1) */
+#define UART_MAX_REG (UART_USR+1)
/* Interrupt Enable Register */
#define UART_IER_ERDAI0x01/* rx data recv'd */
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] xen: Fix 16550 UART console for HP Moonshot (Aarch64) platform
The console was not working on HP Moonshot (HPE Proliant Aarch64) because
the UART registers were accessed as 8-bit aligned addresses. However,
registers are 32-bit aligned for HP Moonshot.
Since ACPI/SPCR table does not specify the register shift to be applied to
the
register offset, this patch implements an erratum to correctly set the
register
shift for HP Moonshot.
Similar erratum was implemented in linux:
commit 79a648328d2a604524a30523ca763fbeca0f70e3
Author: Loc Ho
Date: Mon Jul 3 14:33:09 2017 -0700
ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata
APM X-Gene verion 1 and 2 have an 8250 UART with its register
aligned to 32-bit. In addition, the latest released BIOS
encodes the access field as 8-bit access instead 32-bit access.
This causes no console with ACPI boot as the console
will not match X-Gene UART port due to the lack of mmio32
option.
Signed-off-by: Loc Ho
Acked-by: Greg Kroah-Hartman
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Bhupinder Thakur
---
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
xen/drivers/char/ns16550.c | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index b3f6d85..e716aba 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1542,6 +1542,33 @@ DT_DEVICE_END
#ifdef CONFIG_ACPI
#include
+/*
+ * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
+ * register aligned to 32-bit. In addition, the BIOS also encoded the
+ * access width to be 8 bits. This function detects this errata condition.
+ */
+static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
+{
+bool xgene_8250 = false;
+
+if ( tb->interface_type != ACPI_DBG2_16550_COMPATIBLE )
+return false;
+
+if ( memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
+ memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE) )
+return false;
+
+if ( !memcmp(tb->header.oem_table_id, "XGENESPC",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0 )
+xgene_8250 = true;
+
+if ( !memcmp(tb->header.oem_table_id, "ProLiant",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1 )
+xgene_8250 = true;
+
+return xgene_8250;
+}
+
static int __init ns16550_acpi_uart_init(const void *data)
{
struct ns16550 *uart;
@@ -1568,9 +1595,20 @@ static int __init ns16550_acpi_uart_init(const void
*data)
uart->io_base = spcr->serial_port.address;
uart->irq = spcr->interrupt;
uart->reg_width = spcr->serial_port.bit_width/8;
-uart->reg_shift = 0;
-uart->io_size = UART_MAX_REGreg_shift = 2;
+}
+else
+uart->reg_shift = 0;
+
+uart->io_size = UART_MAX_REGinterrupt, spcr->interrupt_type);
uart->vuart.base_addr = uart->io_base;
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 115476: tolerable all pass - PUSHED
flight 115476 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115476/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 115415
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 115415
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 115415
test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check
fail never pass
test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check
fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass
test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass
version targeted for testing:
libvirt 1bf893406637e852daeaafec6617d3ee3716de25
baseline version:
libvirt bc8a99ef06417a2303ccab455f9f045e2a617916
Last test of basis 115415 2017-10-31 04:20:24 Z2 days
Testing same since 115476 2017-11-02 04:22:37 Z0 days1 attempts
People who touched revisions under test:
Jiri Denemark
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-amd64-i386-libvirt-qcow2pass
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, 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=libvirt
+ revision=1bf893406637e852daeaafec6617d3ee3716de25
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.
PERLLIB=.:.
+++ 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 libvirt
1bf893406637e852daeaafec6617d3ee3716de25
+ branch=libvirt
+ revision=1bf893406637e852daeaafec6617d3ee3716de25
+ . ./cri-lock-repos
++ . ./cr
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
On 11/01/2017 05:10 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Oct 24, 2017 at 04:22:38PM +0100, George Dunlap wrote: >> On Fri, Sep 15, 2017 at 3:51 PM, Konrad Rzeszutek Wilk >> wrote: +### Soft-reset for PV guests >>> >>> s/PV/HVM/ >> >> Is it? I thought this was for RHEL 5 PV guests to be able to do crash >> kernels. >> +### Transcendent Memory + +Status: Experimental + +[XXX Add description] >>> >>> Guests with tmem drivers autoballoon memory out allowing a fluid >>> and dynamic memory allocation - in effect memory overcommit without >>> the need to swap. Only works with Linux guests (as it requires >>> OS drivers). >> >> But autoballooning doesn't require any support in Xen, right? I >> thought the TMEM support in Xen was more about the trancendent memory >> backends. > > frontends you mean? That is Linux guests when compiled with XEN_TMEM will > balloon down (using the self-shrinker) to using the normal balloon code > (XENMEM_decrease_reservation, XENMEM_populate_physmap) to make the > guest smaller. Then the Linux code starts hitting the case where it starts > swapping memory out - and that is where the tmem comes in and the > pages are swapped out to the hypervisor. Right -- so TMEM itself actually consists of this ephemeral and non-ephemeral memory pools. Autoballooning is just a trick to get Linux to put the least-used pages into one of the pools. How about this: --- Transcendent Memory (tmem) allows the creation of hypervisor memory pools which guests can use to store memory rather than caching in its own memory or swapping to disk. Having these in the hypervisor can allow more efficient aggregate use of memory across VMs. --- -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Commit moratorium to staging
On 11/01/2017 02:07 PM, Ian Jackson wrote: > So, investigations (mostly by Roger, and also a bit of archaeology in > the osstest db by me) have determined: > > * This bug is 100% reproducible on affected hosts. The repro is > to boot the Windows guest, save/restore it, then migrate it, > then shut down. (This is from an IRL conversation with Roger and > may not be 100% accurate. Roger, please correct me.) I presume when you say 'migrate' you mean localhost migration? Are the results different if you: - only save/restore *or* migrate it? - save/restore twice or migrate twice, rather than save/restore + migrate? Going through the save/restore path suggests that there's something about the domain that's being set up one way on initial creation than on restoring/receiving from a migration: i.e., something not being saved and restored properly. An alternate explanation would be a 'hitch' somewhere in the 're-attach' driver code. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Commit moratorium to staging
Roger Pau Monné writes ("Re: [Xen-devel] Commit moratorium to staging"):
> Is there anyway to get that from windows in an automatic way? If not I
> could test that with a Debian guest. In fact it might even be a good
> thing for Linux based guest to be added to the regular migration tests
> in order to make sure cpuid bits don't change across migrations.
We do migrations of all the guests in osstest (apart from in ARM,
where the guests don't support it, and some special cases like
rumpkernel and xtf domains).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen: Add support for initializing 16550 UART using ACPI
Hi Bhupinder,
Please write a cover letter even if it is small when your send a series
with multiple patches.
On 02/11/17 10:13, Bhupinder Thakur wrote:
Currently, Xen supports only DT based initialization of 16550 UART.
This patch adds support for initializing 16550 UART using ACPI SPCR table.
Signed-off-by: Bhupinder Thakur
---
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
xen/drivers/char/ns16550.c | 57 +
xen/include/xen/8250-uart.h | 1 +
2 files changed, 58 insertions(+)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index e0f8199..b3f6d85 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1538,6 +1538,63 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
DT_DEVICE_END
#endif /* HAS_DEVICE_TREE */
+
+#ifdef CONFIG_ACPI
The code below is going to break x86 build. You need to do #if
defined(CONFIG_ACPI) && defined(CONFIG_ARM)
+#include
+
+static int __init ns16550_acpi_uart_init(const void *data)
+{
+struct ns16550 *uart;
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **)&spcr);
+
+if ( ACPI_FAILURE(status) )
+{
+printk("ns16550: Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+uart = &ns16550_com[0];
+
+ns16550_init_common(uart);
+
+uart->baud = BAUD_AUTO;
+uart->data_bits = 8;
+uart->parity= spcr->parity;
+uart->stop_bits = spcr->stop_bits;
+uart->io_base = spcr->serial_port.address;
+uart->irq = spcr->interrupt;
+uart->reg_width = spcr->serial_port.bit_width/8;
width / 8;
+uart->reg_shift = 0;
+uart->io_size = UART_MAX_REGinterrupt, spcr->interrupt_type);
+
+uart->vuart.base_addr = uart->io_base;
+uart->vuart.size = uart->io_size;
+uart->vuart.data_off = UART_THR vuart.status_off = UART_LSRvuart.status = UART_LSR_THRE|UART_LSR_TEMT;
Ditto.
Also, the code looks very similar to the DT version. Is there any way to
share it?
+
+/* Register with generic serial driver. */
+serial_register_uart(uart - ns16550_com, &ns16550_driver, uart);
+
+return 0;
+}
+
+ACPI_DEVICE_START(ns16550c, "16550 COMPAT UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_16550_COMPATIBLE,
+.init = ns16550_acpi_uart_init,
+ACPI_DEVICE_END
+ACPI_DEVICE_START(ns16550s, "16550 SUBSET UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_16550_SUBSET,
+.init = ns16550_acpi_uart_init,
+ACPI_DEVICE_END
+
+#endif
/*
* Local variables:
* mode: C
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index 5c3bac3..1b3e137 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -35,6 +35,7 @@
#define UART_USR 0x1f/* Status register (DW) */
#define UART_DLL 0x00/* divisor latch (ls) (DLAB=1) */
#define UART_DLM 0x01/* divisor latch (ms) (DLAB=1) */
+#define UART_MAX_REG (UART_USR+1)
/* Interrupt Enable Register */
#define UART_IER_ERDAI0x01/* rx data recv'd */
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: Fix 16550 UART console for HP Moonshot (Aarch64) platform
Hi Bhupinder,
On 02/11/17 10:13, Bhupinder Thakur wrote:
The console was not working on HP Moonshot (HPE Proliant Aarch64) because
the UART registers were accessed as 8-bit aligned addresses. However,
registers are 32-bit aligned for HP Moonshot.
Since ACPI/SPCR table does not specify the register shift to be applied to
the
register offset, this patch implements an erratum to correctly set the
register
shift for HP Moonshot.
Similar erratum was implemented in linux:
Can you remove the tab at the beginning of each of the lines above?
commit 79a648328d2a604524a30523ca763fbeca0f70e3
Author: Loc Ho
Date: Mon Jul 3 14:33:09 2017 -0700
ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata
APM X-Gene verion 1 and 2 have an 8250 UART with its register
aligned to 32-bit. In addition, the latest released BIOS
encodes the access field as 8-bit access instead 32-bit access.
This causes no console with ACPI boot as the console
will not match X-Gene UART port due to the lack of mmio32
option.
Signed-off-by: Loc Ho
Acked-by: Greg Kroah-Hartman
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Bhupinder Thakur
---
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
xen/drivers/char/ns16550.c | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index b3f6d85..e716aba 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1542,6 +1542,33 @@ DT_DEVICE_END
#ifdef CONFIG_ACPI
#include
+/*
+ * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
+ * register aligned to 32-bit. In addition, the BIOS also encoded the
+ * access width to be 8 bits. This function detects this errata condition.
+ */
+static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
+{
+bool xgene_8250 = false;
+
+if ( tb->interface_type != ACPI_DBG2_16550_COMPATIBLE )
+return false;
+
+if ( memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
+ memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE) )
+return false;
+
+if ( !memcmp(tb->header.oem_table_id, "XGENESPC",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0 )
Please align ACPI_OEM_TABLE_ID_SIZE with ( after memcmp.
+xgene_8250 = true;
+
+if ( !memcmp(tb->header.oem_table_id, "ProLiant",
+ ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1 )
Ditto.
+xgene_8250 = true;
+
+return xgene_8250;
+}
+
static int __init ns16550_acpi_uart_init(const void *data)
{
struct ns16550 *uart;
@@ -1568,9 +1595,20 @@ static int __init ns16550_acpi_uart_init(const void
*data)
uart->io_base = spcr->serial_port.address;
uart->irq = spcr->interrupt;
uart->reg_width = spcr->serial_port.bit_width/8;
-uart->reg_shift = 0;
-uart->io_size = UART_MAX_REGreg_shift = 2;
+}
+else
+uart->reg_shift = 0;
+
+uart->io_size = UART_MAX_REGinterrupt, spcr->interrupt_type);
uart->vuart.base_addr = uart->io_base;
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.9 test] 115473: regressions - FAIL
flight 115473 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/115473/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114814 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114814 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114814 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass version targeted for testing: linuxd785062ef20f9b2cd8cedcafea55ca8264f25f3e baseline version: linux5d7a76acad403638f635c918cc63d1d44ffa4065 Last test of basis 114814 2017-10-20 20:51:56 Z 12 days Failing since114845 2017-10-21 16:14:17 Z 11 days 21 attempts Testing same since 115296 2017-10-27 11:07:37 Z6 days 11 attempts People who touched revisions under test: Alan Stern Alex Deucher Alexandre Belloni Andrew Morton Andrey Konovalov Anoob Soman Arend van Spriel Arnd Bergmann Bart Van Assche Ben Hutchings Ben Skeggs Bin Liu Borislav Petkov Brian Foster Carlos Maiolino Christoph Biedl Christoph Hellwig Christoph Lameter Christophe JAILLET Coly Li Dan Carpenter Darrick J. Wong Dave Chinner David Howells David Kozub David Rientjes David S. Miller Dennis Dalessandro Dexuan Cui Dmitry V. Levin Doug Ledford Easwar Hariharan Emmanuel Grumbach Eric Biggers Eric Dumazet Eric Ren Eric Sandeen Eric Sandeen Eric Sesterhenn Eryu Guan Felipe Balbi Filipe Manana Franck Demathieu Greg Kroah-Hartman Greg Kroah-Hartman gre...@
[Xen-devel] [qemu-mainline test] 115480: regressions - FAIL
flight 115480 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/115480/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 114507 build-amd64-xsm 6 xen-buildfail REGR. vs. 114507 build-i386-xsm6 xen-buildfail REGR. vs. 114507 build-amd64 6 xen-buildfail REGR. vs. 114507 build-armhf 6 xen-buildfail REGR. vs. 114507 build-armhf-xsm 6 xen-buildfail REGR. vs. 114507 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qcow2 1 build-check(1) blocked n/a 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 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-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 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-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 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-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 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 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 b
[Xen-devel] [RFC v1] ALSA: xen-front: Add Xen para-virtualized frontend driver
Hi, all! Foreword This RFC is aimed to introduce support of para-virtualized sound frontend driver for Xen [1] and gather opinions from the relevant communities (ALSA, Xen). It implements the protocol from [2] with the following limitations: - mute/unmute is not supported - get/set volume is not supported Volume control is not supported for the reason that most of the use-cases (at the moment) are based on scenarios where unprivileged OS (e.g. Android, AGL etc) uses software mixers. Both capture and playback are supported. The relevant backend is implemented as a user-space application [3] and uses accompanying helper library [4]. Both frontend driver and backend were tested on real HW running Xen hypervisor (Renesas R-Car ARM based H3/M3 boards, x86). Discussion == During the first attempt to upstream the driver [5] number of comments and concerns were raised, one of the biggest flaws in the design were questioned by both Clemens Ladisch [6] and Takashi Sakamoto [7]: the absence of synchronization between frontend and backend during capture/playback. Two options were discussed: “In design of ALSA PCM core, drivers are expected to synchronize to actual hardwares for semi-realtime data transmission. The synchronization is done by two points: 1) Interrupts to respond events from actual hardwares. 2) Positions of actual data transmission in any serial sound interfaces of actual hardwares. “ and finally a change to the existing protocol was suggested: “In 'include/xen/interface/io/sndif.h', there's no functionalities I described the above: 1. notifications from DomU to Dom0 about the size of period for interrupts from actual hardwares. Or no way from Dom0 to DomU about the configured size of the period. 2. notifications of the interrupts from actual hardwares to DomU.” This is implemented as a change to the sndif protocol [8] and allows removing period emulation: 1. Introduced a new event channel from back to front 2. New event with number of bytes played/captured (XENSND_EVT_CUR_POS, to be used for sending snd_pcm_period_elapsed at frontend (in Linux implementation). Sent in bytes, not frames to make the protocol generic and consistent) 3. New request for playback/capture control (XENSND_OP_TRIGGER) with start/pause/stop/resume sub-ops. Along with these changes other comments on the driver were addressed, e.g. split into smaller chunks, moved the driver from misc to xen etc. Hope, this helps to get the full picture of what was discussed and makes it possible to move forward. Waiting for your valuable comments, Thank you, Oleksandr [1] https://github.com/andr2000/linux/commits/snd_upstream_v1 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/sndif.h [3] https://github.com/xen-troops/snd_be [4] https://github.com/xen-troops/libxenbe [5] https://lkml.org/lkml/2017/8/7/363 [6] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123617.html [7] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-August/123744.html [8] https://github.com/andr2000/linux/commit/095d7feae00bf00c852c67c4f1044de5601678ed ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator
Hi Volodymyr, On 24/10/17 20:02, Volodymyr Babchuk wrote: If it is not safe, this means you have a whitelist solution and therefore tie Xen to a specific OP-TEE version. So if you need to use a new function you would need to upgrade Xen making the code of using new version potentially high. Yes, any ABI change between OP-TEE and its clients will require mediator upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, which is known to XEN. Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you impose anyone wanted to modify OP-TEE for their own purpose can make a closed version of the TEE. But if you need to introspect/whitelist call, you impose the vendor to expose their API. Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. If vendor modifies interface between OP-TEE and Linux, they anyways obligued to expose API. Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. My understanding is the OP-TEE will provide a generic way to access different Trusted Application. While OP-TEE API may be generic, the TA API is custom. AFAICT the latter is not part of Linux driver. Yes, you are perfectly right there. So here my questions: 1) Are you planning allow all the guests to access every Trusted Applications? This is a good question. There are two types of TAs supported in OP-TEE: real TAs (as they are described in GlobalPlatform specs) and PseudoTAs. The latter ones are statically linked right into OP-TEE kernel and execute at S-EL1 level. Real TAs are provided by client. That means that NW userspace supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA and then runs it in S-EL0. So, I'm planning to allow client to work with any real TA. I can't see real problem there. Are the real TAs going to be shared between guests? Or will each guest have their own one? No, we don't plan this. At least at this momoent. Every guest will have own instance of TA. Will you allow every guests loading real TAs? Yes, if guest has access to TEE, it can load TA. Either there is no sense to use TEE. OP-TEE core itself does not provide useful services to clients. In a previous e-mail you mentioned OP-TEE has limited memory. How will you ensure that guest A will not use all the memory of OP-TEE and prevent guest B to load TAs? [...] Not really, you could the domain could block when issuing an SMC until the mediator is up and running. Do you mean, that if domain tries to execute SMC, and mediator is not ready, then hypervisor should pause all domain's vCPUs? That can be destructive for hw domain. Xen is free to unschedule any vCPU at any time. So why would it be destructive? [...] And yes, it seems obvious, but I want to say this explicitly: generic TEE mediator framework should and will use XSM to control which domain can work with TEE. So, if you don't trust your guest - don't let it to call TEE at all. Correct me if I am wrong. TEE could be used by Android guest which likely run the user apps... right? So are you saying you fully trust that guest and obviously the user installing rogue app? I don't think that app downloaded from Play Marget can access OP-TEE directly. OP-TEE can be used by Android itself as a key storage or to access to a SE, for example. But 3rd app that issues TEE calls... I don't think so. You didn't get my point here. That rogue app may be able to break into kernel via an exploit or have enough privilege to break the guest. Who knows what it will be able to do after... Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide some safer environment for sensitive data and code. This environment has well-defined interfaces and is desgined to be as safe as possible. If rogue app breaks into kernel, then it can issue any SMC which it wants. But OP-TEE does not trust to NW. Hypervisor does not trust to guests. Mediator should be written in the same way. So, what can do rogue kernel? As I know - it can cause DoS in OP-TEE. This is known issue. If there is a security bug in OP-TEE, it probably can overcome whole system. But this is true for any system running OP-TEE. I agree that if you take over OP-TEE, you will take over any system. This is not specific to hypervisor. Yes. But it just occured to me that mediator+OP-TEE *can* be more secure then just OP-TEE. You see, mediator should perform own security checks before forwarding call to OP-TEE. So if OP-TEE misses something, mediator can back it up. I wouldn't rely on this. It just interesting thought :-) Baremetal OS taking down the platform will only harm itself. A guest OS could harm the whole platform. Can't argument with that. I think that this feature (shared TEE) is not suitable for, say, VPSes. But it can work just fine on smartphones or o
Re: [Xen-devel] [PATCH-tip v2 2/2] x86/xen: Deprecate xen_nopvspin
On 11/01/2017 06:01 PM, Boris Ostrovsky wrote:
> On 11/01/2017 04:58 PM, Waiman Long wrote:
>> +/* TODO: To be removed in a future kernel version */
>> static __init int xen_parse_nopvspin(char *arg)
>> {
>> -xen_pvspin = false;
>> +pr_warn("xen_nopvspin is deprecated, replace it with
>> \"pvlock_type=queued\"!\n");
>> +if (!pv_spinlock_type)
>> +pv_spinlock_type = locktype_queued;
> Since we currently end up using unfair locks and because you are
> deprecating xen_nopvspin I wonder whether it would be better to set this
> to locktype_unfair so that current behavior doesn't change. (Sorry, I
> haven't responded to your earlier message before you posted this). Juergen?
I think the latest patch from Juergen in tip is to use native qspinlock
when xen_nopvspin is specified. Right? That is why I made the current
choice. I can certainly change to unfair if it is what you guys want.
> I am also not sure I agree with making pv_spinlock an enum *and* a
> bitmask at the same time. I understand that it makes checks easier but I
> think not assuming a value or a pattern would be better, especially
> since none of the uses is on a critical path.
>
> (For example, !pv_spinlock_type is the same as locktype_auto, which is
> defined but never used)
OK, I will take out the enum and make explicit use of locktype_auto.
Cheers,
Longman
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Commit moratorium to staging [and 1 more messages]
Julien Grall writes ("Re: Commit moratorium to staging"):
> Thank you for the explanation. I agree with the force push to unblock
> master (and other tree I mentioned).
I will force push all the affected trees, but in a reactive way
because I base each force push on a test report - so it won't be right
away for all of them.
osstest service owner writes ("[xen-unstable test] 115471: regressions - FAIL"):
> flight 115471 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/115471/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs.
> 114644
> test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs.
> 114644
> test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs.
> 114644
The above are justifiable as discussed, leaving no blockers.
> version targeted for testing:
> xen bb2c1a1cc98a22e2d4c14b18421aa7be6c2adf0d
So I have forced pushed that.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH-tip v2 2/2] x86/xen: Deprecate xen_nopvspin
On 02/11/17 14:25, Waiman Long wrote:
> On 11/01/2017 06:01 PM, Boris Ostrovsky wrote:
>> On 11/01/2017 04:58 PM, Waiman Long wrote:
>>> +/* TODO: To be removed in a future kernel version */
>>> static __init int xen_parse_nopvspin(char *arg)
>>> {
>>> - xen_pvspin = false;
>>> + pr_warn("xen_nopvspin is deprecated, replace it with
>>> \"pvlock_type=queued\"!\n");
>>> + if (!pv_spinlock_type)
>>> + pv_spinlock_type = locktype_queued;
>> Since we currently end up using unfair locks and because you are
>> deprecating xen_nopvspin I wonder whether it would be better to set this
>> to locktype_unfair so that current behavior doesn't change. (Sorry, I
>> haven't responded to your earlier message before you posted this). Juergen?
>
> I think the latest patch from Juergen in tip is to use native qspinlock
> when xen_nopvspin is specified. Right? That is why I made the current
> choice. I can certainly change to unfair if it is what you guys want.
No, when we are keeping xen_nopvspin (even as deprecated) it should
behave as designed, so locktype_queued is correct.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Commit moratorium to staging [and 1 more messages]
Hi Ian,
On 02/11/17 13:27, Ian Jackson wrote:
Julien Grall writes ("Re: Commit moratorium to staging"):
Thank you for the explanation. I agree with the force push to unblock
master (and other tree I mentioned).
I will force push all the affected trees, but in a reactive way
because I base each force push on a test report - so it won't be right
away for all of them.
osstest service owner writes ("[xen-unstable test] 115471: regressions - FAIL"):
flight 115471 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115471/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644
The above are justifiable as discussed, leaving no blockers.
version targeted for testing:
xen bb2c1a1cc98a22e2d4c14b18421aa7be6c2adf0d
So I have forced pushed that.
Thank you! With that, the tree is re-opened. I will go through my
backlog of Xen 4.10 and have a look whether they are suitable.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] linux-arm-xen branch, commit access, etc.
Hi, On 23/10/17 22:33, Stefano Stabellini wrote: On Fri, 20 Oct 2017, Julien Grall wrote: Julien, do you think we need to keep a special linux tree around for Xen on ARM testing in OSSTest or we can start using vanilla kernel releases? I would love to get rid of it, if you know of any reasons why we have to keep it, this is the time to speak :-) I think it would be better to keep aroundSome platform may be available before the code is merged. Sure. Ian, let's create a /arm/linux.git tree on xenbits where both Julien and I can push. The idea is that we'll try to use vanilla kernel releases but we'll keep it around just in case we'll need special patches for hardware support in the future. If it turns out that we don't actually need it, we can get rid of it in a year or two. We'll initialize /arm/linux.git based on the current linux-arm-xen branch. /arm/linux.git will replace linux-arm-xen in OSSTest. Sounds good? I don't mind as long as I have access to the arm linux tree. Ian do you have any opinions? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10 v2 0/5] tools/dombuilder: Fixes and improvements to grant handling
Hi, I noticed I forgot to CC Wei and Ian for committing this patch series. On 27/10/17 14:31, Julien Grall wrote: Hi Juergen, On 25/10/17 08:08, Juergen Gross wrote: On 24/10/17 18:06, Julien Grall wrote: Hi, I think this is 4.10 material (particularly patch #5). Juergen, would it be possible get the some feedback on this series? Patch 5: Reviewed-by: Juergen Gross Thank you! For the series: Release-acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10 v2 0/5] tools/dombuilder: Fixes and improvements to grant handling
Actually CC them... On 02/11/17 13:44, Julien Grall wrote: Hi, I noticed I forgot to CC Wei and Ian for committing this patch series. On 27/10/17 14:31, Julien Grall wrote: Hi Juergen, On 25/10/17 08:08, Juergen Gross wrote: On 24/10/17 18:06, Julien Grall wrote: Hi, I think this is 4.10 material (particularly patch #5). Juergen, would it be possible get the some feedback on this series? Patch 5: Reviewed-by: Juergen Gross Thank you! For the series: Release-acked-by: Julien Grall Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
Hi, On 27/10/17 21:16, Stefano Stabellini wrote: On Fri, 27 Oct 2017, Julien Grall wrote: On 27/10/17 08:27, Hao, Xudong wrote: This bug exist much long time, there are many discussion last year but not a solution then. I call out it now because there is a fix in qemu upstream: commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2 Author: Roger Pau Monne Date: Thu Aug 24 16:07:03 2017 +0100 xen/pt: allow QEMU to request MSI unmasking at bind time The fix is not in qemu-xen tree yet, when will qemu-xen sync this fix? Is it possible to catch Xen 4.10's qemu-xen? I will let Stefano and Anthony providing feedback before giving a release-ack here. Yes, I think we should backport the commit as it fixes a genuine bug. The backport is not risk-free but it only affects PCI Passthrough. Also the commit has been in QEMU for 2 months now. Does anyone actually tested it with QEMU Xen tree? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 4/5] xentrace: enable per-VCPU extratime flag for RTDS
Hi George, On Wed, Oct 25, 2017 at 10:31 AM, Wei Liu wrote: > > On Mon, Oct 23, 2017 at 02:50:31PM -0400, Meng Xu wrote: > > On Tue, Oct 17, 2017 at 4:10 AM, Dario Faggioli wrote: > > > On Wed, 2017-10-11 at 14:02 -0400, Meng Xu wrote: > > >> Change repl_budget event output for xentrace formats and xenalyze > > >> > > >> Signed-off-by: Meng Xu > > >> > > > I'd say: > > > > > > Reviewed-by: Dario Faggioli > > > > Hi guys, > > > > Just a reminder, we may need this patch for the work-conserving RTDS > > scheduler in Xen 4.10. > > > > I say Julien sent out the rc2 today which does not include this patch. > > > > Thanks and best regards, > > > > I'm waiting for George's ack. Just a friendly reminder: Do you have any comment on this patch? Thanks, Meng ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] tools/hotplug: create XEN_LOG_DIR at runtime
On 30/10/17 14:39, Ian Jackson wrote:
Wei Liu writes ("Re: [PATCH] tools/hotplug: create XEN_LOG_DIR at runtime"):
On Fri, Oct 27, 2017 at 07:52:37PM +0300, Andrii Anisov wrote:
From: Andrii Anisov
/var/log could be a tmpfs mount point, so create xen subfolder at runtime.
Signed-off-by: Andrii Anisov
Reviewed-by: Volodymyr Babchuk
Reviewed-by: Oleksandr Andrushchenko
Acked-by: Wei Liu
Julien I think we should apply this for 4.10.
I agree. Subject line tag added.
Acked-by: Ian Jackson
Release-acked-by: Julien Grall
Cheers,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] common/spinlock: Improve the output from check_lock() if it trips
Hi Andrew,
On 31/10/17 10:49, Andrew Cooper wrote:
If check_lock() triggers, a crash will occur. Instead of simply identifying
"the irq context was different", indicate the expected and current irq
context.
Signed-off-by: Andrew Cooper
Release-acked-by: Julien Grall
Cheers,
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
check_lock() only exists in debug builds, which makes this a low risk change
for 4.10.
---
xen/common/spinlock.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 44b07b7..8f2ba08 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -44,7 +44,13 @@ static void check_lock(struct lock_debug *debug)
if ( unlikely(debug->irq_safe != irq_safe) )
{
int seen = cmpxchg(&debug->irq_safe, -1, irq_safe);
-BUG_ON(seen == !irq_safe);
+
+if ( seen == !irq_safe )
+{
+printk("CHECKLOCK FAILURE: prev irqsafe: %d, curr irqsafe %d\n",
+ seen, irq_safe);
+BUG();
+}
}
}
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.10.0 RC1 test result
Hi, On 30/10/17 02:21, Hao, Xudong wrote: -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Friday, October 27, 2017 5:19 PM To: Hao, Xudong Cc: Julien Grall ; Lars Kurth ; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen 4.10.0 RC1 test result On 27.10.17 at 10:28, wrote: RAS: [BUG] xen-mceinj tool testing cause dom0 crash https://www.mail-archive.com/xen-devel@lists.xen.org/msg108671.html Please can you provide helpful links? This doesn't point to the beginning of the thread, and the mail archive chosen doesn't appear to have an easy way to go back to the head of a thread. And when I go through the parts of the thread Unfortunately I didn't find the original link from mail-archive, but I pick up it in my mail client, attach the original mail. which are easily accessible there, it looks like you've never followed up on the additional information (log) request. I've provided the full log which included Xen and Dom0's, even though there was no valid error message from Dom0. This way I don't see how we can make progress there. Yes, this is the end mail https://www.mail-archive.com/xen-devel@lists.xen.org/msg108894.html. Plus, looking over the Cc lists there, Linux maintainers also don't appear to have been involved at any time. I'm not sure if it's related with Dom0's kernel. My intention is we could discuss in Xen list only till we make sure it's Dom0's issue. At the moment the discussion seem to be stuck on Xen list... Jan mentioned that for now he is not convinced it is a Xen bug. How about you CC Linux maintainers to get more feedback? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.10] common/multicall: Increase debugability for bad hypercalls
Hi Andrew,
On 31/10/17 17:18, Andrew Cooper wrote:
While investigating an issue (in a new codepath I'd introduced, as it turns
out), leaving interrupts disabled manifested as a subsequent op in the
multicall failing a check_lock() test.
The codepath would have hit the ASSERT_NOT_IN_ATOMIC on the return-to-guest
path, had it not hit the check_lock() first.
Call ASSERT_NOT_IN_ATOMIC() after each operation in the multicall, to make
failures more obvious.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
As with the related check_lock() patch, this only affects debug builds, so is
a very low risk change for 4.10
Release-acked-by: Julien Grall
With a couple of typos below.
---
xen/common/multicall.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index c7af4e0..d98e59d 100644
--- a/xen/common/multicall.c
+++ b/xen/common/multicall.c
@@ -66,6 +66,13 @@ do_multicall(
disp = arch_do_multicall_call(mcs);
+/*
+ * In the unlikley event that a hypercall has left interrupts,
s/unlikley/unlikely/
+ * spinlocks, or other things in a bad way, continuting the multicall
s/continuting/continuing/
+ * will typically lead to far more subtle issues to debug.
+ */
+ASSERT_NOT_IN_ATOMIC();
+
#ifndef NDEBUG
{
/*
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] USB Passthrough: Incorrect device detected in Domain U
On 02/11/17 08:37, Rakesh Awanti wrote: >>> Hello, >>> >>> I'm trying USB passthrough on x86 and ARM platforms. I've taken the USB >>> frontend and backend code from > >>So from where? > > > https://lists.xen.org/archives/html/xen-devel/2015-02/msg03245.html The backend driver was discarded as its funcionality has been put into qemu. In case you want to continue using the kernel based variant you are basically on your own. The most recent frontend driver is available from https://lists.xen.org/archives/html/xen-devel/2015-06/msg03436.html Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 115475: regressions - FAIL
flight 115475 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/115475/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair18 guests-nbd-mirror/debian fail REGR. vs. 114682 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114682 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 114682 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114682 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114682 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 114682 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114682 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114682 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 114682 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass version targeted for testing: linux3a99df9a3d14cd866b5516f8cba515a3bfd554ab baseline version: linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb Last test of basis 114682 2017-10-18 09:54:11 Z 15 days Failing since114781 2017-10-20 01:00:47 Z 13 days 23 attempts Testing same since 115475 2017-11-02 04:08:22 Z0 days1 attempts 441 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops
Re: [Xen-devel] [PATCH for-4.10] gdbsx: prefer privcmd character device
Hi Wei, On 01/11/17 10:20, Wei Liu wrote: Cc Julien and change tag. I think this is safe to be applied to 4.10. I agree. Release-acked-by: Julien Grall Cheers, On Tue, Oct 31, 2017 at 01:58:07PM -0700, Elena Ufimtseva wrote: On Tue, Oct 31, 2017 at 03:25:39PM +, Wei Liu wrote: On Tue, Oct 31, 2017 at 10:20:11AM -0500, Doug Goldstein wrote: Prefer using the character device over the proc file if the character device exists. CC: Elena Ufimtseva CC: Ian Jackson CC: Stefano Stabellini CC: Wei Liu Signed-off-by: Doug Goldstein --- So this was originally submitted with 9c89dc95201 and 7d418eab3b6 and was rejected since the goal was to convert gdbsx to use libxc but that hasn't happened. /dev/xen/privcmd should be preferred and this change makes that happen. It would be nice if we landed this with the plan to convert gdbsx happening when it happens. Oh well... I think this is fine. Elena has the final verdict. I think this is fine. I will look into the conversion and relevant discussions if I find them and see what can be done. Thanks! Meanwhile, Reviewed-by: Elena Ufimtseva Elena -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 for-next 3/4] xen/tmem: Convert the file common/tmem_xen.c to use typesafe MFN
Hi Konrad, On 01/11/17 18:54, Konrad Rzeszutek Wilk wrote: On Wed, Nov 01, 2017 at 02:03:15PM +, Julien Grall wrote: The file common/tmem_xen.c is now converted to use typesafe. This is requiring to override the macro page_to_mfn to make it work with mfn_t. Note that all variables converted to mfn_t havem there initial value, when set, switch from 0 to INVALID_MFN. This is fine because the initial values was always overriden before used. Also add a couple of missing newlines suggested by Andrew in the code. Signed-off-by: Julien Grall Reviewed-by: Andrew Cooper --- Cc: Konrad Rzeszutek Wilk Acked-by: Konrad Rzeszutek Wilk But could you confirm that you did compile this on x86 and with CONFIG_TMEM=y in the .config? Yes, I have CONFIG_TMEM enabled in .config. Thank you for the ack, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
On Thu, Nov 02, 2017 at 10:46:20AM +, George Dunlap wrote: > On 11/01/2017 05:10 PM, Konrad Rzeszutek Wilk wrote: > > On Tue, Oct 24, 2017 at 04:22:38PM +0100, George Dunlap wrote: > >> On Fri, Sep 15, 2017 at 3:51 PM, Konrad Rzeszutek Wilk > >> wrote: > +### Soft-reset for PV guests > >>> > >>> s/PV/HVM/ > >> > >> Is it? I thought this was for RHEL 5 PV guests to be able to do crash > >> kernels. > >> > +### Transcendent Memory > + > +Status: Experimental > + > +[XXX Add description] > >>> > >>> Guests with tmem drivers autoballoon memory out allowing a fluid > >>> and dynamic memory allocation - in effect memory overcommit without > >>> the need to swap. Only works with Linux guests (as it requires > >>> OS drivers). > >> > >> But autoballooning doesn't require any support in Xen, right? I > >> thought the TMEM support in Xen was more about the trancendent memory > >> backends. > > > > frontends you mean? That is Linux guests when compiled with XEN_TMEM will > > balloon down (using the self-shrinker) to using the normal balloon code > > (XENMEM_decrease_reservation, XENMEM_populate_physmap) to make the > > guest smaller. Then the Linux code starts hitting the case where it starts > > swapping memory out - and that is where the tmem comes in and the > > pages are swapped out to the hypervisor. > > Right -- so TMEM itself actually consists of this ephemeral and > non-ephemeral memory pools. Autoballooning is just a trick to get Linux > to put the least-used pages into one of the pools. > > How about this: > > --- > Transcendent Memory (tmem) allows the creation of hypervisor memory > pools which guests can use to store memory rather than caching in its > own memory or swapping to disk. Having these in the hypervisor can > allow more efficient aggregate use of memory across VMs. > --- Perfect! > > -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document
Hi, On 01/11/17 21:54, Stefano Stabellini wrote: > On Wed, 1 Nov 2017, Andre Przywara wrote: >> Hi Stefano, >> >> >> On 01/11/17 01:58, Stefano Stabellini wrote: >>> On Wed, 11 Oct 2017, Andre Przywara wrote: >> >> many thanks for going through all of this! > > No problems, and thanks for your work and for caring about doing the > best thing for the project. > > (CC:ing some KVM/ARM folks involved in the VGIC) starting with the addition of the ITS support we were seeing more and more issues with the current implementation of our ARM Generic Interrupt Controller (GIC) emulation, the VGIC. Among other approaches to fix those issues it was proposed to copy the VGIC emulation used in KVM. This one was suffering from very similar issues, and a clean design from scratch lead to a very robust and capable re-implementation. Interestingly this implementation is fairly self-contained, so it seems feasible to copy it. Hopefully we only need minor adjustments, possibly we can even copy it verbatim with some additional glue layer code. Stefano asked for getting a design overview, to assess the feasibility of copying the KVM code without reviewing tons of code in the first place. So to follow Xen rules for new features, this design document below is an attempt to describe the current KVM VGIC design - in a hypervisor agnostic session. It is a bit of a retro-fit design description, as it is not strictly forward-looking only, but actually describing the existing implemenation [1]. Please have a look and let me know: 1) if this document has the right scope 2) if this document has the right level of detail 3) if there are points missing from the document 3) if the design in general is a fit >>> >>> Please read the following statements as genuine questions and concerns. >>> Most ideas on this document are good. Some of them I have even suggested >>> them myself in the context of GIC improvements for Xen. I asked for a >>> couple of clarifications. >>> >>> But I don't see why we cannot implement these ideas on top of the >>> existing code, rather than with a separate codebase, ending up with two >>> drivers. I would prefer a natual evolution. Specifically, the following >>> improvements would be simple and would give us most of the benefits on >>> top of the current codebase: >>> - adding the irq lock, and the refcount >>> - taking both vcpu locks when necessary (on migration code for example >>> it would help a lot), the lower vcpu_id first >>> - level irq emulation >> >> I think some of those points you mentioned are not easily implemented in >> the current Xen. For instance I ran into locking order issues with those >> *two* inflight and lr_queue lists, when trying to implement the lock and >> the refcount. >> Also this "put vIRQs into LRs early, but possibly rip them out again" is >> really complicating things a lot. >> >> I believe only level IRQs could be added in a relatively straight >> forward manner. >> >> So the problem with the evolutionary approach is that it generates a lot >> of patches, some of them quite invasive, others creating hard-to-read >> diffs, which are both hard to review. >> And chances are that the actual result would be pretty close to the KVM >> code. To be clear: I hacked the Xen VGIC into the KVM direction in a few >> days some months ago, but it took me *weeks* to make sane patches of >> only the first part of it. >> And this would not cover all those general, tedious corner cases that >> the VGIC comes with. Those would need to be fixed in a painful process, >> which we could avoid by "lifting" the KVM code. > > I hear you, but the principal cost here is the review time, not the > development time. Julien told me that it would be pretty much the same > for him in terms of time it takes to review the changes, it doesn't > matter if it's a new driver or changes to the existing driver. For me, > it wouldn't be the same: I think it would take me far less time to > review them if they were against the existing codebase. I am not so sure about this. The changes are quite dramatic, and those changes tend to produce horrible diffs. Or we try to mitigate this, but this comes at a cost of having *many* patches, which take a while to produce. But if we instantiate a new VGIC implementation from scratch, we can provide very nice-to-review patches, because the patches can focus on logical changes and don't need to care about bisectability. > However, as I wrote, this is not my foremost concern. I would be up to > committing myself to review this even if we decide to go for a new > driver. > > >>> If we do end up with a second separate driver for technical or process >>> reasons, I would expect the regular Xen submission/review process to be >>> followed. The code style will be different, the hooks into the rest of >>> the hypervisors will be different and thing
Re: [Xen-devel] [PATCH for-4.10 v2 3/5] tools/dombuilder: Switch to using gfn terminology for console and xenstore rings
On Thu, Oct 12, 2017 at 08:19:07PM +0100, Andrew Cooper wrote:
> The sole use of xc_dom_translated() and xc_dom_p2m() outside of the domain
> builder is for libxl_dom() to translate the console and xenstore pfns back
> into useful values. PV guest pfns are only interesting to the domain builder,
> and gfns are the address space used by all other hypercalls.
>
> Renaming the fields in xc_dom_image is deliberate, as it will cause
> out-of-tree users of the dombuilder to notice the different semantics.
>
> Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), which are all
> using gfns despite the existing variable names.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Roger Pau Monné
> Acked-by: Wei Liu
> Tested-by: Julien Grall
> ---
> CC: Ian Jackson
> CC: Julien Grall
>
> v2:
> * More style fixes
> ---
> tools/libxc/include/xc_dom.h | 10 +++--
> tools/libxc/xc_dom_arm.c | 12 +--
> tools/libxc/xc_dom_boot.c | 45
> ++-
> tools/libxc/xc_dom_compat_linux.c | 4 ++--
> tools/libxc/xc_dom_x86.c | 45
> ---
> tools/libxl/libxl_dom.c | 11 +++---
> 6 files changed, 63 insertions(+), 64 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index cdcdd07..5907559 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -94,8 +94,6 @@ struct xc_dom_image {
> struct xc_dom_seg devicetree_seg;
> struct xc_dom_seg start_info_seg; /* HVMlite only */
> xen_pfn_t start_info_pfn;
> -xen_pfn_t console_pfn;
> -xen_pfn_t xenstore_pfn;
> xen_pfn_t shared_info_pfn;
> xen_pfn_t bootstack_pfn;
> xen_pfn_t pfn_alloc_end;
> @@ -103,6 +101,14 @@ struct xc_dom_image {
> xen_vaddr_t bsd_symtab_start;
>
> /*
> + * Details for the toolstack-prepared rings.
> + *
> + * *_gfn fields are allocated by the domain builder.
> + */
> +xen_pfn_t console_gfn;
> +xen_pfn_t xenstore_gfn;
> +
> +/*
Stubdom build is broken by this change:
mini-os.c:756:23: note: in expansion of macro ‘BOOTSEC_LOCATION’
mbi.drives_addr = BOOTSEC_LOCATION + (60 * 1024);
^~~~
gcc -mno-red-zone -O1 -fno-omit-frame-pointer -O1 -fno-omit-frame-pointer -m64
-mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64
-DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable
-Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions -fno-builtin
-Wall -Werror -Wredundant-decls -Wno-for
mat -Wno-redundant-decls -Wformat -fno-stack-protector -fgnu89-inline
-Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline -g
-D__INSIDE_MINIOS__ -m64 -mno-red-zone -fno-reorder-blocks -fno-
asynchronous-unwind-tables -DCONFIG_PARAVIRT -DCONFIG_SPARSE_BSS
-DCONFIG_BLKFRONT -DCONFIG_TPMFRONT -DCONFIG_TPM_TIS -DCONFIG_TPMBACK
-DCONFIG_XENBUS -D__XEN_INTERFACE_VERSION__=0x00030205 -isystem
/local/work/COMMITTER/xen.git/stubdom/../extras/mini-os/include -D__MINIOS__
-DHAVE_LIBC -isystem
/local/work/COMMITTER/xen.git/stubdom/../extras/mini-os/include/posix -isystem
/local/work/COMMITTER/
xen.git/stubdom/../tools/xenstore/include -isystem
/local/work/COMMITTER/xen.git/stubdom/../extras/mini-os/include/x86 -isystem
/local/work/COMMITTER/xen.git/stubdom/../extras/mini-os/include/x86/x8
6_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem
/local/work/COMMITTER/xen.git/stubdom/../extras/mini-os/include/posix -isystem
/local/work/COMMITTER/xen.git/stubdom/cross-root-x86_64/x
86_64-xen-elf/include -isystem /usr/lib/gcc/x86_64-linux-gnu/6/include -isystem
/local/work/COMMITTER/xen.git/stubdom/lwip-x86_64/src/include -isystem
/local/work/COMMITTER/xen.git/stubdom/lwip-x86_6
4/src/include/ipv4 -I/local/work/COMMITTER/xen.git/stubdom/include
-I/local/work/COMMITTER/xen.git/stubdom/../xen/include -isystem
/local/work/COMMITTER/xen.git/stubdom/../extras/mini-os/include -D__
MINIOS__ -DHAVE_LIBC -isystem
/local/work/COMMITTER/xen.git/stubdom/../extras/mini-os/include/posix -isystem
/local/work/COMMITTER/xen.git/stubdom/../tools/xenstore/include -isystem
/local/work/COMM
ITTER/xen.git/stubdom/../extras/mini-os/include/x86 -isystem
/local/work/COMMITTER/xen.git/stubdom/../extras/mini-os/include/x86/x86_64 -c
gntmap.c -o /local/work/COMMITTER/xen.git/stubdom/mini-os-x8
6_64-vtpmmgr/gntmap.o
In file included from
/local/work/COMMITTER/xen.git/stubdom/include/xen/xen.h:30:0,
from
/local/work/COMMITTER/xen.git/stubdom/grub/../../tools/libxc/include/xenctrl.h:35,
from kexec.c:22:
/local/work/COMMITTER/xen.git/stubdom/include/xen/xen-compat.h:34:0: warning:
"__XEN_INTERFACE_VERSION__" redefined
#define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__
:0:0: note: this is the location of the previous def
Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator
On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote: Hi Julien, > On 24/10/17 20:02, Volodymyr Babchuk wrote: > >>If it is not safe, this means you have a whitelist solution and > >>therefore > >>tie Xen to a specific OP-TEE version. So if you need to use a new > >>function > >>you would need to upgrade Xen making the code of using new version > >>potentially high. > >Yes, any ABI change between OP-TEE and its clients will require mediator > >upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll > >install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, > >which is known to XEN. > > > >>Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you > >>impose anyone wanted to modify OP-TEE for their own purpose can make a > >>closed version of the TEE. But if you need to introspect/whitelist > >>call, you > >>impose the vendor to expose their API. > >Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL > >v2. > >If vendor modifies interface between OP-TEE and Linux, they anyways > >obligued > >to expose API. > > Pardon me for potential stupid questions, my knowledge of OP-TEE is > limited. > > My understanding is the OP-TEE will provide a generic way to access > different Trusted Application. While OP-TEE API may be generic, the TA API > is custom. AFAICT the latter is not part of Linux driver. > >>>Yes, you are perfectly right there. > >>> > So here my questions: > 1) Are you planning allow all the guests to access every Trusted > Applications? > >>>This is a good question. There are two types of TAs supported in > >>>OP-TEE: real TAs (as they are described in GlobalPlatform specs) and > >>>PseudoTAs. The latter ones are statically linked right into OP-TEE > >>>kernel and execute at S-EL1 level. > >>>Real TAs are provided by client. That means that NW userspace > >>>supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA > >>>and then runs it in S-EL0. > >>>So, I'm planning to allow client to work with any real TA. I can't see > >>>real problem there. > >> > >>Are the real TAs going to be shared between guests? Or will each guest have > >>their own one? > >No, we don't plan this. At least at this momoent. Every guest will have > >own instance of TA. > > > >>Will you allow every guests loading real TAs? > >Yes, if guest has access to TEE, it can load TA. Either there is no > >sense to use TEE. OP-TEE core itself does not provide useful services > >to clients. > > In a previous e-mail you mentioned OP-TEE has limited memory. How will you > ensure that guest A will not use all the memory of OP-TEE and prevent guest > B to load TAs? There are no way to do this right now. Even on bare-metal system, one client call load huge TA or eat up memory in another way to prevent other clients to use OP-TEE. This is known limitation. It can be mitigated by enforcing quotas. > [...] > > >>Not really, you could the domain could block when issuing an SMC until the > >>mediator is up and running. > >Do you mean, that if domain tries to execute SMC, and mediator is not > >ready, then hypervisor should pause all domain's vCPUs? That can be > >destructive for hw domain. > > Xen is free to unschedule any vCPU at any time. So why would it be > destructive? Suppose that mediator domain needs 0.5s to boot up and be ready to serve calls. For half of a second HW domain will be blocked. I don't like the idea, that it will not be able to serve IRQs and other requests. IMHO, it is okay for DomU, but not for Dom0. > >>>And yes, it seems obvious, but I want to say this explicitly: generic > >>>TEE mediator framework should and will use XSM to control which domain > >>>can work with TEE. So, if you don't trust your guest - don't let it > >>>to call TEE at all. > >> > >>Correct me if I am wrong. TEE could be used by Android guest which > >>likely > >>run the user apps... right? So are you saying you fully trust that > >>guest and > >>obviously the user installing rogue app? > >I don't think that app downloaded from Play Marget can access OP-TEE > >directly. > >OP-TEE can be used by Android itself as a key storage or to access to a > >SE, > >for example. But 3rd app that issues TEE calls... I don't think so. > > You didn't get my point here. That rogue app may be able to break into > kernel via an exploit or have enough privilege to break the guest. Who > knows > what it will be able to do after... > >>>Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not > >>>designed > >>>to rule the machine. There is ARM TF for that :) OP-TEE's task is to > >>>provide > >>>some safer environment for sensitive data and code. This environment has > >>>well-defined interfaces and is desgined to be as safe as possible. > >>> > >>
Re: [Xen-devel] pci-passthrough loses msi-x interrupts ability after domain destroy
Hi, On Fri, Sep 22, 2017 at 03:25:00PM -0400, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 22, 2017 at 09:35:40AM +0200, Sander Eikelenboom wrote: > > On 22/09/17 04:09, Christopher Clark wrote: > > > On Thu, Sep 21, 2017 at 1:27 PM, Sander Eikelenboom > > > wrote: > > >> > > >> On Thu, September 21, 2017, 10:39:52 AM, Roger Pau Monné wrote: > > >> > > >>> On Wed, Sep 20, 2017 at 03:50:35PM -0400, Jérôme Oufella wrote: > > > > I'm using PCI pass-through to map a PCIe (intel i210) controller into > > a HVM domain. The system uses xen-pciback to hide the appropriate PCI > > device from Dom0. > > > > When creating the HVM domain after an hypervisor cold boot, the HVM > > domain can access and use the PCIe controller without problem. > > > > However, if the HVM domain is destroyed then restarted, it won't be > > able to use the pass-through PCI device anymore. The PCI device is > > seen and can be mapped, however, the interrupts will not be passed to > > the HVM domain anymore (this is visible under a Linux guest as > > /proc/interrupts counters remain 0). The behavior on a Windows10 guest > > is the same. > > > > A few interesting hints I noticed: > > > > - On Dom0, 'lspci -vv' on that PCIe device between the "working" and > > the "muted interrupts" states, I noted a difference between the > > MSI-X caps: > > > > - Capabilities: [70] MSI-X: Enable- Count=5 Masked- <-- IRQs will work > > if domain started > > + Capabilities: [70] MSI-X: Enable- Count=5 Masked+ <-- IRQs won't > > work if domain started > > ^^^ > > >> > > >>> IMHO it seems that either your device is not able to perform a reset > > >>> successfully, or Linux is not correctly performing such reset. I don't > > >>> think there's a lot that can be done from the Xen side. > > >> > > >> Unfortunately for a lot of pci-devices a simple reset as performed by > > >> default isn't enough, > > >> but also almost none support a real pci FLR. > > >> > > >> In the distant past Konrad has made a patchset that implemented a bus > > >> reset and > > >> reseting config space. (It piggy backed on already existing libxl > > >> mechanism of > > >> trying to call on a syfs "do_flr" attribute which triggers pciback to > > >> perform > > >> the busreset and rewrite of config space for the device. > > >> > > >> I use that patchset ever since for my pci-passtrough needs and it works > > >> pretty > > >> well. I can shutdown an restart VM's with pci devices passed trhough > > >> (also AMD > > >> Radeon graphic cards). > > > > > > Just to confirm the utility of that piece of work: OpenXT also uses an > > > extended version of that same patch to perform device reset for > > > passthrough. > > > > > > I've attached a copy of that OpenXT patch to this message and it can > > > also be obtained from our git repository: > > > https://github.com/OpenXT/xenclient-oe/blob/f8d3b282a87231d9ae717b13d506e8e7e28c78c4/recipes-kernel/linux/4.9/patches/thorough-reset-interface-to-pciback-s-sysfs.patch > > > This version creates a sysfs node named "reset_device" and the OpenXT > > > libxl toolstack is patched to use that node instead of "do_flr". > > > > Nice to hear there are more users of this patch. On #xen on IRC there were > > from time to time > > also users who tried pci-passtrough and ran into this issue (and probably > > abandonning the idea > > since having to restart your host before being able to use your pass > > throughed device again > > defies much of the use case). > > > > > Konrad's original work encountered pushback on upstream acceptance at > > > the time it was developed. I'm not sure I've found where that > > > discussion ended. Is there any prospect of a more comprehensive reset > > > mechanism being accepted into xen-pciback, or elsewhere in the kernel? > > > > Yeah it was nacked by David Vrabel and the discussion somewhat bleeded to > > death. > > >From what i remember the main issue was with the naming, since it doesn't > > >do a FLR, > > the sysfs hook shouldn't be called "do_flr". > > > > Some other perhaps minor issues i can think of are: > > - No way to excempt pci-devices from this new way of resetting them. > > Perhaps there could be pci devices/topologies were this way of > > resetting causes more problems than it solves and could cause a > > regression. Unfortunately auto detecting what works doesn't seem to > > be possible. On the other hand (though only with my n=10) i haven't > > encountered > > such a device yet. > > > > - The communication path between libxl and the kernel via sysfs. > > I think the preference was for a: > > a) having it use a more common used Xen communication channel or > > b) having it all self-contained in pci-back. (from my memory and the > > openxt patch description > > there could be some locking issue when try
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Thu, Aug 24, 2017 at 09:23:16AM +0100, Roger Pau Monné wrote: > On Wed, Aug 23, 2017 at 07:13:00PM +0200, Andreas Kinzler wrote: > > > > > From a brief look it looks like this would be doable, but the way > > > > these flags are being communicated is rather ugly (the values used > > > > here > > > > > aren't part of the public interface, and hence it wasn't immediately > > > > > clear whether using one of the unused bits would be an option, but > > > > > it looks like it is). > > > > Yes, it's not pretty... Last used bit is 15, hence bit 16 could be > > > > used to signal to Xen whether the interrupt should be unmasked after > > > > binding. I have a half-drafted patch, will finish it now. > > > Andreas, could you please give a try to the attached two patches? One > > > is for Xen and the other one is for QEMU. > > > > Seems to work after I fixed a bug ;-) > > > > -gflags |= masked ? 0 : XEN_PT_GFLAGSSHIFT_UNMASKED; > > +gflags |= masked ? 0 : (1 << XEN_PT_GFLAGSSHIFT_UNMASKED); > > > > Please let Jan and/or others review the patches. > > Thanks. I would like to add your tested-by if possible, since I'm not > able to trigger this behavior myself. > Hmm.. did these patches get merged / acked? Thanks, -- Pasi > Roger. > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Thu, Nov 02, 2017 at 07:02:49PM +0200, Pasi Kärkkäinen wrote: > On Thu, Aug 24, 2017 at 09:23:16AM +0100, Roger Pau Monné wrote: > > On Wed, Aug 23, 2017 at 07:13:00PM +0200, Andreas Kinzler wrote: > > > > > > From a brief look it looks like this would be doable, but the way > > > > > these flags are being communicated is rather ugly (the values used > > > > > here > > > > > > aren't part of the public interface, and hence it wasn't immediately > > > > > > clear whether using one of the unused bits would be an option, but > > > > > > it looks like it is). > > > > > Yes, it's not pretty... Last used bit is 15, hence bit 16 could be > > > > > used to signal to Xen whether the interrupt should be unmasked after > > > > > binding. I have a half-drafted patch, will finish it now. > > > > Andreas, could you please give a try to the attached two patches? One > > > > is for Xen and the other one is for QEMU. > > > > > > Seems to work after I fixed a bug ;-) > > > > > > -gflags |= masked ? 0 : XEN_PT_GFLAGSSHIFT_UNMASKED; > > > +gflags |= masked ? 0 : (1 << XEN_PT_GFLAGSSHIFT_UNMASKED); > > > > > > Please let Jan and/or others review the patches. > > > > Thanks. I would like to add your tested-by if possible, since I'm not > > able to trigger this behavior myself. > > > > Hmm.. did these patches get merged / acked? Yes, both the QEMU and the Xen sides have been merged. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1
On Thu, Nov 02, 2017 at 05:11:17PM +, Roger Pau Monné wrote: > On Thu, Nov 02, 2017 at 07:02:49PM +0200, Pasi Kärkkäinen wrote: > > On Thu, Aug 24, 2017 at 09:23:16AM +0100, Roger Pau Monné wrote: > > > On Wed, Aug 23, 2017 at 07:13:00PM +0200, Andreas Kinzler wrote: > > > > > > > From a brief look it looks like this would be doable, but the way > > > > > > these flags are being communicated is rather ugly (the values used > > > > > > here > > > > > > > aren't part of the public interface, and hence it wasn't > > > > > > > immediately > > > > > > > clear whether using one of the unused bits would be an option, but > > > > > > > it looks like it is). > > > > > > Yes, it's not pretty... Last used bit is 15, hence bit 16 could be > > > > > > used to signal to Xen whether the interrupt should be unmasked after > > > > > > binding. I have a half-drafted patch, will finish it now. > > > > > Andreas, could you please give a try to the attached two patches? One > > > > > is for Xen and the other one is for QEMU. > > > > > > > > Seems to work after I fixed a bug ;-) > > > > > > > > -gflags |= masked ? 0 : XEN_PT_GFLAGSSHIFT_UNMASKED; > > > > +gflags |= masked ? 0 : (1 << XEN_PT_GFLAGSSHIFT_UNMASKED); > > > > > > > > Please let Jan and/or others review the patches. > > > > > > Thanks. I would like to add your tested-by if possible, since I'm not > > > able to trigger this behavior myself. > > > > > > > Hmm.. did these patches get merged / acked? > > Yes, both the QEMU and the Xen sides have been merged. > Great, thanks a lot! > Roger. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events
New tigervnc changes the way to send long pressed key,
from "down up down up ..." to "down down ... up", it only
affects xen pv console mode. I send a patch to latest
kernel side, but it may have a fix in qemu backend for
back compatible becase guest VMs may use very old kernel.
This patch inserts an up event after each regular key down
event to simulate an auto-repeat key event for xen keyboard
frontend driver.
Signed-off-by: Liang Yan
---
v2:
- exclude extended key
- change log comment
hw/display/xenfb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 8e2547ac05..1bc5b41ab7 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -292,6 +292,11 @@ static void xenfb_key_event(void *opaque, int scancode)
}
trace_xenfb_key_event(opaque, scancode2linux[scancode], down);
xenfb_send_key(xenfb, down, scancode2linux[scancode]);
+
+/* insert an up event for regular down key event */
+if (down && !xenfb->extended) {
+xenfb_send_key(xenfb, 0, scancode2linux[scancode]);
+}
}
/*
--
2.14.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1] x86/vvmx: don't enable vmcs shadowing for nested guests
On 02/11/17 04:35, Tian, Kevin wrote: >> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] >> Sent: Monday, October 23, 2017 5:33 PM >> >> Running "./xtf_runner vvmx" in L1 Xen under L0 Xen produces the >> following result on H/W with VMCS shadowing: >> >> Test: vmxon >> Failure in test_vmxon_in_root_cpl0() >> Expected 0x820f: VMfailValid(15) VMXON_IN_ROOT >>Got 0x82004400: VMfailValid(17408) >> Test result: FAILURE >> >> This happens because SDM allows vmentries with enabled VMCS >> shadowing >> VM-execution control and VMCS link pointer value of ~0ull. But results >> of a nested VMREAD are undefined in such cases. >> >> Fix this by not copying the value of VMCS shadowing control from vmcs01 >> to vmcs02. >> >> Signed-off-by: Sergey Dyasli > Acked-by: Kevin Tian Pulled into x86-next ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: Enable new SSE/AVX/AVX512 cpu features
On Thu, Nov 02, 2017 at 08:59:20AM +0800, Zhong Yang wrote:
> On Wed, Nov 01, 2017 at 03:29:16PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 27, 2017 at 10:18:04PM +0800, Yang Zhong wrote:
> > > Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> > > VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> > > need expose to guest.wq
> >
> > s/wq//
>
> Hello Konrad,
>
> Thanks for reviewing my patch, i will remove this .wq in next
> version,thanks!
Heh. I also did an review and it looked OK to me. You can also
add Reviewed-by: Konrad Rzeszutek Wilk
>
> Regards,
>
> Yang
>
> > >
> > > The bit definition:
> > > CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
> > > CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
> > > CPUID.(EAX=7,ECX=0):ECX[bit 09] VAES
> > > CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ
> > > CPUID.(EAX=7,ECX=0):ECX[bit 11] AVX512VNNI
> > > CPUID.(EAX=7,ECX=0):ECX[bit 12] AVX512_BITALG
> > >
> > > The release document ref below link:
> > > https://software.intel.com/sites/default/files/managed/c5/15/\
> > > architecture-instruction-set-extensions-programming-reference.pdf
> >
> > Ah! Thank you!
> > >
> > > Signed-off-by: Yang Zhong
> > > ---
> > > docs/man/xl.cfg.pod.5.in| 3 ++-
> > > tools/libxl/libxl_cpuid.c | 6 ++
> > > tools/misc/xen-cpuid.c | 13 +++--
> > > xen/include/public/arch-x86/cpufeatureset.h | 6 ++
> > > xen/tools/gen-cpuid.py | 3 ++-
> > > 5 files changed, 23 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> > > index b7b91d8..d056768 100644
> > > --- a/docs/man/xl.cfg.pod.5.in
> > > +++ b/docs/man/xl.cfg.pod.5.in
> > > @@ -1731,7 +1731,8 @@ perfctr_core perfctr_nb pge pku popcnt pse pse36
> > > psn rdrand rdseed rdtscp rtm
> > > sha skinit smap smep smx ss sse sse2 sse3 sse4.1 sse4.2 sse4_1 sse4_2
> > > sse4a
> > > ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate
> > > svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc tsc-deadline
> > > tsc_adjust
> > > -umip vme vmx wdt x2apic xop xsave xtpr
> > > +umip vme vmx wdt x2apic xop xsave xtpr avx512_vbmi2 gfni vaes vpclmulqdq
> > > +avx512_vnni avx512_bitalg
> > >
> > >
> > > The xend syntax is a list of values in the form of
> > > diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
> > > index e692b61..614991f 100644
> > > --- a/tools/libxl/libxl_cpuid.c
> > > +++ b/tools/libxl/libxl_cpuid.c
> > > @@ -199,6 +199,12 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list
> > > *cpuid, const char* str)
> > > {"umip", 0x0007, 0, CPUID_REG_ECX, 2, 1},
> > > {"pku", 0x0007, 0, CPUID_REG_ECX, 3, 1},
> > > {"ospke",0x0007, 0, CPUID_REG_ECX, 4, 1},
> > > +{"avx512_vbmi2", 0x0007, 0, CPUID_REG_ECX, 6, 1},
> > > +{"gfni", 0x0007, 0, CPUID_REG_ECX, 8, 1},
> > > +{"vaes", 0x0007, 0, CPUID_REG_ECX, 9, 1},
> > > +{"vpclmulqdq", 0x0007, 0, CPUID_REG_ECX, 10, 1},
> > > +{"avx512_vnni", 0x0007, 0, CPUID_REG_ECX, 11, 1},
> > > +{"avx512_bitalg",0x0007, 0, CPUID_REG_ECX, 12, 1},
> > >
> > > {"avx512-4vnniw",0x0007, 0, CPUID_REG_EDX, 2, 1},
> > > {"avx512-4fmaps",0x0007, 0, CPUID_REG_EDX, 3, 1},
> > > diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
> > > index 106be0f..985deea 100644
> > > --- a/tools/misc/xen-cpuid.c
> > > +++ b/tools/misc/xen-cpuid.c
> > > @@ -120,12 +120,13 @@ static const char *str_Da1[32] =
> > >
> > > static const char *str_7c0[32] =
> > > {
> > > -[ 0] = "prechwt1", [ 1] = "avx512vbmi",
> > > -[ 2] = "REZ", [ 3] = "pku",
> > > -[ 4] = "ospke",
> > > -
> > > -[5 ... 13] = "REZ",
> > > -
> > > +[ 0] = "prechwt1", [ 1] = "avx512vbmi",
> > > +[ 2] = "REZ", [ 3] = "pku",
> > > +[ 4] = "ospke",[ 5] = "REZ",
> > > +[ 6] = "avx512_vbmi2", [ 7] = "REZ",
> > > +[ 8] = "gfni", [ 9] = "vaes",
> > > +[10] = "vpclmulqdq", [11] = "avx512_vnni",
> > > +[12] = "avx512_bitalg",[13] = "REZ",
> > > [14] = "avx512_vpopcntdq",
> > >
> > > [15 ... 31] = "REZ",
> > > diff --git a/xen/include/public/arch-x86/cpufeatureset.h
> > > b/xen/include/public/arch-x86/cpufeatureset.h
> > > index 0ee3ea3..bb24b79 100644
> > > --- a/xen/include/public/arch-x86/cpufeatureset.h
> > > +++ b/xen/include/public/arch-x86/cpufeatureset.h
> > > @@ -228,6 +228,12 @@ XEN_CPUFEATURE(AVX512VBMI,6*32+ 1) /*A AVX-512
> > > Vector Byte Manipulation Ins
> > > XEN_CPUFEATURE(UMIP, 6*32+ 2) /*S User Mode Instruction
> > > Prevention */
> > > XEN_CPUFEATURE(PKU, 6*32+ 3) /*H Protection Keys for
> > > Userspace */
> > > XEN_CPUFEATURE(OSPKE, 6*32+ 4) /*! OS Protecti
Re: [Xen-devel] [Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events
On 2 November 2017 at 17:18, Liang Yan wrote:
> New tigervnc changes the way to send long pressed key,
> from "down up down up ..." to "down down ... up", it only
> affects xen pv console mode. I send a patch to latest
> kernel side, but it may have a fix in qemu backend for
> back compatible becase guest VMs may use very old kernel.
> This patch inserts an up event after each regular key down
> event to simulate an auto-repeat key event for xen keyboard
> frontend driver.
>
> Signed-off-by: Liang Yan
> ---
> v2:
> - exclude extended key
> - change log comment
>
> hw/display/xenfb.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 8e2547ac05..1bc5b41ab7 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -292,6 +292,11 @@ static void xenfb_key_event(void *opaque, int scancode)
> }
> trace_xenfb_key_event(opaque, scancode2linux[scancode], down);
> xenfb_send_key(xenfb, down, scancode2linux[scancode]);
> +
> +/* insert an up event for regular down key event */
> +if (down && !xenfb->extended) {
> +xenfb_send_key(xenfb, 0, scancode2linux[scancode]);
> +}
> }
This doesn't look to me like the right place to fix this bug.
The xenfb key event handler is just one QEMU keyboard backend
(in a setup where there are many possible sources of keyboard
events: vnc, gtk, SDL, cocoa UI frontends; and many possible
sinks: xenfb's key handling, ps2 keyboard emulator, etc etc).
We need to be clear in our definition of generic QEMU key
events how key repeat is supposed to be handled, and then
every consumer and every producer needs to follow that.
In the specific case of the vnc UI frontend, we need to
also look at what the VNC protocol specifies for key repeat.
That then tells us whether the bug to be fixed is in QEMU,
or in a particular VNC client.
thanks
-- PMM
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
On 10/27/2017 04:09 PM, NathanStuder wrote: > > > On 10/09/2017 10:14 AM, Lars Kurth wrote: >> >>> On 27 Sep 2017, at 13:57, Robert VanVossen >>> wrote: >>> >>> >>> >>> On 9/26/2017 3:12 AM, Dario Faggioli wrote: [Cc-list modified by removing someone and adding someone else] On Mon, 2017-09-25 at 16:10 -0700, Stefano Stabellini wrote: > On Mon, 11 Sep 2017, George Dunlap wrote: >> +### RTDS based Scheduler >> + >> +Status: Experimental >> + >> +A soft real-time CPU scheduler built to provide guaranteed CPU >> capacity to guest VMs on SMP hosts >> + >> +### ARINC653 Scheduler >> + >> +Status: Supported, Not security supported >> + >> +A periodically repeating fixed timeslice scheduler. Multicore >> support is not yet implemented. >> + >> +### Null Scheduler >> + >> +Status: Experimental >> + >> +A very simple, very static scheduling policy >> +that always schedules the same vCPU(s) on the same pCPU(s). >> +It is designed for maximum determinism and minimum overhead >> +on embedded platforms. >> >> ... >> Actually, the best candidate for gaining security support, is IMO ARINC. Code is also rather simple and "stable" (hasn't changed in the last... years!) and it's used by DornerWorks' people for some of their projects (I think?). It's also not tested in OSSTest, though, and considering how special purpose it is, I think we're not totally comfortable marking it as Sec-Supported, without feedback from the maintainers. George, Josh, Robert? >>> >>> Yes, we do still use the ARINC653 scheduler. Since it is so simple, it >>> hasn't >>> really needed any modifications in the last couple years. >>> >>> We are not really sure what kind of feedback you are looking from us in >>> regards >>> to marking it sec-supported, but would be happy to try and answer any >>> questions. >>> If you have any specific questions or requests, we can discuss it >>> internally and >>> get back to you. >> >> I think there are two sets of issues: one around testing, which Dario >> outlined. >> >> For example, if you had some test harnesses that could be run on Xen release >> candidates, which verify that the scheduler works as expected, that would >> help. It would imply a commitment to run the tests on release candidates. > > We have an internal Xen test harness that we use to test the scheduler, but I > assume you would like it converted to use OSSTest instead, so that the > tests could be integrated into the main test suite someday? In our past discussions I don't think anyone has thought the "everything has to be tested in osstest" strategy is really feasible. So I think we were going for a model where it just had to be regularly tested *somewhere*, more or less as a marker for "is this functionality important enough to people to give security support". >> The second question is what happens if someone reported a security issue on >> the scheduler. The security team would not have the capability to fix issues >> in >> the ARINC scheduler: so it would be necessary to pull in an expert under >> embargo to help triage the issue, fix the issue and prove that the fix >> works. This >> would most likely require "the expert" to work to the timeline of the >> security >> team (which may require prioritising it over other work), as once a security >> issue >> has been reported, the reporter may insist on a disclosure schedule. If we >> didn't >> have a fix in time, because we don't get expert bandwidth, we could be >> forced to >> disclose an XSA without a fix. > > We can support this and have enough staff familiar with the scheduler that > prioritizing security issues shouldn't be a problem. The maintainers (Robbie > and Josh) can triage issues if and when the time comes, but if you need a more > dedicated "expert" for this type of issue, then that would likely be me. OK -- in that case, if it's OK with you, I'll list ArinC as 'Supported'. Thanks, -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events
On Thu, Nov 02, 2017 at 05:26:50PM +, Peter Maydell wrote:
> On 2 November 2017 at 17:18, Liang Yan wrote:
> > New tigervnc changes the way to send long pressed key,
> > from "down up down up ..." to "down down ... up", it only
> > affects xen pv console mode. I send a patch to latest
> > kernel side, but it may have a fix in qemu backend for
> > back compatible becase guest VMs may use very old kernel.
> > This patch inserts an up event after each regular key down
> > event to simulate an auto-repeat key event for xen keyboard
> > frontend driver.
> >
> > Signed-off-by: Liang Yan
> > ---
> > v2:
> > - exclude extended key
> > - change log comment
> >
> > hw/display/xenfb.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> > index 8e2547ac05..1bc5b41ab7 100644
> > --- a/hw/display/xenfb.c
> > +++ b/hw/display/xenfb.c
> > @@ -292,6 +292,11 @@ static void xenfb_key_event(void *opaque, int scancode)
> > }
> > trace_xenfb_key_event(opaque, scancode2linux[scancode], down);
> > xenfb_send_key(xenfb, down, scancode2linux[scancode]);
> > +
> > +/* insert an up event for regular down key event */
> > +if (down && !xenfb->extended) {
> > +xenfb_send_key(xenfb, 0, scancode2linux[scancode]);
> > +}
> > }
>
> This doesn't look to me like the right place to fix this bug.
> The xenfb key event handler is just one QEMU keyboard backend
> (in a setup where there are many possible sources of keyboard
> events: vnc, gtk, SDL, cocoa UI frontends; and many possible
> sinks: xenfb's key handling, ps2 keyboard emulator, etc etc).
>
> We need to be clear in our definition of generic QEMU key
> events how key repeat is supposed to be handled, and then
> every consumer and every producer needs to follow that.
> In the specific case of the vnc UI frontend, we need to
> also look at what the VNC protocol specifies for key repeat.
> That then tells us whether the bug to be fixed is in QEMU,
> or in a particular VNC client.
I'm somewhat inclined to say this is a Tigervnc bug. We fixed this
same issue in GTK-VNC ~10 years ago. While X11 would send a sequence
of press,release,press,release, GTK would turn this into
press,press,press,press,release which broke some VNC servers.
So GTK-VNC undoes this optimization from GTK to ensure a full set
of press,release,press,release pairs is always sent.
The official RFC for VNC does not specify any auto-repeat behaviour
https://tools.ietf.org/html/rfc6143#section-7.5.4
The unofficial community authored extension to the RFC suggests
taking the press,press,press,release approach to allow servers to
distinguish auto-repeat from manual repeat, but I'm not really
convinced by that justification really
http://vncdotool.readthedocs.io/en/latest/rfbproto.html#keyevent
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator
Hi Volodymyr, On 02/11/17 16:53, Volodymyr Babchuk wrote: On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote: On 24/10/17 20:02, Volodymyr Babchuk wrote: If it is not safe, this means you have a whitelist solution and therefore tie Xen to a specific OP-TEE version. So if you need to use a new function you would need to upgrade Xen making the code of using new version potentially high. Yes, any ABI change between OP-TEE and its clients will require mediator upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI, which is known to XEN. Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you impose anyone wanted to modify OP-TEE for their own purpose can make a closed version of the TEE. But if you need to introspect/whitelist call, you impose the vendor to expose their API. Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2. If vendor modifies interface between OP-TEE and Linux, they anyways obligued to expose API. Pardon me for potential stupid questions, my knowledge of OP-TEE is limited. My understanding is the OP-TEE will provide a generic way to access different Trusted Application. While OP-TEE API may be generic, the TA API is custom. AFAICT the latter is not part of Linux driver. Yes, you are perfectly right there. So here my questions: 1) Are you planning allow all the guests to access every Trusted Applications? This is a good question. There are two types of TAs supported in OP-TEE: real TAs (as they are described in GlobalPlatform specs) and PseudoTAs. The latter ones are statically linked right into OP-TEE kernel and execute at S-EL1 level. Real TAs are provided by client. That means that NW userspace supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA and then runs it in S-EL0. So, I'm planning to allow client to work with any real TA. I can't see real problem there. Are the real TAs going to be shared between guests? Or will each guest have their own one? No, we don't plan this. At least at this momoent. Every guest will have own instance of TA. Will you allow every guests loading real TAs? Yes, if guest has access to TEE, it can load TA. Either there is no sense to use TEE. OP-TEE core itself does not provide useful services to clients. In a previous e-mail you mentioned OP-TEE has limited memory. How will you ensure that guest A will not use all the memory of OP-TEE and prevent guest B to load TAs? There are no way to do this right now. Even on bare-metal system, one client call load huge TA or eat up memory in another way to prevent other clients to use OP-TEE. This is known limitation. It can be mitigated by enforcing quotas. Yes, but those clients only serve one OS. Here you would serve multiple OSes, clients from OS A could eat up the memory and prevent a client from OS B to run. This could be a serious issue depending on how important the clients for OS are. So likely enforcing quotas will be needed. [...] Not really, you could the domain could block when issuing an SMC until the mediator is up and running. Do you mean, that if domain tries to execute SMC, and mediator is not ready, then hypervisor should pause all domain's vCPUs? That can be destructive for hw domain. Xen is free to unschedule any vCPU at any time. So why would it be destructive? Suppose that mediator domain needs 0.5s to boot up and be ready to serve calls. For half of a second HW domain will be blocked. I don't like the idea, that it will not be able to serve IRQs and other requests. IMHO, it is okay for DomU, but not for Dom0. And yes, it seems obvious, but I want to say this explicitly: generic TEE mediator framework should and will use XSM to control which domain can work with TEE. So, if you don't trust your guest - don't let it to call TEE at all. Correct me if I am wrong. TEE could be used by Android guest which likely run the user apps... right? So are you saying you fully trust that guest and obviously the user installing rogue app? I don't think that app downloaded from Play Marget can access OP-TEE directly. OP-TEE can be used by Android itself as a key storage or to access to a SE, for example. But 3rd app that issues TEE calls... I don't think so. You didn't get my point here. That rogue app may be able to break into kernel via an exploit or have enough privilege to break the guest. Who knows what it will be able to do after... Only what hypervisor and TEE will allow it to do. Look, OP-TEE was not designed to rule the machine. There is ARM TF for that :) OP-TEE's task is to provide some safer environment for sensitive data and code. This environment has well-defined interfaces and is desgined to be as safe as possible. If rogue app breaks into kernel, then it can issue any SMC which it wants. But OP-TEE does not trust to NW. Hypervisor does not trust to guests. Mediator should be writ
Re: [Xen-devel] [Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events
Thanks for the reply.
On 11/2/17 1:26 PM, Peter Maydell wrote:
> On 2 November 2017 at 17:18, Liang Yan wrote:
>> New tigervnc changes the way to send long pressed key,
>> from "down up down up ..." to "down down ... up", it only
>> affects xen pv console mode. I send a patch to latest
>> kernel side, but it may have a fix in qemu backend for
>> back compatible becase guest VMs may use very old kernel.
>> This patch inserts an up event after each regular key down
>> event to simulate an auto-repeat key event for xen keyboard
>> frontend driver.
>>
>> Signed-off-by: Liang Yan
>> ---
>> v2:
>> - exclude extended key
>> - change log comment
>>
>> hw/display/xenfb.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
>> index 8e2547ac05..1bc5b41ab7 100644
>> --- a/hw/display/xenfb.c
>> +++ b/hw/display/xenfb.c
>> @@ -292,6 +292,11 @@ static void xenfb_key_event(void *opaque, int scancode)
>> }
>> trace_xenfb_key_event(opaque, scancode2linux[scancode], down);
>> xenfb_send_key(xenfb, down, scancode2linux[scancode]);
>> +
>> +/* insert an up event for regular down key event */
>> +if (down && !xenfb->extended) {
>> +xenfb_send_key(xenfb, 0, scancode2linux[scancode]);
>> +}
>> }
> This doesn't look to me like the right place to fix this bug.
> The xenfb key event handler is just one QEMU keyboard backend
> (in a setup where there are many possible sources of keyboard
> events: vnc, gtk, SDL, cocoa UI frontends; and many possible
> sinks: xenfb's key handling, ps2 keyboard emulator, etc etc).
QEMU actually just forwards what it receives(vnc,sdl) to different
backend handler, usually those front and back(device) end will work
together to handle those events. For this one, it could and should be
fixed in front-end driver, but there are so many different guest kernel,
especially for those old versions, it would be totally a pain. That is
why I came back to backend side. BTW, I saw same logic in other places
of qemu too.
Best,
Liang
> We need to be clear in our definition of generic QEMU key
> events how key repeat is supposed to be handled, and then
> every consumer and every producer needs to follow that.
> In the specific case of the vnc UI frontend, we need to
> also look at what the VNC protocol specifies for key repeat.
> That then tells us whether the bug to be fixed is in QEMU,
> or in a particular VNC client.
>
> thanks
> -- PMM
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document
On Thu, 2 Nov 2017, Andre Przywara wrote: > (CC:ing some KVM/ARM folks involved in the VGIC) > > starting with the addition of the ITS support we were seeing more and > more issues with the current implementation of our ARM Generic Interrupt > Controller (GIC) emulation, the VGIC. > Among other approaches to fix those issues it was proposed to copy the > VGIC emulation used in KVM. This one was suffering from very similar > issues, and a clean design from scratch lead to a very robust and > capable re-implementation. Interestingly this implementation is fairly > self-contained, so it seems feasible to copy it. Hopefully we only need > minor adjustments, possibly we can even copy it verbatim with some > additional glue layer code. > > Stefano asked for getting a design overview, to assess the feasibility > of copying the KVM code without reviewing tons of code in the first > place. > So to follow Xen rules for new features, this design document below is > an attempt to describe the current KVM VGIC design - in a hypervisor > agnostic session. It is a bit of a retro-fit design description, as it > is not strictly forward-looking only, but actually describing the > existing implemenation [1]. > > Please have a look and let me know: > 1) if this document has the right scope > 2) if this document has the right level of detail > 3) if there are points missing from the document > 3) if the design in general is a fit > >>> > >>> Please read the following statements as genuine questions and concerns. > >>> Most ideas on this document are good. Some of them I have even suggested > >>> them myself in the context of GIC improvements for Xen. I asked for a > >>> couple of clarifications. > >>> > >>> But I don't see why we cannot implement these ideas on top of the > >>> existing code, rather than with a separate codebase, ending up with two > >>> drivers. I would prefer a natual evolution. Specifically, the following > >>> improvements would be simple and would give us most of the benefits on > >>> top of the current codebase: > >>> - adding the irq lock, and the refcount > >>> - taking both vcpu locks when necessary (on migration code for example > >>> it would help a lot), the lower vcpu_id first > >>> - level irq emulation > >> > >> I think some of those points you mentioned are not easily implemented in > >> the current Xen. For instance I ran into locking order issues with those > >> *two* inflight and lr_queue lists, when trying to implement the lock and > >> the refcount. > >> Also this "put vIRQs into LRs early, but possibly rip them out again" is > >> really complicating things a lot. > >> > >> I believe only level IRQs could be added in a relatively straight > >> forward manner. > >> > >> So the problem with the evolutionary approach is that it generates a lot > >> of patches, some of them quite invasive, others creating hard-to-read > >> diffs, which are both hard to review. > >> And chances are that the actual result would be pretty close to the KVM > >> code. To be clear: I hacked the Xen VGIC into the KVM direction in a few > >> days some months ago, but it took me *weeks* to make sane patches of > >> only the first part of it. > >> And this would not cover all those general, tedious corner cases that > >> the VGIC comes with. Those would need to be fixed in a painful process, > >> which we could avoid by "lifting" the KVM code. > > > > I hear you, but the principal cost here is the review time, not the > > development time. Julien told me that it would be pretty much the same > > for him in terms of time it takes to review the changes, it doesn't > > matter if it's a new driver or changes to the existing driver. For me, > > it wouldn't be the same: I think it would take me far less time to > > review them if they were against the existing codebase. > > I am not so sure about this. The changes are quite dramatic, and those > changes tend to produce horrible diffs. Or we try to mitigate this, but > this comes at a cost of having *many* patches, which take a while to > produce. > But if we instantiate a new VGIC implementation from scratch, we can > provide very nice-to-review patches, because the patches can focus on > logical changes and don't need to care about bisectability. All right > > However, as I wrote, this is not my foremost concern. I would be up to > > committing myself to review this even if we decide to go for a new > > driver. > > > > > >>> If we do end up with a second separate driver for technical or process > >>> reasons, I would expect the regular Xen submission/review process to be > >>> followed. The code style will be different, the hooks into the rest of > >>> the hypervisors will be different and things will be generally changed. > >>> The new V/GIC might be derived from KVM, but it should end up looking > >>> and feeling like a 100% genuin
[Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters
The proposed directory provides a mechanism for tools to control the maximum feature set of the device being provisioned by backend. The parameters/features include offloading features, number of queues etc. Signed-off-by: Joao Martins --- xen/include/public/io/netif.h | 16 1 file changed, 16 insertions(+) diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h index 2454448baa..a412e4771d 100644 --- a/xen/include/public/io/netif.h +++ b/xen/include/public/io/netif.h @@ -161,6 +161,22 @@ */ /* + * The directory "require" maybe be created in backend path by tools + * domain to override the maximum feature set that backend provides to the + * frontend. The children entries within this directory are features names + * and the correspondent values that should be used backend as defaults e.g.: + * + * /local/domain/X/backend///require + * /local/domain/X/backend///require/multi-queue-max-queues = "2" + * /local/domain/X/backend///require/feature-no-csum-offload = "1" + * + * In the example above, network backend will negotiate up to a maximum of + * two queues with frontend plus disabling IPv4 checksum offloading. + * + * This directory and its children entries shall only be visible to the backend. + */ + +/* * Control ring * * -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 4/8] libxl: add backend_features to libxl_device_nic
Adds "backend_features" to the libxl_device_nic structure to
represent a set of features to be set on the device by the admin.
These backend_features is a key value store representing
an array of = , which would then be
translated into (backend-only permissions) xenstore entries in
the form of:
/local/domain//backend/vif///require
/local/domain/[...]/require/ =
Entries get stored under the require directory within the backend
path.
Adjust libxl__device_add and libxl__device_add_async to pass the
third argument as the backend-only entries to be written to backend_path.
Signed-off-by: Joao Martins
---
tools/libxl/libxl.h | 8
tools/libxl/libxl_9pfs.c | 2 +-
tools/libxl/libxl_console.c | 2 +-
tools/libxl/libxl_device.c | 14 --
tools/libxl/libxl_internal.h | 2 +-
tools/libxl/libxl_nic.c | 13 -
tools/libxl/libxl_types.idl | 1 +
tools/libxl/libxl_vdispl.c | 3 ++-
tools/libxl/libxl_vtpm.c | 2 +-
9 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 82990089ef..5b4fbebf7b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1109,6 +1109,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
const libxl_mac *src);
*/
#define LIBXL_HAVE_DISK_BACKEND_FEATURES 1
+/*
+ * LIBXL_HAVE_VIF_BACKEND_FEATURES
+ *
+ * libxl_device_nic contains backend_features which can be used to control
+ * what features are exposed to guest vifs.
+ */
+#define LIBXL_HAVE_VIF_BACKEND_FEATURES 1
+
typedef char **libxl_string_list;
void libxl_string_list_dispose(libxl_string_list *sl);
int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_9pfs.c b/tools/libxl/libxl_9pfs.c
index 9db887b5d8..3b80b358f4 100644
--- a/tools/libxl/libxl_9pfs.c
+++ b/tools/libxl/libxl_9pfs.c
@@ -42,7 +42,7 @@ static LIBXL_DEFINE_UPDATE_DEVID(p9, "9pfs")
static int libxl__set_xenstore_p9(libxl__gc *gc, uint32_t domid,
libxl_device_p9 *p9,
flexarray_t *back, flexarray_t *front,
- flexarray_t *ro_front)
+ flexarray_t *ro_front, flexarray_t *require)
{
flexarray_append_pair(back, "path", p9->path);
flexarray_append_pair(back, "security_model", p9->security_model);
diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index f40def1276..1c5a298750 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -730,7 +730,7 @@ static LIBXL_DEFINE_UPDATE_DEVID(vfb, "vfb")
static int libxl__set_xenstore_vfb(libxl__gc *gc, uint32_t domid,
libxl_device_vfb *vfb,
flexarray_t *back, flexarray_t *front,
- flexarray_t *ro_front)
+ flexarray_t *ro_front, flexarray_t *require)
{
flexarray_append_pair(back, "vnc",
libxl_defbool_val(vfb->vnc.enable) ? "1" : "0");
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 05178fb480..87983e2ef9 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1860,7 +1860,7 @@ void libxl__device_add_async(libxl__egc *egc, uint32_t
domid,
libxl__ao_device *aodev)
{
STATE_AO_GC(aodev->ao);
-flexarray_t *back;
+flexarray_t *back, *require;
flexarray_t *front, *ro_front;
libxl__device *device;
xs_transaction_t t = XBT_NULL;
@@ -1912,6 +1912,7 @@ void libxl__device_add_async(libxl__egc *egc, uint32_t
domid,
back = flexarray_make(gc, 16, 1);
front = flexarray_make(gc, 16, 1);
ro_front = flexarray_make(gc, 16, 1);
+require = flexarray_make(gc, 16, 1);
flexarray_append_pair(back, "frontend-id", GCSPRINTF("%d", domid));
flexarray_append_pair(back, "online", "1");
@@ -1924,7 +1925,7 @@ void libxl__device_add_async(libxl__egc *egc, uint32_t
domid,
GCSPRINTF("%d", XenbusStateInitialising));
if (dt->set_xenstore_config)
-dt->set_xenstore_config(gc, domid, type, back, front, ro_front);
+dt->set_xenstore_config(gc, domid, type, back, front, ro_front,
require);
for (;;) {
rc = libxl__xs_transaction_start(gc, &t);
@@ -1948,7 +1949,7 @@ void libxl__device_add_async(libxl__egc *egc, uint32_t
domid,
libxl__xs_kvs_of_flexarray(gc, back),
libxl__xs_kvs_of_flexarray(gc, front),
libxl__xs_kvs_of_flexarray(gc, ro_front),
- NULL);
+ libxl__xs_kvs_of_flexarray(gc, require));
rc = libxl__xs_transaction_commit(gc, &t);
if (!rc) break;
@@ -1974,7 +1975,7 @@ out:
int libxl__device_add(libxl__gc *gc, uint32_t domid,
const struct li
[Xen-devel] [PATCH RFC 1/8] public/io/blkif: add directory for backend parameters
The proposed directory provides a mechanism for tools to control the maximum feature set of the device being provisioned by backends. Examples include max ring page order, persistent grants, number of queues etc. Signed-off-by: Joao Martins --- xen/include/public/io/blkif.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h index 15a71e3fea..4c0a93a2bf 100644 --- a/xen/include/public/io/blkif.h +++ b/xen/include/public/io/blkif.h @@ -133,6 +133,20 @@ * This option doesn't require a backend to use O_DIRECT, so it * should not be used to try to control the caching behaviour. * + * require + * + * The directory "require" maybe be created by tools domain to + * override the maximum feature set that backend provides to the + * frontend. The children entries within this directory are + * features names and its correspondent value e.g.: + * + * /local/domain/X/backend/vbd///require + * /local/domain/X/backend/vbd///require/multi-queue-max-queues = "2" + * /local/domain/X/backend/vbd///require/feature-persistent = "0" + * + * In the example above, block backend will negotiate up to a maximum of + * two queues with frontend plus disabling persistent grants. + * *- Features - * * feature-barrier -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 0/8] libxl, xl, public/io: PV backends feature control
Hey folks, Presented herewith is an attempt to implement PV backends feature control as discussed in the list (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html) Given that this a simple proposal hence I thought to include all changes involved in the same patchset such that everyone see all the changes and has a better estimate (but restricted to xen-devel just for the RFC purposes). The motivation here is to allow system administrators more fine grained control of the device features being used by guest. The only change I made compared to the proposed discussed above was to use "require" instead of "request" as the prefix because there is a feature which has "request" in it. But if "request" is still preferred as a prefix I can change it up. The scheme proposed is quite simple: * The directory "require" is created (inside the backend path) and within that directory the features/capabilities names and values are written. * Toolstack constructs a key value store of features, and user specifies those through special entry names prefixed also as "require". Toolstack is stateless thus sys admin has full control over what to pass to the backend. In other words it doesn't look at particular feature names/values. * The backend will then use that for seeding its maximum feature set to the frontend. An example would be a domain config to look like this: vif = ["bridge=br0,require-multi-queue-max-queues=2"] disk = [ "phy:/path/to/disk,hda,w,require-feature-persistent=0" ] And if backend supports it, it would create a vif with a maximum of 2 queues, and a vbd with persistent grants disabled. I only implemented for blkback and netback but there is nothing really specific to how it's done and could possibly be implemented in other PV interfaces. But there wasn't a protocol agnostic file to put all this, so I went ahead and did for the two individual io types (block and netif) I am most interested in. Any comments appreciated :) Thanks! Joao For Linux the diffstat/changeset is: (the last two patches) Joao Martins (2): xen-blkback: frontend feature control xen-netback: frontend feature control drivers/block/xen-blkback/blkback.c | 2 +- drivers/block/xen-blkback/common.h | 1 + drivers/block/xen-blkback/xenbus.c | 66 --- drivers/net/xen-netback/xenbus.c| 122 +--- 4 files changed, 159 insertions(+), 32 deletions(-) And for Xen the diffstat/changeset is: Joao Martins (6): public/io/blkif: add directory for backend parameters public/io/netif: add directory for backend parameters libxl: add backend_features to libxl_device_disk libxl: add backend_features to libxl_device_nic libxlu: parse disk backend features parameters xl: parse vif backend features parameters tools/libxl/libxl.h | 16 +++ tools/libxl/libxl_9pfs.c | 2 +- tools/libxl/libxl_console.c | 7 --- tools/libxl/libxl_device.c| 47 +++ tools/libxl/libxl_disk.c | 17 ++-- tools/libxl/libxl_internal.h | 6 -- tools/libxl/libxl_nic.c | 13 +++- tools/libxl/libxl_pci.c | 2 +- tools/libxl/libxl_types.idl | 2 ++ tools/libxl/libxl_usb.c | 2 +- tools/libxl/libxl_vdispl.c| 3 ++- tools/libxl/libxl_vtpm.c | 2 +- tools/libxl/libxlu_disk_l.l | 42 ++ tools/xl/xl_parse.c | 37 ++ tools/xl/xl_parse.h | 2 ++ xen/include/public/io/blkif.h | 14 + xen/include/public/io/netif.h | 16 +++ 17 files changed, 209 insertions(+), 21 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 5/8] libxlu: parse disk backend features parameters
Any option name preceded by "require-" means a backend feature
to be set. This is stored in key value structure which libxl will parse
and tell blkback to override the specified features.
An example would be a config containing:
...
vcpus = 8
disk = [ "phy:/path/to/disk,hda,w,require-multi-queue-max-queues=1" ]
...
Which would set the number of queues to 2 as opposed to e.g. the global
blkback defined xen_blkback.max_queues parameter.
Signed-off-by: Joao Martins
---
tools/libxl/libxlu_disk_l.l | 42 ++
1 file changed, 42 insertions(+)
diff --git a/tools/libxl/libxlu_disk_l.l b/tools/libxl/libxlu_disk_l.l
index 97039a2800..4530c6c4fc 100644
--- a/tools/libxl/libxlu_disk_l.l
+++ b/tools/libxl/libxlu_disk_l.l
@@ -62,6 +62,9 @@ void xlu__disk_yyset_column(int column_no, yyscan_t
yyscanner);
/* For actions whose patterns contain '=', finds the start of the value */
#define FROMEQUALS (strchr(yytext,'=')+1)
+/* For actions whose patterns contain '-', finds the start of the value */
+#define FROMMINUS (strchr(yytext,'-')+1)
+
/* Chops the delimiter off, modifying yytext and yyleng. */
#define STRIP(delim) do{\
if (yyleng>0 && yytext[yyleng-1]==(delim)) \
@@ -114,6 +117,37 @@ static void setbackendtype(DiskParseContext *dpc, const
char *str) {
else xlu__disk_err(dpc,str,"unknown value for backendtype");
}
+static int addbackendfeature(DiskParseContext *dpc, const char *key)
+{
+libxl_key_value_list *sl = &dpc->disk->backend_features;
+size_t count = libxl_key_value_list_length(sl);
+libxl_key_value_list array = *sl;
+char *eql = strchr(key,'=');
+char *val = eql + 1;
+int i;
+
+array = calloc((count+1) * 2 + 1, sizeof(char*));
+if (!array)
+return -ENOMEM;
+
+for (i = 0; i < count * 2; i++) {
+if ((*sl)[i])
+array[i] = strdup((*sl)[i]);
+}
+array[i] = NULL;
+libxl_key_value_list_dispose(sl);
+
+*eql = 0;
+count *= 2;
+array[count++] = strdup(key);
+array[count++] = strdup(val);
+array[count] = NULL;
+*eql = '=';
+
+*sl = array;
+return 0;
+}
+
/* Sets ->colo-port from the string. COLO need this. */
static void setcoloport(DiskParseContext *dpc, const char *str) {
int port = atoi(str);
@@ -187,6 +221,14 @@ script=[^,]*,? { STRIP(','); SAVESTRING("script",
script, FROMEQUALS); }
direct-io-safe,? { DPC->disk->direct_io_safe = 1; }
discard,? { libxl_defbool_set(&DPC->disk->discard_enable, true); }
no-discard,? { libxl_defbool_set(&DPC->disk->discard_enable, false); }
+require-[a-z][-a-z0-9]*=[^,],? {
+ STRIP(',');
+ if (addbackendfeature(DPC, FROMMINUS)) {
+ xlu__disk_err(DPC,yytext,"unable to parse feature");
+ return 0;
+ }
+}
+
/* Note that the COLO configuration settings should be considered unstable.
* They may change incompatibly in future versions of Xen. */
colo,? { libxl_defbool_set(&DPC->disk->colo_enable, true); }
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 6/8] xl: parse vif backend features parameters
Any option name preceded by "require-" means a backend feature to be {un,}set.
This is stored in key value structure which libxl will parse and inform netback
to override the specified features.
An example would be a config containing:
...
vcpus = 8
vif = ["bridge=br0,require-multi-queue-max-queues=2"]
...
Which would set the number of queues to 2 as opposed to e.g. the global
netback defined xen_netback.max_queues parameter.
Signed-off-by: Joao Martins
---
tools/xl/xl_parse.c | 37 +
tools/xl/xl_parse.h | 2 ++
2 files changed, 39 insertions(+)
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 9a692d5ae6..007df694d8 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -401,6 +401,29 @@ void replace_string(char **str, const char *val)
*str = xstrdup(val);
}
+static void add_to_kvlist(libxl_key_value_list *sl, char *key, char *val)
+{
+size_t count = libxl_key_value_list_length(sl);
+libxl_key_value_list array = *sl;
+int i;
+
+array = xcalloc((count+1) * 2 + 1, sizeof(char*));
+
+for (i = 0; i < count * 2; i++) {
+if ((*sl)[i])
+array[i] = xstrdup((*sl)[i]);
+}
+array[i] = NULL;
+libxl_key_value_list_dispose(sl);
+
+count *= 2;
+array[count++] = xstrdup(key);
+array[count++] = xstrdup(val);
+array[count] = NULL;
+
+*sl = array;
+}
+
int match_option_size(const char *prefix, size_t len,
char *arg, char **argopt)
{
@@ -559,6 +582,20 @@ int parse_nic_config(libxl_device_nic *nic, XLU_Config
**config, char *token)
fprintf(stderr, "the accel parameter for vifs is currently not
supported\n");
} else if (MATCH_OPTION("devid", token, oparg)) {
nic->devid = parse_ulong(oparg);
+} else if (MATCH_FEATURE("require", token, oparg)) {
+char *key = NULL, *value = NULL;
+int rc;
+
+rc = split_string_into_pair(oparg, "=", &key, &value);
+if (rc != 0) {
+fprintf(stderr, "failed to parse vif backend feature %s", oparg);
+return 1;
+}
+
+add_to_kvlist(&nic->backend_features, key, value);
+
+free(key);
+free(value);
} else {
fprintf(stderr, "unrecognized argument `%s'\n", token);
return 1;
diff --git a/tools/xl/xl_parse.h b/tools/xl/xl_parse.h
index cc459fb43f..aea07394cc 100644
--- a/tools/xl/xl_parse.h
+++ b/tools/xl/xl_parse.h
@@ -40,6 +40,8 @@ int match_option_size(const char *prefix, size_t len,
#define MATCH_OPTION(prefix, arg, oparg) \
match_option_size((prefix "="), sizeof((prefix)), (arg), &(oparg))
+#define MATCH_FEATURE(prefix, arg, oparg) \
+match_option_size((prefix "-"), sizeof((prefix)), (arg), &(oparg))
void split_string_into_string_list(const char *str, const char *delim,
libxl_string_list *psl);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 3/8] libxl: add backend_features to libxl_device_disk
The function libxl__device_generic_add will have an additional
argument whereby it adds a second set of entries visible to the
backend only. These entries will then be used for devices
thus overriding backend maximum feature set with this user-defined ones.
libxl_device_disk.backend_features are a key value store storing:
=
xl|libxl are stateless with respect to feature names therefore is up to the
admin to carefully select those. If backend isn't supported therefore the
features won't be overwritten.
Signed-off-by: Joao Martins
---
tools/libxl/libxl.h | 8
tools/libxl/libxl_console.c | 5 +++--
tools/libxl/libxl_device.c | 37 +
tools/libxl/libxl_disk.c | 17 +++--
tools/libxl/libxl_internal.h | 4 +++-
tools/libxl/libxl_pci.c | 2 +-
tools/libxl/libxl_types.idl | 1 +
tools/libxl/libxl_usb.c | 2 +-
8 files changed, 65 insertions(+), 11 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 5e9aed739d..82990089ef 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1101,6 +1101,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
const libxl_mac *src);
*/
#define LIBXL_HAVE_SET_PARAMETERS 1
+/*
+ * LIBXL_HAVE_DISK_BACKEND_FEATURES
+ *
+ * libxl_device_disk contains backend_features which can be used to control
+ * what features are exposed to guest vbds.
+ */
+#define LIBXL_HAVE_DISK_BACKEND_FEATURES 1
+
typedef char **libxl_string_list;
void libxl_string_list_dispose(libxl_string_list *sl);
int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index c05dc28b99..f40def1276 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -339,7 +339,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
libxl__device_generic_add(gc, XBT_NULL, device,
libxl__xs_kvs_of_flexarray(gc, back),
libxl__xs_kvs_of_flexarray(gc, front),
- libxl__xs_kvs_of_flexarray(gc, ro_front));
+ libxl__xs_kvs_of_flexarray(gc, ro_front), NULL);
rc = 0;
out:
return rc;
@@ -385,7 +385,8 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t domid,
rc = libxl__device_generic_add(gc, XBT_NULL, &device,
libxl__xs_kvs_of_flexarray(gc, back),
NULL,
- libxl__xs_kvs_of_flexarray(gc, ro_front));
+ libxl__xs_kvs_of_flexarray(gc, ro_front),
+ NULL);
return rc;
}
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5438577c3c..05178fb480 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -43,6 +43,15 @@ char *libxl__device_backend_path(libxl__gc *gc,
libxl__device *device)
device->domid, device->devid);
}
+char *libxl__device_require_path(libxl__gc *gc, libxl__device *device)
+{
+char *dom_path = libxl__xs_get_dompath(gc, device->backend_domid);
+
+return GCSPRINTF("%s/backend/%s/%u/%d/require", dom_path,
+ libxl__device_kind_to_string(device->backend_kind),
+ device->domid, device->devid);
+}
+
char *libxl__device_libxl_path(libxl__gc *gc, libxl__device *device)
{
char *libxl_dom_path = libxl__xs_libxl_path(gc, device->domid);
@@ -114,13 +123,16 @@ out:
}
int libxl__device_generic_add(libxl__gc *gc, xs_transaction_t t,
-libxl__device *device, char **bents, char **fents, char **ro_fents)
+libxl__device *device, char **bents, char **fents, char **ro_fents,
+char **brents)
{
libxl_ctx *ctx = libxl__gc_owner(gc);
-char *frontend_path = NULL, *backend_path = NULL, *libxl_path;
+char *frontend_path = NULL, *backend_path = NULL, *require_path = NULL,
+ *libxl_path;
struct xs_permissions frontend_perms[2];
struct xs_permissions ro_frontend_perms[2];
struct xs_permissions backend_perms[2];
+struct xs_permissions require_perms[1];
int create_transaction = t == XBT_NULL;
int libxl_only = device->backend_kind == LIBXL__DEVICE_KIND_NONE;
int rc;
@@ -131,6 +143,7 @@ int libxl__device_generic_add(libxl__gc *gc,
xs_transaction_t t,
} else {
frontend_path = libxl__device_frontend_path(gc, device);
backend_path = libxl__device_backend_path(gc, device);
+require_path = libxl__device_require_path(gc, device);
}
libxl_path = libxl__device_libxl_path(gc, device);
@@ -144,6 +157,9 @@ int libxl__device_generic_add(libxl__gc *gc,
xs_transaction_t t,
ro_frontend_perms[1].id = backend_perms[1].id = device->domid;
ro_frontend_perms[1].perms = backend_perms[1].perms = XS_PERM_READ;
+require_perms[0].id = device->backend_domid;
+require_perms[0]
[Xen-devel] [PATCH RFC 7/8] xen-blkback: frontend feature control
Toolstack may write values to the "require" subdirectory in the
backend main directory (e.g. backend/vbd/X/Y/). Read these values
and use them when announcing those to the frontend. When backend
scans frontend features the values set in the require directory
take precedence, hence making no significant changes in feature
parsing.
xenbus_read_feature() reads from require subdirectory and prints that
value and otherwise writing a default_val in the entry. We then replace
all instances of xenbus_printf to use these previously seeded features.
A backend_features struct is introduced and all values set there are
used in place of the module parameters being used.
Note, however that feature-barrier, feature-flush-support and
feature-discard aren't probed because first two are physical
device dependent and feature-discard already has tunables to
adjust.
Signed-off-by: Joao Martins
---
drivers/block/xen-blkback/blkback.c | 2 +-
drivers/block/xen-blkback/common.h | 1 +
drivers/block/xen-blkback/xenbus.c | 66 -
3 files changed, 60 insertions(+), 9 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index c90e90b6..05b3f124c871 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -1271,7 +1271,7 @@ static int dispatch_rw_block_io(struct xen_blkif_ring
*ring,
unlikely((req->operation != BLKIF_OP_INDIRECT) &&
(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) ||
unlikely((req->operation == BLKIF_OP_INDIRECT) &&
-(nseg > MAX_INDIRECT_SEGMENTS))) {
+(nseg > ring->blkif->vbd.max_indirect_segs))) {
pr_debug("Bad number of segments in request (%d)\n", nseg);
/* Haven't submitted any bio's yet. */
goto fail_response;
diff --git a/drivers/block/xen-blkback/common.h
b/drivers/block/xen-blkback/common.h
index a7832428e0da..ff12f2d883b9 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -229,6 +229,7 @@ struct xen_vbd {
unsigned intdiscard_secure:1;
unsigned intfeature_gnt_persistent:1;
unsigned intoverflow_max_grants:1;
+ unsigned intmax_indirect_segs;
};
struct backend_info;
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 48d796ea3626..31683f29d5fb 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -25,11 +25,19 @@
/* On the XenBus the max length of 'ring-ref%u'. */
#define RINGREF_NAME_LEN (20)
+#define REQUIRE_PATH_LEN (256)
+
+struct backend_features {
+ unsigned max_queues;
+ unsigned max_ring_order;
+ unsigned pers_grants;
+};
struct backend_info {
struct xenbus_device*dev;
struct xen_blkif*blkif;
struct xenbus_watch backend_watch;
+ struct backend_features features;
unsignedmajor;
unsignedminor;
char*mode;
@@ -602,6 +610,40 @@ int xen_blkbk_barrier(struct xenbus_transaction xbt,
return err;
}
+static int xenbus_read_feature(const char *dir, const char *node,
+ unsigned int default_val)
+{
+ char reqnode[REQUIRE_PATH_LEN];
+ unsigned int val;
+
+ snprintf(reqnode, REQUIRE_PATH_LEN, "%s/require", dir);
+ val = xenbus_read_unsigned(reqnode, node, default_val);
+ return val;
+}
+
+static void xen_blkbk_probe_features(struct xenbus_device *dev,
+struct backend_info *be)
+{
+ struct backend_features *ft = &be->features;
+ struct xen_vbd *vbd = &be->blkif->vbd;
+
+ vbd->max_indirect_segs = xenbus_read_feature(dev->nodename,
+ "feature-max-indirect-segments",
+ MAX_INDIRECT_SEGMENTS);
+
+ ft->max_queues = xenbus_read_feature(dev->nodename,
+"multi-queue-max-queues",
+xenblk_max_queues);
+
+ ft->max_ring_order = xenbus_read_feature(dev->nodename,
+"max-ring-page-order",
+xen_blkif_max_ring_order);
+
+ ft->pers_grants = xenbus_read_feature(dev->nodename,
+ "feature-persistent",
+ 1);
+}
+
/*
* Entry point to this code when a new device is created. Allocate the basic
* structures, and watch the store waiting for the hotplug scripts to tell us
@@ -613,6 +655,7 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
int err;
struct backend_info *be = kzalloc(sizeof(struct backend_info),
[Xen-devel] [PATCH RFC 8/8] xen-netback: frontend feature control
Toolstack may write values to the "require" subdirectory in the backend
main xenstore directory (e.g. backend/vif/X/Y/). Read these values and
use them when announcing those to the frontend. When backend scans
frontend features the values set in the require directory take
precedence, hence making no significant changes in feature parsing.
This is achieved by using the newly introduced helper
(xenbus_printf_feature()) which reads from require subdirectory and
prints that value and otherwise printing a default_val in the entry. We
then replace all instances of xenbus_printf by this new helper. A
backend_features struct is introduced and all values set there are used
in place of the module parameters being used.
Note, however that feature-rx-copy, feature-rx-flip aren't probed
because first two aren't implemented the full set of possibilities.
Additionally probe to for 'feature-no-csum-offload' to allow toolstack
to control per device checksum offloading.
Signed-off-by: Joao Martins
---
drivers/net/xen-netback/xenbus.c | 122 +++
1 file changed, 99 insertions(+), 23 deletions(-)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index a56d3eab35dd..391f1f2e1af2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -22,9 +22,25 @@
#include
#include
+#define REQUIRE_PATH_LEN (256)
+
+struct backend_features {
+ unsigned int max_queues;
+ unsigned int split_evtchn:1;
+ unsigned int ctrl_ring:1;
+ unsigned int can_sg:1;
+ unsigned int gso_v4:1;
+ unsigned int gso_v6:1;
+ unsigned int mcast_ctrl:1;
+ unsigned int dyn_mcast_ctrl:1;
+ unsigned int ip_no_csum:1;
+ unsigned int ipv6_csum:1;
+};
+
struct backend_info {
struct xenbus_device *dev;
struct xenvif *vif;
+ struct backend_features features;
/* This is the state that will be reflected in xenstore when any
* active hotplug script completes.
@@ -48,6 +64,17 @@ static void xen_unregister_watchers(struct xenvif *vif);
static void set_backend_state(struct backend_info *be,
enum xenbus_state state);
+static int xenbus_read_feature(const char *dir, const char *node,
+ unsigned int default_val)
+{
+ char reqnode[REQUIRE_PATH_LEN];
+ unsigned int val;
+
+ snprintf(reqnode, REQUIRE_PATH_LEN, "%s/require", dir);
+ val = xenbus_read_unsigned(reqnode, node, default_val);
+ return val;
+}
+
#ifdef CONFIG_DEBUG_FS
struct dentry *xen_netback_dbg_root = NULL;
@@ -280,6 +307,32 @@ static int netback_remove(struct xenbus_device *dev)
return 0;
}
+static void netback_probe_features(struct xenbus_device *dev,
+ struct backend_info *be)
+{
+ struct backend_features *ft = &be->features;
+
+ ft->can_sg = xenbus_read_feature(dev->nodename, "feature-sg", 1);
+ ft->gso_v4 = xenbus_read_feature(dev->nodename, "feature-gso-v4", 1);
+ ft->gso_v6 = xenbus_read_feature(dev->nodename, "feature-gso-v6", 1);
+ ft->gso_v6 = xenbus_read_feature(dev->nodename, "feature-gso-v6", 1);
+ ft->ipv6_csum = xenbus_read_feature(dev->nodename,
+ "feature-ipv6-csum-offload", 1);
+ ft->ip_no_csum = xenbus_read_feature(dev->nodename,
+ "feature-no-csum-offload", 0);
+ ft->mcast_ctrl = xenbus_read_feature(dev->nodename,
+"feature-multicast-control", 1);
+ ft->dyn_mcast_ctrl = xenbus_read_feature(dev->nodename,
+ "feature-dynamic-multicast-control", 1);
+ ft->split_evtchn = xenbus_read_feature(dev->nodename,
+ "feature-split-event-channels",
+ separate_tx_rx_irq);
+ ft->max_queues = xenbus_read_feature(dev->nodename,
+"multi-queue-max-queues",
+xenvif_max_queues);
+ ft->ctrl_ring = xenbus_read_feature(dev->nodename, "feature-ctrl-ring",
+ 1);
+}
/**
* Entry point to this code when a new device is created. Allocate the basic
@@ -291,8 +344,8 @@ static int netback_probe(struct xenbus_device *dev,
const char *message;
struct xenbus_transaction xbt;
int err;
- int sg;
const char *script;
+ struct backend_features *ft;
struct backend_info *be = kzalloc(sizeof(struct backend_info),
GFP_KERNEL);
if (!be) {
@@ -309,7 +362,8 @@ static int netback_probe(struct xenbus_device *dev,
if (err)
goto fail;
- sg = 1;
+ netback_probe_features(dev, be);
+ ft = &be->features;
d
Re: [Xen-devel] [Qemu-devel] [PATCH v2] hw/display/xenfb: Simulate auto-repeat key events
On 11/2/17 1:40 PM, Daniel P. Berrange wrote:
> On Thu, Nov 02, 2017 at 05:26:50PM +, Peter Maydell wrote:
>> On 2 November 2017 at 17:18, Liang Yan wrote:
>>> New tigervnc changes the way to send long pressed key,
>>> from "down up down up ..." to "down down ... up", it only
>>> affects xen pv console mode. I send a patch to latest
>>> kernel side, but it may have a fix in qemu backend for
>>> back compatible becase guest VMs may use very old kernel.
>>> This patch inserts an up event after each regular key down
>>> event to simulate an auto-repeat key event for xen keyboard
>>> frontend driver.
>>>
>>> Signed-off-by: Liang Yan
>>> ---
>>> v2:
>>> - exclude extended key
>>> - change log comment
>>>
>>> hw/display/xenfb.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
>>> index 8e2547ac05..1bc5b41ab7 100644
>>> --- a/hw/display/xenfb.c
>>> +++ b/hw/display/xenfb.c
>>> @@ -292,6 +292,11 @@ static void xenfb_key_event(void *opaque, int scancode)
>>> }
>>> trace_xenfb_key_event(opaque, scancode2linux[scancode], down);
>>> xenfb_send_key(xenfb, down, scancode2linux[scancode]);
>>> +
>>> +/* insert an up event for regular down key event */
>>> +if (down && !xenfb->extended) {
>>> +xenfb_send_key(xenfb, 0, scancode2linux[scancode]);
>>> +}
>>> }
>> This doesn't look to me like the right place to fix this bug.
>> The xenfb key event handler is just one QEMU keyboard backend
>> (in a setup where there are many possible sources of keyboard
>> events: vnc, gtk, SDL, cocoa UI frontends; and many possible
>> sinks: xenfb's key handling, ps2 keyboard emulator, etc etc).
>>
>> We need to be clear in our definition of generic QEMU key
>> events how key repeat is supposed to be handled, and then
>> every consumer and every producer needs to follow that.
>> In the specific case of the vnc UI frontend, we need to
>> also look at what the VNC protocol specifies for key repeat.
>> That then tells us whether the bug to be fixed is in QEMU,
>> or in a particular VNC client.
> I'm somewhat inclined to say this is a Tigervnc bug. We fixed this
> same issue in GTK-VNC ~10 years ago. While X11 would send a sequence
> of press,release,press,release, GTK would turn this into
> press,press,press,press,release which broke some VNC servers.
> So GTK-VNC undoes this optimization from GTK to ensure a full set
> of press,release,press,release pairs is always sent.
Tigervnc uses "press press press ... release" now, this one is actually
because xenkb couldn't handler these repeat events. I sent a fix to
front-end side, and this patch here is for old compatibly only,
otherwise we need to patch all those guest VMs even we run a newer host.
Thanks,
Liang
> The official RFC for VNC does not specify any auto-repeat behaviour
>
> https://tools.ietf.org/html/rfc6143#section-7.5.4
>
> The unofficial community authored extension to the RFC suggests
> taking the press,press,press,release approach to allow servers to
> distinguish auto-repeat from manual repeat, but I'm not really
> convinced by that justification really
>
> http://vncdotool.readthedocs.io/en/latest/rfbproto.html#keyevent
>
> Regards,
> Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Xen 4.10 RC3
Hi all, Xen 4.10 RC3 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.10.0-rc3 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.10.0-rc3/xen-4.10.0-rc3.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.10.0-rc3/xen-4.10.0-rc3.tar.gz.sig Please send bug reports and test reports to xen-de...@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (julien.gr...@linaro.org). Thanks, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/9] x86/vvmx: Read instruction operands correctly on VM exit
On 02/11/17 07:23, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Friday, October 27, 2017 1:59 AM
>>
>> On 26/10/17 18:03, Euan Harris wrote:
>>> decode_vmx_inst() does not read instruction operands correctly on VM
>> exit:
>>> * It incorrectly uses vmx_inst_info's address_size field to calculate
>>>the sizes of the exit-causing instruction's operands. The sizes of
>>>the operands are specified in the SDM and might depend on whether
>> the
>>>guest is running in 32-bit or 64-bit mode, but they have nothing to do
>>>with the address_size field.
>>>
>>> * It includes its own segmentation logic, duplicating code elsewhere.
>>>This segmentation logic is also incorrect and will raise #GP fault
>>>rather than a #SS fault in response to an invalid memory access
>>>through the stack segment.
>>>
>>> Patches 1-6 (up to 'Remove operand decoding from decode_vmx_inst()')
>>> refactor decode_vmx_inst() in preparation for fixing the bugs mentioned
>>> above. They remove unnecessary code and extract the logic for reading
>>> operands from decode_vmx_inst() into a new operand_read() function.
>>> These patches should not cause any functional changes.
>>>
>>> Patch 7 ('Use correct sizes when reading operands') replaces the incorrect
>>> operand size calculations based on address_size with the correct sizes
>>> from the SDM.
>>>
>>> Patches 8 and 9 add new hvm_copy_{to,from}_guest_virt() helpers and
>> use
>>> them to read memory operands in place of the incorrect segmentation
>>> logic in decode_vmx_inst().
>>>
>>> Euan Harris (9):
>>> x86/vvmx: Remove enum vmx_regs_enc
>>> x86/vvmx: Unify operands in struct vmx_inst_decoded
>>> x86/vvmx: Extract operand reading logic into operand_read()
>>> x86/vvmx: Remove unnecessary VMX operand reads
>>> x86/vvmx: Replace direct calls to reg_read() with operand_read()
>>> x86/vvmx: Remove operand reading from decode_vmx_inst()
>>> x86/vvmx: Use correct sizes when reading operands
>>> x86/hvm: Add hvm_copy_{to,from}_guest_virt() helpers
>>> x86/vvmx: Use hvm_copy_{to,from}_guest_virt() to read operands
>> All Reviewed-by: Andrew Cooper . I've
>> noticed a few trivial style issues which can be fixed up on commit if
>> there are no other issues.
>>
> Acked-by: Kevin Tian
Pulled into x86-next, with the comments addressed.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: xenbus_probe_frontend: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 146562 Addresses-Coverity-ID: 146563 Signed-off-by: Gustavo A. R. Silva --- drivers/xen/xenbus/xenbus_probe_frontend.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c index 19e45ce..07896f4 100644 --- a/drivers/xen/xenbus/xenbus_probe_frontend.c +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c @@ -379,10 +379,12 @@ static void xenbus_reset_frontend(char *fe, char *be, int be_state) case XenbusStateConnected: xenbus_printf(XBT_NIL, fe, "state", "%d", XenbusStateClosing); xenbus_reset_wait_for_backend(be, XenbusStateClosing); + /* fall through */ case XenbusStateClosing: xenbus_printf(XBT_NIL, fe, "state", "%d", XenbusStateClosed); xenbus_reset_wait_for_backend(be, XenbusStateClosed); + /* fall through */ case XenbusStateClosed: xenbus_printf(XBT_NIL, fe, "state", "%d", XenbusStateInitialising); -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/pvcalls-front: mark expected switch fall-through
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case I placed the "fall through" comment on its own line, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva --- drivers/xen/pvcalls-front.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c index 0c1ec68..ed94ea0 100644 --- a/drivers/xen/pvcalls-front.c +++ b/drivers/xen/pvcalls-front.c @@ -1250,7 +1250,8 @@ static void pvcalls_front_changed(struct xenbus_device *dev, case XenbusStateClosed: if (dev->state == XenbusStateClosed) break; - /* Missed the backend's CLOSING state -- fallthrough */ + /* Missed the backend's CLOSING state */ + /* fall through */ case XenbusStateClosing: xenbus_frontend_closed(dev); break; -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 115479: regressions - FAIL
flight 115479 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/115479/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pygrub 17 guest-localmigrate/x10 fail REGR. vs. 115289 test-armhf-armhf-xl-multivcpu 6 xen-install fail REGR. vs. 115289 test-armhf-armhf-libvirt-raw 7 xen-boot fail REGR. vs. 115289 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 115289 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 115289 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115289 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115289 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115289 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115289 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linux4f823316dac3de3463dfbea2be3812102a76e246 baseline version: linuxb44ef85f9033720e7ec6aa7bc9536b9e4b09719a Last test of basis 115289 2017-10-27 08:53:22 Z6 days Testing same since 115479 2017-11-02 08:52:58 Z0 days1 attempts People who touched revisions under test: Baruch Siach Ben Hutchings David Howells Dmitry Torokhov Douglas Gilbert Eric Biggers Greg Kroah-Hartman Ilya Dryomov Jack Pham Jeff Layton Jimmy Assarsson Linus Torvalds Marc Kleine-Budde Marios Titas Mark Brown Martin K. Petersen Mathias Nyman Mayank Rana Miklos Szeredi Steffen Maier jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-
[Xen-devel] [xen-unstable-smoke test] 115490: tolerable all pass - PUSHED
flight 115490 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115490/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen ff93dc55431517ed29c70dbff6721c6b0803acf9
baseline version:
xen bb2c1a1cc98a22e2d4c14b18421aa7be6c2adf0d
Last test of basis 115303 2017-10-27 18:08:19 Z6 days
Testing same since 115490 2017-11-02 17:01:26 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Andrii Anisov
Doug Goldstein
Ian Jackson
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=ff93dc55431517ed29c70dbff6721c6b0803acf9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.
PERLLIB=.:.
+++ 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
ff93dc55431517ed29c70dbff6721c6b0803acf9
+ branch=xen-unstable-smoke
+ revision=ff93dc55431517ed29c70dbff6721c6b0803acf9
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
export PERLLIB=.:.:.
PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ 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.9-testing
+ '[' xff93dc55431517ed29c70dbff6721c6b0803acf9 = 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://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/o
[Xen-devel] [xen-unstable test] 115478: regressions - trouble: blocked/broken/fail/pass
flight 115478 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/115478/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-armhf-pvops 4 host-install(4)broken REGR. vs. 114644 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 114644 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail REGR. vs. 114644 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 6 xen-install fail in 115401 pass in 115471 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail in 115401 pass in 115471 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail in 115401 pass in 115478 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 115401 pass in 115478 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115471 pass in 115478 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 115401 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-examine 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-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 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-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 115401 like 114644 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 115401 like 114644 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 115401 like 114644 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 115401 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 115401 never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 115401 never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 115401 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 115401 never pass test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 115401 never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 115401 never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 115401 never pass test-armhf-armhf-libvirt13 migrate-support-check fail in 115401 never pass test-armhf-armhf-xl 13 migrate-support-check fail in 115471 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 115471 never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114644 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114644 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114644 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114644 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-
[Xen-devel] [qemu-mainline test] 115484: regressions - FAIL
flight 115484 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/115484/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3866 xen-buildfail REGR. vs. 114507 build-amd64-xsm 6 xen-buildfail REGR. vs. 114507 build-i386-xsm6 xen-buildfail REGR. vs. 114507 build-amd64 6 xen-buildfail REGR. vs. 114507 build-armhf 6 xen-buildfail REGR. vs. 114507 build-armhf-xsm 6 xen-buildfail REGR. vs. 114507 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qcow2 1 build-check(1) blocked n/a 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 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-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win10-i386 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-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 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-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 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 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 b
Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths
On 27/10/17 18:42, Igor Druzhinin wrote:
> On 16/02/17 11:15, Jan Beulich wrote:
>> When __context_switch() is being bypassed during original context
>> switch handling, the vCPU "owning" the VMCS partially loses control of
>> it: It will appear non-running to remote CPUs, and hence their attempt
>> to pause the owning vCPU will have no effect on it (as it already
>> looks to be paused). At the same time the "owning" CPU will re-enable
>> interrupts eventually (the lastest when entering the idle loop) and
>> hence becomes subject to IPIs from other CPUs requesting access to the
>> VMCS. As a result, when __context_switch() finally gets run, the CPU
>> may no longer have the VMCS loaded, and hence any accesses to it would
>> fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().
>>
>> Similarly, when __context_switch() is being bypassed also on the second
>> (switch-in) path, VMCS ownership may have been lost and hence needs
>> re-establishing. Since there's no existing hook to put this in, add a
>> new one.
>>
>> Reported-by: Kevin Mayer
>> Reported-by: Anshul Makkar
>> Signed-off-by: Jan Beulich
>> ---
>> v2: Drop the spin loop from vmx_vmc_reload(). Use the function in
>> vmx_do_resume() instead of open coding it there (requiring the
>> ASSERT()s to be adjusted/dropped). Drop the new
>> ->ctxt_switch_same() hook.
>>
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -552,6 +552,20 @@ static void vmx_load_vmcs(struct vcpu *v
>> local_irq_restore(flags);
>> }
>>
>> +void vmx_vmcs_reload(struct vcpu *v)
>> +{
>> +/*
>> + * As we may be running with interrupts disabled, we can't acquire
>> + * v->arch.hvm_vmx.vmcs_lock here. However, with interrupts disabled
>> + * the VMCS can't be taken away from us anymore if we still own it.
>> + */
>> +ASSERT(v->is_running || !local_irq_is_enabled());
>> +if ( v->arch.hvm_vmx.vmcs_pa == this_cpu(current_vmcs) )
>> +return;
>> +
>> +vmx_load_vmcs(v);
>> +}
>> +
>> int vmx_cpu_up_prepare(unsigned int cpu)
>> {
>> /*
>> @@ -1678,10 +1692,7 @@ void vmx_do_resume(struct vcpu *v)
>> bool_t debug_state;
>>
>> if ( v->arch.hvm_vmx.active_cpu == smp_processor_id() )
>> -{
>> -if ( v->arch.hvm_vmx.vmcs_pa != this_cpu(current_vmcs) )
>> -vmx_load_vmcs(v);
>> -}
>> +vmx_vmcs_reload(v);
>> else
>> {
>> /*
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -936,6 +937,18 @@ static void vmx_ctxt_switch_from(struct
>> if ( unlikely(!this_cpu(vmxon)) )
>> return;
>>
>> +if ( !v->is_running )
>> +{
>> +/*
>> + * When this vCPU isn't marked as running anymore, a remote pCPU's
>> + * attempt to pause us (from vmx_vmcs_enter()) won't have a reason
>> + * to spin in vcpu_sleep_sync(), and hence that pCPU might have
>> taken
>> + * away the VMCS from us. As we're running with interrupts disabled,
>> + * we also can't call vmx_vmcs_enter().
>> + */
>> +vmx_vmcs_reload(v);
>> +}
>> +
>> vmx_fpu_leave(v);
>> vmx_save_guest_msrs(v);
>> vmx_restore_host_msrs();
>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
>> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
>> @@ -174,6 +174,7 @@ void vmx_destroy_vmcs(struct vcpu *v);
>> void vmx_vmcs_enter(struct vcpu *v);
>> bool_t __must_check vmx_vmcs_try_enter(struct vcpu *v);
>> void vmx_vmcs_exit(struct vcpu *v);
>> +void vmx_vmcs_reload(struct vcpu *v);
>>
>> #define CPU_BASED_VIRTUAL_INTR_PENDING0x0004
>> #define CPU_BASED_USE_TSC_OFFSETING 0x0008
>>
>
> Hi Jan,
>
> I'm not entirely sure if it's something related but the end result looks
> similar to the issue that this patch solved. We are now getting reports of
> a similar race condition with the following stack trace on 4.7.1 with this
> patch backported but I'm pretty sure this should be the case for master
> as well:
>
> (XEN) [480198.570165] Xen call trace:
> (XEN) [480198.570168][]
> vmx.c#arch/x86/hvm/vmx/vmx.o.unlikely+0x136/0x1a8
> (XEN) [480198.570171][]
> domain.c#__context_switch+0x10c/0x3a4
> (XEN) [480198.570176][] __sync_local_execstate+0x35/0x51
> (XEN) [480198.570179][] invalidate_interrupt+0x40/0x73
> (XEN) [480198.570183][] do_IRQ+0x8c/0x5cb
> (XEN) [480198.570186][] common_interrupt+0x5f/0x70
> (XEN) [480198.570189][] vpmu_destroy+0/0x100
> (XEN) [480198.570192][] vmx.c#vmx_vcpu_destroy+0x21/0x30
> (XEN) [480198.570195][] hvm_vcpu_destroy+0x70/0x77
> (XEN) [480198.570197][] vcpu_destroy+0x5d/0x72
> (XEN) [480198.570201][]
> domain.c#complete_domain_destroy+0x49/0x182
> (XEN) [480198.570204][]
> rcupdate.c#rcu_process_callbacks+0x141/0x1a3
> (XEN) [480198.570207][] softirq.c#__do_softirq+0x75/0x80
> (XEN) [480198.570209][]
> process_pending_softirqs+0xe/0x10
> (XEN) [480198.570212][]
Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator
On Thu, Nov 02, 2017 at 05:49:12PM +, Julien Grall wrote: Hi Julien, > On 02/11/17 16:53, Volodymyr Babchuk wrote: > >On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote: > >>On 24/10/17 20:02, Volodymyr Babchuk wrote: > If it is not safe, this means you have a whitelist solution and > therefore > tie Xen to a specific OP-TEE version. So if you need to use a new > function > you would need to upgrade Xen making the code of using new version > potentially high. > >>>Yes, any ABI change between OP-TEE and its clients will require > >>>mediator > >>>upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if > >>>you'll > >>>install old XEN and new OP-TEE, OP-TEE will use only that subset of > >>>ABI, > >>>which is known to XEN. > >>> > Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means > you > impose anyone wanted to modify OP-TEE for their own purpose can make a > closed version of the TEE. But if you need to introspect/whitelist > call, you > impose the vendor to expose their API. > >>>Basically yes. Is this bad? OP-TEE driver in Linux is licensed under > >>>GPL v2. > >>>If vendor modifies interface between OP-TEE and Linux, they anyways > >>>obligued > >>>to expose API. > >> > >>Pardon me for potential stupid questions, my knowledge of OP-TEE is > >>limited. > >> > >>My understanding is the OP-TEE will provide a generic way to access > >>different Trusted Application. While OP-TEE API may be generic, the TA > >>API > >>is custom. AFAICT the latter is not part of Linux driver. > >Yes, you are perfectly right there. > > > >>So here my questions: > >>1) Are you planning allow all the guests to access every Trusted > >>Applications? > >This is a good question. There are two types of TAs supported in > >OP-TEE: real TAs (as they are described in GlobalPlatform specs) and > >PseudoTAs. The latter ones are statically linked right into OP-TEE > >kernel and execute at S-EL1 level. > >Real TAs are provided by client. That means that NW userspace > >supplicant loads TA into OP-TEE. OP-TEE checks signature for the TA > >and then runs it in S-EL0. > >So, I'm planning to allow client to work with any real TA. I can't see > >real problem there. > > Are the real TAs going to be shared between guests? Or will each guest > have > their own one? > >>>No, we don't plan this. At least at this momoent. Every guest will have > >>>own instance of TA. > >>> > Will you allow every guests loading real TAs? > >>>Yes, if guest has access to TEE, it can load TA. Either there is no > >>>sense to use TEE. OP-TEE core itself does not provide useful services > >>>to clients. > >> > >>In a previous e-mail you mentioned OP-TEE has limited memory. How will you > >>ensure that guest A will not use all the memory of OP-TEE and prevent guest > >>B to load TAs? > >There are no way to do this right now. Even on bare-metal system, one client > >call load huge TA or eat up memory in another way to prevent other clients > >to use OP-TEE. This is known limitation. It can be mitigated by enforcing > >quotas. > > Yes, but those clients only serve one OS. Here you would serve multiple > OSes, clients from OS A could eat up the memory and prevent a client from OS > B to run. > > This could be a serious issue depending on how important the clients for OS > are. > > So likely enforcing quotas will be needed. Yes. I agree there. I think, it is possible to implement them in mediator, so we can use XSM to define quotas. > > > >>[...] > >> > Not really, you could the domain could block when issuing an SMC until the > mediator is up and running. > >>>Do you mean, that if domain tries to execute SMC, and mediator is not > >>>ready, then hypervisor should pause all domain's vCPUs? That can be > >>>destructive for hw domain. > >> > >>Xen is free to unschedule any vCPU at any time. So why would it be > >>destructive? > >Suppose that mediator domain needs 0.5s to boot up and be ready to > >serve calls. For half of a second HW domain will be blocked. I don't > >like the idea, that it will not be able to serve IRQs and other > >requests. IMHO, it is okay for DomU, but not for Dom0. > > > > > >And yes, it seems obvious, but I want to say this explicitly: generic > >TEE mediator framework should and will use XSM to control which > >domain > >can work with TEE. So, if you don't trust your guest - don't let it > >to call TEE at all. > > Correct me if I am wrong. TEE could be used by Android guest which > likely > run the user apps... right? So are you saying you fully trust that > guest and > obviously the user installing rogue app? > >>>I don't think
Re: [Xen-devel] [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen
On 11/01/2017 09:19 PM, Dongli Zhang wrote: > Hi Boris, > > I have received from l...@intel.com that the prior version of patch hit issue > during compilation with aarch64-linux-gnu-gcc. I think this patch reviewed by > you would hit the same compiling issue on arm64 (there is no issue with > x86_64). > > - > > 1st issue: > > Without including header into driver/xen/time.c, compilation on > x86_64 works well (without any warning or error) but arm64 would hit the > following error: > > drivers/xen/time.c: In function ‘xen_manage_runstate_time’: > drivers/xen/time.c:94:20: error: implicit declaration of function > ‘kmalloc_array’ [-Werror=implicit-function-declaration] >runstate_delta = kmalloc_array(num_possible_cpus(), > ^ > > drivers/xen/time.c:131:3: error: implicit declaration of function ‘kfree’ > [-Werror=implicit-function-declaration] >kfree(runstate_delta); >^ > cc1: some warnings being treated as errors > > About the 1st issue, should I submit a new patch including or > just a incremental based on previous patch merged into your own branch > /tree? > > - > > 2nd issue: > > aarch64-linux-gnu-gcc expects a cast for kmalloc_array(). Is this really > necessary as I did find people casting the return type of > kmalloc/kcalloc/kmalloc_array in linux source code (e.g., > drivers/block/virtio_blk.c). Can we just ignore this warning? > > drivers/xen/time.c:94:18: warning: assignment makes pointer from integer > without > a cast [-Wint-conversion] >runstate_delta = kmalloc_array(num_possible_cpus(), > ^ > - That's because you need to declare kmalloc_array(), otherwise the compiler by default assumes that it returns an int. So including linux/slab.h should take care of both warnings. I can add it while committing. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
On 11/02/2017 01:34 PM, George Dunlap wrote: > On 10/27/2017 04:09 PM, NathanStuder wrote: >> >> >> On 10/09/2017 10:14 AM, Lars Kurth wrote: >>> On 27 Sep 2017, at 13:57, Robert VanVossen wrote: On 9/26/2017 3:12 AM, Dario Faggioli wrote: > [Cc-list modified by removing someone and adding someone else] > > On Mon, 2017-09-25 at 16:10 -0700, Stefano Stabellini wrote: >> On Mon, 11 Sep 2017, George Dunlap wrote: >>> +### RTDS based Scheduler >>> + >>> +Status: Experimental >>> + >>> +A soft real-time CPU scheduler built to provide guaranteed CPU >>> capacity to guest VMs on SMP hosts >>> + >>> +### ARINC653 Scheduler >>> + >>> +Status: Supported, Not security supported >>> + >>> +A periodically repeating fixed timeslice scheduler. Multicore >>> support is not yet implemented. >>> + >>> +### Null Scheduler >>> + >>> +Status: Experimental >>> + >>> +A very simple, very static scheduling policy >>> +that always schedules the same vCPU(s) on the same pCPU(s). >>> +It is designed for maximum determinism and minimum overhead >>> +on embedded platforms. >>> >>> ... >>> > Actually, the best candidate for gaining security support, is IMO > ARINC. Code is also rather simple and "stable" (hasn't changed in the > last... years!) and it's used by DornerWorks' people for some of their > projects (I think?). It's also not tested in OSSTest, though, and > considering how special purpose it is, I think we're not totally > comfortable marking it as Sec-Supported, without feedback from the > maintainers. > > George, Josh, Robert? > Yes, we do still use the ARINC653 scheduler. Since it is so simple, it hasn't really needed any modifications in the last couple years. We are not really sure what kind of feedback you are looking from us in regards to marking it sec-supported, but would be happy to try and answer any questions. If you have any specific questions or requests, we can discuss it internally and get back to you. >>> >>> I think there are two sets of issues: one around testing, which Dario >>> outlined. >>> >>> For example, if you had some test harnesses that could be run on Xen >>> release >>> candidates, which verify that the scheduler works as expected, that would >>> help. It would imply a commitment to run the tests on release candidates. >> >> We have an internal Xen test harness that we use to test the scheduler, but I >> assume you would like it converted to use OSSTest instead, so that the >> tests could be integrated into the main test suite someday? > > In our past discussions I don't think anyone has thought the "everything > has to be tested in osstest" strategy is really feasible. So I think we > were going for a model where it just had to be regularly tested > *somewhere*, more or less as a marker for "is this functionality > important enough to people to give security support". > >>> The second question is what happens if someone reported a security issue on >>> the scheduler. The security team would not have the capability to fix >>> issues in >>> the ARINC scheduler: so it would be necessary to pull in an expert under >>> embargo to help triage the issue, fix the issue and prove that the fix >>> works. This >>> would most likely require "the expert" to work to the timeline of the >>> security >>> team (which may require prioritising it over other work), as once a >>> security issue >>> has been reported, the reporter may insist on a disclosure schedule. If we >>> didn't >>> have a fix in time, because we don't get expert bandwidth, we could be >>> forced to >>> disclose an XSA without a fix. >> >> We can support this and have enough staff familiar with the scheduler that >> prioritizing security issues shouldn't be a problem. The maintainers (Robbie >> and Josh) can triage issues if and when the time comes, but if you need a >> more >> dedicated "expert" for this type of issue, then that would likely be me. > > OK -- in that case, if it's OK with you, I'll list ArinC as 'Supported'. We're good with that. Thanks. Nate > > Thanks, > -George > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: support priv-mapping in an HVM tools domain
On 11/02/2017 05:30 AM, Paul Durrant wrote: >> -Original Message- >> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] >> Sent: 01 November 2017 18:19 >> To: Juergen Gross ; Paul Durrant >> ; x...@kernel.org; xen- >> de...@lists.xenproject.org; linux-ker...@vger.kernel.org >> Cc: Thomas Gleixner ; Ingo Molnar >> ; H. Peter Anvin >> Subject: Re: [PATCH v2] xen: support priv-mapping in an HVM tools domain >> >> On 11/01/2017 11:37 AM, Juergen Gross wrote: >>> TBH I like V1 better, too. >>> >>> Boris, do you feel strong about the #ifdef part? >> Having looked at what this turned into I now like V1 better too ;-) >> >> Sorry, Paul. > That's ok. Are you happy with v1 as-is or do you want me to submit a v3 with > any tweaks? V1: Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 115497: regressions - FAIL
flight 115497 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 115490
test-amd64-amd64-xl-qemuu-debianhvm-i386 13 guest-saverestore fail REGR. vs.
115490
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 14 saverestore-support-checkfail never pass
version targeted for testing:
xen 29028ed8db226ad3b7bc576c1e8891983acaa3ff
baseline version:
xen ff93dc55431517ed29c70dbff6721c6b0803acf9
Last test of basis 115490 2017-11-02 17:01:26 Z0 days
Testing same since 115497 2017-11-02 20:01:37 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Julien Grall
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
test-amd64-amd64-libvirt fail
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 29028ed8db226ad3b7bc576c1e8891983acaa3ff
Merge: 9ff6dbf ff93dc5
Author: Wei Liu
Date: Thu Nov 2 17:07:58 2017 +
Merge remote-tracking branch 'origin/staging' into staging
commit 9ff6dbfa7576cc1c5d6f9a3c59c69a8503e36f11
Author: Andrew Cooper
Date: Thu Oct 12 20:19:09 2017 +0100
tools/dombuilder: Prevent failures of xc_dom_gnttab_init()
Recent changes in grant table configuration have caused calls to
xc_dom_gnttab_init() to fail if not proceeded with a call to
xc_domain_set_gnttab_limits(). This is backwards from the point of view of
3rd party dombuilder users.
Add max_{grant,maptrack}_frames parameters to struct xc_dom_image, and
require
them to be set by callers using xc_dom_gnttab_init(). Libxl, which uses
xc_dom_gnttab_init() itself is updated appropriately.
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
Tested-by: Julien Grall
Reviewed-by: Juergen Gross
Release-acked-by: Julien Grall
commit 87b0ae7e8277d2fa13486ce2e11a941e55f8df40
Author: Andrew Cooper
Date: Thu Oct 12 20:19:08 2017 +0100
tools/dombuilder: Fix asymmetry when setting up console and xenstore rings
libxl always uses xc_dom_gnttab_init(), which internally calls
xc_dom_gnttab{_hvm,}_seed() to set up the grants point at the console and
xenstore rings. For HVM guests, libxl then asks Xen for the information set
up previously, and calls xc_dom_gnttab_hvm_seed() a second time, which is
wasteful. ARM construction expects libxl to have set up
dom->{console,xenstore}_evtchn earlier, so only actually functions because
of
this second call.
Rationalise everything and make it consistent for all guests.
1) Users of the domain builder are expected to provide
dom->{console,xenstore}_{evtchn,domid} unconditionally. This is checked
by setting invalid values in xc_dom_allocate(), and checking in
xc_dom_boot_image().
2) For x86 HVM and ARM guests, the event channels are given to Xen at the
same time as the ring gfns. ARM already did this, but x86 is updated to
match. x86 PV already provides this information in the start_info page.
3) Libxl is updated to drop all relevant functionality from
hvm_build_set_params(), and behave consistently with PV guests when it
comes to the handling of dom->{console,xenstore}_{evtchn,domid,gfn}.
This removes several redundant hypercalls (including a foreign mapping) from
the x86 HVM and ARM construction paths.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
Tested-by: Julien Grall
Release-acked-by: Julien Grall
commit f48b5449dabc770acdde6d25cfbd265cfb71034
[Xen-devel] [xen-unstable baseline-only test] 72405: regressions - FAIL
This run is configured for baseline tests only. flight 72405 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72405/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow219 guest-start/debian.repeat fail REGR. vs. 72329 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 72329 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail baseline untested test-armhf-armhf-examine 11 examine-serial/bootloaderfail like 72329 test-armhf-armhf-examine 12 examine-serial/kernelfail like 72329 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 72329 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 72329 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 72329 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 72329 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 72329 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail like 72329 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 72329 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 72329 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 72329 test-amd64-amd64-examine 4 memdisk-try-append fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass version targeted for testing: xen bb2c1a1cc98a22e2d4c14b18421aa7be6c2adf0d baseline version: xen 24fb44e971a62b345c7b6ca3c03b454a1e150abe Last test of basis72329 2017-10-18 09:48:41 Z 15 days Testing same since72405 2017-11-02 13:45:47 Z0 days1 attempts People who touched revisions under test: Andre Przywara Andrew Cooper Anthony PERARD Bhupinder Thakur Boris Ostrovsky Chao Gao David Esler George Dunlap Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monne Roger Pau Monné Ross Lager
[Xen-devel] [PATCH] xen/time: Return -ENODEV from xen_get_wallclock()
For any other error sync_cmos_clock() will reschedule itself
every second or so, for no good reason.
Suggested-by: Paolo Bonzini
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 1ecb05d..244791f 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -74,7 +74,7 @@ static void xen_get_wallclock(struct timespec *now)
static int xen_set_wallclock(const struct timespec *now)
{
- return -1;
+ return -ENODEV;
}
static int xen_pvclock_gtod_notify(struct notifier_block *nb,
--
2.7.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen
Hi Boris, On 11/03/2017 04:28 AM, Boris Ostrovsky wrote: > On 11/01/2017 09:19 PM, Dongli Zhang wrote: >> Hi Boris, >> >> I have received from l...@intel.com that the prior version of patch hit issue >> during compilation with aarch64-linux-gnu-gcc. I think this patch reviewed by >> you would hit the same compiling issue on arm64 (there is no issue with >> x86_64). >> >> - >> >> 1st issue: >> >> Without including header into driver/xen/time.c, compilation >> on >> x86_64 works well (without any warning or error) but arm64 would hit the >> following error: >> >> drivers/xen/time.c: In function ‘xen_manage_runstate_time’: >> drivers/xen/time.c:94:20: error: implicit declaration of function >> ‘kmalloc_array’ [-Werror=implicit-function-declaration] >>runstate_delta = kmalloc_array(num_possible_cpus(), >> ^ >> >> drivers/xen/time.c:131:3: error: implicit declaration of function ‘kfree’ >> [-Werror=implicit-function-declaration] >>kfree(runstate_delta); >>^ >> cc1: some warnings being treated as errors >> >> About the 1st issue, should I submit a new patch including or >> just a incremental based on previous patch merged into your own branch >> /tree? >> >> - >> >> 2nd issue: >> >> aarch64-linux-gnu-gcc expects a cast for kmalloc_array(). Is this really >> necessary as I did find people casting the return type of >> kmalloc/kcalloc/kmalloc_array in linux source code (e.g., >> drivers/block/virtio_blk.c). Can we just ignore this warning? >> >> drivers/xen/time.c:94:18: warning: assignment makes pointer from integer >> without >> a cast [-Wint-conversion] >>runstate_delta = kmalloc_array(num_possible_cpus(), >> ^ >> - > > That's because you need to declare kmalloc_array(), otherwise the > compiler by default assumes that it returns an int. So including > linux/slab.h should take care of both warnings. > > I can add it while committing. Please help add it while committing. Thank you very much for your help! > > > -boris > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel > Dongli Zhang ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
