Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures
>>> On 10.05.16 at 05:41, wrote: > On May 10, 2016 12:14 AM, Jan Beulich wrote: >> >>> On 06.05.16 at 10:54, wrote: >> > --- a/xen/drivers/passthrough/iommu.c >> > +++ b/xen/drivers/passthrough/iommu.c >> > @@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d, >> unsigned long gfn, unsigned long mfn, >> > unsigned int flags) { >> > const struct domain_iommu *hd = dom_iommu(d); >> > +int rc; >> > >> > if ( !iommu_enabled || !hd->platform_ops ) >> > return 0; >> > >> > -return hd->platform_ops->map_page(d, gfn, mfn, flags); >> > +rc = hd->platform_ops->map_page(d, gfn, mfn, flags); >> > + >> > +if ( unlikely(rc) ) >> > +{ >> > +printk(XENLOG_ERR >> > + "iommu_map_page: IOMMU mapping gfn %#lx mfn %#lx failed for >> dom%d.", >> > + gfn, mfn, d->domain_id); >> > + >> > +if ( !is_hardware_domain(d) ) >> > +domain_crash(d); >> > +} >> >> This still may spam the console in at least the case of Dom0. > > I am afraid we may need a minor trade-off. What about: > >dprintk(XENLOG_ERR, "..."); > > to print out in debug mode. And be silent in non-debug mode? That's not what we want. >> For DomU I'd >> really expect you to state in the commit message why no spamming can occur >> (of course assuming it really can't, which I'm not convinced of). >> > > In this v4, I think we will still spam the console in extreme cases :(:(.. > > For mapping: > +ret = iommu_map_page(); > +if ( unlikely(ret) ) > +{ > +while ( i-- ) > +iommu_unmap_page(); > +} > > We'll stop map against any error and unmapping the previous mappings. The > extreme case is error for unmapping the previous mappings. > > Again -- I think dprintk is a better solution. Any suggestion? For DomU the solution seems quite obvious: Only log a message if the domain is not already marked crashed. For Dom0 you'll need to get a little more creative (but by leveraging the fact that there's only one in the system, this can't be too difficult a problem to solve: e.g. "manually" rate limit these messages - see printk_ratelimit() et al). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Hypercall invoking
Hi, I added a new hypercall to xen successfully, but when i try to invoke it in dom0 using privcmd, i am unable to invoke (using XC), I must cd to /xen.x.y.z/tools/xcutils and then try to invoke hypercall by XC interface which i created for it. DO functions of hypercall is written in /xen/common/kernel.c. can you give me a clue? Regards. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen does not work after changing scheduler's code
Thanks. would you please tell me what do you mean by top-post? No, A Xen running inside Vmware does not crash until i modified it. it is not because of vmware at all (it may be caused because of my wrong development). in fact when i can understand the performance difference Xen is working on vmware. From: dunl...@gmail.com on behalf of George Dunlap Sent: Monday, May 9, 2016 2:56 PM To: tutu sky Cc: Dario Faggioli; Juergen Gross; Xen-devel@lists.xen.org Subject: Re: [Xen-devel] Xen does not work after changing scheduler's code On Thu, Apr 28, 2016 at 11:46 AM, tutu sky wrote: > > hi Geoge, > I don't get your meaning. would you please repeat your question for me in > order to understand it? First, please don't top-post. My meaning was this: You said that running Xen inside of VMWare caused your host to crash. I said, none of us know much about VMware, and suggested you try Xen inside of Xen. You responded by saying that you thought Xen inside of VMware would be faster. But what good is it if Xen in VMWare is "faster", if it doesn't even work? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Ping: [PATCH] XSA-77: widen scope again
>>> On 09.05.16 at 18:19, wrote: > On 06/05/16 09:12, Jan Beulich wrote: > On 29.04.16 at 11:35, wrote: >>> As discussed on the hackathon, avoid us having to issue security >>> advisories for issues affecting only heavily disaggregated tool stack >>> setups, which no-one appears to use (or else they should step up to get >>> things into shape). >>> >>> Signed-off-by: Jan Beulich >> >> Ping? >> >>> --- >>> As we want to retain supported status of stubdom qemu: Does qemu use >>> any others when use in a stub domain? >>> >>> --- a/docs/misc/xsm-flask.txt >>> +++ b/docs/misc/xsm-flask.txt >>> @@ -59,68 +59,16 @@ http://www.xenproject.org/security-polic >>> >>> __HYPERVISOR_domctl (xen/include/public/domctl.h) >>> >>> - The following subops are covered by this statement. subops not listed >>> - here are considered safe for disaggregation. >>> + All subops except for the following are covered by this statement. > > Sorry I'm just getting to this -- I think the wording is a bit unclear here. > > The previous wording made it clear what "covered by this statement" > means -- i.e., "subops not listed here are considered safe for > disaggregation". > > Maybe something like this: > > "All subops except the following are covered by this statement. (That > is, only the subops below are considered safe for disaggregation.)" Well, I can certainly do this, but to me it states the same thing twice. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] PVL XenNet inf
Hello, In the latest build of XenNet for Windows (April 1st 2016), it does not connect automatically to the network card. I found that the devide IDs are not right in the inf file, they are : XENVIF\VEN_XP0001&DEV_NET&REV_0809 XENVIF\VEN_XP0002&DEV_NET&REV_0809 they should be : XENBUS\VEN_XP0001&DEV_VIF&REV_0809 XENBUS\VEN_XP0002&DEV_VIF&REV_0809 Also, this driver, and the one before that one, both do not start and gives an error 10. Nothing in the logs of Windows, so I do not know what else to do. This virtual computer had GPLPV previously. I'm running xen 4.5.3. -- Best regards, Dominic Russell MSI Bureautique inc. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 44397: regressions - FAIL
-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-armhf-armhf-xl-midway pass test-amd64-amd64-xl-multivcpupass test-armhf-armhf-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrubpass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-armhf-armhf-libvirt-qcow2 fail test-amd64-amd64-xl-qcow2pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass 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 53db932604dfa7bb9241d132e0173894cf54261c Merge: 975eb6a fd3c136 Author: Peter Maydell Date: Mon May 9 13:42:25 2016 +0100 Merge remote-tracking branch 'remotes/kraxel/tags/pull-vga-20160509-1' into staging vga security fixes (CVE-2016-3710, CVE-2016-3712) # gpg: Signature made Mon 09 May 2016 13:39:30 BST using RSA key ID D3E87138 # gpg: Good signature from "Gerd Hoffmann (work) " # gpg: aka "Gerd Hoffmann " # gpg: aka "Gerd Hoffmann (private) " * remotes/kraxel/tags/pull-vga-20160509-1: vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). vga: update vga register setup on vbe changes vga: factor out vga register setup vga: add vbe_enabled() helper vga: fix banked access bounds checking (CVE-2016-3710) Signed-off-by: Peter Maydell commit fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7 Author: Gerd Hoffmann Date: Tue Apr 26 14:48:06 2016 +0200 vga: make sure vga register setup for vbe stays intact (CVE-2016-3712). Call vbe_update_vgaregs() when the guest touches GFX, SEQ or CRT registers, to make sure the vga registers will always have the values needed by vbe mode. This makes sure the sanity checks applied by vbe_fixup_regs() are effective.
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
On 10/05/16 04:18, Dario Faggioli wrote: > [removing Vitaly, adding Juergen] > > On Mon, 2016-05-09 at 17:55 +0100, Lars Kurth wrote: >> >>> On 9 May 2016, at 17:03, George Dunlap >>> wrote: >>> On Mon, May 9, 2016 at 4:28 PM, Lars Kurth >>> wrote: - George: are there any manual tests for credit 2 hard affinity, for hotplug disk backends (drbd, iscsi, &c) and soft reset for HVM guests that should be added? >>> Hard affinity tests shouldn't be too difficult to add in. >> >> That would be great >> > George, if you are not into this already, I can do it. > > One thing (for Lars). There's a section about "-f option for xl vcpu- > pin". I don't see what's its purpose and what and how one should test > this. > > Perhaps Juergen has better ideas, but I think it should just be > removed. +1 The only test I could imagine would be to test whether the "-f" option is accepted. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures
On May 10, 2016 12:14 AM, Jan Beulich wrote: > >>> On 06.05.16 at 10:54, wrote: > > --- a/xen/drivers/passthrough/iommu.c > > +++ b/xen/drivers/passthrough/iommu.c > > @@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d, > unsigned long gfn, unsigned long mfn, > > unsigned int flags) { > > const struct domain_iommu *hd = dom_iommu(d); > > +int rc; > > > > if ( !iommu_enabled || !hd->platform_ops ) > > return 0; > > > > -return hd->platform_ops->map_page(d, gfn, mfn, flags); > > +rc = hd->platform_ops->map_page(d, gfn, mfn, flags); > > + > > +if ( unlikely(rc) ) > > +{ > > +printk(XENLOG_ERR > > + "iommu_map_page: IOMMU mapping gfn %#lx mfn %#lx failed for > dom%d.", > > + gfn, mfn, d->domain_id); > > + > > +if ( !is_hardware_domain(d) ) > > +domain_crash(d); > > +} > > This still may spam the console in at least the case of Dom0. I am afraid we may need a minor trade-off. What about: dprintk(XENLOG_ERR, "..."); to print out in debug mode. > For DomU I'd > really expect you to state in the commit message why no spamming can occur > (of course assuming it really can't, which I'm not convinced of). > In this v4, I think we will still spam the console in extreme cases :(:(.. For mapping: +ret = iommu_map_page(); +if ( unlikely(ret) ) +{ +while ( i-- ) +iommu_unmap_page(); +} We'll stop map against any error and unmapping the previous mappings. The extreme case is error for unmapping the previous mappings. Again -- I think dprintk is a better solution. Any suggestion? Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
On 5/9/16 10:28 AM, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are on > the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: > > I do have some questions, to ... > - Konrad/Ross: is there any documentation for xSplice which I have missed? > - Julien: Any ARM specific stuff you want people to test? > - Doug: are there any docs / tests for KCONFIG you want to push Not at this time. Unless someone has an idea for what they'd like to see and I'll go off and do it. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
>>> On 5/9/2016 at 11:28 PM, in message <6db04875-03d4-4542-b06c-2b0412d08...@gmail.com>, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are > on the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: > > I do have some questions, to ... > - Konrad/Ross: is there any documentation for xSplice which I have missed? > - Julien: Any ARM specific stuff you want people to test? > - Doug: are there any docs / tests for KCONFIG you want to push > - George: are there any manual tests for credit 2 hard affinity, for hotplug > disk backends (drbd, iscsi, &c) and soft reset for HVM guests that should be > added? > > For the following sections there are some TODO's - please verify and modify > and once OK, remove the TODO from the wiki pages. > > VCPU-PIN (Juergen Gross) > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#-f_option_for_xl > _vcpu-pin > > RTDS (Meng Xu, Chong Li) > - Meng, you mention improvements to the RTDS scheduler in another thread > - Are any specific test instructions needed in > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RTDS_scheduler_i > mprovements > > COLO (Wen Congyang) > - http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#COLO_-_Coarse_Gr > ain_Lock_Stepping > > USB (Chunyan Liu) > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#USB_Support_for_ > xl > - http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB > - http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB_in_xl.2Flibxl Updated! - Chunyan > CDP (He Chen) > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Intel_Code_and_D > ata_Prioritization_.28CDP.29 > - > http://wiki.xenproject.org/wiki/Intel_Platform_QoS_Technologies#Code_and_Data > _Prioritization_.28CDP.29 > > Are there any other big items that are missing? > > Regards > Lars > > > On 5 May 2016, at 18:08, Lars Kurth wrote: > > > > Hi everyone, > > > > I updated http://wiki.xenproject.org/wiki/Xen_Project_Test_Days and created > > > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions (note that we > only have one page for all RC's now to avoid unnecessary copy and pasting). > > > > For those who want new features to be tested, please expect to > > a) Explain what to test (a very short description of the feature) > > b) Add some instructions on how to test (e.g. some command line > instructions) > > > > You can add a new headline (an example is marked with TODO) to either > > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_ARM_Tes > t_Instructions > > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_x86_Tes > t_Instructions > > - OR > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RC_specific_thin > gs_to_test (under a specific RC heading) > > > > I will start promoting Test Days from early next week (on the blog, but > also on the mailing lists). The more specific test instructions for Xen 4.7 > related features, the better the coverage will be and the more likely people > are to actually test. > > > > Best Regards > > Lars > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
[removing Vitaly, adding Juergen] On Mon, 2016-05-09 at 17:55 +0100, Lars Kurth wrote: > > > On 9 May 2016, at 17:03, George Dunlap > > wrote: > > On Mon, May 9, 2016 at 4:28 PM, Lars Kurth > > wrote: > > > > > > - George: are there any manual tests for credit 2 hard affinity, > > > for hotplug disk backends (drbd, iscsi, &c) and soft reset for > > > HVM guests that should be added? > > Hard affinity tests shouldn't be too difficult to add in. > > That would be great > George, if you are not into this already, I can do it. One thing (for Lars). There's a section about "-f option for xl vcpu- pin". I don't see what's its purpose and what and how one should test this. Perhaps Juergen has better ideas, but I think it should just be removed. 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 http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-unstable test] 93919: regressions - FAIL
flight 93919 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/93919/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 92434 test-armhf-armhf-xl-vhd 14 guest-start/debian.repeat fail REGR. vs. 92434 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92434 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 92434 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 92434 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 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-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-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-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass version targeted for testing: qemuu62b3d206425c245ed0a020390a64640d40d97471 baseline version: qemuuae69b059498e8a563c6d64c4aa4cb95e53d76680 Last test of basis92434 2016-04-23 06:47:22 Z 16 days Testing same since93919 2016-05-09 16:44:00 Z0 days1 attempts People who touched revisions under test: Gerd Hoffmann 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 pass test-amd64-amd64-
[Xen-devel] [ovmf test] 93918: regressions - FAIL
flight 93918 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93918/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 65543 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 build-amd64-xsm 5 xen-build fail REGR. vs. 65543 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 9f64a83484ed99f1d98df1487ba39776d30d24d8 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 153 days Failing since 65593 2015-12-08 23:44:51 Z 153 days 251 attempts Testing same since93918 2016-05-09 15:47:59 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Abdul Lateef Attar Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy chenzhihui Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin Dong, Eric edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hegde, Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas Michael Zimmermann MichaŠZegan Nagaraj Hegde Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Sunny Wang Supreeth Venkatesh Tapan Shah Thomas Palmer Tian Feng Tian, Feng Vladislav Vovchenko Volker Rümelin Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 23275 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
On 2016/5/10 0:17, Julien Grall wrote: > (CC Shannon, Stefano and Steve) > > Hi Lars, > > On 09/05/16 16:28, Lars Kurth wrote: >> Hi all, >> >> I added the following sections based on git logs to man pages. Authors >> are on the CC list and should review and modify (or suggest edits by >> replying to this thread). I added/updated/added TODO's to: >> >> I do have some questions, to ... >> - Konrad/Ross: is there any documentation for xSplice which I have >> missed? >> - Julien: Any ARM specific stuff you want people to test? > > General testing of Xen on the boards we are supporting. > > We may also want some testing on ACPI, which will be in tech preview for > Xen 4.7. However this is requiring platform with ACPI 6.0 (or later). If > I remember correctly, none of the ARM64 platform we support fulfill this > requirement. Steve, do you have any platform in mind? > > Shannon, which platform have you used for the ACPI development? Was it > the Foundation Model? > The AEMv8A model. > If so we would need to write down (or update) a wiki page with the > instructions to boot Xen on the model. > There is a wiki page[1] written by Parth. It needs to update it. [1] https://wiki.linaro.org/LEG/Engineering/Xen_boot_on_FVP_ACPI_UEFI Thanks, -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3] libxl: support Xen migration stream V2
On 05/03/2016 07:19 AM, Wei Liu wrote: > On Mon, May 02, 2016 at 07:01:16PM -0600, Jim Fehlig wrote: >> Hi all, >> >> This patch adds support for Xen migration stream V2 to the libvirt >> libxl driver. In the process it fixes save/restore and migration >> tests in OSSTest, which have been failing since libvirt commit >> e7440656. >> >> Patch1 changes the libxl API requirement from version 4.2 to 4.4, >> enabling use of an extended libxl_domain_create_restore() function >> that allows passing restore parameters such as stream version. >> >> Patch2 adds support for migration stream V2 in the basic save/restore >> logic, taking advantage of a save image header that includes a version >> field. The version is set to '2' if the host produces a V2 migration >> stream. This patch fixes the failing save/restore tests in OSSTest. >> >> Patch3 adds support for migration stream V2 in the migration logic. >> The migration code does not use the save image header and instead >> uses libvirt's migration protocol to transfer domain configuration >> and other such goodies from source to destination. The patch >> enables sending version information in the Begin and Prepare >> migration phases so the correct stream version information can be >> passed to libxl_domain_create_restore(). An upshot of this approach >> is safely detecting and aborting a migration from a V2 host to a >> V1-only host. This patch fixes the failing migration tests in >> OSSTest. >> > The general approach looks good to me. Any comments on this series from libvirt maintainers? Would be nice to get this series (or a variant) committed, fixing the daily OSSTest failures. For your viewing pleasure, here's a link to today's failure http://logs.test-lab.xenproject.org/osstest/logs/93880/ Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 93910: tolerable FAIL - PUSHED
flight 93910 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/93910/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93374 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 93374 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 93374 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-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-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuu53db932604dfa7bb9241d132e0173894cf54261c baseline version: qemuu975eb6a547f809608ccb08c221552f11af25 Last test of basis93374 2016-05-02 21:13:00 Z7 days Testing same since93910 2016-05-09 13:13:01 Z0 days1 attempts People who touched revisions under test: Gerd Hoffmann Peter Maydell jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-
Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes
On 05/09/2016 10:35 AM, Ian Jackson wrote: > Ian Jackson writes ("Re: [Xen-devel] [PATCH] tools: Restrict configuration of > qemu processes"): >> Jim Fehlig writes ("[Xen-devel] [PATCH] tools: Restrict configuration of >> qemu processes"): >>> Commit 6ef823fd added '-nodefaults' to the qemu args created by >>> libxl, which is a good step in restricting qemu's default >>> configuration. This change takes another step by adding >>> -no-user-config, which ignores any user-provided config files in >>> sysconfdir. Together, -nodefaults and -no-user-config allow Xen >>> to avoid unkown and uncontrolled qemu configuration. >>> >>> Both options are also added to the qemu invocation in the >>> xen-qemu-dom0-disk-backend systemd service file. >> Queued, thanks. Also listed for backport. > I found this on my backport todo list. Thinking about it, I have had > second thoughts. > > I worry that existing users of stable branches might be relying on the > user config feature (for example by dropping qemu configuration in > ~root). If they are, then applying this would break things for them. > > It's not a security problem because in xen the configuration in > question would have to come from ~root. Good point. > So I think, probably, that we should leave this be (ie, not backport > the patch). Does anyone want to try to change my mind ? I never asked for a backport, so have no incentive to change your mind. Plus, I agree with your comment. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 93903: trouble: broken/fail/pass
flight 93903 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/93903/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 92181 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 92181 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 92181 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 92181 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 92181 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92181 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 92181 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-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 12 migrate-support-checkfail never pass test-armhf-armhf-xl 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-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-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-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 9a9c5095ce1e4b829f1a35df8b7f621c1f9366c7 baseline version: xen c0cfb7220a8426dc3fad40aa33aa8fe9e9e096b4 Last test of basis92181 2016-04-20 17:50:26 Z 19 days Testing same since93903 2016-05-09 11:10:11 Z0 days1 attempts People who touched revisions under test: Andrew Cooper George Dunlap Jan Beulich Mike Meyer Olaf Hering Stefano Stabellini Tim Deegan jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops
Re: [Xen-devel] [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
On 04/05/2016 09:25 PM, Boris Ostrovsky wrote: > This is an RFC for making hvmloader's ACPI builder available to both the > toolstack and the hypervisor, as discussed in > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html When do people think they will get a chance to comment on this? Should this wait until after 4.7 is released? Thanks. -boris > The series > * Removes dependency of today's builder on hvmloader interfaces > * Makes many of the tables built optionally. > * Moves tools/hvmloader/acpi directory to xen/common/libacpi > * Builds tables for PVHv2 domU guests in libxc > > There is still a number of questions about this implementation, thus it's > an RFC. Examples of things that need to be discussed are > > * ACPI tables are built for PVHv2 guests unconditionally. We probably want > to make this an option. > * Not sure about header files, especially xen/common/libacpi/x86.h and > tools/firmware/hvmloader/{stdio.h,string.h} > * The builder is compiled into the hypervisor even though currently > there are no users (PVHv2 dom0 will be the one) > * Patch 19 is somewhat of a spec violation > * Makefiles are questionable > * May need changes to guests' e820 map > > This is also available from > git://oss.oracle.com/git/bostrovs/xen.git:acpi_rfc. > > It has been tested with Linux PVHv2 (and I believe Roger tested an earlier > version with FreeBSD). No passthrough testing has been done. > > (I realize that many people are busy because of Friday's freeze but I figured > I'd > post it now in the hope that this may get some reading so that we can talk > about > it at the hackathon) > > > Boris Ostrovsky (20): > hvmloader: Provide hvmloader_acpi_build_tables() > acpi/hvmloader: Move acpi_info initialization out of ACPI code > acpi/hvmloader: Initialize vm_gid data outside ACPI code > acpi/hvmloader: Decide which SSDTs to build in hvmloader > acpi/hvmloader: Move passthrough initialization from ACPI code > acpi/hvmloader: Collect processor and NUMA info in hvmloader > acpi/hvmloader: Set TIS header address in hvmloader > acpi/hvmloader: Make providing IOAPIC in MADT optional > acpi/hvmloader: Build WAET optionally > acpi/hvmloader: Provide address of acpi_info as an argument to ACPI > code > acpi/hvmloader: Translate all addresses when assigning addresses in > ACPI tables > acpi/hvmloader: Link ACPI object files directly > acpi/hvmloader: Add stdio.h, string.h and x86.h > acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops > acpi: Move ACPI code to xen/common/libacpi > x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic() > x86: Allow LAPIC-only emulation_flags for HVM guests > libxc/acpi: Build ACPI tables for HVMlite guests > acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported > acpi: Make ACPI builder available to hypervisor code > > .gitignore | 8 +- > tools/firmware/hvmloader/Makefile | 16 +- > tools/firmware/hvmloader/config.h | 13 +- > tools/firmware/hvmloader/hvmloader.c | 3 +- > tools/firmware/hvmloader/mp_tables.c | 1 + > tools/firmware/hvmloader/ovmf.c| 4 +- > tools/firmware/hvmloader/pci.c | 1 + > tools/firmware/hvmloader/pir.c | 1 + > tools/firmware/hvmloader/rombios.c | 4 +- > tools/firmware/hvmloader/seabios.c | 4 +- > tools/firmware/hvmloader/smbios.c | 1 + > tools/firmware/hvmloader/smp.c | 1 + > tools/firmware/hvmloader/stdio.h | 7 + > tools/firmware/hvmloader/string.h | 7 + > tools/firmware/hvmloader/util.c| 85 + > tools/firmware/hvmloader/util.h| 6 +- > tools/firmware/rombios/32bit/Makefile | 2 +- > tools/firmware/rombios/32bit/tcgbios/Makefile | 2 +- > tools/firmware/rombios/32bit/util.h| 2 +- > tools/libxc/Makefile | 22 +- > tools/libxc/include/xc_dom.h | 1 + > tools/libxc/xc_acpi.c | 268 + > tools/libxc/xc_dom_x86.c | 7 + > tools/libxl/libxl_x86.c| 19 +- > xen/arch/x86/domain.c | 26 +- > xen/arch/x86/hvm/vlapic.c | 3 + > xen/common/Makefile| 2 +- > .../hvmloader/acpi => xen/common/libacpi}/Makefile | 33 +- > .../hvmloader/acpi => xen/common/libacpi}/README | 0 > .../acpi => xen/common/libacpi}/acpi2_0.h | 66 +++- > .../hvmloader/acpi => xen/common/libacpi}/build.c | 415 > ++--- > .../hvmloader/acpi => xen/common/libacpi}/dsdt.asl | 0 > xen/common/libacpi/dsdt_empty.asl |
[Xen-devel] [xen-4.5-testing test] 93905: regressions - FAIL
flight 93905 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/93905/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-build fail REGR. vs. 92345 build-amd64-pvops 5 kernel-build fail REGR. vs. 92345 build-amd64-prev 5 xen-build fail REGR. vs. 92345 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail like 92182 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a build-amd64-rumpuserxen 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass t
Re: [Xen-devel] [PATCH v2 for-4.7 4/5] x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept()
On 05/09/2016 02:27 PM, Andrew Cooper wrote: > paging_invlpg() already returns a boolean indicating whether an invalidation > is necessary or not. A return value of 0 indicates that the specified virtual > address wasn't shadowed (or has already been flushed), cannot currently be > cached in the TLB. > > This is a performance optimisation. > > Signed-off-by: Andrew Cooper Reviewed-by: Boris Ostrovsky > --- > CC: Jan Beulich > CC: Tim Deegan > CC: Wei Liu > CC: Boris Ostrovsky > CC: Suravee Suthikulpanit > > While being a performance optimisation, the main purpose of splitting this > patch out is to separate the functional change. The following patch performs > some function shuffling, and this patch makes the following one more obviously > correct. > > v2: > * Newly split out > --- > xen/arch/x86/hvm/svm/svm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 7634c3f..081a5d8 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -2224,8 +2224,8 @@ static void svm_invlpg_intercept(unsigned long vaddr) > { > struct vcpu *curr = current; > HVMTRACE_LONG_2D(INVLPG, 0, TRC_PAR_LONG(vaddr)); > -paging_invlpg(curr, vaddr); > -svm_asid_g_invlpg(curr, vaddr); > +if ( paging_invlpg(curr, vaddr) ) > +svm_asid_g_invlpg(curr, vaddr); > } > > static struct hvm_function_table __initdata svm_function_table = { ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.7 5/5] x86/hvm: Fix invalidation for emulated invlpg instructions
On 05/09/2016 02:27 PM, Andrew Cooper wrote: > hap_invlpg() is reachable from the instruction emulator, which means > introspection and tests using hvm_fep can end up here. As such, crashing the > domain is not an appropriate action to take. > > Fixing this involves rearranging the callgraph. > > paging_invlpg() is now the central entry point. It first checks for the > non-canonical NOP case, and calls ino the paging subsystem. If a real flush > is needed, it will call the appropriate handler for the vcpu. This allows the > PV callsites of paging_invlpg() to be simplified. > > The sole user of hvm_funcs.invlpg_intercept() is altered to use > paging_invlpg() instead, allowing the .invlpg_intercept() hook to be removed. > > For both VMX and SVM, the existing $VENDOR_invlpg_intercept() is split in > half. $VENDOR_invlpg_intercept() stays as the intercept handler only (which > just calls paging_invlpg()), and new $VENDOR_invlpg() functions do the > ASID/VPID management. These later functions are made available in hvm_funcs > for paging_invlpg() to use. > > As a result, correct ASID/VPID management occurs for the hvmemul path, even if > it did not originate from an real hardware intercept. > > Signed-off-by: Andrew Cooper Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 93921: tolerable all pass - PUSHED
flight 93921 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/93921/ 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 2656bc7b0c145932e1af80d54d48975edd081997 baseline version: xen 4084fee7a3204bf8ccf7d993dea09186e4e7dd48 Last test of basis93911 2016-05-09 14:01:17 Z0 days Testing same since93921 2016-05-09 17:01:17 Z0 days1 attempts People who touched revisions under test: Dario Faggioli George Dunlap 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=2656bc7b0c145932e1af80d54d48975edd081997 + . ./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 2656bc7b0c145932e1af80d54d48975edd081997 + branch=xen-unstable-smoke + revision=2656bc7b0c145932e1af80d54d48975edd081997 + . ./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.6-testing + '[' x2656bc7b0c145932e1af80d54d48975edd081997 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=' x ']' +++ echo 'git://cache:
Re: [Xen-devel] [PATCH for-qemu-trad] Fix build with newer version of GNUTLS
On Thu, May 05, 2016 at 11:14:44AM +0100, Wei Liu wrote: > gnutls_kx_set_priority, gnutls_certificate_type_set_priority and > gnutls_protocol_set_priority were deprecated and eventually removed in > GNUTLS 3.4. Application should use gnutls_priority_set_direct instead > per [0]. > > gnutls_anon_server_credentials was deprecated at some point. Application > should use gnutls_anon_server_credentials_t instead. > > Provide compatibility layer for QEMU traditional. This commit is in fact > backport of two upstream QEMU commits: > 1. f40d55081667a716312b9a8b6e13835c4074f56b > 2. 7d2a929feba319c18603e324b1750830d6c8b7a1 > > [0] > https://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html > > Signed-off-by: Sjoer van der Ploeg > Signed-off-by: Wei Liu Tested-by: Konrad Rzeszutek Wilk on gnutls-3.4.9-1.fc23.x86_64 And it fixes the build problems. > --- > vnc.c | 71 > +-- > 1 file changed, 48 insertions(+), 23 deletions(-) > > diff --git a/vnc.c b/vnc.c > index 573af3b..61d1555 100644 > --- a/vnc.c > +++ b/vnc.c > @@ -1925,9 +1925,9 @@ static int vnc_tls_initialize(void) > return 1; > } > > -static gnutls_anon_server_credentials vnc_tls_initialize_anon_cred(void) > +static gnutls_anon_server_credentials_t vnc_tls_initialize_anon_cred(void) > { > -gnutls_anon_server_credentials anon_cred; > +gnutls_anon_server_credentials_t anon_cred; > int ret; > > if ((ret = gnutls_anon_allocate_server_credentials(&anon_cred)) < 0) { > @@ -2151,13 +2151,52 @@ static void vnc_handshake_io(void *opaque) { > (vs)->subauth == VNC_AUTH_VENCRYPT_X509VNC ||\ > (vs)->subauth == VNC_AUTH_VENCRYPT_X509PLAIN) > > +#if defined(GNUTLS_VERSION_NUMBER) && \ > +GNUTLS_VERSION_NUMBER >= 0x020200 /* 2.2.0 */ > +static int vnc_set_gnutls_priority(gnutls_session_t s, int x509) > +{ > +const char *priority = x509 ? "NORMAL" : "NORMAL:+ANON-DH"; > +int rc; > > -static int vnc_start_tls(struct VncState *vs) { > -static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 }; > -static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, > GNUTLS_SSL3, 0 }; > -static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0}; > -static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, > GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0}; > +rc = gnutls_priority_set_direct(s, priority, NULL); > +if (rc != GNUTLS_E_SUCCESS) { > +return -1; > +} > +return 0; > +} > +#else > +static int vnc_set_gnutls_priority(gnutls_session_t s, int x509) > +{ > +static const int cert_types[] = { GNUTLS_CRT_X509, 0 }; > +static const int protocols[] = { > +GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 > +}; > +static const int kx_anon[] = { GNUTLS_KX_ANON_DH, 0 }; > +static const int kx_x509[] = { > +GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, > +GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0 > +}; > +int rc; > + > +rc = gnutls_kx_set_priority(s, x509 ? kx_x509 : kx_anon); > +if (rc != GNUTLS_E_SUCCESS) { > +return -1; > +} > + > +rc = gnutls_certificate_type_set_priority(s, cert_types); > +if (rc != GNUTLS_E_SUCCESS) { > +return -1; > +} > > +rc = gnutls_protocol_set_priority(s, protocols); > +if (rc != GNUTLS_E_SUCCESS) { > +return -1; > +} > +return 0; > +} > +#endif > + > +static int vnc_start_tls(struct VncState *vs) { > VNC_DEBUG("Do TLS setup\n"); > if (vnc_tls_initialize() < 0) { > VNC_DEBUG("Failed to init TLS\n"); > @@ -2177,21 +2216,7 @@ static int vnc_start_tls(struct VncState *vs) { > return -1; > } > > - if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? > kx_x509 : kx_anon) < 0) { > - gnutls_deinit(vs->tls_session); > - vs->tls_session = NULL; > - vnc_client_error(vs); > - return -1; > - } > - > - if (gnutls_certificate_type_set_priority(vs->tls_session, > cert_type_priority) < 0) { > - gnutls_deinit(vs->tls_session); > - vs->tls_session = NULL; > - vnc_client_error(vs); > - return -1; > - } > - > - if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < > 0) { > + if (vnc_set_gnutls_priority(vs->tls_session, !!NEED_X509_AUTH(vs)) < 0) > { > gnutls_deinit(vs->tls_session); > vs->tls_session = NULL; > vnc_client_error(vs); > @@ -2219,7 +2244,7 @@ static int vnc_start_tls(struct VncState *vs) { > } > > } else { > - gnutls_anon_server_credentials anon_cred = > vnc_tls_initialize_anon_cred(); > + gnutls_anon_server_credentials_t anon_cred = > vnc_tls_initialize_anon_cred(); > if (!anon_cred) { > gnutls_deinit(vs->tls_session); > vs->tls_session = NULL; > -- > 2.1.4 > > > ___ > Xen-d
Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24
On 05/09/2016 01:22 PM, Kevin Moraga wrote: > > On 05/09/2016 11:15 AM, Boris Ostrovsky wrote: >> On 05/09/2016 12:40 PM, Kevin Moraga wrote: >>> On 05/09/2016 09:53 AM, Jan Beulich wrote: >>> On 09.05.16 at 16:52, wrote: > On 05/09/2016 04:08 AM, Jan Beulich wrote: > On 09.05.16 at 00:51, wrote: >>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 >>> and Intel Skylake processor (Intel Core i7-6600U) >>> >>> This kernel is crashing almost in the same way as explained in this >>> thread... But my problem is mainly with Skylake. Because the same >>> configuration works within another machine but with another processor >>> (Intel Core i5-3340M). Attached are the boot logs. >> The address the fault occurs on (806bdee0) is bogus, so >> from the register and stack dump alone I don't think we can derive >> much. What we'd need is access to the kernel binary used (or >> really the vmlinux accompanying the vmlinuz that was used), in >> order to see where exactly the kernel died, and hence where this >> bogus address originates from. As I understand it this is a kernel >> you built yourself - can you make said binary from exactly that >> build available somewhere? > Yes I have it. But I get the same crash on various 4.4.X and also with > 4.5.3. > > **https://drive.google.com/open?id=0B6Ol0ob95UxXQV9HM1BWMmhCZ0E Well, this doesn't contain the file I'm after (vmlinux), and taking apart vmlinuz would be quite cumbersome. Jan >>> Oh sorry, here is the link to vmlinux >>> >>> https://drive.google.com/file/d/0B6Ol0ob95UxXN0dDMWM1a29vMEk/view?usp=sharing >> This is still vmlinuz but the failure is at >> >> 81007ef3: 48 3b 1d 4e 2e ec 00cmp >> 0xec2e4e(%rip),%rbx# 0x81ecad48 >> 81007efa: 73 51 jae0x81007f4d >> 81007efc: 31 c0 xor%eax,%eax >> 81007efe: 48 8b 15 03 d2 c0 00mov >> 0xc0d203(%rip),%rdx# 0x81c15108 >> 81007f05: 90 nop >> 81007f06: 90 nop >> 81007f07: 90 nop >> 81007f08: 4c 8b 2c da mov >> (%rdx,%rbx,8),%r13<== >> 81007f0c: 90 nop >> 81007f0d: 90 nop >> 81007f0e: 90 nop >> 81007f0f: 85 c0 test %eax,%eax >> 81007f11: 78 3a js 0x81007f4d >> 81007f13: 48 8b 05 ee 11 d2 00mov >> 0xd211ee(%rip),%rax# 0x81d29108 >> 81007f1a: 49 39 c5cmp%rax,%r13 >> 81007f1d: 73 6f jae0x81007f8e >> 81007f1f: 48 8b 05 ea 11 d2 00mov >> 0xd211ea(%rip),%rax# 0x81d29110 >> 81007f26: 4a 8b 04 e8 mov(%rax,%r13,8),%rax >> >> Any chance you could provide an un-stripped binary or System.map? > Here is the link for System.map > > https://drive.google.com/file/d/0B6Ol0ob95UxXYVE4SzdMcENsWWs/view?usp=sharing > So my semi-educated guess at your stack is __early_ioremap -> __early_set_fixmap -> set_pte -> xen_set_pte_init -> mask_rw_pte -> pte_pfn -> pte_val -> xen_pte_val -> pte_mfn_to_pfn -> mfn_to_pfn_no_overrides -> ret = xen_safe_read_ulong(&machine_to_phys_mapping[mfn], &pfn) With 81007f08 being the faulted address the last one looks plausible: 81007efe: 48 8b 15 03 d2 c0 00mov 0xc0d203(%rip),%rdx# 0x81c15108 81007f05: 90 nop 81007f06: 90 nop 81007f07: 90 nop 81007f08: 4c 8b 2c da mov(%rdx,%rbx,8),%r13 since ostr@workbase> grep 81c15108 /tmp/System.map-4.4.8-9.pvops.qubes.x86_64 81c15108 D machine_to_phys_mapping ostr@workbase> But %rdx is not 81c15108, it is 8000: (XEN) rax: rbx: 000d7bdc rcx: 880002059000 (XEN) rdx: 8000 rsi: 8000d7bdc063 rdi: 8000d7bdc063 Perhaps we jumped to 81007f08 from somewhere, but I can't 81007f0* as a target anywhere. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 for-4.7 2/5] x86/hvm: Raise #SS faults for %ss-based segmentation violations
Raising #GP under such circumstances is architecturally wrong. (Refer to the Intel or AMD manuals describing the conditions under which the Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Tim Deegan --- CC: Paul Durrant CC: Wei Liu v2: * Clarified the commit message. --- xen/arch/x86/hvm/emulate.c | 3 ++- xen/arch/x86/mm/shadow/common.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index be1e7c2..ee5cf1f 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -566,7 +566,8 @@ static int hvmemul_virtual_to_linear( /* This is a singleton operation: fail it with an exception. */ hvmemul_ctxt->exn_pending = 1; -hvmemul_ctxt->trap.vector = TRAP_gp_fault; +hvmemul_ctxt->trap.vector = +(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault; hvmemul_ctxt->trap.type = X86_EVENTTYPE_HW_EXCEPTION; hvmemul_ctxt->trap.error_code = 0; hvmemul_ctxt->trap.insn_len = 0; diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c index 559d4a4..226e32d 100644 --- a/xen/arch/x86/mm/shadow/common.c +++ b/xen/arch/x86/mm/shadow/common.c @@ -148,7 +148,8 @@ static int hvm_translate_linear_addr( if ( !okay ) { -hvm_inject_hw_exception(TRAP_gp_fault, 0); +hvm_inject_hw_exception( +(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault, 0); return X86EMUL_EXCEPTION; } -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 for-4.7 1/5] x86/hvm: Always return the linear address from hvm_virtual_to_linear_addr()
Some callers need the linear address (with appropriate segment base), whether or not the limit or canonical check succeeds. While modifying the function, change the return type to bool_t to match its semantics. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Wei Liu --- xen/arch/x86/hvm/hvm.c| 37 +++-- xen/include/asm-x86/hvm/hvm.h | 2 +- 2 files changed, 24 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 82e2ed1..863d134 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -2411,7 +2411,7 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer) return X86EMUL_EXCEPTION; } -int hvm_virtual_to_linear_addr( +bool_t hvm_virtual_to_linear_addr( enum x86_segment seg, struct segment_register *reg, unsigned long offset, @@ -2421,6 +2421,7 @@ int hvm_virtual_to_linear_addr( unsigned long *linear_addr) { unsigned long addr = offset, last_byte; +bool_t okay = 0; if ( !(current->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) ) { @@ -2431,7 +2432,7 @@ int hvm_virtual_to_linear_addr( addr = (uint32_t)(addr + reg->base); last_byte = (uint32_t)addr + bytes - !!bytes; if ( last_byte < addr ) -return 0; +goto out; } else if ( addr_size != 64 ) { @@ -2439,15 +2440,21 @@ int hvm_virtual_to_linear_addr( * COMPATIBILITY MODE: Apply segment checks and add base. */ +/* + * Hardware truncates to 32 bits in compatibility mode. + * It does not truncate to 16 bits in 16-bit address-size mode. + */ +addr = (uint32_t)(addr + reg->base); + switch ( access_type ) { case hvm_access_read: if ( (reg->attr.fields.type & 0xa) == 0x8 ) -return 0; /* execute-only code segment */ +goto out; /* execute-only code segment */ break; case hvm_access_write: if ( (reg->attr.fields.type & 0xa) != 0x2 ) -return 0; /* not a writable data segment */ +goto out; /* not a writable data segment */ break; default: break; @@ -2464,16 +2471,10 @@ int hvm_virtual_to_linear_addr( /* Check first byte and last byte against respective bounds. */ if ( (offset <= reg->limit) || (last_byte < offset) ) -return 0; +goto out; } else if ( (last_byte > reg->limit) || (last_byte < offset) ) -return 0; /* last byte is beyond limit or wraps 0x */ - -/* - * Hardware truncates to 32 bits in compatibility mode. - * It does not truncate to 16 bits in 16-bit address-size mode. - */ -addr = (uint32_t)(addr + reg->base); +goto out; /* last byte is beyond limit or wraps 0x */ } else { @@ -2487,11 +2488,19 @@ int hvm_virtual_to_linear_addr( last_byte = addr + bytes - !!bytes; if ( !is_canonical_address(addr) || last_byte < addr || !is_canonical_address(last_byte) ) -return 0; +goto out; } +/* All checks ok. */ +okay = 1; + + out: +/* + * Always return the correct linear address, even if a permission check + * failed. The permissions failure is not relevant to some callers. + */ *linear_addr = addr; -return 1; +return okay; } struct hvm_write_map { diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h index 7b7ff3f..add6ee8 100644 --- a/xen/include/asm-x86/hvm/hvm.h +++ b/xen/include/asm-x86/hvm/hvm.h @@ -471,7 +471,7 @@ enum hvm_access_type { hvm_access_read, hvm_access_write }; -int hvm_virtual_to_linear_addr( +bool_t hvm_virtual_to_linear_addr( enum x86_segment seg, struct segment_register *reg, unsigned long offset, -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 for-4.7 3/5] x86/hvm: Correct the emulated interaction of invlpg with segments
The `invlpg` instruction is documented to take a memory address, and is not documented to suffer faults from segmentation violations. It is also explicitly documented to be a NOP when issued on a non-canonical address. Experimentally, and subsequently confirmed by both Intel and AMD, the instruction does take into account segment bases, but will happily invalidate a TLB entry for a mapping beyond the segment limit. The emulation logic will currently raise #GP/#SS faults for segment limit violations, or non-canonical addresses, which doesn't match hardware's behaviour. Instead, squash exceptions generated by hvmemul_virtual_to_linear() and proceed with invalidation. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Reviewed-by: Paul Durrant --- CC: Wei Liu --- xen/arch/x86/hvm/emulate.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index ee5cf1f..e6316be 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -1608,7 +1608,22 @@ static int hvmemul_invlpg( rc = hvmemul_virtual_to_linear( seg, offset, 1, &reps, hvm_access_none, hvmemul_ctxt, &addr); -if ( rc == X86EMUL_OKAY ) +if ( rc == X86EMUL_EXCEPTION ) +{ +/* + * `invlpg` takes segment bases into account, but is not subject to + * faults from segment type/limit checks, and is specified as a NOP + * when issued on non-canonical addresses. + * + * hvmemul_virtual_to_linear() raises exceptions for type/limit + * violations, so squash them. + */ +hvmemul_ctxt->exn_pending = 0; +hvmemul_ctxt->trap = (struct hvm_trap){}; +rc = X86EMUL_OKAY; +} + +if ( rc == X86EMUL_OKAY && is_canonical_address(addr) ) hvm_funcs.invlpg_intercept(addr); return rc; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 for-4.7 0/5] Fixes for invlpg handling for HVM guests
Turns out there are a lot of broken corner cases. Changes in v2: * Some improvements to commit messages * Split part of the original patch 4 out, to make the new patch 5 clearer * Add vcpu parameter to new invlpg() function, and avoid assuming 'current' * Modify paging_invlpg() to be void, and issue the PV TLB flush as well Andrew Cooper (5): x86/hvm: Always return the linear address from hvm_virtual_to_linear_addr() x86/hvm: Raise #SS faults for %ss-based segmentation violations x86/hvm: Correct the emulated interaction of invlpg with segments x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept() x86/hvm: Fix invalidation for emulated invlpg instructions xen/arch/x86/hvm/emulate.c | 20 ++-- xen/arch/x86/hvm/hvm.c | 37 +++-- xen/arch/x86/hvm/svm/svm.c | 11 +++ xen/arch/x86/hvm/vmx/vmx.c | 14 +- xen/arch/x86/mm.c | 24 ++-- xen/arch/x86/mm/hap/hap.c | 23 ++- xen/arch/x86/mm/shadow/common.c | 3 ++- xen/include/asm-x86/hvm/hvm.h | 4 ++-- xen/include/asm-x86/paging.h| 11 ++- 9 files changed, 91 insertions(+), 56 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 for-4.7 5/5] x86/hvm: Fix invalidation for emulated invlpg instructions
hap_invlpg() is reachable from the instruction emulator, which means introspection and tests using hvm_fep can end up here. As such, crashing the domain is not an appropriate action to take. Fixing this involves rearranging the callgraph. paging_invlpg() is now the central entry point. It first checks for the non-canonical NOP case, and calls ino the paging subsystem. If a real flush is needed, it will call the appropriate handler for the vcpu. This allows the PV callsites of paging_invlpg() to be simplified. The sole user of hvm_funcs.invlpg_intercept() is altered to use paging_invlpg() instead, allowing the .invlpg_intercept() hook to be removed. For both VMX and SVM, the existing $VENDOR_invlpg_intercept() is split in half. $VENDOR_invlpg_intercept() stays as the intercept handler only (which just calls paging_invlpg()), and new $VENDOR_invlpg() functions do the ASID/VPID management. These later functions are made available in hvm_funcs for paging_invlpg() to use. As a result, correct ASID/VPID management occurs for the hvmemul path, even if it did not originate from an real hardware intercept. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Paul Durrant CC: George Dunlap CC: Tim Deegan CC: Jun Nakajima CC: Kevin Tian CC: Boris Ostrovsky CC: Suravee Suthikulpanit CC: Wei Liu v2: * Split performance improvement for AMD into previous patch * Add vcpu parameter to new invlpg() function, and avoid assuming 'current' * Modify paging_invlpg() to be void, and issue the PV TLB flush as well --- xen/arch/x86/hvm/emulate.c| 4 ++-- xen/arch/x86/hvm/svm/svm.c| 11 +++ xen/arch/x86/hvm/vmx/vmx.c| 14 +- xen/arch/x86/mm.c | 24 ++-- xen/arch/x86/mm/hap/hap.c | 23 ++- xen/include/asm-x86/hvm/hvm.h | 2 +- xen/include/asm-x86/paging.h | 11 ++- 7 files changed, 49 insertions(+), 40 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index e6316be..b9cac8e 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -1623,8 +1623,8 @@ static int hvmemul_invlpg( rc = X86EMUL_OKAY; } -if ( rc == X86EMUL_OKAY && is_canonical_address(addr) ) -hvm_funcs.invlpg_intercept(addr); +if ( rc == X86EMUL_OKAY ) +paging_invlpg(current, addr); return rc; } diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 081a5d8..679e615 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -,10 +,13 @@ static void svm_invlpga_intercept( static void svm_invlpg_intercept(unsigned long vaddr) { -struct vcpu *curr = current; HVMTRACE_LONG_2D(INVLPG, 0, TRC_PAR_LONG(vaddr)); -if ( paging_invlpg(curr, vaddr) ) -svm_asid_g_invlpg(curr, vaddr); +paging_invlpg(current, vaddr); +} + +static void svm_invlpg(struct vcpu *v, unsigned long vaddr) +{ +svm_asid_g_invlpg(v, vaddr); } static struct hvm_function_table __initdata svm_function_table = { @@ -2258,12 +2261,12 @@ static struct hvm_function_table __initdata svm_function_table = { .inject_trap = svm_inject_trap, .init_hypercall_page = svm_init_hypercall_page, .event_pending= svm_event_pending, +.invlpg = svm_invlpg, .cpuid_intercept = svm_cpuid_intercept, .wbinvd_intercept = svm_wbinvd_intercept, .fpu_dirty_intercept = svm_fpu_dirty_intercept, .msr_read_intercept = svm_msr_read_intercept, .msr_write_intercept = svm_msr_write_intercept, -.invlpg_intercept = svm_invlpg_intercept, .set_rdtsc_exiting= svm_set_rdtsc_exiting, .get_insn_bytes = svm_get_insn_bytes, diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index bc4410f..3acf1ab 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -81,7 +81,7 @@ static void vmx_wbinvd_intercept(void); static void vmx_fpu_dirty_intercept(void); static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content); static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content); -static void vmx_invlpg_intercept(unsigned long vaddr); +static void vmx_invlpg(struct vcpu *v, unsigned long vaddr); static int vmx_vmfunc_intercept(struct cpu_user_regs *regs); struct vmx_pi_blocking_vcpu { @@ -2137,6 +2137,7 @@ static struct hvm_function_table __initdata vmx_function_table = { .inject_trap = vmx_inject_trap, .init_hypercall_page = vmx_init_hypercall_page, .event_pending= vmx_event_pending, +.invlpg = vmx_invlpg, .cpu_up = vmx_cpu_up, .cpu_down = vmx_cpu_down, .cpuid_intercept = vmx_cpuid_intercept, @@ -2144,7 +2145,6 @@ static struct hvm_function_table __initdata vmx_function_table = { .fpu_dirty_intercept = vmx_fpu_dirty_intercept, .msr_read_intercept = vmx_msr_read_intercept,
[Xen-devel] [PATCH v2 for-4.7 4/5] x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept()
paging_invlpg() already returns a boolean indicating whether an invalidation is necessary or not. A return value of 0 indicates that the specified virtual address wasn't shadowed (or has already been flushed), cannot currently be cached in the TLB. This is a performance optimisation. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Tim Deegan CC: Wei Liu CC: Boris Ostrovsky CC: Suravee Suthikulpanit While being a performance optimisation, the main purpose of splitting this patch out is to separate the functional change. The following patch performs some function shuffling, and this patch makes the following one more obviously correct. v2: * Newly split out --- xen/arch/x86/hvm/svm/svm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 7634c3f..081a5d8 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2224,8 +2224,8 @@ static void svm_invlpg_intercept(unsigned long vaddr) { struct vcpu *curr = current; HVMTRACE_LONG_2D(INVLPG, 0, TRC_PAR_LONG(vaddr)); -paging_invlpg(curr, vaddr); -svm_asid_g_invlpg(curr, vaddr); +if ( paging_invlpg(curr, vaddr) ) +svm_asid_g_invlpg(curr, vaddr); } static struct hvm_function_table __initdata svm_function_table = { -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] ARM bare metal application test
Hello, > I don't think toolstack tries to load kernel to that guest physical > address -- reading from Ivan's log it suggests toolstack loaded the > kernel to 0x40008000. > That (0x8000800) is the address set in PC, right? I don't think > toolstack is in a position to sanitise that nor should it care. I posted xl create output when i changed address in linker script. This output when it is set to 0x80008000: PC is incorrect? Parsing config from dom.cfg libxl: debug: libxl_create.c:1557:do_domain_create: ao 0x3c1c8: create: how=(nil) callback=(nil) poller=0x3c228 libxl: debug: libxl_arm.c:59:libxl__arch_domain_prepare_config: Configure the domain libxl: debug: libxl_arm.c:62:libxl__arch_domain_prepare_config: - Allocate 0 SPIs libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x363a0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)" libxl: debug: libxl_dom.c:624:libxl__build_pv: pv kernel mapped 0 path kernel.bin domainbuilder: detail: xc_dom_kernel_file: filename="kernel.bin" domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-armv7l domainbuilder: detail: xc_dom_rambase_init: RAM starts at 4 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) loader ... domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel image too small domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... domainbuilder: detail: loader probe OK domainbuilder: detail: xc_dom_parse_zimage32_kernel: called domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x40008000 -> 0x40008034 libxl: debug: libxl_arm.c:776:libxl__arch_domain_init_hw_description: constructing DTB for Xen version 4.6 guest libxl: debug: libxl_arm.c:777:libxl__arch_domain_init_hw_description: - vGIC version: V2 libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@4000 libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@2 libxl: debug: libxl_arm.c:871:libxl__arch_domain_init_hw_description: fdt total size 1237 domainbuilder: detail: xc_dom_devicetree_mem: called domainbuilder: detail: xc_dom_mem_init: mem 32 MB, pages 0x2000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x2000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32 domainbuilder: detail: populate_guest_memory: populating RAM @ 4000-4200 (32MB) domainbuilder: detail: populate_one_size: populated 0x10/0x10 entries with shift 9 domainbuilder: detail: arch_setup_meminit: placing boot modules at 0x41fff000 domainbuilder: detail: arch_setup_meminit: devicetree: 0x41fff000 -> 0x4200 libxl: debug: libxl_arm.c:902:finalise_one_memory_node: Populating placeholder node /memory@4000 libxl: debug: libxl_arm.c:896:finalise_one_memory_node: Nopping out placeholder node /memory@2 domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000 -> 0x40009000 (pfn 0x40008 + 0x1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x40008+0x1 at 0xb6eef000 domainbuilder: detail: xc_dom_load_zimage_kernel: called domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x40009000 domainbuilder: detail: xc_dom_load_zimage_kernel: copy 52 bytes from blob 0xb6ef to dst 0xb6eef000 domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x41fff000 -> 0x4200 (pfn 0x41fff + 0x1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x41fff+0x1 at 0xb6eee000 domainbuilder: detail: alloc_magic_pages: called domainbuilder: detail: count_pgtables_arm: called domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x4200 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-armv7l <= matches domainbuilder: detail: setup_pgtables_arm: called domainbuilder: detail: clear_page: pfn 0x39000, mfn 0x39000 domainbuilder: detail: clear_page: pfn 0x39001, mfn 0x39001 domainbuilder: detail: start_info_arm: called domainbuilder: detail: domain builder memory footprint domainbuilder: detail:allocated domainbuilder: detail: malloc : 66 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail
Re: [Xen-devel] dumping Xen stack
> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, May 09, 2016 1:14 PM > To: Zytaruk, Kelly; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] dumping Xen stack > > On 09/05/16 18:11, Zytaruk, Kelly wrote: > > > >> -Original Message- > >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > >> Sent: Monday, May 09, 2016 12:40 PM > >> To: Zytaruk, Kelly; xen-devel@lists.xen.org > >> Subject: Re: [Xen-devel] dumping Xen stack > >> > >> On 09/05/16 17:37, Zytaruk, Kelly wrote: > >>> Does Xen have an equivalent function to the Linux dump_stack() function? > >>> > >>> I am hitting a panic followed by a reboot and would like to find out > >>> where I am > >> coming from. > >> > >> At the point of a crash, the stack should be printed on the console. > > The only thing I am seeing on the console is the panic message followed by > > the > system will reboot in 5 sec. > > Ah - plain panic()s don't automatically dump register/stack information. > > >> Alternatively, show_execution_state() at any point should dump the > >> Xen register/stack. > > I looked up show_execution_state() and show_trace() and they both require a > pointer to registers. > > I am hitting a panic during boot in queue_invalidate_wait() in > .../drivers/passthrough/vtd/qinval.c . I am not sure how to get the register > pointer from here. > > Oops sorry - I meant dump_execution_state() which takes no parameters. That is exactly what I am looking for. Thx. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARM bare metal application test
On 09/05/16 18:39, Wei Liu wrote: On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote: On 09/05/16 17:43, Ivan Pavić2 wrote: Hello Julien, Hello Ivan, Julien Grall wrote: Guest are booting with MMU disabled, so 0x80008000 will be the physical address. The toolstack will load the kernel at this physical address. However, the start of the guest RAM for Xen 4.7 is 0x4000 (see include/public/arch-arm.h). Can you try to use 0x40008000 for the guest address? I changed address. It seems the problem is solved because PC is now 40008030 (that is address of "work: b work" i think). You can figure out the associated instruction with objdump. By the way, how much RAM did you give to the guest? I wrote "memory = 32" in cfg file, I think that stands for 32 MB? Correct, so the end of the RAM bank would be 0x4200. I am a bit surprised that the toolstack does not complain when trying to load the kernel at 0x80008000. I don't think toolstack tries to load kernel to that guest physical address -- reading from Ivan's log it suggests toolstack loaded the kernel to 0x40008000. That (0x8000800) is the address set in PC, right? I don't think toolstack is in a position to sanitise that nor should it care. The zImage format offers the opportunity to either choose the base address or let the loader do it for you. Based on the specification, this address is supposed to be both the PC and the loading address. However, libxc (see xc_dom_parse_zimage32_kernel) seems to handle the first case incorrectly. It will be fairly easy to sanitize or even fix it. I will send a patch for it. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
> On 9 May 2016, at 18:37, Konrad Rzeszutek Wilk wrote: > > On Mon, May 09, 2016 at 04:28:52PM +0100, Lars Kurth wrote: >> Hi all, >> >> I added the following sections based on git logs to man pages. Authors are >> on the CC list and should review and modify (or suggest edits by replying to >> this thread). I added/updated/added TODO's to: >> >> I do have some questions, to ... >> - Konrad/Ross: is there any documentation for xSplice which I have missed? > > I've updated http://wiki.xen.org/wiki/XSplice > > to have better layout and data. I will have a sub-section on how to test it. Cool: ping me and I will link to it from the test day page Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARM bare metal application test
On Mon, May 09, 2016 at 05:47:38PM +0100, Julien Grall wrote: > > > On 09/05/16 17:43, Ivan Pavić2 wrote: > >Hello Julien, > > Hello Ivan, > > > > >Julien Grall wrote: > >>Guest are booting with MMU disabled, so 0x80008000 will be the physical > >>address. > > > >>The toolstack will load the kernel at this physical address. However, > >>the start of the guest RAM for Xen 4.7 is 0x4000 (see > >>include/public/arch-arm.h). Can you try to use 0x40008000 for the guest > >>address? > > > >I changed address. It seems the problem is solved because PC is now > >40008030 (that is address of "work: b work" i think). > > You can figure out the associated instruction with objdump. > > > > >>By the way, how much RAM did you give to the guest? > > > >I wrote "memory = 32" in cfg file, I think that stands for 32 MB? > > Correct, so the end of the RAM bank would be 0x4200. I am a bit > surprised that the toolstack does not complain when trying to load the > kernel at 0x80008000. > I don't think toolstack tries to load kernel to that guest physical address -- reading from Ivan's log it suggests toolstack loaded the kernel to 0x40008000. That (0x8000800) is the address set in PC, right? I don't think toolstack is in a position to sanitise that nor should it care. Wei. > Can you paste the dump of xl -vvv create... ? > > Regards, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
On Mon, May 09, 2016 at 04:28:52PM +0100, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are on > the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: > > I do have some questions, to ... > - Konrad/Ross: is there any documentation for xSplice which I have missed? I've updated http://wiki.xen.org/wiki/XSplice to have better layout and data. I will have a sub-section on how to test it. > - Julien: Any ARM specific stuff you want people to test? > - Doug: are there any docs / tests for KCONFIG you want to push > - George: are there any manual tests for credit 2 hard affinity, for hotplug > disk backends (drbd, iscsi, &c) and soft reset for HVM guests that should be > added? > > For the following sections there are some TODO's - please verify and modify > and once OK, remove the TODO from the wiki pages. > > VCPU-PIN (Juergen Gross) > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#-f_option_for_xl_vcpu-pin > > RTDS (Meng Xu, Chong Li) > - Meng, you mention improvements to the RTDS scheduler in another thread > - Are any specific test instructions needed in > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RTDS_scheduler_improvements > > COLO (Wen Congyang) > - http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#COLO_-_Coarse_Grain_Lock_Stepping > > USB (Chunyan Liu) > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#USB_Support_for_xl > - http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB > - http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB_in_xl.2Flibxl > > CDP (He Chen) > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Intel_Code_and_Data_Prioritization_.28CDP.29 > - > http://wiki.xenproject.org/wiki/Intel_Platform_QoS_Technologies#Code_and_Data_Prioritization_.28CDP.29 > > Are there any other big items that are missing? > > Regards > Lars > > > On 5 May 2016, at 18:08, Lars Kurth wrote: > > > > Hi everyone, > > > > I updated http://wiki.xenproject.org/wiki/Xen_Project_Test_Days and created > > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions (note that we > > only have one page for all RC's now to avoid unnecessary copy and pasting). > > > > For those who want new features to be tested, please expect to > > a) Explain what to test (a very short description of the feature) > > b) Add some instructions on how to test (e.g. some command line > > instructions) > > > > You can add a new headline (an example is marked with TODO) to either > > - > > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_ARM_Test_Instructions > > - > > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_x86_Test_Instructions > > - OR > > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RC_specific_things_to_test > > (under a specific RC heading) > > > > I will start promoting Test Days from early next week (on the blog, but > > also on the mailing lists). The more specific test instructions for Xen 4.7 > > related features, the better the coverage will be and the more likely > > people are to actually test. > > > > Best Regards > > Lars > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24
On 05/09/2016 11:15 AM, Boris Ostrovsky wrote: > On 05/09/2016 12:40 PM, Kevin Moraga wrote: >> On 05/09/2016 09:53 AM, Jan Beulich wrote: >> On 09.05.16 at 16:52, wrote: On 05/09/2016 04:08 AM, Jan Beulich wrote: On 09.05.16 at 00:51, wrote: >> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 >> and Intel Skylake processor (Intel Core i7-6600U) >> >> This kernel is crashing almost in the same way as explained in this >> thread... But my problem is mainly with Skylake. Because the same >> configuration works within another machine but with another processor >> (Intel Core i5-3340M). Attached are the boot logs. > The address the fault occurs on (806bdee0) is bogus, so > from the register and stack dump alone I don't think we can derive > much. What we'd need is access to the kernel binary used (or > really the vmlinux accompanying the vmlinuz that was used), in > order to see where exactly the kernel died, and hence where this > bogus address originates from. As I understand it this is a kernel > you built yourself - can you make said binary from exactly that > build available somewhere? Yes I have it. But I get the same crash on various 4.4.X and also with 4.5.3. **https://drive.google.com/open?id=0B6Ol0ob95UxXQV9HM1BWMmhCZ0E >>> Well, this doesn't contain the file I'm after (vmlinux), and taking >>> apart vmlinuz would be quite cumbersome. >>> >>> Jan >>> >> Oh sorry, here is the link to vmlinux >> >> https://drive.google.com/file/d/0B6Ol0ob95UxXN0dDMWM1a29vMEk/view?usp=sharing > > This is still vmlinuz but the failure is at > > 81007ef3: 48 3b 1d 4e 2e ec 00cmp > 0xec2e4e(%rip),%rbx# 0x81ecad48 > 81007efa: 73 51 jae0x81007f4d > 81007efc: 31 c0 xor%eax,%eax > 81007efe: 48 8b 15 03 d2 c0 00mov > 0xc0d203(%rip),%rdx# 0x81c15108 > 81007f05: 90 nop > 81007f06: 90 nop > 81007f07: 90 nop > 81007f08: 4c 8b 2c da mov > (%rdx,%rbx,8),%r13<== > 81007f0c: 90 nop > 81007f0d: 90 nop > 81007f0e: 90 nop > 81007f0f: 85 c0 test %eax,%eax > 81007f11: 78 3a js 0x81007f4d > 81007f13: 48 8b 05 ee 11 d2 00mov > 0xd211ee(%rip),%rax# 0x81d29108 > 81007f1a: 49 39 c5cmp%rax,%r13 > 81007f1d: 73 6f jae0x81007f8e > 81007f1f: 48 8b 05 ea 11 d2 00mov > 0xd211ea(%rip),%rax# 0x81d29110 > 81007f26: 4a 8b 04 e8 mov(%rax,%r13,8),%rax > > Any chance you could provide an un-stripped binary or System.map? Here is the link for System.map https://drive.google.com/file/d/0B6Ol0ob95UxXYVE4SzdMcENsWWs/view?usp=sharing -- Sincerely, Kevin Moraga PGP: F258EDCB Fingerprint: 3915 A5A9 959C D18F 0A89 B47E FB4B 55F5 F258 EDCB signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24
On 05/09/2016 12:40 PM, Kevin Moraga wrote: > > On 05/09/2016 09:53 AM, Jan Beulich wrote: > On 09.05.16 at 16:52, wrote: >>> On 05/09/2016 04:08 AM, Jan Beulich wrote: >>> On 09.05.16 at 00:51, wrote: > I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 > and Intel Skylake processor (Intel Core i7-6600U) > > This kernel is crashing almost in the same way as explained in this > thread... But my problem is mainly with Skylake. Because the same > configuration works within another machine but with another processor > (Intel Core i5-3340M). Attached are the boot logs. The address the fault occurs on (806bdee0) is bogus, so from the register and stack dump alone I don't think we can derive much. What we'd need is access to the kernel binary used (or really the vmlinux accompanying the vmlinuz that was used), in order to see where exactly the kernel died, and hence where this bogus address originates from. As I understand it this is a kernel you built yourself - can you make said binary from exactly that build available somewhere? >>> Yes I have it. But I get the same crash on various 4.4.X and also with >>> 4.5.3. >>> >>> **https://drive.google.com/open?id=0B6Ol0ob95UxXQV9HM1BWMmhCZ0E >> Well, this doesn't contain the file I'm after (vmlinux), and taking >> apart vmlinuz would be quite cumbersome. >> >> Jan >> > Oh sorry, here is the link to vmlinux > > https://drive.google.com/file/d/0B6Ol0ob95UxXN0dDMWM1a29vMEk/view?usp=sharing This is still vmlinuz but the failure is at 81007ef3: 48 3b 1d 4e 2e ec 00cmp 0xec2e4e(%rip),%rbx# 0x81ecad48 81007efa: 73 51 jae0x81007f4d 81007efc: 31 c0 xor%eax,%eax 81007efe: 48 8b 15 03 d2 c0 00mov 0xc0d203(%rip),%rdx# 0x81c15108 81007f05: 90 nop 81007f06: 90 nop 81007f07: 90 nop 81007f08: 4c 8b 2c da mov (%rdx,%rbx,8),%r13<== 81007f0c: 90 nop 81007f0d: 90 nop 81007f0e: 90 nop 81007f0f: 85 c0 test %eax,%eax 81007f11: 78 3a js 0x81007f4d 81007f13: 48 8b 05 ee 11 d2 00mov 0xd211ee(%rip),%rax# 0x81d29108 81007f1a: 49 39 c5cmp%rax,%r13 81007f1d: 73 6f jae0x81007f8e 81007f1f: 48 8b 05 ea 11 d2 00mov 0xd211ea(%rip),%rax# 0x81d29110 81007f26: 4a 8b 04 e8 mov(%rax,%r13,8),%rax Any chance you could provide an un-stripped binary or System.map? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
On Mon, May 9, 2016 at 11:28 AM, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are on > the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: > > I do have some questions, to ... > - Konrad/Ross: is there any documentation for xSplice which I have missed? > - Julien: Any ARM specific stuff you want people to test? > - Doug: are there any docs / tests for KCONFIG you want to push > - George: are there any manual tests for credit 2 hard affinity, for hotplug > disk backends (drbd, iscsi, &c) and soft reset for HVM guests that should be > added? > > For the following sections there are some TODO's - please verify and modify > and once OK, remove the TODO from the wiki pages. > > RTDS (Meng Xu, Tianyang, Chong Li) > - Meng, you mention improvements to the RTDS scheduler in another thread > - Are any specific test instructions needed in > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RTDS_scheduler_improvements I verified the text in the wiki, added one comment "which will not invoke the scheduler unnecessarily" for the event-driven model. I removed the TODO in the RTDS section in the wiki. Please let me know if I need to do something else. Thank you very much! Best, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dumping Xen stack
On 09/05/16 18:11, Zytaruk, Kelly wrote: > >> -Original Message- >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Monday, May 09, 2016 12:40 PM >> To: Zytaruk, Kelly; xen-devel@lists.xen.org >> Subject: Re: [Xen-devel] dumping Xen stack >> >> On 09/05/16 17:37, Zytaruk, Kelly wrote: >>> Does Xen have an equivalent function to the Linux dump_stack() function? >>> >>> I am hitting a panic followed by a reboot and would like to find out where >>> I am >> coming from. >> >> At the point of a crash, the stack should be printed on the console. > The only thing I am seeing on the console is the panic message followed by > the system will reboot in 5 sec. Ah - plain panic()s don't automatically dump register/stack information. >> Alternatively, show_execution_state() at any point should dump the Xen >> register/stack. > I looked up show_execution_state() and show_trace() and they both require a > pointer to registers. > I am hitting a panic during boot in queue_invalidate_wait() in > .../drivers/passthrough/vtd/qinval.c . I am not sure how to get the register > pointer from here. Oops sorry - I meant dump_execution_state() which takes no parameters. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
On 09/05/16 17:56, Lars Kurth wrote: On 9 May 2016, at 17:17, Julien Grall wrote: (CC Shannon, Stefano and Steve) Hi Lars, On 09/05/16 16:28, Lars Kurth wrote: Hi all, I added the following sections based on git logs to man pages. Authors are on the CC list and should review and modify (or suggest edits by replying to this thread). I added/updated/added TODO's to: I do have some questions, to ... - Konrad/Ross: is there any documentation for xSplice which I have missed? - Julien: Any ARM specific stuff you want people to test? General testing of Xen on the boards we are supporting. That is already in the boilerplate, but I can make it more prominent We may also want some testing on ACPI, which will be in tech preview for Xen 4.7. However this is requiring platform with ACPI 6.0 (or later). If I remember correctly, none of the ARM64 platform we support fulfill this requirement. Steve, do you have any platform in mind? Shannon, which platform have you used for the ACPI development? Was it the Foundation Model? If so we would need to write down (or update) a wiki page with the instructions to boot Xen on the model. That makes sense There was wallclock also, if I recall Good point. Stefano, how can it be tested? Is checking the date in the guest enough? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dumping Xen stack
> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, May 09, 2016 12:40 PM > To: Zytaruk, Kelly; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] dumping Xen stack > > On 09/05/16 17:37, Zytaruk, Kelly wrote: > > Does Xen have an equivalent function to the Linux dump_stack() function? > > > > I am hitting a panic followed by a reboot and would like to find out where > > I am > coming from. > > At the point of a crash, the stack should be printed on the console. The only thing I am seeing on the console is the panic message followed by the system will reboot in 5 sec. > > Alternatively, show_execution_state() at any point should dump the Xen > register/stack. I looked up show_execution_state() and show_trace() and they both require a pointer to registers. I am hitting a panic during boot in queue_invalidate_wait() in .../drivers/passthrough/vtd/qinval.c . I am not sure how to get the register pointer from here. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/6] libxl: handle error from libxl__need_xenpv_qemu() correctly
Ian Jackson writes ("Re: [PATCH v6 1/6] libxl: handle error from libxl__need_xenpv_qemu() correctly"): > Wei Liu writes ("Re: [PATCH v6 1/6] libxl: handle error from > libxl__need_xenpv_qemu() correctly"): > > On Thu, Mar 31, 2016 at 07:49:01AM +0200, Juergen Gross wrote: > > > In case libxl__need_xenpv_qemu() returns an error let domain creation > > > fail. > > Queued for backport. Pushed to 4.5 and 4.6. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 for-4.7 07/16] libxc: fix usage of uninitialized variable
Ian Jackson writes ("Re: [PATCH v3 for-4.7 07/16] libxc: fix usage of uninitialized variable"): > Wei Liu writes ("Re: [PATCH v3 for-4.7 07/16] libxc: fix usage of > uninitialized variable"): > > Ian, this is a backport candidate. > > Noted, thanks. Backported to 4.6 and 4.5. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: handle xl migrate --debug in legacy stream
Ian Jackson writes ("Re: [PATCH] tools: handle xl migrate --debug in legacy stream"): > Andrew Cooper writes ("Re: [PATCH] tools: handle xl migrate --debug in legacy > stream"): > > Ian: This is also a backport candidate for 4.6 > > Queued for backport. Pushed to 4.6. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] ARM bare metal application test
Hello Julien, Julien Grall wrote: > Guest are booting with MMU disabled, so 0x80008000 will be the physical > address. > The toolstack will load the kernel at this physical address. However, > the start of the guest RAM for Xen 4.7 is 0x4000 (see > include/public/arch-arm.h). Can you try to use 0x40008000 for the guest > address? I changed address. It seems the problem is solved because PC is now 40008030 (that is address of "work: b work" i think). > By the way, how much RAM did you give to the guest? I wrote "memory = 32" in cfg file, I think that stands for 32 MB? I will continue working on this. Thank you very much, Ivan Pavić. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
> On 9 May 2016, at 17:17, Julien Grall wrote: > > (CC Shannon, Stefano and Steve) > > Hi Lars, > > On 09/05/16 16:28, Lars Kurth wrote: >> Hi all, >> >> I added the following sections based on git logs to man pages. Authors are >> on the CC list and should review and modify (or suggest edits by replying to >> this thread). I added/updated/added TODO's to: >> >> I do have some questions, to ... >> - Konrad/Ross: is there any documentation for xSplice which I have missed? >> - Julien: Any ARM specific stuff you want people to test? > > General testing of Xen on the boards we are supporting. That is already in the boilerplate, but I can make it more prominent > We may also want some testing on ACPI, which will be in tech preview for Xen > 4.7. However this is requiring platform with ACPI 6.0 (or later). If I > remember correctly, none of the ARM64 platform we support fulfill this > requirement. Steve, do you have any platform in mind? > > Shannon, which platform have you used for the ACPI development? Was it the > Foundation Model? > > If so we would need to write down (or update) a wiki page with the > instructions to boot Xen on the model. That makes sense There was wallclock also, if I recall Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] tools: configure correct trace backend for QEMU
Newer versions of the QEMU source have replaced the 'stderr' trace backend with 'log'. This patch adjusts the tools Makefile to test for the 'log' backend and specify it if it is available. Signed-off-by: Paul Durrant --- Cc: Ian Jackson Cc: Wei Liu --- tools/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/Makefile b/tools/Makefile index 3f45fb9..6440dec 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -240,7 +240,9 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find source=.; \ fi; \ cd qemu-xen-dir; \ - if $$source/scripts/tracetool.py --check-backend --backend stderr ; then \ + if $$source/scripts/tracetool.py --check-backend --backend log ; then \ + enable_trace_backend='--enable-trace-backend=log'; \ + elif $$source/scripts/tracetool.py --check-backend --backend stderr ; then \ enable_trace_backend='--enable-trace-backend=stderr'; \ else \ enable_trace_backend='' ; \ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Odgovor: ARM bare metal application test
Hello, > Correct, so the end of the RAM bank would be 0x4200. I am a bit > surprised that the toolstack does not complain when trying to load the > kernel at 0x80008000. > Can you paste the dump of xl -vvv create... ? $ xl -vvv create dom.cfg Parsing config from dom.cfg libxl: debug: libxl_create.c:1557:do_domain_create: ao 0x3c1c8: create: how=(nil) callback=(nil) poller=0x3c228 libxl: debug: libxl_arm.c:59:libxl__arch_domain_prepare_config: Configure the domain libxl: debug: libxl_arm.c:62:libxl__arch_domain_prepare_config: - Allocate 0 SPIs libxl: debug: libxl_create.c:945:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch w=0x363a0: deregister unregistered domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)" libxl: debug: libxl_dom.c:624:libxl__build_pv: pv kernel mapped 0 path kernel.bin domainbuilder: detail: xc_dom_kernel_file: filename="kernel.bin" domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-armv7l domainbuilder: detail: xc_dom_rambase_init: RAM starts at 4 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64) loader ... domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel image too small domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... domainbuilder: detail: loader probe OK domainbuilder: detail: xc_dom_parse_zimage32_kernel: called domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l: 0x40008000 -> 0x40008034 libxl: debug: libxl_arm.c:776:libxl__arch_domain_init_hw_description: constructing DTB for Xen version 4.6 guest libxl: debug: libxl_arm.c:777:libxl__arch_domain_init_hw_description: - vGIC version: V2 libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@4000 libxl: debug: libxl_arm.c:380:make_memory_nodes: Creating placeholder node /memory@2 libxl: debug: libxl_arm.c:871:libxl__arch_domain_init_hw_description: fdt total size 1237 domainbuilder: detail: xc_dom_devicetree_mem: called domainbuilder: detail: xc_dom_mem_init: mem 32 MB, pages 0x2000 pages, 4k each domainbuilder: detail: xc_dom_mem_init: 0x2000 pages domainbuilder: detail: xc_dom_boot_mem_init: called domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32 domainbuilder: detail: populate_guest_memory: populating RAM @ 4000-4200 (32MB) domainbuilder: detail: populate_one_size: populated 0x10/0x10 entries with shift 9 domainbuilder: detail: arch_setup_meminit: placing boot modules at 0x41fff000 domainbuilder: detail: arch_setup_meminit: devicetree: 0x41fff000 -> 0x4200 libxl: debug: libxl_arm.c:902:finalise_one_memory_node: Populating placeholder node /memory@4000 libxl: debug: libxl_arm.c:896:finalise_one_memory_node: Nopping out placeholder node /memory@2 [0/47] domainbuilder: detail: xc_dom_build_image: called domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000 -> 0x40009000 (pfn 0x40008 + 0x1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x40008+0x1 at 0xb6f82000 domainbuilder: detail: xc_dom_load_zimage_kernel: called domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg 0x40008000-0x40009000 domainbuilder: detail: xc_dom_load_zimage_kernel: copy 52 bytes from blob 0xb6f83000 to dst 0xb6f82000 domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x41fff000 -> 0x4200 (pfn 0x41fff + 0x1 pages) domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x41fff+0x1 at 0xb6f81000 domainbuilder: detail: alloc_magic_pages: called domainbuilder: detail: count_pgtables_arm: called domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x4200 domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0 domainbuilder: detail: xc_dom_boot_image: called domainbuilder: detail: arch_setup_bootearly: doing nothing domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-armv7l <= matches domainbuilder: detail: setup_pgtables_arm: called domainbuilder: detail: clear_page: pfn 0x39000, mfn 0x39000 domainbuilder: detail: clear_page: pfn 0x39001, mfn 0x39001 domainbuilder: detail: start_info_arm: called domainbuilder: detail: domain builder memory footprint domainbuilder: detail:allocated domainbuilder: detail: malloc : 66 kB domainbuilder: detail: anon mmap : 0 bytes domainbuilder: detail:mapped domainbuilder: detail: file mmap : 52 bytes domainbuilder: detail: domU mmap
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
Reduced CC list > On 9 May 2016, at 17:03, George Dunlap wrote: > > On Mon, May 9, 2016 at 4:28 PM, Lars Kurth wrote: >> Hi all, >> >> I added the following sections based on git logs to man pages. Authors are >> on the CC list and should review and modify (or suggest edits by replying to >> this thread). I added/updated/added TODO's to: >> >> I do have some questions, to ... >> - Konrad/Ross: is there any documentation for xSplice which I have missed? >> - Julien: Any ARM specific stuff you want people to test? >> - Doug: are there any docs / tests for KCONFIG you want to push >> - George: are there any manual tests for credit 2 hard affinity, for hotplug >> disk backends (drbd, iscsi, &c) and soft reset for HVM guests that should be >> added? > > Hard affinity tests shouldn't be too difficult to add in. That would be great > There are > certainly tests for drbd and iscsi, but I'm not personally that > familiar with them, it would basically be, "If you use drbd or iscsi > backends, try HVM guests". :-) I can add that > Soft Reset was added in by Vitaly, I believe; I listed it because I > saw it in the git history. Added Vitaly Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Vote] Minor change to governance document at http://www.xenproject.org/developers/governance.html (Vote before May 16th)
Hi all, as per the RFC at http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg03191.html which received no concrete feedback other than it looks good, I want to call a formal vote on this proposal. As the proposal affects all subprojects, committers from the Hypervisor and XAPI teams which are both mature can vote. == Committers that can Vote == Hypervisor: Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Ian Campbell, Konrad R Wilk, Stefano Stabellini, Wei Liu XAPI: Jon Ludlam, Chandrika Srinivasan, David Scott, Euan Harris, Germano Percossi, Siddharth Vinoth Kumar, John Else, Mate Lakat, Konstantina Chremmou, Rob Hoes, Si Beaumont, Thanos Makatos, Thomas Sanders, Vineeth Thampi Raveendran, Zheng Li == Voting Form == See https://docs.google.com/forms/d/1hsRzZFn64_05orITRHrDUvlUnIF9LytGHxkWPNPCmqk/viewform Please vote before May 16th == Proposed Change == For convenience, find below a copy of the relevant section of http://www.xenproject.org/developers/governance.html that we are proposing to change. --- Committer Elections Developers who have earned the trust of committers in their project (including the project lead) can through election be promoted to can [the (inclusion of the project lead) makes no sense] Committer. A two stage mechanism is used * Nomination: A committers should nominate a community member publicly Community members should nominate candidates by posting a proposal to appointments at xenproject dot org explaining the candidate's contributions to the project and thus why they should be elected as a maintainer on the project's public mailing list. to become a Committer of the project. [Typo: this should have been Committer in the first place] The nomination should include a project, cite evidence such as patches ^ should [the "include a project" makes no sense] and other contributions where the case is not obvious. Existing Committers will review all proposals, check whether the nominee would be willing to accept the nomination and publish suitable nominations on the project's public mailing list for wider community input. --- The modified section will look like ... Committer Elections Developers who have earned the trust of committers in their project can through election be promoted to Committer. A two stage mechanism is used * Nomination: Community members should nominate candidates by posting a proposal to appointments at xenproject dot org explaining the candidate's contributions to the project and thus why they should be elected to become a Committer of the project. The nomination should cite evidence such as patches and other contributions where the case is not obvious. Existing Committers will review all proposals, check whether the nominee would be willing to accept the nomination and publish suitable nominations on the project's public mailing list for wider community input. ... Best Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARM bare metal application test
On 09/05/16 17:43, Ivan Pavić2 wrote: Hello Julien, Hello Ivan, Julien Grall wrote: Guest are booting with MMU disabled, so 0x80008000 will be the physical address. The toolstack will load the kernel at this physical address. However, the start of the guest RAM for Xen 4.7 is 0x4000 (see include/public/arch-arm.h). Can you try to use 0x40008000 for the guest address? I changed address. It seems the problem is solved because PC is now 40008030 (that is address of "work: b work" i think). You can figure out the associated instruction with objdump. By the way, how much RAM did you give to the guest? I wrote "memory = 32" in cfg file, I think that stands for 32 MB? Correct, so the end of the RAM bank would be 0x4200. I am a bit surprised that the toolstack does not complain when trying to load the kernel at 0x80008000. Can you paste the dump of xl -vvv create... ? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen-hvm: ignore background I/O sections
> -Original Message- > From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: 09 May 2016 17:29 > To: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org > Cc: Paul Durrant; Stefano Stabellini; Anthony Perard; Paolo Bonzini > Subject: [PATCH v2] xen-hvm: ignore background I/O sections > > Since Xen will correctly handle accesses to unimplemented I/O ports (by > returning all 1's for reads and ignoring writes) there is no need for > QEMU to register backgroud I/O sections. > > This patch therefore adds checks to xen_io_add/del so that sections with > memory-region ops pointing at 'unassigned_io_ops' are ignored. > > Signed-off-by: Paul Durrant > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Paolo Bonzini > --- > > v2: > - Add missing braces Aargh. Forgot to git add. Please ignore. Paul > --- > xen-hvm.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/xen-hvm.c b/xen-hvm.c > index 039680a..8ab44f0 100644 > --- a/xen-hvm.c > +++ b/xen-hvm.c > @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener, > MemoryRegionSection *section) > { > XenIOState *state = container_of(listener, XenIOState, io_listener); > +MemoryRegion *mr = section->mr; > > -memory_region_ref(section->mr); > +if (mr->ops == &unassigned_io_ops) > +return; > + > +memory_region_ref(mr); > > xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); > } > @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener, > MemoryRegionSection *section) > { > XenIOState *state = container_of(listener, XenIOState, io_listener); > +MemoryRegion *mr = section->mr; > + > +if (mr->ops == &unassigned_io_ops) > +return; > > xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); > > -memory_region_unref(section->mr); > +memory_region_unref(mr); > } > > static void xen_device_realize(DeviceListener *listener, > -- > 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] xen-hvm: ignore background I/O sections
Since Xen will correctly handle accesses to unimplemented I/O ports (by returning all 1's for reads and ignoring writes) there is no need for QEMU to register backgroud I/O sections. This patch therefore adds checks to xen_io_add/del so that sections with memory-region ops pointing at 'unassigned_io_ops' are ignored. Signed-off-by: Paul Durrant Cc: Stefano Stabellini Cc: Anthony Perard Cc: Paolo Bonzini --- v3: - Really add missing braces. v2: - Add missing braces --- xen-hvm.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/xen-hvm.c b/xen-hvm.c index 039680a..e394407 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -510,8 +510,13 @@ static void xen_io_add(MemoryListener *listener, MemoryRegionSection *section) { XenIOState *state = container_of(listener, XenIOState, io_listener); +MemoryRegion *mr = section->mr; -memory_region_ref(section->mr); +if (mr->ops == &unassigned_io_ops) { +return; +} + +memory_region_ref(mr); xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); } @@ -520,10 +525,15 @@ static void xen_io_del(MemoryListener *listener, MemoryRegionSection *section) { XenIOState *state = container_of(listener, XenIOState, io_listener); +MemoryRegion *mr = section->mr; + +if (mr->ops == &unassigned_io_ops) { +return; +} xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); -memory_region_unref(section->mr); +memory_region_unref(mr); } static void xen_device_realize(DeviceListener *listener, -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] xen-hvm: ignore background I/O sections
Since Xen will correctly handle accesses to unimplemented I/O ports (by returning all 1's for reads and ignoring writes) there is no need for QEMU to register backgroud I/O sections. This patch therefore adds checks to xen_io_add/del so that sections with memory-region ops pointing at 'unassigned_io_ops' are ignored. Signed-off-by: Paul Durrant Cc: Stefano Stabellini Cc: Anthony Perard Cc: Paolo Bonzini --- v2: - Add missing braces --- xen-hvm.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/xen-hvm.c b/xen-hvm.c index 039680a..8ab44f0 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener, MemoryRegionSection *section) { XenIOState *state = container_of(listener, XenIOState, io_listener); +MemoryRegion *mr = section->mr; -memory_region_ref(section->mr); +if (mr->ops == &unassigned_io_ops) +return; + +memory_region_ref(mr); xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); } @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener, MemoryRegionSection *section) { XenIOState *state = container_of(listener, XenIOState, io_listener); +MemoryRegion *mr = section->mr; + +if (mr->ops == &unassigned_io_ops) +return; xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); -memory_region_unref(section->mr); +memory_region_unref(mr); } static void xen_device_realize(DeviceListener *listener, -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-hvm: ignore background I/O sections
> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: 09 May 2016 17:39 > To: Paul Durrant; qemu-de...@nongnu.org; xen-de...@lists.xenproject.org > Cc: Stefano Stabellini; Anthony Perard > Subject: Re: [PATCH] xen-hvm: ignore background I/O sections > > > > On 09/05/2016 18:18, Paul Durrant wrote: > > Since Xen will correctly handle accesses to unimplemented I/O ports (by > > returning all 1's for reads and ignoring writes) there is no need for > > QEMU to register backgroud I/O sections. > > > > This patch therefore adds checks to xen_io_add/del so that sections with > > memory-region ops pointing at 'unassigned_io_ops' are ignored. > > > > Signed-off-by: Paul Durrant > > Cc: Stefano Stabellini > > Cc: Anthony Perard > > Cc: Paolo Bonzini > > --- > > xen-hvm.c | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/xen-hvm.c b/xen-hvm.c > > index 039680a..8ab44f0 100644 > > --- a/xen-hvm.c > > +++ b/xen-hvm.c > > @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener, > > MemoryRegionSection *section) > > { > > XenIOState *state = container_of(listener, XenIOState, io_listener); > > +MemoryRegion *mr = section->mr; > > > > -memory_region_ref(section->mr); > > +if (mr->ops == &unassigned_io_ops) > > +return; > > Missing braces, same in xen_io_del. Otherwise looks ok. > Ah, sorry. Forgot to style-switch. Will post v2. > Paolo > > > +memory_region_ref(mr); > > > > xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); > > } > > @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener, > > MemoryRegionSection *section) > > { > > XenIOState *state = container_of(listener, XenIOState, io_listener); > > +MemoryRegion *mr = section->mr; > > + > > +if (mr->ops == &unassigned_io_ops) > > +return; > > > > xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); > > > > -memory_region_unref(section->mr); > > +memory_region_unref(mr); > > } > > > > static void xen_device_realize(DeviceListener *listener, > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24
On 05/09/2016 09:53 AM, Jan Beulich wrote: On 09.05.16 at 16:52, wrote: >> On 05/09/2016 04:08 AM, Jan Beulich wrote: >> On 09.05.16 at 00:51, wrote: I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 and Intel Skylake processor (Intel Core i7-6600U) This kernel is crashing almost in the same way as explained in this thread... But my problem is mainly with Skylake. Because the same configuration works within another machine but with another processor (Intel Core i5-3340M). Attached are the boot logs. >>> The address the fault occurs on (806bdee0) is bogus, so >>> from the register and stack dump alone I don't think we can derive >>> much. What we'd need is access to the kernel binary used (or >>> really the vmlinux accompanying the vmlinuz that was used), in >>> order to see where exactly the kernel died, and hence where this >>> bogus address originates from. As I understand it this is a kernel >>> you built yourself - can you make said binary from exactly that >>> build available somewhere? >> Yes I have it. But I get the same crash on various 4.4.X and also with >> 4.5.3. >> >> **https://drive.google.com/open?id=0B6Ol0ob95UxXQV9HM1BWMmhCZ0E > Well, this doesn't contain the file I'm after (vmlinux), and taking > apart vmlinuz would be quite cumbersome. > > Jan > Oh sorry, here is the link to vmlinux https://drive.google.com/file/d/0B6Ol0ob95UxXN0dDMWM1a29vMEk/view?usp=sharing -- Sincerely, Kevin Moraga PGP: F258EDCB Fingerprint: 3915 A5A9 959C D18F 0A89 B47E FB4B 55F5 F258 EDCB signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dumping Xen stack
On 09/05/16 17:37, Zytaruk, Kelly wrote: > Does Xen have an equivalent function to the Linux dump_stack() function? > > I am hitting a panic followed by a reboot and would like to find out where I > am coming from. At the point of a crash, the stack should be printed on the console. Alternatively, show_execution_state() at any point should dump the Xen register/stack. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-hvm: ignore background I/O sections
On 09/05/2016 18:18, Paul Durrant wrote: > Since Xen will correctly handle accesses to unimplemented I/O ports (by > returning all 1's for reads and ignoring writes) there is no need for > QEMU to register backgroud I/O sections. > > This patch therefore adds checks to xen_io_add/del so that sections with > memory-region ops pointing at 'unassigned_io_ops' are ignored. > > Signed-off-by: Paul Durrant > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Paolo Bonzini > --- > xen-hvm.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/xen-hvm.c b/xen-hvm.c > index 039680a..8ab44f0 100644 > --- a/xen-hvm.c > +++ b/xen-hvm.c > @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener, > MemoryRegionSection *section) > { > XenIOState *state = container_of(listener, XenIOState, io_listener); > +MemoryRegion *mr = section->mr; > > -memory_region_ref(section->mr); > +if (mr->ops == &unassigned_io_ops) > +return; Missing braces, same in xen_io_del. Otherwise looks ok. Paolo > +memory_region_ref(mr); > > xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); > } > @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener, > MemoryRegionSection *section) > { > XenIOState *state = container_of(listener, XenIOState, io_listener); > +MemoryRegion *mr = section->mr; > + > +if (mr->ops == &unassigned_io_ops) > +return; > > xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); > > -memory_region_unref(section->mr); > +memory_region_unref(mr); > } > > static void xen_device_realize(DeviceListener *listener, > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] dumping Xen stack
Does Xen have an equivalent function to the Linux dump_stack() function? I am hitting a panic followed by a reboot and would like to find out where I am coming from. Thanks, Kelly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes
Ian Jackson writes ("Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes"): > Jim Fehlig writes ("[Xen-devel] [PATCH] tools: Restrict configuration of qemu > processes"): > > Commit 6ef823fd added '-nodefaults' to the qemu args created by > > libxl, which is a good step in restricting qemu's default > > configuration. This change takes another step by adding > > -no-user-config, which ignores any user-provided config files in > > sysconfdir. Together, -nodefaults and -no-user-config allow Xen > > to avoid unkown and uncontrolled qemu configuration. > > > > Both options are also added to the qemu invocation in the > > xen-qemu-dom0-disk-backend systemd service file. > > Queued, thanks. Also listed for backport. I found this on my backport todo list. Thinking about it, I have had second thoughts. I worry that existing users of stable branches might be relying on the user config feature (for example by dropping qemu configuration in ~root). If they are, then applying this would break things for them. It's not a security problem because in xen the configuration in question would have to come from ~root. So I think, probably, that we should leave this be (ie, not backport the patch). Does anyone want to try to change my mind ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen-hvm: ignore background I/O sections
Since Xen will correctly handle accesses to unimplemented I/O ports (by returning all 1's for reads and ignoring writes) there is no need for QEMU to register backgroud I/O sections. This patch therefore adds checks to xen_io_add/del so that sections with memory-region ops pointing at 'unassigned_io_ops' are ignored. Signed-off-by: Paul Durrant Cc: Stefano Stabellini Cc: Anthony Perard Cc: Paolo Bonzini --- xen-hvm.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/xen-hvm.c b/xen-hvm.c index 039680a..8ab44f0 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener, MemoryRegionSection *section) { XenIOState *state = container_of(listener, XenIOState, io_listener); +MemoryRegion *mr = section->mr; -memory_region_ref(section->mr); +if (mr->ops == &unassigned_io_ops) +return; + +memory_region_ref(mr); xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); } @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener, MemoryRegionSection *section) { XenIOState *state = container_of(listener, XenIOState, io_listener); +MemoryRegion *mr = section->mr; + +if (mr->ops == &unassigned_io_ops) +return; xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); -memory_region_unref(section->mr); +memory_region_unref(mr); } static void xen_device_realize(DeviceListener *listener, -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARM bare metal application test
Hello Ivan, On 09/05/16 11:29, Ivan Pavić2 wrote: Julien Grail wrote: You can dump the registers of a vCPU with xenctx. $PREFIX/lib/xen/bin/xenctx domid $PREFIX is the path where xen tools have been installed (i.e --prefix on the configure). The default path is /usr/local/ Thanks for advice. I discovered that the PC has value 0x0C and SPSR of ABT mode is same as CPSR so I think that is prefetch abort. But I don't understand why it happens? Invalid memory access? I'm using simple linker script: Guest are booting with MMU disabled, so 0x80008000 will be the physical address. The toolstack will load the kernel at this physical address. However, the start of the guest RAM for Xen 4.7 is 0x4000 (see include/public/arch-arm.h). Can you try to use 0x40008000 for the guest address? By the way, how much RAM did you give to the guest? ... OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { _start = 0x80008000; . = _start; .text : { *(.start); *(.text); } ... Thanks in advance. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 93911: tolerable all pass - PUSHED
flight 93911 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/93911/ 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 4084fee7a3204bf8ccf7d993dea09186e4e7dd48 baseline version: xen f8c66c2ad2efdb281e4ebf15bf329d73c4f02ce7 Last test of basis93623 2016-05-06 17:00:49 Z2 days Testing same since93908 2016-05-09 12:01:07 Z0 days2 attempts People who touched revisions under test: George Dunlap Jan Beulich Juergen Gross 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=4084fee7a3204bf8ccf7d993dea09186e4e7dd48 + . ./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 4084fee7a3204bf8ccf7d993dea09186e4e7dd48 + branch=xen-unstable-smoke + revision=4084fee7a3204bf8ccf7d993dea09186e4e7dd48 + . ./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.6-testing + '[' x4084fee7a3204bf8ccf7d993dea09186e4e7dd48 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=' x ']
[Xen-devel] Odgovor: ARM bare metal application test
Konrad Rzeszutek Wilk wrote: > OK, but that makes an ELF file. I believe (based on the Booting) you need to > extract > the binary code out and also fixup the branch instructions (maybe make > __Start = 0;?). > The Booting says: > - The boot loader is expected to call the kernel image by jumping > directly to the first instruction of the kernel image. > So if it is ELF it will jump in the ELF header, not the cod Ok, this is objdump -h app.elf Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 80008000 80008000 8000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .ARM.attributes 001f 8034 2**0 CONTENTS, READONLY I extracted binary with objcopy and used it to start domain: Segment of output of: xl -vvv create dom.cfg ... domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32) loader ... domainbuilder: detail: loader probe OK domainbuilder: detail: xc_dom_parse_zimage32_kernel: called ... domainbuilder: detail: vcpu_arm32: called domainbuilder: detail: Initial state CPSR 0x1d3 PC 0x80008000 ... Only thing I can think of is that I'm accessing memory I can't access by default of MMU and that causes prefetch abort but I don't know which memory segment I can use? Regards, Ivan Pavic. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures
>>> On 06.05.16 at 10:54, wrote: > --- a/xen/drivers/passthrough/iommu.c > +++ b/xen/drivers/passthrough/iommu.c > @@ -240,21 +240,47 @@ int iommu_map_page(struct domain *d, unsigned long gfn, > unsigned long mfn, > unsigned int flags) > { > const struct domain_iommu *hd = dom_iommu(d); > +int rc; > > if ( !iommu_enabled || !hd->platform_ops ) > return 0; > > -return hd->platform_ops->map_page(d, gfn, mfn, flags); > +rc = hd->platform_ops->map_page(d, gfn, mfn, flags); > + > +if ( unlikely(rc) ) > +{ > +printk(XENLOG_ERR > + "iommu_map_page: IOMMU mapping gfn %#lx mfn %#lx failed for > dom%d.", > + gfn, mfn, d->domain_id); > + > +if ( !is_hardware_domain(d) ) > +domain_crash(d); > +} This still may spam the console in at least the case of Dom0. For DomU I'd really expect you to state in the commit message why no spamming can occur (of course assuming it really can't, which I'm not convinced of). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)
> -Original Message- > From: Paul Durrant > Sent: 09 May 2016 17:02 > To: Paul Durrant; Paolo Bonzini; Martin Cerveny > Cc: xen-de...@lists.xensource.com; George Dunlap > Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server > (Xen4.6.1) > > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > > Paul Durrant > > Sent: 09 May 2016 14:00 > > To: Paolo Bonzini; Martin Cerveny > > Cc: xen-de...@lists.xensource.com; George Dunlap > > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server > > (Xen4.6.1) > > > > > -Original Message- > > > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > > > Sent: 09 May 2016 13:56 > > > To: Paul Durrant; Martin Cerveny > > > Cc: George Dunlap; xen-de...@lists.xensource.com > > > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server > > > (Xen4.6.1) > > > > > > > > > > > > On 28/04/2016 13:25, Paul Durrant wrote: > > > >> Maybe you are lucky, qemu is registered before your own demu > > > >> emulator. > > > > > > > > I guess I was lucky. > > > > > > Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory: > > > Provide separate handling of unassigned io ports accesses", 2013-09-05). > > > > > > >> I used for testing your "demu" 2 years ago, now extending Citrix > > > >> "vgpu", all was fine up to xen 4.5.2 (with qemu 2.0.2) but > > > >> problem begin when I switched to 4.6.1 (with qemu 2.2.1), but it > > > >> maybe lucky timing in registration. > > > > > > > > I think Xen should really be spotting range overlaps like this, but > > > > the QEMU<->Xen interface will clearly need to be fixed to avoid the > > > > over-claiming of I/O ports like this. > > > > > > If the handling of unassigned I/O ports is sane in Xen (in QEMU they > > > return all ones and discard writes), > > > > Yes, it does exactly that. > > > > > it would be okay to make the > > > background 0-65535 range conditional on !xen_enabled(). See > > > memory_map_init() in QEMU's exec.c file. > > > > > > > Cool. Thanks for the tip. Will have a look at that now. > > > > Looks like creation of the background range is required. (Well, when I simply > #if 0-ed out creating it QEMU crashed on invocation). So, I guess I need to be > able to spot, from the memory listener callback in Xen, when a background > range is being added so it can be ignored. Same actually goes for memory as > well as I/O, since Xen will handle access to unimplemented MMIO ranges in a > similar fashion. > In fact, this patch seems to do the trick for I/O: diff --git a/xen-hvm.c b/xen-hvm.c index 039680a..8ab44f0 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener, MemoryRegionSection *section) { XenIOState *state = container_of(listener, XenIOState, io_listener); +MemoryRegion *mr = section->mr; -memory_region_ref(section->mr); +if (mr->ops == &unassigned_io_ops) +return; + +memory_region_ref(mr); xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); } @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener, MemoryRegionSection *section) { XenIOState *state = container_of(listener, XenIOState, io_listener); +MemoryRegion *mr = section->mr; + +if (mr->ops == &unassigned_io_ops) +return; xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); -memory_region_unref(section->mr); +memory_region_unref(mr); } Paul > Paul > > > Cheers, > > > > Paul > > > > > Paolo > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Ping: [PATCH] XSA-77: widen scope again
On 06/05/16 09:12, Jan Beulich wrote: On 29.04.16 at 11:35, wrote: >> As discussed on the hackathon, avoid us having to issue security >> advisories for issues affecting only heavily disaggregated tool stack >> setups, which no-one appears to use (or else they should step up to get >> things into shape). >> >> Signed-off-by: Jan Beulich > > Ping? > >> --- >> As we want to retain supported status of stubdom qemu: Does qemu use >> any others when use in a stub domain? >> >> --- a/docs/misc/xsm-flask.txt >> +++ b/docs/misc/xsm-flask.txt >> @@ -59,68 +59,16 @@ http://www.xenproject.org/security-polic >> >> __HYPERVISOR_domctl (xen/include/public/domctl.h) >> >> - The following subops are covered by this statement. subops not listed >> - here are considered safe for disaggregation. >> + All subops except for the following are covered by this statement. Sorry I'm just getting to this -- I think the wording is a bit unclear here. The previous wording made it clear what "covered by this statement" means -- i.e., "subops not listed here are considered safe for disaggregation". Maybe something like this: "All subops except the following are covered by this statement. (That is, only the subops below are considered safe for disaggregation.)" >> >> - * XEN_DOMCTL_createdomain >> - * XEN_DOMCTL_destroydomain >> - * XEN_DOMCTL_getmemlist >> - * XEN_DOMCTL_setvcpuaffinity >> - * XEN_DOMCTL_shadow_op >> - * XEN_DOMCTL_max_mem >> - * XEN_DOMCTL_setvcpucontext >> - * XEN_DOMCTL_getvcpucontext >> - * XEN_DOMCTL_max_vcpus >> - * XEN_DOMCTL_scheduler_op >> - * XEN_DOMCTL_iomem_permission >> - * XEN_DOMCTL_gethvmcontext >> - * XEN_DOMCTL_sethvmcontext >> - * XEN_DOMCTL_set_address_size >> - * XEN_DOMCTL_assign_device >> - * XEN_DOMCTL_pin_mem_cacheattr >> - * XEN_DOMCTL_set_ext_vcpucontext >> - * XEN_DOMCTL_get_ext_vcpucontext >> - * XEN_DOMCTL_test_assign_device >> - * XEN_DOMCTL_set_target >> - * XEN_DOMCTL_deassign_device >> - * XEN_DOMCTL_get_device_group >> - * XEN_DOMCTL_set_machine_address_size >> - * XEN_DOMCTL_debug_op >> - * XEN_DOMCTL_gethvmcontext_partial >> - * XEN_DOMCTL_vm_event_op >> - * XEN_DOMCTL_mem_sharing_op >> - * XEN_DOMCTL_setvcpuextstate >> - * XEN_DOMCTL_getvcpuextstate >> - * XEN_DOMCTL_set_access_required >> - * XEN_DOMCTL_set_virq_handler >> - * XEN_DOMCTL_set_broken_page_p2m >> - * XEN_DOMCTL_setnodeaffinity >> - * XEN_DOMCTL_gdbsx_guestmemio >> + * XEN_DOMCTL_ioport_mapping >> + * XEN_DOMCTL_memory_mapping >> + * XEN_DOMCTL_bind_pt_irq >> + * XEN_DOMCTL_unbind_pt_irq >> >> __HYPERVISOR_sysctl (xen/include/public/sysctl.h) >> >> - The following subops are covered by this statement. subops not listed >> - here are considered safe for disaggregation. >> - >> - * XEN_SYSCTL_readconsole >> - * XEN_SYSCTL_tbuf_op >> - * XEN_SYSCTL_physinfo >> - * XEN_SYSCTL_sched_id >> - * XEN_SYSCTL_perfc_op >> - * XEN_SYSCTL_getdomaininfolist >> - * XEN_SYSCTL_debug_keys >> - * XEN_SYSCTL_getcpuinfo >> - * XEN_SYSCTL_availheap >> - * XEN_SYSCTL_get_pmstat >> - * XEN_SYSCTL_cpu_hotplug >> - * XEN_SYSCTL_pm_op >> - * XEN_SYSCTL_page_offline_op >> - * XEN_SYSCTL_lockprof_op >> - * XEN_SYSCTL_cputopoinfo >> - * XEN_SYSCTL_numainfo >> - * XEN_SYSCTL_cpupool_op >> - * XEN_SYSCTL_scheduler_op >> - * XEN_SYSCTL_coverage_op >> + All subops are covered by this statement. "... (That is, no subops are considered safe for disaggregation.)" -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)
> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: 09 May 2016 17:18 > To: Paul Durrant; Martin Cerveny > Cc: xen-de...@lists.xensource.com; George Dunlap > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server > (Xen4.6.1) > > > > On 09/05/2016 18:14, Paul Durrant wrote: > >> -Original Message- > >> From: Paul Durrant > >> Sent: 09 May 2016 17:02 > >> To: Paul Durrant; Paolo Bonzini; Martin Cerveny > >> Cc: xen-de...@lists.xensource.com; George Dunlap > >> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server > >> (Xen4.6.1) > >> > >>> -Original Message- > >>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf > Of > >>> Paul Durrant > >>> Sent: 09 May 2016 14:00 > >>> To: Paolo Bonzini; Martin Cerveny > >>> Cc: xen-de...@lists.xensource.com; George Dunlap > >>> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server > >>> (Xen4.6.1) > >>> > -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: 09 May 2016 13:56 > To: Paul Durrant; Martin Cerveny > Cc: George Dunlap; xen-de...@lists.xensource.com > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server > (Xen4.6.1) > > > > On 28/04/2016 13:25, Paul Durrant wrote: > >> Maybe you are lucky, qemu is registered before your own demu > >> emulator. > > > > I guess I was lucky. > > Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, > "memory: > Provide separate handling of unassigned io ports accesses", 2013-09- > 05). > > >> I used for testing your "demu" 2 years ago, now extending Citrix > >> "vgpu", all was fine up to xen 4.5.2 (with qemu 2.0.2) but > >> problem begin when I switched to 4.6.1 (with qemu 2.2.1), but it > >> maybe lucky timing in registration. > > > > I think Xen should really be spotting range overlaps like this, but > > the QEMU<->Xen interface will clearly need to be fixed to avoid the > > over-claiming of I/O ports like this. > > If the handling of unassigned I/O ports is sane in Xen (in QEMU they > return all ones and discard writes), > >>> > >>> Yes, it does exactly that. > >>> > it would be okay to make the > background 0-65535 range conditional on !xen_enabled(). See > memory_map_init() in QEMU's exec.c file. > > >>> > >>> Cool. Thanks for the tip. Will have a look at that now. > >>> > >> > >> Looks like creation of the background range is required. (Well, when I > simply > >> #if 0-ed out creating it QEMU crashed on invocation). So, I guess I need to > be > >> able to spot, from the memory listener callback in Xen, when a > background > >> range is being added so it can be ignored. Same actually goes for memory > as > >> well as I/O, since Xen will handle access to unimplemented MMIO ranges > in a > >> similar fashion. > >> > > > > In fact, this patch seems to do the trick for I/O: > > > > diff --git a/xen-hvm.c b/xen-hvm.c > > index 039680a..8ab44f0 100644 > > --- a/xen-hvm.c > > +++ b/xen-hvm.c > > @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener, > > MemoryRegionSection *section) > > { > > XenIOState *state = container_of(listener, XenIOState, io_listener); > > +MemoryRegion *mr = section->mr; > > > > -memory_region_ref(section->mr); > > +if (mr->ops == &unassigned_io_ops) > > +return; > > + > > +memory_region_ref(mr); > > > > xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); > > } > > @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener, > > MemoryRegionSection *section) > > { > > XenIOState *state = container_of(listener, XenIOState, io_listener); > > +MemoryRegion *mr = section->mr; > > + > > +if (mr->ops == &unassigned_io_ops) > > +return; > > > > xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); > > > > -memory_region_unref(section->mr); > > +memory_region_unref(mr); > > } > > Looks good, feel free to Cc me if you send it to qemu-devel (though I'll > let Anthony merge it). Cool, thanks. Paul > > Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)
On 09/05/2016 18:14, Paul Durrant wrote: >> -Original Message- >> From: Paul Durrant >> Sent: 09 May 2016 17:02 >> To: Paul Durrant; Paolo Bonzini; Martin Cerveny >> Cc: xen-de...@lists.xensource.com; George Dunlap >> Subject: RE: [Xen-devel] Overlaped PIO with multiple ioreq_server >> (Xen4.6.1) >> >>> -Original Message- >>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of >>> Paul Durrant >>> Sent: 09 May 2016 14:00 >>> To: Paolo Bonzini; Martin Cerveny >>> Cc: xen-de...@lists.xensource.com; George Dunlap >>> Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server >>> (Xen4.6.1) >>> -Original Message- From: Paolo Bonzini [mailto:pbonz...@redhat.com] Sent: 09 May 2016 13:56 To: Paul Durrant; Martin Cerveny Cc: George Dunlap; xen-de...@lists.xensource.com Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1) On 28/04/2016 13:25, Paul Durrant wrote: >> Maybe you are lucky, qemu is registered before your own demu >> emulator. > > I guess I was lucky. Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory: Provide separate handling of unassigned io ports accesses", 2013-09-05). >> I used for testing your "demu" 2 years ago, now extending Citrix >> "vgpu", all was fine up to xen 4.5.2 (with qemu 2.0.2) but >> problem begin when I switched to 4.6.1 (with qemu 2.2.1), but it >> maybe lucky timing in registration. > > I think Xen should really be spotting range overlaps like this, but > the QEMU<->Xen interface will clearly need to be fixed to avoid the > over-claiming of I/O ports like this. If the handling of unassigned I/O ports is sane in Xen (in QEMU they return all ones and discard writes), >>> >>> Yes, it does exactly that. >>> it would be okay to make the background 0-65535 range conditional on !xen_enabled(). See memory_map_init() in QEMU's exec.c file. >>> >>> Cool. Thanks for the tip. Will have a look at that now. >>> >> >> Looks like creation of the background range is required. (Well, when I simply >> #if 0-ed out creating it QEMU crashed on invocation). So, I guess I need to >> be >> able to spot, from the memory listener callback in Xen, when a background >> range is being added so it can be ignored. Same actually goes for memory as >> well as I/O, since Xen will handle access to unimplemented MMIO ranges in a >> similar fashion. >> > > In fact, this patch seems to do the trick for I/O: > > diff --git a/xen-hvm.c b/xen-hvm.c > index 039680a..8ab44f0 100644 > --- a/xen-hvm.c > +++ b/xen-hvm.c > @@ -510,8 +510,12 @@ static void xen_io_add(MemoryListener *listener, > MemoryRegionSection *section) > { > XenIOState *state = container_of(listener, XenIOState, io_listener); > +MemoryRegion *mr = section->mr; > > -memory_region_ref(section->mr); > +if (mr->ops == &unassigned_io_ops) > +return; > + > +memory_region_ref(mr); > > xen_map_io_section(xen_xc, xen_domid, state->ioservid, section); > } > @@ -520,10 +524,14 @@ static void xen_io_del(MemoryListener *listener, > MemoryRegionSection *section) > { > XenIOState *state = container_of(listener, XenIOState, io_listener); > +MemoryRegion *mr = section->mr; > + > +if (mr->ops == &unassigned_io_ops) > +return; > > xen_unmap_io_section(xen_xc, xen_domid, state->ioservid, section); > > -memory_region_unref(section->mr); > +memory_region_unref(mr); > } Looks good, feel free to Cc me if you send it to qemu-devel (though I'll let Anthony merge it). Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
(CC Shannon, Stefano and Steve) Hi Lars, On 09/05/16 16:28, Lars Kurth wrote: Hi all, I added the following sections based on git logs to man pages. Authors are on the CC list and should review and modify (or suggest edits by replying to this thread). I added/updated/added TODO's to: I do have some questions, to ... - Konrad/Ross: is there any documentation for xSplice which I have missed? - Julien: Any ARM specific stuff you want people to test? General testing of Xen on the boards we are supporting. We may also want some testing on ACPI, which will be in tech preview for Xen 4.7. However this is requiring platform with ACPI 6.0 (or later). If I remember correctly, none of the ARM64 platform we support fulfill this requirement. Steve, do you have any platform in mind? Shannon, which platform have you used for the ACPI development? Was it the Foundation Model? If so we would need to write down (or update) a wiki page with the instructions to boot Xen on the model. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue
>>> On 06.05.16 at 10:54, wrote: > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn, > unsigned int page_count) > +static void iommu_flush_iotlb_page(struct domain *d, unsigned long gfn, > + unsigned int page_count) The new name suggests just one page. Please use e.g. iommu_flush_iotlb_pages() instead. > { > -__intel_iommu_iotlb_flush(d, gfn, 1, page_count); > +iommu_flush_iotlb(d, gfn, 1, page_count); > } But of course the question is whether having this wrapper is useful in the first place, the more that ... > @@ -639,7 +646,7 @@ static void dma_pte_clear_one(struct domain *domain, u64 > addr) > iommu_flush_cache_entry(pte, sizeof(struct dma_pte)); > > if ( !this_cpu(iommu_dont_flush_iotlb) ) > -__intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1); > +iommu_flush_iotlb(domain, addr >> PAGE_SHIFT_4K, 1, 1); ... it's being open coded here. IOW if you want to retain the wrapper, please use it here. > @@ -1391,13 +1399,19 @@ int domain_context_mapping_one( > spin_unlock(&iommu->lock); > > /* Context entry was previously non-present (with domid 0). */ > -if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn, > -DMA_CCMD_MASK_NOBIT, 1) ) > -iommu_flush_write_buffer(iommu); > -else > +rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn, > +DMA_CCMD_MASK_NOBIT, 1); > + > +if ( !rc ) > { > int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0; > -iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb); > +rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb); Please take the opportunity and add the missing blank line (between declaration(s) and statement(s) in cases like this. > +} > + > +if ( rc > 0 ) Can iommu_flush_context_device() return a positive value? If so, the logic is now likely wrong. If not (which is what I assume) I'd like to suggest adding a respective ASSERT() (even if only to document the fact). Or alternatively this if() could move into the immediately preceding one. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
On Mon, May 9, 2016 at 4:28 PM, Lars Kurth wrote: > Hi all, > > I added the following sections based on git logs to man pages. Authors are on > the CC list and should review and modify (or suggest edits by replying to > this thread). I added/updated/added TODO's to: > > I do have some questions, to ... > - Konrad/Ross: is there any documentation for xSplice which I have missed? > - Julien: Any ARM specific stuff you want people to test? > - Doug: are there any docs / tests for KCONFIG you want to push > - George: are there any manual tests for credit 2 hard affinity, for hotplug > disk backends (drbd, iscsi, &c) and soft reset for HVM guests that should be > added? Hard affinity tests shouldn't be too difficult to add in. There are certainly tests for drbd and iscsi, but I'm not personally that familiar with them, it would basically be, "If you use drbd or iscsi backends, try HVM guests". :-) Soft Reset was added in by Vitaly, I believe; I listed it because I saw it in the git history. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Paul Durrant > Sent: 09 May 2016 14:00 > To: Paolo Bonzini; Martin Cerveny > Cc: xen-de...@lists.xensource.com; George Dunlap > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server > (Xen4.6.1) > > > -Original Message- > > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > > Sent: 09 May 2016 13:56 > > To: Paul Durrant; Martin Cerveny > > Cc: George Dunlap; xen-de...@lists.xensource.com > > Subject: Re: [Xen-devel] Overlaped PIO with multiple ioreq_server > > (Xen4.6.1) > > > > > > > > On 28/04/2016 13:25, Paul Durrant wrote: > > >> Maybe you are lucky, qemu is registered before your own demu > > >> emulator. > > > > > > I guess I was lucky. > > > > Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory: > > Provide separate handling of unassigned io ports accesses", 2013-09-05). > > > > >> I used for testing your "demu" 2 years ago, now extending Citrix > > >> "vgpu", all was fine up to xen 4.5.2 (with qemu 2.0.2) but > > >> problem begin when I switched to 4.6.1 (with qemu 2.2.1), but it > > >> maybe lucky timing in registration. > > > > > > I think Xen should really be spotting range overlaps like this, but > > > the QEMU<->Xen interface will clearly need to be fixed to avoid the > > > over-claiming of I/O ports like this. > > > > If the handling of unassigned I/O ports is sane in Xen (in QEMU they > > return all ones and discard writes), > > Yes, it does exactly that. > > > it would be okay to make the > > background 0-65535 range conditional on !xen_enabled(). See > > memory_map_init() in QEMU's exec.c file. > > > > Cool. Thanks for the tip. Will have a look at that now. > Looks like creation of the background range is required. (Well, when I simply #if 0-ed out creating it QEMU crashed on invocation). So, I guess I need to be able to spot, from the memory listener callback in Xen, when a background range is being added so it can be ignored. Same actually goes for memory as well as I/O, since Xen will handle access to unimplemented MMIO ranges in a similar fashion. Paul > Cheers, > > Paul > > > Paolo > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24
>>> On 09.05.16 at 16:52, wrote: > On 05/09/2016 04:08 AM, Jan Beulich wrote: > On 09.05.16 at 00:51, wrote: >>> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 >>> and Intel Skylake processor (Intel Core i7-6600U) >>> >>> This kernel is crashing almost in the same way as explained in this >>> thread... But my problem is mainly with Skylake. Because the same >>> configuration works within another machine but with another processor >>> (Intel Core i5-3340M). Attached are the boot logs. >> The address the fault occurs on (806bdee0) is bogus, so >> from the register and stack dump alone I don't think we can derive >> much. What we'd need is access to the kernel binary used (or >> really the vmlinux accompanying the vmlinuz that was used), in >> order to see where exactly the kernel died, and hence where this >> bogus address originates from. As I understand it this is a kernel >> you built yourself - can you make said binary from exactly that >> build available somewhere? > Yes I have it. But I get the same crash on various 4.4.X and also with > 4.5.3. > > **https://drive.google.com/open?id=0B6Ol0ob95UxXQV9HM1BWMmhCZ0E Well, this doesn't contain the file I'm after (vmlinux), and taking apart vmlinuz would be quite cumbersome. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARM bare metal application test
On Mon, May 09, 2016 at 10:29:09AM +, Ivan Pavić2 wrote: > Julien Grail wrote: > > > You can dump the registers of a vCPU with xenctx. > > > $PREFIX/lib/xen/bin/xenctx domid > > > $PREFIX is the path where xen tools have been installed (i.e --prefix on > > the configure). The default path is /usr/local/ > > Thanks for advice. I discovered that the PC has value 0x0C and SPSR of ABT > mode is same > as CPSR so I think that is prefetch abort. But I don't understand why it > happens? Invalid memory > access? I'm using simple linker script: What does objdump tell you for the binary? Julien, is there an document outlining what the state of the CPU is when a guest is started on ARM? Ah in the Linux Documentation/arm/Booting > > ... > OUTPUT_ARCH(arm) > ENTRY(_start) > SECTIONS > { > _start = 0x80008000; > > . = _start; > > .text : { > *(.start); > *(.text); > } OK, but that makes an ELF file. I believe (based on the Booting) you need to extract the binary code out and also fixup the branch instructions (maybe make __Start = 0;?). The Booting says: - The boot loader is expected to call the kernel image by jumping directly to the first instruction of the kernel image. So if it is ELF it will jump in the ELF header, not the code. > ... > > Thanks in advance. > Ivan Pavić > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling
On Mon, May 9, 2016 at 3:58 PM, Wei Liu wrote: > On Mon, May 09, 2016 at 03:46:23PM +0100, George Dunlap wrote: >> On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote: >> > On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli >> > wrote: >> >> >> >> The scheduling hooks API is now used properly, and no >> >> initialization or de-initialization happen in >> >> alloc/free_pdata any longer. >> >> >> >> In fact, just like it is for Credit2, there is no real >> >> need for implementing alloc_pdata and free_pdata. >> >> >> >> This also made it possible to improve the replenishment >> >> timer handling logic, such that now the timer is always >> >> kept on one of the pCPU of the scheduler it's servicing. >> >> Before this commit, in fact, even if the pCPU where the >> >> timer happened to be initialized at creation time was >> >> moved to another cpupool, the timer stayed there, >> >> potentially inferfearing with the new scheduler of the >> >> pCPU itself. >> >> >> >> Signed-off-by: Dario Faggioli >> >> -- >> > >> > Reviewed-and-Tested-by: Meng Xu >> >> And on that basis: >> >> Acked-by: George Dunlap >> >> But it looks like it still needs a release ack? >> > > Release-acked-by: Wei Liu And pushed. Thanks. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
> > You need to have appropriate log level set. > > Try adding loglvl=all guest_loglvl=all to your xen command line and > reboot. > > Wei. > I've enabled all the log level just as you said, but no outputs happen at HVMOP_altp2m_vcpu_enable_notify section of do_altp2m_op function, so does that means the function are not called at all? case HVMOP_altp2m_vcpu_enable_notify: > { > struct vcpu *curr = current; > p2m_type_t p2mt; > if ( a.u.enable_notify.pad || a.domain != DOMID_SELF || > a.u.enable_notify.vcpu_id != curr->vcpu_id ) > { > rc = -EINVAL; > > * gdprintk(XENLOG_INFO, "enable_notify args error pad:%d domain:%d vcpu:%d > curr->vcpu:%d\n",**a.u.enable_notify.pad, a.domain, > a.u.enable_notify.vcpu_id, curr->vcpu_id);* > } > if ( (gfn_x(vcpu_altp2m(curr).veinfo_gfn) != INVALID_GFN) || > (mfn_x(get_gfn_query_unlocked(curr->domain, > a.u.enable_notify.gfn, &p2mt)) == INVALID_MFN) ) > { > return -EINVAL; >* gdprintk(XENLOG_INFO, "veinfo page is invalid\n");* > } > vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn); > altp2m_vcpu_update_vmfunc_ve(curr); > *gdprintk(XENLOG_INFO, "veinfo page set successfully\n");* > break; > } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 4/4] x86/hvm: Fix invalidation for emulated invlpg instructions
On 09/05/16 16:14, Tim Deegan wrote: > Hi, > > At 14:15 +0100 on 09 May (1462803342), Andrew Cooper wrote: >> hap_invlpg() is reachable from the instruction emulator, which means >> introspection and tests using hvm_fep can end up here. As such, crashing the >> domain is not an appropriate action to take. >> >> Fixing this involves rearranging the callgraph. >> >> paging_invlpg() is now the central entry point. It first checks for >> applicability of invalidation based on virtual address, and optionally calls >> into the paging invalidation logic. For HVM domains, it also makes ASID/VPID >> management calls. > This reshuffle looks fine, but leaves the return value looking pretty > strange. I suppose it does. This looks to be better option. > For HVM guests it's longer correct (since the hardware > operation has moved inside paging_invlpg() it should always return 0) > but none of the callers actually check it, so yay? > > I think it might be better to make that return value internal to > paging_invlpg() and have it DTRT for PV guests as it now does for HVM > ones, e.g.: > > void paging_invlpg(struct vcpu *v, unsigned long va) > { > if ( !is_canonical_address(va) ) > return; > > if ( paging_mode_enabled(v->domain) >&& !paging_get_hostmode(v)->invlpg(v, va) ) > return; > > if ( is_pv_vcpu(v) ) > flush_tlb_one_local(va) > else > hvm_funcs.invlpg(va); > } > > with appropriate simplifications at the PV callsites. > > I simplified the canonical/__addr_ok test there because I don't think > we care about the speed of guest invlpg of Xen addresses; I suspect we > could remove it entirely, and turn a fast emulated NOP into a slow one. A PV guest should not be able to invlpg Xen addresses at all, which is why the checks were recently added in c/s 828e114f7 "x86/mmuext: tighten TLB flush address checks". I will see if I can untangle this as well without avoiding the __addr_ok() check. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7
Hi all, I added the following sections based on git logs to man pages. Authors are on the CC list and should review and modify (or suggest edits by replying to this thread). I added/updated/added TODO's to: I do have some questions, to ... - Konrad/Ross: is there any documentation for xSplice which I have missed? - Julien: Any ARM specific stuff you want people to test? - Doug: are there any docs / tests for KCONFIG you want to push - George: are there any manual tests for credit 2 hard affinity, for hotplug disk backends (drbd, iscsi, &c) and soft reset for HVM guests that should be added? For the following sections there are some TODO's - please verify and modify and once OK, remove the TODO from the wiki pages. VCPU-PIN (Juergen Gross) - http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#-f_option_for_xl_vcpu-pin RTDS (Meng Xu, Chong Li) - Meng, you mention improvements to the RTDS scheduler in another thread - Are any specific test instructions needed in http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions - http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RTDS_scheduler_improvements COLO (Wen Congyang) - http://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping - http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#COLO_-_Coarse_Grain_Lock_Stepping USB (Chunyan Liu) - http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#USB_Support_for_xl - http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB - http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB_in_xl.2Flibxl CDP (He Chen) - http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Intel_Code_and_Data_Prioritization_.28CDP.29 - http://wiki.xenproject.org/wiki/Intel_Platform_QoS_Technologies#Code_and_Data_Prioritization_.28CDP.29 Are there any other big items that are missing? Regards Lars > On 5 May 2016, at 18:08, Lars Kurth wrote: > > Hi everyone, > > I updated http://wiki.xenproject.org/wiki/Xen_Project_Test_Days and created > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions (note that we > only have one page for all RC's now to avoid unnecessary copy and pasting). > > For those who want new features to be tested, please expect to > a) Explain what to test (a very short description of the feature) > b) Add some instructions on how to test (e.g. some command line instructions) > > You can add a new headline (an example is marked with TODO) to either > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_ARM_Test_Instructions > - > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_x86_Test_Instructions > - OR > http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RC_specific_things_to_test > (under a specific RC heading) > > I will start promoting Test Days from early next week (on the blog, but also > on the mailing lists). The more specific test instructions for Xen 4.7 > related features, the better the coverage will be and the more likely people > are to actually test. > > Best Regards > Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 93901: regressions - FAIL
flight 93901 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/93901/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 275d51369a55952c7d75399752c7269a16ff03de baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 153 days Failing since 65593 2015-12-08 23:44:51 Z 152 days 250 attempts Testing same since93901 2016-05-09 10:44:25 Z0 days1 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Abdul Lateef Attar Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy chenzhihui Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin Dong, Eric edk2 dev edk2-devel Eric Dong Eric Dong erictian Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hegde Nagaraj P Hegde, Nagaraj P Hess Chen Heyi Guo Hot Tian Jaben Carsey James Bottomley Jeff Fan Jeremy Linton Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com jljusten Jordan Justen Juliano Ciocari Justen, Jordan L Karyne Mayer Ken Lu Kun Gui Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leif Lindholm Leo Duran Leon Li Liming Gao lzeng14 Mark Mark Doran Mark Rutland Marvin H?user Marvin Haeuser Marvin Häuser marvin.haeu...@outlook.com Michael D Kinney Michael Kinney Michael LeMay Michael Thomas Michael Zimmermann MichaŠZegan Nagaraj Hegde Ni, Ruiyu Ni, Ruiyu niruiyu Olivier Martin Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qing Huang Qiu Shumin Qiu, Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Shumin Qiu Star Zeng Sunny Wang Supreeth Venkatesh Tapan Shah Thomas Palmer Tian Feng Tian, Feng Vladislav Vovchenko Volker Rümelin Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 23229 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen does not work after changing scheduler's code
On Thu, Apr 28, 2016 at 11:46 AM, tutu sky wrote: > > hi Geoge, > I don't get your meaning. would you please repeat your question for me in > order to understand it? First, please don't top-post. My meaning was this: You said that running Xen inside of VMWare caused your host to crash. I said, none of us know much about VMware, and suggested you try Xen inside of Xen. You responded by saying that you thought Xen inside of VMware would be faster. But what good is it if Xen in VMWare is "faster", if it doesn't even work? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24
On 05/09/2016 04:08 AM, Jan Beulich wrote: On 09.05.16 at 00:51, wrote: >> I'm try to compile kernel 4.4.8 (using fedora 23) to run with Xen 4.6.0 >> and Intel Skylake processor (Intel Core i7-6600U) >> >> This kernel is crashing almost in the same way as explained in this >> thread... But my problem is mainly with Skylake. Because the same >> configuration works within another machine but with another processor >> (Intel Core i5-3340M). Attached are the boot logs. > The address the fault occurs on (806bdee0) is bogus, so > from the register and stack dump alone I don't think we can derive > much. What we'd need is access to the kernel binary used (or > really the vmlinux accompanying the vmlinuz that was used), in > order to see where exactly the kernel died, and hence where this > bogus address originates from. As I understand it this is a kernel > you built yourself - can you make said binary from exactly that > build available somewhere? Yes I have it. But I get the same crash on various 4.4.X and also with 4.5.3. **https://drive.google.com/open?id=0B6Ol0ob95UxXQV9HM1BWMmhCZ0E Also I compiled 4.2.28 / 4.1.X and it works fine with this processor, using i915.preliminary_hw_support, but we are experiencing problems with suspend/wakeup (but that's another story) > Or if you don't have it anymore, obtain > fresh logs for whichever binary you're going to make available? > > Jan Also there are more reports about the same crash with this kernel compiled by someone else: **http://yum.qubes-os.org/r3.1/unstable/dom0/fc20/rpm/kernel-4.4.8-9.pvops.qubes.x86_64.rpm signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling
On Mon, May 09, 2016 at 03:46:23PM +0100, George Dunlap wrote: > On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote: > > On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli > > wrote: > >> > >> The scheduling hooks API is now used properly, and no > >> initialization or de-initialization happen in > >> alloc/free_pdata any longer. > >> > >> In fact, just like it is for Credit2, there is no real > >> need for implementing alloc_pdata and free_pdata. > >> > >> This also made it possible to improve the replenishment > >> timer handling logic, such that now the timer is always > >> kept on one of the pCPU of the scheduler it's servicing. > >> Before this commit, in fact, even if the pCPU where the > >> timer happened to be initialized at creation time was > >> moved to another cpupool, the timer stayed there, > >> potentially inferfearing with the new scheduler of the > >> pCPU itself. > >> > >> Signed-off-by: Dario Faggioli > >> -- > > > > Reviewed-and-Tested-by: Meng Xu > > And on that basis: > > Acked-by: George Dunlap > > But it looks like it still needs a release ack? > Release-acked-by: Wei Liu > -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling
On Mon, May 9, 2016 at 10:52 AM, Dario Faggioli wrote: > On Mon, 2016-05-09 at 10:08 -0400, Meng Xu wrote: >> > I don't think things are confusing, neither right now, nor after >> > this >> > patch, but I'm open to others' opinion. :-) >> >> Hmm, I won't get confused with the comment from now on, but I'm >> unsure >> if someone else will or not. The tricky thing is when I know it, I >> won't feel weird. However, when I first read it, I feel a little >> confusing if not reading the other parts of the code related to this >> macro. >> > I don't feel the same, but I understand the concern. > > I think we have two options here: > 1. we just do nothing; > 2. you send a patch that, according to your best judgement, improve > things (as we all do all the time! :-P). > > :-D > >> Anyway, I'm ok with either way: change the comment or not. >> > Me too, and in fact, I'm not changing it, but I won't stop you tryingto > do so. :-) > OK. I can do it... But is just one comment line change too small to be a patch? ;-) Thanks, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Q35 & virtual VTD support
Hi All: We are researching how to add virtual VTD support for Xen HVM guest. Current qemu has a basic virtual VTD support for Q35. I'd like to confirm whether Xen supports Q35 or not. Can we reuse it for Xen? Thanks. The motivations of adding virtual VTD support for Xen prepare for 1) Shared Virtual Memory (SVM) 2) Increase max VCPUs > 255 (The feature relies on virtual VTD irq remapping function.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling
On Mon, 2016-05-09 at 10:08 -0400, Meng Xu wrote: > > I don't think things are confusing, neither right now, nor after > > this > > patch, but I'm open to others' opinion. :-) > > Hmm, I won't get confused with the comment from now on, but I'm > unsure > if someone else will or not. The tricky thing is when I know it, I > won't feel weird. However, when I first read it, I feel a little > confusing if not reading the other parts of the code related to this > macro. > I don't feel the same, but I understand the concern. I think we have two options here: 1. we just do nothing; 2. you send a patch that, according to your best judgement, improve things (as we all do all the time! :-P). :-D > Anyway, I'm ok with either way: change the comment or not. > Me too, and in fact, I'm not changing it, but I won't stop you tryingto do so. :-) 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 http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling
On Sat, May 7, 2016 at 10:19 PM, Meng Xu wrote: > On Tue, May 3, 2016 at 5:46 PM, Dario Faggioli > wrote: >> >> The scheduling hooks API is now used properly, and no >> initialization or de-initialization happen in >> alloc/free_pdata any longer. >> >> In fact, just like it is for Credit2, there is no real >> need for implementing alloc_pdata and free_pdata. >> >> This also made it possible to improve the replenishment >> timer handling logic, such that now the timer is always >> kept on one of the pCPU of the scheduler it's servicing. >> Before this commit, in fact, even if the pCPU where the >> timer happened to be initialized at creation time was >> moved to another cpupool, the timer stayed there, >> potentially inferfearing with the new scheduler of the >> pCPU itself. >> >> Signed-off-by: Dario Faggioli >> -- > > Reviewed-and-Tested-by: Meng Xu And on that basis: Acked-by: George Dunlap But it looks like it still needs a release ack? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k
On 21/04/16 15:27, Pali Rohár wrote: > On Thursday 21 April 2016 15:12:52 Juergen Gross wrote: >> On 21/04/16 12:57, Pali Rohár wrote: >>> On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote: On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote: > On Tue, Apr 05, 2016 at 07:10:07AM +0200, Juergen Gross wrote: >> Use the smp_call_on_cpu() function to call system management >> mode on cpu 0. >> Make call secure by adding get_online_cpus() to avoid e.g. suspend >> resume cycles in between. >> >> Signed-off-by: Juergen Gross >> --- >> V4: add call to get_online_cpus() > > Pali, any chance to test this ? I can test it, but just on machine where (probably) smm calls can be send from any cpu... Need some time for testing and I believe I can do that at the end of the week. >>> >>> Sorry I had absolutely no more free time last weekend :-( And same >>> prediction is for this weekend and also next one... >> >> Pali, I've got a Dell laptop (Latitude E6440) here. Would this device be >> okay for a test? > > Hi! > > Proper regression test should check if this patch does not break any > function or drivers dependent on dcdbas.ko. And should be done on both > notebook devices: which needs to issue that smm call on cpu 0 and also > on which it is not needed. Hmm, couldn't get one which needs smm to be called on cpu 0. OTOH I've done various tests and added a printk() in raise_smm() and i8k_smm_func() issuing the cpu number it was called on. > Some notebooks which needs smm call to issued from cpu 0 can be found in > git commit messages of i8k, dell-laptop or dcdbas kernel drivers. > >> What would you do for testing? In case you can give me >> some hints how to do a sensible test I'd do it. > > Test e.g. dell-laptop.ko driver. It provides /sys interface for changing > keyboard backlight or changing rfkill switches (bluetooth wifi). Done. > Also test tools from libsmbios (userspace) package. Done. > There must be no difference in output/functionality with or without your > patches. Verified. >> I've verified by adding a printk() to smp_call_on_cpu() that at least >> one of the modified drivers has been used during system boot. > > Also you can patch i8k/dcdbas smm function to print cpu number on which > is code running (to verify that it was really called on cpu 0 as > needed). Done. I tested suspend/resume, too, as adding get_online_cpus() might have changed behavior. Worked like a charm. :-) Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.7 1/4] xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched()
On Fri, May 6, 2016 at 2:21 PM, Dario Faggioli wrote: > On Wed, 2016-05-04 at 18:34 +0100, George Dunlap wrote: >> On 04/05/16 18:21, Dario Faggioli wrote: >> > >> > After all, I'm fine with an ASSERT() too, but then I think we >> > should >> > add one to the same effect to csched_switch_sched() too. >> Well an ASSERT() is sort of like a comment, in that if you see >> ASSERT(irqs_disabled()), you know there's no need to save irqs >> because >> they should already disabled. But it has the advantage that osstest >> will be able to "read" it once we get some proper cpupool tests for >> osstest. :-) >> >> If we weren't in the feature freeze, I'd definitely favor adding an >> ASSERT to credit1. As it is, I think either way (adding now or >> waiting >> until the 4.8 development window) should be fine. >> > Ok, here you go (inline and attached) the patch with ASSERT()-s both in > Credit2 and Credit1 (despite the freeze, I think it's the best thing to > do, see the changelog). > > Thanks and Regards, > Dario > -- > commit cbabd44e171d0bd2169f1c7100e69a9e48289980 > Author: Dario Faggioli > Date: Tue Apr 26 18:56:56 2016 +0200 > > xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched() > > interrupts are already disabled when calling the hook > (from schedule_cpu_switch()), so we must use spin_lock() > and spin_unlock(). > > Add an ASSERT(), so we will notice if this code and its > caller get out of sync with respect to disabling interrupts > (and add one at the same exact occurrence of this pattern > in Credit1 too) > > Signed-off-by: Dario Faggioli Reviewed-by: George Dunlap And queued, thanks. -George > --- > Cc: George Dunlap > Cc: Wei Liu > -- > Changes from v1: > * add the ASSERT(), as requested by George > * add the ASSERT in Credit1 too > -- > For Wei: > - the Credit2 spin_lock_irq()-->spin_lock() change needs >to go in, as it fixes a bug; > - adding the ASSERT was requested during review; > - adding the ASSERT in Credit1 is not strictly necessary, >but imptoves code quality and consistency at zero cost >and risk, so I think we should just go for it now, instead >of waitign for 4.8 (it's basically like I'm adding a >comment!). > > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c > index db4d42a..a38a63d 100644 > --- a/xen/common/sched_credit.c > +++ b/xen/common/sched_credit.c > @@ -615,6 +615,7 @@ csched_switch_sched(struct scheduler *new_ops, unsigned > int cpu, > * schedule_cpu_switch()). It actually may or may not be the 'right' > * one for this cpu, but that is ok for preventing races. > */ > +ASSERT(!local_irq_is_enabled()); > spin_lock(&prv->lock); > init_pdata(prv, pdata, cpu); > spin_unlock(&prv->lock); > diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c > index f3b62ac..f95e509 100644 > --- a/xen/common/sched_credit2.c > +++ b/xen/common/sched_credit2.c > @@ -2238,7 +2238,8 @@ csched2_switch_sched(struct scheduler *new_ops, > unsigned int cpu, > * And owning exactly that one (the lock of the old scheduler of this > * cpu) is what is necessary to prevent races. > */ > -spin_lock_irq(&prv->lock); > +ASSERT(!local_irq_is_enabled()); > +spin_lock(&prv->lock); > > idle_vcpu[cpu]->sched_priv = vdata; > > @@ -2263,7 +2264,7 @@ csched2_switch_sched(struct scheduler *new_ops, > unsigned int cpu, > smp_mb(); > per_cpu(schedule_data, cpu).schedule_lock = &prv->rqd[rqi].lock; > > -spin_unlock_irq(&prv->lock); > +spin_unlock(&prv->lock); > } > > static void > -- > <> (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 > http://lists.xen.org/xen-devel > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] XSA-77: widen scope again
On 29/04/16 10:35, Jan Beulich wrote: > As discussed on the hackathon, avoid us having to issue security > advisories for issues affecting only heavily disaggregated tool stack > setups, which no-one appears to use (or else they should step up to get > things into shape). > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling
> > > > > I do have a minor comment about the patch, although it is not > > important at all and it is not really about this patch... > > > > > > > > @@ -614,7 +612,8 @@ rt_deinit(struct scheduler *ops) > > > { > > > struct rt_private *prv = rt_priv(ops); > > > > > > -kill_timer(prv->repl_timer); > > > +ASSERT(prv->repl_timer->status == TIMER_STATUS_invalid || > > > + prv->repl_timer->status == TIMER_STATUS_killed); > > I found in xen/timer.h, the comment after the definition of the > > TIMER_STATUS_invalid is > > > > #define TIMER_STATUS_invalid 0 /* Should never see > > this. */ > > > > This comment is a little contrary to how the status is used here. > > Actually, what does it exactly means by "Should never see this"? > > > > This _invalid status is used in timer.h and it is the status when a > > timer is initialized by init_timer(). > > > As far as my understanding goes, this means that a timer, during its > operations, should never be found in this state. > > In fact, this mark a situation where the timer has been allocated but > never initialized, and there are ASSERT()s around to enforce that. > > However, if what one wants is _exactly_ to check whether the timer has > been allocated ut not initialized, I don't see why I can't use this. You can use this. Actually, I agree with how you used this here. Actually, this is also how the existing init_timer() uses it. > > > > So I'm thinking maybe this comment can be better improved to avoid > > confusion? > > > I don't think things are confusing, neither right now, nor after this > patch, but I'm open to others' opinion. :-) Hmm, I won't get confused with the comment from now on, but I'm unsure if someone else will or not. The tricky thing is when I know it, I won't feel weird. However, when I first read it, I feel a little confusing if not reading the other parts of the code related to this macro. Anyway, I'm ok with either way: change the comment or not. Best Regards, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 4/4] x86/hvm: Fix invalidation for emulated invlpg instructions
On 09/05/16 14:57, Jan Beulich wrote: On 09.05.16 at 15:15, wrote: >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -,10 +,13 @@ static void svm_invlpga_intercept( >> >> static void svm_invlpg_intercept(unsigned long vaddr) >> { >> -struct vcpu *curr = current; >> HVMTRACE_LONG_2D(INVLPG, 0, TRC_PAR_LONG(vaddr)); >> -paging_invlpg(curr, vaddr); >> -svm_asid_g_invlpg(curr, vaddr); >> +paging_invlpg(current, vaddr); >> +} >> + >> +static void svm_invlpg(unsigned long vaddr) >> +{ >> +svm_asid_g_invlpg(current, vaddr); > Since paging_invlpg() already gets passed a struct vcpu *, having > it hand it to ->invlpg() would seem quite natural. Ok. > >> @@ -2432,10 +2432,14 @@ static void vmx_dr_access(unsigned long >> exit_qualification, >> >> static void vmx_invlpg_intercept(unsigned long vaddr) >> { >> -struct vcpu *curr = current; >> HVMTRACE_LONG_2D(INVLPG, /*invlpga=*/ 0, TRC_PAR_LONG(vaddr)); >> -if ( paging_invlpg(curr, vaddr) && cpu_has_vmx_vpid ) > So the previous dependency on paging_invlpg()'s return value gets > moved into that function (making the call here conditional). While > that's fine for VMX, SVM previously didn't pay attention to that > return value, and hence you're altering behavior in a way not > spelled out in the description (and to be honest I'm also not 100% > certain that change is correct). I thought I had included this in the commit message, but it appears it got lost. AMD is over-the-top with its TLB flushing generally, and will allocate a new ASID rather than shooting a single mapping out of the current ASID. The new svm_invlpg() should be a simple invlpga() call with the in-use ASID. However, the instruction emulator forwards invlpga to invlpg and loses the ASID, meaning that the only reason it functions is because this case over-flushes at the moment. I opted not to break that usecase. However, for the cases where paging_invlpg() returns 0, there is no need to allocate an ASID at all, as there are no mapping needing invalidation which could have been cached in the TLB. As such, this change is a performance improvement, albeit a minor one as the common case is dealt with directly in hardware without Xen's interaction. > >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -6478,6 +6478,19 @@ const unsigned long *__init >> get_platform_badpages(unsigned int *array_size) >> return bad_pages; >> } >> >> +bool_t paging_invlpg(struct vcpu *v, unsigned long va) >> +{ >> +bool_t invl = paging_mode_external(v->domain) >> +? is_canonical_address(va) : __addr_ok(va); >> + >> +if ( invl ) >> +invl = paging_get_hostmode(v)->invlpg(v, va); >> +if ( invl && is_hvm_domain(v->domain) ) > has_hvm_container_domain() (or paging_mode_external(), > implying the former)? I could have sworn I already fixed this... Will do for v2. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] libxl: don't add cache mode for qdisk cdrom drives
On Thu, Apr 28, 2016 at 03:20:46PM -0600, Jim Fehlig wrote: > qemu commit 91a097e7 forbids specifying cache mode for empty > drives. Attempting to create a domain with an empty qdisk cdrom > drive results in > > qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom, >cache=writeback,id=ide-832: Must specify either driver or file > We need to fix this one way or another. > libxl only allows an empty 'target=' for cdroms. By default, cdroms > are readonly (see the 'access' parameter in xl-disk-configuration.txt) > and forced to readonly by any tools (e.g. xl) using libxlutil's > xlu_disk_parse() function. With cdroms always marked readonly, > explicitly specifying the cache mode for cdrom drives can be dropped. > The drive's 'readonly=on' option can also be set unconditionally. > > Signed-off-by: Jim Fehlig CC Stefano who made the change to use writeback in e9a327bbbcab127625b0917a2780cb3601a81d01 . Also CC Anthony. Ian, Stefano and Anthony, do you have opinion on this patch? > --- > > V2: > Drop explicitly setting cache mode since cdrom devices are > readonly. > Unconditionally add 'readonly=on' drive option for cdroms. > > tools/libxl/libxl_dm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index fd12844..959e292 100644 > --- a/tools/libxl/libxl_dm.c > +++ b/tools/libxl/libxl_dm.c > @@ -1368,8 +1368,8 @@ static int libxl__build_device_model_args_new(libxl__gc > *gc, > > if (disks[i].is_cdrom) { > drive = libxl__sprintf(gc, > - > "if=ide,index=%d,readonly=%s,media=cdrom,cache=writeback,id=ide-%i", > - disk, disks[i].readwrite ? "off" : "on", > dev_number); > + "if=ide,index=%d,readonly=on,media=cdrom,id=ide-%i", > + disk, dev_number); > > if (target_path) > drive = libxl__sprintf(gc, "%s,file=%s,format=%s", > -- > 1.8.0.1 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 4/4] x86/hvm: Fix invalidation for emulated invlpg instructions
>>> On 09.05.16 at 15:15, wrote: > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -,10 +,13 @@ static void svm_invlpga_intercept( > > static void svm_invlpg_intercept(unsigned long vaddr) > { > -struct vcpu *curr = current; > HVMTRACE_LONG_2D(INVLPG, 0, TRC_PAR_LONG(vaddr)); > -paging_invlpg(curr, vaddr); > -svm_asid_g_invlpg(curr, vaddr); > +paging_invlpg(current, vaddr); > +} > + > +static void svm_invlpg(unsigned long vaddr) > +{ > +svm_asid_g_invlpg(current, vaddr); Since paging_invlpg() already gets passed a struct vcpu *, having it hand it to ->invlpg() would seem quite natural. > @@ -2432,10 +2432,14 @@ static void vmx_dr_access(unsigned long > exit_qualification, > > static void vmx_invlpg_intercept(unsigned long vaddr) > { > -struct vcpu *curr = current; > HVMTRACE_LONG_2D(INVLPG, /*invlpga=*/ 0, TRC_PAR_LONG(vaddr)); > -if ( paging_invlpg(curr, vaddr) && cpu_has_vmx_vpid ) So the previous dependency on paging_invlpg()'s return value gets moved into that function (making the call here conditional). While that's fine for VMX, SVM previously didn't pay attention to that return value, and hence you're altering behavior in a way not spelled out in the description (and to be honest I'm also not 100% certain that change is correct). > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -6478,6 +6478,19 @@ const unsigned long *__init > get_platform_badpages(unsigned int *array_size) > return bad_pages; > } > > +bool_t paging_invlpg(struct vcpu *v, unsigned long va) > +{ > +bool_t invl = paging_mode_external(v->domain) > +? is_canonical_address(va) : __addr_ok(va); > + > +if ( invl ) > +invl = paging_get_hostmode(v)->invlpg(v, va); > +if ( invl && is_hvm_domain(v->domain) ) has_hvm_container_domain() (or paging_mode_external(), implying the former)? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of invlpg with segments
> -Original Message- > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: 09 May 2016 14:16 > To: Xen-devel > Cc: Andrew Cooper; Jan Beulich; Paul Durrant; Wei Liu > Subject: [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of > invlpg with segments > > The `invlpg` instruction is documented to take a memory address, and is not > documented to suffer faults from segmentation violations. > > Experimentally, and subsequently confirmed by both Intel and AMD, the > instruction does take into account segment bases, but will happily invalidate > a TLB entry for a mapping beyond the segment limit. > > The emulation logic will currently raise #GP/#SS faults for segment limit > violations, or non-canonical addresses, which doesn't match hardware's > behaviour. Instead, squash exceptions generated by > hvmemul_virtual_to_linear() and proceed with invalidation. > > Signed-off-by: Andrew Cooper Reviewed-by: Paul Durrant > --- > CC: Jan Beulich > CC: Paul Durrant > CC: Wei Liu > --- > xen/arch/x86/hvm/emulate.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c > index ee5cf1f..e6316be 100644 > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -1608,7 +1608,22 @@ static int hvmemul_invlpg( > rc = hvmemul_virtual_to_linear( > seg, offset, 1, &reps, hvm_access_none, hvmemul_ctxt, &addr); > > -if ( rc == X86EMUL_OKAY ) > +if ( rc == X86EMUL_EXCEPTION ) > +{ > +/* > + * `invlpg` takes segment bases into account, but is not subject to > + * faults from segment type/limit checks, and is specified as a NOP > + * when issued on non-canonical addresses. > + * > + * hvmemul_virtual_to_linear() raises exceptions for type/limit > + * violations, so squash them. > + */ > +hvmemul_ctxt->exn_pending = 0; > +hvmemul_ctxt->trap = (struct hvm_trap){}; > +rc = X86EMUL_OKAY; > +} > + > +if ( rc == X86EMUL_OKAY && is_canonical_address(addr) ) > hvm_funcs.invlpg_intercept(addr); > > return rc; > -- > 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of invlpg with segments
On 09/05/16 14:42, Jan Beulich wrote: On 09.05.16 at 15:15, wrote: >> The `invlpg` instruction is documented to take a memory address, and is not >> documented to suffer faults from segmentation violations. >> >> Experimentally, and subsequently confirmed by both Intel and AMD, the >> instruction does take into account segment bases, but will happily invalidate >> a TLB entry for a mapping beyond the segment limit. > How about non-canonical addresses? If those don't #GP (which is > what I assume), is such an INVLPG a NOP They are explicitly documented by both Intel and AMD as being a NOP when passed a non-canonical address. Experimentation confirms this. (I am just putting the finishing touches on an XTF test for all of this). > , or does it invalidate > something (e.g. the translation for the address truncated to 48 > bits)? In that latter case we might need to also make our code > behave that way... > >> The emulation logic will currently raise #GP/#SS faults for segment limit >> violations, or non-canonical addresses, which doesn't match hardware's >> behaviour. Instead, squash exceptions generated by >> hvmemul_virtual_to_linear() and proceed with invalidation. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich > > albeit I think ... > >> --- a/xen/arch/x86/hvm/emulate.c >> +++ b/xen/arch/x86/hvm/emulate.c >> @@ -1608,7 +1608,22 @@ static int hvmemul_invlpg( >> rc = hvmemul_virtual_to_linear( >> seg, offset, 1, &reps, hvm_access_none, hvmemul_ctxt, &addr); >> >> -if ( rc == X86EMUL_OKAY ) >> +if ( rc == X86EMUL_EXCEPTION ) >> +{ >> +/* >> + * `invlpg` takes segment bases into account, but is not subject to >> + * faults from segment type/limit checks, and is specified as a NOP >> + * when issued on non-canonical addresses. >> + * >> + * hvmemul_virtual_to_linear() raises exceptions for type/limit >> + * violations, so squash them. >> + */ >> +hvmemul_ctxt->exn_pending = 0; >> +hvmemul_ctxt->trap = (struct hvm_trap){}; > ... this does more work than is really needed. For sanity sake, I would prefer not to leave stale information in the emulation context. This path is definitely not a hotpath. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 3/4] x86/hvm: Correct the emulated interaction of invlpg with segments
>>> On 09.05.16 at 15:15, wrote: > The `invlpg` instruction is documented to take a memory address, and is not > documented to suffer faults from segmentation violations. > > Experimentally, and subsequently confirmed by both Intel and AMD, the > instruction does take into account segment bases, but will happily invalidate > a TLB entry for a mapping beyond the segment limit. How about non-canonical addresses? If those don't #GP (which is what I assume), is such an INVLPG a NOP, or does it invalidate something (e.g. the translation for the address truncated to 48 bits)? In that latter case we might need to also make our code behave that way... > The emulation logic will currently raise #GP/#SS faults for segment limit > violations, or non-canonical addresses, which doesn't match hardware's > behaviour. Instead, squash exceptions generated by > hvmemul_virtual_to_linear() and proceed with invalidation. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich albeit I think ... > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -1608,7 +1608,22 @@ static int hvmemul_invlpg( > rc = hvmemul_virtual_to_linear( > seg, offset, 1, &reps, hvm_access_none, hvmemul_ctxt, &addr); > > -if ( rc == X86EMUL_OKAY ) > +if ( rc == X86EMUL_EXCEPTION ) > +{ > +/* > + * `invlpg` takes segment bases into account, but is not subject to > + * faults from segment type/limit checks, and is specified as a NOP > + * when issued on non-canonical addresses. > + * > + * hvmemul_virtual_to_linear() raises exceptions for type/limit > + * violations, so squash them. > + */ > +hvmemul_ctxt->exn_pending = 0; > +hvmemul_ctxt->trap = (struct hvm_trap){}; ... this does more work than is really needed. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 2/4] x86/hvm: Raise #SS faults for %ss-based segmentation violations
On 09/05/16 14:15, Andrew Cooper wrote: > Raising #GP under such circumstances is architecturally wrong. You should include a reference to the relevant Intel and AMD manuals here. David > --- > CC: Jan Beulich > CC: Tim Deegan > CC: Paul Durrant > CC: Wei Liu > --- > xen/arch/x86/hvm/emulate.c | 3 ++- > xen/arch/x86/mm/shadow/common.c | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c > index be1e7c2..ee5cf1f 100644 > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -566,7 +566,8 @@ static int hvmemul_virtual_to_linear( > > /* This is a singleton operation: fail it with an exception. */ > hvmemul_ctxt->exn_pending = 1; > -hvmemul_ctxt->trap.vector = TRAP_gp_fault; > +hvmemul_ctxt->trap.vector = > +(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault; > hvmemul_ctxt->trap.type = X86_EVENTTYPE_HW_EXCEPTION; > hvmemul_ctxt->trap.error_code = 0; > hvmemul_ctxt->trap.insn_len = 0; > diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c > index 559d4a4..226e32d 100644 > --- a/xen/arch/x86/mm/shadow/common.c > +++ b/xen/arch/x86/mm/shadow/common.c > @@ -148,7 +148,8 @@ static int hvm_translate_linear_addr( > > if ( !okay ) > { > -hvm_inject_hw_exception(TRAP_gp_fault, 0); > +hvm_inject_hw_exception( > +(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault, 0); > return X86EMUL_EXCEPTION; > } > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel