[Xen-devel] [qemu-mainline baseline-only test] 44397: regressions - FAIL

[Platform Team regression test user]

-libvirt-xsm pass
 test-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 <peter.mayd...@linaro.org>
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) <kra...@redhat.com>"
# gpg: aka "Gerd Hoffmann <g...@kraxel.org>"
# gpg: aka "Gerd Hoffmann (private) <kra...@gmail.com>"

* 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 <peter.mayd...@linaro.org>

commit fd3c136b3e1482cd0ec7285d6bc2a3e6a62c38d7
Author: Gerd Hoffmann <kra...@redhat.com>
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 t

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

[Juergen Gross]

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, ) 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

[Xu, Quan]

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

[Doug Goldstein]

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

[Chun Yan Liu]

>>> 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, ) 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

[Dario Faggioli]

[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, ) 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 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

[osstest service owner]

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

[Xen-devel] [ovmf test] 93918: regressions - FAIL

[osstest service owner]

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 

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

[Shannon Zhao]

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

[Jim Fehlig]

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

[osstest service owner]

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-xsm

Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes

[Jim Fehlig]

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

[osstest service owner]

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-pvops   

Re: [Xen-devel] [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

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

[osstest service owner]

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
 

Re: [Xen-devel] [PATCH v2 for-4.7 4/5] x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept()

[Boris Ostrovsky]

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

[Boris Ostrovsky]

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

Re: [Xen-devel] [PATCH for-qemu-trad] Fix build with newer version of GNUTLS

[Konrad Rzeszutek Wilk]

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(_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
> 

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Boris Ostrovsky]

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(_to_phys_mapping[mfn], )


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

[Andrew Cooper]

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()

[Andrew Cooper]

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

[Andrew Cooper]

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, , hvm_access_none, hvmemul_ctxt, );
 
-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

[Andrew Cooper]

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

[Andrew Cooper]

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,
 

[Xen-devel] [PATCH v2 for-4.7 4/5] x86/svm: Don't unconditionally use a new ASID in svm_invlpg_intercept()

[Andrew Cooper]

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

[Ivan Pavić2]

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: 

Re: [Xen-devel] dumping Xen stack

[Zytaruk, Kelly]

> -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

[Julien Grall]

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

[Lars Kurth]

> 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

[Wei Liu]

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

[Konrad Rzeszutek Wilk]

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, ) 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

[Kevin Moraga]

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

[Boris Ostrovsky]

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

[Meng Xu]

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, ) 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

[Andrew Cooper]

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

[Julien Grall]

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

[Zytaruk, Kelly]

> -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]

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]

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]

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

[Ivan Pavić2]

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

[Lars Kurth]

> 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

[Paul Durrant]

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

[Ivan Pavić2]

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

[Lars Kurth]

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, ) 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)

[Lars Kurth]

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

[Julien Grall]

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

[Paul Durrant]

> -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 == _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 == _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

[Paul Durrant]

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 == _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 == _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

[Paul Durrant]

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 == _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 == _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

[Paul Durrant]

> -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 == _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 == _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

[Kevin Moraga]

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

[Andrew Cooper]

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

[Paolo Bonzini]

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 == _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 == _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

[Zytaruk, Kelly]

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]

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

[Paul Durrant]

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 == _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 == _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

[Julien Grall]

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

[osstest service owner]

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 

[Xen-devel] Odgovor: ARM bare metal application test

[Ivan Pavić2]

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

[Jan Beulich]

>>> 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)

[Paul Durrant]

> -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 == _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 == _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

[George Dunlap]

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)

[Paul Durrant]

> -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 == _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 == _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)

[Paolo Bonzini]

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 == _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 == _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

[Julien Grall]

(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

[Jan Beulich]

>>> 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(>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

[George Dunlap]

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, ) 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)

[Paul Durrant]

> -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

[Jan Beulich]

>>> 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

[Konrad Rzeszutek Wilk]

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

[George Dunlap]

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

[Big Strong]

>
> 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, )) == 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

[Andrew Cooper]

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

[Lars Kurth]

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, ) 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

[osstest service owner]

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 

Re: [Xen-devel] Xen does not work after changing scheduler's code

[George Dunlap]

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

[Kevin Moraga]

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

