Re: [Xen-devel] efd1535 xen-blkfront: don't call talk_to_blkback when already connected to blkback and 2a6f71a xen-blkfront: fix resume issues after a migration
On Wed, Jun 15, 2016 at 10:08:39AM -0400, Konrad Rzeszutek Wilk wrote: > Heya! > > Please put on the 4.6 stable tree these two following patches: > > 2a6f71a xen-blkfront: fix resume issues after a migration > efd1535 xen-blkfront: don't call talk_to_blkback when already connected to > blkback Now done, thanks. greg k-h ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] What distros have Xen 4.7 packages that work on UEFI hardware?
>>> On 01.08.16 at 18:59, wrote: > I want to run Xen+Linux Dom0 host on server-grade UEFI hardware. > > I want to use current stable releases of Xen (4.7) and Linux kernel (4.7). > > I prefer to use distro packages when possible, but the current distro > packages I use crash on Xen boot. > > I can't keep having things down for days or weeks at a time and I can't get > any response from the distro devs at all. > > To get off this train I'm working on building my own Xen & Linux from source > and getting that reliable enough for production here. Not quite there yet. > > In the meantime I should try other distros as alternatives too. > > What distros, if any provide "official" and/or "regularly maintained" > packages that are > > (1) up-to-date with current stable releases of Xen and Kernel? > (2) known to work on UEFI hardware for Dom0 boot? > (3) can boot UEFI DomU guests? I don't understand this distro related complaint. Afaict the bug is in upstream Linux, and hence any distro will have the issue. And your expectation that freshly released Linux (or Xen) versions are completely bug free is simply wrong, as is your expectation that a solution will always be found within a couple of days, the more when quite a bit of back and forth is needed to even get all relevant data. As was validly said recently in the context of a different thread: The level of support you get is somewhat proportional to the amount of money you spend. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t
On 29/07/16 11:06, Vitaly Kuznetsov wrote: > We pass xen_vcpu_id mapping information to hypercalls which require > uint32_t type so it would be cleaner to have it as uint32_t. The > initializer to -1 can be dropped as we always do the mapping before using > it and we never check the 'not set' value anyway. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Thanks, Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: Make VPMU init message look less scary
>>> On 02.08.16 at 08:43, wrote:
> --- a/arch/x86/xen/pmu.c
> +++ b/arch/x86/xen/pmu.c
> @@ -547,8 +547,11 @@ void xen_pmu_init(int cpu)
> return;
>
> fail:
> - pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
> - cpu, err);
> + if (err == -EOPNOTSUPP)
> + pr_info_once("VPMU disabled by hypervisor.\n");
> + else
> + pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
> + cpu, err);
I'm sorry for not already having thought about this for v1, but
what about older hypervisors, where the hypercall would return
-ENOSYS?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: Make VPMU init message look less scary
On 02/08/16 09:10, Jan Beulich wrote:
On 02.08.16 at 08:43, wrote:
>> --- a/arch/x86/xen/pmu.c
>> +++ b/arch/x86/xen/pmu.c
>> @@ -547,8 +547,11 @@ void xen_pmu_init(int cpu)
>> return;
>>
>> fail:
>> -pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
>> -cpu, err);
>> +if (err == -EOPNOTSUPP)
>> +pr_info_once("VPMU disabled by hypervisor.\n");
>> +else
>> +pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
>> +cpu, err);
>
> I'm sorry for not already having thought about this for v1, but
> what about older hypervisors, where the hypercall would return
> -ENOSYS?
I wasn't aware of that possibility. It should be covered, of course!
V3 will be sent soon...
Thanks for noticing now,
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/mm: Annotate gfn_get_* helpers as requiring non-NULL parameters
>>> On 01.08.16 at 18:59, wrote: > Introduce and use the nonnull attribute to help the compiler catch NULL > parameters being passed to function which require their parameters not to be > NULL. Experimentally, GCC 4.9 on Debian Jessie only warns of non-NULL-ness > from immediate callers, so propagate the attributes out to all helpers. > > A sample error looks like: > > mem_sharing.c: In function ‘mem_sharing_nominate_page’: > mem_sharing.c:884:13: error: null argument where non-null required (argument > 3) [-Werror=nonnull] > amfn = get_gfn_type_access(ap2m, gfn, NULL, &ap2ma, 0, NULL); > ^ > > As part of this, replace the get_gfn_type_access() macro with an equivalent > static inline function for extra type safety, and the ability to be > annotated. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] xen/types: Correct the definition of uintptr_t
>>> On 01.08.16 at 18:34, wrote: > uintptr_t is specified as unsigned int in 32bit, not unsigned long. This is > why, when copying inttypes.h from GCC, the use of PRIxPTR and similar is > broken for 32bit builds. > > Use __attribute__((__mode__(__pointer__))) to get the compilers default > pointer type, which matches the pre-existing inttypes.h > > Fix the identified breakage with ELF_PRPTRVAL > > Compile tested on all architectures, with a manual printk() to trigger any > potential -Wformat issues. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable baseline-only test] 66882: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 66882 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66882/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm3 host-install(3) broken REGR. vs. 66881 build-i386-pvops 3 host-install(3) broken REGR. vs. 66881 build-i386-prev 3 host-install(3) broken REGR. vs. 66881 test-amd64-amd64-xl-credit2 3 host-install(3) broken REGR. vs. 66881 test-amd64-amd64-qemuu-nested-amd 3 host-install(3)broken REGR. vs. 66881 test-amd64-amd64-pair4 host-install/dst_host(4) broken REGR. vs. 66881 test-amd64-amd64-libvirt-vhd 3 host-install(3) broken REGR. vs. 66881 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 66881 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken REGR. vs. 66881 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 66881 test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 66881 test-armhf-armhf-libvirt-raw 10 guest-start fail REGR. vs. 66881 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 66881 Regressions which are regarded as allowable (not blocking): build-i386-oldkern3 host-install(3) broken like 66881 test-amd64-amd64-amd64-pvgrub 3 host-install(3) broken like 66881 test-amd64-amd64-xl-qemuu-win7-amd64 3 host-install(3) broken like 66881 build-i3863 host-install(3) broken like 66881 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken like 66881 build-amd64-rumpuserxen 6 xen-buildfail like 66881 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66881 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a build-i386-rumpuserxen1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 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-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass 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-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 sav
[Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary
The default for the Xen hypervisor is to not enable VPMU in order to
avoid security issues. In this case the Linux kernel will issue the
message "Could not initialize VPMU for cpu 0, error -95" which looks
more like an error than a normal state.
Change the message to something less scary in case the hypervisor
returns EOPNOTSUPP or ENOSYS when trying to activate VPMU.
Signed-off-by: Juergen Gross
---
V3: support older hypervisors returning ENOSYS as requested by
Jan Beulich
V2: modify error message as suggested by Konrad Wilk
---
arch/x86/xen/pmu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 32bdc2c..b9fc525 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -547,8 +547,11 @@ void xen_pmu_init(int cpu)
return;
fail:
- pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
- cpu, err);
+ if (err == -EOPNOTSUPP || err == -ENOSYS)
+ pr_info_once("VPMU disabled by hypervisor.\n");
+ else
+ pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
+ cpu, err);
free_pages((unsigned long)xenpmu_data, 0);
}
--
2.6.6
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 99893: regressions - FAIL
flight 99893 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/99893/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. vs. 99891 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 99891 build-i386-rumpuserxen6 xen-buildfail like 99891 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99891 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99891 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99891 test-amd64-amd64-xl-rtds 9 debian-install fail like 99891 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99891 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 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-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-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 test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail 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-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 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-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-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: xen caefc852d5a3be3965a0c0131ce62e7f3a313f04 baseline version: xen 2d12afe43a5e52a7ac4d2d633caf657d0eb10dc1 Last test of basis99891 2016-08-01 18:44:40 Z0 days Testing same since99893 2016-08-02 01:13:18 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Chao Gao Jan Beulich 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-oldkern
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
Hi Andrew, On 02/08/2016 00:14, Andrew Cooper wrote: On 01/08/2016 19:15, Julien Grall wrote: On 01/08/16 18:10, Sergej Proskurin wrote: Hello all, Hello Sergej, The following patch series can be found on Github[0] and is part of my contribution to this year's Google Summer of Code (GSoC)[1]. My project is managed by the organization The Honeynet Project. As part of GSoC, I am being supervised by the Xen developer Tamas K. Lengyel , George D. Webster, and Steven Maresca. In this patch series, we provide an implementation of the altp2m subsystem for ARM. Our implementation is based on the altp2m subsystem for x86, providing additional --alternate-- views on the guest's physical memory by means of the ARM 2nd stage translation mechanism. The patches introduce new HVMOPs and extend the p2m subsystem. Also, we extend libxl to support altp2m on ARM and modify xen-access to test the suggested functionality. To be more precise, altp2m allows to create and switch to additional p2m views (i.e. gfn to mfn mappings). These views can be manipulated and activated as will through the provided HVMOPs. In this way, the active guest instance in question can seamlessly proceed execution without noticing that anything has changed. The prime scope of application of altp2m is Virtual Machine Introspection, where guest systems are analyzed from the outside of the VM. Altp2m can be activated by means of the guest control parameter "altp2m" on x86 and ARM architectures. The altp2m functionality by default can also be used from within the guest by design. For use-cases requiring purely external access to altp2m, a custom XSM policy is necessary on both x86 and ARM. As said on the previous version, altp2m operation *should not* be exposed to ARM guest. Any design written for x86 may not fit exactly for ARM (and vice versa), you will need to explain why you think we should follow the same pattern. Sorry, but I am going to step in here and disagree. All the x86 justifications for altp2m being accessible to guests apply equally to ARM, as they are hardware independent. I realise you are maintainer, but the onus is on you to justify why the behaviour should be different between x86 and ARM, rather than simply to complain at it being the same. Naturally, technical issues about the details of the implementation, or the algorithms etc. are of course fine, but I don't see any plausible reason why ARM should purposefully different from x86 in terms of available functionality, and several good reasons why it should be the same (least of all, feature parity across architectures). The question here, is how a guest could take advantage to access to altp2m on ARM today? Whilst on x86 a guest could be notified about memaccess change, this is not yet the case on ARM. So, from my understanding, exposing this feature to a guest is like exposing a no-op with side effects. We should avoid to expose feature to the guest until there is a real usage and the guest could do something useful with it. This has always been the case where some features were not fully ported on ARM until there is an actual usage (or we differ because there will be no-usage). The interface is already there, so a future Xen release can decide to give access to the guest when (and only when) this will be useful. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
Hello Tamas, On 01/08/2016 21:41, Tamas K Lengyel wrote: On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall wrote: we did discuss whether altp2m on ARM should be exposed to guests or not but we did not agree whether restricting it on ARM is absolutely necessary. Altp2m was designed even on the x86 to be accessible from within the guest on all systems irrespective of actual hardware support for it. Thus, this design fits ARM as well where there is no dedicated hardware support, from the altp2m perspective there is no difference. Really? I looked at the design document [1] which is Intel focus. Similar think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). That design cover letter mentions specifically "Both VMFUNC and #VE are designed such that a VMM can emulate them on legacy CPUs". While they certainly had only Intel hardware in-mind, the software route can also be taken on ARM as well. As our primary use-case is purely external use of altp2m we have not implemented the bits that enable the injection of mem_access faults into the guest (equivalent of #VE). Whether without that the altp2m switching from within the guest make sense or not is beyond the scope of this series but as it could technically be implemented in the future, I don't see a reason to disable that possibility right away. The question here, is how a guest could take advantage to access to altp2m on ARM today? Whilst on x86 a guest could be notified about memaccess change, this is not yet the case on ARM. So, from my understanding, exposing this feature to a guest is like exposing a no-op with side effects. We should avoid to expose feature to the guest until there is a real usage and the guest could do something useful with it. This has always been the case where some features were not fully ported on ARM until there is an actual usage (or we differ because there will be no-usage). The interface is already there, so a future Xen release can decide to give access to the guest when (and only when) this will be useful. Regards, Tamas -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers
On 08/01/2016 08:59 PM, Tamas K Lengyel wrote: > Add support for getting/setting registers through vm_event on ARM. Only > TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set > as part of a response. The set of registers can be expanded in the future to > include other registers as well if necessary. > > Signed-off-by: Tamas K Lengyel > Reviewed-by: Andrew Cooper Acked-by: Razvan Cojocaru ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] x86/emulate: add support for {, v}movq xmm, xmm/m64
On Tuesday 02 August 2016 00:19:22 Jan Beulich wrote:
> > > > On 02.08.16 at 01:19, wrote:
> > > > @@ -4412,6 +4412,7 @@ x86_emulate(
> > > > case 0x7f: /* movq mm,mm/m64 */
> > > > /* {,v}movdq{a,u} xmm,xmm/m128 */
> > > > /* vmovdq{a,u} ymm,ymm/m256 */
> > > > +case 0xd6: /* {,v}movq xmm,xmm/m64 */
> > > > {
> > > > uint8_t *buf = get_stub(stub);
> > > > struct fpu_insn_ctxt fic = { .insn_bytes = 5 };
> > > > @@ -4429,9 +4430,9 @@ x86_emulate(
> > > > case vex_66:
> > > > case vex_f3:
> > > > host_and_vcpu_must_have(sse2);
> > > > -buf[0] = 0x66; /* movdqa */
> > > > +buf[0] = 0x66; /* SSE */
> > >
> > > The comment change here indicates a problem: So far it was indicating
> > > that despite the possible F3 prefix (movdqu) we encode a 66 one
> > > (movdqa). Opcode D6 prefixed with F3, however, is movq2dq, which
> > > you then either don't emulate correctly, or if it happens to be
> > > emulated correctly you should include in the comment accompanying
> > > the case label. And its AVX counterpart should then produce #UD.
> >
> > I fiddled with this for a while and the attached patch (adjusted)
> > appears to be doing the right thing: ie. movq2dq gets emulated
> > correctly too. copy_REX_VEX() does not work OK with movq2dq, but it
> > looked easy to single out this case.
>
> Except that you can't really avoid it (see below). Without you being
> more explicit I also can't tell what it is that doesn't work right in that
> case.
Sorry about that. In x86_emulate(), after buf[0] == 0x66 and
copy_REX_VEX():
f3 0f d6 d1 movq2dq %mm1,%xmm2
becomes:
66 40 0f d6 d1 rex movq %xmm2,%xmm1
Now that I slept over it, I can see it's not really a problem with
copy_REX_VEX().
> > All tests pass, including for {,v}movq xmm/m64 and movq2dq. There does
> > not appear to be an AVX variant for the latter, or I'm not reading the
> > Intel SDM right (or binutils' as is lying to me).
>
> Well, that's what I said earlier on (still visible above), and what you
> still fail to deal with.
>
> > @@ -4469,7 +4471,11 @@ x86_emulate(
> > }
> > if ( !rc )
> > {
> > - copy_REX_VEX(buf, rex_prefix, vex);
> > + /* try to preserve the mandatory prefix for movq2dq */
> > + if ( !rex_prefix && vex.opcx == vex_none && vex.pfx == vex_f3 )
> > + buf[0] = 0xf3;
> > + else
> > + copy_REX_VEX(buf, rex_prefix, vex);
>
> So what about a movq2dq having a REX prefix to encode XMM8..15
> for one or both of its operands? The writing of the F3 prefix really
> needs to go elsewhere - probably the best place is where the 66
> one gets written unconditionally right now. And afaict then
> copy_REX_VEX() will work fine here too.
--
Mihai DONȚU
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request
On 08/01/2016 07:52 PM, Tamas K Lengyel wrote: > The two functions monitor_traps and mem_access_send_req duplicate some of the > same functionality. The mem_access_send_req however leaves a lot of the > standard vm_event fields to be filled by other functions. > > Remove mem_access_send_req() completely, making use of monitor_traps() to put > requests into the monitor ring. This in turn causes some cleanup around the > old callsites of mem_access_send_req(), and on ARM, the introduction of the > __p2m_mem_access_send_req() helper to fill in common mem_access information. > We also update monitor_traps to now include setting the common vcpu_id field > so that all other call-sites can ommit this step. > > Finally, this change identifies that errors from mem_access_send_req() were > never checked. As errors constitute a problem with the monitor ring, > crashing the domain is the most appropriate action to take. > > Signed-off-by: Tamas K Lengyel > Reviewed-by: Andrew Cooper Acked-by: Razvan Cojocaru ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 25/25] arm/altp2m: Add test of xc_altp2m_change_gfn.
On 08/01/2016 08:10 PM, Sergej Proskurin wrote:
> This commit extends xen-access by a simple test of the functionality
> provided by "xc_altp2m_change_gfn". The idea is to dynamically remap a
> trapping gfn to another mfn, which holds the same content as the
> original mfn.
>
> Signed-off-by: Sergej Proskurin
> ---
> Cc: Razvan Cojocaru
> Cc: Tamas K Lengyel
> Cc: Ian Jackson
> Cc: Wei Liu
> ---
> tools/tests/xen-access/xen-access.c | 135
> +++-
> 1 file changed, 132 insertions(+), 3 deletions(-)
>
> diff --git a/tools/tests/xen-access/xen-access.c
> b/tools/tests/xen-access/xen-access.c
> index eafd7d6..39b7ddf 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -38,6 +38,7 @@
> #include
> #include
>
> +#define XC_WANT_COMPAT_MAP_FOREIGN_API
> #include
> #include
> #include
> @@ -49,6 +50,8 @@
> #define START_PFN 0ULL
> #endif
>
> +#define INVALID_GFN ~(0UL)
> +
> #define DPRINTF(a, b...) fprintf(stderr, a, ## b)
> #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
> #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
> @@ -72,9 +75,14 @@ typedef struct xenaccess {
> xen_pfn_t max_gpfn;
>
> vm_event_t vm_event;
> +
> +unsigned int ap2m_idx;
> +xen_pfn_t gfn_old;
> +xen_pfn_t gfn_new;
> } xenaccess_t;
>
> static int interrupted;
> +static int gfn_changed = 0;
> bool evtchn_bind = 0, evtchn_open = 0, mem_access_enable = 0;
>
> static void close_handler(int sig)
> @@ -82,6 +90,94 @@ static void close_handler(int sig)
> interrupted = sig;
> }
>
> +static int copy_gfn(xc_interface *xch, domid_t domain_id,
> +xen_pfn_t dst_gfn, xen_pfn_t src_gfn)
> +{
> +void *src_vaddr = NULL;
> +void *dst_vaddr = NULL;
> +
> +src_vaddr = xc_map_foreign_range(xch, domain_id, XC_PAGE_SIZE,
> + PROT_READ, src_gfn);
> +if ( src_vaddr == MAP_FAILED || src_vaddr == NULL)
> +{
> +return -1;
> +}
Please don't use scopes for single return statements (i.e. no { ... }
around them).
> +
> +dst_vaddr = xc_map_foreign_range(xch, domain_id, XC_PAGE_SIZE,
> + PROT_WRITE, dst_gfn);
> +if ( dst_vaddr == MAP_FAILED || dst_vaddr == NULL)
> +{
> +return -1;
> +}
But if this failed and the first one succeeds, shouldn't we munmap() the
first one before the return?
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix printing hotplug arguments/environment
On Mon, Aug 01, 2016 at 06:20:56PM +0200, Roger Pau Monne wrote:
> A OS could decide to not pass arguments or any environment variables to
"An"
> hotplug scripts, and this will trigger a bug in device_hotplug logic, since
> it expects both the argument and the environment arrays to exist. Allow
> both args or env to be NULL.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Wei Liu
> Cc: Ian Jackson
> ---
> tools/libxl/libxl_device.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index b9a6df2..0e5f546 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -1132,7 +1132,7 @@ static void device_hotplug(libxl__egc *egc,
> libxl__ao_device *aodev)
>
> LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]);
> LOG(DEBUG, "extra args:");
> -{
> +if ( args != NULL) {
Minor nit, extraneous space here.
Shouldn't this check be moved before the "calling hotplug script..."
line?
> const char *arg;
> unsigned int x;
>
> @@ -1140,7 +1140,7 @@ static void device_hotplug(libxl__egc *egc,
> libxl__ao_device *aodev)
> LOG(DEBUG, "\t%s", arg);
> }
> LOG(DEBUG, "env:");
> -{
> +if ( env != NULL) {
> const char *k, *v;
> unsigned int x;
>
> --
> 2.7.4 (Apple Git-66)
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: use gcc6'es flags asm() output support
On 02/08/16 07:09, Jan Beulich wrote:
On 01.08.16 at 19:11, wrote:
>> On 01/08/16 17:06, Jan Beulich wrote:
>> On 01.07.16 at 18:51, wrote:
How about a different example, from the second hunk
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -832,8 +832,19 @@ static int read_ulong(
static bool_t mul_dbl(unsigned long m[2])
{
bool_t rc;
-asm ( "mul %1; seto %2"
- : "+a" (m[0]), "+d" (m[1]), "=qm" (rc) );
+
+asm ( "mul %1;"
+#ifndef __GCC_ASM_FLAG_OUTPUTS__
+ "seto %[rc];"
+#endif
+ : "+a" (m[0]), "+d" (m[1]),
+#ifdef __GCC_ASM_FLAG_OUTPUTS__
+[rc] "=@cco" (rc)
+#else
+[rc] "=qm" (rc)
+#endif
+);
+
return rc;
}
>>> Looking at this again I think I really like the original, submitted version
>>> better. Are you strongly biased towards the above form?
>> I am not overly fussed between this version and the original submission.
>>
>> However, I definitely think that we shouldn't hide semantic bits of the
>> ASM statement behind macros.
> Well, the originally submitted variant doesn't do anything like that,
> so may I translate the above to an ack?
You do already have a Rev-by from my first reply.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 06/12] xen/x86: populate PVHv2 Dom0 physical memory map
On Fri, Jul 29, 2016 at 08:04:12PM +0100, Andrew Cooper wrote:
> On 29/07/16 17:29, Roger Pau Monne wrote:
> > Craft the Dom0 e820 memory map and populate it.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Jan Beulich
> > Cc: Andrew Cooper
> > ---
> > xen/arch/x86/domain_build.c | 199
> > ++--
> > 1 file changed, 193 insertions(+), 6 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
> > index c0ef40f..cb8ecbd 100644
> > --- a/xen/arch/x86/domain_build.c
> > +++ b/xen/arch/x86/domain_build.c
> > @@ -43,6 +43,11 @@ static long __initdata dom0_nrpages;
> > static long __initdata dom0_min_nrpages;
> > static long __initdata dom0_max_nrpages = LONG_MAX;
> >
> > +/* GFN of the identity map for EPT. */
> > +#define HVM_IDENT_PT_GFN 0xfeffeu
>
> The IDENT_PT is only needed on Gen1 VT-x hardware which doesn't support
> unrestricted-guest mode. OTOH, it needs to be matched with VM86_TSS,
> which is also needed if hardware doesn't support unrestricted-guest.
> Also, the IDENT_PT can live anywhere in GFN space. 0xfeffe is just
> convention for HVM guests as nothing else interesting lives there, but a
> PVH dom0 will want to ensure it doesn't alias anything interesting it
> might wish to map.
>
> Now I look at it, there is substantial WTF. The domain builder makes
> IDENT_PT, but HVMLoader makes VM86_TSS. I presume this is a historical
> side effect of IDENT_PT being a prerequisite to even executing
> hvmloader, while VM86_TSS was only a prerequisite to executing the
> rombios payload. Either way, eww :(
>
> I think the VM86_TSS setup needs to move to unconditionally being beside
> IDENT_PT setup in the domain builder, and mirrored here in dom0_hvm()
> creation. I don't think it is reasonable to expect an HVMLite payload
> to set up its own VM86_TSS if it didn't set up IDENT_PT. (OTOH, the
> chances of an HVMLite guest ever needing to return to real mode is slim,
> but in the name of flexibility, it would be nice not to rule it out).
>
> Longterm, it would be nice to disentangle the unrestricted-guest support
> from the main vmx code, and make it able to be compiled out. There is
> lots of it, and it all-but-dead on modern hardware.
Thanks! I didn't know anything about the VM86 TSS stuff, the fact that the
identity page tables and the VM86 TSS are set at completely different points
makes it quite hard to follow :/.
I've now moved the setup of the VM86 TSS inside the domain builder for both
DomU and Dom0.
> > @@ -591,6 +610,8 @@ static __init void pvh_setup_e820(struct domain *d,
> > unsigned long nr_pages)
> > {
> > cur_pages += pages;
> > }
> > +ASSERT((entry_guest->addr & ~PAGE_MASK) == 0 &&
> > + (entry_guest->size & ~PAGE_MASK) == 0);
>
> This would be clearer as ASSERT(IS_ALIGNED(entry_guest->addr, PAGE_SIZE));
>
> (although I suspect the IS_ALIGNED() predicate is newer than your first
> iteration of this code.)
>
> > next:
> > d->arch.nr_e820++;
> > entry_guest++;
> > @@ -1631,7 +1652,7 @@ static int __init construct_dom0_pv(
> > dom0_update_physmap(d, pfn, mfn, 0);
> >
> > pvh_map_all_iomem(d, nr_pages);
> > -pvh_setup_e820(d, nr_pages);
> > +hvm_setup_e820(d, nr_pages);
> > }
> >
> > if ( d->domain_id == hardware_domid )
> > @@ -1647,15 +1668,181 @@ out:
> > return rc;
> > }
> >
> > +/* Helper to convert from bytes into human-readable form. */
> > +static void __init pretty_print_bytes(uint64_t size)
> > +{
> > +const char* units[] = {"B", "KB", "MB", "GB", "TB"};
>
> static const char *units[] __initconst
>
> However, this particular array would be far smaller as
>
> static const char units[][3] __initconst = { "B", ... };
>
> as it avoids embedding 5x8byte pointers to get at 14 useful bytes of
> information.
>
> > +int i = 0;
> > +
> > +while ( ++i < sizeof(units) && size >= 1024 )
> > +size >>= 10; /* size /= 1024 */
> > +
> > +printk("%4" PRIu64 "%2s", size, units[i-1]);
>
> Wouldn't it be better to introduce a new %p format identifier to do
> this? (Linux doesn't appear to have an existing format identifier which
> we can 'borrow')
>
> It looks potentially useful elsewhere, and avoids the awkward
>
> printk("Order %2u: ", MAX_ORDER - i);
> pretty_print_bytes(((uint64_t)1 << (MAX_ORDER - i + PAGE_SHIFT)) *
>hvm_mem_stats[MAX_ORDER - i]);
> printk("\n");
>
> constructs you have below.
Done all the above.
>
> > +}
> > +
> > +/* Calculate the biggest usable order given a size in bytes. */
> > +static inline unsigned int get_order(uint64_t size)
> > +{
> > +unsigned int order;
> > +uint64_t pg;
> > +
> > +ASSERT((size & ~PAGE_MASK) == 0);
> > +pg = PFN_DOWN(size);
> > +for ( order = 0; pg >= (1 << (order + 1)); order++ );
> > +
> > +return order;
> > +}
>
> We already have get_orde
Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian
On Fri, Jul 29, 2016 at 10:17:22PM +0200, Ingo Jürgensmann wrote: > Am 29.07.2016 um 13:45 schrieb Andreas Ziegler : > > > we tried with kernel 4.6 now, the crashed happened again, though. > > Please find attached the netconsole log of 3 from 4 crashes so far today… What is also interesting is that you seem to be running some sort of ip accounting software (pmacctd) which also segfault'ed. Still not sure what to make of that though. Wei. > > -- > Ciao... //http://blog.windfluechter.net > Ingo \X/ XMPP: i...@jabber.windfluechter.net > > gpg pubkey: http://www.juergensmann.de/ij_public_key.asc > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix printing hotplug arguments/environment
On Tue, Aug 02, 2016 at 10:13:42AM +0100, Wei Liu wrote:
> On Mon, Aug 01, 2016 at 06:20:56PM +0200, Roger Pau Monne wrote:
> > A OS could decide to not pass arguments or any environment variables to
>
> "An"
>
> > hotplug scripts, and this will trigger a bug in device_hotplug logic, since
> > it expects both the argument and the environment arrays to exist. Allow
> > both args or env to be NULL.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc: Wei Liu
> > Cc: Ian Jackson
> > ---
> > tools/libxl/libxl_device.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> > index b9a6df2..0e5f546 100644
> > --- a/tools/libxl/libxl_device.c
> > +++ b/tools/libxl/libxl_device.c
> > @@ -1132,7 +1132,7 @@ static void device_hotplug(libxl__egc *egc,
> > libxl__ao_device *aodev)
> >
> > LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]);
> > LOG(DEBUG, "extra args:");
> > -{
> > +if ( args != NULL) {
>
> Minor nit, extraneous space here.
>
> Shouldn't this check be moved before the "calling hotplug script..."
> line?
This one should be removed, args cannot be NULL or else we won't call
anything, and thus libxl__get_hotplug_script_info should return 0.
> > const char *arg;
> > unsigned int x;
> >
> > @@ -1140,7 +1140,7 @@ static void device_hotplug(libxl__egc *egc,
> > libxl__ao_device *aodev)
> > LOG(DEBUG, "\t%s", arg);
> > }
> > LOG(DEBUG, "env:");
> > -{
> > +if ( env != NULL) {
> > const char *k, *v;
> > unsigned int x;
> >
> > --
> > 2.7.4 (Apple Git-66)
> >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix printing hotplug arguments/environment
On Tue, Aug 02, 2016 at 11:27:13AM +0200, Roger Pau Monne wrote:
> On Tue, Aug 02, 2016 at 10:13:42AM +0100, Wei Liu wrote:
> > On Mon, Aug 01, 2016 at 06:20:56PM +0200, Roger Pau Monne wrote:
> > > A OS could decide to not pass arguments or any environment variables to
> >
> > "An"
> >
> > > hotplug scripts, and this will trigger a bug in device_hotplug logic,
> > > since
> > > it expects both the argument and the environment arrays to exist. Allow
> > > both args or env to be NULL.
> > >
> > > Signed-off-by: Roger Pau Monné
> > > ---
> > > Cc: Wei Liu
> > > Cc: Ian Jackson
> > > ---
> > > tools/libxl/libxl_device.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> > > index b9a6df2..0e5f546 100644
> > > --- a/tools/libxl/libxl_device.c
> > > +++ b/tools/libxl/libxl_device.c
> > > @@ -1132,7 +1132,7 @@ static void device_hotplug(libxl__egc *egc,
> > > libxl__ao_device *aodev)
> > >
> > > LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]);
> > > LOG(DEBUG, "extra args:");
> > > -{
> > > +if ( args != NULL) {
> >
> > Minor nit, extraneous space here.
> >
> > Shouldn't this check be moved before the "calling hotplug script..."
> > line?
>
> This one should be removed, args cannot be NULL or else we won't call
> anything, and thus libxl__get_hotplug_script_info should return 0.
>
OK, please update the patch commit message and content.
I will wait for v2.
> > > const char *arg;
> > > unsigned int x;
> > >
> > > @@ -1140,7 +1140,7 @@ static void device_hotplug(libxl__egc *egc,
> > > libxl__ao_device *aodev)
> > > LOG(DEBUG, "\t%s", arg);
> > > }
> > > LOG(DEBUG, "env:");
> > > -{
> > > +if ( env != NULL) {
> > > const char *k, *v;
> > > unsigned int x;
> > >
> > > --
> > > 2.7.4 (Apple Git-66)
> > >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation
On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
> On 29/07/16 17:28, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
> > index 107fc8c..1b270df 100644
> > --- a/xen/arch/x86/mm/paging.c
> > +++ b/xen/arch/x86/mm/paging.c
> > @@ -953,6 +953,22 @@ void paging_write_p2m_entry(struct p2m_domain *p2m,
> > unsigned long gfn,
> > safe_write_pte(p, new);
> > }
> >
> > +int paging_set_allocation(struct domain *d, unsigned long pages)
> > +{
> > +int rc;
> > +
> > +ASSERT(paging_mode_enabled(d));
> > +
> > +paging_lock(d);
> > +if ( hap_enabled(d) )
> > +rc = hap_set_allocation(d, pages, NULL);
> > +else
> > +rc = sh_set_allocation(d, pages, NULL);
>
> (without looking at the rest of the series) Your NMI is probably a
> watchdog timeout from this call, as passing NULL means "non-preemptible".
I don't think so, the NMI I saw happened while the guest was booting.
> As this is for the construction of dom0, it would be better to take a
> preemptible pointer, loop in construct_dom0(), with a
> process_pending_softirqs() call in between.
Now fixed.
> > +paging_unlock(d);
> > +
> > +return rc;
> > +}
> > +
> > /*
> > * Local variables:
> > * mode: C
> > diff --git a/xen/arch/x86/mm/shadow/common.c
> > b/xen/arch/x86/mm/shadow/common.c
> > index c22362f..452e22e 100644
> > --- a/xen/arch/x86/mm/shadow/common.c
> > +++ b/xen/arch/x86/mm/shadow/common.c
> > @@ -1604,9 +1604,8 @@ shadow_free_p2m_page(struct domain *d, struct
> > page_info *pg)
> > * Input will be rounded up to at least shadow_min_acceptable_pages(),
> > * plus space for the p2m table.
> > * Returns 0 for success, non-zero for failure. */
> > -static unsigned int sh_set_allocation(struct domain *d,
> > - unsigned int pages,
> > - int *preempted)
> > +unsigned int sh_set_allocation(struct domain *d, unsigned int pages,
> > + int *preempted)
> > {
> > struct page_info *sp;
> > unsigned int lower_bound;
> > diff --git a/xen/include/asm-x86/hap.h b/xen/include/asm-x86/hap.h
> > index c613836..e3c9c98 100644
> > --- a/xen/include/asm-x86/hap.h
> > +++ b/xen/include/asm-x86/hap.h
> > @@ -46,7 +46,8 @@ int hap_track_dirty_vram(struct domain *d,
> > XEN_GUEST_HANDLE_64(uint8) dirty_bitmap);
> >
> > extern const struct paging_mode *hap_paging_get_mode(struct vcpu *);
> > -void hap_set_alloc_for_pvh_dom0(struct domain *d, unsigned long num_pages);
> > +unsigned int hap_set_allocation(struct domain *d, unsigned int pages,
> > + int *preempted);
>
> I also note from this change that there is an unsigned long => unsigned
> int truncation in the internals of *_set_allocation(). This should
> definitely be fixed, although possibly wants to be a separate change.
Right, let me take a stab at this.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] libxl: memory size in kb requires 64 bit variable
On Thu, Jul 28, 2016 at 03:35:19PM +0200, Juergen Gross wrote:
> libxl_set_memory_target() and several other interface functions of
> libxl use a 32 bit sized parameter for a memory size value in kBytes.
> This limits the maximum size to be passed in such a parameter
> depending on signedness of the parameter to 2TB or 4TB.
>
> Correct this by using 64 bit types.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Dario Faggioli
> ---
[...]
> +static int libxl__memkb_64to32(libxl_ctx *ctx, int rc,
> + uint64_t val64, uint32_t *ptr32)
> +{
It's a bit unusual for an internal function to take ctx. But I think you
want to avoid code repetition in the compact functions.
I can live with this.
Acked-by: Wei Liu
And thanks Dario for reviewing.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 25/25] arm/altp2m: Add test of xc_altp2m_change_gfn.
Hi Razvan,
On 08/02/2016 11:14 AM, Razvan Cojocaru wrote:
> On 08/01/2016 08:10 PM, Sergej Proskurin wrote:
>> This commit extends xen-access by a simple test of the functionality
>> provided by "xc_altp2m_change_gfn". The idea is to dynamically remap a
>> trapping gfn to another mfn, which holds the same content as the
>> original mfn.
>>
>> Signed-off-by: Sergej Proskurin
>> ---
>> Cc: Razvan Cojocaru
>> Cc: Tamas K Lengyel
>> Cc: Ian Jackson
>> Cc: Wei Liu
>> ---
>> tools/tests/xen-access/xen-access.c | 135
>> +++-
>> 1 file changed, 132 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/tests/xen-access/xen-access.c
>> b/tools/tests/xen-access/xen-access.c
>> index eafd7d6..39b7ddf 100644
>> --- a/tools/tests/xen-access/xen-access.c
>> +++ b/tools/tests/xen-access/xen-access.c
>> @@ -38,6 +38,7 @@
>> #include
>> #include
>>
>> +#define XC_WANT_COMPAT_MAP_FOREIGN_API
>> #include
>> #include
>> #include
>> @@ -49,6 +50,8 @@
>> #define START_PFN 0ULL
>> #endif
>>
>> +#define INVALID_GFN ~(0UL)
>> +
>> #define DPRINTF(a, b...) fprintf(stderr, a, ## b)
>> #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
>> #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
>> @@ -72,9 +75,14 @@ typedef struct xenaccess {
>> xen_pfn_t max_gpfn;
>>
>> vm_event_t vm_event;
>> +
>> +unsigned int ap2m_idx;
>> +xen_pfn_t gfn_old;
>> +xen_pfn_t gfn_new;
>> } xenaccess_t;
>>
>> static int interrupted;
>> +static int gfn_changed = 0;
>> bool evtchn_bind = 0, evtchn_open = 0, mem_access_enable = 0;
>>
>> static void close_handler(int sig)
>> @@ -82,6 +90,94 @@ static void close_handler(int sig)
>> interrupted = sig;
>> }
>>
>> +static int copy_gfn(xc_interface *xch, domid_t domain_id,
>> +xen_pfn_t dst_gfn, xen_pfn_t src_gfn)
>> +{
>> +void *src_vaddr = NULL;
>> +void *dst_vaddr = NULL;
>> +
>> +src_vaddr = xc_map_foreign_range(xch, domain_id, XC_PAGE_SIZE,
>> + PROT_READ, src_gfn);
>> +if ( src_vaddr == MAP_FAILED || src_vaddr == NULL)
>> +{
>> +return -1;
>> +}
> Please don't use scopes for single return statements (i.e. no { ... }
> around them).
>
I will adapt the scopes to the coding style, thank you. These are
leftovers from my test outputs.
>> +
>> +dst_vaddr = xc_map_foreign_range(xch, domain_id, XC_PAGE_SIZE,
>> + PROT_WRITE, dst_gfn);
>> +if ( dst_vaddr == MAP_FAILED || dst_vaddr == NULL)
>> +{
>> +return -1;
>> +}
> But if this failed and the first one succeeds, shouldn't we munmap() the
> first one before the return?
>
You are absolutely right. I will adapt the implementation accordingly.
Thank you very much.
Best regards,
~Sergej
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] live migration to qemu.git fails
Doing a live migration of a HVM domU from staging-4.5 with its included qemu-xen to staging-4.7 with qemu-xen from qemu.org (either master or 2.6.0) fails: # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log char device redirected to /dev/pts/4 (label serial0) xen_ram_alloc: do not alloc f80 bytes of ram at 0 when runstate is INMIGRATE xen_ram_alloc: do not alloc 80 bytes of ram at f80 when runstate is INMIGRATE xen_ram_alloc: do not alloc 1 bytes of ram at 1000 when runstate is INMIGRATE xen_ram_alloc: do not alloc 4 bytes of ram at 1001 when runstate is INMIGRATE VNC server running on 127.0.0.1:5900 qemu-system-i386: Expected vmdescription section, but got 0 'xl vnc domU' on the receiver side just shows "guest has not initialized display yet". For some reason the domU is still alive, 'vmstat 1' via ssh keeps running. 'xl shutdown domU' fails. It looks like the guest OS shuts down, the ssh connection gets terminated, but the domU becomes busy according to 'xl top', and never shuts down. domU.cfg looks like this: name="fv-x64-sles12sp1-clean" memory=256 serial="pty" builder="hvm" boot="cd" disk=[ 'file:/disk0.raw,hda,w', 'file:/DVD1.iso,hdc:cdrom,r', ] vif=[ 'bridge=br0' ] keymap="de" vfb = [ 'type=vnc,vncunused=1,keymap=de' ] usb=1 usbdevice='tablet' device_model_override="/root/dm.sh" The override is to make sure to use qemu-xen as included in xen-4.5 on the sending side and qemu.git on the receiving side. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry
On 01/08/2016 19:22, Mark Rutland wrote: Hi, Hi Mark, I realised I made a confusing mistake in my last reply; clarification below. On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote: On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote: however we only need one TLBI instruction (assuming there is no superpage shattering) per-batch rather than one per-entry in this case. I got Cc'd to a reply without the original patch context, so I'm not sure what the case is here. I'm not exactly sure what you mean by "per-batch". Sorry for that. I CCed in case I did not summarize correctly the conversation we had. The page table handling code can be found in patch #18 [1]. Assuming that you've (only) changed the permissions (i.e. the AP bits and XN bits) of a number of stage-2 leaf entries, you need either: [...] * Per entry, a TLBI IPAS2LE1IS e.g. for_each_entry(x) modify_ap_bits(x); dsb(ishst); tlbi(ipas2le1is); dsb(ish); Here I was trying to have the bare minimum barriers necessary, but in focussing on that I failed to add the required loop to have a TLBI per entry. The above should have been: for_each_entry(x) modify_ap_bits(x); dsb(ishst); for_each_entry(x) tlbi(ipas2le1is, x); dsb(ish); I have a question related to this example. Is there a threshold where invalidate all the TLB entry for a given VMID/ASID is worth? Assuming the necessary bit fiddling for the TLBI to affect the IPA of x, with the right VMID, etc. Regards, [1] https://lists.xen.org/archives/html/xen-devel/2016-07/msg02966.html -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 99894: regressions - FAIL
flight 99894 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/99894/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 99776 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 99776 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99776 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99776 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99776 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99776 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail 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-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-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-libvirt-vhd 11 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-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail 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-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass version targeted for testing: xen 625c3e47e077129b0bc903e8db03bdf1cbbeb413 baseline version: xen dfe85d302f5f127c4ab5e2a5e8bcd6a964f7218c Last test of basis99776 2016-07-29 04:09:24 Z4 days Testing same since99894 2016-08-02 02:03:03 Z0 days1 attempts People who touched revisions under test: Julien Grall 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-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen
[Xen-devel] [libvirt test] 99895: tolerable FAIL - PUSHED
flight 99895 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99895/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail 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-libvirt 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-libvirt-vhd 11 migrate-support-checkfail never pass
version targeted for testing:
libvirt 230c631917f293865856cf675172f1b36cb7e680
baseline version:
libvirt 1e058463732b647fdf5481208a539c50f1c729cf
Last test of basis99788 2016-07-29 12:56:09 Z3 days
Testing same since99895 2016-08-02 04:22:25 Z0 days1 attempts
People who touched revisions under test:
Boris Fiuczynski
Ján Tomko
Marc Hartmayer
Michal Privoznik
Nikolay Shirokovskiy
Peter Krempa
Sascha Silbe
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-amd64-libvirt-vhd pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=230c631917f293865856cf675172f1b36cb7e680
+ . ./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 l
Re: [Xen-devel] Default controller type for USB devices
On Fri, Jul 29, 2016 at 02:15:24PM +0100, George Dunlap wrote: > On 29/07/16 14:00, Juergen Gross wrote: > > When specifying no USB controller type for a usb device the default is > > chosen in libxl__device_usbctrl_setdefault(). For a HVM guest this is > > currently the not yet supported "LIBXL_USBCTRL_TYPE_DEVICEMODEL". > > > > Wouldn't it make sense to handle HVM guests in the same way as PV guests > > as long as emulated USB devices are not implemented in libxl? Or would > > this create future incompatibilities which we don't want to run into? > > > > I'd be happy to send a patch if this is the way to go. > > I think the big thing is that we can pretty much expect a typical HVM > guest OS to have drivers for the emulated hardware; we *cannot* expect > an average HVM guest OS to have pvfront drivers. This will probably > always apply to Windows, but at the moment it even applies to Linux. > > So what happens right now if a user simply asks for a usbctrl for an HVM > guest? They get an error on domain creation. This will hopefully > prompt them to look into either switching back to the old format, or > finding out about pvusb, at which point they can maybe find a pvusbfront > for their OS. > > If we make the switch you propose, then the user will create a usb > controller, which will succeed; but if the guest OS doesn't have > pvusbfront drivers (which is likely), then they will mysteriously just > not see the controller and devices they've plugged in. > > As a user, I would personally rather have an error message up front > which gives me a clue as to what's wrong, rather than have things > mysteriously not work and spend a lot of time going around trying to > figure out what's wrong. > > So I think the current default is the best. Wei / Ian, any thoughts? > Note that I haven't been following closely the HVM/PV USB development, but I think your analysis makes sense. Wei. > -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 99896: all pass - PUSHED
flight 99896 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99896/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 28ade7b802e0732cf9839017ee6e9cf78b842582
baseline version:
ovmf 07783fdd67e40fa7cff3ebf34399c1ab65937802
Last test of basis99888 2016-08-01 12:16:24 Z0 days
Testing same since99896 2016-08-02 06:46:13 Z0 days1 attempts
People who touched revisions under test:
Ard Biesheuvel
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=28ade7b802e0732cf9839017ee6e9cf78b842582
+ . ./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 ovmf
28ade7b802e0732cf9839017ee6e9cf78b842582
+ branch=ovmf
+ revision=28ade7b802e0732cf9839017ee6e9cf78b842582
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x28ade7b802e0732cf9839017ee6e9cf78b842582 = 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 $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:
Re: [Xen-devel] [PATCH v3 3/4] tools: use pidfile for test if xenstored is running
On Fri, Jul 22, 2016 at 05:09:30PM +0200, Juergen Gross wrote:
> Instead of trying to read xenstore via xenstore-read use the pidfile
> of xenstored for the test whether xenstored is running. This prepares
> support of xenstore domain, as trying to read xenstore will block
> for ever in case xenstore domain is started after trying to read.
>
> Signed-off-by: Juergen Gross
> ---
> tools/hotplug/Linux/init.d/xencommons.in | 2 +-
> tools/hotplug/Linux/launch-xenstore.in | 58
> +++-
> 2 files changed, 35 insertions(+), 25 deletions(-)
>
> diff --git a/tools/hotplug/Linux/init.d/xencommons.in
> b/tools/hotplug/Linux/init.d/xencommons.in
> index a32608c..a6a40d6 100644
> --- a/tools/hotplug/Linux/init.d/xencommons.in
> +++ b/tools/hotplug/Linux/init.d/xencommons.in
> @@ -96,7 +96,7 @@ case "$1" in
> do_start
> ;;
>status)
> -${bindir}/xenstore-read -s /
> +test -f @XEN_RUN_DIR@/xenstored.pid
> ;;
>stop)
> do_stop
> diff --git a/tools/hotplug/Linux/launch-xenstore.in
> b/tools/hotplug/Linux/launch-xenstore.in
> index a0cbfd3..2bd9f64 100644
> --- a/tools/hotplug/Linux/launch-xenstore.in
> +++ b/tools/hotplug/Linux/launch-xenstore.in
> @@ -18,38 +18,48 @@
> XENSTORED=@XENSTORED@
>
> . @XEN_SCRIPT_DIR@/hotplugpath.sh
> -test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && .
> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
>
> -time=0
> -timeout=30
> +test_xenstore () {
> + test -f /var/run/xenstored.pid
You need to change this to @XEN_RUN_DIR@ as well.
Other than this, this patch looks good to me.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 21/22] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry
On Tue, Aug 02, 2016 at 10:58:00AM +0100, Julien Grall wrote:
> On 01/08/2016 19:22, Mark Rutland wrote:
> >On Mon, Aug 01, 2016 at 06:26:54PM +0100, Mark Rutland wrote:
> >>On Mon, Aug 01, 2016 at 05:57:50PM +0100, Julien Grall wrote:
> >>>however we only need one TLBI instruction (assuming there is
> >>>no superpage shattering) per-batch rather than one per-entry in this
> >>>case.
> >>
> >>I got Cc'd to a reply without the original patch context, so I'm not
> >>sure what the case is here. I'm not exactly sure what you mean by
> >>"per-batch".
>
> Sorry for that. I CCed in case I did not summarize correctly the
> conversation we had.
>
> The page table handling code can be found in patch #18 [1].
If I've understood, you're asking if you can do a TLBI VMALLE1IS per
batch of leaf entry updates in p2m_set_entry?
As below, if only the AP and/or XN bits are changing, that should be
safe. If any other fields are being altered (inc. the output address,
even for intermediate entries), that may not be safe.
> >>Assuming that you've (only) changed the permissions (i.e. the AP bits
> >>and XN bits) of a number of stage-2 leaf entries, you need either:
> >>* Per entry, a TLBI IPAS2LE1IS
> >>
> >> e.g.
> > for_each_entry(x)
> >modify_ap_bits(x);
> > dsb(ishst);
> > for_each_entry(x)
> >tlbi(ipas2le1is, x);
> > dsb(ish);
>
> I have a question related to this example. Is there a threshold
> where invalidate all the TLB entry for a given VMID/ASID is worth?
Strictly speaking, "yes", but the value is going to depend on
implementation and workload, so there's no "good" value as such provided
by the architecture.
In Linux, we end up doing so in some cases to avoid softlockups. Look
for MAX_TLB_RANGE in arch/arm64/include/asm/tlbflush.h. There are some
more details in commit 05ac65305437e8ef ("arm64: fix soft lockup due to
large tlb flush range").
Thanks,
Mark.
> [1] https://lists.xen.org/archives/html/xen-devel/2016-07/msg02966.html
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/4] tools: use pidfile for test if xenstored is running
On 02/08/16 12:23, Wei Liu wrote:
> On Fri, Jul 22, 2016 at 05:09:30PM +0200, Juergen Gross wrote:
>> Instead of trying to read xenstore via xenstore-read use the pidfile
>> of xenstored for the test whether xenstored is running. This prepares
>> support of xenstore domain, as trying to read xenstore will block
>> for ever in case xenstore domain is started after trying to read.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> tools/hotplug/Linux/init.d/xencommons.in | 2 +-
>> tools/hotplug/Linux/launch-xenstore.in | 58
>> +++-
>> 2 files changed, 35 insertions(+), 25 deletions(-)
>>
>> diff --git a/tools/hotplug/Linux/init.d/xencommons.in
>> b/tools/hotplug/Linux/init.d/xencommons.in
>> index a32608c..a6a40d6 100644
>> --- a/tools/hotplug/Linux/init.d/xencommons.in
>> +++ b/tools/hotplug/Linux/init.d/xencommons.in
>> @@ -96,7 +96,7 @@ case "$1" in
>> do_start
>> ;;
>>status)
>> -${bindir}/xenstore-read -s /
>> +test -f @XEN_RUN_DIR@/xenstored.pid
>> ;;
>>stop)
>> do_stop
>> diff --git a/tools/hotplug/Linux/launch-xenstore.in
>> b/tools/hotplug/Linux/launch-xenstore.in
>> index a0cbfd3..2bd9f64 100644
>> --- a/tools/hotplug/Linux/launch-xenstore.in
>> +++ b/tools/hotplug/Linux/launch-xenstore.in
>> @@ -18,38 +18,48 @@
>> XENSTORED=@XENSTORED@
>>
>> . @XEN_SCRIPT_DIR@/hotplugpath.sh
>> -test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && .
>> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
>>
>> -time=0
>> -timeout=30
>> +test_xenstore () {
>> +test -f /var/run/xenstored.pid
>
> You need to change this to @XEN_RUN_DIR@ as well.
Indeed. Thanks for noticing.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 66883: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 66883 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66883/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 3 host-install(3) broken REGR. vs. 66875 build-i3863 host-install(3) broken REGR. vs. 66875 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 66875 test-amd64-amd64-libvirt 3 host-install(3) broken REGR. vs. 66875 test-amd64-amd64-libvirt-xsm 3 host-install(3) broken REGR. vs. 66875 test-amd64-amd64-xl-qcow2 3 host-install(3) broken REGR. vs. 66875 test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 66875 test-armhf-armhf-xl-vhd 9 debian-di-install fail REGR. vs. 66875 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-pvh-intel 3 host-install(3) broken like 66875 test-amd64-amd64-qemuu-nested-amd 3 host-install(3) broken like 66875 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3)broken like 66875 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66875 test-amd64-amd64-amd64-pvgrub 10 guest-start fail like 66875 Tests which did not succeed, but are not blocking: build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-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-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start 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-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 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-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-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-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 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 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 version targeted for testing: qemuucc0100f464c94bf80ad36cd432f4a1ed58126b60 baseline version: qemuu69d490079f82f5ffe31fff426aaa580d5fec5fb7 Last test of basis66875 2016-08-01 02:16:10 Z1 days Testing same since6688
Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian
On 02.08.2016 11:20, Wei Liu wrote: On Fri, Jul 29, 2016 at 10:17:22PM +0200, Ingo Jürgensmann wrote: What is also interesting is that you seem to be running some sort of ip accounting software (pmacctd) which also segfault'ed. Yeah, it is segfaulting, because the database (in a domU VM) where it is storing the accounting is not yet available after the crash. When database is up&running, those segfaults go away. Still not sure what to make of that though. Me neither. ;-) I already tried to get a core dump by setting ulimit -c unlimited, but that didn't work as well, which makes me believe that the crash happens in hypervisor not in dom0 kernel. When it's dom0 kernel I would expect dumping a core file should work. -- Ciao... //http://blog.windfluechter.net Ingo \X/ XMPP: i...@jabber.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/4] tools: split out xenstored starting form xencommons
In order to prepare starting a xenstore domain split out the starting
of the xenstore daemon from the xencommons script into a dedicated
launch-xenstore script.
Correct one error: don't remove old tdb files in background, as this
could lead to very subtle races.
A rerun of autogen.sh is required.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/configure | 3 +-
tools/configure.ac | 1 +
tools/hotplug/Linux/Makefile | 1 +
tools/hotplug/Linux/init.d/xencommons.in | 36 ++---
tools/hotplug/Linux/launch-xenstore.in | 55
6 files changed, 63 insertions(+), 34 deletions(-)
create mode 100644 tools/hotplug/Linux/launch-xenstore.in
diff --git a/.gitignore b/.gitignore
index 9b8dece..d193820 100644
--- a/.gitignore
+++ b/.gitignore
@@ -157,6 +157,7 @@ tools/hotplug/Linux/init.d/xen-watchdog
tools/hotplug/Linux/init.d/xencommons
tools/hotplug/Linux/init.d/xendomains
tools/hotplug/Linux/init.d/xendriverdomain
+tools/hotplug/Linux/launch-xenstore
tools/hotplug/Linux/systemd/*.conf
tools/hotplug/Linux/systemd/*.mount
tools/hotplug/Linux/systemd/*.socket
diff --git a/tools/configure b/tools/configure
index 1c84c6c..51f16c5 100755
--- a/tools/configure
+++ b/tools/configure
@@ -2410,7 +2410,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
-ac_config_files="$ac_config_files ../config/Tools.mk
hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain
hotplug/Linux/init.d/sysconfig.xencommons
hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog
hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains
hotplug/Linux/init.d/xendriverdomain hotplug/Linux/vif-setup
hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains
hotplug/NetBSD/rc.d/xencommons hotplug/NetBSD/rc.d/xendriverdomain
libxl/xenlight.pc.in libxl/xlutil.pc.in ocaml/xenstored/oxenstored.conf"
+ac_config_files="$ac_config_files ../config/Tools.mk
hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain
hotplug/Linux/init.d/sysconfig.xencommons
hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog
hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains
hotplug/Linux/init.d/xendriverdomain hotplug/Linux/launch-xenstore
hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh
hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons
hotplug/NetBSD/rc.d/xendriverdomain libxl/xenlight.pc.in libxl/xlutil.pc.in
ocaml/xenstored/oxenstored.conf"
ac_config_headers="$ac_config_headers config.h"
@@ -10376,6 +10376,7 @@ do
"hotplug/Linux/init.d/xencommons") CONFIG_FILES="$CONFIG_FILES
hotplug/Linux/init.d/xencommons" ;;
"hotplug/Linux/init.d/xendomains") CONFIG_FILES="$CONFIG_FILES
hotplug/Linux/init.d/xendomains" ;;
"hotplug/Linux/init.d/xendriverdomain") CONFIG_FILES="$CONFIG_FILES
hotplug/Linux/init.d/xendriverdomain" ;;
+"hotplug/Linux/launch-xenstore") CONFIG_FILES="$CONFIG_FILES
hotplug/Linux/launch-xenstore" ;;
"hotplug/Linux/vif-setup") CONFIG_FILES="$CONFIG_FILES
hotplug/Linux/vif-setup" ;;
"hotplug/Linux/xen-hotplug-common.sh") CONFIG_FILES="$CONFIG_FILES
hotplug/Linux/xen-hotplug-common.sh" ;;
"hotplug/Linux/xendomains") CONFIG_FILES="$CONFIG_FILES
hotplug/Linux/xendomains" ;;
diff --git a/tools/configure.ac b/tools/configure.ac
index f991ab3..3a4abb5 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -15,6 +15,7 @@ hotplug/Linux/init.d/xen-watchdog
hotplug/Linux/init.d/xencommons
hotplug/Linux/init.d/xendomains
hotplug/Linux/init.d/xendriverdomain
+hotplug/Linux/launch-xenstore
hotplug/Linux/vif-setup
hotplug/Linux/xen-hotplug-common.sh
hotplug/Linux/xendomains
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 6d6ccee..29280cb 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -30,6 +30,7 @@ XEN_SCRIPTS += block-drbd-probe
XEN_SCRIPTS += block-dummy
XEN_SCRIPTS += $(XEN_SCRIPTS-y)
XEN_SCRIPTS += colo-proxy-setup
+XEN_SCRIPTS += launch-xenstore
SUBDIRS-$(CONFIG_SYSTEMD) += systemd
diff --git a/tools/hotplug/Linux/init.d/xencommons.in
b/tools/hotplug/Linux/init.d/xencommons.in
index 2d8f30b..a32608c 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -18,7 +18,6 @@
# Description: Starts and stops the daemons neeeded for xl/xend
### END INIT INFO
-XENSTORED=@XENSTORED@
BACKEND_MODULES="@LINUX_BACKEND_MODULES@"
. @XEN_SCRIPT_DIR@/hotplugpath.sh
@@ -53,8 +52,6 @@ if test -f /proc/xen/capabilities && \
fi
do_start () {
-local time=0
- local timeout=30
local mod
for mod in $BACKEND_MODULES ; do modprobe "$mod" &>/dev/null ; done
@@ -62,37 +59,10 @@ do_start () {
mkdir -p ${XEN_RUN_DIR}
mkdir -p ${XEN_LOCK_DIR}
- if ! `${bindir}/xenstore-read -s / >/dev/nul
[Xen-devel] [PATCH v4 1/4] tools: remove systemd xenstore socket definitions
On a system with systemd the xenstore sockets are created via systemd. Remove the related configuration files in order to be able to decide at runtime whether the sockets should be created or not. This will enable Xen to start xenstore either via a daemon or via a stub domain. As the xenstore domain start program will exit after it has done its job prepare the same behaviour to be tolerated by systemd for the xenstore daemon by specifying the appropriate flags in the service file. A rerun of autogen.sh is required. Signed-off-by: Juergen Gross --- V4: remove sd_booted() test, undo unintended white space changes V3: re-add sd_notify() call --- tools/configure| 4 +- tools/configure.ac | 2 - tools/hotplug/Linux/systemd/Makefile | 5 - tools/hotplug/Linux/systemd/xenstored.service.in | 5 +- tools/hotplug/Linux/systemd/xenstored.socket.in| 13 --- tools/hotplug/Linux/systemd/xenstored_ro.socket.in | 13 --- tools/ocaml/xenstored/systemd.ml | 2 - tools/ocaml/xenstored/systemd.mli | 8 -- tools/ocaml/xenstored/systemd_stubs.c | 98 tools/ocaml/xenstored/utils.ml | 9 +- tools/ocaml/xenstored/xenstored.ml | 3 +- tools/xenstore/xenstored_core.c| 103 + 12 files changed, 10 insertions(+), 255 deletions(-) delete mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in diff --git a/tools/configure b/tools/configure index 5b5dcce..1c84c6c 100755 --- a/tools/configure +++ b/tools/configure @@ -9670,7 +9670,7 @@ fi if test "x$systemd" = "xy"; then : -ac_config_files="$ac_config_files hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xendriverdomain.service hotplug/Linux/systemd/xenstored.service hotplug/Linux/systemd/xenstored.socket hotplug/Linux/systemd/xenstored_ro.socket" +ac_config_files="$ac_config_files hotplug/Linux/systemd/proc-xen.mount hotplug/Linux/systemd/var-lib-xenstored.mount hotplug/Linux/systemd/xen-init-dom0.service hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service hotplug/Linux/systemd/xen-watchdog.service hotplug/Linux/systemd/xenconsoled.service hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xendriverdomain.service hotplug/Linux/systemd/xenstored.service" fi @@ -10394,8 +10394,6 @@ do "hotplug/Linux/systemd/xendomains.service") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xendomains.service" ;; "hotplug/Linux/systemd/xendriverdomain.service") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xendriverdomain.service" ;; "hotplug/Linux/systemd/xenstored.service") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xenstored.service" ;; -"hotplug/Linux/systemd/xenstored.socket") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xenstored.socket" ;; -"hotplug/Linux/systemd/xenstored_ro.socket") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/xenstored_ro.socket" ;; *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;; esac diff --git a/tools/configure.ac b/tools/configure.ac index 87e14a8..f991ab3 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -438,8 +438,6 @@ AS_IF([test "x$systemd" = "xy"], [ hotplug/Linux/systemd/xendomains.service hotplug/Linux/systemd/xendriverdomain.service hotplug/Linux/systemd/xenstored.service -hotplug/Linux/systemd/xenstored.socket -hotplug/Linux/systemd/xenstored_ro.socket ]) ]) diff --git a/tools/hotplug/Linux/systemd/Makefile b/tools/hotplug/Linux/systemd/Makefile index 558e459..7d24bbe 100644 --- a/tools/hotplug/Linux/systemd/Makefile +++ b/tools/hotplug/Linux/systemd/Makefile @@ -6,9 +6,6 @@ XEN_SYSTEMD_MODULES = xen.conf XEN_SYSTEMD_MOUNT = proc-xen.mount XEN_SYSTEMD_MOUNT += var-lib-xenstored.mount -XEN_SYSTEMD_SOCKET = xenstored.socket -XEN_SYSTEMD_SOCKET += xenstored_ro.socket - XEN_SYSTEMD_SERVICE = xenstored.service XEN_SYSTEMD_SERVICE += xenconsoled.service XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service @@ -19,7 +16,6 @@ XEN_SYSTEMD_SERVICE += xendriverdomain.service ALL_XEN_SYSTEMD = $(XEN_SYSTEMD_MODULES) \ $(XEN_SYSTEMD_MOUNT)\ - $(XEN_SYSTEMD_SOCKET) \ $(XEN_SYSTEMD_SERVICE) .PHONY: all @@ -38,7 +34,6 @@ install: $(ALL_XEN_SYSTEMD) $(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_DIR) [ -d $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD) ] || \ $(INSTALL_DIR) $(DESTD
[Xen-devel] [PATCH v4 4/4] tools: make xenstore domain easy configurable
Add configuration entries to sysconfig.xencommons for selection of the
xenstore type (domain or daemon) and start the selected xenstore
service via a script called from sysvinit or systemd.
Signed-off-by: Juergen Gross
---
V3: - remove check for running xenstore domain, as this is done in
init-xenstore-domain already
- if booted with systemd send a systemd-notify message in the
xenstore domain case
- if booted with systemd don't wait until xenstore daemon is
running, as the daemon will have sent a notify message by its
own
- split up patch as requested by Ian Jackson
V2: - add .gitignore entry for launch-xenstore
---
tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 42 --
tools/hotplug/Linux/launch-xenstore.in | 42 --
tools/hotplug/Linux/systemd/xenstored.service.in | 8 +
3 files changed, 72 insertions(+), 20 deletions(-)
diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index c27a476..cc8185c 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -6,12 +6,24 @@
#XENCONSOLED_TRACE=[none|guest|hv|all]
## Type: string
+## Default: daemon
+#
+# Select type of xentore service.
+#
+# This can be either of:
+# * daemon
+# * domain
+#
+# Changing this requires a reboot to take effect.
+#
+#XENSTORETYPE=daemon
+
+## Type: string
## Default: xenstored
#
# Select xenstore implementation, this can be either
-# of these below. If using systemd it's preferred that you
-# just edit the xenstored.service unit file and change
-# the XENSTORED variable there.
+# of these below.
+# Only evaluated if XENSTORETYPE is "daemon".
#
# This can be either of:
# * @sbindir@/oxenstored
@@ -26,21 +38,45 @@
# Additional commandline arguments to start xenstored,
# like "--trace-file @XEN_LOG_DIR@/xenstored-trace.log"
# See "@sbindir@/xenstored --help" for possible options.
+# Only evaluated if XENSTORETYPE is "daemon".
XENSTORED_ARGS=
## Type: string
## Default: Not defined, tracing off
#
# Log xenstored messages
+# Only evaluated if XENSTORETYPE is "daemon".
#XENSTORED_TRACE=[yes|on|1]
## Type: string
## Default: "@XEN_LIB_STORED@"
#
# Running xenstored on XENSTORED_ROOTDIR
+# Only evaluated if XENSTORETYPE is "daemon".
#XENSTORED_ROOTDIR=@XEN_LIB_STORED@
## Type: string
+## Default: @LIBEXEC@/boot/xenstore-stubdom.gz
+#
+# xenstore domain kernel.
+# Only evaluated if XENSTORETYPE is "domain".
+#XENSTORE_DOMAIN_KERNEL=@LIBEXEC@/boot/xenstore-stubdom.gz
+
+## Type: integer
+## Default: 8
+#
+# xenstore domain memory size in MiB.
+# Only evaluated if XENSTORETYPE is "domain".
+#XENSTORE_DOMAIN_SIZE=8
+
+## Type: string
+## Default: ""
+#
+# Additional arguments for starting the xenstore domain.
+# Only evaluated if XENSTORETYPE is "domain".
+XENSTORE_DOMAIN_ARGS=
+
+## Type: string
## Default: Not defined, xenbackendd debug mode off
#
# Running xenbackendd in debug mode
diff --git a/tools/hotplug/Linux/launch-xenstore.in
b/tools/hotplug/Linux/launch-xenstore.in
index caa9345..cf98bd1 100644
--- a/tools/hotplug/Linux/launch-xenstore.in
+++ b/tools/hotplug/Linux/launch-xenstore.in
@@ -48,18 +48,40 @@ test_xenstore && exit 0
test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && .
@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
-test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
-rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null
-test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T
@XEN_LOG_DIR@/xenstored-trace.log"
+[ "$XENSTORETYPE" = "" ] && XENSTORETYPE=daemon
+
+/bin/mkdir -p @XEN_RUN_DIR@
+
+[ "$XENSTORETYPE" = "daemon" ] && {
+ [ -z "$XENSTORED_ROOTDIR" ] && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
+ /bin/rm -f $XENSTORED_ROOTDIR/tdb* 2>/dev/null
+ [ -z "$XENSTORED_TRACE" ] || XENSTORED_ARGS="$XENSTORED_ARGS -T
@XEN_LOG_DIR@/xenstored-trace.log"
+ [ -z "$XENSTORED" ] && XENSTORED=@XENSTORED@
+ [ -x "$XENSTORED" ] || {
+ echo "No xenstored found"
+ exit 1
+ }
-if [ -n "$XENSTORED" ] ; then
echo -n Starting $XENSTORED...
$XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS
-else
- echo "No xenstored found"
- exit 1
-fi
-timeout_xenstore $XENSTORED || exit 1
+ systemd-notify --booted 2>/dev/null || timeout_xenstore $XENSTORED ||
exit 1
-exit 0
+ exit 0
+}
+
+[ "$XENSTORETYPE" = "domain" ] && {
+ [ -z "$XENSTORE_DOMAIN_KERNEL" ] &&
XENSTORE_DOMAIN_KERNEL=@LIBEXEC@/boot/xenstore-stubdom.gz
+ XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS --kernel
$XENSTORE_DOMAIN_KERNEL"
+ [ -z "$XENSTORE_DOMAIN_SIZE" ] && XENSTORE_DOMAIN_SIZE=8
+ XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS --memory
$XENSTORE_DOMAIN_SIZE"
+
+ echo -n Starting $XENSTORE_DOMAIN_KERNEL...
+ ${LIBEXEC_BIN}/init-xenstore-domain $XENSTORE_D
Re: [Xen-devel] [PATCH] x86: use gcc6'es flags asm() output support
>>> On 02.08.16 at 11:15, wrote:
> On 02/08/16 07:09, Jan Beulich wrote:
> On 01.08.16 at 19:11, wrote:
>>> On 01/08/16 17:06, Jan Beulich wrote:
>>> On 01.07.16 at 18:51, wrote:
> How about a different example, from the second hunk
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -832,8 +832,19 @@ static int read_ulong(
> static bool_t mul_dbl(unsigned long m[2])
> {
> bool_t rc;
> -asm ( "mul %1; seto %2"
> - : "+a" (m[0]), "+d" (m[1]), "=qm" (rc) );
> +
> +asm ( "mul %1;"
> +#ifndef __GCC_ASM_FLAG_OUTPUTS__
> + "seto %[rc];"
> +#endif
> + : "+a" (m[0]), "+d" (m[1]),
> +#ifdef __GCC_ASM_FLAG_OUTPUTS__
> +[rc] "=@cco" (rc)
> +#else
> +[rc] "=qm" (rc)
> +#endif
> +);
> +
> return rc;
> }
Looking at this again I think I really like the original, submitted version
better. Are you strongly biased towards the above form?
>>> I am not overly fussed between this version and the original submission.
>>>
>>> However, I definitely think that we shouldn't hide semantic bits of the
>>> ASM statement behind macros.
>> Well, the originally submitted variant doesn't do anything like that,
>> so may I translate the above to an ack?
>
> You do already have a Rev-by from my first reply.
Oops, indeed. I'm sorry for the noise then.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/4] tools: use pidfile for test if xenstored is running
Instead of trying to read xenstore via xenstore-read use the pidfile
of xenstored for the test whether xenstored is running. This prepares
support of xenstore domain, as trying to read xenstore will block
for ever in case xenstore domain is started after trying to read.
Signed-off-by: Juergen Gross
---
V4: use @XEN_RUN_DIR@ as requested by Wei Liu
---
tools/hotplug/Linux/init.d/xencommons.in | 2 +-
tools/hotplug/Linux/launch-xenstore.in | 58 +++-
2 files changed, 35 insertions(+), 25 deletions(-)
diff --git a/tools/hotplug/Linux/init.d/xencommons.in
b/tools/hotplug/Linux/init.d/xencommons.in
index a32608c..a6a40d6 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -96,7 +96,7 @@ case "$1" in
do_start
;;
status)
-${bindir}/xenstore-read -s /
+test -f @XEN_RUN_DIR@/xenstored.pid
;;
stop)
do_stop
diff --git a/tools/hotplug/Linux/launch-xenstore.in
b/tools/hotplug/Linux/launch-xenstore.in
index a0cbfd3..caa9345 100644
--- a/tools/hotplug/Linux/launch-xenstore.in
+++ b/tools/hotplug/Linux/launch-xenstore.in
@@ -18,38 +18,48 @@
XENSTORED=@XENSTORED@
. @XEN_SCRIPT_DIR@/hotplugpath.sh
-test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && .
@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
-time=0
-timeout=30
+test_xenstore () {
+ test -f @XEN_RUN_DIR@/xenstored.pid
+ return $?
+}
-if ! `${bindir}/xenstore-read -s / >/dev/null 2>&1`
-then
- test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
- rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null
- test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T
@XEN_LOG_DIR@/xenstored-trace.log"
+timeout_xenstore () {
+ local time=0
+ local timeout=30
- if [ -n "$XENSTORED" ] ; then
- echo -n Starting $XENSTORED...
- $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS
- else
- echo "No xenstored found"
- exit 1
- fi
-
- # Wait for xenstored to actually come up, timing out after 30 seconds
- while [ $time -lt $timeout ] && ! `${bindir}/xenstore-read -s /
>/dev/null 2>&1` ; do
- echo -n .
- time=$(($time+1))
- sleep 1
+ while [ $time -lt $timeout ] && ! test_xenstore ; do
+ echo -n .
+ time=$(($time+1))
+ sleep 1
done
echo
-
+
# Exit if we timed out
if ! [ $time -lt $timeout ] ; then
- echo Could not start xenstored
- exit 1
+ echo "Could not start $@"
+ return 1
fi
+
+ return 0
+}
+
+test_xenstore && exit 0
+
+test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && .
@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
+
+test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@"
+rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null
+test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T
@XEN_LOG_DIR@/xenstored-trace.log"
+
+if [ -n "$XENSTORED" ] ; then
+ echo -n Starting $XENSTORED...
+ $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid $XENSTORED_ARGS
+else
+ echo "No xenstored found"
+ exit 1
fi
+timeout_xenstore $XENSTORED || exit 1
+
exit 0
--
2.6.6
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 0/4] tools: make xenstore domain/daemon configurable
Add a configuration option to /etc/sysconfig/xencommons to let the user configure whether he wants to start xenstore service as a daemon or as a stubdom. Changes in V4: - patch 1: remove sd_booted() test, undo unintended white space changes - patch 3: use @XEN_RUN_DIR@ as requested by Wei Liu Changes in V3: - patch 1: re-add sd_notify() call - split up former patch 2 into 3 patches as requested by Ian Jackson - patch 4 (was 2): remove check for running xenstore domain, as this is done in init-xenstore-domain already - patch 4 (was 2): if booted with systemd send a systemd-notify message in the xenstore domain case - patch 4 (was 2): if booted with systemd don't wait until xenstore daemon is running, as the daemon will have sent a notify message by its own Changes in V2: - move service type modification form patch 2 to patch 1 as implied by Ross Lagerwall (at least I guess so) - add .gitignore entry for launch-xenstore Juergen Gross (4): tools: remove systemd xenstore socket definitions tools: split out xenstored starting form xencommons tools: use pidfile for test if xenstored is running tools: make xenstore domain easy configurable .gitignore | 1 + tools/configure| 7 +- tools/configure.ac | 3 +- tools/hotplug/Linux/Makefile | 1 + tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 42 - tools/hotplug/Linux/init.d/xencommons.in | 38 +--- tools/hotplug/Linux/launch-xenstore.in | 87 + tools/hotplug/Linux/systemd/Makefile | 5 - tools/hotplug/Linux/systemd/xenstored.service.in | 13 +-- tools/hotplug/Linux/systemd/xenstored.socket.in| 13 --- tools/hotplug/Linux/systemd/xenstored_ro.socket.in | 13 --- tools/ocaml/xenstored/systemd.ml | 2 - tools/ocaml/xenstored/systemd.mli | 8 -- tools/ocaml/xenstored/systemd_stubs.c | 98 tools/ocaml/xenstored/utils.ml | 9 +- tools/ocaml/xenstored/xenstored.ml | 3 +- tools/xenstore/xenstored_core.c| 103 + 17 files changed, 146 insertions(+), 300 deletions(-) create mode 100644 tools/hotplug/Linux/launch-xenstore.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in delete mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in -- 2.6.6 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] live migration to qemu.git fails
On Tue, Aug 02, Olaf Hering wrote: > Doing a live migration of a HVM domU from staging-4.5 with its included > qemu-xen to staging-4.7 with qemu-xen from qemu.org (either master or > 2.6.0) fails: It fails also with staging-4.6 and staging-4.7 and their included qemu-xen binaries, and staging-4.7 with qemu-xen from qemu.org as target. Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] libxl: fix printing hotplug arguments/environment
An OS could decide to not pass any environment variables to hotplug scripts,
and this will trigger a bug in device_hotplug logic, since it expects the
environment array to exist. Allow env to be NULL.
Signed-off-by: Roger Pau Monné
---
Cc: Wei Liu
Cc: Ian Jackson
---
Changes since v1:
- Fix commit message
- Only allow env to be NULL.
---
tools/libxl/libxl_device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index b9a6df2..dbf157d 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1130,6 +1130,7 @@ static void device_hotplug(libxl__egc *egc,
libxl__ao_device *aodev)
goto out;
}
+assert(args != NULL);
LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]);
LOG(DEBUG, "extra args:");
{
@@ -1140,7 +1141,7 @@ static void device_hotplug(libxl__egc *egc,
libxl__ao_device *aodev)
LOG(DEBUG, "\t%s", arg);
}
LOG(DEBUG, "env:");
-{
+if (env != NULL) {
const char *k, *v;
unsigned int x;
--
2.7.4 (Apple Git-66)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] libxl: fix printing hotplug arguments/environment
On Tue, Aug 02, 2016 at 12:49:51PM +0200, Roger Pau Monne wrote:
> An OS could decide to not pass any environment variables to hotplug scripts,
> and this will trigger a bug in device_hotplug logic, since it expects the
> environment array to exist. Allow env to be NULL.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
> ---
> Cc: Wei Liu
> Cc: Ian Jackson
> ---
> Changes since v1:
> - Fix commit message
> - Only allow env to be NULL.
> ---
> tools/libxl/libxl_device.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index b9a6df2..dbf157d 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -1130,6 +1130,7 @@ static void device_hotplug(libxl__egc *egc,
> libxl__ao_device *aodev)
> goto out;
> }
>
> +assert(args != NULL);
> LOG(DEBUG, "calling hotplug script: %s %s", args[0], args[1]);
> LOG(DEBUG, "extra args:");
> {
> @@ -1140,7 +1141,7 @@ static void device_hotplug(libxl__egc *egc,
> libxl__ao_device *aodev)
> LOG(DEBUG, "\t%s", arg);
> }
> LOG(DEBUG, "env:");
> -{
> +if (env != NULL) {
> const char *k, *v;
> unsigned int x;
>
> --
> 2.7.4 (Apple Git-66)
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space
On Thu, Jul 28, 2016 at 12:06:11PM +0100, Julien Grall wrote: > Hi, > > On 26/07/16 02:17, Boris Ostrovsky wrote: > >On 07/25/2016 07:40 PM, Stefano Stabellini wrote: > >>On Mon, 25 Jul 2016, Boris Ostrovsky wrote: > >>>On 07/25/2016 06:06 PM, Stefano Stabellini wrote: > On Mon, 25 Jul 2016, George Dunlap wrote: > >On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini > > wrote: > Going back to the discussion about how to account for the ACPI blob in > maxmem, let's make this simple, if we increase maxmem by the size of > the > ACPI blob: > > - the toolstack allocates more RAM than expected (bad) > - when the admin specifies 1GB of RAM, the guest actually gets 1GB of > usable RAM (good) > - things are faster as Xen and the guest can exploit superpage mappings > more easily at stage-1 and stage-2 (good) > > Let's call this option A. > > If we do not increase maxmem: > > - the toolstack allocates less RAM, closer to the size specified in the > VM config file (good) > - the guest gets less usable memory than expected, less than what was > specified in the VM config file (bad) > >>> > >>>Not sure I agree with this, at least for x86/Linux: guest gets 1GB of > >>>usable RAM and part of that RAM stores ACPI stuff. Guest is free to > >>>stash ACPI tables somewhere else or ignore them altogether and use that > >>>memory for whatever it wants. > >>On ARM it will be a ROM (from guest POV) > > > > > >In which case I don't see why we should take it from maxmem allocation. > >I somehow thought that there was a choice of whether to put it in ROM or > >RAM on ARM but if it's ROM only then I don't think there is an option. > > We have option to do the both on ARM. I just feel that the ROM option is a > cleaner interface because the ACPI tables are not supposed be modified by > the guest, so we can prevent to be overridden (+ all the advantages > mentioned by Stefano with option A). > > >IIUIC the toolstack pretends that the blob goes to memory because that's > >how its interfaces work but that space is not really what we think about > >when we set memory/maxmem in the configuration file. Unlike x86. > > I think we need to draw a conclusion for Shannon to continue to do the work > and I would like to see this series in Xen 4.8. From my understanding you > are for option B, so does George. > > Stefano votes for option A, but find B acceptable. Any other opinions? > From my PoV I just need things to be clearly documented. Wei. > Regards, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space
On Thu, Jul 28, 2016 at 08:42:05PM +0800, Shannon Zhao wrote: > On 2016年07月28日 19:06, Julien Grall wrote: > > On 26/07/16 02:17, Boris Ostrovsky wrote: > >> On 07/25/2016 07:40 PM, Stefano Stabellini wrote: > >>> On Mon, 25 Jul 2016, Boris Ostrovsky wrote: > On 07/25/2016 06:06 PM, Stefano Stabellini wrote: > > On Mon, 25 Jul 2016, George Dunlap wrote: > >> On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini > >> wrote: > > Going back to the discussion about how to account for the ACPI blob in > > maxmem, let's make this simple, if we increase maxmem by the size of > > the > > ACPI blob: > > > > - the toolstack allocates more RAM than expected (bad) > > - when the admin specifies 1GB of RAM, the guest actually gets 1GB of > >usable RAM (good) > > - things are faster as Xen and the guest can exploit superpage > > mappings > >more easily at stage-1 and stage-2 (good) > > > > Let's call this option A. > > > > If we do not increase maxmem: > > > > - the toolstack allocates less RAM, closer to the size specified in > > the > >VM config file (good) > > - the guest gets less usable memory than expected, less than what was > >specified in the VM config file (bad) > > Not sure I agree with this, at least for x86/Linux: guest gets 1GB of > usable RAM and part of that RAM stores ACPI stuff. Guest is free to > stash ACPI tables somewhere else or ignore them altogether and use that > memory for whatever it wants. > >>> On ARM it will be a ROM (from guest POV) > >> > >> > >> In which case I don't see why we should take it from maxmem allocation. > >> I somehow thought that there was a choice of whether to put it in ROM or > >> RAM on ARM but if it's ROM only then I don't think there is an option. > > > > We have option to do the both on ARM. I just feel that the ROM option is > > a cleaner interface because the ACPI tables are not supposed be modified > > by the guest, so we can prevent to be overridden (+ all the advantages > > mentioned by Stefano with option A). > > > >> IIUIC the toolstack pretends that the blob goes to memory because that's > >> how its interfaces work but that space is not really what we think about > >> when we set memory/maxmem in the configuration file. Unlike x86. > > > > I think we need to draw a conclusion for Shannon to continue to do the > > work and I would like to see this series in Xen 4.8. From my > > understanding you are for option B, so does George. > > > > Stefano votes for option A, but find B acceptable. Any other opinions? > I agree with Stefano, both are fine. > Sorry for the late reply. Are you now unblocked? If not, what is not yet decided or needed clarification? Wei. > Thanks, > -- > Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/4] tools: remove systemd xenstore socket definitions
On Tue, Aug 02, 2016 at 12:39:25PM +0200, Juergen Gross wrote: > On a system with systemd the xenstore sockets are created via systemd. > Remove the related configuration files in order to be able to decide > at runtime whether the sockets should be created or not. This will > enable Xen to start xenstore either via a daemon or via a stub domain. > > As the xenstore domain start program will exit after it has done its > job prepare the same behaviour to be tolerated by systemd for the > xenstore daemon by specifying the appropriate flags in the service > file. > > A rerun of autogen.sh is required. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu The ocaml bits would need an ack from Dave. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/4] tools: split out xenstored starting form xencommons
On Tue, Aug 02, 2016 at 12:39:26PM +0200, Juergen Gross wrote: > In order to prepare starting a xenstore domain split out the starting > of the xenstore daemon from the xencommons script into a dedicated > launch-xenstore script. > > Correct one error: don't remove old tdb files in background, as this > could lead to very subtle races. > Sorry to only notice this now -- I suppose this shouldn't be in commit message because it is a changelog for different revision of your patch, or you need to describe what the race is if there is really such issue -- and that's a potential backport candidate. As far as I can tell this is pure code motion and shouldn't have any change in behaviour. Hence this line in commit message makes me feel a bit confused. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 3/4] tools: use pidfile for test if xenstored is running
On Tue, Aug 02, 2016 at 12:39:27PM +0200, Juergen Gross wrote: > Instead of trying to read xenstore via xenstore-read use the pidfile > of xenstored for the test whether xenstored is running. This prepares > support of xenstore domain, as trying to read xenstore will block > for ever in case xenstore domain is started after trying to read. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 4/4] tools: make xenstore domain easy configurable
On Tue, Aug 02, 2016 at 12:39:28PM +0200, Juergen Gross wrote: > Add configuration entries to sysconfig.xencommons for selection of the > xenstore type (domain or daemon) and start the selected xenstore > service via a script called from sysvinit or systemd. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On 02/08/16 08:38, Julien Grall wrote: > Hello Tamas, > > On 01/08/2016 21:41, Tamas K Lengyel wrote: >> On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall >> wrote: we did discuss whether altp2m on ARM should be exposed to guests or not but we did not agree whether restricting it on ARM is absolutely necessary. Altp2m was designed even on the x86 to be accessible from within the guest on all systems irrespective of actual hardware support for it. Thus, this design fits ARM as well where there is no dedicated hardware support, from the altp2m perspective there is no difference. >>> >>> >>> Really? I looked at the design document [1] which is Intel focus. >>> Similar >>> think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c). >> >> That design cover letter mentions specifically "Both VMFUNC and #VE >> are designed such that a VMM can emulate them on legacy CPUs". While >> they certainly had only Intel hardware in-mind, the software route can >> also be taken on ARM as well. As our primary use-case is purely >> external use of altp2m we have not implemented the bits that enable >> the injection of mem_access faults into the guest (equivalent of #VE). >> Whether without that the altp2m switching from within the guest make >> sense or not is beyond the scope of this series but as it could >> technically be implemented in the future, I don't see a reason to >> disable that possibility right away. > > The question here, is how a guest could take advantage to access to > altp2m on ARM today? Whilst on x86 a guest could be notified about > memaccess change, this is not yet the case on ARM. > > So, from my understanding, exposing this feature to a guest is like > exposing a no-op with side effects. We should avoid to expose feature to > the guest until there is a real usage and the guest could do something > useful with it. It seems like having guest altp2m support without the equivalent of a #VE does seem pretty useless. Would you disagree with this assessment, Tamas? Every interface we expose to the guest increases the surface of attack; so it seems like until there is a usecase for guest altp2m, we should probably disable it. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/4] tools: split out xenstored starting form xencommons
On 02/08/16 13:13, Wei Liu wrote: > On Tue, Aug 02, 2016 at 12:39:26PM +0200, Juergen Gross wrote: >> In order to prepare starting a xenstore domain split out the starting >> of the xenstore daemon from the xencommons script into a dedicated >> launch-xenstore script. >> >> Correct one error: don't remove old tdb files in background, as this >> could lead to very subtle races. >> > > Sorry to only notice this now -- I suppose this shouldn't be in commit > message because it is a changelog for different revision of your patch, > or you need to describe what the race is if there is really such issue > -- and that's a potential backport candidate. - rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null ... + rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null Please note the "&" in the removed line. And the description just tells you that: the file shouldn't be removed in the background. How else would you describe it? And the race should be obvious: removing a file in the background which is going to be used by the next command is racy. > As far as I can tell this is pure code motion and shouldn't have any > change in behaviour. Hence this line in commit message makes me feel a > bit confused. Still confused? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0096/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- drivers/block/xen-blkback/blkback.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 4809c15..73251ce 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -63,7 +63,7 @@ */ static int xen_blkif_max_buffer_pages = 1024; -module_param_named(max_buffer_pages, xen_blkif_max_buffer_pages, int, 0644); +module_param_named(max_buffer_pages, xen_blkif_max_buffer_pages, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(max_buffer_pages, "Maximum number of free pages to keep in each block backend buffer"); @@ -79,7 +79,7 @@ MODULE_PARM_DESC(max_buffer_pages, */ static int xen_blkif_max_pgrants = 1056; -module_param_named(max_persistent_grants, xen_blkif_max_pgrants, int, 0644); +module_param_named(max_persistent_grants, xen_blkif_max_pgrants, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(max_persistent_grants, "Maximum number of grants to map persistently"); @@ -88,7 +88,7 @@ MODULE_PARM_DESC(max_persistent_grants, * are CPUs if user has not specified a value. */ unsigned int xenblk_max_queues; -module_param_named(max_queues, xenblk_max_queues, uint, 0644); +module_param_named(max_queues, xenblk_max_queues, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(max_queues, "Maximum number of hardware queues per virtual disk." \ "By default it is the number of online CPUs."); @@ -116,7 +116,7 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order of pages to be used for the /* Run-time switchable: /sys/module/blkback/parameters/ */ static unsigned int log_stats; -module_param(log_stats, int, 0644); +module_param(log_stats, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); #define BLKBACK_INVALID_HANDLE (~0) -- 2.9.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hap: use the right cache attributes when MTRR is disabled
On Mon, Aug 01, 2016 at 09:33:56AM -0600, Jan Beulich wrote: > >>> On 26.07.16 at 18:15, wrote: > > --- a/xen/arch/x86/hvm/mtrr.c > > +++ b/xen/arch/x86/hvm/mtrr.c > > @@ -814,10 +814,17 @@ int epte_get_entry_emt(struct domain *d, unsigned > > long gfn, mfn_t mfn, > > if ( gmtrr_mtype == -EADDRNOTAVAIL ) > > return -1; > > > > -gmtrr_mtype = is_hvm_domain(d) && v ? > > Where did the is_hvm_domain() go? Let's not break PVHv1 just yet. Hm, TBH I don't see why this is needed, AFAICT PVHv1 guests will never have MTRR enabled, so they will just go into the MTRR_TYPE_WRBACK case. > > - get_mtrr_type(&v->arch.hvm_vcpu.mtrr, > > -gfn << PAGE_SHIFT, order) : > > - MTRR_TYPE_WRBACK; > > +if ( v && v->arch.hvm_vcpu.mtrr.enabled ) > > +/* MTRR is enabled, use MTRR */ > > +gmtrr_mtype = get_mtrr_type(&v->arch.hvm_vcpu.mtrr, gfn << > > PAGE_SHIFT, > > +order); > > +else if ( v && !hvm_paging_enabled(v) ) > > +/* MTRR is not enabled and paging is disabled, force UC */ > > +gmtrr_mtype = MTRR_TYPE_UNCACHABLE; > > +else > > +/* MTRR is not enabled and paging is enabled, use PAT */ > > +gmtrr_mtype = MTRR_TYPE_WRBACK; > > I think this would then better be > > if ( v ) Aren't all guests going to fall into this case, and thus MTRR_TYPE_WRBACK is going to be returned without even checking if the guest has MTRR enabled or not? Do you mean "if ( !v )" instead? > gmtrr_mtype = MTRR_TYPE_WRBACK; > else if ( v->arch.hvm_vcpu.mtrr.enabled ) > /* MTRR is enabled, use MTRR */ > gmtrr_mtype = get_mtrr_type(&v->arch.hvm_vcpu.mtrr, gfn << PAGE_SHIFT, > order); > else if ( !hvm_paging_enabled(v) ) > /* MTRR is not enabled and paging is disabled, force UC */ > gmtrr_mtype = MTRR_TYPE_UNCACHABLE; > else > /* MTRR is not enabled and paging is enabled, use PAT */ > gmtrr_mtype = MTRR_TYPE_WRBACK; > > albeit even then using vCPU 0 feels wrong when d != current->domain. > Plus v->arch.hvm_vcpu.mtrr.enabled isn't really a boolean, so I think > its use also needs refining. Yes, I've realized that the check against v->arch.hvm_vcpu.mtrr.enabled is wrong, I will change it, but I'm not sure how to fix the d != current->domain comments that you mention. > And finally please fix the comment style. Right, thanks for the review. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 99900: tolerable all pass - PUSHED
flight 99900 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99900/
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 2eee1c746af6f683247700642786b7c21c991234
baseline version:
xen caefc852d5a3be3965a0c0131ce62e7f3a313f04
Last test of basis99890 2016-08-01 17:01:54 Z0 days
Testing same since99900 2016-08-02 10:01:42 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=2eee1c746af6f683247700642786b7c21c991234
+ . ./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
2eee1c746af6f683247700642786b7c21c991234
+ branch=xen-unstable-smoke
+ revision=2eee1c746af6f683247700642786b7c21c991234
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x2eee1c746af6f683247700642786b7c21c991234 = 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 $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://githu
Re: [Xen-devel] [PATCH 2/2] xen: drain submit queue in xen-usb before removing device
On Fr, 2016-07-29 at 13:17 +0200, Juergen Gross wrote:
> When unplugging a device in the Xen pvusb backend drain the submit
> queue before deallocation of the control structures. Otherwise there
> will be bogus memory accesses when I/O contracts are finished.
>
> Correlated to this issue is the handling of cancel requests: a packet
> cancelled will still lead to the call of complete, so add a flag
> A
=== checkpatch complains ===
WARNING: braces {} are necessary for all arms of this statement
#105: FILE: hw/usb/xen-usb.c:696:
+if (sched)
[...]
WARNING: braces {} are necessary for all arms of this statement
#111: FILE: hw/usb/xen-usb.c:702:
+if (!usbif->ports[port - 1].attached)
[...]
WARNING: braces {} are necessary for all arms of this statement
#152: FILE: hw/usb/xen-usb.c:847:
+if (usbif->ports[i].dev)
[...]
cheers,
Gerd
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote: > Introducing HVMCTL, Jan wrote: > > A long while back separating out all control kind operations (intended > > for use by only the control domain or device model) from the currect > > hvmop hypercall has been discussed. This series aims at finally making > > this reality (at once allowing to streamline the associated XSM checking). > > I think we need to introduce a new hypercall (which I will call DMOP > for now) which may augment or replace some of HVMCTL. Let me explain: > > > We would like to be able to deprivilege qemu-in-dom0. This is > because qemu has a large attack surface and has a history of security > bugs. If we get this right we can easily reduce the impact of `guest > can take over qemu' bugs to DoS; and perhaps with a bit of effort we > can eliminate the DoS too. (qemu stubdom are another way to do this > but they have their own difficulties.) > > A part of this plan has to be a way for qemu to make hypercalls > related to the guest it is servicing. But qemu needs to be _unable_ > to make _other_ hypercalls. > > I see four possible approaches. In IMO increasing order of > desirability: > > 1. We could simply patch the dom0 privcmd driver to know exactly which >hypercalls are permitted. This is obviously never going to work >because there would have to be a massive table in the kernel, kept >in step with Xen. We could have a kind of pattern matching engine >instead, and load the tables from userspace, but that's a daft >edifice to be building (even if we reuse BPF or something) and a >total pain to maintain. > > 2. We could have some kind of privileged proxy or helper process, >which makes the hypercalls on instruction from qemu. This would be >quite complicated and involve a lot of back-and-forth parameter >passing. Like option 1, this arrangement would end up embedding >detailed knowledge about which hypercalls are appropriate, and have >to understand all of their parameters. > > 3. We could have the dom0 privcmd driver wrap each of qemu's >hypercalls in a special "wrap up with different XSM tag" hypercall. >Then, we could specify the set of allowable hypercalls with XSM. >If we want qemu deprivileged by default, this depends on turning >XSM on by default. But we want qemu depriv ASAP and there are >difficulties with XSM by default. This approach also involves >writing a large and hard-to-verify hypercall permission table, in >the form of an XSM policy. > > 4. We could invent a new hypercall `DMOP' for hypercalls which device >models should be able to use, which always has the target domain in >a fixed location in the arguments. We have the dom0 privcmd driver >know about this one hypercall number and the location of the target >domid. > > Option 4 has the following advantages: > > * The specification of which hypercalls are authorised to qemu is > integrated with the specification of the hypercalls themselves: > There is no need to maintain a separate table which can get out of > step (or contain security bugs). > > * The changes required to the rest of the system are fairly small. > In particular: > > * We need only one small, non-varying, patch to the dom0 kernel. > I think your analysis makes sense. > > Let me flesh out option 4 in more detail: > > > We define a new hypercall DMOP. > > Its first argument is always a target domid. The DMOP hypercall > number and position of the target domid in the arguments are fixed. > > A DMOP is defined to never put at risk the stability or security of > the whole system, nor of the domain which calls DMOP. However, a DMOP > may have arbitrary effects on the target domid. > I would like to point out that this is non-trivial since we would need to audit a lot of stuff. But the requirement to audit interface is not unique to DMOP -- I expect this is needed for any other approach. > In the privcmd driver, we provide a new restriction ioctl, which takes > a domid parameter. After that restriction ioctl is called, the > privcmd driver will permit only DMOP hypercalls, and only with the > specified target domid. > It is phrased like that the guest kernel is supposed to enforce the policy? Would it be possible to make Xen do it? I don't think we should trust DM domain kernel here. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: > >>> On 01.08.16 at 13:32, wrote: > > 4. We could invent a new hypercall `DMOP' for hypercalls which device > >models should be able to use, which always has the target domain in > >a fixed location in the arguments. We have the dom0 privcmd driver > >know about this one hypercall number and the location of the target > >domid. > > > > Option 4 has the following advantages: > > > > * The specification of which hypercalls are authorised to qemu is > > integrated with the specification of the hypercalls themselves: > > There is no need to maintain a separate table which can get out of > > step (or contain security bugs). > > > > * The changes required to the rest of the system are fairly small. > > In particular: > > > > * We need only one small, non-varying, patch to the dom0 kernel. > > > > > > Let me flesh out option 4 in more detail: > > > > > > We define a new hypercall DMOP. > > > > Its first argument is always a target domid. The DMOP hypercall > > number and position of the target domid in the arguments are fixed. > > > > A DMOP is defined to never put at risk the stability or security of > > the whole system, nor of the domain which calls DMOP. However, a DMOP > > may have arbitrary effects on the target domid. > > With the exception of this and the privcmd layer described below, > DMOP == HVMCTL afaics. The privcmd layer is independent anyway. > And the security aspect mentioned above won't disappear if we > use DMOP instead of HVMCTL. So I don't see why the hvmctl > series as is can't be the starting point of this, with the stability/ > security concerns addressed subsequently, for being orthogonal. > Yeah, to turn HVMCTL to DMOP: 1. s/HVMCTL/DMOP/ 2. maybe s/interface_version// I think we could at least do #1 and merge the series. Wei. > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/4] tools: split out xenstored starting form xencommons
On Tue, Aug 02, 2016 at 01:20:40PM +0200, Juergen Gross wrote: > On 02/08/16 13:13, Wei Liu wrote: > > On Tue, Aug 02, 2016 at 12:39:26PM +0200, Juergen Gross wrote: > >> In order to prepare starting a xenstore domain split out the starting > >> of the xenstore daemon from the xencommons script into a dedicated > >> launch-xenstore script. > >> > >> Correct one error: don't remove old tdb files in background, as this > >> could lead to very subtle races. > >> > > > > Sorry to only notice this now -- I suppose this shouldn't be in commit > > message because it is a changelog for different revision of your patch, > > or you need to describe what the race is if there is really such issue > > -- and that's a potential backport candidate. > > - rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null > ... > + rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null > > Please note the "&" in the removed line. And the description just tells > you that: the file shouldn't be removed in the background. How else > would you describe it? > > And the race should be obvious: removing a file in the background which > is going to be used by the next command is racy. > > > As far as I can tell this is pure code motion and shouldn't have any > > change in behaviour. Hence this line in commit message makes me feel a > > bit confused. > > Still confused? Ah, the 2> vs &> thing is really subtle. I missed that, sorry. I think you need to separate that one change out so that we can backport it to stable releases to avoid the race. Wei. > > > Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls
On Di, 2016-08-02 at 08:32 +0200, Juergen Gross wrote: > Instead of calling xen_be_register() for each supported backend type > for hvm and pv guests in their machine init functions use a common > function in order not to have to add new backends twice. > > This at once fixes the error that hvm domains couldn't use the qusb > backend. Looks good to me. Should I take this through the usb patch queue, together with the other xen-usb fixes (once codestyle issues are fixed)? If so, can I get an ack from xen please, preferably fast enough for -rc2? thanks, Gerd ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
On 02/08/16 12:37, Wei Liu wrote: > On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote: >> Introducing HVMCTL, Jan wrote: >>> A long while back separating out all control kind operations (intended >>> for use by only the control domain or device model) from the currect >>> hvmop hypercall has been discussed. This series aims at finally making >>> this reality (at once allowing to streamline the associated XSM checking). >> >> I think we need to introduce a new hypercall (which I will call DMOP >> for now) which may augment or replace some of HVMCTL. Let me explain: >> >> >> We would like to be able to deprivilege qemu-in-dom0. This is >> because qemu has a large attack surface and has a history of security >> bugs. If we get this right we can easily reduce the impact of `guest >> can take over qemu' bugs to DoS; and perhaps with a bit of effort we >> can eliminate the DoS too. (qemu stubdom are another way to do this >> but they have their own difficulties.) >> >> A part of this plan has to be a way for qemu to make hypercalls >> related to the guest it is servicing. But qemu needs to be _unable_ >> to make _other_ hypercalls. >> >> I see four possible approaches. In IMO increasing order of >> desirability: >> >> 1. We could simply patch the dom0 privcmd driver to know exactly which >>hypercalls are permitted. This is obviously never going to work >>because there would have to be a massive table in the kernel, kept >>in step with Xen. We could have a kind of pattern matching engine >>instead, and load the tables from userspace, but that's a daft >>edifice to be building (even if we reuse BPF or something) and a >>total pain to maintain. >> >> 2. We could have some kind of privileged proxy or helper process, >>which makes the hypercalls on instruction from qemu. This would be >>quite complicated and involve a lot of back-and-forth parameter >>passing. Like option 1, this arrangement would end up embedding >>detailed knowledge about which hypercalls are appropriate, and have >>to understand all of their parameters. >> >> 3. We could have the dom0 privcmd driver wrap each of qemu's >>hypercalls in a special "wrap up with different XSM tag" hypercall. >>Then, we could specify the set of allowable hypercalls with XSM. >>If we want qemu deprivileged by default, this depends on turning >>XSM on by default. But we want qemu depriv ASAP and there are >>difficulties with XSM by default. This approach also involves >>writing a large and hard-to-verify hypercall permission table, in >>the form of an XSM policy. >> >> 4. We could invent a new hypercall `DMOP' for hypercalls which device >>models should be able to use, which always has the target domain in >>a fixed location in the arguments. We have the dom0 privcmd driver >>know about this one hypercall number and the location of the target >>domid. >> >> Option 4 has the following advantages: >> >> * The specification of which hypercalls are authorised to qemu is >> integrated with the specification of the hypercalls themselves: >> There is no need to maintain a separate table which can get out of >> step (or contain security bugs). >> >> * The changes required to the rest of the system are fairly small. >> In particular: >> >> * We need only one small, non-varying, patch to the dom0 kernel. >> > > I think your analysis makes sense. > >> >> Let me flesh out option 4 in more detail: >> >> >> We define a new hypercall DMOP. >> >> Its first argument is always a target domid. The DMOP hypercall >> number and position of the target domid in the arguments are fixed. >> >> A DMOP is defined to never put at risk the stability or security of >> the whole system, nor of the domain which calls DMOP. However, a DMOP >> may have arbitrary effects on the target domid. >> > > I would like to point out that this is non-trivial since we would need > to audit a lot of stuff. > > But the requirement to audit interface is not unique to DMOP -- I expect > this is needed for any other approach. > >> In the privcmd driver, we provide a new restriction ioctl, which takes >> a domid parameter. After that restriction ioctl is called, the >> privcmd driver will permit only DMOP hypercalls, and only with the >> specified target domid. >> > > It is phrased like that the guest kernel is supposed to enforce the > policy? Would it be possible to make Xen do it? I don't think we should > trust DM domain kernel here. The problem is that Xen doesn't know what process is running, and so can't tell whether qemuA is accessing domainA's memory, or whether qemuB is accessing domainA's memory. The two options that have been proposed are: 1. Have a way for dom0 to give Xen an XSM tag for the current process (so Xen can do the enforcing) 2. Have dom0 filter out the calls based on the fact that all the hypercalls have the same template (i.e., domid in the same position). Either w
[Xen-devel] [distros-debian-snapshot test] 66884: trouble: blocked/broken/fail/pass
flight 66884 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66884/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken REGR. vs. 66811 build-amd64-pvops 3 host-install(3) broken REGR. vs. 66811 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail blocked in 66811 Tests which did not succeed, but are not blocking: test-amd64-i386-amd64-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-i386-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-current-netinst-pygrub 1 build-check(1)blocked n/a test-amd64-amd64-i386-current-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-i386-i386-daily-netboot-pvgrub 1 build-check(1)blocked n/a test-amd64-i386-amd64-daily-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-daily-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-daily-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-i386-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-weekly-netinst-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-weekly-netinst-pygrub 1 build-check(1) blocked n/a baseline version: flight 66811 jobs: build-amd64 broken build-armhf pass build-i386 pass build-amd64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-daily-netboot-pvgrub blocked test-amd64-i386-i386-daily-netboot-pvgrubblocked test-amd64-i386-amd64-daily-netboot-pygrub blocked test-armhf-armhf-armhf-daily-netboot-pygrub fail test-amd64-amd64-i386-daily-netboot-pygrub blocked test-amd64-amd64-amd64-current-netinst-pygrubblocked test-amd64-i386-amd64-current-netinst-pygrub blocked test-amd64-amd64-i386-current-netinst-pygrub blocked test-amd64-i386-i386-current-netinst-pygrub blocked test-amd64-amd64-amd64-weekly-netinst-pygrub blocked test-amd64-i386-amd64-weekly-netinst-pygrub blocked test-amd64-amd64-i386-weekly-netinst-pygrub blocked test-amd64-i386-i386-weekly-netinst-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default
Thanks for your reply. I installed the debug hypervisor and got a new crash dump now. I must confess that I have little to no experience debugging crash dumps, but this seems to be a different kind of error, or at least the way the error is reached is different. The pattern with “page number X invalid” and the “restore” repeats for all preceding domains visible in the dump. […] (XEN) memory.c:269:d164v0 Domain 164 page number 54fc invalid (XEN) memory.c:269:d164v0 Domain 164 page number 54fd invalid (XEN) grant_table.c:1491:d164v0 Expanding dom (164) grant table from (4) to (32) frames. (XEN) Dom164 callback via changed to GSI 28 (XEN) HVM165 restore: VM saved on one CPU (0x206c2) and restored on another (0x106a5). (XEN) HVM165 restore: CPU 0 (XEN) HVM165 restore: PIC 0 (XEN) HVM165 restore: PIC 1 (XEN) HVM165 restore: IOAPIC 0 (XEN) HVM165 restore: LAPIC 0 (XEN) HVM165 restore: LAPIC_REGS 0 (XEN) HVM165 restore: PCI_IRQ 0 (XEN) HVM165 restore: ISA_IRQ 0 (XEN) HVM165 restore: PCI_LINK 0 (XEN) HVM165 restore: PIT 0 (XEN) HVM165 restore: RTC 0 (XEN) HVM165 restore: HPET 0 (XEN) HVM165 restore: PMTIMER 0 (XEN) HVM165 restore: MTRR 0 (XEN) HVM165 restore: VMCE_VCPU 0 (XEN) HVM165 restore: TSC_ADJUST 0 (XEN) memory.c:269:d165v0 Domain 165 page number 54de invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54df invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e0 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e1 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e2 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e3 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e4 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e5 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e6 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e7 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e8 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54e9 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54ea invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54eb invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54ec invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54ed invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54ee invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54ef invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f0 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f1 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f2 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f3 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f4 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f5 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f6 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f7 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f8 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54f9 invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54fa invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54fb invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54fc invalid (XEN) memory.c:269:d165v0 Domain 165 page number 54fd invalid (XEN) grant_table.c:1491:d165v0 Expanding dom (165) grant table from (4) to (32) frames. (XEN) Dom165 callback via changed to GSI 28 (XEN) Debugging connection not set up. (XEN) [ Xen-4.6.1 x86_64 debug=y Not tainted ] (XEN) CPU:6 (XEN) RIP:e008:[] vmx_vmenter_helper+0x27e/0x30a (XEN) RFLAGS: 00010003 CONTEXT: hypervisor (XEN) rax: 8005003b rbx: 8300e72fc000 rcx: (XEN) rdx: 6c00 rsi: 830617fd7fc0 rdi: 8300e6fc (XEN) rbp: 830617fd7c40 rsp: 830617fd7c30 r8: (XEN) r9: 830be8dc9310 r10: r11: 3475e9cf85d0 (XEN) r12: 0006 r13: 830c14ee1000 r14: 8300e6fc (XEN) r15: 830617fd cr0: 8005003b cr4: 26e0 (XEN) cr3: 0001bd665000 cr2: 0451 (XEN) ds: es: fs: gs: ss: cs: e008 (XEN) Xen stack trace from rsp=830617fd7c30: (XEN)830617fd7c40 8300e72fc000 830617fd7ca0 82d080174f91 (XEN)830617fd7f18 830be8dc9000 0286 830617fd7c90 (XEN)0206 0246 0001 830617e91250 (XEN)8300e72fc000 830be8dc9000 830617fd7cc0 82d080178c19 (XEN)00bdeeae 8300e72fc000 830617fd7cd0 82d080178c3e (XEN)830617fd7d20 82d080179740 8300e6fc2000 830c17e38e80 (XEN)830617e91250 82008000 0002 830617e91250 (XEN)830617e91240 830be8dc9000 830617fd7d70 82d080196152 (XEN)830617fd7d50 82d0801f7c6b 8300e6fc2000 830617e91250 (XEN)8300e6fc2000 830617e91250 830617e91240 830be8dc9000 (XEN)830617fd7d80 82d080244a6
Re: [Xen-devel] [PATCH 2/2] xen: drain submit queue in xen-usb before removing device
On 02/08/16 13:37, Gerd Hoffmann wrote: > On Fr, 2016-07-29 at 13:17 +0200, Juergen Gross wrote: >> When unplugging a device in the Xen pvusb backend drain the submit >> queue before deallocation of the control structures. Otherwise there >> will be bogus memory accesses when I/O contracts are finished. >> >> Correlated to this issue is the handling of cancel requests: a packet >> cancelled will still lead to the call of complete, so add a flag >> A > > === checkpatch complains === Aargh, sorry! Wrote too many Xen and Linux patches recently. I'll correct those. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/hap: use the right cache attributes when MTRR is disabled
>>> On 02.08.16 at 13:25, wrote: > On Mon, Aug 01, 2016 at 09:33:56AM -0600, Jan Beulich wrote: >> >>> On 26.07.16 at 18:15, wrote: >> > --- a/xen/arch/x86/hvm/mtrr.c >> > +++ b/xen/arch/x86/hvm/mtrr.c >> > @@ -814,10 +814,17 @@ int epte_get_entry_emt(struct domain *d, unsigned >> > long gfn, mfn_t mfn, >> > if ( gmtrr_mtype == -EADDRNOTAVAIL ) >> > return -1; >> > >> > -gmtrr_mtype = is_hvm_domain(d) && v ? >> >> Where did the is_hvm_domain() go? Let's not break PVHv1 just yet. > > Hm, TBH I don't see why this is needed, AFAICT PVHv1 guests will never have > MTRR enabled, so they will just go into the MTRR_TYPE_WRBACK case. Ah, good point. But please then briefly mention this in the description. >> > - get_mtrr_type(&v->arch.hvm_vcpu.mtrr, >> > -gfn << PAGE_SHIFT, order) : >> > - MTRR_TYPE_WRBACK; >> > +if ( v && v->arch.hvm_vcpu.mtrr.enabled ) >> > +/* MTRR is enabled, use MTRR */ >> > +gmtrr_mtype = get_mtrr_type(&v->arch.hvm_vcpu.mtrr, gfn << >> > PAGE_SHIFT, >> > +order); >> > +else if ( v && !hvm_paging_enabled(v) ) >> > +/* MTRR is not enabled and paging is disabled, force UC */ >> > +gmtrr_mtype = MTRR_TYPE_UNCACHABLE; >> > +else >> > +/* MTRR is not enabled and paging is enabled, use PAT */ >> > +gmtrr_mtype = MTRR_TYPE_WRBACK; >> >> I think this would then better be >> >> if ( v ) > > Aren't all guests going to fall into this case, and thus MTRR_TYPE_WRBACK is > going to be returned without even checking if the guest has MTRR enabled or > not? Do you mean "if ( !v )" instead? Indeed I did mean that. >> gmtrr_mtype = MTRR_TYPE_WRBACK; >> else if ( v->arch.hvm_vcpu.mtrr.enabled ) >> /* MTRR is enabled, use MTRR */ >> gmtrr_mtype = get_mtrr_type(&v->arch.hvm_vcpu.mtrr, gfn << >> PAGE_SHIFT, >> order); >> else if ( !hvm_paging_enabled(v) ) >> /* MTRR is not enabled and paging is disabled, force UC */ >> gmtrr_mtype = MTRR_TYPE_UNCACHABLE; >> else >> /* MTRR is not enabled and paging is enabled, use PAT */ >> gmtrr_mtype = MTRR_TYPE_WRBACK; >> >> albeit even then using vCPU 0 feels wrong when d != current->domain. >> Plus v->arch.hvm_vcpu.mtrr.enabled isn't really a boolean, so I think >> its use also needs refining. > > Yes, I've realized that the check against v->arch.hvm_vcpu.mtrr.enabled is > wrong, I will change it, but I'm not sure how to fix the d != > current->domain comments that you mention. And I don't think you absolutely need to do something about that right away, as you're not introducing that issue (you just slightly widen it). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
>>> On 02.08.16 at 13:38, wrote: > On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: >> >>> On 01.08.16 at 13:32, wrote: >> > 4. We could invent a new hypercall `DMOP' for hypercalls which device >> >models should be able to use, which always has the target domain in >> >a fixed location in the arguments. We have the dom0 privcmd driver >> >know about this one hypercall number and the location of the target >> >domid. >> > >> > Option 4 has the following advantages: >> > >> > * The specification of which hypercalls are authorised to qemu is >> > integrated with the specification of the hypercalls themselves: >> > There is no need to maintain a separate table which can get out of >> > step (or contain security bugs). >> > >> > * The changes required to the rest of the system are fairly small. >> > In particular: >> > >> > * We need only one small, non-varying, patch to the dom0 kernel. >> > >> > >> > Let me flesh out option 4 in more detail: >> > >> > >> > We define a new hypercall DMOP. >> > >> > Its first argument is always a target domid. The DMOP hypercall >> > number and position of the target domid in the arguments are fixed. >> > >> > A DMOP is defined to never put at risk the stability or security of >> > the whole system, nor of the domain which calls DMOP. However, a DMOP >> > may have arbitrary effects on the target domid. >> >> With the exception of this and the privcmd layer described below, >> DMOP == HVMCTL afaics. The privcmd layer is independent anyway. >> And the security aspect mentioned above won't disappear if we >> use DMOP instead of HVMCTL. So I don't see why the hvmctl >> series as is can't be the starting point of this, with the stability/ >> security concerns addressed subsequently, for being orthogonal. >> > > Yeah, to turn HVMCTL to DMOP: > > 1. s/HVMCTL/DMOP/ > 2. maybe s/interface_version// Andrew had brought up 2 too, but I'm really not sure that'd be a good idea. I rather think we should keep it but maybe (other than domctl/sysctl) recognize older versions. In any event I consider having it better for an unstable interface (as Ian said, libxc is supposed to provide the stable one). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 23/25] arm/altp2m: Extend libxl to activate altp2m on ARM.
On Mon, Aug 01, 2016 at 07:10:26PM +0200, Sergej Proskurin wrote:
> The current implementation allows to set the parameter HVM_PARAM_ALTP2M.
> This parameter allows further usage of altp2m on ARM. For this, we
> define an additional, common altp2m field as part of the
> libxl_domain_type struct. This field can be set on x86 and on ARM systems
> through the "altp2m" switch in the domain's configuration file (i.e.
> set altp2m=1).
>
> Note, that the old parameter "altp2mhvm" is still valid for x86. Since
> this commit defines this old parameter as deprecated, libxl will
> generate a warning during processing.
>
> Signed-off-by: Sergej Proskurin
> ---
> Cc: Ian Jackson
> Cc: Wei Liu
> ---
> v2: The macro LIBXL_HAVE_ALTP2M is now valid for x86 and ARM.
>
> Moved the field altp2m out of info->u.pv.altp2m into the common
> field info->altp2m, where it can be accessed independent by the
> underlying architecture (x86 or ARM). Now, altp2m can be activated
> by the guest control parameter "altp2m".
>
> Adopted initialization routines accordingly.
> ---
> tools/libxl/libxl.h | 3 ++-
> tools/libxl/libxl_create.c | 8 +---
> tools/libxl/libxl_dom.c | 4 ++--
> tools/libxl/libxl_types.idl | 4 +++-
> tools/libxl/xl_cmdimpl.c| 26 +-
> 5 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 48a43ce..a2cbd34 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -839,7 +839,8 @@ typedef struct libxl__ctx libxl_ctx;
>
> /*
> * LIBXL_HAVE_ALTP2M
> - * If this is defined, then libxl supports alternate p2m functionality.
> + * If this is defined, then libxl supports alternate p2m functionality for
> + * x86 HVM and ARM PV guests.
> */
> #define LIBXL_HAVE_ALTP2M 1
Either you misunderstood or I said something wrong.
These macros have defined semantics that shouldn't be changed because
application code uses them to detect the presence / absence of certain
things.
We need a new macro for ARM altp2m. I think
LIBXL_HAVE_ARM_ALTP2M
would do.
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index d7db9e9..16d3b52 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -319,7 +319,6 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
> libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
> libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
> libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
> -libxl_defbool_setdefault(&b_info->u.hvm.altp2m, false);
> libxl_defbool_setdefault(&b_info->u.hvm.usb,false);
> libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
>
> @@ -406,6 +405,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
> libxl_domain_type_to_string(b_info->type));
> return ERROR_INVAL;
> }
> +
> +libxl_defbool_setdefault(&b_info->altp2m, false);
> +
> return 0;
> }
>
> @@ -901,8 +903,8 @@ static void initiate_domain_create(libxl__egc *egc,
>
> if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
> (libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) &&
> - libxl_defbool_val(d_config->b_info.u.hvm.altp2m))) {
> -LOG(ERROR, "nestedhvm and altp2mhvm cannot be used together");
> + libxl_defbool_val(d_config->b_info.altp2m))) {
> +LOG(ERROR, "nestedhvm and altp2m cannot be used together");
> goto error_out;
> }
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index ec29060..1550ef8 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -291,8 +291,6 @@ static void hvm_set_conf_params(xc_interface *handle,
> uint32_t domid,
> libxl_defbool_val(info->u.hvm.vpt_align));
> xc_hvm_param_set(handle, domid, HVM_PARAM_NESTEDHVM,
> libxl_defbool_val(info->u.hvm.nested_hvm));
> -xc_hvm_param_set(handle, domid, HVM_PARAM_ALTP2M,
> -libxl_defbool_val(info->u.hvm.altp2m));
> }
>
> int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> @@ -434,6 +432,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> #endif
> }
>
> +xc_hvm_param_set(ctx->xch, domid, HVM_PARAM_ALTP2M,
> libxl_defbool_val(info->altp2m));
> +
And the reason for moving this call to this function is?
> rc = libxl__arch_domain_create(gc, d_config, domid);
>
> return rc;
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ef614be..42e7c95 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -512,7 +512,6 @@ libxl_domain_build_info = Struct("domain_build_info",[
> ("mmio_hole_memkb", MemKB),
> ("timer_mode",
> libx
Re: [Xen-devel] [PATCH v4 2/4] tools: split out xenstored starting form xencommons
On Tue, Aug 02, Juergen Gross wrote: > - rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null > + rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null > > Please note the "&" in the removed line. And the description just tells > you that: the file shouldn't be removed in the background. How else > would you describe it? "&>" redirects stdout and stderr at the same time. See bash(1) "Redirecting Standard Output and Standard Error". Are you saying it does fork into background instead? Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/4] tools: split out xenstored starting form xencommons
On 02/08/16 13:59, Olaf Hering wrote: > On Tue, Aug 02, Juergen Gross wrote: > >> -rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null >> +rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null >> >> Please note the "&" in the removed line. And the description just tells >> you that: the file shouldn't be removed in the background. How else >> would you describe it? > > "&>" redirects stdout and stderr at the same time. See bash(1) > "Redirecting Standard Output and Standard Error". > Are you saying it does fork into background instead? No. I'm saying that I managed to overlook that part of the man page. I explicitly had a look as I didn't know the &> notation and I wanted to make sure I don't miss anything. I failed obviously. :-( Thanks for the bash lesson. :-) V5 is about to come... Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] xen: drain submit queue in xen-usb before removing device
When unplugging a device in the Xen pvusb backend drain the submit
queue before deallocation of the control structures. Otherwise there
will be bogus memory accesses when I/O contracts are finished.
Correlated to this issue is the handling of cancel requests: a packet
cancelled will still lead to the call of complete, so add a flag
to the request indicating it should be just dropped on complete.
Signed-off-by: Juergen Gross
---
hw/usb/xen-usb.c | 94 +---
1 file changed, 62 insertions(+), 32 deletions(-)
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 7992456..174d715 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -90,6 +90,8 @@ struct usbback_req {
void *buffer;
void *isoc_buffer;
struct libusb_transfer *xfer;
+
+bool cancelled;
};
struct usbback_hotplug {
@@ -301,20 +303,23 @@ static void usbback_do_response(struct usbback_req
*usbback_req, int32_t status,
usbback_req->isoc_buffer = NULL;
}
-res = RING_GET_RESPONSE(&usbif->urb_ring, usbif->urb_ring.rsp_prod_pvt);
-res->id = usbback_req->req.id;
-res->status = status;
-res->actual_length = actual_length;
-res->error_count = error_count;
-res->start_frame = 0;
-usbif->urb_ring.rsp_prod_pvt++;
-RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&usbif->urb_ring, notify);
+if (usbif->urb_sring) {
+res = RING_GET_RESPONSE(&usbif->urb_ring,
usbif->urb_ring.rsp_prod_pvt);
+res->id = usbback_req->req.id;
+res->status = status;
+res->actual_length = actual_length;
+res->error_count = error_count;
+res->start_frame = 0;
+usbif->urb_ring.rsp_prod_pvt++;
+RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&usbif->urb_ring, notify);
-if (notify) {
-xen_be_send_notify(xendev);
+if (notify) {
+xen_be_send_notify(xendev);
+}
}
-usbback_put_req(usbback_req);
+if (!usbback_req->cancelled)
+usbback_put_req(usbback_req);
}
static void usbback_do_response_ret(struct usbback_req *usbback_req,
@@ -366,15 +371,14 @@ static void usbback_set_address(struct usbback_info
*usbif,
}
}
-static bool usbback_cancel_req(struct usbback_req *usbback_req)
+static void usbback_cancel_req(struct usbback_req *usbback_req)
{
-bool ret = false;
-
if (usb_packet_is_inflight(&usbback_req->packet)) {
usb_cancel_packet(&usbback_req->packet);
-ret = true;
+QTAILQ_REMOVE(&usbback_req->stub->submit_q, usbback_req, q);
+usbback_req->cancelled = true;
+usbback_do_response_ret(usbback_req, -EPROTO);
}
-return ret;
}
static void usbback_process_unlink_req(struct usbback_req *usbback_req)
@@ -391,7 +395,7 @@ static void usbback_process_unlink_req(struct usbback_req
*usbback_req)
devnum = usbif_pipedevice(usbback_req->req.pipe);
if (unlikely(devnum == 0)) {
usbback_req->stub = usbif->ports +
-usbif_pipeportnum(usbback_req->req.pipe);
+usbif_pipeportnum(usbback_req->req.pipe) - 1;
if (unlikely(!usbback_req->stub)) {
ret = -ENODEV;
goto fail_response;
@@ -406,9 +410,7 @@ static void usbback_process_unlink_req(struct usbback_req
*usbback_req)
QTAILQ_FOREACH(unlink_req, &usbback_req->stub->submit_q, q) {
if (unlink_req->req.id == id) {
-if (usbback_cancel_req(unlink_req)) {
-usbback_do_response_ret(unlink_req, -EPROTO);
-}
+usbback_cancel_req(unlink_req);
break;
}
}
@@ -681,6 +683,33 @@ static void usbback_hotplug_enq(struct usbback_info
*usbif, unsigned port)
usbback_hotplug_notify(usbif);
}
+static void usbback_portid_drain(struct usbback_info *usbif, unsigned port)
+{
+struct usbback_req *req, *tmp;
+bool sched = false;
+
+QTAILQ_FOREACH_SAFE(req, &usbif->ports[port - 1].submit_q, q, tmp) {
+usbback_cancel_req(req);
+sched = true;
+}
+
+if (sched) {
+qemu_bh_schedule(usbif->bh);
+}
+}
+
+static void usbback_portid_detach(struct usbback_info *usbif, unsigned port)
+{
+if (!usbif->ports[port - 1].attached) {
+return;
+}
+
+usbif->ports[port - 1].speed = USBIF_SPEED_NONE;
+usbif->ports[port - 1].attached = false;
+usbback_portid_drain(usbif, port);
+usbback_hotplug_enq(usbif, port);
+}
+
static void usbback_portid_remove(struct usbback_info *usbif, unsigned port)
{
USBPort *p;
@@ -694,9 +723,7 @@ static void usbback_portid_remove(struct usbback_info
*usbif, unsigned port)
object_unparent(OBJECT(usbif->ports[port - 1].dev));
usbif->ports[port - 1].dev = NULL;
-usbif->ports[port - 1].speed = USBIF_SPEED_NONE;
-usbif->ports[port - 1].attached = false;
-usbback_hotplug_enq(usbif, port);
+usbback_portid_detac
[Xen-devel] [PATCH v2 1/2] xen: when removing a backend don't remove many of them
When a Xenstore watch fires indicating a backend has to be removed
don't remove all backends for that domain with the specified device
index, but just the one which has the correct type.
The easiest way to achieve this is to use the already determined
xendev as parameter for xen_be_del_xendev() instead of only the domid
and device index.
This at once removes the open coded QTAILQ_FOREACH_SAVE() in
xen_be_del_xendev() as there is no need to search for the correct
xendev any longer.
Signed-off-by: Juergen Gross
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_backend.c | 58 +---
1 file changed, 19 insertions(+), 39 deletions(-)
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index bab79b1..3ceb778 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -321,48 +321,28 @@ static struct XenDevice *xen_be_get_xendev(const char
*type, int dom, int dev,
/*
* release xen backend device.
*/
-static struct XenDevice *xen_be_del_xendev(int dom, int dev)
+static void xen_be_del_xendev(struct XenDevice *xendev)
{
-struct XenDevice *xendev, *xnext;
-
-/*
- * This is pretty much like QTAILQ_FOREACH(xendev, &xendevs, next) but
- * we save the next pointer in xnext because we might free xendev.
- */
-xnext = xendevs.tqh_first;
-while (xnext) {
-xendev = xnext;
-xnext = xendev->next.tqe_next;
-
-if (xendev->dom != dom) {
-continue;
-}
-if (xendev->dev != dev && dev != -1) {
-continue;
-}
-
-if (xendev->ops->free) {
-xendev->ops->free(xendev);
-}
-
-if (xendev->fe) {
-char token[XEN_BUFSIZE];
-snprintf(token, sizeof(token), "fe:%p", xendev);
-xs_unwatch(xenstore, xendev->fe, token);
-g_free(xendev->fe);
-}
+if (xendev->ops->free) {
+xendev->ops->free(xendev);
+}
-if (xendev->evtchndev != NULL) {
-xenevtchn_close(xendev->evtchndev);
-}
-if (xendev->gnttabdev != NULL) {
-xengnttab_close(xendev->gnttabdev);
-}
+if (xendev->fe) {
+char token[XEN_BUFSIZE];
+snprintf(token, sizeof(token), "fe:%p", xendev);
+xs_unwatch(xenstore, xendev->fe, token);
+g_free(xendev->fe);
+}
-QTAILQ_REMOVE(&xendevs, xendev, next);
-g_free(xendev);
+if (xendev->evtchndev != NULL) {
+xenevtchn_close(xendev->evtchndev);
}
-return NULL;
+if (xendev->gnttabdev != NULL) {
+xengnttab_close(xendev->gnttabdev);
+}
+
+QTAILQ_REMOVE(&xendevs, xendev, next);
+g_free(xendev);
}
/*
@@ -682,7 +662,7 @@ static void xenstore_update_be(char *watch, char *type, int
dom,
if (xendev != NULL) {
bepath = xs_read(xenstore, 0, xendev->be, &len);
if (bepath == NULL) {
-xen_be_del_xendev(dom, dev);
+xen_be_del_xendev(xendev);
} else {
free(bepath);
xen_be_backend_changed(xendev, path);
--
2.6.6
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/2] xen: bug fixes in Xen backend handling
When testing qemu based pvusb backend two bugs have been discovered: - detaching of a usb controller leads to memory clobbering in qemu - detaching of a usb device with active I/O requests could result in crash of qemu V2: remove checkpatch warnings for patch 2 as requested by Gerd Hoffmann Juergen Gross (2): xen: when removing a backend don't remove many of them xen: drain submit queue in xen-usb before removing device hw/usb/xen-usb.c | 94 ++-- hw/xen/xen_backend.c | 58 +++- 2 files changed, 81 insertions(+), 71 deletions(-) -- 2.6.6 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9] x86/mem-sharing: mem-sharing a range of memory
On Mon, Aug 01, 2016 at 11:14:27AM -0600, Tamas K Lengyel wrote: > Currently mem-sharing can be performed on a page-by-page basis from the > control > domain. However, this process is quite wasteful when a range of pages have to > be deduplicated. > > This patch introduces a new mem_sharing memop for range sharing where > the user doesn't have to separately nominate each page in both the source and > destination domain, and the looping over all pages happen in the hypervisor. > This significantly reduces the overhead of sharing a range of memory. > > Signed-off-by: Tamas K Lengyel > Acked-by: Wei Liu > Reviewed-by: Andrew Cooper I notice this patch has got sufficient acks. I will queue this up. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0806/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- drivers/net/xen-netfront.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 96ccd4e..70c86fa 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -58,7 +58,7 @@ /* Module parameters */ static unsigned int xennet_max_queues; -module_param_named(max_queues, xennet_max_queues, uint, 0644); +module_param_named(max_queues, xennet_max_queues, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(max_queues, "Maximum number of queues per virtual interface"); -- 2.9.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0805/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- drivers/net/xen-netback/netback.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c index edbae0b..e6e6598 100644 --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -53,22 +53,22 @@ * enabled by default. */ bool separate_tx_rx_irq = true; -module_param(separate_tx_rx_irq, bool, 0644); +module_param(separate_tx_rx_irq, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); /* The time that packets can stay on the guest Rx internal queue * before they are dropped. */ unsigned int rx_drain_timeout_msecs = 1; -module_param(rx_drain_timeout_msecs, uint, 0444); +module_param(rx_drain_timeout_msecs, uint, S_IRUSR | S_IRGRP | S_IROTH); /* The length of time before the frontend is considered unresponsive * because it isn't providing Rx slots. */ unsigned int rx_stall_timeout_msecs = 6; -module_param(rx_stall_timeout_msecs, uint, 0444); +module_param(rx_stall_timeout_msecs, uint, S_IRUSR | S_IRGRP | S_IROTH); unsigned int xenvif_max_queues; -module_param_named(max_queues, xenvif_max_queues, uint, 0644); +module_param_named(max_queues, xenvif_max_queues, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(max_queues, "Maximum number of queues per virtual interface"); @@ -78,7 +78,7 @@ MODULE_PARM_DESC(max_queues, */ #define FATAL_SKB_SLOTS_DEFAULT 20 static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT; -module_param(fatal_skb_slots, uint, 0444); +module_param(fatal_skb_slots, uint, S_IRUSR | S_IRGRP | S_IROTH); /* The amount to copy out of the first guest Tx slot into the skb's * linear area. If the first slot has more data, it will be mapped @@ -92,7 +92,7 @@ module_param(fatal_skb_slots, uint, 0444); /* This is the maximum number of flows in the hash cache. */ #define XENVIF_HASH_CACHE_SIZE_DEFAULT 64 unsigned int xenvif_hash_cache_size = XENVIF_HASH_CACHE_SIZE_DEFAULT; -module_param_named(hash_cache_size, xenvif_hash_cache_size, uint, 0644); +module_param_named(hash_cache_size, xenvif_hash_cache_size, uint, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(hash_cache_size, "Number of flows in the hash cache"); static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx, -- 2.9.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0828/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu
Signed-off-by: Baole Ni
---
drivers/pci/xen-pcifront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 5f70fee..4008d5f 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -77,7 +77,7 @@ static DEFINE_SPINLOCK(pcifront_dev_lock);
static struct pcifront_device *pcifront_dev;
static int verbose_request;
-module_param(verbose_request, int, 0644);
+module_param(verbose_request, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
static int errno_to_pcibios_err(int errno)
{
--
2.9.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default
>>> On 02.08.16 at 13:45, wrote: > (XEN) [ Xen-4.6.1 x86_64 debug=y Not tainted ] > (XEN) CPU:6 > (XEN) RIP:e008:[] vmx_vmenter_helper+0x27e/0x30a > (XEN) RFLAGS: 00010003 CONTEXT: hypervisor > (XEN) rax: 8005003b rbx: 8300e72fc000 rcx: > (XEN) rdx: 6c00 rsi: 830617fd7fc0 rdi: 8300e6fc > (XEN) rbp: 830617fd7c40 rsp: 830617fd7c30 r8: > (XEN) r9: 830be8dc9310 r10: r11: 3475e9cf85d0 > (XEN) r12: 0006 r13: 830c14ee1000 r14: 8300e6fc > (XEN) r15: 830617fd cr0: 8005003b cr4: 26e0 > (XEN) cr3: 0001bd665000 cr2: 0451 > (XEN) ds: es: fs: gs: ss: cs: e008 > (XEN) Xen stack trace from rsp=830617fd7c30: > (XEN)830617fd7c40 8300e72fc000 830617fd7ca0 82d080174f91 > (XEN)830617fd7f18 830be8dc9000 0286 830617fd7c90 > (XEN)0206 0246 0001 830617e91250 > (XEN)8300e72fc000 830be8dc9000 830617fd7cc0 82d080178c19 > (XEN)00bdeeae 8300e72fc000 830617fd7cd0 82d080178c3e > (XEN)830617fd7d20 82d080179740 8300e6fc2000 830c17e38e80 > (XEN)830617e91250 82008000 0002 830617e91250 > (XEN)830617e91240 830be8dc9000 830617fd7d70 82d080196152 > (XEN)830617fd7d50 82d0801f7c6b 8300e6fc2000 830617e91250 > (XEN)8300e6fc2000 830617e91250 830617e91240 830be8dc9000 > (XEN)830617fd7d80 82d080244a62 830617fd7db0 82d0801d3fe2 > (XEN)8300e6fc2000 830617e91f28 830617e91000 > (XEN)830617fd7dd0 82d080175c2c 8300e6fc2000 8300e6fc2000 > (XEN)830617fd7e00 82d080105dd4 830c17e38040 > (XEN) 830617fd 830617fd7e30 82d0801215fd > (XEN)8300e6fc 82d080329280 82d080328f80 fffd > (XEN)830617fd7e60 82d08012caf8 0006 830c17e3bc60 > (XEN)0002 830c17e3bbe0 830617fd7e70 82d08012cb3b > (XEN)830617fd7ef0 82d0801c23a8 8300e72fc000 > (XEN)82d0801f3200 830617fd7f08 82d080329280 > (XEN) Xen call trace: > (XEN)[] vmx_vmenter_helper+0x27e/0x30a > (XEN)[] __context_switch+0xdb/0x3b5 > (XEN)[] __sync_local_execstate+0x5e/0x7a > (XEN)[] sync_local_execstate+0x9/0xb > (XEN)[] map_domain_page+0xa0/0x5d4 > (XEN)[] destroy_perdomain_mapping+0x8f/0x1e8 > (XEN)[] free_compat_arg_xlat+0x26/0x28 > (XEN)[] hvm_vcpu_destroy+0x73/0xb0 > (XEN)[] vcpu_destroy+0x5d/0x72 > (XEN)[] complete_domain_destroy+0x49/0x192 > (XEN)[] rcu_process_callbacks+0x19a/0x1fb > (XEN)[] __do_softirq+0x82/0x8d > (XEN)[] process_pending_softirqs+0x38/0x3a > (XEN)[] mwait_idle+0x10c/0x315 > (XEN)[] idle_loop+0x51/0x6b On this deep a stack execution can't validly end up in vmx_vmenter_helper: That's a function called only when the stack is almost empty. Nor is the caller of it the context switch code. Hence your problem starts quite a bit earlier - perhaps memory corruption? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
On Tue, Aug 02, 2016 at 12:42:36PM +0100, George Dunlap wrote: > On 02/08/16 12:37, Wei Liu wrote: > > On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote: > >> Introducing HVMCTL, Jan wrote: > >>> A long while back separating out all control kind operations (intended > >>> for use by only the control domain or device model) from the currect > >>> hvmop hypercall has been discussed. This series aims at finally making > >>> this reality (at once allowing to streamline the associated XSM checking). > >> > >> I think we need to introduce a new hypercall (which I will call DMOP > >> for now) which may augment or replace some of HVMCTL. Let me explain: > >> > >> > >> We would like to be able to deprivilege qemu-in-dom0. This is > >> because qemu has a large attack surface and has a history of security > >> bugs. If we get this right we can easily reduce the impact of `guest > >> can take over qemu' bugs to DoS; and perhaps with a bit of effort we > >> can eliminate the DoS too. (qemu stubdom are another way to do this > >> but they have their own difficulties.) > >> > >> A part of this plan has to be a way for qemu to make hypercalls > >> related to the guest it is servicing. But qemu needs to be _unable_ > >> to make _other_ hypercalls. > >> > >> I see four possible approaches. In IMO increasing order of > >> desirability: > >> > >> 1. We could simply patch the dom0 privcmd driver to know exactly which > >>hypercalls are permitted. This is obviously never going to work > >>because there would have to be a massive table in the kernel, kept > >>in step with Xen. We could have a kind of pattern matching engine > >>instead, and load the tables from userspace, but that's a daft > >>edifice to be building (even if we reuse BPF or something) and a > >>total pain to maintain. > >> > >> 2. We could have some kind of privileged proxy or helper process, > >>which makes the hypercalls on instruction from qemu. This would be > >>quite complicated and involve a lot of back-and-forth parameter > >>passing. Like option 1, this arrangement would end up embedding > >>detailed knowledge about which hypercalls are appropriate, and have > >>to understand all of their parameters. > >> > >> 3. We could have the dom0 privcmd driver wrap each of qemu's > >>hypercalls in a special "wrap up with different XSM tag" hypercall. > >>Then, we could specify the set of allowable hypercalls with XSM. > >>If we want qemu deprivileged by default, this depends on turning > >>XSM on by default. But we want qemu depriv ASAP and there are > >>difficulties with XSM by default. This approach also involves > >>writing a large and hard-to-verify hypercall permission table, in > >>the form of an XSM policy. > >> > >> 4. We could invent a new hypercall `DMOP' for hypercalls which device > >>models should be able to use, which always has the target domain in > >>a fixed location in the arguments. We have the dom0 privcmd driver > >>know about this one hypercall number and the location of the target > >>domid. > >> > >> Option 4 has the following advantages: > >> > >> * The specification of which hypercalls are authorised to qemu is > >> integrated with the specification of the hypercalls themselves: > >> There is no need to maintain a separate table which can get out of > >> step (or contain security bugs). > >> > >> * The changes required to the rest of the system are fairly small. > >> In particular: > >> > >> * We need only one small, non-varying, patch to the dom0 kernel. > >> > > > > I think your analysis makes sense. > > > >> > >> Let me flesh out option 4 in more detail: > >> > >> > >> We define a new hypercall DMOP. > >> > >> Its first argument is always a target domid. The DMOP hypercall > >> number and position of the target domid in the arguments are fixed. > >> > >> A DMOP is defined to never put at risk the stability or security of > >> the whole system, nor of the domain which calls DMOP. However, a DMOP > >> may have arbitrary effects on the target domid. > >> > > > > I would like to point out that this is non-trivial since we would need > > to audit a lot of stuff. > > > > But the requirement to audit interface is not unique to DMOP -- I expect > > this is needed for any other approach. > > > >> In the privcmd driver, we provide a new restriction ioctl, which takes > >> a domid parameter. After that restriction ioctl is called, the > >> privcmd driver will permit only DMOP hypercalls, and only with the > >> specified target domid. > >> > > > > It is phrased like that the guest kernel is supposed to enforce the > > policy? Would it be possible to make Xen do it? I don't think we should > > trust DM domain kernel here. > > The problem is that Xen doesn't know what process is running, and so > can't tell whether qemuA is accessing domainA's memory, or whether qemuB > is accessing domainA's memory. > > The two options
Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian
On Tue, Aug 02, 2016 at 12:30:30PM +0200, Ingo Jürgensmann wrote: > On 02.08.2016 11:20, Wei Liu wrote: > >On Fri, Jul 29, 2016 at 10:17:22PM +0200, Ingo Jürgensmann wrote: > >What is also interesting is that you seem to be running some sort of > >ip accounting software (pmacctd) which also segfault'ed. > > Yeah, it is segfaulting, because the database (in a domU VM) where it is > storing the accounting is not yet available after the crash. When database > is up&running, those segfaults go away. > At least we can now rule out that it is not related to the issue you reported. > >Still not sure what to make of that though. > > Me neither. ;-) > > I already tried to get a core dump by setting ulimit -c unlimited, but that > didn't work as well, which makes me believe that the crash happens in > hypervisor not in dom0 kernel. When it's dom0 kernel I would expect dumping > a core file should work. > We can't draw the conclusion that the crash is in hypervisor yet. If your dom0 crash, hypervisor would normally decide to reboot the machine. Wei. > -- > Ciao... //http://blog.windfluechter.net > Ingo \X/ XMPP: i...@jabber.windfluechter.net > > > gpg pubkey: http://www.juergensmann.de/ij_public_key.asc ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0805/1285] Replace numeric parameter like 0444 with macro
On Tue, Aug 02, 2016 at 07:48:12PM +0800, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro, > and that using macro can improve the robustness and readability of the code, > thus, I suggest replacing the numeric parameter with the macro. > > Signed-off-by: Chuansheng Liu > Signed-off-by: Baole Ni Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request
>>> On 01.08.16 at 18:52, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
> int rc, fall_through = 0, paged = 0;
> int sharing_enomem = 0;
> vm_event_request_t *req_ptr = NULL;
> -bool_t ap2m_active;
> +bool_t ap2m_active, sync = 0;
>
> /* On Nested Virtualization, walk the guest page table.
> * If this succeeds, all is fine.
> @@ -1846,11 +1846,12 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
> }
> }
>
> -if ( p2m_mem_access_check(gpa, gla, npfec, &req_ptr) )
> -{
> +sync = p2m_mem_access_check(gpa, gla, npfec, &req_ptr);
> +
> +if ( !sync ) {
Coding style. If you dropped the brace entirely, you could at once
adjust ...
> fall_through = 1;
> } else {
... coding style here.
> -/* Rights not promoted, vcpu paused, work here is done */
> +/* Rights not promoted (aka. sync event), work here is done
> */
Comment style. More of these elsewhere.
> +int hvm_monitor_mem_access(struct vcpu* v, bool_t sync,
Coding style.
> + vm_event_request_t *req)
> +{
> +return monitor_traps(v, sync, req);
> +}
Overall - is this a useful wrapper? Why can't the caller(s) call
monitor_traps() directly? And if you really want to keep it, it would
probably better be an inline one.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1028/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- drivers/xen/gntalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c index 4547a91..1451b98 100644 --- a/drivers/xen/gntalloc.c +++ b/drivers/xen/gntalloc.c @@ -71,7 +71,7 @@ #include static int limit = 1024; -module_param(limit, int, 0644); +module_param(limit, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(limit, "Maximum number of grants that may be allocated by " "the gntalloc device"); -- 2.9.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1030/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- drivers/xen/xen-acpi-processor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c index 076970a..3d2d055 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -36,7 +36,7 @@ static int no_hypercall; MODULE_PARM_DESC(off, "Inhibit the hypercall."); -module_param_named(off, no_hypercall, int, 0400); +module_param_named(off, no_hypercall, int, S_IRUSR); /* * Note: Do not convert the acpi_id* below to cpumask_var_t or use cpumask_bit -- 2.9.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1029/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu
Signed-off-by: Baole Ni
---
drivers/xen/gntdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 6793957..8cb7759 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -51,7 +51,7 @@ MODULE_AUTHOR("Derek G. Murray , "
MODULE_DESCRIPTION("User-space granted page access driver");
static int limit = 1024*1024;
-module_param(limit, int, 0644);
+module_param(limit, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(limit, "Maximum number of grants that may be mapped by "
"the gntdev device");
--
2.9.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1032/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- drivers/xen/xen-pciback/conf_space.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/conf_space.c b/drivers/xen/xen-pciback/conf_space.c index 8e67336..e1fb906 100644 --- a/drivers/xen/xen-pciback/conf_space.c +++ b/drivers/xen/xen-pciback/conf_space.c @@ -17,7 +17,7 @@ #include "conf_space_quirks.h" bool xen_pcibk_permissive; -module_param_named(permissive, xen_pcibk_permissive, bool, 0644); +module_param_named(permissive, xen_pcibk_permissive, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); /* This is where xen_pcibk_read_config_byte, xen_pcibk_read_config_word, * xen_pcibk_write_config_word, and xen_pcibk_write_config_byte are created. */ -- 2.9.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1034/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- drivers/xen/xen-pciback/pciback_ops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c index 2f19dd7..27e19c2 100644 --- a/drivers/xen/xen-pciback/pciback_ops.c +++ b/drivers/xen/xen-pciback/pciback_ops.c @@ -14,7 +14,7 @@ #include "pciback.h" int verbose_request; -module_param(verbose_request, int, 0644); +module_param(verbose_request, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); static irqreturn_t xen_pcibk_guest_interrupt(int irq, void *dev_id); -- 2.9.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1033/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu
Signed-off-by: Baole Ni
---
drivers/xen/xen-pciback/pci_stub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-pciback/pci_stub.c
b/drivers/xen/xen-pciback/pci_stub.c
index 258b7c3..cf67c9c 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -31,7 +31,7 @@ wait_queue_head_t xen_pcibk_aer_wait_queue;
* We want to avoid in middle of AER ops, xen_pcibk devices is being removed
*/
static DECLARE_RWSEM(pcistub_sem);
-module_param_named(hide, pci_devs_to_hide, charp, 0444);
+module_param_named(hide, pci_devs_to_hide, charp, S_IRUSR | S_IRGRP | S_IROTH);
struct pcistub_device_id {
struct list_head slot_list;
--
2.9.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1031/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu Signed-off-by: Baole Ni --- drivers/xen/xen-balloon.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c index 79865b8..0a8cad2 100644 --- a/drivers/xen/xen-balloon.c +++ b/drivers/xen/xen-balloon.c @@ -124,10 +124,10 @@ BALLOON_SHOW(current_kb, "%lu\n", PAGES2KB(balloon_stats.current_pages)); BALLOON_SHOW(low_kb, "%lu\n", PAGES2KB(balloon_stats.balloon_low)); BALLOON_SHOW(high_kb, "%lu\n", PAGES2KB(balloon_stats.balloon_high)); -static DEVICE_ULONG_ATTR(schedule_delay, 0444, balloon_stats.schedule_delay); -static DEVICE_ULONG_ATTR(max_schedule_delay, 0644, balloon_stats.max_schedule_delay); -static DEVICE_ULONG_ATTR(retry_count, 0444, balloon_stats.retry_count); -static DEVICE_ULONG_ATTR(max_retry_count, 0644, balloon_stats.max_retry_count); +static DEVICE_ULONG_ATTR(schedule_delay, S_IRUSR | S_IRGRP | S_IROTH, balloon_stats.schedule_delay); +static DEVICE_ULONG_ATTR(max_schedule_delay, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, balloon_stats.max_schedule_delay); +static DEVICE_ULONG_ATTR(retry_count, S_IRUSR | S_IRGRP | S_IROTH, balloon_stats.retry_count); +static DEVICE_ULONG_ATTR(max_retry_count, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, balloon_stats.max_retry_count); static ssize_t show_target_kb(struct device *dev, struct device_attribute *attr, char *buf) -- 2.9.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1035/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the
corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu
Signed-off-by: Baole Ni
---
drivers/xen/xen-scsiback.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index d6950e0..a9fd45a 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -185,10 +185,10 @@ struct scsiback_tpg {
#define SCSIBACK_INVALID_HANDLE (~0)
static bool log_print_stat;
-module_param(log_print_stat, bool, 0644);
+module_param(log_print_stat, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
static int scsiback_max_buffer_pages = 1024;
-module_param_named(max_buffer_pages, scsiback_max_buffer_pages, int, 0644);
+module_param_named(max_buffer_pages, scsiback_max_buffer_pages, int, S_IRUSR |
S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(max_buffer_pages,
"Maximum number of free pages to keep in backend buffer");
--
2.9.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/9] x86/pv: Support do_set_segment_base() for compat guests
>>> On 18.07.16 at 11:51, wrote: > set_segment_base is the only hypercall exists in only one of the two modes > guests might run in; all other hypercalls are either implemented, or > unimplemented in both modes. > > Remove this split, by allowing do_set_segment_base() to be called in the > compat hypercall path. This change will simplify the verification logic in a > later change. > > No behavioural change from a guests point of view. Nevertheless I don't view this as a reasonable change on its own: > --- a/xen/arch/x86/x86_64/compat/entry.S > +++ b/xen/arch/x86/x86_64/compat/entry.S > @@ -453,7 +453,7 @@ ENTRY(compat_hypercall_table) > .quad compat_update_va_mapping_otherdomain > .quad compat_iret > .quad compat_vcpu_op > -.quad compat_ni_hypercall /* 25 */ > +.quad do_set_segment_base /* 25 */ This part will (I suppose) be deleted by a later change. > --- a/xen/arch/x86/x86_64/mm.c > +++ b/xen/arch/x86/x86_64/mm.c > @@ -1031,6 +1031,9 @@ long do_set_segment_base(unsigned int which, unsigned > long base) > struct vcpu *v = current; > long ret = 0; > > +if ( is_pv_32bit_vcpu(v) ) > +return -ENOSYS; /* x86/64 only. */ And this addition could as well happen when that later change does the re-org. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h
>>> On 18.07.16 at 11:51, wrote: > --- a/xen/include/asm-x86/hypercall.h > +++ b/xen/include/asm-x86/hypercall.h > @@ -5,9 +5,21 @@ > #ifndef __ASM_X86_HYPERCALL_H__ > #define __ASM_X86_HYPERCALL_H__ > > +#include > #include > +#include Why? > #include /* for do_mca */ > -#include > + > +typedef unsigned long hypercall_fn_t( > +unsigned long, unsigned long, unsigned long, > +unsigned long, unsigned long, unsigned long); Wouldn't this better go into xen/hypercall.h? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/9] x86/hypercall: Move the hypercall arg tables into C
>>> On 18.07.16 at 11:51, wrote: > Editing (and indeed, finding) the hypercall args tables can be tricky, > especially towards the end where .rept's are used to maintain the correct > layout. > > Move this all into C, and let the compiler do the hard work. As 0 is the > default value, drop all explicit 0's. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)
On 02/08/16 12:58, Jan Beulich wrote: On 02.08.16 at 13:38, wrote: >> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote: >> On 01.08.16 at 13:32, wrote: 4. We could invent a new hypercall `DMOP' for hypercalls which device models should be able to use, which always has the target domain in a fixed location in the arguments. We have the dom0 privcmd driver know about this one hypercall number and the location of the target domid. Option 4 has the following advantages: * The specification of which hypercalls are authorised to qemu is integrated with the specification of the hypercalls themselves: There is no need to maintain a separate table which can get out of step (or contain security bugs). * The changes required to the rest of the system are fairly small. In particular: * We need only one small, non-varying, patch to the dom0 kernel. Let me flesh out option 4 in more detail: We define a new hypercall DMOP. Its first argument is always a target domid. The DMOP hypercall number and position of the target domid in the arguments are fixed. A DMOP is defined to never put at risk the stability or security of the whole system, nor of the domain which calls DMOP. However, a DMOP may have arbitrary effects on the target domid. >>> >>> With the exception of this and the privcmd layer described below, >>> DMOP == HVMCTL afaics. The privcmd layer is independent anyway. >>> And the security aspect mentioned above won't disappear if we >>> use DMOP instead of HVMCTL. So I don't see why the hvmctl >>> series as is can't be the starting point of this, with the stability/ >>> security concerns addressed subsequently, for being orthogonal. >>> >> >> Yeah, to turn HVMCTL to DMOP: >> >> 1. s/HVMCTL/DMOP/ >> 2. maybe s/interface_version// > > Andrew had brought up 2 too, but I'm really not sure that'd be a > good idea. I rather think we should keep it but maybe (other than > domctl/sysctl) recognize older versions. In any event I consider > having it better for an unstable interface (as Ian said, libxc is > supposed to provide the stable one). A stable user space library API is no good for an in-kernel emulator, like that needed for Intel GVT-g -- the hypercall ABI needs to be stable. David ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] What distros have Xen 4.7 packages that work on UEFI hardware?
On Tue, Aug 2, 2016, at 12:06 AM, Jan Beulich wrote: > I don't understand this distro related complaint. Possibly because it's not a complaint. It's a question. > Afaict the bug is in upstream Linux, and hence any distro will have the issue. > expectation that freshly released Linux (or Xen) versions are > completely bug free is simply wrong, as is your expectation that a > solution will always be found within a couple of days, the more > when quite a bit of back and forth is needed to even get all > relevant data. As was validly said recently in the context of a > different thread: The level of support you get is somewhat > proportional to the amount of money you spend. I don't have expectations here. I have a question. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0096/1285] Replace numeric parameter like 0444 with macro
On Tue, Aug 02, 2016 at 06:40:21PM +0800, Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro, > and that using macro can improve the robustness and readability of the code, > thus, I suggest replacing the numeric parameter with the macro. > > Signed-off-by: Chuansheng Liu > Signed-off-by: Baole Ni Acked-by: Roger Pau Monné ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/9] x86/pv: Implement pv_hypercall() in C
>>> On 18.07.16 at 11:51, wrote:
> +long pv_hypercall(struct cpu_user_regs *regs)
> +{
> +struct vcpu *curr = current;
> +#ifndef NDEBUG
> +unsigned long old_rip = regs->rip;
> +#endif
> +long ret;
> +uint32_t eax = regs->eax;
> +
> +ASSERT(curr->arch.flags & TF_kernel_mode);
I'm afraid TF_kernel_mode can't be relied on for 32-bit guests, so
this needs to move into the if() below.
> +if ( (eax >= NR_hypercalls) || !hypercall_table[eax] )
> + return -ENOSYS;
> +
> +if ( !is_pv_32bit_vcpu(curr) )
> +{
> +unsigned long rdi = regs->rdi;
> +unsigned long rsi = regs->rsi;
> +unsigned long rdx = regs->rdx;
> +unsigned long r10 = regs->r10;
> +unsigned long r8 = regs->r8;
> +unsigned long r9 = regs->r9;
> +
> +#ifndef NDEBUG
> +/* Deliberately corrupt parameter regs not used by this hypercall. */
> +switch ( hypercall_args_table[eax] )
> +{
> +case 0: rdi = 0xdeadbeefdeadf00dUL;
> +case 1: rsi = 0xdeadbeefdeadf00dUL;
> +case 2: rdx = 0xdeadbeefdeadf00dUL;
> +case 3: r10 = 0xdeadbeefdeadf00dUL;
> +case 4: r8 = 0xdeadbeefdeadf00dUL;
> +case 5: r9 = 0xdeadbeefdeadf00dUL;
Without comments, aren't these going to become 5 new Coverity
issues?
> +}
> +#endif
> +if ( unlikely(tb_init_done) )
> +{
> +unsigned long args[6] = { rdi, rsi, rdx, r10, r8, r9 };
> +
> +__trace_hypercall(TRC_PV_HYPERCALL_V2, eax, args);
> +}
> +
> +ret = hypercall_table[eax](rdi, rsi, rdx, r10, r8, r9);
> +
> +#ifndef NDEBUG
> +if ( regs->rip == old_rip )
> +{
> +/* Deliberately corrupt parameter regs used by this hypercall. */
> +switch ( hypercall_args_table[eax] )
> +{
> +case 6: regs->r9 = 0xdeadbeefdeadf00dUL;
> +case 5: regs->r8 = 0xdeadbeefdeadf00dUL;
> +case 4: regs->r10 = 0xdeadbeefdeadf00dUL;
> +case 3: regs->edx = 0xdeadbeefdeadf00dUL;
> +case 2: regs->esi = 0xdeadbeefdeadf00dUL;
> +case 1: regs->edi = 0xdeadbeefdeadf00dUL;
For consistency with earlier code, lease use rdx, rsi, and rdi here.
> +#ifndef NDEBUG
> +if ( regs->rip == old_rip )
> +{
> +/* Deliberately corrupt parameter regs used by this hypercall. */
> +switch ( compat_hypercall_args_table[eax] )
> +{
> +case 6: regs->ebp = 0xdeadf00d;
> +case 5: regs->edi = 0xdeadf00d;
> +case 4: regs->esi = 0xdeadf00d;
> +case 3: regs->edx = 0xdeadf00d;
> +case 2: regs->ecx = 0xdeadf00d;
> +case 1: regs->ebx = 0xdeadf00d;
Please use 32-bit stores here.
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -25,70 +25,10 @@ UNLIKELY_START(ne, msi_check)
> LOAD_C_CLOBBERED compat=1 ax=0
> UNLIKELY_END(msi_check)
>
> -movl UREGS_rax(%rsp),%eax
> GET_CURRENT(bx)
>
> -cmpl $NR_hypercalls,%eax
> -jae compat_bad_hypercall
> -#ifndef NDEBUG
> -/* Deliberately corrupt parameter regs not used by this hypercall. */
> -pushq UREGS_rbx(%rsp); pushq %rcx; pushq %rdx; pushq %rsi; pushq %rdi
> -pushq UREGS_rbp+5*8(%rsp)
> -leaq compat_hypercall_args_table(%rip),%r10
> -movl $6,%ecx
> -subb (%r10,%rax,1),%cl
> -movq %rsp,%rdi
> -movl $0xDEADBEEF,%eax
> -rep stosq
> -popq %r8 ; popq %r9 ; xchgl %r8d,%r9d /* Args 5&6: zero extend */
> -popq %rdx; popq %rcx; xchgl %edx,%ecx /* Args 3&4: zero extend */
> -popq %rdi; popq %rsi; xchgl %edi,%esi /* Args 1&2: zero extend */
> -movl UREGS_rax(%rsp),%eax
> -pushq %rax
> -pushq UREGS_rip+8(%rsp)
> -#define SHADOW_BYTES 16 /* Shadow EIP + shadow hypercall # */
> -#else
> -/* Relocate argument registers and zero-extend to 64 bits. */
> -xchgl %ecx,%esi /* Arg 2, Arg 4 */
> -movl %edx,%edx /* Arg 3*/
> -movl %edi,%r8d /* Arg 5*/
> -movl %ebp,%r9d /* Arg 6*/
> -movl UREGS_rbx(%rsp),%edi /* Arg 1*/
> -#define SHADOW_BYTES 0 /* No on-stack shadow state */
> -#endif
> -cmpb $0,tb_init_done(%rip)
> -UNLIKELY_START(ne, compat_trace)
> -call __trace_hypercall_entry
> -/* Restore the registers that __trace_hypercall_entry clobbered. */
> -movl UREGS_rax+SHADOW_BYTES(%rsp),%eax /* Hypercall # */
> -movl UREGS_rbx+SHADOW_BYTES(%rsp),%edi /* Arg 1*/
> -movl UREGS_rcx+SHADOW_BYTES(%rsp),%esi /* Arg 2*/
> -movl UREGS_rdx+SHADOW_BYTES(%rsp),%edx /* Arg 3*/
> -movl UREGS_rsi+SHADOW_BYTES(%rsp),%ecx /* Arg 4*/
> -movl UREGS_rdi+SHADOW_BYT
Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?
On Mon, Aug 1, 2016, at 11:36 PM, Jan Beulich wrote: > yet without a full log thereof I can't judge I've asked what that 'full log' should be >>> Hmmm Could you provide full console dump from Xen and Linux kernel? > >Will serial console output with these options > > kernel: earlyprintk=xen,keep debug loglevel=8 > hypervisor: loglvl=all guest_loglvl=all sync_console console_to_ring got an ack, then provided the serial console output with that set of log options. Like I said I'm happy to try to provide what's needed. If THAT is not the full log output that's needed, then what specifically is? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/mm: Annotate gfn_get_* helpers as requiring non-NULL parameters
On Mon, Aug 1, 2016 at 5:59 PM, Andrew Cooper wrote: > Introduce and use the nonnull attribute to help the compiler catch NULL > parameters being passed to function which require their parameters not to be > NULL. Experimentally, GCC 4.9 on Debian Jessie only warns of non-NULL-ness > from immediate callers, so propagate the attributes out to all helpers. > > A sample error looks like: > > mem_sharing.c: In function ‘mem_sharing_nominate_page’: > mem_sharing.c:884:13: error: null argument where non-null required (argument > 3) [-Werror=nonnull] > amfn = get_gfn_type_access(ap2m, gfn, NULL, &ap2ma, 0, NULL); > ^ > > As part of this, replace the get_gfn_type_access() macro with an equivalent > static inline function for extra type safety, and the ability to be annotated. > > Signed-off-by: Andrew Cooper Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h
On 02/08/16 13:50, Jan Beulich wrote: On 18.07.16 at 11:51, wrote: >> --- a/xen/include/asm-x86/hypercall.h >> +++ b/xen/include/asm-x86/hypercall.h >> @@ -5,9 +5,21 @@ >> #ifndef __ASM_X86_HYPERCALL_H__ >> #define __ASM_X86_HYPERCALL_H__ >> >> +#include >> #include >> +#include > Why? You snipped the commit message, which justifies why. This header file cannot currently be included in isolation, and I need it to be. > >> #include /* for do_mca */ >> -#include >> + >> +typedef unsigned long hypercall_fn_t( >> +unsigned long, unsigned long, unsigned long, >> +unsigned long, unsigned long, unsigned long); > Wouldn't this better go into xen/hypercall.h? It is architecture specific. ARM's version is typedef register_t (*arm_hypercall_fn_t)( register_t, register_t, register_t, register_t, register_t); ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
