Re: [Xen-devel] [PATCH v2 1/2] x86/vmx: Print the problematic MSR if a vmentry fails
>>> On 13.10.16 at 15:46, wrote: > Sample error looks like: > > (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading (entry > 13). > (XEN) msr 068a, val 1fff80102af0, (mbz 0) A _really_ minor remark: This is no longer in line with what gets actually logged. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
>>> On 14.10.16 at 02:58, wrote: > On Fri, 14 Oct 2016, Andrew Cooper wrote: >> There should be a high barrier to "Supported" status, because the cost >> of getting it wrong is equally high. However, there are perfectly >> legitimate intermediate stages such as "Supported in these limited set >> of circumstances". A number of features are not plausibly for use in >> production environments, but otherwise function fine for >> development/investigatory purposes. In these cases, something like "no >> security support, but believed to be working fine" might be appropriate. > > I agree on this. I think we need an intermediate step: "working but not > supported for security" is completely reasonable. When we say that it is > "working", it should be because we have automated testing for it (I > don't know if I would go as far as requiring it to be in OSSTest, any > automated testing, even third party, would do). If it is not > automatically tested, then it is just "best effort". I don't think this is a reasonable expectation - how would you envision testing the dozens of command line options alone, not to speak of things depending on hardware characteristics? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 for-4.8] libelf: fix symtab/strtab loading for 32bit domains
>>> On 13.10.16 at 15:25, wrote: > On 13/10/16 13:48, Roger Pau Monne wrote: >> diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h >> index 90bd8cb..70abbaf 100644 >> --- a/xen/include/xen/libelf.h >> +++ b/xen/include/xen/libelf.h >> @@ -432,6 +432,16 @@ struct elf_dom_parms { >> uint64_t virt_kend; >> }; >> >> +/* Number of section header needed in order to fit the SYMTAB and STRTAB. > */ >> +#define ELF_BSDSYM_SECTIONS 3 >> +struct elf_sym_header { >> +uint32_t size; >> +struct { >> +elf_ehdr header; >> +elf_shdr section[ELF_BSDSYM_SECTIONS]; >> +} elf_header; >> +} __attribute__((packed)); > > __packed please, rather than opencoding it. Also, should be between > struct and the structure name. There's no __packed in libxc afaics, and the code here is shared. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: honor MXCSR.MM
>>> On 13.10.16 at 15:26, wrote: > On 13/10/16 13:57, Jan Beulich wrote: >> Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory >> operands") didn't consider a specific AMD mode: Mis-alignment #GP >> faults can be masked on some of their hardware. >> >> Signed-off-by: Jan Beulich > > This highlights that the following CPUID dependency change is also required > > diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py > index 33e68eb..e803654 100755 > --- a/xen/tools/gen-cpuid.py > +++ b/xen/tools/gen-cpuid.py > @@ -185,8 +185,9 @@ def crunch_numbers(state): > # the first place. > APIC: [X2APIC], > > -# AMD built MMXExtentions and 3DNow as extentions to MMX. > -MMX: [MMXEXT, _3DNOW], > +# AMD built MMXExtentions, 3DNow and SSE Misalignment as > extensions to > +# MMX. > +MMX: [MMXEXT, _3DNOW, MISALIGNSSE], > > # The FXSAVE/FXRSTOR instructions were introduced into hardware > before > # SSE, which is why they behave differently based on > %CR4.OSFXSAVE and Hmm, for one this is an orthogonal change, so doesn't belong in this patch. And then - why is this an extension to MMX (which doesn't have any alignment requirements anyway) rather than SSE? >> @@ -4675,7 +4679,13 @@ x86_emulate( >> ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4; >> if ( ea.type == OP_MEM ) >> { >> -generate_exception_if((b >= 0x28) && >> +uint32_t mxcsr = 0; >> + >> +if ( b < 0x28 ) >> +mxcsr = MXCSR_MM; >> +else if ( vcpu_has_misalignsse() ) >> +asm ( "stmxcsr %0" : "=m" (mxcsr) ); >> +generate_exception_if(!(mxcsr & MXCSR_MM) && >>!is_aligned(ea.mem.seg, ea.mem.off, >> ea.bytes, >>ctxt, ops), >>EXC_GP, 0); >> @@ -4955,7 +4965,13 @@ x86_emulate( >> } >> if ( ea.type == OP_MEM ) >> { >> -generate_exception_if((vex.pfx == vex_66) && >> +uint32_t mxcsr = 0; >> + >> +if ( vex.pfx != vex_66 ) >> +mxcsr = MXCSR_MM; >> +else if ( vcpu_has_misalignsse() ) >> +asm ( "stmxcsr %0" : "=m" (mxcsr) ); >> +generate_exception_if(!(mxcsr & MXCSR_MM) && >>!is_aligned(ea.mem.seg, ea.mem.off, >> ea.bytes, >>ctxt, ops), >>EXC_GP, 0); > > According to the docs, we should also be possibly raising #AC here. Well, you've said the same in a different context not so long ago, and my answer is then also the same: As long as we don't do any #AC generation, I see no reason why we would want to create an exception here. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 101424: regressions - FAIL
flight 101424 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/101424/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101000 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-freebsd10-i386 6 xen-boot fail REGR. vs. 101000 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 101413 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 101424 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 101413 pass in 101424 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 101413 pass in 101424 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 101413 pass in 101424 test-amd64-i386-freebsd10-amd64 6 xen-bootfail pass in 101389 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail pass in 101398 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail pass in 101398 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-bootfail pass in 101398 test-amd64-i386-libvirt 6 xen-boot fail pass in 101413 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail pass in 101413 test-armhf-armhf-xl-rtds 11 guest-startfail pass in 101413 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 12 migrate-support-check fail in 101413 never pass test-armhf-armhf-xl-rtds12 migrate-support-check fail in 101413 never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 101413 never pass build-i386-rumprun5 rumprun-buildfail never pass build-amd64-rumprun 5 rumprun-buildfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-ar
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On Fri, 14 Oct 2016, Andrew Cooper wrote: > > I like the idea of keeping these info on pandoc on a git repo, like Lars > > did with the governance. > > I should hasten to add that perhaps picking on the security team in > isolation was a poor move on my part, for which I apologise. There are > multiple involved parties with different interests, all of which need > attending to. No worries, on my part I just think that we should write down these things to remember, set expectations and to avoid surprises. > The feature submitter (should) have a vested interest in getting code > submitted (even as experimental/tech preview to start with), so that > others can trial/debug/extend the feature. Even having code upstream > but disabled-by-default in Kconfig is a far better position for others > to start from, than to be provided with instructions saying "there was a > patch series several months ago on a mailing list". Undeniably true. > The reviewers/maintainers (should) have a vested interest in keeping the > overall quality up. Due to their appointment within the community, they > have demonstrated knowledge and expertise in their respective areas, and > the overall project relies on them to ask questions such as "How does $X > work with $Y?" or "Have you considered $Z as an alternative?", and to > come to a fair and unbiased opinion to the quality and worthiness of a > feature. > > The release manager has conflicted vested interests. On the one hand, > getting more features in a release is better on paper and in the press, > but can certainly backfire when features aren't up to scratch. > Ultimately, if features in a release are substandard, the downstreams > and end users will be the ones to bear the pain. It is in the release > managers best interest to ensure that the features which are finally > accepted are actually ready. > > Nothing is ever perfect, but a whole lot of stuff is perfectly good in > common case, and useful for people in general. This is why the feature > doc template specifically has sections for know issues to be fixed, and > areas for future improvement. Any documentation (so long as it isn't > factually incorrect) is better than nothing. > > There seems to be general consensus that a status of "Supported" means > "with security support", and I agree with this assessment. Ultimately, > the security team is accountable to whatever the project as a whole > declares "Supported", but as the security team are all commiters and > maintainer there is a large overlap of responsibility. OTOH, the > security team are also responsible for managing the fallout when things > go wrong. > > XSAs are bad publicity, and are a problem for downstreams (remember that > we have plenty of downstreams who measure quantity of servers in units > of a datacenter). Another problem we as a community have is that no > support status is written down; there is a 13ish? year backlog in this > regard. Writing details down in feature docs is intended to get > everyone on the same, un-ambiguous, page. > > We also have an unfortunate habit of new features appearing, being > accepted, and (intentionally or unintentionally) available to guests. > Fastforward a bit, and it is discovered that said feature resembles a > sieve in terms of security holes, and the common recourse is to publish > an XSA stating "turn it off and don't use it with untrusted guests", or > "here is a patch to actually turn it off, and still don't use it with > untrusted guests", because we really can't re-engineer a feature in a > security patch. (Sorry to pick on TMEM here, but it is now 4 years of > development later and it still has a lot of development left to go. > Reworking features in the light of a security hole can be very > complicated, and lots of work.) Yes, that's definitely a position we should try not to be in. > There should be a high barrier to "Supported" status, because the cost > of getting it wrong is equally high. However, there are perfectly > legitimate intermediate stages such as "Supported in these limited set > of circumstances". A number of features are not plausibly for use in > production environments, but otherwise function fine for > development/investigatory purposes. In these cases, something like "no > security support, but believed to be working fine" might be appropriate. I agree on this. I think we need an intermediate step: "working but not supported for security" is completely reasonable. When we say that it is "working", it should be because we have automated testing for it (I don't know if I would go as far as requiring it to be in OSSTest, any automated testing, even third party, would do). If it is not automatically tested, then it is just "best effort". Finally some features involve some sort of ABI exposed to the guest. At some point when the feature is "Supported", the ABI will be most certainly maintained for backward compatibility. But the feature could be fully workin
Re: [Xen-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI
On Fri, 2 Sep 2016, Olaf Hering wrote: > Implement SUSE specific unplug protocol for emulated PCI devices > in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'. > This protocol was implemented and used since Xen 3.0.4. > It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and > openSUSE 12.3. > > Signed-off-by: Olaf Hering > --- > hw/i386/xen/xen_platform.c | 31 ++- > 1 file changed, 30 insertions(+), 1 deletion(-) > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > index 53be3c7..6faee4c 100644 > --- a/hw/i386/xen/xen_platform.c > +++ b/hw/i386/xen/xen_platform.c > @@ -313,13 +313,42 @@ static void xen_platform_ioport_writeb(void *opaque, > hwaddr addr, > uint64_t val, unsigned int size) > { > PCIXenPlatformState *s = opaque; > +PCIDevice *pci_dev = PCI_DEVICE(s); > > switch (addr) { > case 0: /* Platform flags */ > platform_fixed_ioport_writeb(opaque, 0, (uint32_t)val); > break; > +case 4: > +if (val == 1) { > +/* > + * SUSE unplug for Xenlinux > + * xen-kmp used this since xen-3.0.4, instead the official > protocol > + * from xen-3.3+ It did an unconditional "outl(1, (ioaddr + 4));" > + * Pre VMDP 1.7 used 4 and 8 depending on how VMDP was > configured. > + * If VMDP was to control both disk and LAN it would use 4. > + * If it controlled just disk or just LAN, it would use 8 below. > + */ > +blk_drain_all(); > +blk_flush_all(); I was about to send a pull request for this series but blk_flush_all causes a build failure: /local/qemu-upstream/hw/i386/xen/xen_platform.c: In function 'xen_platform_ioport_writeb': /local/qemu-upstream/hw/i386/xen/xen_platform.c:331:13: error: implicit declaration of function 'blk_flush_all' [-Werror=implicit-function-declaration] /local/qemu-upstream/hw/i386/xen/xen_platform.c:331:13: error: nested extern declaration of 'blk_flush_all' [-Werror=nested-externs] cc1: all warnings being treated as errors make[1]: *** [hw/i386/xen/xen_platform.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [subdir-i386-softmmu] Error 2 > +pci_unplug_disks(pci_dev->bus); > +pci_unplug_nics(pci_dev->bus); > +} > +break; > case 8: > -log_writeb(s, (uint32_t)val); > +switch (val) { > +case 1: > +blk_drain_all(); > +blk_flush_all(); > +pci_unplug_disks(pci_dev->bus); > +break; > +case 2: > +pci_unplug_nics(pci_dev->bus); > +break; > +default: > +log_writeb(s, (uint32_t)val); > +break; > +} > break; > default: > break; > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On 13/10/2016 22:06, Stefano Stabellini wrote: > > Credit2 **Supperted**, instead of experimental. Supperted? That's like supported right? ;p It is fine for you to propose that a feature should be upgraded to supported, and this is probably the best way to formally do so. However, final agreement of a feature becoming supported should >>> include input from the security team. (At the end of the day, it is us with extra work if the feature isn't up to scratch.) >>> Is this new? If so, should we formalize the change in process somewhere >>> (patch to governance, etc.)? >> This came about when we had .. XSA7? Which was the tmem one and came with >> the idea that anything that moves to Supported has to pass the security >> audit pass. Off the top of my head, XSA-7 is the Intel silicon sysret bug. ITYM XSA-15, but your point still stands. > Make sense. In that case we should definitely write it down somewhere. My entire purpose with introducing feature docs to start with was to try and do for feature what we now do very well for docs/misc/xen-command-line.markdown i.e. to keep the documentation easy, and up to date. This does involve the committers, maintainers and reviewers being mindful to prompt for an update when necessary. However, it is very evident from the replies on-list these days that it has become second nature to a lot of people to either patch the document in the first place, or prompt others to do the same in submitted patches. Overall, this is a very good position to be in, for the community as a whole. I am certainly hoping that in another couple of years, we as a community have exactly the same "second nature" mindset when it comes to keeping the feature docs up to date. > I like the idea of keeping these info on pandoc on a git repo, like Lars > did with the governance. I should hasten to add that perhaps picking on the security team in isolation was a poor move on my part, for which I apologise. There are multiple involved parties with different interests, all of which need attending to. The feature submitter (should) have a vested interest in getting code submitted (even as experimental/tech preview to start with), so that others can trial/debug/extend the feature. Even having code upstream but disabled-by-default in Kconfig is a far better position for others to start from, than to be provided with instructions saying "there was a patch series several months ago on a mailing list". The reviewers/maintainers (should) have a vested interest in keeping the overall quality up. Due to their appointment within the community, they have demonstrated knowledge and expertise in their respective areas, and the overall project relies on them to ask questions such as "How does $X work with $Y?" or "Have you considered $Z as an alternative?", and to come to a fair and unbiased opinion to the quality and worthiness of a feature. The release manager has conflicted vested interests. On the one hand, getting more features in a release is better on paper and in the press, but can certainly backfire when features aren't up to scratch. Ultimately, if features in a release are substandard, the downstreams and end users will be the ones to bear the pain. It is in the release managers best interest to ensure that the features which are finally accepted are actually ready. Nothing is ever perfect, but a whole lot of stuff is perfectly good in common case, and useful for people in general. This is why the feature doc template specifically has sections for know issues to be fixed, and areas for future improvement. Any documentation (so long as it isn't factually incorrect) is better than nothing. There seems to be general consensus that a status of "Supported" means "with security support", and I agree with this assessment. Ultimately, the security team is accountable to whatever the project as a whole declares "Supported", but as the security team are all commiters and maintainer there is a large overlap of responsibility. OTOH, the security team are also responsible for managing the fallout when things go wrong. XSAs are bad publicity, and are a problem for downstreams (remember that we have plenty of downstreams who measure quantity of servers in units of a datacenter). Another problem we as a community have is that no support status is written down; there is a 13ish? year backlog in this regard. Writing details down in feature docs is intended to get everyone on the same, un-ambiguous, page. We also have an unfortunate habit of new features appearing, being accepted, and (intentionally or unintentionally) available to guests. Fastforward a bit, and it is discovered that said feature resembles a sieve in terms of security holes, and the common recourse is to publish an XSA stating "turn it off and don't use it with untrusted guests", or "here is a patch to actually turn it off, and still don't use it with untrusted guests", because
[Xen-devel] [PATCH for-4.8] altp2m: don't attempt to unshare pages during change_altp2m_gfn op
Attempting to change gfn mappings with altp2m on a memory shared page results in a lock-order violation (mm locking order violation: 282 > 254), which crashes the hypervisor. Don't attempt to automatically unshare such pages and just fall back to failing the op if the page type is not correct. Signed-off-by: Tamas K Lengyel --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/mm/p2m.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 9526fff..6a45185 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -2628,7 +2628,7 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int idx, if ( !mfn_valid(mfn) ) { mfn = __get_gfn_type_access(hp2m, gfn_x(old_gfn), &t, &a, -P2M_ALLOC | P2M_UNSHARE, &page_order, 0); +P2M_ALLOC, &page_order, 0); if ( !mfn_valid(mfn) || t != p2m_ram_rw ) goto out; -- 2.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 101421: regressions - FAIL
flight 101421 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/101421/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-bootfail REGR. vs. 101365 test-armhf-armhf-xl-arndale 11 guest-start fail REGR. vs. 101365 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 101365 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101365 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101365 test-amd64-amd64-xl-rtds 9 debian-install fail like 101365 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 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-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass version targeted for testing: qemuu692d88b4085559f1254d0e04d64a849ce8ab5932 baseline version: qemuu627eae7d729277c84f8e0ac07a8caab39c92c38d Last test of basis 101365 2016-10-11 02:21:11 Z2 days Failing since101395 2016-10-12 10:15:00 Z1 days3 attempts Testing same since 101421 2016-10-13 14:46:06 Z0 days1 attempts People who touched revisions under test: Cornelia Huck Daniel P. Berrange David Gibson Eric Blake Gerd Hoffmann Hans de Goede LluÃs Vilanova Marc-André Lureau P J P Peter Maydell Stefan Hajnoczi Thomas Huth Vijay Kumar B Vijay Kumar B. jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl
[Xen-devel] [xen-unstable test] 101415: regressions - FAIL
flight 101415 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101415/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 101396 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101396 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101396 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101396 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101396 test-amd64-amd64-xl-rtds 9 debian-install fail like 101396 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a build-i386-rumprun5 rumprun-buildfail never pass build-amd64-rumprun 5 rumprun-buildfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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 version targeted for testing: xen 38ab99b26bf4298a33105ec66f3f6a3f7e05a326 baseline version: xen 71b8b46111219a2f83f4f9ae06ac5409744ea86e Last test of basis 101396 2016-10-12 11:16:02 Z1 days Testing same since 101415 2016-10-13 06:04:49 Z0 days1 attempts People who touched revisions under test: Alistair Francis Edgar E. Iglesias Ian Jackson Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386
Re: [Xen-devel] [PATCH v2 10/10] xl: allow to set the ratelimit value online for Credit2
On 09/29/2016 08:54 PM, Dario Faggioli wrote: Last part of the wiring necessary for allowing to change the value of the ratelimit_us parameter online, for Credit2 (like it is already for Credit1). Signed-off-by: Dario Faggioli Reviewed-by: George Dunlap Seeing this patch got me to thinking that it would be cool if libvirt supported Credit2 :-). Do you have any plans/time to do that? Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [DOC v7] PV Calls protocol design
Hi all, This is the design document of the PV Calls protocol. You can find prototypes of the Linux frontend and backend drivers here: git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-7 To use them, make sure to enable CONFIG_XEN_PVCALLS in your kernel config and add "pvcalls=1" to the command line of your DomU Linux kernel. You also need the toolstack to create the initial xenstore nodes for the protocol. To do that, please apply the attached patch to libxl (the patch is based on Xen 4.7.0-rc3) and add "pvcalls=1" to your DomU config file. Please review! Cheers, Stefano Changes in v7: - add a glossary of Xen terms - add a paragraph on why Xen was chosen - wording improvements - add links to xenstore documents and headers - specify that the current version is "1" - rename max-dataring-page-order to max-page-order - rename networking-calls to function-calls - add links to [Data ring] throughout the document - explain the difference between req_id and id - mention that future commands larger than 56 bytes will require a version increase - mention that the list of commands is in calling order - clarify that reuse data rings are found by ref - rename ENOTSUPP to ENOTSUP - add padding in struct pvcalls_data_intf for cachelining - rename pvcalls_ring_queued to pvcalls_ring_unconsumed Changes in v6: - add reuse field in release command - add "networking-calls" backend node on xenstore - fixed tab/whitespace indentation Changes in v5: - clarify text - rename id to req_id - rename sockid to id - move id to request and response specific fields - add version node to xenstore Changes in v4: - rename xensock to pvcalls Changes in v3: - add a dummy element to struct xen_xensock_request to make sure the size of the struct is the same on both x86_32 and x86_64 Changes in v2: - add max-dataring-page-order - add "Publish backend features and transport parameters" to backend xenbus workflow - update new cmd values - update xen_xensock_request - add backlog parameter to listen and binary layout - add description of new data ring format (interface+data) - modify connect and accept to reflect new data ring format - add link to POSIX docs - add error numbers - add address format section and relevant numeric definitions - add explicit mention of unimplemented commands - add protocol node name - add xenbus shutdown diagram - add socket operation --- # PV Calls Protocol version 1 ## Glossary The following is a list of terms and definitions used in the Xen community. If you are a Xen contributor you can skip this section. * PV Short for paravirtualized. * Dom0 First virtual machine that boots. In most configurations Dom0 is privileged and has control over hardware devices, such as network cards, graphic cards, etc. * DomU Regular unprivileged Xen virtual machine. * Domain A Xen virtual machine. Dom0 and all DomUs are all separate Xen domains. * Guest Same as domain: a Xen virtual machine. * Frontend Each DomU has one or more paravirtualized frontend drivers to access disks, network, console, graphics, etc. The presence of PV devices is advertized on XenStore, a cross domain key-value database. Frontends are similar in intent to the virtio drivers in Linux. * Backend A Xen paravirtualized backend typically runs in Dom0 and it is used to export disks, network, console, graphics, etcs, to DomUs. Backends can live both in kernel space and in userspace. For example xen-blkback lives under drivers/block in the Linux kernel and xen_disk lives under hw/block in QEMU. Paravirtualized backends are similar in intent to virtio device emulators. * VMX and SVM On Intel processors, VMX is the CPU flag for VT-x, hardware virtualization support. It corresponds to SVM on AMD processors. ## Rationale PV Calls is a paravirtualized protocol that allows the implementation of a set of POSIX functions in a different domain. The PV Calls frontend sends POSIX function calls to the backend, which implements them and returns a value to the frontend. This version of the document covers networking function calls, such as connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but the protocol is meant to be easily extended to cover different sets of calls. Unimplemented commands return ENOTSUP. PV Calls provide the following benefits: * full visibility of the guest behavior on the backend domain, allowing for inexpensive filtering and manipulation of any guest calls * excellent performance Specifically, PV Calls for networking offer these advantages: * guest networking works out of the box with VPNs, wireless networks and any other complex configurations on the host * guest services listen on ports bound directly to the backend domain IP addresses * localhost becomes a secure namespace for inter-VMs communications ## Design ### Why Xen? PV Calls are part of an effort to create a secure runtime environment for containers (OCI im
Re: [Xen-devel] [PATCH] acpi: don't register acpi_pad driver if running as xen dom0
On Wednesday, October 12, 2016 01:11:45 PM Juergen Gross wrote: > When running as Xen dom0 a special processor_aggregator driver is > needed. Don't register the standard driver in this case. > > Without that check an error message: > > "Error: Driver 'processor_aggregator' is already registered, > aborting..." > > will be displayed. > > Signed-off-by: Juergen Gross > --- > drivers/acpi/acpi_pad.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c > index 8ea8211..1c3be12 100644 > --- a/drivers/acpi/acpi_pad.c > +++ b/drivers/acpi/acpi_pad.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > > #define ACPI_PROCESSOR_AGGREGATOR_CLASS "acpi_pad" > #define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor Aggregator" > @@ -477,6 +478,10 @@ static struct acpi_driver acpi_pad_driver = { > > static int __init acpi_pad_init(void) > { > + /* Xen acpi pad is responsible when running as Xen Dom0. */ > + if (xen_initial_domain()) > + return -ENODEV; > + > power_saving_mwait_init(); > if (power_saving_mwait_eax == 0) > return -EINVAL; > Applied. Thanks, Rafael ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 67875: all pass
This run is configured for baseline tests only. flight 67875 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67875/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 08354c34486947da17a36a605f9a4b000132123f baseline version: ovmf a12b214ef9e002b3b7a7f7845bb025a2a8597dcc Last test of basis67870 2016-10-13 06:23:21 Z0 days Testing same since67875 2016-10-13 16:18:57 Z0 days1 attempts People who touched revisions under test: Maurice Ma Michael Kinney Tapan Shah Thomas Palmer 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.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. commit 08354c34486947da17a36a605f9a4b000132123f Author: Maurice Ma Date: Wed Oct 12 18:00:44 2016 -0700 IntelFsp2Pkg/FspSecCore: Make FSP functions position independent The current AsmGetFspInfoHeader function in FspHeader.nasm is position dependent code since it uses absolute address. Change to use relative address instead to make it position independent. Cc: Jiewen Yao Cc: Giri P Mudusuru Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma Reviewed-by: Giri P Mudusuru commit 75351daf3e92c86b3d1669ba0e6d95a6e9a270a3 Author: Thomas Palmer Date: Wed Oct 12 13:14:34 2016 -0700 ShellPkg/UefiShellTftpCommandLib: Update TFTP help text Clear up some help text for the TFTP shell command Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer Reviewed-by: Jaben Carsey commit dd170333f6444a4256e75356a8f0758a40bfb77d Author: Michael Kinney Date: Fri Oct 7 14:07:03 2016 -0700 BaseTools/GenFds: Support FDF sections in any order https://bugzilla.tianocore.org/show_bug.cgi?id=141 This patch updates EDK II FDF parser in GenFds to allow sections to be placed in any order in the FDF file. Cc: Kelly Steele Cc: Yonghong Zhu Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney Reviewed-by: Yonghong Zhu commit a7ea752e59bbbf69c6d8a72ee6a8b7a0f77cca7c Author: Tapan Shah Date: Fri Oct 7 13:59:34 2016 -0700 ShellPkg:?cd \? command fails to go back to the root directory of a file system Allows cd command to go back to the root directory when 'cd \' executed in system. This change prevents last PathRemoveLastItem() call which truncates '\' from 'fs0:\' in desired root path which is required to set CWD to the root directory. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Tapan Shah Reviewed-by: Jaben Carsey ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] x86/Intel: virtualize support for cpuid faulting
On HVM guests, the cpuid triggers a vm exit, so we can check the emulated faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no hardware support for faulting on cpuid is necessary to emulate support with an HVM guest. On PV guests, hardware support is required so that userspace cpuid will trap to xen. Xen already enables cpuid faulting on supported CPUs for pv guests (that aren't the control domain, see the comment in intel_ctxt_switch_levelling). Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via do_general_protection). Once there we simply decline to emulate cpuid if the CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to handle. Signed-off-by: Kyle Huey --- xen/arch/x86/hvm/vmx/vmx.c | 24 ++-- xen/arch/x86/traps.c | 30 ++ xen/include/asm-x86/domain.h | 3 +++ 3 files changed, 55 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index b9102ce..55201c1 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2427,16 +2427,25 @@ static void vmx_cpuid_intercept( HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx); } static int vmx_do_cpuid(struct cpu_user_regs *regs) { unsigned int eax, ebx, ecx, edx; unsigned int leaf, subleaf; +struct segment_register sreg; +struct vcpu *v = current; + +hvm_get_segment_register(v, x86_seg_ss, &sreg); +if ( v->arch.cpuid_fault && sreg.attr.fields.dpl > 0 ) +{ +hvm_inject_hw_exception(TRAP_gp_fault, 0); +return 0; +} eax = regs->eax; ebx = regs->ebx; ecx = regs->ecx; edx = regs->edx; leaf = regs->eax; subleaf = regs->ecx; @@ -2694,19 +2703,23 @@ static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content) case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL: case MSR_IA32_PEBS_ENABLE: case MSR_IA32_DS_AREA: if ( vpmu_do_rdmsr(msr, msr_content) ) goto gp_fault; break; case MSR_INTEL_PLATFORM_INFO: -if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *msr_content) ) -goto gp_fault; +*msr_content = MSR_PLATFORM_INFO_CPUID_FAULTING; +break; + +case MSR_INTEL_MISC_FEATURES_ENABLES: *msr_content = 0; +if ( current->arch.cpuid_fault ) +*msr_content |= MSR_MISC_FEATURES_CPUID_FAULTING; break; default: if ( passive_domain_do_rdmsr(msr, msr_content) ) goto done; switch ( long_mode_do_msr_read(msr, msr_content) ) { case HNDL_unhandled: @@ -2925,16 +2938,23 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content) break; case MSR_INTEL_PLATFORM_INFO: if ( msr_content || rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) ) goto gp_fault; break; +case MSR_INTEL_MISC_FEATURES_ENABLES: +if ( msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING ) +goto gp_fault; +v->arch.cpuid_fault = +!!(msr_content & MSR_MISC_FEATURES_CPUID_FAULTING); +break; + default: if ( passive_domain_do_wrmsr(msr, msr_content) ) return X86EMUL_OKAY; if ( wrmsr_viridian_regs(msr, msr_content) ) break; switch ( long_mode_do_msr_write(msr, msr_content) ) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 293ff8d..6d1c1ef 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct cpu_user_regs *regs) /* We only emulate CPUID. */ if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 ) { propagate_page_fault(eip + sizeof(instr) - rc, 0); return EXCRET_fault_fixed; } if ( memcmp(instr, "\xf\xa2", sizeof(instr)) ) return 0; +/* Let the guest have this one */ +if ( current->arch.cpuid_fault && !guest_kernel_mode(current, regs) ) +return 0; + eip += sizeof(instr); pv_cpuid(regs); instruction_done(regs, eip, 0); trace_trap_one_addr(TRC_PV_FORCED_INVALID_OP, regs->eip); @@ -2474,16 +2478,27 @@ static int priv_op_read_msr(unsigned int reg, uint64_t *val, *val = 0; return X86EMUL_OKAY; case MSR_INTEL_PLATFORM_INFO: if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *val) ) break; *val = 0; +if ( this_cpu(cpuid_faulting_enabled) ) +*val |= MSR_PLATFORM_INFO_CPUID_FAULTING; +return X86EMUL_OKAY; + +case MSR_INTEL_MISC_FEATURES_ENABLES: +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || + rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, *val)) +break; +*val = 0; +if ( curr->arch.
[Xen-devel] [PATCH v2 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere
--- xen/arch/x86/cpu/intel.c| 3 ++- xen/include/asm-x86/cpuid.h | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c index 7b60aaa..95c8e14 100644 --- a/xen/arch/x86/cpu/intel.c +++ b/xen/arch/x86/cpu/intel.c @@ -27,19 +27,20 @@ static bool_t __init probe_intel_cpuid_faulting(void) return 0; expected_levelling_cap |= LCAP_faulting; levelling_caps |= LCAP_faulting; __set_bit(X86_FEATURE_CPUID_FAULTING, boot_cpu_data.x86_capability); return 1; } +DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled); + static void set_cpuid_faulting(bool_t enable) { - static DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled); bool_t *this_enabled = &this_cpu(cpuid_faulting_enabled); uint32_t hi, lo; ASSERT(cpu_has_cpuid_faulting); if (*this_enabled == enable) return; diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h index 8e3f639..af8eb9d 100644 --- a/xen/include/asm-x86/cpuid.h +++ b/xen/include/asm-x86/cpuid.h @@ -59,16 +59,19 @@ struct cpuidmasks }; /* Per CPU shadows of masking MSR values, for lazy context switching. */ DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks); /* Default masking MSR values, calculated at boot. */ extern struct cpuidmasks cpuidmask_defaults; +/* Whether or not cpuid faulting is available for the current domain. */ +DECLARE_PER_CPU(bool_t, cpuid_faulting_enabled); + #endif /* __ASSEMBLY__ */ #endif /* !__X86_CPUID_H__ */ /* * Local variables: * mode: C * c-file-style: "BSD" * c-basic-offset: 4 base-commit: 71b8b46111219a2f83f4f9ae06ac5409744ea86e -- 2.10.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86/Intel: virtualize support for cpuid faulting
rr (http://rr-project.org/), a Linux userspace record-and-replay reverse- execution debugger, would like to trap and emulate the CPUID instruction. This would allow us to a) mask away certain hardware features that rr does not support (e.g. RDRAND) and b) enable trace portability across machines by providing constant results. Patches for support in the Linux kernel are in flight, and we'd like to be able to use this feature on virtualized Linux instances as well. Changes since the previous version: - Rebased. - Exposed cpuid_faulting_enabled outside of cpu/intel.c, as suggested by Andrew Cooper. This is now patch 1, and the original changes are in patch 2. - Various style nits from Andrew Cooper and Jan Beulich. - Additional style changes not suggested (primarily replacing ternaries with if (condition) value |= BIT for futureproofing). - Check guest_kernel_mode instead of ring_0 in emulate_privileged_op. - Check cpuid_fault and guest_kernel_mode in emulate_forced_invalid_op. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On Thu, 13 Oct 2016, Konrad Rzeszutek Wilk wrote: > On October 13, 2016 2:13:19 PM EDT, Stefano Stabellini > wrote: > >On Thu, 13 Oct 2016, Andrew Cooper wrote: > >> On 13/10/16 12:01, Dario Faggioli wrote: > >> > Hey, > >> > > >> > "Just" as per the subject, I wrote feature documents for (almost) > >all our > >> > schedulers. No big deal, I'd say, apart from the fact that I'm > >declaring > >> > Credit2 **Supperted**, instead of experimental. > >> > >> Supperted? That's like supported right? ;p > >> > >> > >> It is fine for you to propose that a feature should be upgraded to > >> supported, and this is probably the best way to formally do so. > >> > >> However, final agreement of a feature becoming supported should > >include > >> input from the security team. (At the end of the day, it is us with > >> extra work if the feature isn't up to scratch.) > > > >Is this new? If so, should we formalize the change in process somewhere > >(patch to governance, etc.)? > > This came about when we had .. XSA7? Which was the tmem one and came with the > idea that anything that moves to Supported has to pass the security audit > pass. Make sense. In that case we should definitely write it down somewhere. I like the idea of keeping these info on pandoc on a git repo, like Lars did with the governance. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On October 13, 2016 2:13:19 PM EDT, Stefano Stabellini wrote: >On Thu, 13 Oct 2016, Andrew Cooper wrote: >> On 13/10/16 12:01, Dario Faggioli wrote: >> > Hey, >> > >> > "Just" as per the subject, I wrote feature documents for (almost) >all our >> > schedulers. No big deal, I'd say, apart from the fact that I'm >declaring >> > Credit2 **Supperted**, instead of experimental. >> >> Supperted? That's like supported right? ;p >> >> >> It is fine for you to propose that a feature should be upgraded to >> supported, and this is probably the best way to formally do so. >> >> However, final agreement of a feature becoming supported should >include >> input from the security team. (At the end of the day, it is us with >> extra work if the feature isn't up to scratch.) > >Is this new? If so, should we formalize the change in process somewhere >(patch to governance, etc.)? This came about when we had .. XSA7? Which was the tmem one and came with the idea that anything that moves to Supported has to pass the security audit pass. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] ANNOUNCEMENT] Xen 4.8 RC2 FULL SUCCESS 13.10.16
* Hardware: Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz * Software: Debian testing is the Host * Guest operating systems: Guests Ubuntu 14.04 LTS Debian Stretch/Sid Ubuntu 16.04 * Functionality tested: xl creating booting pygrub * Comments: Wei Liu is the man - On 13 Oct, 2016, at 16:45, Wei Liu wei.l...@citrix.com wrote: > Add back xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On 13/10/16 19:59, Dan Williams wrote: > On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper > wrote: >> On 13/10/16 16:40, Dan Williams wrote: >>> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote: >>> [..] > I think we can do the similar for Xen, like to lay another pseudo > device on /dev/pmem and do the reservation, like 2. in my previous > reply. Well, my opinion certainly doesn't count much here, but I continue to consider this a bad idea. For entities like drivers it may well be appropriate, but I think there ought to be an independent concept of "OS reserved", and in the Xen case this could then be shared between hypervisor and Dom0 kernel. Or if we were to consider Dom0 "just a guest", things should even be the other way around: Xen gets all of the OS reserved space, and Dom0 needs something custom. >>> You haven't made the case why Xen is special and other applications of >>> persistent memory are not. >> In a Xen system, Xen runs in the baremetal root-mode ring0, and dom0 is >> a VM running in ring1/3 with the nvdimm driver. This is the opposite >> way around to the KVM model. >> >> Dom0, being the hardware domain, has default ownership of all the >> hardware, but to gain access in the first place, it must request a >> mapping from Xen. > This is where my understanding the Xen model breaks down. Are you > saying dom0 can't access the persistent memory range unless the ring0 > agent has metadata storage space for tracking what it maps into dom0? No. I am trying to point out that the current suggestion wont work, and needs re-designing. Xen *must* be able to properly configure mappings of the NVDIMM for dom0, *without* modifying any content on the NVDIMM. Otherwise, data corruption will occur. Whether this means no Xen metadata, or the metadata living elsewhere in regular ram, such as the main frametable, is an implementation detail. > >> Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to work >> and figure out what is on the DIMM, and which areas are safe to use. > I don't understand this ordering of events. Dom0 needs to have a > mapping to even write the on-media structure to indicate a > reservation. So, initial dom0 access can't depend on metadata > reservation already being present. I agree. Overall, I think the following is needed. * Xen starts up. ** Xen might find some NVDIMM SPA/MFN ranges in the NFIT table, and needs to note this information somehow. ** Xen might find some Type 7 E820 regions, and needs to note this information somehow. * Xen starts dom0. * Once OSPM is running, a Xen component in Linux needs to collect and report all NVDIMM SPA/MFN regions it knowns about. ** This covers the AML-only case, and the hotplug case. * Dom0 requests a mapping of the NVDIMMs via the usual mechanism. ** This should work, as Xen is aware that there is something there to be mapped (rather than just empty physical address space). * Dom0 finds that some NVDIMM ranges are now available for use (probably modelled as hotplug events). * /dev/pmem $STUFF starts happening as normal. At some pointer later after dom0 policy decisions are made (ultimately, by the host administrator): * If an area of NVDIMM is chosen for Xen to use, Dom0 needs to inform Xen of the SPA/MFN regions which are safe to use. * Xen then incorporates these regions into its idea of RAM, and starts using them for whatever. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper wrote: > On 13/10/16 16:40, Dan Williams wrote: >> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote: >> [..] I think we can do the similar for Xen, like to lay another pseudo device on /dev/pmem and do the reservation, like 2. in my previous reply. >>> Well, my opinion certainly doesn't count much here, but I continue to >>> consider this a bad idea. For entities like drivers it may well be >>> appropriate, but I think there ought to be an independent concept >>> of "OS reserved", and in the Xen case this could then be shared >>> between hypervisor and Dom0 kernel. Or if we were to consider Dom0 >>> "just a guest", things should even be the other way around: Xen gets >>> all of the OS reserved space, and Dom0 needs something custom. >> You haven't made the case why Xen is special and other applications of >> persistent memory are not. > > In a Xen system, Xen runs in the baremetal root-mode ring0, and dom0 is > a VM running in ring1/3 with the nvdimm driver. This is the opposite > way around to the KVM model. > > Dom0, being the hardware domain, has default ownership of all the > hardware, but to gain access in the first place, it must request a > mapping from Xen. This is where my understanding the Xen model breaks down. Are you saying dom0 can't access the persistent memory range unless the ring0 agent has metadata storage space for tracking what it maps into dom0? That can't be true because then PCI memory ranges would not work without metadata reserve space. Dom0 still needs to map and write the DIMMs to even set up the struct page reservation, it isn't established by default. > Xen therefore needs to know and cope with being able > to give dom0 a mapping to the nvdimms, without touching the content of > the nvidmm itself (so as to avoid corrupting data). Is it true that this metadata only comes into use when remapping the dom0 discovered range(s) into a guest VM? > Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to work > and figure out what is on the DIMM, and which areas are safe to use. I don't understand this ordering of events. Dom0 needs to have a mapping to even write the on-media structure to indicate a reservation. So, initial dom0 access can't depend on metadata reservation already being present. > At this point, a Xen subsystem in Linux could choose one or more areas > to hand back to the hypervisor to use as RAM/other. To me all this configuration seems to come after the fact. After dom0 sees /dev/pmemX devices, then it can go to work carving it up and writing Xen specific metadata to the range(s). The struct page reservation never comes into the picture. In fact, a raw mode namespace (one without a reservation) could be used in this model, the nvdimm core never needs to know what is happening. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] flask: add gcov_op check
On 10/13/2016 10:37 AM, Wei Liu wrote: Signed-off-by: Wei Liu Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On Thu, 13 Oct 2016, Andrew Cooper wrote: > On 13/10/16 12:01, Dario Faggioli wrote: > > Hey, > > > > "Just" as per the subject, I wrote feature documents for (almost) all our > > schedulers. No big deal, I'd say, apart from the fact that I'm declaring > > Credit2 **Supperted**, instead of experimental. > > Supperted? That's like supported right? ;p > > > It is fine for you to propose that a feature should be upgraded to > supported, and this is probably the best way to formally do so. > > However, final agreement of a feature becoming supported should include > input from the security team. (At the end of the day, it is us with > extra work if the feature isn't up to scratch.) Is this new? If so, should we formalize the change in process somewhere (patch to governance, etc.)? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 101422: tolerable all pass - PUSHED
flight 101422 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101422/ 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 b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb baseline version: xen 38ab99b26bf4298a33105ec66f3f6a3f7e05a326 Last test of basis 101403 2016-10-12 15:03:35 Z1 days Testing same since 101418 2016-10-13 12:06:49 Z0 days2 attempts People who touched revisions under test: Ian Jackson Jan Beulich Lan Tianyu Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable-smoke + revision=b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb + . ./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 b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb + branch=xen-unstable-smoke + revision=b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb + . ./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 + '[' xb5283627de6b7ba2b8d75ecf1edf0a46bcd83edb = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/xtf.git ++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git ++ : git://xenbits.xen.org/xtf.git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/osstest/rumprun.git ++ : git ++ : git://xenbits.xen.org/osstest/rumprun.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git ++ : git://git.seabios.org/seabios.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git ++ : git://xenbits.xen.org/osstest/seabios.git ++ : https://github.com/tianocore/edk2.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git ++ : git://xenbits.xen.org/osstest/ovmf.git ++ : git://xenbits.xen.org/osstest/linux-firmware.git ++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git ++ : git://git.kerne
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
Add back xen-devel On Thu, Oct 13, 2016 at 05:26:12PM +0100, Juergen Schinker wrote: > > > - On 13 Oct, 2016, at 14:53, Wei Liu wei.l...@citrix.com wrote: > > > Hmm... I think no amount of hand-holding is going to help you. > > > > In your situation I would suggest you to use various tools available on > > Linux to figure out why it hang. Tools like strace, ldd, gdb etc, but > > that's going to be rather technical and the finding isn't going to be > > useful or interesting to you in the long run. The hang is likely due to > > mismatch in various bits in the system. > > > > I think your best bet is to have a clean installation of Xen. > > > > Wei. > > I don't want hand holding - this is a bug report dude > > I;m very technical and it is useful and interesting Sorry if that came out offensive to you -- I didn't mean to. If you're really interested in going down this rabbit hole, I think you will need to do the following: 1. Make sure all the Xen related libraries are properly installed into the location you specified when building Xen. 2. Use ldd to check if xl / xenstored are the ones you installed. 3. Make sure they can find all the libraries (ldd should be handy). 4. Use strace to identify when and where they hang. There is a lot information about Xen in general on wiki.xenproject.org. If you need to get more information about the architecture / moving parts of Xen, check out the wiki. After identifying why they don't work, you will have a lot more information to either submit a detailed bug report or start hunting down these issues for fun and profit (!). :-) There isn't enough information in the current report for me to tell what goes wrong in your setup. The basic life cycle of running Xen (the operations in your bug report) is constantly tested in Xen project CI and all developers -- neither CI nor humans spotted bugs in those areas in the past week. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 101413: regressions - FAIL
flight 101413 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/101413/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-pair 9 xen-boot/src_hostfail REGR. vs. 101000 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 101000 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 101000 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 101413 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 101413 test-amd64-i386-freebsd10-amd64 6 xen-bootfail pass in 101389 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-bootfail pass in 101398 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail pass in 101398 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail pass in 101398 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail pass in 101398 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass in 101398 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 101000 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a build-i386-rumprun5 rumprun-buildfail never pass build-amd64-rumprun 5 rumprun-buildfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-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-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: linux3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430 baseline version:
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On 13/10/16 16:40, Dan Williams wrote: > On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote: > [..] >>> I think we can do the similar for Xen, like to lay another pseudo >>> device on /dev/pmem and do the reservation, like 2. in my previous >>> reply. >> Well, my opinion certainly doesn't count much here, but I continue to >> consider this a bad idea. For entities like drivers it may well be >> appropriate, but I think there ought to be an independent concept >> of "OS reserved", and in the Xen case this could then be shared >> between hypervisor and Dom0 kernel. Or if we were to consider Dom0 >> "just a guest", things should even be the other way around: Xen gets >> all of the OS reserved space, and Dom0 needs something custom. > You haven't made the case why Xen is special and other applications of > persistent memory are not. In a Xen system, Xen runs in the baremetal root-mode ring0, and dom0 is a VM running in ring1/3 with the nvdimm driver. This is the opposite way around to the KVM model. Dom0, being the hardware domain, has default ownership of all the hardware, but to gain access in the first place, it must request a mapping from Xen. Xen therefore needs to know and cope with being able to give dom0 a mapping to the nvdimms, without touching the content of the nvidmm itself (so as to avoid corrupting data). Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to work and figure out what is on the DIMM, and which areas are safe to use. At this point, a Xen subsystem in Linux could choose one or more areas to hand back to the hypervisor to use as RAM/other. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 baseline-only test] 67872: tolerable FAIL
This run is configured for baseline tests only. flight 67872 linux-4.1 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67872/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail blocked in 67728 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail blocked in 67728 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 67728 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 67728 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a build-amd64-rumprun 5 rumprun-buildfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-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-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass build-i386-rumprun5 rumprun-buildfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: linux91473db3a3257eacead8f4d84cf4bc96c447193f baseline version: linux04cb720142764ebf3786eba1feb8fc4b6ef87fcf Last test of basis67728 2016-09-18 23:15:34 Z 24 days Testing same since67872 2016-10-13 08:19:29 Z0 days1 attempts People who touched revisions under test: Akshay Bhat Al Viro Alan Stern Andrew Morton Anson Huang Ard Biesheuvel Ashish Samant Balbir Singh Benjamin Herrenschmidt Boris Brezillon Catalin Marinas Chris Mason Christoffer Dall Clemens Gruber Daniele Palmas Dave Airlie David S. Miller Eric Biggers Fabio Estevam Felipe Balbi Felix Fietkau Greg Kroah-Hartman Gregory CLEMENT Guenter Roeck Hans-Christian Noren Egtvedt Havard Skinnemoen Herbert Xu Huacai Chen Ian Kent Ingo Molnar Itaru Kitayama Jaegeuk Kim James Hogan Jan Kara Jan Leupold Jan Stancek Jeff Mahoney Jesper Nilsson Johan Hovold Johannes Berg Jonathan Cameron Joseph Qi Jun Piao Justin Chen Kai-Heng Feng Kalle Valo Ken Lin Kristian H. Kristensen Kristian H. Kristensen Lee Jones Linus Torvalds Linus Walleij Manuel Laus
Re: [Xen-devel] [PATCH 02/15] xen: Fix coding style warnings
Oh, I see. Because gmail messes up the alignment but raw diff looked fine I thought that you were seeing the same issue as I see on email client. I will align the quoted strings properly with the first parameter and I will send another series. Thanks, Emil On Thu, Oct 13, 2016 at 2:35 PM, Anthony PERARD wrote: > On Thu, Oct 13, 2016 at 07:04:56AM +0300, Emil Condrea wrote: >> On Tue, Oct 11, 2016 at 5:20 PM, Anthony PERARD >> wrote: >> > On Tue, Oct 04, 2016 at 09:43:31AM +0300, Emil Condrea wrote: >> >> Fixes: >> >> * WARNING: line over 80 characters >> >> >> >> Signed-off-by: Emil Condrea >> >> --- >> >> hw/block/xen_disk.c | 3 ++- >> >> hw/char/xen_console.c| 6 -- >> >> hw/display/xenfb.c | 30 -- >> >> hw/net/xen_nic.c | 12 >> >> hw/xen/xen_backend.c | 15 ++- >> >> include/hw/xen/xen_backend.h | 8 +--- >> >> 6 files changed, 49 insertions(+), 25 deletions(-) >> >> >> >> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c >> >> index 5aa350a..24edeb2 100644 >> >> --- a/hw/block/xen_disk.c >> >> +++ b/hw/block/xen_disk.c >> >> @@ -1068,7 +1068,8 @@ static int blk_connect(struct XenDevice *xendev) >> >> blk_set_enable_write_cache(blkdev->blk, !writethrough); >> >> } else { >> >> /* setup via qemu cmdline -> already setup for us */ >> >> -xen_be_printf(&blkdev->xendev, 2, "get configured bdrv (cmdline >> >> setup)\n"); >> >> +xen_be_printf(&blkdev->xendev, 2, >> >> + "get configured bdrv (cmdline setup)\n"); >> > >> > Arguments are usually aligned with the first one, so there is one >> > missing space. >> >> I guess this is displayed wrongly in the email client as in mine but the >> source >> of the email contains this patch http://pastebin.com/Sbk23h6m, which shows >> that >> this line is aligned to the first parameter. > > My mail client runs in a terminal, also I've apply the patches to a > local tree, so no display issue. > > Here, the quote is just below the open parentheses, but it's normally > one space futher. > > If I ask Vim to realign it, I end up with this: > xen_be_printf(&blkdev->xendev, 2, > - "get configured bdrv (cmdline setup)\n"); > + "get configured bdrv (cmdline setup)\n"); > > You can also have a look at other call of xen_be_printf() in this > function (blk_connect) to get an idea ;). > > -- > Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 101414: all pass - PUSHED
flight 101414 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/101414/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 08354c34486947da17a36a605f9a4b000132123f baseline version: ovmf a12b214ef9e002b3b7a7f7845bb025a2a8597dcc Last test of basis 101402 2016-10-12 15:00:43 Z1 days Testing same since 101414 2016-10-13 05:59:09 Z0 days1 attempts People who touched revisions under test: Maurice Ma Michael Kinney Tapan Shah Thomas Palmer 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=08354c34486947da17a36a605f9a4b000132123f + . ./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 08354c34486947da17a36a605f9a4b000132123f + branch=ovmf + revision=08354c34486947da17a36a605f9a4b000132123f + . ./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 + '[' x08354c34486947da17a36a605f9a4b000132123f = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/xtf.git ++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git ++ : git://xenbits.xen.org/xtf.git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/osstest/rumprun.git ++ : git ++ : git://xenbits.xen.org/osstest/rumprun.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git ++ : git://git.seabios.org/seabios.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git ++ : git://xenbits.xen.org/osstest/seabios.git ++ : https://github.com/tianocore/edk2.git ++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git ++ : git://xenbits.xen.org/osstest/ovmf.git ++ : git://xenbits.xen.org/osstest/linux-firmware.git ++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git ++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git ++ : os
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On 10/13/16 03:08 -0600, Jan Beulich wrote: On 13.10.16 at 10:53, wrote: On 10/13/16 02:34 -0600, Jan Beulich wrote: On 12.10.16 at 18:19, wrote: On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: On 12.10.16 at 17:42, wrote: On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: On 12.10.16 at 16:58, wrote: On 10/12/16 05:32 -0600, Jan Beulich wrote: On 12.10.16 at 12:33, wrote: The layout is shown as the following diagram. +---+---+---+--+--+ | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | | by kernel| Table | Block | for Xen | | +---+---+---+--+--+ \_ ___/ V /dev/pmem0 I have to admit that I dislike this, for not being OS-agnostic. Neither should there be any Xen-specific region, nor should the "whatever used by kernel" one be restricted to just Linux. What I could see is an OS-reserved area ahead of the partition table, the exact usage of which depends on which OS is currently running (and in the Xen case this might be both Xen _and_ the Dom0 kernel, arbitrated by a tbd protocol). After all, when running under Xen, the Dom0 may not have a need for as much control data as it has when running on bare hardware, for it controlling less (if any) of the actual memory ranges when Xen is present. Isn't this OS-reserved area still not OS-agnostic, as it requires OS to know where the reserved area is? Or do you mean it's not if it's defined by a protocol that is accepted by all OSes? The latter - we clearly won't get away without some agreement on where to retrieve position and size of this area. I was simply assuming that such a protocol already exists. No, we should not mix the struct page reservation that the Dom0 kernel may actively use with the Xen reservation that the Dom0 kernel does not consume. Explain again what is wrong with the partition approach? Not sure what was unclear in my previous reply. I don't think there should be apriori knowledge of whether Xen is (going to be) used on a system, and even if it gets used, but just occasionally, it would (apart from the abstract considerations already given) be a waste of resources to set something aside that could be used for other purposes while Xen is not running. Static partitioning should only be needed for persistent data. The reservation needs to be persistent / static even if the data is volatile, as is the case with struct page, because we can't have the size of the device change depending on use. So, from the aspect of wasting space while Xen is not in use, both partitions and the intrinsic reservation approach suffer the same problem. Setting that aside I don't want to mix 2 different use cases into the same reservation. Then you didn't understand what I've said: I certainly didn't mean the reservation to vary from a device perspective. However, when Xen is in use I don't see why part of that static reservation couldn't be used by Xen, and another part by the Dom0 kernel. The kernel obviously would need to ask the hypervisor how much of the space is left, and where that area starts. I think Dan means that there should be a clear separation between reservations for different usages (kernel/xen/...). The libnvdimm driver is for the linux kernel and only needs to maintain the reservation for kernel functionality. For others including xen/dm/..., if they want reservation for their own purpose, they should maintain their own reservations out of libnvdimm driver and avoid bothering the libnvdimm driver (e.g. add specific handling in libnvdimm driver). IIUC, one existing example is device-mapper device (dm) which needs to reserve on-device area for its own meta-data. Its choice is to store the meta-data on the block device (/dev/pmemN) provided by the libnvdimm driver. I think we can do the similar for Xen, like to lay another pseudo device on /dev/pmem and do the reservation, like 2. in my previous reply. Well, my opinion certainly doesn't count much here, but I continue to consider this a bad idea. For entities like drivers it may well be appropriate, but I think there ought to be an independent concept of "OS reserved", and in the Xen case this could then be shared between hypervisor and Dom0 kernel. No such independent concept seems exist right now. It may be hard to define such concept, because it's hard to know the common requirements (e.g. size/alignment/...) from ALL OSes. Making each component to maintain its own reservation in its own way seems more flexible. Or if we were to consider Dom0 "just a guest", things should even be the other way around: Xen gets all of the OS reserved space, and Dom0 needs something custom. Sure, it's possible to implement the driver in a way that if the driver finds it runs on Xen, then it just leaves the OS reserved area
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote: [..] >> I think we can do the similar for Xen, like to lay another pseudo >> device on /dev/pmem and do the reservation, like 2. in my previous >> reply. > > Well, my opinion certainly doesn't count much here, but I continue to > consider this a bad idea. For entities like drivers it may well be > appropriate, but I think there ought to be an independent concept > of "OS reserved", and in the Xen case this could then be shared > between hypervisor and Dom0 kernel. Or if we were to consider Dom0 > "just a guest", things should even be the other way around: Xen gets > all of the OS reserved space, and Dom0 needs something custom. You haven't made the case why Xen is special and other applications of persistent memory are not. The current struct page reservation supports fundamental address-ability of persistent memory namespaces for the rest of the kernel. The Xen reservation is application specific. XFS, EXT4, and DM also have application specific usages of persistent memory and consume metadata space out of a block device. If we don't need an XFS-mode nvdimm device, why do we need Xen-mode? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-netback: fix type mismatch warning
From: Arnd Bergmann Date: Wed, 12 Oct 2016 16:54:01 +0200 > Wiht the latest rework of the xen-netback driver, we get a warning > on ARM about the types passed into min(): > > drivers/net/xen-netback/rx.c: In function 'xenvif_rx_next_chunk': > include/linux/kernel.h:739:16: error: comparison of distinct pointer types > lacks a cast [-Werror] > > The reason is that XEN_PAGE_SIZE is not size_t here. There > is no actual bug, and we can easily avoid the warning using the > min_t() macro instead of min(). > > Fixes: eb1723a29b9a ("xen-netback: refactor guest rx") > Signed-off-by: Arnd Bergmann Applied, thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
On Thu, Oct 13, 2016 at 11:02:09AM +0100, Juergen Schinker wrote: > > > - On 13 Oct, 2016, at 09:29, Wei Liu wei.l...@citrix.com wrote: > > > On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote: > >> Right and still no solution > >> > >> there is no xz-dev or libxz-dev; I installed everything which just looks > >> remote > >> like xz or lzma > >> > > > > On Debian it is called liblzma-dev. Not sure what distro you use. > > > >> building is no problem as I build with > >> > >> ./configure --enable-githttp --enable-systemd --disable-rombios > >> --disable-qemu-traditional --disable-stubdom --disable-docs > >> > >> > > > > And you sorta worked around the lzma requirement by disabling rombios. > > > > This issue you encountered is a different issue from Boris'. > > no still no solution > > the xz problem is only for xen-4.7 but i gave up on that > > my last test was 4.8-rc2 which also didn't work ; building and booting > hypervizor is ok > > xl tools nope > > creating or starting a VM nope > > xl -v cr something hangs forever > > restarting xencommons hangs > > restarting xenconsoled hangs > > sigh Hmm... I think no amount of hand-holding is going to help you. In your situation I would suggest you to use various tools available on Linux to figure out why it hang. Tools like strace, ldd, gdb etc, but that's going to be rather technical and the finding isn't going to be useful or interesting to you in the long run. The hang is likely due to mismatch in various bits in the system. I think your best bet is to have a clean installation of Xen. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 101418: regressions - FAIL
flight 101418 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101418/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 5 xen-install fail REGR. vs. 101403 Tests which did not succeed, but are not blocking: 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 b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb baseline version: xen 38ab99b26bf4298a33105ec66f3f6a3f7e05a326 Last test of basis 101403 2016-10-12 15:03:35 Z0 days Testing same since 101418 2016-10-13 12:06:49 Z0 days1 attempts People who touched revisions under test: Ian Jackson Jan Beulich Lan Tianyu Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit b5283627de6b7ba2b8d75ecf1edf0a46bcd83edb Author: Wei Liu Date: Thu Oct 13 12:03:17 2016 +0100 tools: check liblzma in configure for rombios We upgraded ipxe in 38ab99b2 ("ipxe: update to new commit"). That version of ipxe requires liblzma to build. Check that in configure and document this in README. Signed-off-by: Wei Liu Acked-by: Ian Jackson commit de05bd965afcd08769c1e21d98ba7c2e4de7394b Author: Jan Beulich Date: Thu Oct 13 13:07:25 2016 +0200 x86emul: correct {,F}CMOV and F{,U}COMI{,P} emulation The FPU ones need to be executed with guest EFLAGS.{C,P,Z}F in context. We also can't exclude someone wanting to hide the feature from (32-bit) guests. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper commit 610b4eda2ce2b87cccbc8f61bdec01052e54fc66 Author: Lan Tianyu Date: Thu Oct 13 13:06:28 2016 +0200 keyhandler: rework process of nonirq keyhandler Keyhandler may run for a long time in serial port driver's timer handler on the large machine with a lot of physical cpus(e,g dump_timerq()) when serial port driver works in the poll mode(via the exception mechanism). If a timer handler runs a long time, it will block nmi_timer_fn() to feed NMI watchdog and cause Xen hypervisor panic. Inserting process_pending_softirqs() in timer handler will not help. when timer interrupt arrives, timer subsystem calls all expired timer handlers before programming next timer interrupt. There is no timer interrupt arriving to trigger timer softirq during run a timer handler. This patch is to fix the issue to make nonirq keyhandler run in tasklet when receive debug key from serial port. Signed-off-by: Lan Tianyu Reviewed-by: Jan Beulich (qemu changes not included) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.
Hi Jan / Wei, Took a while before i had the chance to fiddle some more to find the actual culprit. After analyzing the output of xl -v create somewhat more i came to the insight it was probably Qemu and not Xen causing the fault. As a test I just used a qemu-xen binary build with xen-4.6.0 booting up a guest with direct kernel boot mode on xen-unstable. And that old qemu binary works fine. After testing i can conclude, Jan was right, the bisection was a red herring, the problem is caused by some change in Qemu and not by something in the Xen tree. (strange thing is that for as far as i know i did a "make distclean" between every build (taking a lot of time), which should have pulled a fresh qemu-xen tree and therefor the bisection should have lead to a commit with a Config.mk hash change for qemu-xen version.) Will see if i can find some more time and bisect qemu and find the culprit. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] flask: add gcov_op check
On Thu, Oct 13, 2016 at 03:37:13PM +0100, Wei Liu wrote: > Signed-off-by: Wei Liu > --- > Cc: Daniel De Graaf > Cc: Konrad Rzeszutek Wilk Reviewed-by: Konrad Rzeszutek Wilk > --- > tools/flask/policy/modules/dom0.te | 2 +- > xen/xsm/flask/hooks.c | 3 +++ > xen/xsm/flask/policy/access_vectors | 2 ++ > 3 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/tools/flask/policy/modules/dom0.te > b/tools/flask/policy/modules/dom0.te > index 2d982d9..54c3572 100644 > --- a/tools/flask/policy/modules/dom0.te > +++ b/tools/flask/policy/modules/dom0.te > @@ -15,7 +15,7 @@ allow dom0_t xen_t:xen { > }; > allow dom0_t xen_t:xen2 { > resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol > - get_cpu_levelling_caps get_cpu_featureset livepatch_op > + get_cpu_levelling_caps get_cpu_featureset livepatch_op gcov_op > }; > > # Allow dom0 to use all XENVER_ subops that have checks. > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c > index 177c11f..040a251 100644 > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -822,6 +822,9 @@ static int flask_sysctl(int cmd) > case XEN_SYSCTL_livepatch_op: > return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, > XEN2__LIVEPATCH_OP, NULL); > +case XEN_SYSCTL_gcov_op: > +return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, > +XEN2__GCOV_OP, NULL); > > default: > return avc_unknown_permission("sysctl", cmd); > diff --git a/xen/xsm/flask/policy/access_vectors > b/xen/xsm/flask/policy/access_vectors > index 49c9a9e..92e6da9 100644 > --- a/xen/xsm/flask/policy/access_vectors > +++ b/xen/xsm/flask/policy/access_vectors > @@ -99,6 +99,8 @@ class xen2 > get_cpu_featureset > # XEN_SYSCTL_livepatch_op > livepatch_op > +# XEN_SYSCTL_gcov_op > +gcov_op > } > > # Classes domain and domain2 consist of operations that a domain performs on > -- > 2.1.4 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] flask: add gcov_op check
Signed-off-by: Wei Liu --- Cc: Daniel De Graaf Cc: Konrad Rzeszutek Wilk --- tools/flask/policy/modules/dom0.te | 2 +- xen/xsm/flask/hooks.c | 3 +++ xen/xsm/flask/policy/access_vectors | 2 ++ 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te index 2d982d9..54c3572 100644 --- a/tools/flask/policy/modules/dom0.te +++ b/tools/flask/policy/modules/dom0.te @@ -15,7 +15,7 @@ allow dom0_t xen_t:xen { }; allow dom0_t xen_t:xen2 { resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol - get_cpu_levelling_caps get_cpu_featureset livepatch_op + get_cpu_levelling_caps get_cpu_featureset livepatch_op gcov_op }; # Allow dom0 to use all XENVER_ subops that have checks. diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c index 177c11f..040a251 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -822,6 +822,9 @@ static int flask_sysctl(int cmd) case XEN_SYSCTL_livepatch_op: return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, XEN2__LIVEPATCH_OP, NULL); +case XEN_SYSCTL_gcov_op: +return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2, +XEN2__GCOV_OP, NULL); default: return avc_unknown_permission("sysctl", cmd); diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors index 49c9a9e..92e6da9 100644 --- a/xen/xsm/flask/policy/access_vectors +++ b/xen/xsm/flask/policy/access_vectors @@ -99,6 +99,8 @@ class xen2 get_cpu_featureset # XEN_SYSCTL_livepatch_op livepatch_op +# XEN_SYSCTL_gcov_op +gcov_op } # Classes domain and domain2 consist of operations that a domain performs on -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1 net] xen-netback: fix guest Rx stall detection (after guest Rx refactor)
From: David Vrabel Date: Tue, 11 Oct 2016 16:48:27 +0100 > If a VIF has been ready for rx_stall_timeout (60s by default) and an > Rx ring is drained of all requests an Rx stall will be incorrectly > detected. When this occurs and the guest Rx queue is empty, the Rx > ring's event index will not be set and the frontend will not raise an > event when new requests are placed on the ring, permanently stalling > the VIF. > > This is a regression introduced by eb1723a29b9a7 (xen-netback: > refactor guest rx). > > Fix this by reinstating the setting of queue->last_rx_time when > placing a packet onto the guest Rx ring. > > Signed-off-by: David Vrabel Applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 101411: regressions - FAIL
flight 101411 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/101411/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 7 host-ping-check-xen fail REGR. vs. 101365 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 101365 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 101365 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101365 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101365 test-amd64-amd64-xl-rtds 9 debian-install fail like 101365 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 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-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass version targeted for testing: qemuuc264a8807299852fc45562768ae60ccc886cea91 baseline version: qemuu627eae7d729277c84f8e0ac07a8caab39c92c38d Last test of basis 101365 2016-10-11 02:21:11 Z2 days Failing since101395 2016-10-12 10:15:00 Z1 days2 attempts Testing same since 101411 2016-10-13 02:15:32 Z0 days1 attempts People who touched revisions under test: Daniel P. Berrange Eric Blake Gerd Hoffmann Hans de Goede LluÃs Vilanova P J P Peter Maydell Stefan Hajnoczi Vijay Kumar B Vijay Kumar B. jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl
Re: [Xen-devel] [PATCH net] xen-netback: (re-)create a debugfs node for hash information
From: Paul Durrant Date: Mon, 10 Oct 2016 09:30:53 +0100 > From: Paul Durrant > > It is useful to be able to see the hash configuration when running tests. > This patch adds a debugfs node for that purpose. > > The original version of this patch (commit c0c64c152389) was reverted due > to build failures caused by a conflict with commit 0364a8824c02 > ("xen-netback: switch to threaded irq for control ring"). This new version > of the patch is nearly identical to the original, the only difference > being that creation of the debugfs node is predicated on 'ctrl_irq' being > non-zero rather then the now non-existent 'ctrl_task'. > > Signed-off-by: Paul Durrant Applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] x86/vmx: Print the problematic MSR if a vmentry fails
Sample error looks like: (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading (entry 13). (XEN) msr 068a, val 1fff80102af0, (mbz 0) (XEN) * VMCS Area ** Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jun Nakajima CC: Kevin Tian v2: * const, %lu, remove some commas, boundary check --- xen/arch/x86/hvm/vmx/vmx.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index b9102ce..b406989 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3104,8 +3104,23 @@ static void vmx_failed_vmentry(unsigned int exit_reason, printk("caused by invalid guest state (%ld).\n", exit_qualification); break; case EXIT_REASON_MSR_LOADING: -printk("caused by MSR entry %ld loading.\n", exit_qualification); +{ +unsigned long idx = exit_qualification - 1; +const struct vmx_msr_entry *msr; + +printk("caused by MSR loading (entry %lu).\n", idx); + +if ( idx >= (PAGE_SIZE / sizeof(*msr)) ) +printk(" Entry out of range\n"); +else +{ +msr = &curr->arch.hvm_vmx.msr_area[idx]; + +printk(" msr %08x val %016"PRIx64" (mbz %#x)\n", + msr->index, msr->data, msr->mbz); +} break; +} case EXIT_REASON_MCE_DURING_VMENTRY: printk("caused by machine check.\n"); HVMTRACE_0D(MCE); -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] x86/vmx: Reduce the verbosity of the vmentry failure error reporting
Identify the affected vcpu at the start of the message. While tweaking this area, add extra newlines between cases. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jun Nakajima CC: Kevin Tian v2: * %lu --- xen/arch/x86/hvm/vmx/vmx.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index b406989..db12cdb 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3096,19 +3096,20 @@ static void vmx_failed_vmentry(unsigned int exit_reason, unsigned long exit_qualification; struct vcpu *curr = current; -printk("Failed vm entry (exit reason %#x) ", exit_reason); +printk("%pv vmentry failure (reason %#x): ", curr, exit_reason); __vmread(EXIT_QUALIFICATION, &exit_qualification); switch ( failed_vmentry_reason ) { case EXIT_REASON_INVALID_GUEST_STATE: -printk("caused by invalid guest state (%ld).\n", exit_qualification); +printk("Invalid guest state (%lu)\n", exit_qualification); break; + case EXIT_REASON_MSR_LOADING: { unsigned long idx = exit_qualification - 1; const struct vmx_msr_entry *msr; -printk("caused by MSR loading (entry %lu).\n", idx); +printk("MSR loading (entry %lu)\n", idx); if ( idx >= (PAGE_SIZE / sizeof(*msr)) ) printk(" Entry out of range\n"); @@ -3121,13 +3122,15 @@ static void vmx_failed_vmentry(unsigned int exit_reason, } break; } + case EXIT_REASON_MCE_DURING_VMENTRY: -printk("caused by machine check.\n"); +printk("MCE\n"); HVMTRACE_0D(MCE); /* Already handled. */ break; + default: -printk("reason not known yet!"); +printk("Unknown\n"); break; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c > index 93f107c..2f64bb5 100644 > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > > long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > { > @@ -395,6 +396,13 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) > u_sysctl) > } > break; > > +#ifdef CONFIG_GCOV > +case XEN_SYSCTL_gcov_op: > +ret = sysctl_gcov_op(&op->u.gcov_op); > +copyback = 1; > +break; > +#endif Should there be an XSM entry in flask_sysctl for this? And also in flask/policy/access_vectors And in tools/flask/policy/policy.conf Maybe that should be a seperate patch? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support
On Thu, Oct 13, 2016 at 09:38:45AM -0400, Konrad Rzeszutek Wilk wrote: > > diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c > > index 93f107c..2f64bb5 100644 > > --- a/xen/common/sysctl.c > > +++ b/xen/common/sysctl.c > > @@ -28,6 +28,7 @@ > > #include > > #include > > #include > > +#include > > > > long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > > { > > @@ -395,6 +396,13 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) > > u_sysctl) > > } > > break; > > > > +#ifdef CONFIG_GCOV > > +case XEN_SYSCTL_gcov_op: > > +ret = sysctl_gcov_op(&op->u.gcov_op); > > +copyback = 1; > > +break; > > +#endif > > Should there be an XSM entry in flask_sysctl for this? > And also in flask/policy/access_vectors > > And in tools/flask/policy/policy.conf > > Maybe that should be a seperate patch? Yes. That's planned. Didn't want to cram in too much stuff in one single patch. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 for-4.8] libelf: fix symtab/strtab loading for 32bit domains
On 13/10/16 13:48, Roger Pau Monne wrote: > diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h > index 90bd8cb..70abbaf 100644 > --- a/xen/include/xen/libelf.h > +++ b/xen/include/xen/libelf.h > @@ -432,6 +432,16 @@ struct elf_dom_parms { > uint64_t virt_kend; > }; > > +/* Number of section header needed in order to fit the SYMTAB and STRTAB. */ > +#define ELF_BSDSYM_SECTIONS 3 > +struct elf_sym_header { > +uint32_t size; > +struct { > +elf_ehdr header; > +elf_shdr section[ELF_BSDSYM_SECTIONS]; > +} elf_header; > +} __attribute__((packed)); __packed please, rather than opencoding it. Also, should be between struct and the structure name. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: honor MXCSR.MM
On 13/10/16 13:57, Jan Beulich wrote: > Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory > operands") didn't consider a specific AMD mode: Mis-alignment #GP > faults can be masked on some of their hardware. > > Signed-off-by: Jan Beulich This highlights that the following CPUID dependency change is also required diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py index 33e68eb..e803654 100755 --- a/xen/tools/gen-cpuid.py +++ b/xen/tools/gen-cpuid.py @@ -185,8 +185,9 @@ def crunch_numbers(state): # the first place. APIC: [X2APIC], -# AMD built MMXExtentions and 3DNow as extentions to MMX. -MMX: [MMXEXT, _3DNOW], +# AMD built MMXExtentions, 3DNow and SSE Misalignment as extensions to +# MMX. +MMX: [MMXEXT, _3DNOW, MISALIGNSSE], # The FXSAVE/FXRSTOR instructions were introduced into hardware before # SSE, which is why they behave differently based on %CR4.OSFXSAVE and > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -446,6 +446,9 @@ typedef union { > #define EFLG_PF (1<<2) > #define EFLG_CF (1<<0) > > +/* MXCSR bit definitions. */ > +#define MXCSR_MM (1U << 17) > + > /* Exception definitions. */ > #define EXC_DE 0 > #define EXC_DB 1 > @@ -1253,6 +1256,7 @@ static bool_t vcpu_has( > > #define vcpu_has_clflush() vcpu_has( 1, EDX, 19, ctxt, ops) > #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX, 5, ctxt, ops) > +#define vcpu_has_misalignsse() vcpu_has(0x8001, ECX, 7, ctxt, ops) > #define vcpu_has_bmi1() vcpu_has(0x0007, EBX, 3, ctxt, ops) > #define vcpu_has_hle() vcpu_has(0x0007, EBX, 4, ctxt, ops) > #define vcpu_has_rtm() vcpu_has(0x0007, EBX, 11, ctxt, ops) > @@ -4675,7 +4679,13 @@ x86_emulate( > ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4; > if ( ea.type == OP_MEM ) > { > -generate_exception_if((b >= 0x28) && > +uint32_t mxcsr = 0; > + > +if ( b < 0x28 ) > +mxcsr = MXCSR_MM; > +else if ( vcpu_has_misalignsse() ) > +asm ( "stmxcsr %0" : "=m" (mxcsr) ); > +generate_exception_if(!(mxcsr & MXCSR_MM) && >!is_aligned(ea.mem.seg, ea.mem.off, > ea.bytes, >ctxt, ops), >EXC_GP, 0); > @@ -4955,7 +4965,13 @@ x86_emulate( > } > if ( ea.type == OP_MEM ) > { > -generate_exception_if((vex.pfx == vex_66) && > +uint32_t mxcsr = 0; > + > +if ( vex.pfx != vex_66 ) > +mxcsr = MXCSR_MM; > +else if ( vcpu_has_misalignsse() ) > +asm ( "stmxcsr %0" : "=m" (mxcsr) ); > +generate_exception_if(!(mxcsr & MXCSR_MM) && >!is_aligned(ea.mem.seg, ea.mem.off, > ea.bytes, >ctxt, ops), >EXC_GP, 0); According to the docs, we should also be possibly raising #AC here. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] docs: Credit1 feature document.
On Thu, 2016-10-13 at 12:47 +0100, Andrew Cooper wrote: > On 13/10/16 12:02, Dario Faggioli wrote: > > > > diff --git a/docs/features/credit.pandoc > > b/docs/features/credit.pandoc > > new file mode 100644 > > index 000..fed0da2 > > --- /dev/null > > +++ b/docs/features/credit.pandoc > > Simply "Credit" as a top level feature isn't very descriptive. Can > you > see about working scheduler somewhere into the name? > Yep, I wasn't sure whether or not to do that. Re-thinking things, I agree that'd be better. I'll do. > > @@ -0,0 +1,99 @@ > > +% Credit > > +% Revision 1 > > + > > +\clearpage > > + > > +# Basics > > + --- > > - > > + Status: e.g. **Supported** > > + > > +Architecture(s): e.g. x86, arm > > + > > + Component: e.g. Hypervisor > > + --- > > - > > You should drop the e.g.'s. > Which I was sure I'd have done... sorry. > In cases like this where it really is just > a software algorithm, I would suggest setting the architecture to > all, > or omitting the line entirely. > Omitting the line is what I also was considering myself. Again, will do. > > +# Overview > > + > > +Credit (also known as Credit1) is the default virtual CPU (vCPU) > > scheduler > > +of the Xen hypervisor. The job of an hypervisor's scheduler is to > > decide, > > +among all the various vCPUs of the various virtual machines, which > > ones > > +should execute on the host's physical CPUs (pCPUs), at any given > > point in > > +time. > > A lot of this is generic to all schedulers. > Not really. Well, sure some is, but, at the end, this period is pretty much the only one that is present, identical to itself, in all the three documents (and I certainly can see about shortening or removing it, if we don't want that). And in fact, the rest... > I wonder whether it might be better to have a schedulers meta-feature > doc which deals with the common scheduler parts, including > interactions > on the Xen command line, xl, etc. > ...may look similar, but they're subtle differences spread around. And the more subtle those differences, the higher the amount of cross- referencing between different documents would be, making it more difficult to read and understand what the situation is for one specific scheduler. xl interface is a good example: sub-commands are very similar, but then the scheduling parameters are different for each scheduler. The way in which you create a cpupool is the same (modulo the name=""), but doesn't necessarily have to be, e.g., if we start allowing specifing some of the global parameters of the scheduler on the command line (e.g., "create a Credit cpupool, but with timeslice=10"). Not possible right now, but doable, and even convenient (I've already have plans for that :-P). So, FWIW, I would stick with different documents. > > +Once the system is live, for creating a cpupool with Credit as its > > +scheduler, either compile a cpupool configuration file, as > > described > > +in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in > > +`tools/examples/cpupool`), or use just `xl` directly: > > I should see about ensuring that cross-references work with the > HTML-generated versions of these docs. You might be able to get away > with just putting in a plain hyperlink here. > I thought about that, but then ended up following suit from your docs/feature/migration.pandoc. I'll turn this in links if that's what you think is best. Personally, I 's say it makes the _text_ document a bit less readable, but I guess the version we care about is the _HTML_ one? Anyway, I'm basically ok with anything. :-) Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support
On Thu, Oct 13, 2016 at 07:05:21AM -0600, Jan Beulich wrote: > >>> On 13.10.16 at 14:04, wrote: > > A new sysctl interface for passing gcov data back to userspace. The new > > interface uses a customised record file format. The new sysctl reuses > > original sysctl number but renames the op to gcov_op. > > > > Formats starting from gcc version 3.4 are supported. The code is > > rewritten so that a new format can be easily added in the future. > > Version specific code is grouped into different files. The format one > > needs to use can be picked via Kconfig. The default format is the newest > > one. > > > > Userspace programs to handle extracted data will come in a later patch. > > > > Signed-off-by: Wei Liu > > Acked-by: Jan Beulich > with one suggestion and one further adjustment: > > > --- /dev/null > > +++ b/xen/common/gcov/gcc_4_9.c > > @@ -0,0 +1,35 @@ > > +/* > > + * This code provides functions to handle gcc's profiling data format > > + * introduced with gcc 4.7. > > + * > > + * This file is based heavily on gcc_3_4.c file. > > I think this is not really applicable here and in gcc_5.c. OK. I will delete this. > > > + * > > + * For a better understanding, refer to gcc source: > > + * gcc/gcov-io.h > > + * libgcc/libgcov.c > > + * > > + * Uses gcc-internal data definitions. > > + * > > + * Imported from Linux and modified for Xen by > > + *Wei Liu > > + */ > > + > > +#include "gcov.h" > > + > > +#if !(GCC_VERSION >= 40900 && GCC_VERSION < 50100) > > This wants to be 5 now on the right side, afaict. > Right. I missed this one place. I will fix it. Thanks for your careful review. Wei. > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 for-4.8] libelf: fix symtab/strtab loading for 32bit domains
>>> On 13.10.16 at 14:48, wrote: > @@ -174,8 +171,8 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t > pstart) > /* Space to store the size of the elf image */ > sz = sizeof(uint32_t); > > -/* Space for the elf and elf section headers */ > -sz += elf_uval(elf, elf->ehdr, e_ehsize) + > +/* Space for the elf header and elf section headers */ > +sz += offsetof(struct elf_sym_header, elf_header.section) + >ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize); You've retained the inconsistency which I had asked to eliminate when commenting on v2. > --- a/xen/include/xen/libelf.h > +++ b/xen/include/xen/libelf.h > @@ -432,6 +432,16 @@ struct elf_dom_parms { > uint64_t virt_kend; > }; > > +/* Number of section header needed in order to fit the SYMTAB and STRTAB. */ > +#define ELF_BSDSYM_SECTIONS 3 > +struct elf_sym_header { > +uint32_t size; > +struct { > +elf_ehdr header; > +elf_shdr section[ELF_BSDSYM_SECTIONS]; > +} elf_header; > +} __attribute__((packed)); This doesn't belong here - it's still an internal structure. At most this might go into libelf-private.h, but I think best would be to keep in the C file, just moving it up (and out of any function) there. And if you were to move it into _any_ header, the comment would need adjustment to make clear what part of the loader this actually is relevant for. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/2] gcov: provide the capability to select gcov format automatically
>>> On 13.10.16 at 14:04, wrote: > And make it the default in Kconfig. > > Signed-off-by: Wei Liu > --- > v4: dropped Jan's ack Feel free to re-instate. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support
>>> On 13.10.16 at 14:04, wrote: > A new sysctl interface for passing gcov data back to userspace. The new > interface uses a customised record file format. The new sysctl reuses > original sysctl number but renames the op to gcov_op. > > Formats starting from gcc version 3.4 are supported. The code is > rewritten so that a new format can be easily added in the future. > Version specific code is grouped into different files. The format one > needs to use can be picked via Kconfig. The default format is the newest > one. > > Userspace programs to handle extracted data will come in a later patch. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich with one suggestion and one further adjustment: > --- /dev/null > +++ b/xen/common/gcov/gcc_4_9.c > @@ -0,0 +1,35 @@ > +/* > + * This code provides functions to handle gcc's profiling data format > + * introduced with gcc 4.7. > + * > + * This file is based heavily on gcc_3_4.c file. I think this is not really applicable here and in gcc_5.c. > + * > + * For a better understanding, refer to gcc source: > + * gcc/gcov-io.h > + * libgcc/libgcov.c > + * > + * Uses gcc-internal data definitions. > + * > + * Imported from Linux and modified for Xen by > + *Wei Liu > + */ > + > +#include "gcov.h" > + > +#if !(GCC_VERSION >= 40900 && GCC_VERSION < 50100) This wants to be 5 now on the right side, afaict. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86emul: honor MXCSR.MM
Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory operands") didn't consider a specific AMD mode: Mis-alignment #GP faults can be masked on some of their hardware. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -446,6 +446,9 @@ typedef union { #define EFLG_PF (1<<2) #define EFLG_CF (1<<0) +/* MXCSR bit definitions. */ +#define MXCSR_MM (1U << 17) + /* Exception definitions. */ #define EXC_DE 0 #define EXC_DB 1 @@ -1253,6 +1256,7 @@ static bool_t vcpu_has( #define vcpu_has_clflush() vcpu_has( 1, EDX, 19, ctxt, ops) #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX, 5, ctxt, ops) +#define vcpu_has_misalignsse() vcpu_has(0x8001, ECX, 7, ctxt, ops) #define vcpu_has_bmi1() vcpu_has(0x0007, EBX, 3, ctxt, ops) #define vcpu_has_hle() vcpu_has(0x0007, EBX, 4, ctxt, ops) #define vcpu_has_rtm() vcpu_has(0x0007, EBX, 11, ctxt, ops) @@ -4675,7 +4679,13 @@ x86_emulate( ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4; if ( ea.type == OP_MEM ) { -generate_exception_if((b >= 0x28) && +uint32_t mxcsr = 0; + +if ( b < 0x28 ) +mxcsr = MXCSR_MM; +else if ( vcpu_has_misalignsse() ) +asm ( "stmxcsr %0" : "=m" (mxcsr) ); +generate_exception_if(!(mxcsr & MXCSR_MM) && !is_aligned(ea.mem.seg, ea.mem.off, ea.bytes, ctxt, ops), EXC_GP, 0); @@ -4955,7 +4965,13 @@ x86_emulate( } if ( ea.type == OP_MEM ) { -generate_exception_if((vex.pfx == vex_66) && +uint32_t mxcsr = 0; + +if ( vex.pfx != vex_66 ) +mxcsr = MXCSR_MM; +else if ( vcpu_has_misalignsse() ) +asm ( "stmxcsr %0" : "=m" (mxcsr) ); +generate_exception_if(!(mxcsr & MXCSR_MM) && !is_aligned(ea.mem.seg, ea.mem.off, ea.bytes, ctxt, ops), EXC_GP, 0); x86emul: honor MXCSR.MM Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory operands") didn't consider a specific AMD mode: Mis-alignment #GP faults can be masked on some of their hardware. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -446,6 +446,9 @@ typedef union { #define EFLG_PF (1<<2) #define EFLG_CF (1<<0) +/* MXCSR bit definitions. */ +#define MXCSR_MM (1U << 17) + /* Exception definitions. */ #define EXC_DE 0 #define EXC_DB 1 @@ -1253,6 +1256,7 @@ static bool_t vcpu_has( #define vcpu_has_clflush() vcpu_has( 1, EDX, 19, ctxt, ops) #define vcpu_has_lzcnt() vcpu_has(0x8001, ECX, 5, ctxt, ops) +#define vcpu_has_misalignsse() vcpu_has(0x8001, ECX, 7, ctxt, ops) #define vcpu_has_bmi1() vcpu_has(0x0007, EBX, 3, ctxt, ops) #define vcpu_has_hle() vcpu_has(0x0007, EBX, 4, ctxt, ops) #define vcpu_has_rtm() vcpu_has(0x0007, EBX, 11, ctxt, ops) @@ -4675,7 +4679,13 @@ x86_emulate( ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4; if ( ea.type == OP_MEM ) { -generate_exception_if((b >= 0x28) && +uint32_t mxcsr = 0; + +if ( b < 0x28 ) +mxcsr = MXCSR_MM; +else if ( vcpu_has_misalignsse() ) +asm ( "stmxcsr %0" : "=m" (mxcsr) ); +generate_exception_if(!(mxcsr & MXCSR_MM) && !is_aligned(ea.mem.seg, ea.mem.off, ea.bytes, ctxt, ops), EXC_GP, 0); @@ -4955,7 +4965,13 @@ x86_emulate( } if ( ea.type == OP_MEM ) { -generate_exception_if((vex.pfx == vex_66) && +uint32_t mxcsr = 0; + +if ( vex.pfx != vex_66 ) +mxcsr = MXCSR_MM; +else if ( vcpu_has_misalignsse() ) +asm ( "stmxcsr %0" : "=m" (mxcsr) ); +generate_exception_if(!(mxcsr & MXCSR_MM) && !is_aligned(ea.mem.seg, ea.mem.off, ea.bytes, ctxt, ops), EXC_GP, 0); ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 for-4.8] libelf: fix symtab/strtab loading for 32bit domains
Commit ed04ca introduced a bug in the symtab/strtab loading for 32bit guests, that corrupted the section headers array due to the padding introduced by the elf_shdr union. The Elf section header array on 32bit should be accessible as an array of Elf32_Shdr elements, and the union with Elf64_Shdr done in elf_shdr was breaking this due to size differences between Elf32_Shdr and Elf64_Shdr. Fix this by copying each section header one by one, and using the proper size depending on the bitness of the guest kernel. While there, also fix elf_parse_bsdsyms so that it takes into account the size of the elf_ehdr struct instead of the native Elf header size. Reported-by: Brian Marcotte Signed-off-by: Roger Pau Monné Acked-by: Ian Jackson --- Cc: Brian Marcotte Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- Should be backported to Xen 4.7 stable branch. --- Changes since v2: - Use offsetof to correctly account for the memory used by the elf header. Changes since v1: - No need to calculate shdr_size again, it's already fetched from the original elf header. - Remove shdr variable. - Use offsetof instead of subtracting two sizeofs. - Fix elf_parse_bsdsyms so that it takes into account the size of elf_ehdr instead of the size of the native elf header. --- xen/common/libelf/libelf-loader.c | 44 --- xen/include/xen/libelf.h | 10 + 2 files changed, 37 insertions(+), 17 deletions(-) diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c index 2626a40..3a83d61 100644 --- a/xen/common/libelf/libelf-loader.c +++ b/xen/common/libelf/libelf-loader.c @@ -21,9 +21,6 @@ #include "libelf-private.h" -/* Number of section header needed in order to fit the SYMTAB and STRTAB. */ -#define ELF_BSDSYM_SECTIONS 3 - /* */ elf_errorstatus elf_init(struct elf_binary *elf, const char *image_input, size_t size) @@ -174,8 +171,8 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t pstart) /* Space to store the size of the elf image */ sz = sizeof(uint32_t); -/* Space for the elf and elf section headers */ -sz += elf_uval(elf, elf->ehdr, e_ehsize) + +/* Space for the elf header and elf section headers */ +sz += offsetof(struct elf_sym_header, elf_header.section) + ELF_BSDSYM_SECTIONS * elf_uval(elf, elf->ehdr, e_shentsize); sz = elf_round_up(elf, sz); @@ -253,18 +250,11 @@ static void elf_load_bsdsyms(struct elf_binary *elf) * strtab, so we only need three section headers in our fake ELF * header (first section header is always the undefined section). */ -struct { -uint32_t size; -struct { -elf_ehdr header; -elf_shdr section[ELF_BSDSYM_SECTIONS]; -} __attribute__((packed)) elf_header; -} __attribute__((packed)) header; - +struct elf_sym_header header; ELF_HANDLE_DECL(elf_ehdr) header_handle; -unsigned long shdr_size; +unsigned long shdr_size, ehdr_size; ELF_HANDLE_DECL(elf_shdr) section_handle; -unsigned int link, rc; +unsigned int link, rc, i; elf_ptrval header_base; elf_ptrval elf_header_base; elf_ptrval symtab_base; @@ -394,15 +384,35 @@ do { \ header.size = strtab_base + elf_uval(elf, section_handle, sh_size) - elf_header_base; -/* Load the headers. */ +/* Load the size plus elf header. */ +ehdr_size = offsetof(typeof(header), elf_header.section); rc = elf_load_image(elf, header_base, ELF_REALPTR2PTRVAL(&header), -sizeof(header), sizeof(header)); +ehdr_size, ehdr_size); if ( rc != 0 ) { elf_mark_broken(elf, "unable to load ELF headers into guest memory"); return; } +/* + * Load the section headers. + * + * NB: this _must_ be done one by one, and taking the bitness into account, + * so that the guest can treat this as an array of type Elf{32/64}_Shdr. + */ +for ( i = 0; i < ELF_BSDSYM_SECTIONS; i++ ) +{ +rc = elf_load_image(elf, header_base + ehdr_size + shdr_size * i, +ELF_REALPTR2PTRVAL(&header.elf_header.section[i]), +shdr_size, shdr_size); +if ( rc != 0 ) +{ +elf_mark_broken(elf, +"unable to load ELF section header into guest memory"); +return; +} +} + /* Remove permissions from elf_memcpy_safe. */ elf->caller_xdest_base = NULL; elf->caller_xdest_size = 0; diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h index 90bd8cb..70abbaf 100644 --- a/xen/include/xen/libelf.h +++ b/xen/include/xen/libelf.h @@
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On Thu, Oct 13, 2016 at 01:44:28PM +0100, Dario Faggioli wrote: > On Thu, 2016-10-13 at 12:28 +0100, Andrew Cooper wrote: > > On 13/10/16 12:01, Dario Faggioli wrote: > > > "Just" as per the subject, I wrote feature documents for (almost) > > > all our > > > schedulers. No big deal, I'd say, apart from the fact that I'm > > > declaring > > > Credit2 **Supperted**, instead of experimental. > > > > Supperted? That's like supported right? ;p > > > Nah, 'supperted' is the new 'supported', didn't you know? :-P > > > It is fine for you to propose that a feature should be upgraded to > > supported, and this is probably the best way to formally do so. > > > > However, final agreement of a feature becoming supported should > > include > > input from the security team. (At the end of the day, it is us with > > extra work if the feature isn't up to scratch.) > > > Ok, so, if that's the case, what's the process: resend (this patch) -- > or some other kind of formal request-- with secur...@xenproject.org > Cc-ed? > If you want these to be applied more quickly the best thing to do is to leave the status experimental and later send another patch with security@ CC'ed to change the status. Wei. > Regards, > Dario > -- > <> (Raistlin Majere) > - > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On Thu, 2016-10-13 at 12:28 +0100, Andrew Cooper wrote: > On 13/10/16 12:01, Dario Faggioli wrote: > > "Just" as per the subject, I wrote feature documents for (almost) > > all our > > schedulers. No big deal, I'd say, apart from the fact that I'm > > declaring > > Credit2 **Supperted**, instead of experimental. > > Supperted? That's like supported right? ;p > Nah, 'supperted' is the new 'supported', didn't you know? :-P > It is fine for you to propose that a feature should be upgraded to > supported, and this is probably the best way to formally do so. > > However, final agreement of a feature becoming supported should > include > input from the security team. (At the end of the day, it is us with > extra work if the feature isn't up to scratch.) > Ok, so, if that's the case, what's the process: resend (this patch) -- or some other kind of formal request-- with secur...@xenproject.org Cc-ed? Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] Xen 4.2.4 and 4.6 hangs
BCC'ing xen-devel, since this is clearly a xen-users question at the moment. On Mon, Oct 10, 2016 at 9:52 PM, Soumendu Satapathy wrote: > Hi there, > > > > I am trying to install and boot xen. I followed the following procedure. > There was no errors while installation. But when I select the grub entry it > hangs. > > > > The following is the steps I followed. > > yum -y install centos-release-xen > yum --enablerepo=centos-virt-xen -y update kernel > yum --enablerepo=centos-virt-xen -y install xen > /bin/grub-bootxen.sh > reboot > xl info > > > > > > I also tried to compile the xen4.2.4 source code . I did the following.. > > > > $ ./configure > > $ make world > > $ make install > > > > After the above steps completed without errors, I added an entry to the > grub.cfg and booted but like the above it hangs. But I am able to select the > linux kernel and it boots properly. In both I get the following and then the > xen hangs… > > > > Loading Xen 4.6 > > Loading Linux > > Loading initial ramdisk … > > > > > > > > Is there any steps we are missing? It's not 100% clear here -- did you get the same result (Grub says it's booting Xen then hangs) for both the CentOS packages and your own build? It looks like you got grub to attempt to load Xen, so as far as that goes it looks like you did OK. But there's not nearly enough information in this report to move forward, and it looks like you've actively removed some important information. :-) What Linux kernel version are you using? What version of CentOS, and what Xen packages? What hardware is it running on? What does your grub config look like? Do you have a serial console attached? Are you using encryted (LUKS) disks? Thanks, -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/2] gcov: provide the capability to select gcov format automatically
And make it the default in Kconfig. Signed-off-by: Wei Liu --- v4: dropped Jan's ack Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- xen/Kconfig.debug| 9 - xen/common/gcov/Makefile | 4 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug index b19b357..8139564 100644 --- a/xen/Kconfig.debug +++ b/xen/Kconfig.debug @@ -39,10 +39,17 @@ config GCOV choice prompt "Specify Gcov format" depends on GCOV - default GCOV_FORMAT_5 + default GCOV_FORMAT_AUTODETECT ---help--- The gcov format is determined by gcc version. + If unsure, choose "Autodetect". + +config GCOV_FORMAT_AUTODETECT + bool "Autodetect" + ---help--- + Automatically select gcov format based on gcc version. + config GCOV_FORMAT_5 bool "GCC 5 format" ---help--- diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile index 6a304ab..1b61357 100644 --- a/xen/common/gcov/Makefile +++ b/xen/common/gcov/Makefile @@ -3,3 +3,7 @@ obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o obj-$(CONFIG_GCOV_FORMAT_4_9) += gcc_4_9.o obj-$(CONFIG_GCOV_FORMAT_5) += gcc_5.o +obj-$(CONFIG_GCOV_FORMAT_AUTODETECT) += $(call cc-ifversion,lt,0x040700, \ + gcc_3_4.o, $(call cc-ifversion,lt,0x040900, \ + gcc_4_7.o, $(call cc-ifversion,lt,0x05, \ + gcc_4_9.o, gcc_5.o))) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/2] gcov: add new interface and new formats support
A new sysctl interface for passing gcov data back to userspace. The new interface uses a customised record file format. The new sysctl reuses original sysctl number but renames the op to gcov_op. Formats starting from gcc version 3.4 are supported. The code is rewritten so that a new format can be easily added in the future. Version specific code is grouped into different files. The format one needs to use can be picked via Kconfig. The default format is the newest one. Userspace programs to handle extracted data will come in a later patch. Signed-off-by: Wei Liu --- v4: 1. gcov conflicts with livepatch in Kconfig. 2. Finer grain formats v3: 1. Check gcc version in gcc_*.c files. 2. Eliminate u32 / u64. 3. Mark __gcov_init as __init. 4. Fix a rebase error in v2. 5. Some other cosmetic fixes. v2: 1. Use tab in Kconfig and indent help text properly. 2. Bump XEN_SYSCTL_INTERFACE_VERSION. 3. Fix cosmetic issues. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu --- xen/Kconfig.debug | 39 - xen/common/gcov/Makefile| 5 + xen/common/gcov/gcc_3_4.c | 367 xen/common/gcov/gcc_4_7.c | 204 xen/common/gcov/gcc_4_9.c | 35 + xen/common/gcov/gcc_5.c | 35 + xen/common/gcov/gcov.c | 257 +++ xen/common/gcov/gcov.h | 40 + xen/common/gcov/gcov_base.c | 60 xen/common/sysctl.c | 8 + xen/include/public/sysctl.h | 39 - xen/include/xen/gcov.h | 9 ++ 12 files changed, 1091 insertions(+), 7 deletions(-) create mode 100644 xen/common/gcov/gcc_3_4.c create mode 100644 xen/common/gcov/gcc_4_7.c create mode 100644 xen/common/gcov/gcc_4_9.c create mode 100644 xen/common/gcov/gcc_5.c create mode 100644 xen/common/gcov/gcov.c create mode 100644 xen/common/gcov/gcov.h create mode 100644 xen/common/gcov/gcov_base.c create mode 100644 xen/include/xen/gcov.h diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug index ef863dc..b19b357 100644 --- a/xen/Kconfig.debug +++ b/xen/Kconfig.debug @@ -30,16 +30,45 @@ config FRAME_POINTER config GCOV bool "Gcov Support" - depends on BROKEN + depends on !LIVEPATCH ---help--- Enable gcov (a test coverage program in GCC) support. - Currently the data structure and hypercall interface are tied - to GCC 3.4 gcov format. You need to have a version of GCC - that is compatible with that format to make gcov work. - If unsure, say N here. +choice + prompt "Specify Gcov format" + depends on GCOV + default GCOV_FORMAT_5 + ---help--- + The gcov format is determined by gcc version. + +config GCOV_FORMAT_5 + bool "GCC 5 format" + ---help--- + Select this option to use the format specified in GCC 5. + Works in gcc version range [5, ...). + +config GCOV_FORMAT_4_9 + bool "GCC 4.9 format" + ---help--- + Select this option to use the format specified in GCC 4.9. + Works in gcc version range [4.9, 5). + +config GCOV_FORMAT_4_7 + bool "GCC 4.7 format" + ---help--- + Select this option to use the format specified in GCC 4.7. + Works in gcc version range [4.7, 4.9). + +config GCOV_FORMAT_3_4 + bool "GCC 3.4 format" + ---help--- + Select this option to use the format specified in GCC 3.4. + Works in gcc version range [3.4, 4.7). + +endchoice + config LOCK_PROFILE bool "Lock Profiling" ---help--- diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile index e69de29..6a304ab 100644 --- a/xen/common/gcov/Makefile +++ b/xen/common/gcov/Makefile @@ -0,0 +1,5 @@ +obj-y += gcov_base.o gcov.o +obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o +obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o +obj-$(CONFIG_GCOV_FORMAT_4_9) += gcc_4_9.o +obj-$(CONFIG_GCOV_FORMAT_5) += gcc_5.o diff --git a/xen/common/gcov/gcc_3_4.c b/xen/common/gcov/gcc_3_4.c new file mode 100644 index 000..3631f4b --- /dev/null +++ b/xen/common/gcov/gcc_3_4.c @@ -0,0 +1,367 @@ +/* + * This code provides functions to handle gcc's profiling data format + * introduced with gcc 3.4. Future versions of gcc may change the gcov + * format (as happened before), so all format-specific information needs + * to be kept modular and easily exchangeable. + * + * This file is based on gcc-internal definitions. Functions and data + * structures are defined to be compatible with gcc counterparts. + * For a better understanding, refer to gcc source: gcc/gcov-io.h. + * + *Copyright IBM Corp. 2009 + *Author(s): Peter Oberparleiter + * + *Uses gcc-internal data definitions. + * + * Imported from Linux and modified for Xen by + *Wei Liu + */ + + +#include + +#include "gcov.h" + +#if !(GCC_VERSION >= 30400 && GCC_VERSION <
[Xen-devel] [PATCH v4 0/2] Rework gcov support in Xen
Only sending out two patches. This series can be found at: git://xenbits.xen.org/people/liuw/xen.git wip.rework-gcov-v$VERSION Wei. --- v2: see individual commits for changes. Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Wei Liu (2): gcov: add new interface and new formats support gcov: provide the capability to select gcov format automatically xen/Kconfig.debug | 46 +- xen/common/gcov/Makefile| 9 ++ xen/common/gcov/gcc_3_4.c | 367 xen/common/gcov/gcc_4_7.c | 204 xen/common/gcov/gcc_4_9.c | 35 + xen/common/gcov/gcc_5.c | 35 + xen/common/gcov/gcov.c | 257 +++ xen/common/gcov/gcov.h | 40 + xen/common/gcov/gcov_base.c | 60 xen/common/sysctl.c | 8 + xen/include/public/sysctl.h | 39 - xen/include/xen/gcov.h | 9 ++ 12 files changed, 1102 insertions(+), 7 deletions(-) create mode 100644 xen/common/gcov/gcc_3_4.c create mode 100644 xen/common/gcov/gcc_4_7.c create mode 100644 xen/common/gcov/gcc_4_9.c create mode 100644 xen/common/gcov/gcc_5.c create mode 100644 xen/common/gcov/gcov.c create mode 100644 xen/common/gcov/gcov.h create mode 100644 xen/common/gcov/gcov_base.c create mode 100644 xen/include/xen/gcov.h -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/vmx: Print the problematic MSR if a vmentry fails
On 13/10/16 12:38, Jan Beulich wrote: On 13.10.16 at 13:15, wrote: >> Sample error looks like: >> >> (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading >> (entry 13). >> (XEN) msr 068a, val 1fff80102af0, (mbz 0) >> (XEN) * VMCS Area ** >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich > with > >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -3104,8 +3104,23 @@ static void vmx_failed_vmentry(unsigned int >> exit_reason, >> printk("caused by invalid guest state (%ld).\n", >> exit_qualification); >> break; >> case EXIT_REASON_MSR_LOADING: >> -printk("caused by MSR entry %ld loading.\n", exit_qualification); >> +{ >> +unsigned long idx = exit_qualification - 1; >> +struct vmx_msr_entry *msr; > ... preferably const here Will do. > (and the declaration perhaps moved into > the more narrow scope it's needed in), ... Cant, due to its use in the sizeof() expression. (I tried that first) > >> +printk("caused by MSR loading (entry %ld).\n", idx); > ... %lu (plus ideally the full stop dropped) here, and ... Ok for %lu. The full stop is dealt with in the following patch, so will leave this as-is for consistency of both patches. > >> +if ( idx > (PAGE_SIZE / sizeof(*msr)) ) > ... >= here. > >> +printk(" Entry out of range\n"); >> +else >> +{ >> +msr = &curr->arch.hvm_vmx.msr_area[idx]; >> + >> +printk(" msr %08x, val %016"PRIx64", (mbz %#x)\n", > I'm also unsure about the usefulness of the commas here - at least > the second one seems a little strange with the value in parentheses. Ok. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] docs: Credit1 feature document.
On 13/10/16 12:02, Dario Faggioli wrote: > diff --git a/docs/features/credit.pandoc b/docs/features/credit.pandoc > new file mode 100644 > index 000..fed0da2 > --- /dev/null > +++ b/docs/features/credit.pandoc Simply "Credit" as a top level feature isn't very descriptive. Can you see about working scheduler somewhere into the name? > @@ -0,0 +1,99 @@ > +% Credit > +% Revision 1 > + > +\clearpage > + > +# Basics > + > + Status: e.g. **Supported** > + > +Architecture(s): e.g. x86, arm > + > + Component: e.g. Hypervisor > + You should drop the e.g.'s. In cases like this where it really is just a software algorithm, I would suggest setting the architecture to all, or omitting the line entirely. I would expect that any new architecture is going gain all the schedulers without modification? > + > +# Overview > + > +Credit (also known as Credit1) is the default virtual CPU (vCPU) scheduler > +of the Xen hypervisor. The job of an hypervisor's scheduler is to decide, > +among all the various vCPUs of the various virtual machines, which ones > +should execute on the host's physical CPUs (pCPUs), at any given point in > +time. A lot of this is generic to all schedulers. I wonder whether it might be better to have a schedulers meta-feature doc which deals with the common scheduler parts, including interactions on the Xen command line, xl, etc. > + > +# User details > + > +Xen supports multiple schedulers. As said, Credit is the default, so it > +is used automatically, unless the `sched=$SCHED` (with `$SCHED` different > +than `credit`) parameter is passed to Xen via the bootloader. > + > +Once the system is live, for creating a cpupool with Credit as its > +scheduler, either compile a cpupool configuration file, as described > +in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in > +`tools/examples/cpupool`), or use just `xl` directly: I should see about ensuring that cross-references work with the HTML-generated versions of these docs. You might be able to get away with just putting in a plain hyperlink here. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] docs: Credit1 feature document.
On Thu, Oct 13, 2016 at 12:02:28PM +0100, Dario Faggioli wrote: > Signed-off-by: Dario Faggioli > --- > Cc: George Dunlap > Cc: Wei Liu > Cc: Lars Kurth > Cc: Andrew Cooper > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > --- > docs/features/credit.pandoc | 99 > +++ > 1 file changed, 99 insertions(+) > create mode 100644 docs/features/credit.pandoc > > diff --git a/docs/features/credit.pandoc b/docs/features/credit.pandoc > new file mode 100644 > index 000..fed0da2 > --- /dev/null > +++ b/docs/features/credit.pandoc > @@ -0,0 +1,99 @@ > +% Credit > +% Revision 1 > + > +\clearpage > + > +# Basics > + > + Status: e.g. **Supported** > + Delete the "e.g." in all three documents, please. > +Architecture(s): e.g. x86, arm > + And this should probably be "any". Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 101412: tolerable FAIL - PUSHED
flight 101412 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/101412/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 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-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass version targeted for testing: libvirt e1a33ed18c0200e26d92eb2900943573fc0f7d60 baseline version: libvirt 043ba4a40a4ae26cf616146d0d1c129d65b156b8 Last test of basis 101386 2016-10-12 04:22:05 Z1 days Testing same since 101412 2016-10-13 04:21:58 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Corey S. McQuay Martin Kletzander Michal Privoznik Nitesh Konkar Nitesh Konkar Pavel Hrdina Peter Krempa 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=e1a33ed18c0200e26d92eb2900943573fc0f7d60 + . ./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/re
Re: [Xen-devel] [PATCH 2/2] x86/vmx: Reduce the verbosity of the vmentry failure error reporting
>>> On 13.10.16 at 13:15, wrote: > Identify the affected vcpu at the start of the message. While tweaking this > area, add extra newlines between cases. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich with ... > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -3096,19 +3096,20 @@ static void vmx_failed_vmentry(unsigned int > exit_reason, > unsigned long exit_qualification; > struct vcpu *curr = current; > > -printk("Failed vm entry (exit reason %#x) ", exit_reason); > +printk("%pv vmentry failure (reason %#x): ", curr, exit_reason); > __vmread(EXIT_QUALIFICATION, &exit_qualification); > switch ( failed_vmentry_reason ) > { > case EXIT_REASON_INVALID_GUEST_STATE: > -printk("caused by invalid guest state (%ld).\n", exit_qualification); > +printk("Invalid guest state (%ld)\n", exit_qualification); ... %lu here. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/vmx: Print the problematic MSR if a vmentry fails
>>> On 13.10.16 at 13:15, wrote: > Sample error looks like: > > (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading (entry > 13). > (XEN) msr 068a, val 1fff80102af0, (mbz 0) > (XEN) * VMCS Area ** > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich with > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -3104,8 +3104,23 @@ static void vmx_failed_vmentry(unsigned int > exit_reason, > printk("caused by invalid guest state (%ld).\n", exit_qualification); > break; > case EXIT_REASON_MSR_LOADING: > -printk("caused by MSR entry %ld loading.\n", exit_qualification); > +{ > +unsigned long idx = exit_qualification - 1; > +struct vmx_msr_entry *msr; ... preferably const here (and the declaration perhaps moved into the more narrow scope it's needed in), ... > +printk("caused by MSR loading (entry %ld).\n", idx); ... %lu (plus ideally the full stop dropped) here, and ... > +if ( idx > (PAGE_SIZE / sizeof(*msr)) ) ... >= here. > +printk(" Entry out of range\n"); > +else > +{ > +msr = &curr->arch.hvm_vmx.msr_area[idx]; > + > +printk(" msr %08x, val %016"PRIx64", (mbz %#x)\n", I'm also unsure about the usefulness of the commas here - at least the second one seems a little strange with the value in parentheses. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On 13/10/16 12:28, Andrew Cooper wrote: > On 13/10/16 12:01, Dario Faggioli wrote: >> Hey, >> >> "Just" as per the subject, I wrote feature documents for (almost) all our >> schedulers. No big deal, I'd say, apart from the fact that I'm declaring >> Credit2 **Supperted**, instead of experimental. > > Supperted? That's like supported right? ;p > > > It is fine for you to propose that a feature should be upgraded to > supported, and this is probably the best way to formally do so. > > However, final agreement of a feature becoming supported should include > input from the security team. (At the end of the day, it is us with > extra work if the feature isn't up to scratch.) Yes, interesting idea. I don't think in our discussions of feature lifecycle maturity we'd talked about that yet. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/15] xen: Fix coding style warnings
On Thu, Oct 13, 2016 at 07:04:56AM +0300, Emil Condrea wrote: > On Tue, Oct 11, 2016 at 5:20 PM, Anthony PERARD > wrote: > > On Tue, Oct 04, 2016 at 09:43:31AM +0300, Emil Condrea wrote: > >> Fixes: > >> * WARNING: line over 80 characters > >> > >> Signed-off-by: Emil Condrea > >> --- > >> hw/block/xen_disk.c | 3 ++- > >> hw/char/xen_console.c| 6 -- > >> hw/display/xenfb.c | 30 -- > >> hw/net/xen_nic.c | 12 > >> hw/xen/xen_backend.c | 15 ++- > >> include/hw/xen/xen_backend.h | 8 +--- > >> 6 files changed, 49 insertions(+), 25 deletions(-) > >> > >> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c > >> index 5aa350a..24edeb2 100644 > >> --- a/hw/block/xen_disk.c > >> +++ b/hw/block/xen_disk.c > >> @@ -1068,7 +1068,8 @@ static int blk_connect(struct XenDevice *xendev) > >> blk_set_enable_write_cache(blkdev->blk, !writethrough); > >> } else { > >> /* setup via qemu cmdline -> already setup for us */ > >> -xen_be_printf(&blkdev->xendev, 2, "get configured bdrv (cmdline > >> setup)\n"); > >> +xen_be_printf(&blkdev->xendev, 2, > >> + "get configured bdrv (cmdline setup)\n"); > > > > Arguments are usually aligned with the first one, so there is one > > missing space. > > I guess this is displayed wrongly in the email client as in mine but the > source > of the email contains this patch http://pastebin.com/Sbk23h6m, which shows > that > this line is aligned to the first parameter. My mail client runs in a terminal, also I've apply the patches to a local tree, so no display issue. Here, the quote is just below the open parentheses, but it's normally one space futher. If I ask Vim to realign it, I end up with this: xen_be_printf(&blkdev->xendev, 2, - "get configured bdrv (cmdline setup)\n"); + "get configured bdrv (cmdline setup)\n"); You can also have a look at other call of xen_be_printf() in this function (blk_connect) to get an idea ;). -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
On 13/10/16 12:01, Dario Faggioli wrote: > Hey, > > "Just" as per the subject, I wrote feature documents for (almost) all our > schedulers. No big deal, I'd say, apart from the fact that I'm declaring > Credit2 **Supperted**, instead of experimental. Supperted? That's like supported right? ;p It is fine for you to propose that a feature should be upgraded to supported, and this is probably the best way to formally do so. However, final agreement of a feature becoming supported should include input from the security team. (At the end of the day, it is us with extra work if the feature isn't up to scratch.) ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/vmx: Reduce the verbosity of the vmentry failure error reporting
Identify the affected vcpu at the start of the message. While tweaking this area, add extra newlines between cases. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima CC: Kevin Tian --- xen/arch/x86/hvm/vmx/vmx.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 38cbcea..554f9e8 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3096,19 +3096,20 @@ static void vmx_failed_vmentry(unsigned int exit_reason, unsigned long exit_qualification; struct vcpu *curr = current; -printk("Failed vm entry (exit reason %#x) ", exit_reason); +printk("%pv vmentry failure (reason %#x): ", curr, exit_reason); __vmread(EXIT_QUALIFICATION, &exit_qualification); switch ( failed_vmentry_reason ) { case EXIT_REASON_INVALID_GUEST_STATE: -printk("caused by invalid guest state (%ld).\n", exit_qualification); +printk("Invalid guest state (%ld)\n", exit_qualification); break; + case EXIT_REASON_MSR_LOADING: { unsigned long idx = exit_qualification - 1; struct vmx_msr_entry *msr; -printk("caused by MSR loading (entry %ld).\n", idx); +printk("MSR loading (entry %ld)\n", idx); if ( idx > (PAGE_SIZE / sizeof(*msr)) ) printk(" Entry out of range\n"); @@ -3121,13 +3122,15 @@ static void vmx_failed_vmentry(unsigned int exit_reason, } break; } + case EXIT_REASON_MCE_DURING_VMENTRY: -printk("caused by machine check.\n"); +printk("MCE\n"); HVMTRACE_0D(MCE); /* Already handled. */ break; + default: -printk("reason not known yet!"); +printk("Unknown\n"); break; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/vmx: Print the problematic MSR if a vmentry fails
Sample error looks like: (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading (entry 13). (XEN) msr 068a, val 1fff80102af0, (mbz 0) (XEN) * VMCS Area ** Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Jun Nakajima CC: Kevin Tian --- xen/arch/x86/hvm/vmx/vmx.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index b9102ce..38cbcea 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3104,8 +3104,23 @@ static void vmx_failed_vmentry(unsigned int exit_reason, printk("caused by invalid guest state (%ld).\n", exit_qualification); break; case EXIT_REASON_MSR_LOADING: -printk("caused by MSR entry %ld loading.\n", exit_qualification); +{ +unsigned long idx = exit_qualification - 1; +struct vmx_msr_entry *msr; + +printk("caused by MSR loading (entry %ld).\n", idx); + +if ( idx > (PAGE_SIZE / sizeof(*msr)) ) +printk(" Entry out of range\n"); +else +{ +msr = &curr->arch.hvm_vmx.msr_area[idx]; + +printk(" msr %08x, val %016"PRIx64", (mbz %#x)\n", + msr->index, msr->data, msr->mbz); +} break; +} case EXIT_REASON_MCE_DURING_VMENTRY: printk("caused by machine check.\n"); HVMTRACE_0D(MCE); -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] tools: check liblzma in configure for rombios
Wei Liu writes ("[PATCH for-4.8] tools: check liblzma in configure for rombios"): > We upgraded ipxe in 38ab99b2 ("ipxe: update to new commit"). That > version of ipxe requires liblzma to build. > > Check that in configure and document this in README. Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/3] docs: RTDS feature document.
Signed-off-by: Dario Faggioli --- Cc: Meng Xu Cc: George Dunlap Cc: Wei Liu Cc: Lars Kurth Cc: Andrew Cooper Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini --- docs/features/rtds.pandoc | 125 + 1 file changed, 125 insertions(+) create mode 100644 docs/features/rtds.pandoc diff --git a/docs/features/rtds.pandoc b/docs/features/rtds.pandoc new file mode 100644 index 000..76aa165 --- /dev/null +++ b/docs/features/rtds.pandoc @@ -0,0 +1,125 @@ +% RTDS +% Revision 1 + +\clearpage + +# Basics + + Status: e.g. **Experimental** + +Architecture(s): e.g. x86, arm + + Component: e.g. Hypervisor + + +# Overview + +RTDS is one of the virtual CPU (vCPU) scheduler available in the Xen +hypervisor. The job of an hypervisor's virtual CPU scheduler is to +decide, among all the various vCPUs of the various virtual machines, +which ones should execute on the host's physical CPUs (pCPUs), at any +given point in time. + +RTDS is a real--time scheduler, so its purpose is enabling +**deterministic** scheduling of the virtual machine's vCPUs. It has +been originally developed in the context of the RT-Xen project. + +# User details + +RTDS is not in use by default. In order to use it as the Xen scheduler +the following parameter should be passed to the hypervisor at boot: + +`sched=rtds` + +Once the system is live, for creating a cpupool with RTDS as its +scheduler, either compile a cpupool configuration file, as described +in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in +`tools/examples/cpupool`), or use just `xl` directly: + +xl cpupool-create name=\"pool-rt\" sched=\"rtds\" cpus=[4,5,6,8] + +For checking or changing a VM's scheduling parameters from xl, do +as follows: +* `xl sched-rtds -d vm-rt` +* `xl sched-rtds -d vm-rt -t 1 -b 25000` + +It is possible, for a multiple vCPUs VM, to change the parameters of +each vCPU individually: +* `xl sched-rtds -d vm-rt -v 0 -p 2 -b 1 -v 1 -p 45000 -b 12000` + +# Technical details + +The implementation entirely lives in the hypervisor. Xen has a +pluggable, hook based, architecture for schedulers. RTDS code +is all inside one file: `xen/common/sched_rt.c` + +In libxl, the availability of the RTDS scheduler is advertised by +the presence of the LIBXL\_HAVE\_SCHED\_RTDS symbol. The ability of +specifying different scheduling parameters for each vcpu has been +introduced later, and is available if the following symbols are defined: +* `LIBXL\_HAVE\_VCPU\_SCHED\_PARAMS`, +* `LIBXL\_HAVE\_SCHED\_RTDS\_VCPU\_PARAMS`. + +# Limitations + +RTDS is a special purpose scheduling. This is by design, and not at +all a limitation, but it is certainly something to keep in mind when +thinking about using it. The purpose of the scheduler is enabling +deterministic and statically analyzable behavior (as per the +real-time academic literature), according to the scheduling parameters +assigned to each vCPU. + +Using RTDS a the Xen scheduler, and/or for general purpose workloads +is definitely possible, but the vCPU scheduling parameters (of both +Domain0 and of the various VMs) would probably require tweaking, with +respect to their default values. + +# Testing + +Any change done in RTDS must be tested by doing the following: + +* create a cpupool with RTDS as its scheduler, +* create a few virtual machines a move them in and out of the pool, +* create a few virtual machines, directly inside the pool, and verify + that they boot and can run some basic workload (e.g., login into them + and run simple commands), +* shutdown/reboot the virtual machines, + +The fact that the system boots fine when passing `sched=rtds` to Xen +should also be verified. + +Finally, to check that the scheduler is working properly (although only +at a macroscopic level), the following should be done: + +* create a VM with 1 vCPU and put it in the RTDS cpupool, +* set the scheduling parameters such as it has a 50% reservation, with + `xl sched-rtds -d vm -t 10 -b 5`, +* run a CPU-burning process inside the VM (e.g., `yes`), +* check with `xentop` (in Domain0) that the VM is getting no more than + 50% pCPU time. + +# Areas for improvement + +* Work-conserving mode to be added; +* performance assessment, especially focusing on what level of real-time + behavior the scheduler enables. + +# Known issues + +* OSSTest reports occasional failures on ARM. + +# References + +* "RT-Xen: Real-Time Virtualization" [XPDS14 Presentation](http://events.linuxfoundation.org/sites/events/files/slides/2014_Xen_Developer_Summit_0.pdf) +* "Scheduling in Xen" [XPDS15 Presentation](http://events.linuxfoundation.org/sites/events/files/slides/Faggioli_XenSummit.pdf) +* [RT-Xen Project](https://sites.google.com/site/realtimexen/) +* [RTDS-Based-Scheduler](
[Xen-devel] [PATCH 2/3] docs: Credit2 feature document.
Since we are marking the feature as 'Supported', remove the "this is experimental software" warning in the code at once. Signed-off-by: Dario Faggioli --- Cc: George Dunlap Cc: Anshul Makkar Cc: Wei Liu Cc: Lars Kurth Cc: Andrew Cooper Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini --- docs/features/credit2.pandoc | 123 ++ xen/common/sched_credit2.c |2 - 2 files changed, 123 insertions(+), 2 deletions(-) create mode 100644 docs/features/credit2.pandoc diff --git a/docs/features/credit2.pandoc b/docs/features/credit2.pandoc new file mode 100644 index 000..6203cec --- /dev/null +++ b/docs/features/credit2.pandoc @@ -0,0 +1,123 @@ +% Credit2 +% Revision 1 + +\clearpage + +# Basics + + Status: e.g. **Supported** + +Architecture(s): e.g. x86, arm + + Component: e.g. Hypervisor + + +# Overview + +Credit2 is one of the virtual CPU (vCPU) scheduler available in the +Xen hypervisor. The job of an hypervisor's virtual CPU scheduler is +to decide, among all the various vCPUs of the various virtual machines, +which ones should execute on the host's physical CPUs (pCPUs), at any +given point in time. + +Credit2 was designed as a general purpose scheduler, with particular +focus on improving handling of mixed workloads, scalability and +support for low latency applications inside VMs, with respect to +Credit1. + +# User details + +Credit2 is not in use by default. In order to use it as the Xen +scheduler the following parameter should be passed to the hypervisor +at boot: + +`sched=credit2` + +Other parameters are available for tuning the behavior of Credit2 +(see `docs/misc/xen-command-line.markdown` for a complete list and +for their meaning). + +Once the system is live, for creating a cpupool with Credit2 as +its scheduler, either compile a cpupool configuration file, as +described in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified +in `tools/examples/cpupool`), or use just `xl` directly: + +xl cpupool-create name=\"pool1\" sched=\"credit2\" cpus=[1,2] + +Two kind of interactions with the scheduler are possible: + +* checking or changing the global parameters, via, e.g.: +* `xl sched-credit2 -s` +* `xl sched-credit2 -s -p pool1` +* `xl sched-credit2 -s -r 100` +* checking or changing a VM scheduling parameters, via, e.g.: +* `xl sched-credit2 -d vm1` +* `xl sched-credit2 -d vm1 -w 1024` + +# Technical details + +The implementation entirely lives in the hypervisor. Xen has a +pluggable, hook based, architecture for schedulers. Credit2 code +is all inside one file: `xen/common/sched_credit2.c` + +Global scheduling parameters, such as context switching rate +limiting, is only available from Xen 4.8 onward. In libxl, the +`LIBXL\_HAVE\_SCHED\_CREDIT2\_PARAMS` symbol is introduced to +indicate their availability. + +# Limitations + +The Credit1 scheduler supports vCPU hard-affinity, vCPU soft-affinity +and caps (see `docs/man/xl.pod.1.in` for more details). In Credit2, +vCPU hard affinity is supported starting from Xen 4.8, while soft-affinity +and caps are being implemented, but not supported yet in any released +hypervisor. + +# Testing + +Any change done in Credit2 wants to be tested by doing at least the +following: + +* boot the system with `sched=credit2`, +* create a few virtual machine and verify that they boot and can + run some basic workload (e.g., login into them and run simple commands), +* shutdown/reboot the virtual machines, +* shutdown/reboot the system. + +Ideally, all the above steps should **also** be performed in a configuration +where Credit2 is used as the scheduler of a cpupool, and by also doing the +following: + +* move a virtual machine inside and outside a Credit2 cpupool. + +# Areas for improvement + +* Close the feature gap with Credit1 (i.e., finishing implementing vCPU + soft-affinity and caps); +* vCPUs' reservations (similar to caps, but providing a vCPU with guarantees + about some pCPU time it will always be able to execute for); +* benchmarking for assessing the best combination of values for the various + parameters (`sched\_credit2\_migrate\_resist`, `credit2\_balance\_over`, + `credit2\_balance\_under`) + +# Known issues + +* I/O oriented benchmarks (like network and disk throughput) have given + contradictory and non-conclusive results so far. Need to run more of + those. + +# References + +* "Scheduler development update", XenSummit Asia 2009 [whitepaper](http://www-archive.xenproject.org/files/xensummit_intel09/George_Dunlap.pdf) +* "Scheduling in Xen" [XPDS15 Presentation](http://events.linuxfoundation.org/sites/events/files/slides/Faggioli_XenSummit.pdf) +* "Scope and Performance of Credit-2 Scheduler" [XPDS16 Presentation](http://www.slideshare.net/xen_com_mgr/xpds16-scope-and-performance-
[Xen-devel] [PATCH for-4.8] tools: check liblzma in configure for rombios
We upgraded ipxe in 38ab99b2 ("ipxe: update to new commit"). That version of ipxe requires liblzma to build. Check that in configure and document this in README. Signed-off-by: Wei Liu --- Cc: Ian Jackson Rerun autogen.sh while committing. --- README | 1 + tools/config.h.in | 3 ++ tools/configure| 139 +++-- tools/configure.ac | 2 + 4 files changed, 99 insertions(+), 46 deletions(-) diff --git a/README b/README index 91f4a8b..b370ce2 100644 --- a/README +++ b/README @@ -82,6 +82,7 @@ disabled at compile time: information. * 16-bit x86 assembler, loader and compiler for qemu-traditional / rombios (dev86 rpm or bin86 & bcc debs) +* Development install of liblzma for rombios Second, you need to acquire a suitable kernel for use in domain 0. If possible you should use a kernel provided by your OS distributor. If diff --git a/tools/config.h.in b/tools/config.h.in index f65eec4..58856bc 100644 --- a/tools/config.h.in +++ b/tools/config.h.in @@ -36,6 +36,9 @@ /* Define to 1 if you have the `fdt' library (-lfdt). */ #undef HAVE_LIBFDT +/* Define to 1 if you have the `lzma' library (-llzma). */ +#undef HAVE_LIBLZMA + /* Define to 1 if you have the `yajl' library (-lyajl). */ #undef HAVE_LIBYAJL diff --git a/tools/configure b/tools/configure index e3cc3ea..25edfee 100755 --- a/tools/configure +++ b/tools/configure @@ -1696,6 +1696,52 @@ fi } # ac_fn_c_try_compile +# ac_fn_c_try_link LINENO +# --- +# Try to link conftest.$ac_ext, and return whether this succeeded. +ac_fn_c_try_link () +{ + as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack + rm -f conftest.$ac_objext conftest$ac_exeext + if { { ac_try="$ac_link" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\"" +$as_echo "$ac_try_echo"; } >&5 + (eval "$ac_link") 2>conftest.err + ac_status=$? + if test -s conftest.err; then +grep -v '^ *+' conftest.err >conftest.er1 +cat conftest.er1 >&5 +mv -f conftest.er1 conftest.err + fi + $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5 + test $ac_status = 0; } && { +test -z "$ac_c_werror_flag" || +test ! -s conftest.err + } && test -s conftest$ac_exeext && { +test "$cross_compiling" = yes || +test -x conftest$ac_exeext + }; then : + ac_retval=0 +else + $as_echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + ac_retval=1 +fi + # Delete the IPA/IPO (Inter Procedural Analysis/Optimization) information + # created by the PGI compiler (conftest_ipa8_conftest.oo), as it would + # interfere with the next link command; also delete a directory that is + # left behind by Apple's compiler. We do this before executing the actions. + rm -rf conftest.dSYM conftest_ipa8_conftest.oo + eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno + as_fn_set_status $ac_retval + +} # ac_fn_c_try_link + # ac_fn_c_try_cpp LINENO # -- # Try to preprocess conftest.$ac_ext, and return whether this succeeded. @@ -1897,52 +1943,6 @@ $as_echo "$ac_res" >&6; } } # ac_fn_c_check_header_compile -# ac_fn_c_try_link LINENO -# --- -# Try to link conftest.$ac_ext, and return whether this succeeded. -ac_fn_c_try_link () -{ - as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack - rm -f conftest.$ac_objext conftest$ac_exeext - if { { ac_try="$ac_link" -case "(($ac_try" in - *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; - *) ac_try_echo=$ac_try;; -esac -eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\"" -$as_echo "$ac_try_echo"; } >&5 - (eval "$ac_link") 2>conftest.err - ac_status=$? - if test -s conftest.err; then -grep -v '^ *+' conftest.err >conftest.er1 -cat conftest.er1 >&5 -mv -f conftest.er1 conftest.err - fi - $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5 - test $ac_status = 0; } && { -test -z "$ac_c_werror_flag" || -test ! -s conftest.err - } && test -s conftest$ac_exeext && { -test "$cross_compiling" = yes || -test -x conftest$ac_exeext - }; then : - ac_retval=0 -else - $as_echo "$as_me: failed program was:" >&5 -sed 's/^/| /' conftest.$ac_ext >&5 - - ac_retval=1 -fi - # Delete the IPA/IPO (Inter Procedural Analysis/Optimization) information - # created by the PGI compiler (conftest_ipa8_conftest.oo), as it would - # interfere with the next link command; also delete a directory that is - # left behind by Apple's compiler. We do this before executing the actions. - rm -rf conftest.dSYM conftest_ipa8_conftest.oo - eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno - as_fn_set_status $ac_retval - -} # ac_fn_c_try_link - # ac_fn_c_check_func LINENO FUNC VAR # --
[Xen-devel] [PATCH 1/3] docs: Credit1 feature document.
Signed-off-by: Dario Faggioli --- Cc: George Dunlap Cc: Wei Liu Cc: Lars Kurth Cc: Andrew Cooper Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini --- docs/features/credit.pandoc | 99 +++ 1 file changed, 99 insertions(+) create mode 100644 docs/features/credit.pandoc diff --git a/docs/features/credit.pandoc b/docs/features/credit.pandoc new file mode 100644 index 000..fed0da2 --- /dev/null +++ b/docs/features/credit.pandoc @@ -0,0 +1,99 @@ +% Credit +% Revision 1 + +\clearpage + +# Basics + + Status: e.g. **Supported** + +Architecture(s): e.g. x86, arm + + Component: e.g. Hypervisor + + +# Overview + +Credit (also known as Credit1) is the default virtual CPU (vCPU) scheduler +of the Xen hypervisor. The job of an hypervisor's scheduler is to decide, +among all the various vCPUs of the various virtual machines, which ones +should execute on the host's physical CPUs (pCPUs), at any given point in +time. + +# User details + +Xen supports multiple schedulers. As said, Credit is the default, so it +is used automatically, unless the `sched=$SCHED` (with `$SCHED` different +than `credit`) parameter is passed to Xen via the bootloader. + +Once the system is live, for creating a cpupool with Credit as its +scheduler, either compile a cpupool configuration file, as described +in `docs/man/xlcpupool.cfg.pod.5` (and as exemplified in +`tools/examples/cpupool`), or use just `xl` directly: + +xl cpupool-create name=\"pool1\" sched=\"credit\" cpus=[4,8] + +Two kind of interactions with the scheduler are possible: + +* checking or changing the global parameters, via, e.g.: +* `xl sched-credit -s` +* `xl sched-credit -s -p pool1` +* `xl sched-credit -s -t 20` +* checking or changing a VM's scheduling parameters, via, e.g.: +* `xl sched-credit -d vm1` +* `xl sched-credit -d vm1 -w 512` + +# Technical details + +Implementation entirely lives in the hypervisor. Xen has a pluggable, hook +based, architecture for schedulers. Actual Credit code is all inside one +file: `xen/common/sched_credit.c`. + +# Limitations + +In Credit, a vCPU has a priority, a status (i.e., active or inactive), +a weight and some credits... and all these things interact in a rather +involved way. Also, with years of use, things have gotten even more +complex (due to, e.g., the introduction of boosting, caps and vCPU +soft-affinity). + +Dealing with such complexity is starting to be an issue. Odd behavior +or subtle scheduling anomalies, that is not always possible to act upon, +have been identified already. [1][2][3] + +A certain lack of scalability and difficulties and weakness in dealing +with mixed workloads and VMs with low latency requirements are other +known problems. [4] For all these reasons, effort is ongoing to have +Credit2 become the new default scheduler. + +# Testing + +Any change to Credit code must to be tested by doing at least the following: + +* create a few virtual machine and verify that they boot and can + run some basic workload (e.g., login into them and run simple commands), +* shutdown/reboot the virtual machines, +* shutdown the system. + +Ideally, all the above steps should **also** be performed in a configuration +that includes cpupools, better if with pools using different schedulers, and +by also doing the following: + +* move the virtual machines between cpupools. + +# References + +* [potential non-ideal behavior on hyperthreaded systems](https://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01848.html) [1] +* [long standing BOOST vs. migration bug](https://lists.xen.org/archives/html/xen-devel/2015-10/msg02851.html) [2] +* [priority handling issues](https://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01362.html) [3] +* "Scheduler development update", XenSummit Asia 2009 [whitepaper](http://www-archive.xenproject.org/files/xensummit_intel09/George_Dunlap.pdf) [4] +* "Scheduling in Xen" [XPDS15 Presentation](http://events.linuxfoundation.org/sites/events/files/slides/Faggioli_XenSummit.pdf) +* [Xen Project Scheduler](https://wiki.xenproject.org/wiki/Xen_Project_Schedulers) + +# History + + +Date Revision Version Notes +-- --- +2016-10-10 1Xen 4.8 Document written +-- --- ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/3 for 4.8] docs: feature documents for the schedulers
Hey, "Just" as per the subject, I wrote feature documents for (almost) all our schedulers. No big deal, I'd say, apart from the fact that I'm declaring Credit2 **Supperted**, instead of experimental. In fact, it's being tested by OSSTest for ages, and it's undergone a huge amount of development, testing and benchmarking lately, and its current status is finally good enough, IMO. As a consequence of that, in patch 2, I'm also touching the code, but that's just for removing a printk, so it should not be too big of a deal I hope. This wiki page is listed among the references in Credit2's feature document: https://wiki.xenproject.org/wiki/Credit2_Scheduler_Development. If you go there checking it out, bear in mind that I'm updating and re-organazing it by quite a bit, like right now. Sorry if the Cc-list is a bit large, but that's the best I and get_maintainers.pl could come up with. :-P Thanks and Regards, Dario --- Dario Faggioli (3): docs: Credit1 feature document. docs: Credit2 feature document. docs: RTDS feature document. docs/features/credit.pandoc | 99 + docs/features/credit2.pandoc | 123 + docs/features/rtds.pandoc| 125 ++ xen/common/sched_credit2.c |2 - 4 files changed, 347 insertions(+), 2 deletions(-) create mode 100644 docs/features/credit.pandoc create mode 100644 docs/features/credit2.pandoc create mode 100644 docs/features/rtds.pandoc -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: correct {, F}CMOV and F{, U}COMI{, P} emulation
On 13/10/16 07:41, Jan Beulich wrote: > The FPU ones need to be executed with guest EFLAGS.{C,P,Z}F in context. > > We also can't exclude someone wanting to hide the feature from (32-bit) > guests. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
- On 13 Oct, 2016, at 09:29, Wei Liu wei.l...@citrix.com wrote: > On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote: >> Right and still no solution >> >> there is no xz-dev or libxz-dev; I installed everything which just looks >> remote >> like xz or lzma >> > > On Debian it is called liblzma-dev. Not sure what distro you use. > >> building is no problem as I build with >> >> ./configure --enable-githttp --enable-systemd --disable-rombios >> --disable-qemu-traditional --disable-stubdom --disable-docs >> >> > > And you sorta worked around the lzma requirement by disabling rombios. > > This issue you encountered is a different issue from Boris'. no still no solution the xz problem is only for xen-4.7 but i gave up on that my last test was 4.8-rc2 which also didn't work ; building and booting hypervizor is ok xl tools nope creating or starting a VM nope xl -v cr something hangs forever restarting xencommons hangs restarting xenconsoled hangs sigh ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH Altp2m cleanup 2/3 v10 2/2] Moving ept code to ept specific files as requested in: https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html Renamed p2m_init_al
>>> On 12.10.16 at 01:40, wrote: > Signed-off-by: Paul Lai > Reviewed-by: Konrad Rzeszutek Wilk > --- > v10 > Added Reviewed-by stamp Same thing here - please address _all_ review comments. On v9 Konrad did say "someting is off with your title. I think you need to add an extra newline." As it stands the patch title is definitely too long. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH Altp2m cleanup 2/3 v10 1/2] Move altp2m specific functions to altp2m files.
>>> On 12.10.16 at 01:40, wrote: > @@ -66,6 +67,63 @@ altp2m_vcpu_destroy(struct vcpu *v) > } > > /* > + * allocate and initialize memory for altp2m portion of domain > + * > + * returns < 0 on error > + * returns 0 on no operation & success > + */ > +int > +altp2m_domain_init(struct domain *d) > +{ > +int rc; > +unsigned int i; > + > +if ( d == NULL ) > +return 0; I'm sorry for not having paid attention before, but why do you add this check? > @@ -493,32 +494,25 @@ int hap_enable(struct domain *d, u32 mode) > goto out; > } > > -for (i = 0; i < MAX_NESTEDP2M; i++) { > +for (i = 0; i < MAX_NESTEDP2M; i++) > +{ If you correct coding style issues, then please deal with all of them at once. Albeit this code is unrelated to altp2m, so maybe you'd better leave it alone in this patch. > rv = p2m_alloc_table(d->arch.nested_p2m[i]); > if ( rv != 0 ) > goto out; > } > > -if ( hvm_altp2m_supported() ) > +if ( (rv = altp2m_domain_init(d)) < 0 ) > { > -/* Init alternate p2m data */ > -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL ) > +for (i = 0; i < MAX_NESTEDP2M; i++) As said on v8: Coding style (you've moved the opening brace, but you didn't insert blanks). > { > -rv = -ENOMEM; > -goto out; > +p2m_teardown(d->arch.nested_p2m[i]); > } > > -for ( i = 0; i < MAX_EPTP; i++ ) > -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN); > - > -for ( i = 0; i < MAX_ALTP2M; i++ ) > -{ > -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]); > -if ( rv != 0 ) > - goto out; > -} > +if ( d->arch.paging.hap.total_pages != 0 ) > +hap_teardown(d, NULL); > > -d->arch.altp2m_active = 0; > +p2m_teardown(p2m_get_hostp2m(d)); > +goto out; > } Repeating my v8 comment: "The portions of code removed in this hunk went into altp2m_domain_init(). The additions, however, are unexplained in the commit message and I'm not convinced they actually properly deal with the previously missing error cleanup. In particular I don't see how partial success of altp2m_domain_init() is being dealt with." While it looks like the final part of that may have been taken care of, may I once again remind you that it is a waste of everyone's time unless _all_ comments given on a prior version get addressed either verbally or in the next submitted version? In particular (but please don't again take this as the only thing needing changing/explaining) the call to hap_teardown() looks unmotivated. Don't you mean to just undo the earlier hap_set_allocation()? And then - did you check that cleanup is (a) necessary here in the first place and (b) is now complete? I ask because e.g. the nested p2m allocation loop doesn't appear to be doing any cleanup either. It looks like this is wrong too, but if you fix it you need to (1) confirm for yourself the change is needed and (2) reason about the change in the commit message. And it may well be that this again would better not be done here, but in a prerequisite (and thus backportable) patch. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] per-domain logging
On Thu, Oct 13, 2016 at 11:28:21AM +0200, Cedric Bosdonnat wrote: > Hi Wei, Ian, > > In quite a number of places, the domid we have in the function calling LOG* > may be the one of a stubdom. In the log we want to output the domid of the > domain the user knows about. Would there be a way to get it? > > An example of that is do_pci_add. It has a libxl_is_stubdom call, suggesting > that domid may not be the real domain id. An I wonder if there are other > places where domid may be the one of a stubdom and I don't know it. > The third argument of libxl_is_stubdom can be used to retrieve the target domid. If you find other places where you need to get the domid, please let me know. I believe there are some fields embedded in various structs that we can interrogate. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] Xen/Keyhandler: Rework process of nonirq keyhandler
On Thu, Oct 13, 2016 at 03:30:04AM -0600, Jan Beulich wrote: > >>> On 13.10.16 at 12:06, wrote: > > Keyhandler may run for a long time in serial port driver's > > timer handler on the large machine with a lot of physical > > cpus(e,g dump_timerq()) when serial port driver works in > > the poll mode(via the exception mechanism). > > > > If a timer handler runs a long time, it will block nmi_timer_fn() > > to feed NMI watchdog and cause Xen hypervisor panic. Inserting > > process_pending_softirqs() in timer handler will not help. when timer > > interrupt arrives, timer subsystem calls all expired timer handlers > > before programming next timer interrupt. There is no timer interrupt > > arriving to trigger timer softirq during run a timer handler. > > > > This patch is to fix the issue to make nonirq keyhandler run in > > tasklet when receive debug key from serial port. > > > > Signed-off-by: Lan Tianyu > > Reviewed-by: Jan Beulich > with ... > > > --- a/xen/include/xen/keyhandler.h > > +++ b/xen/include/xen/keyhandler.h > > @@ -46,7 +46,9 @@ void register_irq_keyhandler(unsigned char key, > > bool_t diagnostic); > > > > /* Inject a keypress into the key-handling subsystem. */ > > -extern void handle_keypress(unsigned char key, struct cpu_user_regs *regs); > > +extern void handle_keypress(unsigned char key, > > + struct cpu_user_regs *regs, > > + bool async); > > ... this also changed to force_tasklet. I guess the committer could, > easily do that, but otoh I'm not sure we want/need this for 4.8 - Wei? > I'm fine with putting this into 4.8. The tree is stable at the moment, we can feed to few nice-to-have things. Wei. > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
On Thu, Oct 13, 2016 at 10:04:11AM +0100, Wei Liu wrote: > On Wed, Oct 12, 2016 at 05:03:11PM -0400, Boris Ostrovsky wrote: > > On 10/12/2016 05:27 AM, Wei Liu wrote: > > > On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote: > > >> > > >>> We're going to tag rc2 some time this week. Thanks for help testing Xen! > > >>> > > >>> Wei. > > >>> > > J > > > > - On 11 Oct, 2016, at 09:37, Wei Liu wei.l...@citrix.com wrote: > > > > > No, you can try to work around this issue by appending > > > --disable-rombios > > > to your ./configure invocation. You can test major functionalities of > > > Xen just fine without rombios. > > > > > > Wei. > > >> Now for the fun of it I tried the RELEASE-4.7 > > >> > > >> and it turns out it has no support for xz-decompression > > >> > > > That's probably because you don't have libzx development package > > > installed when building Xen. > > > > > > Which would be a new requirement for building Xen. And it broke our > > (pre-historic) build server that never had it installed. > > > > I don't think it breaks building Xen -- you just can't decompress xz > format file, right? Otherwise Juergen would not have been able to build > Xen. Now I see what happened -- upstream ipxe now requires lzma to build. I can document that in README. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote: > Right and still no solution > > there is no xz-dev or libxz-dev; I installed everything which just looks > remote like xz or lzma > On Debian it is called liblzma-dev. Not sure what distro you use. > building is no problem as I build with > > ./configure --enable-githttp --enable-systemd --disable-rombios > --disable-qemu-traditional --disable-stubdom --disable-docs > > And you sorta worked around the lzma requirement by disabling rombios. This issue you encountered is a different issue from Boris'. Wei. > I'm thinking of building a special VM with only stable Debian and old gcc and > old everything - Pepperidge Farm remembers > > and build there > > - On 13 Oct, 2016, at 09:04, Wei Liu wei.l...@citrix.com wrote: > > > I don't think it breaks building Xen -- you just can't decompress xz > > format file, right? Otherwise Juergen would not have been able to build > > Xen. > > > > Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V3] Xen/Keyhandler: Rework process of nonirq keyhandler
>>> On 13.10.16 at 12:06, wrote: > Keyhandler may run for a long time in serial port driver's > timer handler on the large machine with a lot of physical > cpus(e,g dump_timerq()) when serial port driver works in > the poll mode(via the exception mechanism). > > If a timer handler runs a long time, it will block nmi_timer_fn() > to feed NMI watchdog and cause Xen hypervisor panic. Inserting > process_pending_softirqs() in timer handler will not help. when timer > interrupt arrives, timer subsystem calls all expired timer handlers > before programming next timer interrupt. There is no timer interrupt > arriving to trigger timer softirq during run a timer handler. > > This patch is to fix the issue to make nonirq keyhandler run in > tasklet when receive debug key from serial port. > > Signed-off-by: Lan Tianyu Reviewed-by: Jan Beulich with ... > --- a/xen/include/xen/keyhandler.h > +++ b/xen/include/xen/keyhandler.h > @@ -46,7 +46,9 @@ void register_irq_keyhandler(unsigned char key, > bool_t diagnostic); > > /* Inject a keypress into the key-handling subsystem. */ > -extern void handle_keypress(unsigned char key, struct cpu_user_regs *regs); > +extern void handle_keypress(unsigned char key, > + struct cpu_user_regs *regs, > + bool async); ... this also changed to force_tasklet. I guess the committer could, easily do that, but otoh I'm not sure we want/need this for 4.8 - Wei? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] per-domain logging
Hi Wei, Ian, In quite a number of places, the domid we have in the function calling LOG* may be the one of a stubdom. In the log we want to output the domid of the domain the user knows about. Would there be a way to get it? An example of that is do_pci_add. It has a libxl_is_stubdom call, suggesting that domid may not be the real domain id. An I wonder if there are other places where domid may be the one of a stubdom and I don't know it. -- Cedric On Mon, 2016-10-10 at 11:06 +0100, Wei Liu wrote: > On Mon, Oct 10, 2016 at 09:03:49AM +0200, Cedric Bosdonnat wrote: > > On Fri, 2016-10-07 at 15:09 +0100, Wei Liu wrote: > > > Instead of trying to change all the format strings I think it would be > > > better to have a new set of LOG macros that takes domid. > > > > > > Something like: > > > LOGEVD(ERROR, errno, domid, ""); > > > > > > Sounds good to me, even if LOGEVD will just concatenate something like > > "Domain %d: " to the "". At least this would be much cleaner in the > > libxl code > > > > > I would also like to have the log format written down in some document > > > or header file. > > > > > > You mean as a documentation? That would be in libxl, not in xtl, right? > > We could have a comment above the LOG*D macros explaining what the message > > will look like (Prepending 'Domain %d: " to the message passed to normal log > > functions). And a comment on top of the current functions explaining all the > > different things that are passed on to xtl. > > > > > Presumably you will define LOG*D variants in libxl_internal.h, I think a > comment there right before those macros will be good enough. > > > > But let's step back a bit: have we agreed on the approach forward? This > > > thread doesn't seem to have a clear conclusion yet. Obviously I don't > > > want you to waste your writing code that's going to be threw away. > > > > > > I don't want to loose time either, but sometimes it's better to write some > > code to check that what we are mentioning is possible. > > > > > If you're happy with demuxing in libvirt, I won't object to it. Looks > > > like there is relatively less code churn involved than other solutions, > > > say, libxl keeping track of a set of per-domain xtl loggers. > > > > > > Having a set of per-domain xtl logger is also possible, but with one logger > > demuxing all messages, it's fairly easy to support both old log format > > and new ones. And the format we get in the callbacks from libxl is something > > like "%s%s%s%s%s", with things like file, line, function and message. Thus > > adding a domain in there doesn't make much sense. I'ld more in favor of the > > LOG*D family in libxl. > > > > > Sure, fine by me. > > Wei. > > > -- > > Cedric > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] PCIe devices that are hotplugged after MMIO has been setup fail due to _CRS not covering 64-bit area
>>> On 12.10.16 at 23:15, wrote: > On Wed, Sep 28, 2016 at 03:21:08AM -0600, Jan Beulich wrote: >> >>> On 27.09.16 at 16:43, wrote: >> > If the guest is booted with 'pci' we nicely expand the MMIO region below >> > 4GB and try to fit in the BARs in there. If that fails (not enough >> > space) we move it above the memory (64-bit). And throughout all of this >> > we also update the _CRS field to cover these ranges. >> > >> > (Note, I need to check if the 64-bit area is also set, I think it is). >> > >> > But the situation is different if we hot-plug a device that has too big >> > BAR to fit in the MMIO region. We move it in the 64-bit area but we >> > don't update the _CRS. Which means that Linux will complain (unless >> > booted with pci=nocrs)). Not sure about Windows but I would assume so >> > to. >> > >> > I was wondering what would be a good way to solve this? I looked at some >> > Dell machines to see how they deal with hotplug PCIe devices and they >> > just declared all the memory in the _CRS (including RAM). >> > >> > We could do a hybrid - during bootup make the _CRS region have entry from >> > end of RAM to .. end of memory? >> >> End of physical address space you mean? Generally yes, but we >> need to be a little careful there: For one, on AMD we'd better not >> overlap with the HT area. And then there's this MTRR related >> comment next to the setting of pci_hi_mem_end (albeit both HT >> area start and end of PA space should be aligned well enough). >> >> > Or perhaps add some extra logic between QEMU and ACPI AML to expand (or >> > perhaps modify the last _CRS entry) when PCIe devices are hotplugged? >> >> While that would be the most flexible variant, I'd be afraid of this >> getting rather complicated. Or have you already got some >> reasonable layout of how this would look like? > > I did this and while all the plumbing works great and I can see that > the pci_hi_len gets incremented by the size of the 64-bit BARS of the > new device (and also decremented if hot-unplugged) I hit a snag: > > Linux evaluates this only once (actually twice, but only during bootup). Ah - quite reasonable to expect this won't change. > For right now let me jump with the "simpler" solution of just > hardcoding the end of physical address space and see how that works out. Right. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Thu, Oct 13, 2016 at 03:15:09AM -0600, Jan Beulich wrote: > >>> On 13.10.16 at 10:49, wrote: > > On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote: > > [...] > >> >> >> ... this structure's trailing fields actually getting used by the > >> >> >> code > >> >> >> won't work well when changing compiler versions without cleaning > >> >> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c > >> >> >> #define-ing their GCOV_COUNTERS and then #include-ing this > >> >> >> shared source file. Plus btw, I don't think gcc 5.0.x (the > >> >> >> development variant of 5.x) would use anything different from > >> >> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not > >> >> >> normally be necessary anymore with gcc 5+. > >> >> >> > >> >> > > >> >> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the > >> >> > "y" part is __GNUC_PATCHLEVEL__. > >> >> > >> >> No, I didn't. From 5.x onwards the information previously carried in > >> >> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much > >> >> as previously you would not normally need to look at the former, > >> >> with newer gcc you shouldn't need to look at the latter. > >> >> > >> > > >> > I can't find relevant information in GCC cpp manual. > >> > > >> > Specifically, I look at 4.9.4 and 5.4.0 doc: > >> > > >> > > > https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Comm > > > > > >> > on-Predefined-Macros > >> > > > https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Comm > > > > > >> > on-Predefined-Macros > >> > > >> > The sections about __GNUC_* macros are identical, their semantics stay > >> > the same. > >> > > >> > What did I miss? > >> > >> Their change in how version numbers get used. I'm sure you've noticed > >> there never was a released 5.0.0 or 6.0.0, and that the stable updates > >> following 5.1.0 were 5.2.0, 5.3.0, etc. > >> > > > > OK. I found the bits at https://gcc.gnu.org/develop.html. I see what you > > meant previously. > > > > It doesn't seem to be a problem to me to compare to 5.1 though -- that's > > the first release of gcc 5, which should be what people use anyway. > > But your check should cover the introduction point of the feature, > which is 5.0.0 imo. > > > If it is the complexity of the macro that concerns you, now it has been > > changed to use GCC_VERSION macro in gcov.h, which is a lot simpler to > > reason about. Are you happy with such arrangement? > > If you mean this to be an adjustment newer than v3, then I think > I'd be fine with that, provided you cover the full range (as indicated > above), i.e. starting at 5.0.0. > OK. The check is now like: #if GCC_VERSION < 5 #error "Wrong version of GCC used to compile gcov" #endif GCC_VERSION is a convenient marco that you can find in this patch. Then all reference to gcc 5.1 will be changed to gcc 5. Wei. > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
>>> On 13.10.16 at 10:49, wrote: > On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote: > [...] >> >> >> ... this structure's trailing fields actually getting used by the code >> >> >> won't work well when changing compiler versions without cleaning >> >> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c >> >> >> #define-ing their GCOV_COUNTERS and then #include-ing this >> >> >> shared source file. Plus btw, I don't think gcc 5.0.x (the >> >> >> development variant of 5.x) would use anything different from >> >> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not >> >> >> normally be necessary anymore with gcc 5+. >> >> >> >> >> > >> >> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the >> >> > "y" part is __GNUC_PATCHLEVEL__. >> >> >> >> No, I didn't. From 5.x onwards the information previously carried in >> >> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much >> >> as previously you would not normally need to look at the former, >> >> with newer gcc you shouldn't need to look at the latter. >> >> >> > >> > I can't find relevant information in GCC cpp manual. >> > >> > Specifically, I look at 4.9.4 and 5.4.0 doc: >> > >> > > https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Comm > > >> > on-Predefined-Macros >> > > https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Comm > > >> > on-Predefined-Macros >> > >> > The sections about __GNUC_* macros are identical, their semantics stay >> > the same. >> > >> > What did I miss? >> >> Their change in how version numbers get used. I'm sure you've noticed >> there never was a released 5.0.0 or 6.0.0, and that the stable updates >> following 5.1.0 were 5.2.0, 5.3.0, etc. >> > > OK. I found the bits at https://gcc.gnu.org/develop.html. I see what you > meant previously. > > It doesn't seem to be a problem to me to compare to 5.1 though -- that's > the first release of gcc 5, which should be what people use anyway. But your check should cover the introduction point of the feature, which is 5.0.0 imo. > If it is the complexity of the macro that concerns you, now it has been > changed to use GCC_VERSION macro in gcov.h, which is a lot simpler to > reason about. Are you happy with such arrangement? If you mean this to be an adjustment newer than v3, then I think I'd be fine with that, provided you cover the full range (as indicated above), i.e. starting at 5.0.0. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
Right and still no solution there is no xz-dev or libxz-dev; I installed everything which just looks remote like xz or lzma building is no problem as I build with ./configure --enable-githttp --enable-systemd --disable-rombios --disable-qemu-traditional --disable-stubdom --disable-docs I'm thinking of building a special VM with only stable Debian and old gcc and old everything - Pepperidge Farm remembers and build there - On 13 Oct, 2016, at 09:04, Wei Liu wei.l...@citrix.com wrote: > I don't think it breaks building Xen -- you just can't decompress xz > format file, right? Otherwise Juergen would not have been able to build > Xen. > > Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
>>> On 13.10.16 at 10:53, wrote: > On 10/13/16 02:34 -0600, Jan Beulich wrote: > On 12.10.16 at 18:19, wrote: >>> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: >>> On 12.10.16 at 17:42, wrote: > On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: > On 12.10.16 at 16:58, wrote: >>> On 10/12/16 05:32 -0600, Jan Beulich wrote: >>> On 12.10.16 at 12:33, wrote: > The layout is shown as the following diagram. > > +---+---+---+--+--+ > | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | > | by kernel| Table | Block | for Xen | | > +---+---+---+--+--+ > \_ ___/ > V > /dev/pmem0 I have to admit that I dislike this, for not being OS-agnostic. Neither should there be any Xen-specific region, nor should the "whatever used by kernel" one be restricted to just Linux. What I could see is an OS-reserved area ahead of the partition table, the exact usage of which depends on which OS is currently running (and in the Xen case this might be both Xen _and_ the Dom0 kernel, arbitrated by a tbd protocol). After all, when running under Xen, the Dom0 may not have a need for as much control data as it has when running on bare hardware, for it controlling less (if any) of the actual memory ranges when Xen is present. >>> >>> Isn't this OS-reserved area still not OS-agnostic, as it requires OS >>> to know where the reserved area is? Or do you mean it's not if it's >>> defined by a protocol that is accepted by all OSes? >> >> The latter - we clearly won't get away without some agreement on >> where to retrieve position and size of this area. I was simply >> assuming that such a protocol already exists. >> > > No, we should not mix the struct page reservation that the Dom0 kernel > may actively use with the Xen reservation that the Dom0 kernel does > not consume. Explain again what is wrong with the partition approach? Not sure what was unclear in my previous reply. I don't think there should be apriori knowledge of whether Xen is (going to be) used on a system, and even if it gets used, but just occasionally, it would (apart from the abstract considerations already given) be a waste of resources to set something aside that could be used for other purposes while Xen is not running. Static partitioning should only be needed for persistent data. >>> >>> The reservation needs to be persistent / static even if the data is >>> volatile, as is the case with struct page, because we can't have the >>> size of the device change depending on use. So, from the aspect of >>> wasting space while Xen is not in use, both partitions and the >>> intrinsic reservation approach suffer the same problem. Setting that >>> aside I don't want to mix 2 different use cases into the same >>> reservation. >> >>Then you didn't understand what I've said: I certainly didn't mean >>the reservation to vary from a device perspective. However, when >>Xen is in use I don't see why part of that static reservation couldn't >>be used by Xen, and another part by the Dom0 kernel. The kernel >>obviously would need to ask the hypervisor how much of the space >>is left, and where that area starts. >> > > I think Dan means that there should be a clear separation between > reservations for different usages (kernel/xen/...). The libnvdimm > driver is for the linux kernel and only needs to maintain the > reservation for kernel functionality. For others including xen/dm/..., > if they want reservation for their own purpose, they should maintain > their own reservations out of libnvdimm driver and avoid bothering the > libnvdimm driver (e.g. add specific handling in libnvdimm driver). > > IIUC, one existing example is device-mapper device (dm) which needs to > reserve on-device area for its own meta-data. Its choice is to store > the meta-data on the block device (/dev/pmemN) provided by the > libnvdimm driver. > > I think we can do the similar for Xen, like to lay another pseudo > device on /dev/pmem and do the reservation, like 2. in my previous > reply. Well, my opinion certainly doesn't count much here, but I continue to consider this a bad idea. For entities like drivers it may well be appropriate, but I think there ought to be an independent concept of "OS reserved", and in the Xen case this could then be shared between hypervisor and Dom0 kernel. Or if we were to consider Dom0 "just a guest", things should even be the other way around: Xen gets all of the OS reserved space, and Dom0 needs something custom. Jan
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
+Dan Williams I accidentally dropped him in my last reply. Add him back. On 10/13/16 16:53 +0800, Haozhong Zhang wrote: On 10/13/16 02:34 -0600, Jan Beulich wrote: On 12.10.16 at 18:19, wrote: On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: On 12.10.16 at 17:42, wrote: On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: On 12.10.16 at 16:58, wrote: On 10/12/16 05:32 -0600, Jan Beulich wrote: On 12.10.16 at 12:33, wrote: The layout is shown as the following diagram. +---+---+---+--+--+ | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | | by kernel| Table | Block | for Xen | | +---+---+---+--+--+ \_ ___/ V /dev/pmem0 I have to admit that I dislike this, for not being OS-agnostic. Neither should there be any Xen-specific region, nor should the "whatever used by kernel" one be restricted to just Linux. What I could see is an OS-reserved area ahead of the partition table, the exact usage of which depends on which OS is currently running (and in the Xen case this might be both Xen _and_ the Dom0 kernel, arbitrated by a tbd protocol). After all, when running under Xen, the Dom0 may not have a need for as much control data as it has when running on bare hardware, for it controlling less (if any) of the actual memory ranges when Xen is present. Isn't this OS-reserved area still not OS-agnostic, as it requires OS to know where the reserved area is? Or do you mean it's not if it's defined by a protocol that is accepted by all OSes? The latter - we clearly won't get away without some agreement on where to retrieve position and size of this area. I was simply assuming that such a protocol already exists. No, we should not mix the struct page reservation that the Dom0 kernel may actively use with the Xen reservation that the Dom0 kernel does not consume. Explain again what is wrong with the partition approach? Not sure what was unclear in my previous reply. I don't think there should be apriori knowledge of whether Xen is (going to be) used on a system, and even if it gets used, but just occasionally, it would (apart from the abstract considerations already given) be a waste of resources to set something aside that could be used for other purposes while Xen is not running. Static partitioning should only be needed for persistent data. The reservation needs to be persistent / static even if the data is volatile, as is the case with struct page, because we can't have the size of the device change depending on use. So, from the aspect of wasting space while Xen is not in use, both partitions and the intrinsic reservation approach suffer the same problem. Setting that aside I don't want to mix 2 different use cases into the same reservation. Then you didn't understand what I've said: I certainly didn't mean the reservation to vary from a device perspective. However, when Xen is in use I don't see why part of that static reservation couldn't be used by Xen, and another part by the Dom0 kernel. The kernel obviously would need to ask the hypervisor how much of the space is left, and where that area starts. I think Dan means that there should be a clear separation between reservations for different usages (kernel/xen/...). The libnvdimm driver is for the linux kernel and only needs to maintain the reservation for kernel functionality. For others including xen/dm/..., if they want reservation for their own purpose, they should maintain their own reservations out of libnvdimm driver and avoid bothering the libnvdimm driver (e.g. add specific handling in libnvdimm driver). IIUC, one existing example is device-mapper device (dm) which needs to reserve on-device area for its own meta-data. Its choice is to store the meta-data on the block device (/dev/pmemN) provided by the libnvdimm driver. I think we can do the similar for Xen, like to lay another pseudo device on /dev/pmem and do the reservation, like 2. in my previous reply. Thanks, Haozhong The kernel needs to know about the struct page reservation because it needs to manage the lifetime of page references vs the lifetime of the device. It does not have the same relationship with a Xen reservation which is why I'm proposing they be managed separately. I don't think I understand the difference you try to point out here. Linux'es struct page and Xen's struct page_info serve the same fundamental purpose. Jan ___ Linux-nvdimm mailing list linux-nvd...@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit
On Wed, Oct 12, 2016 at 05:03:11PM -0400, Boris Ostrovsky wrote: > On 10/12/2016 05:27 AM, Wei Liu wrote: > > On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote: > >> > >>> We're going to tag rc2 some time this week. Thanks for help testing Xen! > >>> > >>> Wei. > >>> > J > > - On 11 Oct, 2016, at 09:37, Wei Liu wei.l...@citrix.com wrote: > > > No, you can try to work around this issue by appending --disable-rombios > > to your ./configure invocation. You can test major functionalities of > > Xen just fine without rombios. > > > > Wei. > >> Now for the fun of it I tried the RELEASE-4.7 > >> > >> and it turns out it has no support for xz-decompression > >> > > That's probably because you don't have libzx development package > > installed when building Xen. > > > Which would be a new requirement for building Xen. And it broke our > (pre-historic) build server that never had it installed. > I don't think it breaks building Xen -- you just can't decompress xz format file, right? Otherwise Juergen would not have been able to build Xen. Wei. > -boris > > > > > >> so it can't decompress the kernel via pygrub > >> > >> what > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > https://lists.xen.org/xen-devel > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
On 10/13/16 02:34 -0600, Jan Beulich wrote: On 12.10.16 at 18:19, wrote: On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: On 12.10.16 at 17:42, wrote: On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: On 12.10.16 at 16:58, wrote: On 10/12/16 05:32 -0600, Jan Beulich wrote: On 12.10.16 at 12:33, wrote: The layout is shown as the following diagram. +---+---+---+--+--+ | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | | by kernel| Table | Block | for Xen | | +---+---+---+--+--+ \_ ___/ V /dev/pmem0 I have to admit that I dislike this, for not being OS-agnostic. Neither should there be any Xen-specific region, nor should the "whatever used by kernel" one be restricted to just Linux. What I could see is an OS-reserved area ahead of the partition table, the exact usage of which depends on which OS is currently running (and in the Xen case this might be both Xen _and_ the Dom0 kernel, arbitrated by a tbd protocol). After all, when running under Xen, the Dom0 may not have a need for as much control data as it has when running on bare hardware, for it controlling less (if any) of the actual memory ranges when Xen is present. Isn't this OS-reserved area still not OS-agnostic, as it requires OS to know where the reserved area is? Or do you mean it's not if it's defined by a protocol that is accepted by all OSes? The latter - we clearly won't get away without some agreement on where to retrieve position and size of this area. I was simply assuming that such a protocol already exists. No, we should not mix the struct page reservation that the Dom0 kernel may actively use with the Xen reservation that the Dom0 kernel does not consume. Explain again what is wrong with the partition approach? Not sure what was unclear in my previous reply. I don't think there should be apriori knowledge of whether Xen is (going to be) used on a system, and even if it gets used, but just occasionally, it would (apart from the abstract considerations already given) be a waste of resources to set something aside that could be used for other purposes while Xen is not running. Static partitioning should only be needed for persistent data. The reservation needs to be persistent / static even if the data is volatile, as is the case with struct page, because we can't have the size of the device change depending on use. So, from the aspect of wasting space while Xen is not in use, both partitions and the intrinsic reservation approach suffer the same problem. Setting that aside I don't want to mix 2 different use cases into the same reservation. Then you didn't understand what I've said: I certainly didn't mean the reservation to vary from a device perspective. However, when Xen is in use I don't see why part of that static reservation couldn't be used by Xen, and another part by the Dom0 kernel. The kernel obviously would need to ask the hypervisor how much of the space is left, and where that area starts. I think Dan means that there should be a clear separation between reservations for different usages (kernel/xen/...). The libnvdimm driver is for the linux kernel and only needs to maintain the reservation for kernel functionality. For others including xen/dm/..., if they want reservation for their own purpose, they should maintain their own reservations out of libnvdimm driver and avoid bothering the libnvdimm driver (e.g. add specific handling in libnvdimm driver). IIUC, one existing example is device-mapper device (dm) which needs to reserve on-device area for its own meta-data. Its choice is to store the meta-data on the block device (/dev/pmemN) provided by the libnvdimm driver. I think we can do the similar for Xen, like to lay another pseudo device on /dev/pmem and do the reservation, like 2. in my previous reply. Thanks, Haozhong The kernel needs to know about the struct page reservation because it needs to manage the lifetime of page references vs the lifetime of the device. It does not have the same relationship with a Xen reservation which is why I'm proposing they be managed separately. I don't think I understand the difference you try to point out here. Linux'es struct page and Xen's struct page_info serve the same fundamental purpose. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
On Thu, Oct 13, 2016 at 02:29:08AM -0600, Jan Beulich wrote: [...] > >> >> ... this structure's trailing fields actually getting used by the code > >> >> won't work well when changing compiler versions without cleaning > >> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c > >> >> #define-ing their GCOV_COUNTERS and then #include-ing this > >> >> shared source file. Plus btw, I don't think gcc 5.0.x (the > >> >> development variant of 5.x) would use anything different from > >> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not > >> >> normally be necessary anymore with gcc 5+. > >> >> > >> > > >> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the > >> > "y" part is __GNUC_PATCHLEVEL__. > >> > >> No, I didn't. From 5.x onwards the information previously carried in > >> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much > >> as previously you would not normally need to look at the former, > >> with newer gcc you shouldn't need to look at the latter. > >> > > > > I can't find relevant information in GCC cpp manual. > > > > Specifically, I look at 4.9.4 and 5.4.0 doc: > > > > https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Comm > > > > on-Predefined-Macros > > https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Comm > > > > on-Predefined-Macros > > > > The sections about __GNUC_* macros are identical, their semantics stay > > the same. > > > > What did I miss? > > Their change in how version numbers get used. I'm sure you've noticed > there never was a released 5.0.0 or 6.0.0, and that the stable updates > following 5.1.0 were 5.2.0, 5.3.0, etc. > OK. I found the bits at https://gcc.gnu.org/develop.html. I see what you meant previously. It doesn't seem to be a problem to me to compare to 5.1 though -- that's the first release of gcc 5, which should be what people use anyway. If it is the complexity of the macro that concerns you, now it has been changed to use GCC_VERSION macro in gcov.h, which is a lot simpler to reason about. Are you happy with such arrangement? If you feel strongly about this version comparison thing, I'm fine with just comparing it to the major number, too. Wei. > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
>>> On 12.10.16 at 18:19, wrote: > On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote: > On 12.10.16 at 17:42, wrote: >>> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote: >>> On 12.10.16 at 16:58, wrote: > On 10/12/16 05:32 -0600, Jan Beulich wrote: > On 12.10.16 at 12:33, wrote: >>> The layout is shown as the following diagram. >>> >>> +---+---+---+--+--+ >>> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 | >>> | by kernel| Table | Block | for Xen | | >>> +---+---+---+--+--+ >>> \_ ___/ >>> V >>> /dev/pmem0 >> >>I have to admit that I dislike this, for not being OS-agnostic. >>Neither should there be any Xen-specific region, nor should the >>"whatever used by kernel" one be restricted to just Linux. What >>I could see is an OS-reserved area ahead of the partition table, >>the exact usage of which depends on which OS is currently >>running (and in the Xen case this might be both Xen _and_ the >>Dom0 kernel, arbitrated by a tbd protocol). After all, when >>running under Xen, the Dom0 may not have a need for as much >>control data as it has when running on bare hardware, for it >>controlling less (if any) of the actual memory ranges when Xen >>is present. >> > > Isn't this OS-reserved area still not OS-agnostic, as it requires OS > to know where the reserved area is? Or do you mean it's not if it's > defined by a protocol that is accepted by all OSes? The latter - we clearly won't get away without some agreement on where to retrieve position and size of this area. I was simply assuming that such a protocol already exists. >>> >>> No, we should not mix the struct page reservation that the Dom0 kernel >>> may actively use with the Xen reservation that the Dom0 kernel does >>> not consume. Explain again what is wrong with the partition approach? >> >> Not sure what was unclear in my previous reply. I don't think there >> should be apriori knowledge of whether Xen is (going to be) used on >> a system, and even if it gets used, but just occasionally, it would >> (apart from the abstract considerations already given) be a waste >> of resources to set something aside that could be used for other >> purposes while Xen is not running. Static partitioning should only be >> needed for persistent data. > > The reservation needs to be persistent / static even if the data is > volatile, as is the case with struct page, because we can't have the > size of the device change depending on use. So, from the aspect of > wasting space while Xen is not in use, both partitions and the > intrinsic reservation approach suffer the same problem. Setting that > aside I don't want to mix 2 different use cases into the same > reservation. Then you didn't understand what I've said: I certainly didn't mean the reservation to vary from a device perspective. However, when Xen is in use I don't see why part of that static reservation couldn't be used by Xen, and another part by the Dom0 kernel. The kernel obviously would need to ask the hypervisor how much of the space is left, and where that area starts. > The kernel needs to know about the struct page reservation because it > needs to manage the lifetime of page references vs the lifetime of the > device. It does not have the same relationship with a Xen reservation > which is why I'm proposing they be managed separately. I don't think I understand the difference you try to point out here. Linux'es struct page and Xen's struct page_info serve the same fundamental purpose. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support
>>> On 12.10.16 at 19:07, wrote: > On Wed, Oct 12, 2016 at 09:42:17AM -0600, Jan Beulich wrote: >> >>> On 12.10.16 at 17:33, wrote: >> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote: >> >> >>> On 11.10.16 at 12:31, wrote: >> >> > --- /dev/null >> >> > +++ b/xen/common/gcov/gcc_4_7.c >> >> > @@ -0,0 +1,205 @@ >> >> > +/* >> >> > + * This code provides functions to handle gcc's profiling data format >> >> > + * introduced with gcc 4.7. >> >> > + * >> >> > + * This file is based heavily on gcc_3_4.c file. >> >> > + * >> >> > + * For a better understanding, refer to gcc source: >> >> > + * gcc/gcov-io.h >> >> > + * libgcc/libgcov.c >> >> > + * >> >> > + * Uses gcc-internal data definitions. >> >> > + * >> >> > + * Imported from Linux and modified for Xen by >> >> > + *Wei Liu >> >> > + */ >> >> > + >> >> > +#include >> >> > + >> >> > +#include "gcov.h" >> >> > + >> >> > +#if GCC_VERSION < 40700 >> >> > +#error "Wrong version of GCC used to compile gcov" >> >> > +#endif >> >> > + >> >> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1) >> >> > +#define GCOV_COUNTERS 10 >> >> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9 >> >> > +#define GCOV_COUNTERS 9 >> >> > +#else >> >> > +#define GCOV_COUNTERS 8 >> >> > +#endif >> >> >> >> I'm sorry for not having pointed this out on v2 (I had noticed it, >> >> but then didn't finish analyzing the situation), but I'm afraid this >> >> together with ... >> >> >> >> > +struct gcov_info { >> >> > +unsigned int version; >> >> > +struct gcov_info *next; >> >> > +unsigned int stamp; >> >> > +const char *filename; >> >> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int); >> >> > +unsigned int n_functions; >> >> > +struct gcov_fn_info **functions; >> >> > +}; >> >> >> >> ... this structure's trailing fields actually getting used by the code >> >> won't work well when changing compiler versions without cleaning >> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c >> >> #define-ing their GCOV_COUNTERS and then #include-ing this >> >> shared source file. Plus btw, I don't think gcc 5.0.x (the >> >> development variant of 5.x) would use anything different from >> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not >> >> normally be necessary anymore with gcc 5+. >> >> >> > >> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the >> > "y" part is __GNUC_PATCHLEVEL__. >> >> No, I didn't. From 5.x onwards the information previously carried in >> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much >> as previously you would not normally need to look at the former, >> with newer gcc you shouldn't need to look at the latter. >> > > I can't find relevant information in GCC cpp manual. > > Specifically, I look at 4.9.4 and 5.4.0 doc: > > https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Comm > > on-Predefined-Macros > https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Comm > > on-Predefined-Macros > > The sections about __GNUC_* macros are identical, their semantics stay > the same. > > What did I miss? Their change in how version numbers get used. I'm sure you've noticed there never was a released 5.0.0 or 6.0.0, and that the stable updates following 5.1.0 were 5.2.0, 5.3.0, etc. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel