Re: [Xen-devel] [PATCH v2] x86/hvm: Allow the guest to permit the use of userspace hypercalls
>>> On 11.01.16 at 17:51, wrote:
> Currently, hypercalls issued from HVM userspace will unconditionally fail
> with
> -EPERM.
>
> This is inflexible, and a guest may wish to allow userspace to make
> hypercalls.
>
> Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the
> permissions check for hypercalls. It behaves exactly like the dpl field for
> GDT/LDT/IDT entries.
>
> As the dpl is initialised to 0, hypercalls are restricted to cpl0 code until
> the OS explicitly chooses an alternative.
>
> Signed-off-by: Andrew Cooper
> --
> CC: Jan Beulich
> CC: Ian Campbell
> CC: Stefano Stabellini
>
> v2:
> * Fix rcu lock and dpl check.
That's a bold statement considering ...
> @@ -6839,6 +6840,31 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> rc = do_altp2m_op(arg);
> break;
>
> +case HVMOP_set_hypercall_dpl:
> +{
> +xen_hvm_hypercall_dpl_t a;
> +struct domain *d;
> +
> +if ( copy_from_guest(&a, arg, 1 ) )
> +return -EFAULT;
> +
> +d = rcu_lock_domain_by_any_id(a.domid);
> +if ( d == NULL )
> +return -ESRCH;
> +
> +if ( current->domain != d )
> +return -EPERM;
> +
> +if ( !is_hvm_domain(d) )
> +return -EINVAL;
> +
> +if ( a.dpl > 3 )
> +return -EDOM;
> +
> +d->arch.hvm_domain.hypercall_dpl = a.dpl;
> +break;
> +}
... there's no unlock anywhere here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 77825: regressions - FAIL
flight 77825 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/77825/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543 version targeted for testing: ovmf 819a2394f17f6e4e97893481e4acb95401e7b380 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 34 days Failing since 65593 2015-12-08 23:44:51 Z 34 days 20 attempts Testing same since77825 2016-01-11 11:52:35 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Yao, Jiewen" Andrew Fish Ard Biesheuvel Cecil Sheng Chao Zhang Dandan Bi Daocheng Bu Daryl McDaniel Eric Dong Eric Dong Eugene Cohen Feng Tian Fu Siyuan Hao Wu Hess Chen Heyi Guo Jaben Carsey Jeff Fan Jiaxin Wu Jim Dailey Jordan Justen Larry Hauch Laszlo Ersek Leekha Shaveta Liming Gao Mark Rutland Michael Kinney Michael Thomas Paulo Alcantara Qin Long Qiu Shumin Ruiyu Ni Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Star Zeng Tapan Shah Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zhang Lubo jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.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. (No revision log; it would be 4855 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] build: introduce CONFIG_NR_CPUS in Kconfig
>>> On 11.01.16 at 23:02, wrote: > --- /dev/null > +++ b/xen/arch/Kconfig > @@ -0,0 +1,8 @@ > + > +config NR_CPUS > + int "Maximum number of physical CPUs" > + range 1 65536 Why did you change this to 64k, when we settled on 4k-1 being correct? I don't mind fixing this up upon commit, but I'd like it to be confirmed that this was unintentional. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] build: convert NR_CPUS to Kconfig
>>> On 11.01.16 at 23:02, wrote: > --- a/xen/include/xen/config.h > +++ b/xen/include/xen/config.h > @@ -92,4 +92,7 @@ > #define FLASK_AVC_STATS 1 > #endif > > +/* allow existing code to work with Kconfig variable */ > +#define NR_CPUS CONFIG_NR_CPUS Perhaps here or in a follow-up patch derive CONFIG_SMP (used in a few places in ARM code) from NR_CPUS > 1? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
Yes, Linux VM update to a 3.18 kernel. The RHEL7.2 default kernel (should be 3.10) VM don't boot up with IGD pass-through, and Windows can't boot up either. Thanks, -Xudong > -Original Message- > From: Gerd Hoffmann [mailto:kra...@redhat.com] > Sent: Monday, January 11, 2016 6:32 PM > To: Hao, Xudong > Cc: Stefano Stabellini ; Lars Kurth > ; xen-de...@lists.xensource.com; Michael S. Tsirkin > ; Lars Kurth ; qemu- > de...@nongnu.org; Cao jin ; Stefano Stabellini > > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > convert to realize() > > Hi, > > > I can boot up Linux VM with IGD pass-through with latest qemu (without > > any additional patch), guest run 3D "nexuiz" and get 180fps. > > That is a pretty recent linux guest I assume? > Tried older kernels too, possibly even the old userspace xorg driver? > Do windows guest work as well? > > cheers, > Gerd ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote: > On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > >On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > >smp_read_barrier_depends, smp_store_release and smp_load_acquire match > >the asm-generic variants exactly. Drop the local definitions and pull in > >asm-generic/barrier.h instead. > > > This statement doesn't fit MIPS barriers variations. Moreover, there is a > reason to extend that even more specific, at least for smp_store_release and > smp_load_acquire, look into > > http://patchwork.linux-mips.org/patch/10506/ > > - Leonid. Fine, but it matches what current code is doing. Since that MIPS_LIGHTWEIGHT_SYNC patch didn't go into linux-next yet, do you see a problem reworking it on top of this patchset? -- MST ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
OK - it's possible that this patch commit 349a3b1cc9023f67f8fa336cb3c4a8f21a4aaaf3 Author: Cao jin Date: Sat Jan 2 16:02:20 2016 +0800 igd-passthrough: fix use of host_pci_config_read is required for older guests. This patch just went it - could you test latest master please? On Tue, Jan 12, 2016 at 08:41:13AM +, Hao, Xudong wrote: > Yes, Linux VM update to a 3.18 kernel. > The RHEL7.2 default kernel (should be 3.10) VM don't boot up with IGD > pass-through, and Windows can't boot up either. > > Thanks, > -Xudong > > > > -Original Message- > > From: Gerd Hoffmann [mailto:kra...@redhat.com] > > Sent: Monday, January 11, 2016 6:32 PM > > To: Hao, Xudong > > Cc: Stefano Stabellini ; Lars Kurth > > ; xen-de...@lists.xensource.com; Michael S. Tsirkin > > ; Lars Kurth ; qemu- > > de...@nongnu.org; Cao jin ; Stefano Stabellini > > > > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > > convert to realize() > > > > Hi, > > > > > I can boot up Linux VM with IGD pass-through with latest qemu (without > > > any additional patch), guest run 3D "nexuiz" and get 180fps. > > > > That is a pretty recent linux guest I assume? > > Tried older kernels too, possibly even the old userspace xorg driver? > > Do windows guest work as well? > > > > cheers, > > Gerd > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Nested virtualization off VMware vSphere 6.0 with EL6 guests crashes on Xen 4.6
>>> On 12.01.16 at 04:38, wrote: > (XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698 > (XEN) [ Xen-4.6.0 x86_64 debug=y Tainted:C ] > (XEN) CPU:39 > (XEN) RIP:e008:[] virtual_vmentry+0x487/0xac9 > (XEN) RFLAGS: 00010246 CONTEXT: hypervisor (d1v3) > (XEN) rax: rbx: 83007786c000 rcx: > (XEN) rdx: 0e00 rsi: 000f rdi: 83407f81e010 > (XEN) rbp: 834008a47ea8 rsp: 834008a47e38 r8: > (XEN) r9: r10: r11: > (XEN) r12: r13: 82c000341000 r14: 834008a47f18 > (XEN) r15: 83407f7c4000 cr0: 80050033 cr4: 001526e0 > (XEN) cr3: 00407fb22000 cr2: > (XEN) ds: es: fs: gs: ss: cs: e008 > (XEN) Xen stack trace from rsp=834008a47e38: > (XEN)834008a47e68 82d0801d2cde 834008a47e68 0d00 > (XEN) 834008a47e88 0004801cc30e > (XEN)83007786c000 83007786c000 834008a4 > (XEN)834008a47f18 834008a47f08 82d0801edf94 > (XEN)834008a47ef8 834008f62000 834008a47f18 > (XEN)00ae8c99eb8d 83007786c000 > (XEN) 82d0801ee2ab > (XEN) > (XEN) > (XEN) > (XEN)078bfbff beefbeef > (XEN)fc4b3440 00bfbeef 00040046 fc607f00 > (XEN)beef beef beef beef > (XEN)beef 0027 83007786c000 006f88716300 > (XEN) > (XEN) Xen call trace: > (XEN)[] virtual_vmentry+0x487/0xac9 > (XEN)[] nvmx_switch_guest+0x8ff/0x915 > (XEN)[] vmx_asm_vmexit_handler+0x4b/0xc0 > (XEN) > (XEN) > (XEN) > (XEN) Panic on CPU 39: > (XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698 > (XEN) > (XEN) > > ..and then to my surprise the hypervisor stopped hitting this. Since we can (I hope) pretty much exclude a paging type, the ASSERT() must have triggered because of vapic_pg being NULL. That might be verifiable without extra printk()s, just by checking the disassembly (assuming the value sits in a register). In which case vapic_gpfn would be of interest too. What looks odd to me is the connection between CPU_BASED_TPR_SHADOW being set and the use of a (valid) virtual APIC page: Wouldn't this rather need to depend on SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES, just like in nvmx_update_apic_access_address()? Anyway, the writing of the respective VMCS field to zero in the alternative worries me a little: Aren't we risking MFN zero to be wrongly accessed due to this? Furthermore, nvmx_update_apic_access_address() having a similar ASSERT() seems entirely wrong: The APIC access page doesn't really need to match up with any actual page belonging to the guest - a guest could choose to point this into no-where (note that we've been at least considering this option recently for our own purposes, in the context of http://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02191.html). > Instead I started getting an even more bizzare crash: > > > (d1) enter handle_19: > (d1) NULL > (d1) Booting from Hard Disk... > (d1) Booting from :7c00 > (XEN) stdvga.c:151:d1v0 leaving stdvga mode > (XEN) stdvga.c:147:d1v0 entering stdvga and caching modes > (XEN) stdvga.c:520:d1v0 leaving caching mode > (XEN) [ Xen-4.6.0 x86_64 debug=y Tainted:C ] > (XEN) CPU:3 > (XEN) RIP:e008:[] vmx_cpu_up+0xacc/0xba5 > (XEN) RFLAGS: 00010242 CONTEXT: hypervisor (d1v1) > (XEN) rax: rbx: 830077877000 rcx: 834077e54000 > (XEN) rdx: 834007dc8000 rsi: 2000 rdi: 830077877000 > (XEN) rbp: 834007dcfc48 rsp: 834007dcfc38 r8: 0404 > (XEN) r9: 000ff000 r10: r11: fc423f1e > (XEN) r12: 2000 r13: r14: > (XEN) r15: cr0: 80050033 cr4: 001526e0 > (XEN) cr3: 004000763000 cr2: > (XEN) ds: es: fs: gs: ss: cs: e008 > (XEN) Xen stack trace from rsp=834007dcfc38: > (XEN)834007dcfc98 834007dcfc68 82d0801e2533 > (XEN)830077877000 2000 834007dcfc78 82d0801ea933 > (XEN)834007dcfca8 f
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote: > This statement doesn't fit MIPS barriers variations. Moreover, there is a > reason to extend that even more specific, at least for smp_store_release and > smp_load_acquire, look into > > http://patchwork.linux-mips.org/patch/10506/ Dude, that's one horrible patch. 1) you do not make such things selectable; either the hardware needs them or it doesn't. If it does you _must_ use them, however unlikely. 2) the changelog _completely_ fails to explain the sync 0x11 and sync 0x12 semantics nor does it provide a publicly accessible link to documentation that does. 3) it really should have explained what you did with smp_llsc_mb/smp_mb__before_llsc() in _detail_. And I agree that ideally it should be split into parts. Seriously, this is _NOT_ OK. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't boot up with IGD. Thanks, -Xudong > -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Tuesday, January 12, 2016 4:48 PM > To: Hao, Xudong > Cc: Gerd Hoffmann ; Stefano Stabellini > ; Lars Kurth ; xen- > de...@lists.xensource.com; Lars Kurth ; qemu- > de...@nongnu.org; Cao jin ; Stefano Stabellini > > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > convert to realize() > > OK - it's possible that this patch > commit 349a3b1cc9023f67f8fa336cb3c4a8f21a4aaaf3 > Author: Cao jin > Date: Sat Jan 2 16:02:20 2016 +0800 > > igd-passthrough: fix use of host_pci_config_read > > is required for older guests. > This patch just went it - could you test latest master please? > > On Tue, Jan 12, 2016 at 08:41:13AM +, Hao, Xudong wrote: > > Yes, Linux VM update to a 3.18 kernel. > > The RHEL7.2 default kernel (should be 3.10) VM don't boot up with IGD pass- > through, and Windows can't boot up either. > > > > Thanks, > > -Xudong > > > > > > > -Original Message- > > > From: Gerd Hoffmann [mailto:kra...@redhat.com] > > > Sent: Monday, January 11, 2016 6:32 PM > > > To: Hao, Xudong > > > Cc: Stefano Stabellini ; Lars > > > Kurth ; xen-de...@lists.xensource.com; > > > Michael S. Tsirkin ; Lars Kurth > > > ; qemu- de...@nongnu.org; Cao jin > > > ; Stefano Stabellini > > > > > > Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > > > convert to realize() > > > > > > Hi, > > > > > > > I can boot up Linux VM with IGD pass-through with latest qemu > > > > (without any additional patch), guest run 3D "nexuiz" and get 180fps. > > > > > > That is a pretty recent linux guest I assume? > > > Tried older kernels too, possibly even the old userspace xorg driver? > > > Do windows guest work as well? > > > > > > cheers, > > > Gerd > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 12, 2016 at 10:43:36AM +0200, Michael S. Tsirkin wrote: > On Mon, Jan 11, 2016 at 05:14:14PM -0800, Leonid Yegoshin wrote: > > On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > > >On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > > >smp_read_barrier_depends, smp_store_release and smp_load_acquire match > > >the asm-generic variants exactly. Drop the local definitions and pull in > > >asm-generic/barrier.h instead. > > > > > This statement doesn't fit MIPS barriers variations. Moreover, there is a > > reason to extend that even more specific, at least for smp_store_release and > > smp_load_acquire, look into > > > > http://patchwork.linux-mips.org/patch/10506/ > > > > - Leonid. > > Fine, but it matches what current code is doing. Since that > MIPS_LIGHTWEIGHT_SYNC patch didn't go into linux-next yet, do > you see a problem reworking it on top of this patchset? That patch is a complete doorstop atm. It needs a lot more work before it can go anywhere. Don't worry about it. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
> -Original Message- > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > Sent: Monday, January 11, 2016 6:46 PM > To: Hao, Xudong > Cc: Stefano Stabellini ; Lars Kurth > ; Lars Kurth ; Cao jin > ; xen-de...@lists.xensource.com; Stefano Stabellini > ; qemu-de...@nongnu.org; Michael S. Tsirkin > > Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to > realize() > > On Mon, 11 Jan 2016, Hao, Xudong wrote: > > Stefano, > > > > Patch http://marc.info/?l=qemu-devel&m=145137863501079 don't works for > qemu at all, some conflict when git apply. > > Patch http://marc.info/?l=qemu-devel&m=145137863501079 is based on > patch http://marc.info/?l=qemu-devel&m=145172165010604, right? > > > > I can boot up Linux VM with IGD pass-through with latest qemu (without any > additional patch), guest run 3D "nexuiz" and get 180fps. > > Very interesting, thanks for testing. > The Linux VM's kernel is 3.18. > > > Will try the two patch together later. > > That would be useful > With the two patch, Linux VM (with 3.18) boot up successfully. RHEL7.2(default kernel 3.10) and Windows8.1 VM boot up fail with IGD pass-through. The result is same w/o these two patches. > > > > -Original Message- > > > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com] > > > Sent: Friday, January 8, 2016 7:57 PM > > > To: Hao, Xudong > > > Cc: Stefano Stabellini ; Lars > > > Kurth ; Lars Kurth > > > ; Cao jin ; > > > xen-de...@lists.xensource.com; Stefano Stabellini > > > ; qemu-de...@nongnu.org; Michael S. > > > Tsirkin > > > Subject: RE: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert > > > to realize() > > > > > > Since you are at it, could you please let me know how well igd > > > passthrough works without this bugfix: > > > > > > http://marc.info/?l=qemu-devel&m=145172165010604 > > > > > > which is about to land in QEMU. I guess it doesn't work at all? > > > > > > I am asking because I would like to know the level of support we > > > need to provide to igd passthrough with the latest QEMU release (2.5). > > > > > > > > > On Thu, 7 Jan 2016, Hao, Xudong wrote: > > > > Sure. I'll test it soon. > > > > > > > > Thanks, > > > > -Xudong > > > > > > > > > -Original Message- > > > > > From: Stefano Stabellini > > > > > [mailto:stefano.stabell...@eu.citrix.com] > > > > > Sent: Wednesday, January 6, 2016 8:18 PM > > > > > To: Lars Kurth > > > > > Cc: Stefano Stabellini ; Hao, > > > > > Xudong ; Lars Kurth > > > > > ; Cao jin ; > > > > > xen-de...@lists.xensource.com; Stefano Stabellini > > > > > ; qemu-de...@nongnu.org; Michael > > > > > S. Tsirkin > > > > > Subject: Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: > > > > > convert to realize() > > > > > > > > > > Hello Xudong, > > > > > > > > > > please test this patch: > > > > > > > > > > http://marc.info/?l=qemu-devel&m=145137863501079 > > > > > > > > > > with an intel graphic card assigned to a Xen guest. If > > > > > everything still works as expected, please reply with your Tested-by. > > > > > > > > > > Thanks, > > > > > > > > > > Stefano > > > > > > > > > > On Wed, 6 Jan 2016, Lars Kurth wrote: > > > > > > Hi folks, > > > > > > let me introduce you to Xudong from Intel, who is willing to help > > > > > > out. > > > > > > Best Regards > > > > > > Lars > > > > > > > > > > > > > On 4 Jan 2016, at 15:41, Stefano Stabellini > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > On Mon, 4 Jan 2016, Lars Kurth wrote: > > > > > > >> On 04/01/2016 14:47, "Stefano Stabellini" > > > > > > >> wrote: > > > > > > >> > > > > > > >>> Unfortunately I don't have a setup to test this either. > > > > > > >>> Maybe Lars can find out who should be involved on the Intel side > on this. > > > > > > >> > > > > > > >> I can certainly help to this and get back to you. What > > > > > > >> exactly are we asking Intel to do? > > > > > > >> It is not clear to me from this email thread > > > > > > > > > > > > > > Tiejun Chen, the author of the Intel graphic card > > > > > > > passthrough patches for QEMU, seems to have left the > > > > > > > company. It would be nice if somebody else tested this patch > > > > > > > with an intel graphic card assigned to a guest VM. > > > > > > > > > > > > > > ___ > > > > > > > Xen-devel mailing list > > > > > > > Xen-devel@lists.xen.org > > > > > > > http://lists.xen.org/xen-devel > > > > > > > > > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 2/2] public/io/netif.h: document control ring and toeplitz hashing
> -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 11 January 2016 16:05 > To: xen-de...@lists.xenproject.org > Cc: Paul Durrant; Ian Campbell; Ian Jackson; Jan Beulich; Keir (Xen.org); Tim > (Xen.org) > Subject: [PATCH v6 2/2] public/io/netif.h: document control ring and toeplitz > hashing > > This patch documents a new shared ring between frontend and backend that > can be used to pass bulk out-of-band data, such as that required to > implement toeplitz hashing in the backend such that it is configurable by > the frontend (which is needed to support NDIS RSS for Windows guests). > > The patch then goes on to document the messages passed over the control > ring that can be used to configure toeplitz hashing and a new extra info > fragment that can be used to pass hash values between frontend and > backend for both transmit and receive packets. > > Signed-off-by: Paul Durrant > Cc: Ian Campbell > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Keir Fraser > Cc: Tim Deegan > --- > v5: > - Clarify the control API for toeplitz hashing in many places. > - Add messages for getting and setting mapping table order to allow >for a table that is larger than can be mapped by a single grant >reference. > - Fold in the definition of the new extra info type for passing >hash values and make it toeplitz specific. > > v4: > - Fix netif_ctrl_response_t definition to match specification. > > v3: > - Fix commit comment. > > v2: > - Use a balanced fix-sized message ring for the control ring >(bulk data now passed by grant reference). > --- > xen/include/public/io/netif.h | 380 > +- > 1 file changed, 379 insertions(+), 1 deletion(-) > > diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h > index 0a3272f..e437d6d 100644 > --- a/xen/include/public/io/netif.h > +++ b/xen/include/public/io/netif.h > @@ -151,6 +151,361 @@ > */ > > /* > + * Control ring > + * > + * > + * Some features, such as toeplitz hashing (detailed below), require a > + * significant amount of out-of-band data to be passed from frontend to > + * backend. Use of xenstore is not suitable for large quantities of data > + * because of quota limitations and so a dedicated 'control ring' is used. > + * The ability of the backend to use a control ring is advertised by > + * setting: > + * > + * /local/domain/X/backend///feature-control-ring = "1" I noticed this isn't consistent with the abbreviation of 'control' to 'ctrl' below so I'll change it. Paul > + * > + * The frontend provides a control ring to the backend by setting: > + * > + * /local/domain//device/vif//ctrl-ring-ref = > + * /local/domain//device/vif//event-channel-ctrl = > + * > + * where is the grant reference of the shared page used to > + * implement the control ring and is an event channel to be used > + * as a mailbox interrupt. These keys must be set before the frontend > + * moves into the connected state. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 0/2] public/io/netif.h: support for toeplitz hashing
This series documents changes needed to support toeplitz hashing in a backend, configurable by the frontend. Patch #1 adds further clarifications to the receive and transmit wire formats. Patch #2 documents a new 'control ring' for passing bulk data between frontend and backend. This is needed for passing the hash mapping table and hash key. It also documents messages to allow a frontend to configure toeplitz hashing and a new extra info segment that can be used for passing hash values along with packets on both the transmit and receive side. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 2/2] public/io/netif.h: document control ring and toeplitz hashing
This patch documents a new shared ring between frontend and backend that can be used to pass bulk out-of-band data, such as that required to implement toeplitz hashing in the backend such that it is configurable by the frontend (which is needed to support NDIS RSS for Windows guests). The patch then goes on to document the messages passed over the control ring that can be used to configure toeplitz hashing and a new extra info fragment that can be used to pass hash values between frontend and backend for both transmit and receive packets. Signed-off-by: Paul Durrant Cc: Ian Campbell Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan --- v7: - s/feature-control-ring/feature-ctrl-ring/g for consistency v5: - Clarify the control API for toeplitz hashing in many places. - Add messages for getting and setting mapping table order to allow for a table that is larger than can be mapped by a single grant reference. - Fold in the definition of the new extra info type for passing hash values and make it toeplitz specific. v4: - Fix netif_ctrl_response_t definition to match specification. v3: - Fix commit comment. v2: - Use a balanced fix-sized message ring for the control ring (bulk data now passed by grant reference). --- xen/include/public/io/netif.h | 380 +- 1 file changed, 379 insertions(+), 1 deletion(-) diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h index 0a3272f..fe0a87f 100644 --- a/xen/include/public/io/netif.h +++ b/xen/include/public/io/netif.h @@ -151,6 +151,361 @@ */ /* + * Control ring + * + * + * Some features, such as toeplitz hashing (detailed below), require a + * significant amount of out-of-band data to be passed from frontend to + * backend. Use of xenstore is not suitable for large quantities of data + * because of quota limitations and so a dedicated 'control ring' is used. + * The ability of the backend to use a control ring is advertised by + * setting: + * + * /local/domain/X/backend///feature-ctrl-ring = "1" + * + * The frontend provides a control ring to the backend by setting: + * + * /local/domain//device/vif//ctrl-ring-ref = + * /local/domain//device/vif//event-channel-ctrl = + * + * where is the grant reference of the shared page used to + * implement the control ring and is an event channel to be used + * as a mailbox interrupt. These keys must be set before the frontend + * moves into the connected state. + * + * The control ring uses a fixed request/response message size and is + * balanced (i.e. one request to one response), so operationally it is much + * the same as a transmit or receive ring. + * Note that there is no requirement that responses are issued in the same + * order as requests. + */ + +/* + * Toeplitz hash types + * === + * + * For the purposes of the definitions below, 'Packet[]' is an array of + * octets containing an IP packet without options, 'Array[X..Y]' means a + * sub-array of 'Array' containing bytes X thru Y inclusive, and '+' is + * used to indicate concatenation of arrays. + */ + +/* + * A hash calculated over an IP version 4 header as follows: + * + * Buffer[0..8] = Packet[12..15] (source address) + + *Packet[16..19] (destination address) + * + * Result = ToeplitzHash(Buffer, 8) + */ +#define _NETIF_CTRL_TOEPLITZ_HASH_IPV4 0 +#define NETIF_CTRL_TOEPLITZ_HASH_IPV4 (1 << _NETIF_CTRL_TOEPLITZ_HASH_IPV4) + +/* + * A hash calculated over an IP version 4 header and TCP header as + * follows: + * + * Buffer[0..12] = Packet[12..15] (source address) + + * Packet[16..19] (destination address) + + * Packet[20..21] (source port) + + * Packet[22..23] (destination port) + * + * Result = ToeplitzHash(Buffer, 12) + */ +#define _NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP 1 +#define NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP (1 << _NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP) + +/* + * A hash calculated over an IP version 6 header as follows: + * + * Buffer[0..32] = Packet[8..23] (source address ) + + * Packet[24..39] (destination address) + * + * Result = ToeplitzHash(Buffer, 32) + */ +#define _NETIF_CTRL_TOEPLITZ_HASH_IPV6 2 +#define NETIF_CTRL_TOEPLITZ_HASH_IPV6 (1 << _NETIF_CTRL_TOEPLITZ_HASH_IPV4) + +/* + * A hash calculated over an IP version 6 header and TCP header as + * follows: + * + * Buffer[0..36] = Packet[8..23] (source address) + + * Packet[24..39] (destination address) + + * Packet[40..41] (source port) + + * Packet[42..43] (destination port) + * + * Result = ToeplitzHash(Buffer, 36) + */ +#define _NETIF_CTRL_TOEPLITZ_HASH_IPV6_TCP 3 +#define NETIF_CTRL_TOEPLITZ_HASH_IPV6_TCP (1 << _NETIF_CTRL_TOEPLITZ_HASH_IPV4_TCP) + +/* + * Control requests (netif_ctrl_request_t) + * === + * + * All requests have the following format: + * + *0 1 2
[Xen-devel] [PATCH v7 1/2] public/io/netif.h: clarifications to wire formats
My previous patch 03809ae7 "document transmit and receive wire formats separately" improved documentation of the receive and transmit wire formats but further clarifications were requested. This patch adds those clarifications. Signed-off-by: Paul Durrant Cc: Ian Campbell Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan --- v6: - v4 of the original patch was committed so this is an incremental version of the patch in v5. v5: - Add extra clarifications. --- xen/include/public/io/netif.h | 28 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h index 1790ea0..0a3272f 100644 --- a/xen/include/public/io/netif.h +++ b/xen/include/public/io/netif.h @@ -154,19 +154,29 @@ * Guest transmit * == * - * This is the 'wire' format for packets: + * This is the 'wire' format for transmit (frontend -> backend) packets: + * * Fragment 1: netif_tx_request_t - flags = NETTXF_* *size = total packet size * [Extra 1: netif_extra_info_t]- (only if fragment 1 flags include * NETTXF_extra_info) + * ... * [Extra N: netif_extra_info_t]- (only if extra N-1 flags include * XEN_NETIF_EXTRA_MORE) * ... * Fragment N: netif_tx_request_t - (only if fragment N-1 flags include - * NETTXF_more_data) + * NETTXF_more_data - flags on preceding + * extras are not relevent here) *flags = 0 *size = fragment size * + * NOTE: + * + * This format slightly is different from that used for receive + * (backend -> frontend) packets. Specifically, in a multi-fragment + * packet the actual size of fragment 1 can only be determined by + * subtracting the sizes of fragments 2..N from the total packet size. + * * Ring slot size is 12 octets, however not all request/response * structs use the full size. * @@ -202,19 +212,29 @@ * Guest receive * = * - * This is the 'wire' format for packets: + * This is the 'wire' format for receive (backend -> frontend) packets: + * * Fragment 1: netif_rx_request_t - flags = NETRXF_* *size = fragment size * [Extra 1: netif_extra_info_t]- (only if fragment 1 flags include * NETRXF_extra_info) + * ... * [Extra N: netif_extra_info_t]- (only if extra N-1 flags include * XEN_NETIF_EXTRA_MORE) * ... * Fragment N: netif_rx_request_t - (only if fragment N-1 flags include - * NETRXF_more_data) + * NETRXF_more_data - flags on preceding + * extras are not relevent here) *flags = 0 *size = fragment size * + * NOTE: + * + * This format slightly is different from that used for transmit + * (frontend -> backend) packets. Specifically, in a multi-fragment + * packet the size of the packet can only be determined by summing the + * sizes of fragments 1..N. + * * Ring slot size is 8 octets. * * rx request (netif_rx_request_t) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2
This went unnoticed until a backport of this to an older Xen got used,
causing migration of guests enabling this VM assist to fail, because
page table pinning there preceeds vCPU context loading, and hence L4
tables get initialized for the wrong mode. Fix this by post-processing
L4 tables when setting the intended VM assist flags for the guest.
Note that this leaves in place a dependency on vCPU 0 getting its guest
context restored first, but afaict the logic here is not the only thing
depending on that.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1067,8 +1067,48 @@ int arch_set_info_guest(
goto out;
if ( v->vcpu_id == 0 )
+{
d->vm_assist = c(vm_assist);
+/*
+ * In the restore case we need to deal with L4 pages which got
+ * initialized with m2p_strict still clear (and which hence lack the
+ * correct initial RO_MPT_VIRT_{START,END} L4 entry).
+ */
+if ( d != current->domain && VM_ASSIST(d, m2p_strict) &&
+ is_pv_domain(d) && !is_pv_32bit_domain(d) &&
+ atomic_read(&d->arch.pv_domain.nr_l4_pages) )
+{
+bool_t done = 0;
+
+spin_lock_recursive(&d->page_alloc_lock);
+
+for ( i = 0; ; )
+{
+struct page_info *page = page_list_remove_head(&d->page_list);
+
+if ( page_lock(page) )
+{
+if ( (page->u.inuse.type_info & PGT_type_mask) ==
+ PGT_l4_page_table )
+done = !fill_ro_mpt(page_to_mfn(page));
+
+page_unlock(page);
+}
+
+page_list_add_tail(page, &d->page_list);
+
+if ( done || (!(++i & 0xff) && hypercall_preempt_check()) )
+break;
+}
+
+spin_unlock_recursive(&d->page_alloc_lock);
+
+if ( !done )
+return -ERESTART;
+}
+}
+
rc = put_old_guest_table(current);
if ( rc )
return rc;
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1463,13 +1463,20 @@ void init_guest_l4_table(l4_pgentry_t l4
l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty();
}
-void fill_ro_mpt(unsigned long mfn)
+bool_t fill_ro_mpt(unsigned long mfn)
{
l4_pgentry_t *l4tab = map_domain_page(_mfn(mfn));
+bool_t ret = 0;
-l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
-idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
+if ( !l4e_get_intpte(l4tab[l4_table_offset(RO_MPT_VIRT_START)]) )
+{
+l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
+idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
+ret = 1;
+}
unmap_domain_page(l4tab);
+
+return ret;
}
void zap_ro_mpt(unsigned long mfn)
@@ -1527,10 +1534,15 @@ static int alloc_l4_table(struct page_in
adjust_guest_l4e(pl4e[i], d);
}
-init_guest_l4_table(pl4e, d, !VM_ASSIST(d, m2p_strict));
+if ( rc >= 0 )
+{
+init_guest_l4_table(pl4e, d, !VM_ASSIST(d, m2p_strict));
+atomic_inc(&d->arch.pv_domain.nr_l4_pages);
+rc = 0;
+}
unmap_domain_page(pl4e);
-return rc > 0 ? 0 : rc;
+return rc;
}
static void free_l1_table(struct page_info *page)
@@ -1648,7 +1660,13 @@ static int free_l4_table(struct page_inf
unmap_domain_page(pl4e);
-return rc > 0 ? 0 : rc;
+if ( rc >= 0 )
+{
+atomic_dec(&d->arch.pv_domain.nr_l4_pages);
+rc = 0;
+}
+
+return rc;
}
int page_lock(struct page_info *page)
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -248,6 +248,8 @@ struct pv_domain
{
l1_pgentry_t **gdt_ldt_l1tab;
+atomic_t nr_l4_pages;
+
/* map_domain_page() mapping cache. */
struct mapcache_domain mapcache;
};
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -322,7 +322,7 @@ int free_page_type(struct page_info *pag
void init_guest_l4_table(l4_pgentry_t[], const struct domain *,
bool_t zap_ro_mpt);
-void fill_ro_mpt(unsigned long mfn);
+bool_t fill_ro_mpt(unsigned long mfn);
void zap_ro_mpt(unsigned long mfn);
int is_iomem_page(unsigned long mfn);
x86/PV: fix unintended dependency of m2p-strict mode on migration-v2
This went unnoticed until a backport of this to an older Xen got used,
causing migration of guests enabling this VM assist to fail, because
page table pinning there preceeds vCPU context loading, and hence L4
tables get initialized for the wrong mode. Fix this by post-processing
L4 tables when setting the intended VM assist flags for the guest.
Note that this leaves in place a dependency on vCPU 0 getting its guest
context restored first, but afaict the logic here is not the only thing
depending on that.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1067,8 +1067,48 @@ int arch_set_info_guest(
Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
>>> On 06.01.16 at 12:50, wrote:
> On Wed, Jan 6, 2016 at 12:48 PM, Andrew Cooper
> wrote:
>
>> On 06/01/16 11:42, Tamas K Lengyel wrote:
>>
>>
>>
>> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich wrote:
>>
>>> >>> On 23.12.15 at 15:53, < ta...@tklengyel.com>
>>> wrote:
>>> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
>>> vm_event_request_t *req)
>>> > vm_event_vcpu_pause(curr);
>>> > }
>>> >
>>> > +if ( altp2m_active(currd) )
>>> > +{
>>> > +req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>>> > +req->altp2m_idx = vcpu_altp2m(curr).p2midx;
>>> > +}
>>>
>>> So far this info was provided just for MEM_ACCESS events. Now
>>> you provide it for a few more ones, but wouldn't this then better
>>> be supplied for all of them, namely also the other two MEM ones?
>>>
>>
>> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure but
>> I think it's also incompatible with paging.
>>
>>
>> I don't think they are strictly incompatible; I don't see a technical
>> reason preventing some development work to make them function together.
>>
>> Whether this happens or not is a very different matter.
>
> Sure, the two systems can be made to work in tandem, this work just hasn't
> been done yet. I would very much like to get that to work in the future.
Which re-raises the question: Shouldn't the information then be
made available uniformly for all events?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()
On Di, 2016-01-12 at 09:50 +, Hao, Xudong wrote: > With latest qemu 7b8a354d4716, RHEL7.2 (with default kernel) VM still can't > boot up with IGD. There is another bug, using pci_default_write_config() doesn't fly as this checks writes against wmask and the registers in question are not whitelisted ... I've just rebased my igd patch series which (among other stuff) fixes that bug: https://www.kraxel.org/cgit/qemu/log/?h=work/igd git://git.kraxel.org/qemu work/igd Can you give it a spin? Also: what does "can't boot up" mean exactly? Guest doesn't boot at all? Guest boots, but igd/console/Xorg doesn't work? In case of the latter: Any chance to login via network and get a kernel log? thanks, Gerd ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote:
> 2) the changelog _completely_ fails to explain the sync 0x11 and sync
> 0x12 semantics nor does it provide a publicly accessible link to
> documentation that does.
Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/
> 3) it really should have explained what you did with
> smp_llsc_mb/smp_mb__before_llsc() in _detail_.
And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
are _NOT_ transitive and therefore cannot be used to implement the
smp_mb__{before,after} stuff.
That is, in MIPS speak, those SYNC types are Ordering Barriers, not
Completion Barriers. They need not be globally performed.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/hvm: Allow the guest to permit the use of userspace hypercalls
On Mon, Jan 11, 2016 at 5:58 PM, Andrew Cooper wrote: > On 11/01/16 17:11, Konrad Rzeszutek Wilk wrote: >> On Mon, Jan 11, 2016 at 04:51:19PM +, Andrew Cooper wrote: >>> Currently, hypercalls issued from HVM userspace will unconditionally fail >>> with >>> -EPERM. >>> >>> This is inflexible, and a guest may wish to allow userspace to make >>> hypercalls. >>> >>> Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the >>> permissions check for hypercalls. It behaves exactly like the dpl field for >>> GDT/LDT/IDT entries. >> >> Could you explain a bit of the use-case? > > My specific usecase, > http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=shortlog;h=refs/heads/wip-traps-v0.1 > > It isn't quite ready for formal release yet. > >> As in why the ioctl via the kernel is no good? > > Who says Linux is running? > > Hopefully answered in > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01155.html Not really. Obviously if you're running custom test code rather than Linux, then you aren't going to make an ioctl system call on a file descriptor; but what people are actually suggesting is just that you make *some* sort of system call from ring 3 which will then make the hypercall from ring 0. That's not "the Linux way" of doing things, it's the *operating system* way of doing things. >From the previous discussion, ISTR that what you want to be able to log messages to the Xen console from your test code when running in ring 3. It should be fairly easy to set up a custom system call in your test system that will then make the appropriate hypercall from ring 0 and return, with minimal interaction with other parts of the system. (I think there were some other suggestions there as well.) Is there a reason that's not possible? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 38621: regressions - FAIL
This run is configured for baseline tests only. flight 38621 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38621/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 38609 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl 19 guest-start/debian.repeatfail like 38609 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeatfail like 38609 test-amd64-amd64-pygrub 18 guest-start/debian.repeatfail like 38609 test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail like 38609 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuu6bb9ead762bf749af11ea225fc2a74db1b93c105 baseline version: qemuua7e00e2536941a6e570b45b7ab4afec4505ff67e Last test of basis38609 2016-01-09 11:22:39 Z2 days Testing same since38621 2016-01-11 16:55:22 Z0 days1 attempts People who touched revisions under test: Bandan Das Bo Tu Fam Zheng Gerd Hoffmann Hervé Poussineau Laurent Vivier Mark Cave-Ayland Markus Armbruster Max Reitz OGAWA Hirofumi Paolo Bonzini Peter Maydell 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-xl fail test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debi
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote:
> > 2) the changelog _completely_ fails to explain the sync 0x11 and sync
> > 0x12 semantics nor does it provide a publicly accessible link to
> > documentation that does.
>
> Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/
>
> > 3) it really should have explained what you did with
> > smp_llsc_mb/smp_mb__before_llsc() in _detail_.
>
> And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
> are _NOT_ transitive and therefore cannot be used to implement the
> smp_mb__{before,after} stuff.
>
> That is, in MIPS speak, those SYNC types are Ordering Barriers, not
> Completion Barriers. They need not be globally performed.
Which if true; and I know Will has some questions here; would also mean
that you 'cannot' use the ACQUIRE/RELEASE barriers for your locks as was
recently suggested by David Daney.
That is, currently all architectures -- with exception of PPC -- have
RCsc locks, but using these non-transitive things will get you RCpc
locks.
So yes, MIPS can go RCpc for its locks and share the burden of pain with
PPC, but that needs to be a very concious decision.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
On 12/01/16 07:33, Jan Beulich wrote: On 11.01.16 at 18:17, wrote: >> On 11/01/16 14:44, Jan Beulich wrote: >> On 11.01.16 at 14:59, wrote: Currently, hypercalls issued from HVM userspace will unconditionally fail with -EPERM. This is inflexible, and a guest may wish to allow userspace to make hypercalls. >>> I thought previous discussion had made clear that routing these >>> through ioctls or alike is the right approach, and hence the patch >>> isn't needed. The more that an all-or-nothing approach seems >>> pretty bold. >> All other issues fixed in v2, but to answer this one specifically. >> >> In it inappropriate for Xen to presume that all guests want Linux-like >> handing of situations like this. It is simply not true. >> >> As part of getting my test framework ready to publish, I attempted to >> port my XSA-106 unit tests to PV guests. I have shelved that work as I >> don't have sufficient time to fix PV trap handing in Xen at this present >> time, but do plan to fix them in due course. >> >> The bugs I have identified so far are: >> * "INT n" handling assumes the instruction was 2 bytes long >> * In some circumstances, Xen crashes the domain rather than injecting >> #NP[sel] >> * In most circumstances, Xen delivers #GP[sel] where #NP[sel] would be >> correct > All of these could be considered part of the awareness > requirements towards guests. The first causes corruption of process state in circumstances which wouldn't under native, including userspace state. You could make that argument for the final two. I reckon it is an unreasonable requirement. > >> * Not possible to have non-dpl3 descriptors for #BP and #OF > Actually the issue is broader I think (I've stumbled across this > limitation before, namely in the context of the #AC issue having > been the subject of a recent XSA) - you can't associate a DPL > with any exception vector. Ah - I had not patched Xen up sufficiently for the unit test to notice this (the domain crashes rather than #NP exceptions were prohibitive). > >> * Not possible to mark an existing descriptor as not-present > "Not easily possible" I suppose you mean, since one can by re- > writing the entire table. Can't be done atomically. Even if interrupts are disabled, there is a window where NMIs and MCEs would be lost. Writing a PV guest from scratch has been very enlightening to demonstrate how much of a trainwreck the ABI is. Almost nothing is documented. Some bits which are documented are misleading. Several areas needlessly deviate from x86 architectural behaviour. Almost any deviation from the way Linux does things ends up in situations which don't function. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
On Tue, Jan 12, 2016 at 10:57 AM, Andrew Cooper wrote: > Writing a PV guest from scratch has been very enlightening to > demonstrate how much of a trainwreck the ABI is. Almost nothing is > documented. Some bits which are documented are misleading. Several > areas needlessly deviate from x86 architectural behaviour. Almost any > deviation from the way Linux does things ends up in situations which > don't function. Something I think HPA has been complaining about for nearly a decade now I think... -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 77827: regressions - FAIL
flight 77827 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/77827/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 66879 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 66879 test-armhf-armhf-xl-rtds 9 debian-installfail REGR. vs. 66879 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 66879 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66879 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66879 test-amd64-amd64-libvirt-vhd 9 debian-di-installfail like 66879 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: xen f7347a282420a5edc74afb31e7c42c2765f24de5 baseline version: xen bf925a9f1254391749f569c1b8fc606036340488 Last test of basis66879 2015-12-21 21:25:56 Z 21 days Failing since 67053 2015-12-23 06:54:21 Z 20 days6 attempts Testing same since77827 2016-01-11 12:11:48 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Bob Moore Boris Ostrovsky Daniel De Graaf Doug Goldstein Feng Wu Graeme Gregory Hanjun Guo Haozhong Zhang Ian Campbell Ian Jackson Jan Beulich Joshua Otto Juergen Gross Julien Grall Kevin Tian Len Brown Lin Ming Lv Zheng Paul Durrant Rafael J. Wysocki Samuel Thibault Shannon Zhao Stefano Stabellini Tomasz Nowicki Wei Liu 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-libvi
Re: [Xen-devel] [PATCH RFC OSSTEST v1 04/12] mfi-common: always add host suite to hostos_runvars
Ian Campbell writes ("[PATCH RFC OSSTEST v1 04/12] mfi-common: always add host
suite to hostos_runvars"):
> This avoids situations where production-config* has changed
> DebianSuite but the bisector is still picking up baselines etc from
> before the change and reusing their runvars (without suite) with an
> inconsistent config.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 12, 2016 at 11:40:12AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote:
> > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync
> > > 0x12 semantics nor does it provide a publicly accessible link to
> > > documentation that does.
> >
> > Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/
> >
> > > 3) it really should have explained what you did with
> > > smp_llsc_mb/smp_mb__before_llsc() in _detail_.
> >
> > And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12
> > are _NOT_ transitive and therefore cannot be used to implement the
> > smp_mb__{before,after} stuff.
> >
> > That is, in MIPS speak, those SYNC types are Ordering Barriers, not
> > Completion Barriers. They need not be globally performed.
>
> Which if true; and I know Will has some questions here; would also mean
> that you 'cannot' use the ACQUIRE/RELEASE barriers for your locks as was
> recently suggested by David Daney.
The issue I have with the SYNC description in the text above is that it
describes the single CPU (program order) and the dual-CPU (confusingly
named global order) cases, but then doesn't generalise any further. That
means we can't sensibly reason about transitivity properties when a third
agent is involved. For example, the WRC+sync+addr test:
P0:
Wx = 1
P1:
Rx == 1
SYNC
Wy = 1
P2:
Ry == 1
Rx = 0
I can't find anything to forbid that, given the text. The main problem
is having the SYNC on P1 affect the write by P0.
> That is, currently all architectures -- with exception of PPC -- have
> RCsc locks, but using these non-transitive things will get you RCpc
> locks.
>
> So yes, MIPS can go RCpc for its locks and share the burden of pain with
> PPC, but that needs to be a very concious decision.
I think it's much worse than RCpc, given my interpretation of the wording.
Will
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] 2014 and 2015 contribution stats (including Reviewed-by and other tags)
Hi all, I attached a cleaned-up version for 2015. Thanks to those which provided input Lars On Mon, Jan 11, 2016 at 11:53 AM, Lars Kurth wrote: > Hi folks, > > please find attached 2014 and 2015 contribution stats, including some of the > tags. To compare like with like, the 2015 figures do contain repos which were > taken out of xen.git. They also include osstest, as I used to track these in > the past. > > The company figures in the 2015 file may have some inaccuracies as, I have > not tidied the user to company mapping yet. If you see your name or e-mail > address in there, it would be great if you could let me know which employer > to map you to by sending a private email. > > Key observations > * The number of patch-sets contributed have gone up significantly (from 2118 > to 2954) > * The number of developers has gone up from 110 to 116 > * The number of employers could possibly have gone down, but there is always > some uncertainty as I don't always know who works for whom and if I don't > know people are mapped int the "(Individual)" company bucket > * The number of "reviews, including ACKs" has increased from 2392 to 3257. If > you look at just the ACK's, a lot more people are reviewing. Also the > distribution has changed significantly. What is notable is that the Citrix > proportion of reviews has shot up significantly. Note that reviewed-by and > ACK tags do not accurately reflect actual effort in a review: just an > end-state. > * The number of test related tags has gone up marginally > > Best Regards > Lars > open output file /home/adminuser/Code-Clean/output/hypervisor/2015-dev.csv WARNING: duplicate email/empl for mee...@yomimono.org WARNING: duplicate email/empl for emun...@mgebm.net WARNING: duplicate email/empl for car...@cardoe.com Processed 2954 csets from 116 developers 33 employers found A total of 170336 lines added, 103200 removed (delta 67136) Developers with the most changesets Ian Jackson507 (17.2%) Ian Campbell 401 (13.6%) Jan Beulich326 (11.0%) Andrew Cooper 244 (8.3%) Wei Liu207 (7.0%) Julien Grall 188 (6.4%) Stefano Stabellini 130 (4.4%) Roger Pau Monné71 (2.4%) Dario Faggioli 71 (2.4%) Boris Ostrovsky 66 (2.2%) Paul Durrant50 (1.7%) Konrad Rzeszutek Wilk 47 (1.6%) Doug Goldstein 42 (1.4%) Olaf Hering 39 (1.3%) David Vrabel34 (1.2%) Juergen Gross 33 (1.1%) Chao Peng 30 (1.0%) Tamas K Lengyel 27 (0.9%) Tiejun Chen 25 (0.8%) George Dunlap 24 (0.8%) Yang Hongyang 23 (0.8%) Ross Lagerwall 20 (0.7%) Quan Xu 19 (0.6%) Feng Wu 16 (0.5%) Robert Ho 14 (0.5%) Tim Deegan 14 (0.5%) Vitaly Kuznetsov14 (0.5%) Kai Huang 13 (0.4%) Daniel Kiper13 (0.4%) Razvan Cojocaru 10 (0.3%) Ed White10 (0.3%) Chen Baozi 10 (0.3%) Don Slutz9 (0.3%) Daniel De Graaf 8 (0.3%) Anthony PERARD 8 (0.3%) Vijaya Kumar K 8 (0.3%) Edgar E. Iglesias8 (0.3%) Thomas Leonard 7 (0.2%) Haozhong Zhang 6 (0.2%) Harmandeep Kaur 6 (0.2%) longtao.pang 5 (0.2%) Shuai Ruan 5 (0.2%) Jonathan Creekmore 5 (0.2%) Len Brown5 (0.2%) Oleksandr Tyshchenko 5 (0.2%) Chris Brand 5 (0.2%) Liang Li 5 (0.2%) Frediano Ziglio 5 (0.2%) Sander Eikelenboom 4 (0.1%) Martin Lucina4 (0.1%) Huaitong Han 4 (0.1%) He Chen 4 (0.1%) Fabio Fantoni4 (0.1%) Wei Wang 4 (0.1%) Ravi Sahita 4 (0.1%) Yu Zhang 3 (0.1%) Wen Congyang 3 (0.1%) Jennifer Herbert 3 (0.1%) Charles Arnold 3 (0.1%) Pramod Devendra 3 (0.1%) Malcolm Crossley 2 (0.1%) Jim Fehlig 2 (0.1%) Bob Liu 2 (0.1%) Riku Voipio 2 (0.1%) Aravind Gopalakrishnan 2 (0.1%) Mike Latimer 2 (0.1%) Elena Ufimtseva 2 (0.1%) Ting-Wei Lan 2 (0.1%) Ben Catterall2 (0.1%) Euan Harris 2 (0.1%) Koushik Chakravarty 2 (0.1%) Giuseppe Mazzotta2 (0.1%) Robert VanVossen 2 (0.1%) Eugene Korenevsky2 (0.1%) Emil Condrea 2 (0.1%) Uma Sharma 2 (0.1%) Mihai Donțu 2 (0.1%) Alex Xu 1 (0.0%) Kevin Tian 1 (0.0%) David Scott 1 (0.0%) Chu
Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2
On 12/01/16 10:08, Jan Beulich wrote:
> This went unnoticed until a backport of this to an older Xen got used,
> causing migration of guests enabling this VM assist to fail, because
> page table pinning there preceeds vCPU context loading, and hence L4
> tables get initialized for the wrong mode. Fix this by post-processing
> L4 tables when setting the intended VM assist flags for the guest.
>
> Note that this leaves in place a dependency on vCPU 0 getting its guest
> context restored first, but afaict the logic here is not the only thing
> depending on that.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1067,8 +1067,48 @@ int arch_set_info_guest(
> goto out;
>
> if ( v->vcpu_id == 0 )
> +{
> d->vm_assist = c(vm_assist);
>
> +/*
> + * In the restore case we need to deal with L4 pages which got
> + * initialized with m2p_strict still clear (and which hence lack the
> + * correct initial RO_MPT_VIRT_{START,END} L4 entry).
> + */
> +if ( d != current->domain && VM_ASSIST(d, m2p_strict) &&
> + is_pv_domain(d) && !is_pv_32bit_domain(d) &&
> + atomic_read(&d->arch.pv_domain.nr_l4_pages) )
> +{
> +bool_t done = 0;
> +
> +spin_lock_recursive(&d->page_alloc_lock);
> +
> +for ( i = 0; ; )
> +{
> +struct page_info *page =
> page_list_remove_head(&d->page_list);
> +
> +if ( page_lock(page) )
> +{
> +if ( (page->u.inuse.type_info & PGT_type_mask) ==
> + PGT_l4_page_table )
> +done = !fill_ro_mpt(page_to_mfn(page));
> +
> +page_unlock(page);
> +}
> +
> +page_list_add_tail(page, &d->page_list);
> +
> +if ( done || (!(++i & 0xff) && hypercall_preempt_check()) )
> +break;
> +}
> +
> +spin_unlock_recursive(&d->page_alloc_lock);
> +
> +if ( !done )
> +return -ERESTART;
This is a long loop. It is preemptible, but will incur a time delay
proportional to the size of the domain during the VM downtime.
Could you defer the loop until after %cr3 has set been set up, and only
enter the loop if the kernel l4 table is missing the RO mappings? That
way, domains migrated with migration v2 will skip the loop entirely.
> +}
> +}
> +
> rc = put_old_guest_table(current);
> if ( rc )
> return rc;
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -1463,13 +1463,20 @@ void init_guest_l4_table(l4_pgentry_t l4
> l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty();
> }
>
> -void fill_ro_mpt(unsigned long mfn)
> +bool_t fill_ro_mpt(unsigned long mfn)
> {
> l4_pgentry_t *l4tab = map_domain_page(_mfn(mfn));
> +bool_t ret = 0;
>
> -l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
> -idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
> +if ( !l4e_get_intpte(l4tab[l4_table_offset(RO_MPT_VIRT_START)]) )
> +{
> +l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
> +idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
> +ret = 1;
This is a behavioural change. Previously, the old value was clobbered.
It appears that you are now using this return value to indicate when the
entire pagelist has been walked, but it it relies on the slots being
zero, which is a fragile assumption.
~Andrew
> +}
> unmap_domain_page(l4tab);
> +
> +return ret;
> }
>
> void zap_ro_mpt(unsigned long mfn)
> @@ -1527,10 +1534,15 @@ static int alloc_l4_table(struct page_in
> adjust_guest_l4e(pl4e[i], d);
> }
>
> -init_guest_l4_table(pl4e, d, !VM_ASSIST(d, m2p_strict));
> +if ( rc >= 0 )
> +{
> +init_guest_l4_table(pl4e, d, !VM_ASSIST(d, m2p_strict));
> +atomic_inc(&d->arch.pv_domain.nr_l4_pages);
> +rc = 0;
> +}
> unmap_domain_page(pl4e);
>
> -return rc > 0 ? 0 : rc;
> +return rc;
> }
>
> static void free_l1_table(struct page_info *page)
> @@ -1648,7 +1660,13 @@ static int free_l4_table(struct page_inf
>
> unmap_domain_page(pl4e);
>
> -return rc > 0 ? 0 : rc;
> +if ( rc >= 0 )
> +{
> +atomic_dec(&d->arch.pv_domain.nr_l4_pages);
> +rc = 0;
> +}
> +
> +return rc;
> }
>
> int page_lock(struct page_info *page)
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -248,6 +248,8 @@ struct pv_domain
> {
> l1_pgentry_t **gdt_ldt_l1tab;
>
> +atomic_t nr_l4_pages;
> +
> /* map_domain_page() mapping cache. */
> struct mapcache_domain mapcache;
> };
> --- a/xen/include/asm-x86/mm.h
> +++ b/xen/include/asm-x86/mm.h
> @@ -322,7 +322,7 @@ int free_page_type(struct page_info *pag
>
> void init_guest_l4_table(l4_pgentry_t[], const struct domain
[Xen-devel] blk_update_request: I/O error on NFS (was: [Xen-users] xen domU disk on nfs shared file)
Drop xen-users@, CC xen-devel@ and blk maintainers, change title. On Mon, Jan 11, 2016 at 03:08:24PM +0100, Kojedzinszky Richárd wrote: > Dear all, > > We are facing a regular lockup with our xen setup. We have an nfs share > mounted on the xen dom0, where the vm images are served, and those files are > given to xen domUs. > > I was just preparing an experiment, where I created a 100G file on the host: > # truncate -s 100G /srv/nfs/domU/disk2 > And after added this disk to the instance's configuration. > > On the host this is the mountpoint: > # mount|grep srv/xen > 10.1.1.1:/mnt/main/vps on /srv/xen type nfs > (rw,relatime,vers=3,rsize=16384,wsize=16384,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.1.1.1,mountvers=3,mountport=4045,mountproto=udp,local_lock=none,addr=10.1.1.1) > > After starting the instance I partitioned the disk with gdisk, and created > an xfs fs on it. While the fs has been created well, strange messages > appeared on the console: > > [ 23.787504] blk_update_request: I/O error, dev xvdc, sector 2048 > [ 23.788904] blk_update_request: I/O error, dev xvdc, sector 8390655 > [ 23.789611] blk_update_request: I/O error, dev xvdc, sector 16779262 > [ 23.790359] blk_update_request: I/O error, dev xvdc, sector 25167869 > [ 23.791148] blk_update_request: I/O error, dev xvdc, sector 33556476 > [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 41945083 > [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 50333690 > [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 58722297 > [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 67110904 > [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 75499511 > > I dont think that this is normal. If I chose a local block device (probably > lvm) for the domU, this does not appear. > > The host is running xen-4.4 with 3.16.0-4-amd64 kernel (debian jessie > stock), the domU is running 4.3.0-0.bpo.1-amd64 (jessie backport, 4.4.4). > > I suspect those messages should not be there. > > Regards, > > Kojedzinszky Richárd > Euronet Magyarorszag Informatika Zrt. > ___ > Xen-users mailing list > xen-us...@lists.xen.org > http://lists.xen.org/xen-users ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
On Mon, 11 Jan 2016, David Vrabel wrote: > On 11/01/16 17:17, Andrew Cooper wrote: > > So from one point of view, sufficient justification for this change is > > "because the Linux way isn't the only valid way to do this". > > "Because we can" isn't a good justification for adding something new. > Particularly something that is trivially easy to (accidentally) misuse > and open a big security hole between userspace and kernel. > > The vague idea for a userspace netfront that's floating around > internally is also not a good reason for pushing this feature at this time. I agree with David, but I might have another good use case for this. Consider the following scenario: we have a Xen HVM guest, with Xen installed inside of it (nested virtualization). I'll refer to Xen running on the host as L0 Xen and Xen running inside the VM as L1 Xen. Similarly we have two dom0 running, the one with access to the physical hardware, L0 Dom0, and the one running inside the VM, L1 Dom0. Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV frontend drivers, netfront and blkfront to speed up execution. In order to do that, the first thing it needs to do is making an hypercall to L0 Xen. That's because netfront and blkfront needs to communicate with netback and blkback in L0 Dom0: event channels and grant tables are the ones provided by L0 Xen. However L0 Xen refuses hypercalls from ring 3, and L1 Dom0 is running in ring 3 so unfortunately it cannot actually do it. With this hypercall in place, it is conceivable for L1 Dom0 to instruct L1 Xen to make a HVMOP_set_hypercall_dpl call and allow L1 Dom0 to setup netfront and blkfront with L0 Xen. Fun, isn't it. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
On Jan 12, 2016 3:21 AM, "Jan Beulich" wrote:
>
> >>> On 06.01.16 at 12:50, wrote:
> > On Wed, Jan 6, 2016 at 12:48 PM, Andrew Cooper <
andrew.coop...@citrix.com>
> > wrote:
> >
> >> On 06/01/16 11:42, Tamas K Lengyel wrote:
> >>
> >>
> >>
> >> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich wrote:
> >>
> >>> >>> On 23.12.15 at 15:53, < ta...@tklengyel.com>
> >>> wrote:
> >>> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
> >>> vm_event_request_t *req)
> >>> > vm_event_vcpu_pause(curr);
> >>> > }
> >>> >
> >>> > +if ( altp2m_active(currd) )
> >>> > +{
> >>> > +req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> >>> > +req->altp2m_idx = vcpu_altp2m(curr).p2midx;
> >>> > +}
> >>>
> >>> So far this info was provided just for MEM_ACCESS events. Now
> >>> you provide it for a few more ones, but wouldn't this then better
> >>> be supplied for all of them, namely also the other two MEM ones?
> >>>
> >>
> >> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure
but
> >> I think it's also incompatible with paging.
> >>
> >>
> >> I don't think they are strictly incompatible; I don't see a technical
> >> reason preventing some development work to make them function together.
> >>
> >> Whether this happens or not is a very different matter.
> >
> > Sure, the two systems can be made to work in tandem, this work just
hasn't
> > been done yet. I would very much like to get that to work in the future.
>
> Which re-raises the question: Shouldn't the information then be
> made available uniformly for all events?
>
IMHO there is no point doing so while the systems don't work together.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/hvm: Allow the guest to permit the use of userspace hypercalls
On Mon, 11 Jan 2016, Andrew Cooper wrote:
> Currently, hypercalls issued from HVM userspace will unconditionally fail with
> -EPERM.
>
> This is inflexible, and a guest may wish to allow userspace to make
> hypercalls.
>
> Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the
> permissions check for hypercalls. It behaves exactly like the dpl field for
> GDT/LDT/IDT entries.
>
> As the dpl is initialised to 0, hypercalls are restricted to cpl0 code until
> the OS explicitly chooses an alternative.
>
> Signed-off-by: Andrew Cooper
> --
> CC: Jan Beulich
> CC: Ian Campbell
> CC: Stefano Stabellini
>
> v2:
> * Fix rcu lock and dpl check.
> * Use uint8_t for hypercall_dpl and reposition for better packing.
>
> The test framework (soon to be published officially) how has both positive and
> negative tests to confirm the correct behaviour of this hypercall.
>
> Arm folks: Is something like this sufficiently generic to be useful on Arm,
> perhaps with more generic naming?
Hypercalls on ARM are made issuing an HVC instruction which is
"UNDEFINED in Secure state, and in User mode in Non-secure state".
In other words, it cannot work.
> PV guest support for userspace hypercalls is substantially more involved, and
> will take longer to complete.
> ---
> xen/arch/x86/hvm/hvm.c | 28 +++-
> xen/include/asm-x86/hvm/domain.h | 2 ++
> xen/include/public/hvm/hvm_op.h | 8
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 21470ec..5f3be6b 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5228,7 +5228,8 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
> case 4:
> case 2:
> hvm_get_segment_register(curr, x86_seg_ss, &sreg);
> -if ( unlikely(sreg.attr.fields.dpl) )
> +if ( unlikely(sreg.attr.fields.dpl >
> + currd->arch.hvm_domain.hypercall_dpl) )
> {
> default:
> regs->eax = -EPERM;
> @@ -6839,6 +6840,31 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> rc = do_altp2m_op(arg);
> break;
>
> +case HVMOP_set_hypercall_dpl:
> +{
> +xen_hvm_hypercall_dpl_t a;
> +struct domain *d;
> +
> +if ( copy_from_guest(&a, arg, 1 ) )
> +return -EFAULT;
> +
> +d = rcu_lock_domain_by_any_id(a.domid);
> +if ( d == NULL )
> +return -ESRCH;
> +
> +if ( current->domain != d )
> +return -EPERM;
> +
> +if ( !is_hvm_domain(d) )
> +return -EINVAL;
> +
> +if ( a.dpl > 3 )
> +return -EDOM;
> +
> +d->arch.hvm_domain.hypercall_dpl = a.dpl;
> +break;
> +}
> +
> default:
> {
> gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op);
> diff --git a/xen/include/asm-x86/hvm/domain.h
> b/xen/include/asm-x86/hvm/domain.h
> index a8cc2ad..ac426ce 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -123,6 +123,8 @@ struct hvm_domain {
> spinlock_t uc_lock;
> bool_t is_in_uc_mode;
>
> +uint8_thypercall_dpl;
> +
> /* Pass-through */
> struct hvm_iommu hvm_iommu;
>
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index 1606185..f8247db 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -489,6 +489,14 @@ struct xen_hvm_altp2m_op {
> typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t;
> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t);
>
> +#define HVMOP_set_hypercall_dpl 26
> +struct xen_hvm_hypercall_dpl {
> +domid_t domid;
> +uint16_t dpl; /* IN[1:0] cpl required to make hypercalls. */
> +};
> +typedef struct xen_hvm_hypercall_dpl xen_hvm_hypercall_dpl_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_hvm_hypercall_dpl_t);
> +
> #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */
>
> /*
> --
> 2.1.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [ovmf test] 77825: regressions - FAIL
On Tue, Jan 12, 2016 at 08:36:42AM +, osstest service owner wrote: > flight 77825 ovmf real [real] > http://logs.test-lab.xenproject.org/osstest/logs/77825/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail > REGR. vs. 65543 > test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail > REGR. vs. 65543 > The guest is constantly rebooting. But there isn't much clue in serial log. I will wait a bit for the bisector to come back with this. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/41] arch: barrier cleanup + barriers for virt
On Sun, Jan 10, 2016 at 04:16:22PM +0200, Michael S. Tsirkin wrote: > I parked this in vhost tree for now, though the inclusion of patch 1 from tip > creates a merge conflict - but one that is trivial to resolve. > > So I intend to just merge it all through my tree, including the > duplicate patch, and assume conflict will be resolved. > > I would really appreciate some feedback on arch bits (especially the x86 > bits), > and acks for merging this through the vhost tree. Thanks for doing this, looks good to me. Acked-by: Peter Zijlstra (Intel) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] blk_update_request: I/O error on NFS
Hello, El 12/01/16 a les 13.05, Wei Liu ha escrit: > Drop xen-users@, CC xen-devel@ and blk maintainers, change title. > > On Mon, Jan 11, 2016 at 03:08:24PM +0100, Kojedzinszky Richárd wrote: >> Dear all, >> >> We are facing a regular lockup with our xen setup. We have an nfs share >> mounted on the xen dom0, where the vm images are served, and those files are >> given to xen domUs. >> >> I was just preparing an experiment, where I created a 100G file on the host: >> # truncate -s 100G /srv/nfs/domU/disk2 >> And after added this disk to the instance's configuration. Have you tried creating the file with dd instead of truncate? (so it's not sparse) >> On the host this is the mountpoint: >> # mount|grep srv/xen >> 10.1.1.1:/mnt/main/vps on /srv/xen type nfs >> (rw,relatime,vers=3,rsize=16384,wsize=16384,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.1.1.1,mountvers=3,mountport=4045,mountproto=udp,local_lock=none,addr=10.1.1.1) >> >> After starting the instance I partitioned the disk with gdisk, and created >> an xfs fs on it. While the fs has been created well, strange messages >> appeared on the console: AFAICT this is the guest console. Is there any corresponding error on the host console? >> [ 23.787504] blk_update_request: I/O error, dev xvdc, sector 2048 >> [ 23.788904] blk_update_request: I/O error, dev xvdc, sector 8390655 >> [ 23.789611] blk_update_request: I/O error, dev xvdc, sector 16779262 >> [ 23.790359] blk_update_request: I/O error, dev xvdc, sector 25167869 >> [ 23.791148] blk_update_request: I/O error, dev xvdc, sector 33556476 >> [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 41945083 >> [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 50333690 >> [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 58722297 >> [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 67110904 >> [ 23.791498] blk_update_request: I/O error, dev xvdc, sector 75499511 >> >> I dont think that this is normal. If I chose a local block device (probably >> lvm) for the domU, this does not appear. IIRC Xen 4.4 still uses Qemu (Qdisk) for raw disks, do you have any kind of errors/warnings in /var/log/xen/qemu-dm-.log? Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] build: introduce CONFIG_NR_CPUS in Kconfig
On 1/12/16 2:37 AM, Jan Beulich wrote: On 11.01.16 at 23:02, wrote: >> --- /dev/null >> +++ b/xen/arch/Kconfig >> @@ -0,0 +1,8 @@ >> + >> +config NR_CPUS >> +int "Maximum number of physical CPUs" >> +range 1 65536 > > Why did you change this to 64k, when we settled on 4k-1 being > correct? I don't mind fixing this up upon commit, but I'd like it to > be confirmed that this was unintentional. > > Jan > It was definitely unintentional. I must have edited the patch to make it 4095 the first time before I sent it. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] libxl: fix _SC_GETPW_R_SIZE_MAX usage
According to the FreeBSD sysconf man page [0] if the variable is associated
with functionality that is not supported, -1 is returned and errno is not
modified. Modify libxl__dm_runas_helper so it's able to correctly
deal with this situation by setting the initial buffer value to 2048.
[0] https://www.freebsd.org/cgi/man.cgi?query=sysconf
Signed-off-by: Roger Pau Monné
---
tools/libxl/libxl_dm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 0aaefd9..ec8fb51 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -728,7 +728,14 @@ static int libxl__dm_runas_helper(libxl__gc *gc, const
char *username)
long buf_size;
int ret;
+errno = 0;
buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
+if (buf_size < 0 && errno == 0) {
+buf_size = 2048;
+LOG(DEBUG,
+"sysconf(_SC_GETPW_R_SIZE_MAX) is not supported, using a buffer size of %ld",
+buf_size);
+}
if (buf_size < 0) {
LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error %ld",
buf_size);
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] libxl: FreeBSD fixes
Hello, This series contains a couple of small fixes for FreeBSD. The first one is regarding the newly introduced libxl__dm_runas_helper function and it's usage of sysconf, while the second one fixes a long-stading bug that impacts UUID usage on FreeBSD (and NetBSD AFAICT). Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] libxl: fix UUID usage on FreeBSD
libxl makes the assumtion that libxl_uuid == uuid_t, and that uuid_t can be
freely used as a byte array. This is not true on FreeBSD (and NetBSD
too, not sure about other BSD UUID implementations), where the internals of
uuid don't match what libxl expects as a byte array because of endianness
issues.
Fix this by converting the libxl_uuid type to a struct with an internal
uuid_t field and a byte-array. Also introduce a new function that should be
used in order to load a byte array into a uuid_t struct.
Signed-off-by: Roger Pau Monné
---
tools/libxl/libxl.c | 2 +-
tools/libxl/libxl.h | 9 +
tools/libxl/libxl_uuid.c | 22 +++---
tools/libxl/libxl_uuid.h | 3 ++-
4 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9207621..ae08b2f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -616,7 +616,7 @@ static void xcinfo2xlinfo(libxl_ctx *ctx,
{
size_t size;
-memcpy(&(xlinfo->uuid), xcinfo->handle, sizeof(xen_domain_handle_t));
+libxl_uuid_from_bytearray(&xlinfo->uuid, xcinfo->handle);
xlinfo->domid = xcinfo->domain;
xlinfo->ssidref = xcinfo->ssidref;
if (libxl_flask_sid_to_context(ctx, xlinfo->ssidref,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 05606a7..876fca8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -867,6 +867,15 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
libxl_mac *src);
*/
#define LIBXL_HAVE_DEVICE_MODEL_VERSION_NONE 1
+/*
+ * LIBXL_HAVE_UUID_FROM_BYTEARRAY
+ *
+ * In the case that LIBXL_HAVE_UUID_FROM_BYTEARRAY is set libxl
+ * provides a function (libxl_uuid_from_bytearray) to convert an
+ * octet stream into a UUID.
+ */
+#define LIBXL_HAVE_UUID_FROM_BYTEARRAY 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_uuid.c b/tools/libxl/libxl_uuid.c
index 7d4a032..f566f50 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -33,6 +33,12 @@ int libxl_uuid_from_string(libxl_uuid *uuid, const char *in)
return uuid_parse(in, uuid->uuid);
}
+int libxl_uuid_from_bytearray(libxl_uuid *uuid, const uint8_t *raw)
+{
+memcpy(uuid, raw, sizeof(*uuid));
+return 0;
+}
+
void libxl_uuid_copy(libxl_ctx *ctx_opt, libxl_uuid *dst,
const libxl_uuid *src)
{
@@ -72,9 +78,9 @@ void libxl_uuid_generate(libxl_uuid *uuid)
{
uint32_t status;
-BUILD_BUG_ON(sizeof(libxl_uuid) != sizeof(uuid_t));
uuid_create(&uuid->uuid, &status);
assert(status == uuid_s_ok);
+uuid_enc_be(uuid->uuid_raw, &uuid->uuid);
}
#ifdef __FreeBSD__
@@ -85,6 +91,8 @@ int libxl_uuid_from_string(libxl_uuid *uuid, const char *in)
uuid_from_string(in, &uuid->uuid, &status);
if (status != uuid_s_ok)
return -1;
+uuid_enc_be(uuid->uuid_raw, &uuid->uuid);
+
return 0;
}
#else
@@ -101,15 +109,23 @@ int libxl_uuid_from_string(libxl_uuid *uuid, const char
*in)
#undef LIBXL__UUID_PTRS
#endif
+int libxl_uuid_from_bytearray(libxl_uuid *uuid, const uint8_t *raw)
+{
+uuid_dec_le(raw, &uuid->uuid);
+uuid_enc_be(uuid->uuid_raw, &uuid->uuid);
+
+return 0;
+}
+
void libxl_uuid_copy(libxl_ctx *ctx_opt, libxl_uuid *dst,
const libxl_uuid *src)
{
-memcpy(&dst->uuid, &src->uuid, sizeof(dst->uuid));
+memcpy(dst, src, sizeof(*dst));
}
void libxl_uuid_clear(libxl_uuid *uuid)
{
-memset(&uuid->uuid, 0, sizeof(uuid->uuid));
+memset(uuid, 0, sizeof(*uuid));
}
#ifdef __FreeBSD__
diff --git a/tools/libxl/libxl_uuid.h b/tools/libxl/libxl_uuid.h
index c5041c7..d84e3d1 100644
--- a/tools/libxl/libxl_uuid.h
+++ b/tools/libxl/libxl_uuid.h
@@ -42,7 +42,7 @@ typedef struct {
#include
#include
-typedef union {
+typedef struct {
uuid_t uuid;
uint8_t uuid_raw[16];
} libxl_uuid;
@@ -73,6 +73,7 @@ void libxl_uuid_clear(libxl_uuid *uuid);
int libxl_uuid_compare(const libxl_uuid *uuid1, const libxl_uuid *uuid2);
const uint8_t *libxl_uuid_bytearray_const(const libxl_uuid *uuid);
uint8_t *libxl_uuid_bytearray(libxl_uuid *uuid);
+int libxl_uuid_from_bytearray(libxl_uuid *uuid, const uint8_t *raw);
#endif /* __LIBXL_UUID_H__ */
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 77890: tolerable all pass - PUSHED
flight 77890 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77890/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
baseline version:
xen f7347a282420a5edc74afb31e7c42c2765f24de5
Last test of basis77538 2016-01-08 19:08:39 Z3 days
Testing same since77890 2016-01-12 11:03:17 Z0 days1 attempts
People who touched revisions under test:
Brendan Gregg
Daniel De Graaf
Doug Goldstein
Haozhong Zhang
Juergen Gross
Kevin Tian
Wei Liu for tools bits
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=20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
+ branch=xen-unstable-smoke
+ revision=20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' x20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++
Re: [Xen-devel] [libvirt] [PATCH V2 1/3] xenconfig: support vif bandwidth in sexpr parser and formatter
On 01/04/2016 08:08 PM, Jim Fehlig wrote:
> The xen sexpr config format has long supported specifying vif rate
> limiting, e.g.
>
> (device
> (vif
> (mac '00:16:3e:1b:b1:47')
> (rate '10240KB/s')
> ...
> )
> )
>
> Add support for mapping rate to and from in the xenconfig
> sexpr parser and formatter. rate is mapped to the required 'average'
> attribute of the element, e.g.
>
>
> ...
>
>
>
>
>
> Also add unit tests to check the conversion logic.
>
> This patch benefits both the old xen driver and the libxl driver.
> Both drivers gain support for vif bandwidth when converting to/from
> domXML and xen-sxpr. In addition, the old xen driver will now be
> able to handle vif 'rate' setting when communicating with xend.
>
> Signed-off-by: Jim Fehlig
> ---
>
> I used a bit of code from libxlu_vif.c to implement xenParseSxprVifRate()
> instead of using the libxlutil lib directly, since rate limiting applies
> to the old xen driver (no libxl) as well.
>
> src/libvirt_xenconfig.syms | 1 +
> src/xenconfig/xen_sxpr.c| 74
> +
> src/xenconfig/xen_sxpr.h| 2 +
> tests/sexpr2xmldata/sexpr2xml-vif-rate.sexpr| 11
> tests/sexpr2xmldata/sexpr2xml-vif-rate.xml | 51 +
> tests/sexpr2xmltest.c | 2 +
> tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr | 10
> tests/xml2sexprdata/xml2sexpr-fv-net-rate.xml | 34
> tests/xml2sexprtest.c | 1 +
> 9 files changed, 186 insertions(+)
>
Coverity found an 'issue'...
> diff --git a/src/libvirt_xenconfig.syms b/src/libvirt_xenconfig.syms
> index 6541685..b69f2ab 100644
> --- a/src/libvirt_xenconfig.syms
> +++ b/src/libvirt_xenconfig.syms
> @@ -15,6 +15,7 @@ xenParseSxpr;
> xenParseSxprChar;
> xenParseSxprSound;
> xenParseSxprString;
> +xenParseSxprVifRate;
>
> # xenconfig/xen_xm.h
> xenFormatXM;
> diff --git a/src/xenconfig/xen_sxpr.c b/src/xenconfig/xen_sxpr.c
> index d99bac0..9ae50b0 100644
> --- a/src/xenconfig/xen_sxpr.c
> +++ b/src/xenconfig/xen_sxpr.c
> @@ -26,6 +26,8 @@
>
> #include
>
> +#include
> +
> #include "internal.h"
> #include "virerror.h"
> #include "virconf.h"
> @@ -315,6 +317,56 @@ xenParseSxprChar(const char *value,
> }
>
>
> +static const char *vif_bytes_per_sec_re = "^[0-9]+[GMK]?[Bb]/s$";
> +
> +int
> +xenParseSxprVifRate(const char *rate, unsigned long long *kbytes_per_sec)
> +{
> +char *trate = NULL;
> +char *p;
> +regex_t rec;
> +char *suffix;
> +unsigned long long tmp;
> +int ret = -1;
> +
> +if (VIR_STRDUP(trate, rate) < 0)
> +return -1;
> +
> +p = strchr(trate, '@');
> +if (p != NULL)
> +*p = 0;
> +
> +regcomp(&rec, vif_bytes_per_sec_re, REG_EXTENDED|REG_NOSUB);
5) Event check_return: Calling "regcomp" without checking return value
(as is done elsewhere 14 out of 15 times).
IOW: What if regcomp fails...
John
> +if (regexec(&rec, trate, 0, NULL, 0)) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> + _("Invalid rate '%s' specified"), rate);
> +goto cleanup;
> +}
> +
> +if (virStrToLong_ull(rate, &suffix, 10, &tmp)) {
> +virReportError(VIR_ERR_INTERNAL_ERROR,
> + _("Failed to parse rate '%s'"), rate);
> +goto cleanup;
> +}
> +
> +if (*suffix == 'G')
> + tmp *= 1024 * 1024;
> +else if (*suffix == 'M')
> + tmp *= 1024;
> +
> +if (*suffix == 'b' || *(suffix + 1) == 'b')
> + tmp /= 8;
> +
> +*kbytes_per_sec = tmp;
> +ret = 0;
> +
> + cleanup:
> +regfree(&rec);
> +VIR_FREE(trate);
> +return ret;
> +}
> +
> +
<...>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 13/41] x86: reuse asm-generic/barrier.h
On Sun, 10 Jan 2016, Michael S. Tsirkin wrote: > As on most architectures, on x86 read_barrier_depends and > smp_read_barrier_depends are empty. Drop the local definitions and pull > the generic ones from asm-generic/barrier.h instead: they are identical. > > This is in preparation to refactoring this code area. > > Signed-off-by: Michael S. Tsirkin > Acked-by: Arnd Bergmann Reviewed-by: Thomas Gleixner ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 27/41] x86: define __smp_xxx
On Sun, 10 Jan 2016, Michael S. Tsirkin wrote: > This defines __smp_xxx barriers for x86, > for use by virtualization. > > smp_xxx barriers are removed as they are > defined correctly by asm-generic/barriers.h > > Signed-off-by: Michael S. Tsirkin > Acked-by: Arnd Bergmann Reviewed-by: Thomas Gleixner ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Nested virtualization off VMware vSphere 6.0 with EL6 guests crashes on Xen 4.6
Insure that memory and maxmem are set to the same value. On 01/11/2016 10:38 PM, Konrad Rzeszutek Wilk wrote: Hey, The machine is an X5-2 which is a Haswell based E5-2699 v3. We are trying to launch to use the nested virtualization. The guest is a simple VMware vSphere 6.0 with 32GB, 8 CPUs. The guest than that is launched within VMware is a 2 VCPU 2GB Linux (OEL6 to be exact). During its bootup Xen crashes with this assert. Oddly enough if this is repeated on a workstation Ivy Bridge CPU (i5-3570) it works fine. Disabling APICv (apicv=0) on the Xen command line did not help. I added some debug code to see if the vapic_pg is bad and what the p2mt type is [read below] Serial console started. To stop, type ESC ( (XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698 (XEN) [ Xen-4.6.0 x86_64 debug=y Tainted:C ] (XEN) CPU:39 (XEN) RIP:e008:[] virtual_vmentry+0x487/0xac9 (XEN) RFLAGS: 00010246 CONTEXT: hypervisor (d1v3) (XEN) rax: rbx: 83007786c000 rcx: (XEN) rdx: 0e00 rsi: 000f rdi: 83407f81e010 (XEN) rbp: 834008a47ea8 rsp: 834008a47e38 r8: (XEN) r9: r10: r11: (XEN) r12: r13: 82c000341000 r14: 834008a47f18 (XEN) r15: 83407f7c4000 cr0: 80050033 cr4: 001526e0 (XEN) cr3: 00407fb22000 cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=834008a47e38: (XEN)834008a47e68 82d0801d2cde 834008a47e68 0d00 (XEN) 834008a47e88 0004801cc30e (XEN)83007786c000 83007786c000 834008a4 (XEN)834008a47f18 834008a47f08 82d0801edf94 (XEN)834008a47ef8 834008f62000 834008a47f18 (XEN)00ae8c99eb8d 83007786c000 (XEN) 82d0801ee2ab (XEN) (XEN) (XEN) (XEN)078bfbff beefbeef (XEN)fc4b3440 00bfbeef 00040046 fc607f00 (XEN)beef beef beef beef (XEN)beef 0027 83007786c000 006f88716300 (XEN) (XEN) Xen call trace: (XEN)[] virtual_vmentry+0x487/0xac9 (XEN)[] nvmx_switch_guest+0x8ff/0x915 (XEN)[] vmx_asm_vmexit_handler+0x4b/0xc0 (XEN) (XEN) (XEN) (XEN) Panic on CPU 39: (XEN) Assertion 'vapic_pg && !p2m_is_paging(p2mt)' failed at vvmx.c:698 (XEN) (XEN) ..and then to my surprise the hypervisor stopped hitting this. Instead I started getting an even more bizzare crash: (d1) enter handle_19: (d1) NULL (d1) Booting from Hard Disk... (d1) Booting from :7c00 (XEN) stdvga.c:151:d1v0 leaving stdvga mode (XEN) stdvga.c:147:d1v0 entering stdvga and caching modes (XEN) stdvga.c:520:d1v0 leaving caching mode (XEN) [ Xen-4.6.0 x86_64 debug=y Tainted:C ] (XEN) CPU:3 (XEN) RIP:e008:[] vmx_cpu_up+0xacc/0xba5 (XEN) RFLAGS: 00010242 CONTEXT: hypervisor (d1v1) (XEN) rax: rbx: 830077877000 rcx: 834077e54000 (XEN) rdx: 834007dc8000 rsi: 2000 rdi: 830077877000 (XEN) rbp: 834007dcfc48 rsp: 834007dcfc38 r8: 0404 (XEN) r9: 000ff000 r10: r11: fc423f1e (XEN) r12: 2000 r13: r14: (XEN) r15: cr0: 80050033 cr4: 001526e0 (XEN) cr3: 004000763000 cr2: (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=834007dcfc38: (XEN)834007dcfc98 834007dcfc68 82d0801e2533 (XEN)830077877000 2000 834007dcfc78 82d0801ea933 (XEN)834007dcfca8 82d0801eaae4 830077877000 (XEN) 834007dcff18 834007dcfd08 82d0801eb983 (XEN)8341 00013692c000 8340 fc607f28 (XEN)0008 8346 834007dcff18 830077877000 (XEN)0015 834007dcff08 82d0801e8c8d (XEN)834007763000 8300778c2000 8340007c3000 834007dcfd50 (XEN)82d0801e120b 834007dcfd50 830077877000 834007dcfdf0 (XEN) 82d08012fe0b
Re: [Xen-devel] [PATCH RFC OSSTEST v1 05/12] make-*flight: Abolish $defsuite and $guestdefsuite
Ian Campbell writes ("[PATCH RFC OSSTEST v1 05/12] make-*flight: Abolish
$defsuite and $guestdefsuite"):
> Instead have mfi-common set $suite or $guestsuite if it is unset. When
> doing so move the use of local to this point, using local at the top
> of the function would shadow any attempt to set a global value, while
> restricting it only to when setting the default means it doesn't leak.
> NB "local" scopes the variable to the containing function, not the
> scope of the block where it is written (i.e. the if body in this
> case).
I'm not really sure this approach is right.
If we were to decide that some of the tests resulting from
test_matrix_iterate ought to have different suite values, we would
have to (re)introduce a layer of indirection.
Perhaps it would be better to retain defsuite and defguestsuite;
move the copy from those to suite and guestsuite closer to use site;
and unconditionally set the runvar ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC OSSTEST v1 06/12] ts-host-install: Support DiVersion coming from runvars
Ian Campbell writes ("[PATCH RFC OSSTEST v1 06/12] ts-host-install: Support
DiVersion coming from runvars"):
> To do so initialise $ho->{DiVersion} in select host and use it in
> ts-host-install.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC OSSTEST v1 09/12] mfi-common: Set diversion for build & test host install
Ian Campbell writes ("[PATCH RFC OSSTEST v1 09/12] mfi-common: Set diversion
for build & test host install"):
> This means that bisections will use the same version, even if
> production-config changed in the mean time.
Acked-by: Ian Jackson
Subject to anticipated change to the runvar name.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC OSSTEST v1 07/12] ts-debian-di-install: Allow Di Version to come from runvars
Ian Campbell writes ("[PATCH RFC OSSTEST v1 07/12] ts-debian-di-install: Allow
Di Version to come from runvars"):
> and following the lead of the suite arrange for a version selected
> from the defaults to be written back to the runvars.
...
> - debian_guest_suite
> + debian_guest_suite debian_guest_diversion
Can we please call this function, ..._di_version ? Otherwise it sounds
very much like something is being diverted.
> +sub debian_guest_diversion ($) {
> +my ($gho) = @_;
> +
> +$gho->{DiVersion} //= guest_var($gho,'diversion',undef);
> +
> +if (!$gho->{DiVersion}) {
> + $gho->{DiVersion} = $c{TftpDiVersion};
> + store_runvar("$gho->{Guest}_diversion", $gho->{DiVersion});
I'm not sure what we should do about the runvar. `diversion' is a bad
name but there is a risk with `..._di_version' getting confused with
all the `..._revision' fields.
OTOH
osstestdb=> select distinct name from runvars where name like '%version';
name
--
device_model_version
(1 row)
osstestdb=>
So maybe guest_di_version would be the right answer.
Aside from the questions about this name, this patch LGTM.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC OSSTEST v1 08/12] make-flight: Set diversion runvar on d-i based test jobs.
Ian Campbell writes ("[PATCH RFC OSSTEST v1 08/12] make-flight: Set diversion
runvar on d-i based test jobs."):
> Note that make-distros-flight does not want this, since it uses d-i
> fetched from the web not the version in our config.
Acked-by: Ian Jackson
Subject to anticipated change to the runvar name.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 77830: regressions - FAIL
flight 77830 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/77830/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-raw 6 xen-bootfail baseline untested test-armhf-armhf-libvirt-qcow2 6 xen-boot fail baseline untested test-amd64-amd64-libvirt-vhd 9 debian-di-install fail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass version targeted for testing: linuxafd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 187 days Failing since 59348 2015-07-10 04:24:05 Z 186 days 120 attempts Testing same since77830 2016-01-11 13:05:12 Z1 days1 attempts 3445 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-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass
Re: [Xen-devel] [PATCH 0/2] libxl: FreeBSD fixes
El 12/01/16 a les 14.14, Roger Pau Monne ha escrit: > Hello, > > This series contains a couple of small fixes for FreeBSD. The first one is > regarding the newly introduced libxl__dm_runas_helper function and it's > usage of sysconf, while the second one fixes a long-stading bug that impacts > UUID usage on FreeBSD (and NetBSD AFAICT). > > Thanks, Roger. Hm, it seems like I haven't Cced any of the maintainers, doing it here to reduce spam, sorry for the trouble. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.5-rc0
On 11/01/16 23:01, Stephen Rothwell wrote: > Hi David, > > On Mon, 11 Jan 2016 11:32:01 + David Vrabel wrote: >> >> Please git pull the following tag: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git >> for-linus-4.5-rc0-tag >> >> xen: features and fixes for 4.5-rc0 >> >> - - Stolen ticks and PV wallclock support for arm/arm64. >> - - Add grant copy ioctl to gntdev device. > > So the version I have of this in linux-next has not been updated since > Dec 2 and is based on v4.4-rc1. The version above is based on > v4.4-rc6 and has extra commits ... Did someone forget to update the > xen-tip/linux-next branch? Yes. Ideally I'd like the linux-next branch in ../xen/tip.git to be symbolic reference to the current for-linus-x.y branch so I do not have to remember to push to two different branches. I can't see a way to do this though. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
>>> On 12.01.16 at 13:07, wrote: > On Mon, 11 Jan 2016, David Vrabel wrote: >> On 11/01/16 17:17, Andrew Cooper wrote: >> > So from one point of view, sufficient justification for this change is >> > "because the Linux way isn't the only valid way to do this". >> >> "Because we can" isn't a good justification for adding something new. >> Particularly something that is trivially easy to (accidentally) misuse >> and open a big security hole between userspace and kernel. >> >> The vague idea for a userspace netfront that's floating around >> internally is also not a good reason for pushing this feature at this time. > > I agree with David, but I might have another good use case for this. > > Consider the following scenario: we have a Xen HVM guest, with Xen > installed inside of it (nested virtualization). I'll refer to Xen > running on the host as L0 Xen and Xen running inside the VM as L1 Xen. > Similarly we have two dom0 running, the one with access to the physical > hardware, L0 Dom0, and the one running inside the VM, L1 Dom0. > > Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV > frontend drivers, netfront and blkfront to speed up execution. In order > to do that, the first thing it needs to do is making an hypercall to L0 > Xen. That's because netfront and blkfront needs to communicate with > netback and blkback in L0 Dom0: event channels and grant tables are the > ones provided by L0 Xen. That's again a layering violation (bypassing the L1 hypervisor). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2
>>> On 12.01.16 at 12:55, wrote:
> On 12/01/16 10:08, Jan Beulich wrote:
>> This went unnoticed until a backport of this to an older Xen got used,
>> causing migration of guests enabling this VM assist to fail, because
>> page table pinning there preceeds vCPU context loading, and hence L4
>> tables get initialized for the wrong mode. Fix this by post-processing
>> L4 tables when setting the intended VM assist flags for the guest.
>>
>> Note that this leaves in place a dependency on vCPU 0 getting its guest
>> context restored first, but afaict the logic here is not the only thing
>> depending on that.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1067,8 +1067,48 @@ int arch_set_info_guest(
>> goto out;
>>
>> if ( v->vcpu_id == 0 )
>> +{
>> d->vm_assist = c(vm_assist);
>>
>> +/*
>> + * In the restore case we need to deal with L4 pages which got
>> + * initialized with m2p_strict still clear (and which hence lack the
>> + * correct initial RO_MPT_VIRT_{START,END} L4 entry).
>> + */
>> +if ( d != current->domain && VM_ASSIST(d, m2p_strict) &&
>> + is_pv_domain(d) && !is_pv_32bit_domain(d) &&
>> + atomic_read(&d->arch.pv_domain.nr_l4_pages) )
>> +{
>> +bool_t done = 0;
>> +
>> +spin_lock_recursive(&d->page_alloc_lock);
>> +
>> +for ( i = 0; ; )
>> +{
>> +struct page_info *page =
>> page_list_remove_head(&d->page_list);
>> +
>> +if ( page_lock(page) )
>> +{
>> +if ( (page->u.inuse.type_info & PGT_type_mask) ==
>> + PGT_l4_page_table )
>> +done = !fill_ro_mpt(page_to_mfn(page));
>> +
>> +page_unlock(page);
>> +}
>> +
>> +page_list_add_tail(page, &d->page_list);
>> +
>> +if ( done || (!(++i & 0xff) && hypercall_preempt_check()) )
>> +break;
>> +}
>> +
>> +spin_unlock_recursive(&d->page_alloc_lock);
>> +
>> +if ( !done )
>> +return -ERESTART;
>
> This is a long loop. It is preemptible, but will incur a time delay
> proportional to the size of the domain during the VM downtime.
>
> Could you defer the loop until after %cr3 has set been set up, and only
> enter the loop if the kernel l4 table is missing the RO mappings? That
> way, domains migrated with migration v2 will skip the loop entirely.
Well, first of all this would be the result only as long as you or
someone else don't re-think and possibly move pinning ahead of
context load again.
Deferring until after CR3 got set up is - afaict - not an option, as
it would defeat the purpose of m2p-strict mode as much as doing
the fixup e.g. in the #PF handler. This mode enabled needs to
strictly mean "L4s start with the slot filled, and user-mode uses
clear it", as documented.
There's a much simpler way we could avoid the loop being
entered: Check the previous setting of the flag. However, I
intentionally did not go that route in this initial version as I
didn't want to add more special casing than needed, plus to
make sure the new code isn't effectively dead.
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -1463,13 +1463,20 @@ void init_guest_l4_table(l4_pgentry_t l4
>> l4tab[l4_table_offset(RO_MPT_VIRT_START)] = l4e_empty();
>> }
>>
>> -void fill_ro_mpt(unsigned long mfn)
>> +bool_t fill_ro_mpt(unsigned long mfn)
>> {
>> l4_pgentry_t *l4tab = map_domain_page(_mfn(mfn));
>> +bool_t ret = 0;
>>
>> -l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
>> -idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
>> +if ( !l4e_get_intpte(l4tab[l4_table_offset(RO_MPT_VIRT_START)]) )
>> +{
>> +l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
>> +idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
>> +ret = 1;
>
> This is a behavioural change. Previously, the old value was clobbered.
>
> It appears that you are now using this return value to indicate when the
> entire pagelist has been walked, but it it relies on the slots being
> zero, which is a fragile assumption.
There are only two values possible in this slot - zero or the one
referring to the _shared across domains_ sub-tree for the r/o
MPT. I.e. the change of behavior is only an apparent one, and
I don't see this being fragile either.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Unexpected error:
On 07/01/16 10:21, Wei Liu wrote:
> CC George (who does the packaging for CentOS)
>
> BTW this problem is better directed to appropriate mailing list of
> CentOS (centos-virt? I can't remember the exact name).
It would be centos-virt, but as it looks like an upstream bug, if Janis
had reported this there, I probably would have asked him to re-report it
here (or on xen-users).
> On Thu, Jan 07, 2016 at 10:53:00AM +0200, Jānis Andersons | Failiem.lv wrote:
>> xen_major : 4
>> xen_minor : 4
>> xen_extra : .3-3.el6
>> CentOS release 6.7 (Final)
>>
>> After:
>> xm usb-hc-create demo_win2012_r2 2 4
I'm actually a bit surprised this worked, as I didn't think the CentOS
Virt SIG kernel had PVUSB support. Which kernel are you using?
Chunyan / Juergen, what modules should he look for to see if he has
pvusb backend support?
>> xm usb-list demo_win2012_r2
>> WARNING: xend/xm is deprecated.
>> Idx BE state usb-ver BE-path
>> 0 0 1 USB2.0 /local/domain/0/backend/vusb/2/0
>> port 1:
>> port 2:
>> port 3:
>> port 4:
>> xm usb-list-assignable-devices
>> WARNING: xend/xm is deprecated.
>> 1-1 : ID 090c:1000 SMI Corporation USB DISK
>> 1-10 : ID 14dd:0002 Peppercon AG Multidevice
>>
>>
>> xm usb-attach demo_win2012_r2 0 1 1-1
>>
>> WARNING: xend/xm is deprecated.
>> Unexpected error:
>>
>> Please report to xen-devel@lists.xen.org
>> Traceback (most recent call last):
>> File "/usr/sbin/xm", line 20, in
>> main.main(sys.argv)
>> File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 3946, in
>> main
>> _, rc = _run_cmd(cmd, cmd_name, args)
>> File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 3970, in
>> _run_cmd
>> return True, cmd(args)
>> File "/usr/lib64/python2.6/site-packages/xen/xm/main.py", line 3011, in
>> xm_usb_attach
>> if vusb_util.bus_is_assigned(bus):
>> File "/usr/lib64/python2.6/site-packages/xen/util/vusb_util.py", line 275,
>> in bus_is_assigned
>> raise UsbDeviceParseError("Can't get assignment status: (%s)." % bus)
>> xen.util.vusb_util.UsbDeviceParseError: vusb: Error parsing USB device info:
>> Can't get assignment status: (1-1).
This could possibly be a side-effect of having no PVUSB backend; it
could also be a straight-up bug in xend.
If it's an issue with having no PVUSB backend, you could try to build a
kernel with support; the SLES kernel is probably your best bet, as I
*think* they officially support it.
If you have PVUSB available, then it's probably a bug in xend.
Unfortunately xend has been poorly maintained for some time. Xen 4.4 is
already out of support, and xend was removed from the tree shortly after
the Xen 4.5 development window opened (hence the warnings). So in this
case it would most likely be classified as WONTFIX.
PVUSB support for xl is 99% certain to be available for Xen 4.7.
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC OSSTEST v1 10/12] Qualify TftpDiVersion with the suite.
Ian Campbell writes ("[PATCH RFC OSSTEST v1 10/12] Qualify TftpDiVersion with
the suite."):
> This allows the version to differ e.g. between Wheezy and Jessie.
>
> Update production-config* to set TftpDiVersion_jessie instead of just
> TftpDiVersion, also add TftpDiVersion_wheezy using the version
> replaced in commit f610ea162836 "Switch to Debian 8.0 (jessie) as OS
> for test hosts".
>
> In mfi-common we need to check for TftpDiVersion_$suite (_$guestsuite)
> and TftpDiVersion manually since getconfig In that context will not
> see any DebianSuite override in the environment.
>
> This ensures that when a non-default suite is configured a
> corresponding useful version of DI is selected.
Acked-by: Ian Jackson
provided the identifier `diversion' is changed (see my previous
mails).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] build: convert NR_CPUS to Kconfig
On 1/12/16 2:41 AM, Jan Beulich wrote: On 11.01.16 at 23:02, wrote: >> --- a/xen/include/xen/config.h >> +++ b/xen/include/xen/config.h >> @@ -92,4 +92,7 @@ >> #define FLASK_AVC_STATS 1 >> #endif >> >> +/* allow existing code to work with Kconfig variable */ >> +#define NR_CPUS CONFIG_NR_CPUS > > Perhaps here or in a follow-up patch derive CONFIG_SMP (used in a > few places in ARM code) from NR_CPUS > 1? > > Jan > I agree with you. That's actually in a follow on. I've got most of the CONFIG_ fields in a branch locally and as each patch gets reviewed I'm submitting more. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC OSSTEST v1 11/12] mfi-common: usual_debianhvm_image: derive version from $guestsuite
Ian Campbell writes ("[PATCH RFC OSSTEST v1 11/12] mfi-common:
usual_debianhvm_image: derive version from $guestsuite"):
> This more likely matches the callers intention.
>
> Move the setting into production-config* alongside the Suite and
> TftpDiVersion settings. Continue to support $DEBIAN_IMAGE_VERSION as an
> override. The value for Wheezy is from what was replaced
> in 610ea1628363 "Switch to Debian 8.0 (jessie) as OS for test hosts".
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC OSSTEST v1 12/12] make-flight: Use older Debian for host and guest OS with older Xen
Ian Campbell writes ("[PATCH RFC OSSTEST v1 12/12] make-flight: Use older
Debian for host and guest OS with older Xen"):
> Sometimes when updating osstest to use a newer version of Debian as a
> baseline we find that the new compiler or other tools pickup latent
> errors in older code bases for which the fixes are invasive or
> otherwise inappropriate for a stable branch.
>
> This is the case with Debian Jessie and Xen 4.3 and earlier, so
> restrict those branches to keep using Wheezy.
Acked-by: Ian Jackson
Subject to anticipated change to the runvar name.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 5/7] Database locking: Tcl: for errorCode, use pg_exec, not pg_execute
Ian Campbell writes ("Re: [OSSTEST PATCH 5/7] Database locking: Tcl: for
errorCode, use pg_exec, not pg_execute"):
> On Thu, 2016-01-07 at 19:38 +, Ian Jackson wrote:
> > A wrinkle is that as a result it is no longer possible to use
> > db-execute on a SELECT statement nor db-execute-array on a non-SELECT
> > statement. This is because the 1. the `ok' status that we have to
(fixed the typos, thanks)
> > of the statement handle (-cmdTuples vs -numTuples). But all uses in
> > the codebase are now fine for this distinction.
>
> Does this imply that db-execute-array could be renamed db-execute-select,
> or even just db-select?
Yes, indeed. Do you think I should ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4.4 1/2] libxl: Rerun bison and flex
Ian Campbell writes ("Re: [PATCH 4.4 1/2] libxl: Rerun bison and flex"):
> On Mon, 2016-01-04 at 14:50 +, Ian Jackson wrote:
> > We are going to want to cherry pick a change to the bison input, which
> > will involve rerunning bison.
> >
> > So firstly, update the bison and flex output to that from current
> > Debian wheezy (i386; 1:2.5.dfsg-2.1 and 2.5.35-10.1 respectively).
> >
> > There should be no functional change since there is no change to the
> > source file, but we will inherit bugfixes and behavioural changes from
> > the new version of bison. So this is more a matter of hope than
> > knowledge.
>
> This one isn't a cherry pick, but rather a manual rerun of the tools with a
> cargo-culted commit message from another such occasion, right?
Yes.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 3/7] Database locking: Tcl: Use db-execute
Ian Campbell writes ("Re: [OSSTEST PATCH 3/7] Database locking: Tcl: Use
db-execute"):
> On Thu, 2016-01-07 at 19:38 +, Ian Jackson wrote:
> > Replace open-coded uses of pg_execute dbh STMT with
> > jobdb::db-execute-array STMT.
>
> ITYM jobdb::db-execute?
Yes, fixed, thanks.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Backport of SeaBIOS changeset 3b8c53
Hello, I would like to request the backport of the following SeaBIOS commit to the master branch of the SeaBIOS repository used by Xen unstable (this is AFAICT the only one that requires this build fix). commit 3b8c5378dfe24ca8dfeabbcc435c7eb9e2d8d769 Author: Roger Pau Monne Date: Mon Dec 28 13:50:41 2015 +0100 build: fix typo in buildversion.py Fixes the following build error: Building ld scripts Traceback (most recent call last): File "./scripts/buildversion.py", line 134, in main() File "./scripts/buildversion.py", line 114, in main cleanbuild, toolstr = tool_versions(options.tools) File "./scripts/buildversion.py", line 90, in tool_versions vers[isbinutils] = "mixed" NameError: global name 'vers' is not defined Makefile:160: recipe for target 'out/romlayout16.lds' failed Signed-off-by: Roger Pau Monné Without this build fix it's not possible to build SeaBIOS on systems with mixed toolstacks. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Unexpected error:
On 12/01/16 16:19, George Dunlap wrote: > On 07/01/16 10:21, Wei Liu wrote: >> CC George (who does the packaging for CentOS) >> >> BTW this problem is better directed to appropriate mailing list of >> CentOS (centos-virt? I can't remember the exact name). > > It would be centos-virt, but as it looks like an upstream bug, if Janis > had reported this there, I probably would have asked him to re-report it > here (or on xen-users). > >> On Thu, Jan 07, 2016 at 10:53:00AM +0200, Jānis Andersons | Failiem.lv wrote: >>> xen_major : 4 >>> xen_minor : 4 >>> xen_extra : .3-3.el6 >>> CentOS release 6.7 (Final) >>> >>> After: >>> xm usb-hc-create demo_win2012_r2 2 4 > > I'm actually a bit surprised this worked, as I didn't think the CentOS > Virt SIG kernel had PVUSB support. Which kernel are you using? > > Chunyan / Juergen, what modules should he look for to see if he has > pvusb backend support? The classic kernel-xen flavor has "usbback", so do openSUSE and SLE official releases. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/HVM: prune error labels in do_hvm_op()
I've got repeatedly annoyed by the bad naming: Make them slightly
better recognizable (and less likely to get mixed up), except in cases
where they can be eliminated altogether.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -6523,29 +6523,29 @@ long do_hvm_op(unsigned long op, XEN_GUE
rc = -EINVAL;
if ( !is_hvm_domain(d) )
-goto param_fail2;
+goto tdv_fail;
if ( a.nr > GB(1) >> PAGE_SHIFT )
-goto param_fail2;
+goto tdv_fail;
rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
if ( rc )
-goto param_fail2;
+goto tdv_fail;
rc = -ESRCH;
if ( d->is_dying )
-goto param_fail2;
+goto tdv_fail;
rc = -EINVAL;
if ( d->vcpu == NULL || d->vcpu[0] == NULL )
-goto param_fail2;
+goto tdv_fail;
if ( shadow_mode_enabled(d) )
rc = shadow_track_dirty_vram(d, a.first_pfn, a.nr, a.dirty_bitmap);
else
rc = hap_track_dirty_vram(d, a.first_pfn, a.nr, a.dirty_bitmap);
-param_fail2:
+tdv_fail:
rcu_unlock_domain(d);
break;
}
@@ -6564,21 +6564,21 @@ long do_hvm_op(unsigned long op, XEN_GUE
rc = -EINVAL;
if ( !is_hvm_domain(d) )
-goto param_fail3;
+goto modmem_fail;
rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
if ( rc )
-goto param_fail3;
+goto modmem_fail;
rc = -EINVAL;
if ( a.nr < start_iter ||
((a.first_pfn + a.nr - 1) < a.first_pfn) ||
((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
-goto param_fail3;
+goto modmem_fail;
rc = 0;
if ( !paging_mode_log_dirty(d) )
-goto param_fail3;
+goto modmem_fail;
while ( a.nr > start_iter )
{
@@ -6604,7 +6604,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
}
}
-param_fail3:
+modmem_fail:
rcu_unlock_domain(d);
break;
}
@@ -6623,11 +6623,9 @@ long do_hvm_op(unsigned long op, XEN_GUE
return -ESRCH;
rc = xsm_hvm_param(XSM_TARGET, d, op);
-if ( rc )
-goto param_fail_getmemtype;
-
-rc = -EINVAL;
-if ( is_hvm_domain(d) )
+if ( unlikely(rc) )
+/* nothing */;
+else if ( likely(is_hvm_domain(d)) )
{
/* Use get_gfn query as we are interested in the current
* type, not in allocating or unsharing. That'll happen
@@ -6647,10 +6645,12 @@ long do_hvm_op(unsigned long op, XEN_GUE
a.mem_type = HVMMEM_ram_rw;
else
a.mem_type = HVMMEM_mmio_dm;
-rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
+if ( __copy_to_guest(arg, &a, 1) )
+rc = -EFAULT;
}
+else
+rc = -EINVAL;
-param_fail_getmemtype:
rcu_unlock_domain(d);
break;
}
@@ -6677,20 +6677,20 @@ long do_hvm_op(unsigned long op, XEN_GUE
rc = -EINVAL;
if ( !is_hvm_domain(d) )
-goto param_fail4;
+goto setmemtype_fail;
rc = xsm_hvm_control(XSM_DM_PRIV, d, op);
if ( rc )
-goto param_fail4;
+goto setmemtype_fail;
rc = -EINVAL;
if ( a.nr < start_iter ||
((a.first_pfn + a.nr - 1) < a.first_pfn) ||
((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
-goto param_fail4;
+goto setmemtype_fail;
if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
-goto param_fail4;
+goto setmemtype_fail;
while ( a.nr > start_iter )
{
@@ -6703,39 +6703,39 @@ long do_hvm_op(unsigned long op, XEN_GUE
put_gfn(d, pfn);
p2m_mem_paging_populate(d, pfn);
rc = -EAGAIN;
-goto param_fail4;
+goto setmemtype_fail;
}
if ( p2m_is_shared(t) )
{
put_gfn(d, pfn);
rc = -EAGAIN;
-goto param_fail4;
+goto setmemtype_fail;
}
if ( !p2m_is_ram(t) &&
(!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
(t != p2m_mmio_write_dm || a.hvmmem_type != HVMMEM_ram_rw) )
{
put_gfn(d, pfn);
-goto param_fail4;
+goto setmemtype_fail;
}
rc = p2m_change_type_one(d, pfn, t, memtype[a.hvmmem_type]);
put_gfn(d, pfn);
if ( rc )
-goto param_fail4;
+goto setmemtype_fail;
/* Check for continuation if it's not the last interation */
if ( a.nr
[Xen-devel] [qemu-upstream-4.4-testing test] 77834: tolerable FAIL - PUSHED
flight 77834 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77834/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 62580
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 62702
Tests which did not succeed, but are not blocking:
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-amd64-i386-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass
version targeted for testing:
qemuu2264b0c66075cc34c252a1386f019f8be6240890
baseline version:
qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0
Last test of basis62702 2015-10-06 15:32:13 Z 98 days
Testing same since66539 2015-12-18 16:12:10 Z 24 days 13 attempts
People who touched revisions under test:
Stefano Stabellini
jobs:
build-amd64-xend pass
build-i386-xend pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-qemuu-nested-amdfail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpupass
test-amd64-amd64-pairpass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-amd64-pvgrubpass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2pass
test-amd64-i386-xl-raw pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-amd64-amd64-xl-qemuu-winxpsp3 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=qemu-upstream-4.4-testing
+ revision=2264b0c66075cc34c252a1386f019f8be6240890
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repo
Re: [Xen-devel] [PATCH] tools: make flask utils build unconditional
On Mon, Jan 11, 2016 at 11:10:35AM -0600, Doug Goldstein wrote:
> On 1/11/16 9:19 AM, Wei Liu wrote:
> > On Fri, Jan 08, 2016 at 12:49:07PM -0600, Doug Goldstein wrote:
> > [...]
> >> Ok so I'm at a loss what steps I need to take. I've submitted patches to
> >> put the config in /boot so that this check can be made but there's a
> >> disagreement if that's even necessary or not.
> >>
> >
> > That's a bit unfortunate. :-(
> >
> > But if I'm not mistaken that's orthogonal to this problem, right? That's
> > one more step down the road regarding grub integration.
> >
> >> Do I need to supply a patch to make --disable-xsmpolicy the default so
> >> that this change doesn't generate the policy by default? The point of
> >> this patch is to compile the necessarily bits always which will help
> >> shake out bugs earlier. If we don't want the policy file to be installed
> >> then we should use the proper setting for that and not the fact that the
> >> utility isn't being compiled.
> >>
> >
> > I think one solution would be to modify flask/Makefile to guard policy
> > compilation against (FLASK_ENABLE && FLASK_POLICY).
> >
> > What do you think? Admittedly I haven't followed closely all the KConfig
> > work so I might be talking nonsense.
> >
> > Ian and Ian?
> >
> > Wei.
>
> Wei (and Ian and Ian and Daniel),
>
> There's already a guard against compiling the policy in the tools/
> directory's configure script called --{enable,disable}-xsmpolicy What I
> could do is disable it by default because it is currently enabled by
> default.
>
> I honestly think that would be an improvement because we would compile
> all the source code (causing us to shake bugs out earlier) but only
> generate the policy when the user explicitly requests it. Right now the
> policy is made whenever the utilities are compiled.
>
> Let me know if that sounds appealing to you.
>
Fine by me.
I don't really have a strong opinion at this point. My original concern
that the installed xenpolicy file interferes with grub was based on the
assumption that we only had version numbers as indicator to match
hypervisor binary and xenpolicy file. But now since I think there is
better way to generate grub entry I don't think my objection based on
the (bad) assumption to this patch is relevant anymore.
Wei.
> Thanks.
> --
> Doug Goldstein
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 2/2] Revert "libxc: create an initial FPU state for HVM guests"
This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad:
Xen always set the FPU as initialized when loading a HVM context, so libxc
has to provide a valid FPU context when setting the CPU registers.
This was a stop-gap measure in order to unblock OSSTest Windows 7 failures
while a proper fix for the HVM CPU save/restore is being worked on.
This can now be reverted because a proper fix is in place and we can signal
in the save record whether the FPU is initialized or not.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
Acked-by: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxc/xc_dom_x86.c | 38 --
1 file changed, 38 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index b8d2904..b650762 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -987,27 +987,6 @@ static int vcpu_hvm(struct xc_dom_image *dom)
struct hvm_save_descriptor end_d;
HVM_SAVE_TYPE(END) end;
} bsp_ctx;
-/*
- * The layout of the fpu context structure is the same for
- * both 32 and 64 bits.
- */
-struct {
-uint16_t fcw;
-uint16_t fsw;
-uint8_t ftw;
-uint8_t rsvd1;
-uint16_t fop;
-union {
-uint64_t addr;
-struct {
-uint32_t offs;
-uint16_t sel;
-uint16_t rsvd;
-};
-} fip, fdp;
-uint32_t mxcsr;
-uint32_t mxcsr_mask;
-} *fpu_ctxt;
uint8_t *full_ctx = NULL;
int rc;
@@ -1075,23 +1054,6 @@ static int vcpu_hvm(struct xc_dom_image *dom)
/* Set the control registers. */
bsp_ctx.cpu.cr0 = X86_CR0_PE | X86_CR0_ET;
-/*
- * XXX: Set initial FPU state.
- *
- * This should be removed once Xen is able to know if the
- * FPU state saved is valid or not, now Xen always sets
- * fpu_initialised to true regardless of the FPU state.
- *
- * The code below mimics the FPU sate after executing
- * fninit
- * ldmxcsr 0x1f80
- */
-fpu_ctxt = (typeof(fpu_ctxt))bsp_ctx.cpu.fpu_regs;
-
-fpu_ctxt->fcw = 0x37f;
-fpu_ctxt->ftw = 0xff;
-fpu_ctxt->mxcsr = 0x1f80;
-
/* Set the IP. */
bsp_ctx.cpu.rip = dom->parms.phys_entry;
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 0/2] Introduce a flags field to HVM CPU context
Hello, This patch series tries to properly solve the problem seen with the HVMlite series, that Xen always assumes the FPU is initialised on CPU context restore. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 1/2] xen/hvm: introduce a flags field in the CPU save record
Introduce a new flags field and use bit 0 to signal if the FPU has been
initialised or not. Previously Xen always wrongly assumed the FPU was
initialised on restore.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v5:
- Adapt the code due to the changes introduced by XSA-165.
Changes since v4:
- Zero the fpu save area if the FPU is not initialised. This avoids
leaking hypervisor data.
- Due to the previous patch in this series, slightly rework the way to load
the FPU state in a xsave capable host.
Changes since v3:
- Don't add a comment in the compat structure regaring the fpu_initialised
field.
- Rename fpu_initialised to flags and use it as a bit field. Bit 0 will be
used to signal whether the fpu is initialised.
- Only save the fpu context if it's initialised.
- Only restore the fpu context from the save record if the fpu is
initialised.
- Check that unused bits in the flags field are 0.
Changes since v1:
- Don't add yet another compat structure, new fields should always be added
to the end of the existing structure and offsetof should be used to
compare sizes.
- Leave the previous compat structure as-is, since the field was not added
to the end we cannot remove it and use offsetof in this case.
- Set xstate_bv based on fpu_initialised value instead of unconditionally
setting it to XSTATE_FP_SSE.
---
xen/arch/x86/hvm/hvm.c | 42 ++
xen/include/public/arch-x86/hvm/save.h | 27 --
2 files changed, 48 insertions(+), 21 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 787b7de..79ec90f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1797,9 +1797,15 @@ static int hvm_save_cpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
ctxt.ldtr_arbytes = seg.attr.bytes;
if ( v->fpu_initialised )
+{
memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs));
-else
-memset(ctxt.fpu_regs, 0, sizeof(ctxt.fpu_regs));
+ctxt.flags = XEN_X86_FPU_INITIALISED;
+}
+else
+{
+ memset(ctxt.fpu_regs, 0, sizeof(ctxt.fpu_regs));
+ ctxt.flags = 0;
+}
ctxt.rax = v->arch.user_regs.eax;
ctxt.rbx = v->arch.user_regs.ebx;
@@ -1981,7 +1987,7 @@ static int hvm_load_cpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
return -EINVAL;
}
-if ( hvm_load_entry(CPU, h, &ctxt) != 0 )
+if ( hvm_load_entry_zeroextend(CPU, h, &ctxt) != 0 )
return -EINVAL;
/* Sanity check some control registers. */
@@ -2009,6 +2015,13 @@ static int hvm_load_cpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
return -EINVAL;
}
+if ( (ctxt.flags & ~XEN_X86_FPU_INITIALISED) != 0 )
+{
+gprintk(XENLOG_ERR, "bad flags value in CPU context: %#x\n",
+ctxt.flags);
+return -EINVAL;
+}
+
/* Older Xen versions used to save the segment arbytes directly
* from the VMCS on Intel hosts. Detect this and rearrange them
* into the struct segment_register format. */
@@ -2087,19 +2100,21 @@ static int hvm_load_cpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
seg.attr.bytes = ctxt.ldtr_arbytes;
hvm_set_segment_register(v, x86_seg_ldtr, &seg);
-/* In case xsave-absent save file is restored on a xsave-capable host */
-if ( cpu_has_xsave && !xsave_enabled(v) )
+v->fpu_initialised = !!(ctxt.flags & XEN_X86_FPU_INITIALISED);
+if ( v->fpu_initialised )
{
-struct xsave_struct *xsave_area = v->arch.xsave_area;
+memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
+/* In case xsave-absent save file is restored on a xsave-capable host
*/
+if ( cpu_has_xsave && !xsave_enabled(v) )
+{
+struct xsave_struct *xsave_area = v->arch.xsave_area;
-memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
-xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
-if ( cpu_has_xsaves || cpu_has_xsavec )
-xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
- XSTATE_COMPACTION_ENABLED;
+xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
+if ( cpu_has_xsaves || cpu_has_xsavec )
+xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
+ XSTATE_COMPACTION_ENABLED;
+}
}
-else
-memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
v->arch.user_regs.eax = ctxt.rax;
v->arch.user_regs.ebx = ctxt.rbx;
@@ -2127,7 +2142,6 @@ static int hvm_load_cpu_ctxt(struct domain *d,
hvm_domain_context_t *h)
v->arch.debugreg[7] = ctxt.dr7;
v->arch.vgc_flags = VGCF_online;
-v->fpu_initialised = 1;
/* Auxiliary processors should be woken immediate
Re: [Xen-devel] [PATCH v3 1/3] xsm/xen_version: Add XSM for the xen_version hypercall (v6).
>>> On 08.01.16 at 03:25, wrote:
> @@ -226,9 +227,10 @@ void __init do_initcalls(void)
> /*
> * Simple hypercalls.
> */
> -
> DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> +bool_t deny = !!xsm_version_op(XSM_OTHER, cmd);
> +
> switch ( cmd )
> {
> case XENVER_version:
> @@ -354,10 +356,17 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> return 0;
>
> case XENVER_commandline:
> -if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
> +{
> +size_t len = ARRAY_SIZE(saved_cmdline);
> +
> +if ( deny )
> +len = strlen(xen_deny()) + 1;
> +
> +if ( copy_to_guest(arg, deny ? xen_deny() : saved_cmdline, len) )
> return -EFAULT;
> return 0;
> }
> +}
>
> return -ENOSYS;
> }
As said before, I don't think it is appropriate for "deny" to be
ignored for all other sub-ops when there is a designated policy.
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -55,3 +55,8 @@ const char *xen_banner(void)
> {
> return XEN_BANNER;
> }
> +
> +const char *xen_deny(void)
> +{
> +return "\0";
> +}
There's still this strange extra NUL character here.
> @@ -1621,6 +1622,28 @@ static int flask_pmu_op (struct domain *d, unsigned
> int op)
> }
> #endif /* CONFIG_X86 */
>
> +static int flask_version_op (uint32_t op)
> +{
> +u32 dsid = domain_sid(current->domain);
> +
> +switch ( op )
> +{
> +case XENVER_version:
> +case XENVER_extraversion:
> +case XENVER_compile_info:
> +case XENVER_capabilities:
> +case XENVER_changeset:
> +case XENVER_platform_parameters:
> +case XENVER_get_features:
> +case XENVER_pagesize:
> +case XENVER_guest_handle:
> +return 0; /* These MUST always be accessible to guests. */
> +default:
> +return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN2,
> +XEN2__VERSION_PRIV, NULL);
> +}
> +}
And along with the comment above, I don't think there should be
a switch statement here, but instead "op" should be subjected to
policy restrictions.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.2-testing test] 77852: regressions - FAIL
flight 77852 qemu-upstream-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/77852/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 62044 build-amd64 5 xen-build fail REGR. vs. 62044 Tests which did not succeed, but are not blocking: build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xend-qemuu-winxpsp3 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-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a version targeted for testing: qemuu5081fc1c773d2a83ec7a867f030323b8b6956cd1 baseline version: qemuuc17e602ae64fb24405ebd256679ba9a6f5819086 Last test of basis62044 2015-09-15 15:06:42 Z 119 days Testing same since66542 2015-12-18 16:37:10 Z 24 days 17 attempts People who touched revisions under test: Stefano Stabellini jobs: build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked test-amd64-i386-xend-qemuu-winxpsp3 blocked test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master 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 5081fc1c773d2a83ec7a867f030323b8b6956cd1 Author: Stefano Stabellini Date: Fri Dec 18 15:45:14 2015 + xenfb: avoid reading twice the same fields from the shared page Reading twice the same field could give the guest an attack of opportunity. In the case of event->type, gcc could compile the switch statement into a jump table, effectively ending up reading the type field multiple times. This is part of XSA-155. Signed-off-by: Stefano Stabellini commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6 Author: Stefano Stabellini Date: Fri Dec 18 15:44:58 2015 + xen/blkif: Avoid double access to src->nr_segments src is stored in shared memory and src->nr_segments is dereferenced twice at the end of the function. If a compiler decides to compile this into two separate memory accesses then the size limitation could be bypassed. Fix it by removing the double access to src->nr_segments. This is part of XSA-155. Signed-off-by: Stefano Stabellini
Re: [Xen-devel] [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)
>>> On 08.01.16 at 03:25, wrote:
> The mechanism to get this is via the XENVER hypercall and
> we add a new sub-command to retrieve the binary build-id
> called XENVER_build_id. The sub-hypercall parameter
> allows an arbitrary size (the buffer and len is provided
> to the hypervisor). A NULL parameter will probe the hypervisor
> for the length of the build-id.
>
> One can also retrieve the value of the build-id by doing
> 'readelf -h xen-syms'.
Does this or something similar also work on xen.gz and xen.efi?
I ask because xen-syms isn't present on the boot partition, and
may not be present anywhere on an otherwise functioning
system.
> --- a/Config.mk
> +++ b/Config.mk
> @@ -126,6 +126,17 @@ endef
> check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least
> gcc-4.1")
> $(eval $(check-y))
>
> +ld-ver = $(shell if [ $$((`$(1) --version | head -1 | sed 's/[^0-9]/ /g' |
> awk \
> + '{ printf "0x%02x%02x", $$1, $$2}'`)) -ge $$(($(2))) ]; \
> + then echo y; else echo n; fi ;)
> +
> +# binutils 2.18 implement build-id.
> +ifeq ($(call ld-ver,$(LD),0x0212),n)
> +build_id :=
> +else
> +build_id := --build-id=sha1
> +endif
Wouldn't it be better to probe the linker for recognizing the --build-id
command line option, along the lines of $(cc-option)?
In any event the option should be added to LDFLAGS unless this
conflicts with something else.
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -67,6 +67,12 @@ SECTIONS
> *(.rodata.*)
>} :text
>
> + .note.gnu.build-id : {
> + __note_gnu_build_id_start = .;
> + *(.note.gnu.build-id)
> + __note_gnu_build_id_end = .;
> + } :text
Wouldn't this better be a generic .note section, with .note.gnu.build-id
just special cased ahead of *(.note) *(.note.*)?
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -366,6 +366,41 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> return -EFAULT;
> return 0;
> }
> +case XENVER_build_id:
Blank line ahead of case statements please when most/all others
have it that way in a particular switch().
> +{
> +xen_build_id_t build_id;
> +unsigned int sz = 0;
> +int rc = 0;
> +char *p = NULL;
> +
> +if ( deny )
> +return -EPERM;
> +
> +/* Only return size. */
> +if ( !guest_handle_is_null(arg) )
> +{
> +if ( copy_from_guest(&build_id, arg, 1) )
> +return -EFAULT;
> +
> +if ( build_id.len == 0 )
> +return -EINVAL;
> +}
> +
> +rc = xen_build_id(&p, &sz);
Perhaps use the helpers from xen/err.h to limit the amount of
indirection needed?
> +if ( rc )
> +return rc;
> +
> +if ( guest_handle_is_null(arg) )
> +return sz;
> +
> +if ( sz > build_id.len )
> +return -ENOBUFS;
And how will the caller know how much is needed?
> +if ( copy_to_guest_offset(arg, offsetof(xen_build_id_t, buf), p, sz)
> )
> +return -EFAULT;
> +
> +return sz;
> +}
Or how much got copied?
> +int xen_build_id(char **p, unsigned int *len)
> +{
> +const Elf_Note *n = __note_gnu_build_id_start;
> +static bool_t checked = 0;
Pointless initializer.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release()
On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote:
> From: Davidlohr Bueso
>
> With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()")
> it was made clear that the context of this call (and thus set_mb)
> is strictly for CPU ordering, as opposed to IO. As such all archs
> should use the smp variant of mb(), respecting the semantics and
> saving a mandatory barrier on UP.
>
> Signed-off-by: Davidlohr Bueso
> Signed-off-by: Peter Zijlstra (Intel)
> Cc:
> Cc: Andrew Morton
> Cc: Benjamin Herrenschmidt
> Cc: Heiko Carstens
> Cc: Linus Torvalds
> Cc: Paul E. McKenney
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Tony Luck
> Cc: d...@stgolabs.net
> Link:
> http://lkml.kernel.org/r/1445975631-17047-3-git-send-email-d...@stgolabs.net
> Signed-off-by: Ingo Molnar
Aside from a need for s/lcoking/locking/ in the subject line:
Reviewed-by: Paul E. McKenney
> ---
> arch/ia64/include/asm/barrier.h| 2 +-
> arch/powerpc/include/asm/barrier.h | 2 +-
> arch/s390/include/asm/barrier.h| 2 +-
> include/asm-generic/barrier.h | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/ia64/include/asm/barrier.h b/arch/ia64/include/asm/barrier.h
> index df896a1..209c4b8 100644
> --- a/arch/ia64/include/asm/barrier.h
> +++ b/arch/ia64/include/asm/barrier.h
> @@ -77,7 +77,7 @@ do {
> \
> ___p1; \
> })
>
> -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); }
> while (0)
> +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); }
> while (0)
>
> /*
> * The group barrier in front of the rsm & ssm are necessary to ensure
> diff --git a/arch/powerpc/include/asm/barrier.h
> b/arch/powerpc/include/asm/barrier.h
> index 0eca6ef..a7af5fb 100644
> --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -34,7 +34,7 @@
> #define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
>
> -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); }
> while (0)
> +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); }
> while (0)
>
> #ifdef __SUBARCH_HAS_LWSYNC
> #define SMPWMB LWSYNC
> diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h
> index d68e11e..7ffd0b1 100644
> --- a/arch/s390/include/asm/barrier.h
> +++ b/arch/s390/include/asm/barrier.h
> @@ -36,7 +36,7 @@
> #define smp_mb__before_atomic() smp_mb()
> #define smp_mb__after_atomic() smp_mb()
>
> -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value);
> mb(); } while (0)
> +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb();
> } while (0)
>
> #define smp_store_release(p, v)
> \
> do { \
> diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
> index b42afad..0f45f93 100644
> --- a/include/asm-generic/barrier.h
> +++ b/include/asm-generic/barrier.h
> @@ -93,7 +93,7 @@
> #endif /* CONFIG_SMP */
>
> #ifndef smp_store_mb
> -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while
> (0)
> +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); }
> while (0)
> #endif
>
> #ifndef smp_mb__before_atomic
> --
> MST
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/2] xen/hvm: introduce a flags field in the CPU save record
>>> On 12.01.16 at 17:12, wrote:
> @@ -2087,19 +2100,21 @@ static int hvm_load_cpu_ctxt(struct domain *d,
> hvm_domain_context_t *h)
> seg.attr.bytes = ctxt.ldtr_arbytes;
> hvm_set_segment_register(v, x86_seg_ldtr, &seg);
>
> -/* In case xsave-absent save file is restored on a xsave-capable host */
> -if ( cpu_has_xsave && !xsave_enabled(v) )
> +v->fpu_initialised = !!(ctxt.flags & XEN_X86_FPU_INITIALISED);
> +if ( v->fpu_initialised )
> {
> -struct xsave_struct *xsave_area = v->arch.xsave_area;
> +memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
> +/* In case xsave-absent save file is restored on a xsave-capable
> host */
> +if ( cpu_has_xsave && !xsave_enabled(v) )
> +{
> +struct xsave_struct *xsave_area = v->arch.xsave_area;
>
> -memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
> -xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
> -if ( cpu_has_xsaves || cpu_has_xsavec )
> -xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
> - XSTATE_COMPACTION_ENABLED;
> +xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
> +if ( cpu_has_xsaves || cpu_has_xsavec )
> +xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
> + XSTATE_COMPACTION_ENABLED;
> +}
> }
> -else
> -memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
>
I would have expected this to simply be re-indentation, yet
you changed from if/else to just if with the else code done
ahead of it. If this really is intended, the commit message should
explain it.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/HVM: prune error labels in do_hvm_op()
On 12/01/16 16:00, Jan Beulich wrote: > I've got repeatedly annoyed by the bad naming: Make them slightly > better recognizable (and less likely to get mixed up), except in cases > where they can be eliminated altogether. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 05/41] powerpc: reuse asm-generic/barrier.h
On Sun, Jan 10, 2016 at 04:17:09PM +0200, Michael S. Tsirkin wrote:
> On powerpc read_barrier_depends, smp_read_barrier_depends
> smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the
> asm-generic variants exactly. Drop the local definitions and pull in
> asm-generic/barrier.h instead.
>
> This is in preparation to refactoring this code area.
>
> Signed-off-by: Michael S. Tsirkin
> Acked-by: Arnd Bergmann
Looks sane to me.
Reviewed-by: Paul E. McKenney
> ---
> arch/powerpc/include/asm/barrier.h | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/barrier.h
> b/arch/powerpc/include/asm/barrier.h
> index a7af5fb..980ad0c 100644
> --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -34,8 +34,6 @@
> #define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
>
> -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); }
> while (0)
> -
> #ifdef __SUBARCH_HAS_LWSYNC
> #define SMPWMB LWSYNC
> #else
> @@ -60,9 +58,6 @@
> #define smp_wmb()barrier()
> #endif /* CONFIG_SMP */
>
> -#define read_barrier_depends() do { } while (0)
> -#define smp_read_barrier_depends() do { } while (0)
> -
> /*
> * This is a barrier which prevents following instructions from being
> * started until the value of the argument x is known. For example, if
> @@ -87,8 +82,8 @@ do {
> \
> ___p1; \
> })
>
> -#define smp_mb__before_atomic() smp_mb()
> -#define smp_mb__after_atomic() smp_mb()
> #define smp_mb__before_spinlock() smp_mb()
>
> +#include
> +
> #endif /* _ASM_POWERPC_BARRIER_H */
> --
> MST
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall.
On Mon, Jan 11, 2016 at 09:17:57AM -0700, Jan Beulich wrote:
> >>> On 11.01.16 at 17:01, wrote:
> > On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote:
> >> >>> On 08.01.16 at 18:31, wrote:
> >> >> >> > The rest: XENVER_[version|capabilities|
> >> >> >> > parameters|get_features|page_size|guest_handle] behave
> >> >> >> > as before - allowed by default for all guests.
> >> >> >> >
> >> >> >> > This is with the XSM default policy and with the dummy ones.
> >> >> >>
> >> >> >> And with a non-default policy you now ignore one of the latter
> >> >> >> ops to also get denied.
> >> >> >
> >> >> > No, but that is due to the 'deny' being only checked for certain
> >> >> > subops.
> >> >>
> >> >> To me this reply seems contradictory in itself: The "no" doesn't
> >> >> seem to match up with the rest.
> >> >>
> >> >> > I think what you are saying is that for XENVER_[version|capabilities|
> >> >> > parameters|get_features|page_size|guest_handle] we should not have any
> >> >> > XSM checks as they serve no purpose (which is what I had in the
> >> >> > earlier
> >> >> > versions of this patch). However Andrew mentioned that he would
> >> >> > like _ALL_ of the sub-ops to be checked for.
> >> >>
> >> >> And I agree with Andrew, hence my earlier comment above (with
> >> >> the reply I can't really make sense of).
> >> >
> >> > I am all confused now.
> >> >
> >> > There are two parts here:
> >> > a) The XSM checks - which allow the XENVER_version..XENVER_guest_handle
> >> >without any hinderance. For XENVER_commandline and XENVER_buildid
> >> >they are evaluated.
> >> >
> >> > b) Acting on the XSM check. For most of them we cannot actually return
> >> >-EFAULT and MUST return either an valid value or some form of a
> >> > string.
> >> >
> >> >The ones for which we could return '' were changeset,
> >> > compile_info,
> >> >commandline, extraversion. To make it simpler we only do it for
> >> >commandline.
> >> >
> >> > In essence we have an XSM check which is ignored by all XENVER_ subops
> >> > except commandline (and build_id in later patch).
> >> >
> >> > I think both of you are OK with that?
> >>
> >> Iirc Andrew's request was to honor XSM denies on any sub-op
> >> when a non-default policy is in place. Whereas in default mode
> >> only command line and build id are the ones clearly needing
> >> restricting. Which won't be possible if you ignore the return
> >> value of the XSM check in some of the cases.
> >
> > That means we need two (as earlier patches had it) version labels.
> > One for the command_line and build_id (version_priv) and one for
> > the rest (version_use). By default version_use would be available
> > to every guest. If a non-default policy wants to mess with it - that is OK.
>
> That would seem a little too coarse grained. Why can't we keep it
> at the sub-op level, just that the default is "OK" for everything
> except the two?
So you thinking have a whole new XSM 'class' for this hypercall?
As in (not compile tested of course):
diff --git a/tools/flask/policy/policy/modules/xen/xen.te
b/tools/flask/policy/policy/modules/xen/xen.te
index 17f304e..fca5809 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -141,6 +141,13 @@ if (guest_writeconsole) {
# pmu_ctrl is for)
allow domain_type xen_t:xen2 pmu_use;
+allow dom0_t version:domain {
+version parameters ... commandline build_id
+};
+allow domain_type version:domain {
+version parameters ...
+}
+
###
#
# Domain creation
diff --git a/xen/xsm/flask/policy/access_vectors
b/xen/xsm/flask/policy/access_vectors
index c123256..4b20d08 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -246,6 +246,18 @@ class domain2
psr_cat_op
}
+# defined by XENVER_hypercall
+class xenver
+{
+# XENVER_version
+version
+# XENVER_parameters
+parameters
+# ... snip..
+commandline
+build_id
+}
+
# Similar to class domain, but primarily contains domctls related to HVM
domains
class hvm
{
>
> > Now comes the big question - for the XENVER_[version|capabilities|
> > parameters|get_features|page_size|guest_handle] - if it is denied
> > (so non-default version_use policy) - what should we return?
>
> "" just like for the others that return strings; page_size
> and other numeric ones may need to return zero.
>
> > I can return '' for the strings, but what should we do
> > for the page_size, capabilities and guest_handle ? -EPERM?
>
> guest_handle is particularly interesting: It seems to make very
> little sense to deny a guest access to its own handle.
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] xsm/xen_version: Add XSM for the xen_version hypercall.
>>> On 12.01.16 at 17:37, wrote: > On Mon, Jan 11, 2016 at 09:17:57AM -0700, Jan Beulich wrote: >> >>> On 11.01.16 at 17:01, wrote: >> > On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote: >> >> >>> On 08.01.16 at 18:31, wrote: >> >> >> >> > The rest: XENVER_[version|capabilities| >> >> >> >> > parameters|get_features|page_size|guest_handle] behave >> >> >> >> > as before - allowed by default for all guests. >> >> >> >> > >> >> >> >> > This is with the XSM default policy and with the dummy ones. >> >> >> >> >> >> >> >> And with a non-default policy you now ignore one of the latter >> >> >> >> ops to also get denied. >> >> >> > >> >> >> > No, but that is due to the 'deny' being only checked for certain >> >> >> > subops. >> >> >> >> >> >> To me this reply seems contradictory in itself: The "no" doesn't >> >> >> seem to match up with the rest. >> >> >> >> >> >> > I think what you are saying is that for XENVER_[version|capabilities| >> >> >> > parameters|get_features|page_size|guest_handle] we should not have >> >> >> > any >> >> >> > XSM checks as they serve no purpose (which is what I had in the >> >> >> > earlier >> >> >> > versions of this patch). However Andrew mentioned that he would >> >> >> > like _ALL_ of the sub-ops to be checked for. >> >> >> >> >> >> And I agree with Andrew, hence my earlier comment above (with >> >> >> the reply I can't really make sense of). >> >> > >> >> > I am all confused now. >> >> > >> >> > There are two parts here: >> >> > a) The XSM checks - which allow the XENVER_version..XENVER_guest_handle >> >> >without any hinderance. For XENVER_commandline and XENVER_buildid >> >> >they are evaluated. >> >> > >> >> > b) Acting on the XSM check. For most of them we cannot actually return >> >> >-EFAULT and MUST return either an valid value or some form of a >> >> > string. >> >> > >> >> >The ones for which we could return '' were changeset, > compile_info, >> >> >commandline, extraversion. To make it simpler we only do it for >> >> >commandline. >> >> > >> >> > In essence we have an XSM check which is ignored by all XENVER_ subops >> >> > except commandline (and build_id in later patch). >> >> > >> >> > I think both of you are OK with that? >> >> >> >> Iirc Andrew's request was to honor XSM denies on any sub-op >> >> when a non-default policy is in place. Whereas in default mode >> >> only command line and build id are the ones clearly needing >> >> restricting. Which won't be possible if you ignore the return >> >> value of the XSM check in some of the cases. >> > >> > That means we need two (as earlier patches had it) version labels. >> > One for the command_line and build_id (version_priv) and one for >> > the rest (version_use). By default version_use would be available >> > to every guest. If a non-default policy wants to mess with it - that is OK. >> >> That would seem a little too coarse grained. Why can't we keep it >> at the sub-op level, just that the default is "OK" for everything >> except the two? > > So you thinking have a whole new XSM 'class' for this hypercall? Yes, subject to Daniel's input it seems to me that's the only way providing the necessary granularity. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 12/13] vmx: Add VMX RDTSC(P) scaling support
>>> On 31.12.15 at 04:03, wrote:
> @@ -2003,6 +2011,10 @@ static struct hvm_function_table __initdata
> vmx_function_table = {
> .altp2m_vcpu_update_vmfunc_ve = vmx_vcpu_update_vmfunc_ve,
> .altp2m_vcpu_emulate_ve = vmx_vcpu_emulate_ve,
> .altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
> +.default_tsc_scaling_ratio = VMX_TSC_MULTIPLIER_DEFAULT,
> +.max_tsc_scaling_ratio = VMX_TSC_MULTIPLIER_MAX,
> +.tsc_scaling_ratio_frac_bits = 48,
> +.setup_tsc_scaling = vmx_setup_tsc_scaling,
> };
>
> /* Handle VT-d posted-interrupt when VCPU is running. */
> @@ -2107,6 +2119,9 @@ const struct hvm_function_table * __init start_vmx(void)
> && cpu_has_vmx_secondary_exec_control )
> vmx_function_table.pvh_supported = 1;
>
> +if ( cpu_has_vmx_tsc_scaling )
> +vmx_function_table.tsc_scaling_supported = 1;
Do you actually still need this separate flag field? I.e. can't you
derive this from one of the other four fields?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 77827: regressions - FAIL
osstest service owner writes ("[xen-unstable test] 77827: regressions - FAIL"):
> flight 77827 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/77827/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install
> fail REGR. vs. 66879
Looking at
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
and
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/ALL
it seems that this test has been intermittently broken on most osstest
branches for some time. 66879 was an [un]lucky pass. (The symptoms,
and hence the specific test step which fails, seem to vary according
to the host.)
I am therefore going to force push this.
We had a discussion on IRC. Several people were of the opinion that
32-bit stubdom will be hard to fix and that the effort won't be worth
it.
If we are going to abandon this then we should switch to 64-bit
stubdom dm in 32-bit dom0 configurations, and certainly not any longer
build a probably-broken 32-bit stubdom dm along with the 32-bit tools.
> version targeted for testing:
> xen f7347a282420a5edc74afb31e7c42c2765f24de5
> baseline version:
> xen bf925a9f1254391749f569c1b8fc606036340488
I have pushed this version.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 09/13] x86/hvm: Replace architecture TSC scaling by a common function
>>> On 31.12.15 at 04:03, wrote: > This patch implements a common function hvm_scale_tsc() to scale TSC by > using TSC scaling information collected by architecture code. > > Signed-off-by: Haozhong Zhang > Reviewed-by: Kevin Tian (except the mul64 part) The tail of this should have been dropped with ... > --- > Changes in v3: > (addressing Boris Ostrovsky's comments) > * Remove unnecessary assertions in hvm_scale_tsc(). > * Move math64 stuffs to a standalone patch and state their origination. ... this. Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)
On Tue, Jan 12, 2016 at 09:25:27AM -0700, Jan Beulich wrote:
> >>> On 08.01.16 at 03:25, wrote:
> > The mechanism to get this is via the XENVER hypercall and
> > we add a new sub-command to retrieve the binary build-id
> > called XENVER_build_id. The sub-hypercall parameter
> > allows an arbitrary size (the buffer and len is provided
> > to the hypervisor). A NULL parameter will probe the hypervisor
> > for the length of the build-id.
> >
> > One can also retrieve the value of the build-id by doing
> > 'readelf -h xen-syms'.
>
> Does this or something similar also work on xen.gz and xen.efi?
Sadly no.
> I ask because xen-syms isn't present on the boot partition, and
> may not be present anywhere on an otherwise functioning
> system.
Right. Some later patches (xsplice related) hook the build-id printing
to a keyboard handler. Would that work ?
Or are you suggesting that perhaps the kernel should at boot time
print the build-id (like it does the changset)?
>
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -126,6 +126,17 @@ endef
> > check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least
> > gcc-4.1")
> > $(eval $(check-y))
> >
> > +ld-ver = $(shell if [ $$((`$(1) --version | head -1 | sed 's/[^0-9]/ /g' |
> > awk \
> > + '{ printf "0x%02x%02x", $$1, $$2}'`)) -ge $$(($(2))) ]; \
> > + then echo y; else echo n; fi ;)
> > +
> > +# binutils 2.18 implement build-id.
> > +ifeq ($(call ld-ver,$(LD),0x0212),n)
> > +build_id :=
> > +else
> > +build_id := --build-id=sha1
> > +endif
>
> Wouldn't it be better to probe the linker for recognizing the --build-id
> command line option, along the lines of $(cc-option)?
Let me see what happens with that.
>
> In any event the option should be added to LDFLAGS unless this
> conflicts with something else.
>
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.S
> > @@ -67,6 +67,12 @@ SECTIONS
> > *(.rodata.*)
> >} :text
> >
> > + .note.gnu.build-id : {
> > + __note_gnu_build_id_start = .;
> > + *(.note.gnu.build-id)
> > + __note_gnu_build_id_end = .;
> > + } :text
>
> Wouldn't this better be a generic .note section, with .note.gnu.build-id
> just special cased ahead of *(.note) *(.note.*)?
>
> > --- a/xen/common/kernel.c
> > +++ b/xen/common/kernel.c
> > @@ -366,6 +366,41 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> > arg)
> > return -EFAULT;
> > return 0;
> > }
> > +case XENVER_build_id:
>
> Blank line ahead of case statements please when most/all others
> have it that way in a particular switch().
>
> > +{
> > +xen_build_id_t build_id;
> > +unsigned int sz = 0;
> > +int rc = 0;
> > +char *p = NULL;
> > +
> > +if ( deny )
> > +return -EPERM;
> > +
> > +/* Only return size. */
> > +if ( !guest_handle_is_null(arg) )
> > +{
> > +if ( copy_from_guest(&build_id, arg, 1) )
> > +return -EFAULT;
> > +
> > +if ( build_id.len == 0 )
> > +return -EINVAL;
> > +}
> > +
> > +rc = xen_build_id(&p, &sz);
>
> Perhaps use the helpers from xen/err.h to limit the amount of
> indirection needed?
>
> > +if ( rc )
> > +return rc;
> > +
> > +if ( guest_handle_is_null(arg) )
> > +return sz;
> > +
> > +if ( sz > build_id.len )
> > +return -ENOBUFS;
>
> And how will the caller know how much is needed?
Duh. I shall update the build_id.len with the appropiate value.
>
> > +if ( copy_to_guest_offset(arg, offsetof(xen_build_id_t, buf), p,
> > sz) )
> > +return -EFAULT;
> > +
> > +return sz;
> > +}
>
> Or how much got copied?
That one is easy - we do return 'sz' which tells us how much got copied.
Or are you suggesting that the build_id.len should also be updated?
>
> > +int xen_build_id(char **p, unsigned int *len)
> > +{
> > +const Elf_Note *n = __note_gnu_build_id_start;
> > +static bool_t checked = 0;
>
> Pointless initializer.
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] QEMU as non-root and PCI passthrough do not mix
PCI passthrough cannot work if QEMU is run as a non-root process today,
as QEMU needs to open /dev/mem to mmap the MSI-X table of the device and
read/write relevant nodes on sysfs.
Update the docs to reflect that.
Run QEMU as root and print a warning if at least one PCI device has been
assigned to the guest at domain creation. Print a debug message on pci
hotplug.
Signed-off-by: Stefano Stabellini
diff --git a/docs/misc/qemu-deprivilege.txt b/docs/misc/qemu-deprivilege.txt
index dde74ab..cf52547 100644
--- a/docs/misc/qemu-deprivilege.txt
+++ b/docs/misc/qemu-deprivilege.txt
@@ -29,3 +29,13 @@ adduser --no-create-home --system xen-qemuuser-shared
3) root
As a last resort, libxl will start QEMU as root.
+
+
+Please note that QEMU will still be run as root when PCI devices are
+assigned to the virtual machine (if you specified pci=["$PCI_BDF"] in
+your VM config file, where $PCI_BDF is the PCI BDF of the device you
+want to assign). If you want to hotplug a PCI device sometime after the
+VM has started, you need to make sure that the QEMU instance of that VM
+has root privileges (for example by not specifying either
+xen-qemuuser-shared or xen-qemuuser-domid$domid, or by giving root
+privileges to xen-qemuuser-domid$domid).
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 0aaefd9..6b98750 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1254,6 +1254,12 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
break;
}
+/* Do not run QEMU as non-root if PCI devices are assigned */
+if (guest_config->num_pcidevs > 0) {
+LOG(WARN, "Cannot run QEMU as non-root when PCI devices are being
assigned to the guest VM");
+goto end_search;
+}
+
if (b_info->device_model_user) {
user = b_info->device_model_user;
goto end_search;
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index dc10cb7..04d0dd4 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1176,6 +1176,9 @@ int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid,
{
AO_CREATE(ctx, domid, ao_how);
int rc;
+
+LOG(DEBUG, "QEMU needs to be run as root for PCI passthrough to work");
+
rc = libxl__device_pci_add(gc, domid, pcidev, 0);
libxl__ao_complete(egc, ao, rc);
return AO_INPROGRESS;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 0/2] memory-hotplug: add automatic onlining policy for the newly added memory
Changes since v3:
- Add support for the policy to Xen balloon driver [Daniel Kiper, David Vrabel]
- I found an issue with PATCH v3: when memory auto onlining was requested we
do nothing to memblocks states so in sysfs they stay 'offline' (while in
reality they're online). Modify register_new_memory() (and its only caller,
__add_section()) to create memblocks in the proper state.
Original description:
Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
to make this happen automatically. This is not a great solution for virtual
machines where memory hotplug is being used to address high memory pressure
situations as such onlining is slow and a userspace process doing this
(udev) has a chance of being killed by the OOM killer as it will probably
require to allocate some memory.
Introduce default policy for the newly added memory blocks in
/sys/devices/system/memory/auto_online_blocks file with two possible
values: "offline" which preserves the current behavior and "online" which
causes all newly added memory blocks to go online as soon as they're added.
The default is "offline".
Vitaly Kuznetsov (2):
memory-hotplug: add automatic onlining policy for the newly added
memory
xen_balloon: support memory auto onlining policy
Documentation/memory-hotplug.txt | 19 +++
drivers/base/memory.c| 40
drivers/xen/Kconfig | 20 +---
drivers/xen/balloon.c| 30 +++---
include/linux/memory.h | 3 ++-
include/linux/memory_hotplug.h | 4 +++-
mm/memory_hotplug.c | 18 +++---
7 files changed, 103 insertions(+), 31 deletions(-)
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/2] xen_balloon: support memory auto onlining policy
Add support for the newly added kernel memory auto onlining policy to Xen
ballon driver.
Suggested-by: Daniel Kiper
Signed-off-by: Vitaly Kuznetsov
---
drivers/xen/Kconfig | 20 +---
drivers/xen/balloon.c | 30 +++---
2 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..098ab49 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -37,23 +37,29 @@ config XEN_BALLOON_MEMORY_HOTPLUG
Memory could be hotplugged in following steps:
- 1) dom0: xl mem-max
+ 1) domU: ensure that memory auto online policy is in effect by
+ checking /sys/devices/system/memory/auto_online_blocks file
+ (should be 'online').
+
+ 2) dom0: xl mem-max
where is >= requested memory size,
- 2) dom0: xl mem-set
+ 3) dom0: xl mem-set
where is requested memory size; alternatively memory
could be added by writing proper value to
/sys/devices/system/xen_memory/xen_memory0/target or
/sys/devices/system/xen_memory/xen_memory0/target_kb on dumU,
- 3) domU: for i in /sys/devices/system/memory/memory*/state; do \
- [ "`cat "$i"`" = offline ] && echo online > "$i"; done
+ Alternatively, if memory auto onlining was not requested at step 1
+ the newly added memory can be manually onlined in domU by doing the
+ following:
- Memory could be onlined automatically on domU by adding following
line to udev rules:
+ for i in /sys/devices/system/memory/memory*/state; do \
+ [ "`cat "$i"`" = offline ] && echo online > "$i"; done
- SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f
/sys$devpath/state ] && echo online > /sys$devpath/state'"
+ or by adding the following line to udev rules:
- In that case step 3 should be omitted.
+ SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f
/sys$devpath/state ] && echo online > /sys$devpath/state'"
config XEN_BALLOON_MEMORY_HOTPLUG_LIMIT
int "Hotplugged memory limit (in GiB) for a PV guest"
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 890c3b5..68f0aa2 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -284,7 +284,7 @@ static void release_memory_resource(struct resource
*resource)
kfree(resource);
}
-static enum bp_state reserve_additional_memory(void)
+static enum bp_state reserve_additional_memory(bool online)
{
long credit;
struct resource *resource;
@@ -338,7 +338,18 @@ static enum bp_state reserve_additional_memory(void)
}
#endif
- rc = add_memory_resource(nid, resource, false);
+ /*
+* add_memory_resource() will call online_pages() which in its turn
+* will call xen_online_page() callback causing deadlock if we don't
+* release balloon_mutex here. It is safe because there can only be
+* one balloon_process() running at a time and balloon_mutex is
+* internal to Xen driver, generic memory hotplug code doesn't mess
+* with it.
+*/
+ mutex_unlock(&balloon_mutex);
+ rc = add_memory_resource(nid, resource, online);
+ mutex_lock(&balloon_mutex);
+
if (rc) {
pr_warn("Cannot add additional memory (%i)\n", rc);
goto err;
@@ -562,14 +573,11 @@ static void balloon_process(struct work_struct *work)
credit = current_credit();
- if (credit > 0) {
- if (balloon_is_inflated())
- state = increase_reservation(credit);
- else
- state = reserve_additional_memory();
- }
-
- if (credit < 0)
+ if (credit > 0 && balloon_is_inflated())
+ state = increase_reservation(credit);
+ else if (credit > 0)
+ state = reserve_additional_memory(memhp_auto_online);
+ else if (credit < 0)
state = decrease_reservation(-credit, GFP_BALLOON);
state = update_schedule(state);
@@ -599,7 +607,7 @@ static int add_ballooned_pages(int nr_pages)
enum bp_state st;
if (xen_hotplug_unpopulated) {
- st = reserve_additional_memory();
+ st = reserve_additional_memory(false);
if (st != BP_ECANCELED) {
mutex_unlock(&balloon_mutex);
wait_event(balloon_wq,
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/2] memory-hotplug: add automatic onlining policy for the newly added memory
Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
to make this happen automatically. This is not a great solution for virtual
machines where memory hotplug is being used to address high memory pressure
situations as such onlining is slow and a userspace process doing this
(udev) has a chance of being killed by the OOM killer as it will probably
require to allocate some memory.
Introduce default policy for the newly added memory blocks in
/sys/devices/system/memory/auto_online_blocks file with two possible
values: "offline" which preserves the current behavior and "online" which
causes all newly added memory blocks to go online as soon as they're added.
The default is "offline".
Signed-off-by: Vitaly Kuznetsov
---
Documentation/memory-hotplug.txt | 19 +++
drivers/base/memory.c| 40
drivers/xen/balloon.c| 2 +-
include/linux/memory.h | 3 ++-
include/linux/memory_hotplug.h | 4 +++-
mm/memory_hotplug.c | 18 +++---
6 files changed, 72 insertions(+), 14 deletions(-)
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index ce2cfcf..ceaf40c 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -254,12 +254,23 @@ If the memory block is online, you'll read "online".
If the memory block is offline, you'll read "offline".
-5.2. How to online memory
+5.2. Memory onlining
-Even if the memory is hot-added, it is not at ready-to-use state.
-For using newly added memory, you have to "online" the memory block.
+When the memory is hot-added, the kernel decides whether or not to "online"
+it according to the policy which can be read from "auto_online_blocks" file:
-For onlining, you have to write "online" to the memory block's state file as:
+% cat /sys/devices/system/memory/auto_online_blocks
+
+The default is "offline" which means the newly added memory is not in a
+ready-to-use state and you have to "online" the newly added memory blocks
+manually. Automatic onlining can be requested by writing "online" to
+"auto_online_blocks" file:
+
+% echo online > /sys/devices/system/memory/auto_online_blocks
+
+If the automatic onlining wasn't requested or some memory block was offlined
+it is possible to change the individual block's state by writing to the "state"
+file:
% echo online > /sys/devices/system/memory/memoryXXX/state
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 25425d3..7008edc 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -439,6 +439,37 @@ print_block_size(struct device *dev, struct
device_attribute *attr,
static DEVICE_ATTR(block_size_bytes, 0444, print_block_size, NULL);
/*
+ * Memory auto online policy.
+ */
+
+static ssize_t
+show_auto_online_blocks(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ if (memhp_auto_online)
+ return sprintf(buf, "online\n");
+ else
+ return sprintf(buf, "offline\n");
+}
+
+static ssize_t
+store_auto_online_blocks(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ if (sysfs_streq(buf, "online"))
+ memhp_auto_online = true;
+ else if (sysfs_streq(buf, "offline"))
+ memhp_auto_online = false;
+ else
+ return -EINVAL;
+
+ return count;
+}
+
+static DEVICE_ATTR(auto_online_blocks, 0644, show_auto_online_blocks,
+ store_auto_online_blocks);
+
+/*
* Some architectures will have custom drivers to do this, and
* will not need to do it from userspace. The fake hot-add code
* as well as ppc64 will do all of their discovery in userspace
@@ -654,10 +685,10 @@ static int add_memory_block(int base_section_nr)
/*
- * need an interface for the VM to add new memory regions,
- * but without onlining it.
+ * add new memory regions keeping their state.
*/
-int register_new_memory(int nid, struct mem_section *section)
+int register_new_memory(int nid, struct mem_section *section,
+ unsigned long state)
{
int ret = 0;
struct memory_block *mem;
@@ -669,7 +700,7 @@ int register_new_memory(int nid, struct mem_section
*section)
mem->section_count++;
put_device(&mem->dev);
} else {
- ret = init_memory_block(&mem, section, MEM_OFFLINE);
+ ret = init_memory_block(&mem, section, state);
if (ret)
goto out;
}
@@ -737,6 +768,7 @@ static struct attribute *memory_root_attrs[] = {
#endif
&dev_attr_block_size_bytes.attr,
+ &dev_attr_auto_online_blocks.attr,
NULL
};
Re: [Xen-devel] [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)
>>> On 12.01.16 at 17:43, wrote: > On Tue, Jan 12, 2016 at 09:25:27AM -0700, Jan Beulich wrote: >> >>> On 08.01.16 at 03:25, wrote: >> > The mechanism to get this is via the XENVER hypercall and >> > we add a new sub-command to retrieve the binary build-id >> > called XENVER_build_id. The sub-hypercall parameter >> > allows an arbitrary size (the buffer and len is provided >> > to the hypervisor). A NULL parameter will probe the hypervisor >> > for the length of the build-id. >> > >> > One can also retrieve the value of the build-id by doing >> > 'readelf -h xen-syms'. >> >> Does this or something similar also work on xen.gz and xen.efi? > > Sadly no. >> I ask because xen-syms isn't present on the boot partition, and >> may not be present anywhere on an otherwise functioning >> system. > > Right. Some later patches (xsplice related) hook the build-id printing > to a keyboard handler. Would that work ? Key handlers are strictly a debugging facility. > Or are you suggesting that perhaps the kernel should at boot time > print the build-id (like it does the changset)? Perhaps, albeit to me that's a bit orthogonal to being able to find out the build ID for a given binary. >> > +if ( rc ) >> > +return rc; >> > + >> > +if ( guest_handle_is_null(arg) ) >> > +return sz; >> > + >> > +if ( sz > build_id.len ) >> > +return -ENOBUFS; >> >> And how will the caller know how much is needed? > > Duh. I shall update the build_id.len with the appropiate value. Ah, actually I now see you have Andrew's beloved NULL handle check up a few lines - that may suffice. Albeit I'm not generally in favor of this model; I prefer a first attempt to succeed if possible, and a second one only to be needed if the caller estimated size in fact didn't suffice (and then no 3rd one being necessary in order to obtain the needed size). >> > +if ( copy_to_guest_offset(arg, offsetof(xen_build_id_t, buf), p, >> > sz) ) >> > +return -EFAULT; >> > + >> > +return sz; >> > +} >> >> Or how much got copied? > > That one is easy - we do return 'sz' which tells us how much got copied. Ah, right. Perhaps I shouldn't be reviewing patches a few minutes before heading home... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
On Tue, 12 Jan 2016, Jan Beulich wrote: > >>> On 12.01.16 at 13:07, wrote: > > On Mon, 11 Jan 2016, David Vrabel wrote: > >> On 11/01/16 17:17, Andrew Cooper wrote: > >> > So from one point of view, sufficient justification for this change is > >> > "because the Linux way isn't the only valid way to do this". > >> > >> "Because we can" isn't a good justification for adding something new. > >> Particularly something that is trivially easy to (accidentally) misuse > >> and open a big security hole between userspace and kernel. > >> > >> The vague idea for a userspace netfront that's floating around > >> internally is also not a good reason for pushing this feature at this time. > > > > I agree with David, but I might have another good use case for this. > > > > Consider the following scenario: we have a Xen HVM guest, with Xen > > installed inside of it (nested virtualization). I'll refer to Xen > > running on the host as L0 Xen and Xen running inside the VM as L1 Xen. > > Similarly we have two dom0 running, the one with access to the physical > > hardware, L0 Dom0, and the one running inside the VM, L1 Dom0. > > > > Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV > > frontend drivers, netfront and blkfront to speed up execution. In order > > to do that, the first thing it needs to do is making an hypercall to L0 > > Xen. That's because netfront and blkfront needs to communicate with > > netback and blkback in L0 Dom0: event channels and grant tables are the > > ones provided by L0 Xen. > > That's again a layering violation (bypassing the L1 hypervisor). True, but in this scenario it might be necessary for performance reasons: otherwise every hypercall would need to bounce off L1 Xen, possibly cancelling the benefits of running netfront and blkfront in the first place. I don't have numbers though. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
On 12/01/16 18:05, Stefano Stabellini wrote: > On Tue, 12 Jan 2016, Jan Beulich wrote: > On 12.01.16 at 13:07, wrote: >>> On Mon, 11 Jan 2016, David Vrabel wrote: On 11/01/16 17:17, Andrew Cooper wrote: > So from one point of view, sufficient justification for this change is > "because the Linux way isn't the only valid way to do this". "Because we can" isn't a good justification for adding something new. Particularly something that is trivially easy to (accidentally) misuse and open a big security hole between userspace and kernel. The vague idea for a userspace netfront that's floating around internally is also not a good reason for pushing this feature at this time. >>> >>> I agree with David, but I might have another good use case for this. >>> >>> Consider the following scenario: we have a Xen HVM guest, with Xen >>> installed inside of it (nested virtualization). I'll refer to Xen >>> running on the host as L0 Xen and Xen running inside the VM as L1 Xen. >>> Similarly we have two dom0 running, the one with access to the physical >>> hardware, L0 Dom0, and the one running inside the VM, L1 Dom0. >>> >>> Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV >>> frontend drivers, netfront and blkfront to speed up execution. In order >>> to do that, the first thing it needs to do is making an hypercall to L0 >>> Xen. That's because netfront and blkfront needs to communicate with >>> netback and blkback in L0 Dom0: event channels and grant tables are the >>> ones provided by L0 Xen. >> >> That's again a layering violation (bypassing the L1 hypervisor). > > True, but in this scenario it might be necessary for performance > reasons: otherwise every hypercall would need to bounce off L1 Xen, > possibly cancelling the benefits of running netfront and blkfront in the > first place. I don't have numbers though. How is this supposed to work? How can dom0 make hypercalls to L1 _or_ L0 hypervisor? How can it select the hypervisor it is talking to? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
On Tue, 12 Jan 2016, Juergen Gross wrote: > On 12/01/16 18:05, Stefano Stabellini wrote: > > On Tue, 12 Jan 2016, Jan Beulich wrote: > > On 12.01.16 at 13:07, wrote: > >>> On Mon, 11 Jan 2016, David Vrabel wrote: > On 11/01/16 17:17, Andrew Cooper wrote: > > So from one point of view, sufficient justification for this change is > > "because the Linux way isn't the only valid way to do this". > > "Because we can" isn't a good justification for adding something new. > Particularly something that is trivially easy to (accidentally) misuse > and open a big security hole between userspace and kernel. > > The vague idea for a userspace netfront that's floating around > internally is also not a good reason for pushing this feature at this > time. > >>> > >>> I agree with David, but I might have another good use case for this. > >>> > >>> Consider the following scenario: we have a Xen HVM guest, with Xen > >>> installed inside of it (nested virtualization). I'll refer to Xen > >>> running on the host as L0 Xen and Xen running inside the VM as L1 Xen. > >>> Similarly we have two dom0 running, the one with access to the physical > >>> hardware, L0 Dom0, and the one running inside the VM, L1 Dom0. > >>> > >>> Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV > >>> frontend drivers, netfront and blkfront to speed up execution. In order > >>> to do that, the first thing it needs to do is making an hypercall to L0 > >>> Xen. That's because netfront and blkfront needs to communicate with > >>> netback and blkback in L0 Dom0: event channels and grant tables are the > >>> ones provided by L0 Xen. > >> > >> That's again a layering violation (bypassing the L1 hypervisor). > > > > True, but in this scenario it might be necessary for performance > > reasons: otherwise every hypercall would need to bounce off L1 Xen, > > possibly cancelling the benefits of running netfront and blkfront in the > > first place. I don't have numbers though. > > How is this supposed to work? How can dom0 make hypercalls to L1 _or_ L0 > hypervisor? How can it select the hypervisor it is talking to? >From L0 Xen point of view, the guest is just a normal PV on HVM guest, it doesn't matter what's inside, so L1 Dom0 is going to make hypercalls to L0 Xen like any other PV on HVM guests: mapping the hypercall page by writing to the right MSR, retrieved via cpuid, then calling into the hypercall page. L0 Xen would populate the hypercall page as usual for PV on HVM guests, using vmcall instructions. However once that is done, L0 Xen would still refuse the hypercalls because they are issued from ring 3. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/2] xen_balloon: support memory auto onlining policy
On 12/01/16 16:56, Vitaly Kuznetsov wrote:
> Add support for the newly added kernel memory auto onlining policy to Xen
> ballon driver.
[...]
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -37,23 +37,29 @@ config XEN_BALLOON_MEMORY_HOTPLUG
>
> Memory could be hotplugged in following steps:
>
> - 1) dom0: xl mem-max
> + 1) domU: ensure that memory auto online policy is in effect by
> +checking /sys/devices/system/memory/auto_online_blocks file
> +(should be 'online').
Step 1 applies to dom0 and domUs.
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -284,7 +284,7 @@ static void release_memory_resource(struct resource
> *resource)
> kfree(resource);
> }
>
> -static enum bp_state reserve_additional_memory(void)
> +static enum bp_state reserve_additional_memory(bool online)
> {
> long credit;
> struct resource *resource;
> @@ -338,7 +338,18 @@ static enum bp_state reserve_additional_memory(void)
> }
> #endif
>
> - rc = add_memory_resource(nid, resource, false);
> + /*
> + * add_memory_resource() will call online_pages() which in its turn
> + * will call xen_online_page() callback causing deadlock if we don't
> + * release balloon_mutex here. It is safe because there can only be
> + * one balloon_process() running at a time and balloon_mutex is
> + * internal to Xen driver, generic memory hotplug code doesn't mess
> + * with it.
There are multiple callers of reserve_additional_memory() and these are
not all serialized via the balloon process. Replace the "It is safe..."
sentence with:
"Unlocking here is safe because the callers drop the mutex before trying
again."
> + */
> + mutex_unlock(&balloon_mutex);
> + rc = add_memory_resource(nid, resource, online);
This should always be memhp_auto_online, because...
> @@ -562,14 +573,11 @@ static void balloon_process(struct work_struct *work)
>
> credit = current_credit();
>
> - if (credit > 0) {
> - if (balloon_is_inflated())
> - state = increase_reservation(credit);
> - else
> - state = reserve_additional_memory();
> - }
> -
> - if (credit < 0)
> + if (credit > 0 && balloon_is_inflated())
> + state = increase_reservation(credit);
> + else if (credit > 0)
> + state = reserve_additional_memory(memhp_auto_online);
> + else if (credit < 0)
> state = decrease_reservation(-credit, GFP_BALLOON);
I'd have preferred this refactored as:
if (credit > 0) {
if (balloon_is_inflated())
...
else
...
} else if (credit < 0) {
...
}
>
> state = update_schedule(state);
> @@ -599,7 +607,7 @@ static int add_ballooned_pages(int nr_pages)
> enum bp_state st;
>
> if (xen_hotplug_unpopulated) {
> - st = reserve_additional_memory();
> + st = reserve_additional_memory(false);
... we want to auto-online this memory as well.
> if (st != BP_ECANCELED) {
> mutex_unlock(&balloon_mutex);
> wait_event(balloon_wq,
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/2] xen/hvm: introduce a flags field in the CPU save record
El 12/01/16 a les 17.31, Jan Beulich ha escrit:
On 12.01.16 at 17:12, wrote:
>> @@ -2087,19 +2100,21 @@ static int hvm_load_cpu_ctxt(struct domain *d,
>> hvm_domain_context_t *h)
>> seg.attr.bytes = ctxt.ldtr_arbytes;
>> hvm_set_segment_register(v, x86_seg_ldtr, &seg);
>>
>> -/* In case xsave-absent save file is restored on a xsave-capable host */
>> -if ( cpu_has_xsave && !xsave_enabled(v) )
>> +v->fpu_initialised = !!(ctxt.flags & XEN_X86_FPU_INITIALISED);
>> +if ( v->fpu_initialised )
>> {
>> -struct xsave_struct *xsave_area = v->arch.xsave_area;
>> +memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
>> +/* In case xsave-absent save file is restored on a xsave-capable
>> host */
>> +if ( cpu_has_xsave && !xsave_enabled(v) )
>> +{
>> +struct xsave_struct *xsave_area = v->arch.xsave_area;
>>
>> -memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
>> -xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
>> -if ( cpu_has_xsaves || cpu_has_xsavec )
>> -xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
>> - XSTATE_COMPACTION_ENABLED;
>> +xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
>> +if ( cpu_has_xsaves || cpu_has_xsavec )
>> +xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
>> + XSTATE_COMPACTION_ENABLED;
>> +}
>> }
>> -else
>> -memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
>>
>
> I would have expected this to simply be re-indentation, yet
> you changed from if/else to just if with the else code done
> ahead of it. If this really is intended, the commit message should
> explain it.
Right, sorry. AFAICT v->arch.fpu_ctxt points to the xsave_area (as set
by vcpu_init_fpu), so I though it was simpler to just do one memcpy for
both cases, since v->arch.fpu_ctxt always points to the right area for
either cases (and I was already modifying the code in question).
I can see that this might be seen as an unrelated change, so if you want
I can split it into a separate patch, or add the following to the commit
message:
"While modifying the FPU restore part of hvm_load_cpu_ctxt remove the
memcpy branching, since v->arch.fpu_ctxt will always point to the right
area for hosts with XSAVE or without it."
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V12 2/5] libxl_utils: add internal function to read sysfs file contents
Chunyan Liu writes ("[PATCH V12 2/5] libxl_utils: add internal function to read
sysfs file contents"):
> Add a new function libxl_read_sysfs_file_contents to handle sysfs file
> specially. It would be used in later pvusb work.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V12 1/5] libxl: export some functions for pvusb use
Chunyan Liu writes ("[PATCH V12 1/5] libxl: export some functions for pvusb
use"):
> Signed-off-by: Chunyan Liu
> Signed-off-by: Simon Cao
> Reviewed-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V12 3/5] libxl: add pvusb API
Chunyan Liu writes ("[PATCH V12 3/5] libxl: add pvusb API"):
> Add pvusb APIs, including:
> - attach/detach (create/destroy) virtual usb controller.
> - attach/detach usb device
> - list usb controller and usb devices
> - some other helper functions
>
> Signed-off-by: Chunyan Liu
> Signed-off-by: Simon Cao
> Signed-off-by: George Dunlap
> Reviewed-by: George Dunlap
Thanks. I have re-reviewed this and found a few issues, I'm afraid,
mostly in the error handling.
> +/* find first unused controller:port and give that to usb device */
> +static int
> +libxl__device_usbdev_set_default_usbctrl(libxl__gc *gc, uint32_t domid,
> + libxl_device_usbdev *usbdev)
> +{
...
> +path = GCSPRINTF("%s/backend/vusb/%d/%d/port/%d",
> + libxl__xs_get_dompath(gc,
> LIBXL_TOOLSTACK_DOMID),
> + domid, usbctrls[i].devid, j + 1);
> +tmp = libxl__xs_read(gc, XBT_NULL, path);
I think this probably ought to be libxl__xs_read_checked ? (With
corresponding change to handling of return value.)
> +/* get original driver path of usb interface, stored in @drvpath */
> +static int usbintf_get_drvpath(libxl__gc *gc, const char *intf, char
> **drvpath)
> +{
> +char *spath, *dp = NULL;
> +struct stat st;
> +int rc;
> +
> +spath = GCSPRINTF(SYSFS_USB_DEV "/%s/driver", intf);
> +
> +rc = lstat(spath, &st);
> +if (rc == 0) {
> +/* Find the canonical path to the driver. */
> +dp = libxl__zalloc(gc, PATH_MAX);
> +dp = realpath(spath, dp);
This call to realpath seems to lack error checking/handling.
> +static int sysfs_write_intf(libxl__gc *gc, const char *intf, const char
> *path)
> +{
What is `intf' here ? Maybe `interface' ? But there is nothing usb
specific about this function. Looking for similar code elsewhere this
function seems very similar to libxl_pci.c:sysfs_write_bdf, but I
won't ask you to try to refactor these two functions together.
> +rc = write(fd, intf, strlen(intf));
rc ought not be used for a syscall return value. (CODING_STYLE)
> +close(fd);
This is a pretty ad-hoc error handling approach. Can you please use
the CODYING_STYLE-recommended pattern ?
> +static int bind_usbintf(libxl__gc *gc, const char *intf, const char *drvpath)
> +{
> +char *path;
> +struct stat st;
> +
> +path = GCSPRINTF("%s/%s", drvpath, intf);
> +/* if already bound, return */
> +if (!lstat(path, &st))
> +return 0;
If lstat fails, you need to check the error return to see why.
> +/* Encode usb interface so that it could be written to xenstore as a key.
> + *
> + * Since xenstore key cannot include '.' or ':', we'll change '.' to '_',
> + * change ':' to '@'. For example, 3-1:2.1 will be encoded to 3-1@2_1.
> + * This will be used to save original driver of USB device to xenstore.
> + */
> +static char *usb_interface_xenstore_encode(libxl__gc *gc, const char *busid)
> +{
> +char *str = libxl__strdup(gc, busid);
> +int i, len = strlen(str);
> +
> +for (i = 0; i < len; i++) {
> +if (str[i] == '.')
> +str[i] = '_';
> +if (str[i] == ':')
> +str[i] = '@';
I know I'm late with this comment and it's trivial and my
comaintainers may disagree, but I would find this
+if (str[i] == '.') str[i] = '_';
+if (str[i] == ':') str[i] = '@';
clearer because the layout reflects the regular structure of the code.
But please don't change this until another maintainer has commented
and said whether they agree with me. Certainly this is observation of
mine does not block this patch.
> +static int usbback_dev_unassign(libxl__gc *gc, const char *busid)
> +{
> +char **intfs = NULL;
> +char *usbdev_encode = NULL;
> +char *path = NULL;
> +int i, num = 0;
> +int rc;
> +
> +if (usbdev_get_all_interfaces(gc, busid, &intfs, &num) < 0)
> +return ERROR_FAIL;
usbdev_get_all_interfaces returns a libxl error code, which you should
preserved. So assign the result to rc, and `if (rc) goto out;'. Same
goes for unbind_usbintf (and maybe other calls elsewhere in this
file).
> +path = GCSPRINTF(USBBACK_INFO_PATH "/%s/%s/driver_path",
> + usbdev_encode, usbintf_encode);
> +rc = libxl__xs_read_checked(gc, XBT_NULL, path, &drvpath);
> +if (rc) continue;
This anomalous error handling deserves a comment I think. (See also
below.)
> +if (drvpath && bind_usbintf(gc, intf, drvpath))
> +LOGE(WARN, "Couldn't rebind %s to %s", intf, drvpath);
> +}
> +
> +/* finally, remove xenstore driver path */
> +path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode);
> +libxl__xs_rm_checked(gc, XBT_NULL, path);
If you are deliberately throwing away errors (which I think maybe you
are), please say so in a comment.
Ought this function to really report success if these calls fail ?
> +/* Bind USB d
Re: [Xen-devel] [PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release()
On Tue, Jan 12, 2016 at 08:28:44AM -0800, Paul E. McKenney wrote:
> On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote:
> > From: Davidlohr Bueso
> >
> > With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()")
> > it was made clear that the context of this call (and thus set_mb)
> > is strictly for CPU ordering, as opposed to IO. As such all archs
> > should use the smp variant of mb(), respecting the semantics and
> > saving a mandatory barrier on UP.
> >
> > Signed-off-by: Davidlohr Bueso
> > Signed-off-by: Peter Zijlstra (Intel)
> > Cc:
> > Cc: Andrew Morton
> > Cc: Benjamin Herrenschmidt
> > Cc: Heiko Carstens
> > Cc: Linus Torvalds
> > Cc: Paul E. McKenney
> > Cc: Peter Zijlstra
> > Cc: Thomas Gleixner
> > Cc: Tony Luck
> > Cc: d...@stgolabs.net
> > Link:
> > http://lkml.kernel.org/r/1445975631-17047-3-git-send-email-d...@stgolabs.net
> > Signed-off-by: Ingo Molnar
>
> Aside from a need for s/lcoking/locking/ in the subject line:
>
> Reviewed-by: Paul E. McKenney
Thanks!
Though Ingo already put this in tip tree like this,
and I need a copy in my tree to avoid breaking bisect,
so I will probably keep it exactly the same to avoid confusion.
> > ---
> > arch/ia64/include/asm/barrier.h| 2 +-
> > arch/powerpc/include/asm/barrier.h | 2 +-
> > arch/s390/include/asm/barrier.h| 2 +-
> > include/asm-generic/barrier.h | 2 +-
> > 4 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/ia64/include/asm/barrier.h
> > b/arch/ia64/include/asm/barrier.h
> > index df896a1..209c4b8 100644
> > --- a/arch/ia64/include/asm/barrier.h
> > +++ b/arch/ia64/include/asm/barrier.h
> > @@ -77,7 +77,7 @@ do {
> > \
> > ___p1; \
> > })
> >
> > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); }
> > while (0)
> > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); }
> > while (0)
> >
> > /*
> > * The group barrier in front of the rsm & ssm are necessary to ensure
> > diff --git a/arch/powerpc/include/asm/barrier.h
> > b/arch/powerpc/include/asm/barrier.h
> > index 0eca6ef..a7af5fb 100644
> > --- a/arch/powerpc/include/asm/barrier.h
> > +++ b/arch/powerpc/include/asm/barrier.h
> > @@ -34,7 +34,7 @@
> > #define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> > #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
> >
> > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); }
> > while (0)
> > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); }
> > while (0)
> >
> > #ifdef __SUBARCH_HAS_LWSYNC
> > #define SMPWMB LWSYNC
> > diff --git a/arch/s390/include/asm/barrier.h
> > b/arch/s390/include/asm/barrier.h
> > index d68e11e..7ffd0b1 100644
> > --- a/arch/s390/include/asm/barrier.h
> > +++ b/arch/s390/include/asm/barrier.h
> > @@ -36,7 +36,7 @@
> > #define smp_mb__before_atomic()smp_mb()
> > #define smp_mb__after_atomic() smp_mb()
> >
> > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value);
> > mb(); } while (0)
> > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb();
> > } while (0)
> >
> > #define smp_store_release(p, v)
> > \
> > do {
> > \
> > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
> > index b42afad..0f45f93 100644
> > --- a/include/asm-generic/barrier.h
> > +++ b/include/asm-generic/barrier.h
> > @@ -93,7 +93,7 @@
> > #endif /* CONFIG_SMP */
> >
> > #ifndef smp_store_mb
> > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); }
> > while (0)
> > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); }
> > while (0)
> > #endif
> >
> > #ifndef smp_mb__before_atomic
> > --
> > MST
> >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 77846: tolerable FAIL - PUSHED
flight 77846 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/77846/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 9 debian-install fail like 77743 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass version targeted for testing: qemuu7b8a354d4716ab2c201fad04c22b8d4a16a1b8c6 baseline version: qemuu6bb9ead762bf749af11ea225fc2a74db1b93c105 Last test of basis77743 2016-01-10 15:27:52 Z2 days Testing same since77846 2016-01-11 16:53:58 Z1 days1 attempts People who touched revisions under test: Alexey Kardashevskiy Alexis Dambricourt Andrew Jones Ashok Kumar Cao jin Chen Gang Chen Gang Cornelia Huck David Gibson Dr. David Alan Gilbert Eric Blake Haozhong Zhang Harmandeep Kaur Igor Mammedov Jason Wang Jean-Christophe Dubois Johan Ouwerkerk John Paul Adrian Glaubitz Laszlo Ersek Laurent Vivier Li Zhijian Marc-André Lureau Miao Yan Miao Yan Michael S. Tsirkin Michael Tokarev P J P Paolo Bonzini Peter Maydell Prasad J Pandit Riku Voipio Roman Kagan Shmulik Ladkani Sukadev Bhattiprolu Tetsuya Mukawa Thomas Huth Zhu Lingshan 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-xl