[Wei Liu]

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

[Meng Xu]

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

[Lan, Tianyu]

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

[Dario Faggioli]

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 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

[George Dunlap]

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

[Juergen Gross]

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()

[George Dunlap]

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(>lock);
>  init_pdata(prv, pdata, cpu);
>  spin_unlock(>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(>lock);
> +ASSERT(!local_irq_is_enabled());
> +spin_lock(>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 = >rqd[rqi].lock;
>
> -spin_unlock_irq(>lock);
> +spin_unlock(>lock);
>  }
>
>  static void
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R 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

[Andrew Cooper]

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

[Meng Xu]

>
>
>
> > 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

[Andrew Cooper]

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

[Wei Liu]

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

[Jan Beulich]

>>> 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

[Paul Durrant]

> -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, , hvm_access_none, hvmemul_ctxt, );
> 
> -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

[Andrew Cooper]

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, , hvm_access_none, hvmemul_ctxt, );
>>  
>> -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

[Jan Beulich]

>>> 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, , hvm_access_none, hvmemul_ctxt, );
>  
> -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

[David Vrabel]

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

Re: [Xen-devel] [PATCH for-4.7 2/4] x86/hvm: Raise #SS faults for %ss-based segmentation violations

[Wei Liu]

CC George as well

On Mon, May 09, 2016 at 02:15:40PM +0100, Andrew Cooper wrote:
> Raising #GP under such circumstances is architecturally wrong.
> 
> Signed-off-by: Andrew Cooper 
> ---
> 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;
>  }
>  
> -- 
> 2.1.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/balloon: Fix declared-but-not-defined warning

[Juergen Gross]

On 09/05/16 15:29, Ross Lagerwall wrote:
> Fix a declared-but-not-defined warning when building with
> XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by
> commit dfd74a1edfab
> ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE").
> 
> Signed-off-by: Ross Lagerwall 
> ---
>  drivers/xen/balloon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index d46839f..0e57906 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -151,8 +151,6 @@ static DECLARE_WAIT_QUEUE_HEAD(balloon_wq);
>  static void balloon_process(struct work_struct *work);
>  static DECLARE_DELAYED_WORK(balloon_worker, balloon_process);
>  
> -static void release_memory_resource(struct resource *resource);
> -
>  /* When ballooning out (allocating memory to return to Xen) we don't really
> want the kernel to try too hard since that can trigger the oom killer. */
>  #define GFP_BALLOON \
> @@ -248,6 +246,8 @@ static enum bp_state update_schedule(enum bp_state state)
>  }
>  
>  #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
> +static void release_memory_resource(struct resource *resource);
> +

I'd rather move release_memory_resource() here instead of adding the
prototype.


Juergen

>  static struct resource *additional_memory_resource(phys_addr_t size)
>  {
>   struct resource *res;
> 


___
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

[Jan Beulich]

>>> On 09.05.16 at 15:15,  wrote:
> Raising #GP under such circumstances is architecturally wrong.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7 1/4] x86/hvm: Always return the linear address from hvm_virtual_to_linear_addr()

[Jan Beulich]

>>> On 09.05.16 at 15:15,  wrote:
> 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 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86: correct remaining extended CPUID level checks

[Wei Liu]

On Mon, May 09, 2016 at 07:19:56AM -0600, Jan Beulich wrote:
> We should consistently check the upper 16 bits to be equal 0x8000 and
> only then the full value to be >= the desired level.
> 
> Signed-off-by: Jan Beulich 
> ---
> As to inclusion in 4.7 - I think this would be desirable, but it's not
> a must: I'm unaware of real world environments where
> CPUID[0x8000].EAX would yield a value not having the upper 16 bits
> set to 0x8000.
> 

We're early in our RC so:

Release-acked-by: Wei Liu 

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86: cap address bits CPUID output

[Wei Liu]

On Mon, May 09, 2016 at 07:15:47AM -0600, Jan Beulich wrote:
> Don't use more or report more to guests than we are capable of
> handling.
> 
> At once
> - correct the involved extended CPUID level checks,
> - simplify the code in hvm_cpuid() and mtrr_top_of_ram().
> 
> Signed-off-by: Jan Beulich 

Release-acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel