Re: [Xen-devel] Big.LITTLE support (WAS Re: Xen ARM community call)

[Peng Fan]

Hi Julien,
On Tue, Nov 22, 2016 at 02:28:39PM +, Julien Grall wrote:
>Hello Anastassios,
>
>On 09/11/16 22:50, Anastassios Nanos wrote:
>>Hi Julien, all,
>>
>>>I would like to start organizing a recurring community call to discuss and
>>>sync-up on upcoming features for Xen ARM.
>>
>>great idea, I'd like to join too (GMT).
>>
>>>Example of features that could be discussed:
>>>- Sharing co-processor between guests
>>>- PCI passthrough
>>
>>Another issue to discuss, at some point, could be big.LITTLE support
>>(based on 
>>https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01802.html).
>
>Good point. Looking at the discussion, many ideas was suggested and I don't
>remember whether we all agreed on what to do. I would recommend to summarize
>the discussion in a mail so we can come up with an agreement.
>
>Peng, would you be up to do this?

Sorry for late reply. I am a bit busy on other things. I appreciate if you or 
anyone else
can help summarize the ideas. I may come to this big.little stuff at the 
beginning
of Dec.

Thanks,
Peng.

>
>Regards,
>
>-- 
>Julien Grall
>
>___
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>https://lists.xen.org/xen-devel

-- 

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

[Xen-devel] [libvirt test] 102550: regressions - FAIL

[osstest service owner]

flight 102550 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102550/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-pair 16 debian-fixup/dst_hostfail REGR. vs. 102503

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102503
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102503
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102503
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102503

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  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-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass

version targeted for testing:
 libvirt  29dc9a52d78b09cafbb3b2cd20f13d38fb258181
baseline version:
 libvirt  0b4c3bd30725a4d5f5fd40712b470a9de38b6835

Last test of basis   102503  2016-11-22 04:34:14 Z2 days
Testing same since   102550  2016-11-23 04:40:24 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Jiri Denemark 
  Marc Hartmayer 
  Michal Privoznik 
  Peter Krempa 
  Sławek Kapłoński 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair fail
 test-armhf-armhf-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 29dc9a52d78b09cafbb3b2cd20f13d38fb258181
Author: Jiri Denemark 
Date:   Tue Nov 22 19:26:45 2016 +0100

virsh: Document --rdma-pin-all migrate option properly

https://bugzilla.redhat.com/show_bug.cgi?id=1368351

Signed-off-by: Jiri Denemark 

[Xen-devel] [xen-4.5-testing test] 102543: regressions - FAIL

[osstest service owner]

flight 102543 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102543/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101275
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 102520 
REGR. vs. 101275

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt 14 guest-saverestore fail in 102520 pass in 102543
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail in 102520 
pass in 102543
 test-xtf-amd64-amd64-1 20 xtf/test-hvm32-invlpg~shadow fail pass in 102520
 test-xtf-amd64-amd64-1  29 xtf/test-hvm32pae-invlpg~shadow fail pass in 102520
 test-xtf-amd64-amd64-1 40 xtf/test-hvm64-invlpg~shadow fail pass in 102520
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail pass in 102520
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate  fail pass in 102520

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 102520 like 
101258
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail in 102520 like 101275
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 101275
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 101275
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101275
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101275

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1 18 xtf/test-hvm32-cpuid-faulting fail in 102520 never 
pass
 test-xtf-amd64-amd64-4 18 xtf/test-hvm32-cpuid-faulting fail in 102520 never 
pass
 test-xtf-amd64-amd64-1 27 xtf/test-hvm32pae-cpuid-faulting fail in 102520 
never pass
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pse-cpuid-faulting fail in 102520 
never pass
 test-xtf-amd64-amd64-1 37 xtf/test-hvm64-cpuid-faulting fail in 102520 never 
pass
 test-xtf-amd64-amd64-4 27 xtf/test-hvm32pae-cpuid-faulting fail in 102520 
never pass
 test-xtf-amd64-amd64-1 49 xtf/test-pv32pae-cpuid-faulting fail in 102520 never 
pass
 test-xtf-amd64-amd64-1 57 xtf/test-pv64-cpuid-faulting fail in 102520 never 
pass
 test-xtf-amd64-amd64-4 33 xtf/test-hvm32pse-cpuid-faulting fail in 102520 
never pass
 test-xtf-amd64-amd64-4 37 xtf/test-hvm64-cpuid-faulting fail in 102520 never 
pass
 test-xtf-amd64-amd64-4 49 xtf/test-pv32pae-cpuid-faulting fail in 102520 never 
pass
 test-xtf-amd64-amd64-4 57 xtf/test-pv64-cpuid-faulting fail in 102520 never 
pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 102520 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 102520 never pass
 test-xtf-amd64-amd64-3   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-xtf-amd64-amd64-3  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm64-cpuid-faulting fail  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-credit2  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-xtf-amd64-amd64-2  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-5  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   57 

Re: [Xen-devel] Xen virtual IOMMU high level design doc

[Lan Tianyu]

On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
 Hi,
 > > >
 > > > I have a few questions.
 > > >
 > > > If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
 > > > So guests will essentially create intel iommu style page-tables.
 > > >
 > > > If we were to use this on Xen/ARM, we would likely be modelling an 
 > > > ARM
 > > > SMMU as a vIOMMU. Since Xen on ARM does not use QEMU for emulation, 
 > > > the
 > > > hypervisor OPs for QEMUs xen dummy IOMMU queries would not really be 
 > > > used.
 > > > Do I understand this correctly?
>>> > > 
>>> > > I think they could be called from the toolstack. This is why I was
>>> > > saying in the other thread that the hypercalls should be general enough
>>> > > that QEMU is not the only caller.
>>> > > 
>>> > > For PVH and ARM guests, the toolstack should be able to setup the vIOMMU
>>> > > on behalf of the guest without QEMU intervention.
> OK, I see. Or, I think I understand, not sure :-)
> 
> In QEMU when someone changes mappings in an IOMMU there will be a notifier
> to tell caches upstream that mappings have changed. I think we will need to
> prepare for that. I.e when TCG CPUs sit behind an IOMMU.

For Xen side, we may notify pIOMMU driver about mapping change via
calling pIOMMU driver's API in vIOMMU.

> 
> Another area that may need change is that on ARM we need the map-query to 
> return
> the memory attributes for the given mapping. Today QEMU or any emulator 
> doesn't use it much but in the future things may change.
> 
> For SVM, whe will also need to deal with page-table faults by the IOMMU.
> So I think there will need to be a channel from Xen to Guesrt to report these.

Yes, vIOMMU should forward the page-fault event to guest. For VTD side,
we will trigger VTD's interrupt to notify guest about the event.

> 
> For example, what happens when a guest assigned DMA unit page-faults?
> Xen needs to know how to forward this fault back to guest for fixup and the
> guest needs to be able to fix it and tell the device that it's OK to contine.
> E.g PCI PRI or similar.
> 
> 


-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH 12/15] x86/hvm: Rename hvm_copy_*_guest_virt() to hvm_copy_*_guest_linear()

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 23, 2016 11:39 PM
> 
> The functions use linear addresses, not virtual addresses, as no segmentation
> is used.  (Lots of other code in Xen makes this mistake.)
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 23, 2016 11:39 PM
> 
> which is filled with pagefault information should one occur.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 23, 2016 11:39 PM
> 
> Intel VT-x and AMD SVM provide access to the full segment descriptor cache via
> fields in the VMCB/VMCS.  However, the bits which are actually checked by
> hardware and preserved across vmentry/exit are inconsistent, and the vendor
> accessor functions perform inconsistent modification to the raw values.
> 
> Convert {svm,vmx}_{get,set}_segment_register() into raw accessors, and alter
> hvm_{get,set}_segment_register() to cook the values consistently.  This allows
> the common emulation code to better rely on finding architecturally-expected
> values.
> 
> This does cause some functional changes because of the modifications being
> applied uniformly.  A side effect of this fixes latent bugs where
> vmx_set_segment_register() didn't correctly fix up .G for segments, and
> inconsistent fixing up of the GDTR/IDTR limits.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 07/15] x86/vmx: Use hvm_{get, set}_segment_register() rather than vmx_{get, set}_segment_register()

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 23, 2016 11:39 PM
> 
> No functional change at this point, but this is a prerequisite for forthcoming
> functional changes.
> 
> Make vmx_get_segment_register() private to vmx.c like all the other Vendor
> get/set functions.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> Reviewed-by: George Dunlap 
> ---
> CC: Jun Nakajima 
> CC: Kevin Tian 
> ---

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 23, 2016 11:39 PM
> 
> The emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.
> 
> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
> are visible to the emulator.  This removes the need for the
> inject_{hw,sw}_interrupt() hooks, which are dropped and replaced with
> x86_emul_{hw_exception,software_event}() instead.
> 
> The shadow pagetable and PV uses of x86_emulate() previously failed with
> X86EMUL_UNHANDLEABLE due to the lack of inject_*() hooks, but this behaviour
> has subtly changed.  Adjust the return value checking to cause a pending event
> to fall back into the previous codepath.
> 
> No overall functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 04/15] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 23, 2016 11:39 PM
> 
> and move it to live with the other x86_event infrastructure in x86_emulate.h.
> Switch it and x86_event.error_code to being signed, matching the rest of the
> code.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 23, 2016 11:39 PM
> 
> The x86 emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.  The naming choice is to match both the Intel and
> AMD terms, and to avoid 'trap' specifically as it has an architectural meaning
> different to its current usage.
> 
> While making this change, make other changes for consistency
> 
>  * Rename *_trap() infrastructure to *_event()
>  * Rename trapnr/trap parameters to vector
>  * Convert hvm_inject_hw_exception() and hvm_inject_page_fault() to being
>static inlines, as they are only thin wrappers around hvm_inject_event()
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 23, 2016 11:39 PM
> 
>  * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
>very closely related.
>  * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
>hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how to
>and when to use them.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

reviewed-by: Kevin Tian 

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

[Xen-devel] [ovmf test] 102546: all pass - PUSHED

[osstest service owner]

flight 102546 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102546/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0265811dbe56cf46fb3c152b2ccdefd8fb47a170
baseline version:
 ovmf 36e9e3e8ea0ce477504b6d2e21603ea94847efae

Last test of basis   102513  2016-11-22 11:43:31 Z1 days
Testing same since   102546  2016-11-23 02:23:46 Z1 days1 attempts


People who touched revisions under test:
  Dandan Bi 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=0265811dbe56cf46fb3c152b2ccdefd8fb47a170
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
0265811dbe56cf46fb3c152b2ccdefd8fb47a170
+ branch=ovmf
+ revision=0265811dbe56cf46fb3c152b2ccdefd8fb47a170
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x0265811dbe56cf46fb3c152b2ccdefd8fb47a170 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [xen-4.7-testing test] 102536: tolerable FAIL - PUSHED

[osstest service owner]

flight 102536 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102536/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail in 102518 pass in 
102536
 test-armhf-armhf-xl-xsm   5 xen-install  fail in 102518 pass in 102536
 test-armhf-armhf-xl-arndale   6 xen-boot fail in 102518 pass in 102536
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
102518 pass in 102536
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail in 102518 pass in 102536
 test-amd64-amd64-libvirt 11 guest-start  fail in 102518 pass in 102536
 test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail in 102518 pass in 
102536
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 102518 pass in 102536
 test-armhf-armhf-libvirt 15 guest-start/debian.repeat fail in 102518 pass in 
102536
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 102518 pass in 
102536
 test-armhf-armhf-xl-credit2  16 guest-start.2  fail pass in 102518

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101949
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101949
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101949
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101949
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101949
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101949
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101949

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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  206fc7084dfaf05c55fd9de650f93a7ef9fe0722
baseline version:
 xen  86f912c86501b9a3c1abf908731e7d86778a594e

Last test of basis   101949  2016-11-05 06:01:53 Z   18 days
Testing same since   102518  2016-11-22 13:41:48 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm

[Xen-devel] [xen-unstable baseline-only test] 68086: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68086 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68086/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   like 68067
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   like 68067
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   like 68067
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   like 68067
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   like 68067
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 68067
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68067
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68067
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68067
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68067

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun6 xen-buildfail   never pass
 build-amd64-rumprun   6 xen-buildfail   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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f678e2c78110e73431217306bbd33c736802d700
baseline version:
 xen  58bd0c7985890e0292212f94a56235228a3445c3

Last test of basis68067  2016-11-19 16:16:36 Z4 days
Testing same since68086  2016-11-23 16:16:48 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64   

Re: [Xen-devel] Xen virtual IOMMU high level design doc

[Edgar E. Iglesias]

On Thu, Nov 24, 2016 at 02:00:21AM +, Tian, Kevin wrote:
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: Thursday, November 24, 2016 3:09 AM
> > 
> > On Wed, 23 Nov 2016, Edgar E. Iglesias wrote:
> > > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote:
> > > > Hi All:
> > > >  The following is our Xen vIOMMU high level design for detail
> > > > discussion. Please have a look. Very appreciate for your comments.
> > > > This design doesn't cover changes when root port is moved to hypervisor.
> > > > We may design it later.
> > >
> > > Hi,
> > >
> > > I have a few questions.
> > >
> > > If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
> > > So guests will essentially create intel iommu style page-tables.
> > >
> > > If we were to use this on Xen/ARM, we would likely be modelling an ARM
> > > SMMU as a vIOMMU. Since Xen on ARM does not use QEMU for emulation, the
> > > hypervisor OPs for QEMUs xen dummy IOMMU queries would not really be used.
> > > Do I understand this correctly?
> > 
> > I think they could be called from the toolstack. This is why I was
> > saying in the other thread that the hypercalls should be general enough
> > that QEMU is not the only caller.
> > 
> > For PVH and ARM guests, the toolstack should be able to setup the vIOMMU
> > on behalf of the guest without QEMU intervention.

OK, I see. Or, I think I understand, not sure :-)

In QEMU when someone changes mappings in an IOMMU there will be a notifier
to tell caches upstream that mappings have changed. I think we will need to
prepare for that. I.e when TCG CPUs sit behind an IOMMU.

Another area that may need change is that on ARM we need the map-query to return
the memory attributes for the given mapping. Today QEMU or any emulator 
doesn't use it much but in the future things may change.

For SVM, whe will also need to deal with page-table faults by the IOMMU.
So I think there will need to be a channel from Xen to Guesrt to report these.

For example, what happens when a guest assigned DMA unit page-faults?
Xen needs to know how to forward this fault back to guest for fixup and the
guest needs to be able to fix it and tell the device that it's OK to contine.
E.g PCI PRI or similar.


> > > Has a platform agnostic PV-IOMMU been considered to support 2-stage
> > > translation (i.e VFIO in the guest)? Perhaps that would hurt map/unmap
> > > performance too much?
> > 
> > That's an interesting idea. I don't know if that's feasible, but if it
> > is not, then we need to be able to specify the PV-IOMMU type in the
> > hypercalls, so that you would get Intel IOMMU on x86 and SMMU on ARM.
> > 
> > 
> 
> Not considered yet. PV is always possible as we've done for other I/O
> devices. Ideally it could be designed being more efficient than full
> emulation of vendor specific IOMMU, but also means requirement of
> maintaining a new guest IOMMU driver and limitation of supporting
> only newer version guest OSes. It's a tradeoff... at least not compelling 
> now (may consider when we see a real need in the future).

Agreed. Thanks.

Best regards,
Edgar

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

[Xen-devel] [qemu-upstream-4.4-testing baseline-only test] 68087: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68087 qemu-upstream-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68087/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
66857

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail blocked in 
66857
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail blocked in 
66857
 test-amd64-amd64-pv  17 guest-localmigrate/x10   fail   like 66857
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10  fail like 66857

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass

version targeted for testing:
 qemuu5fadf00bf21ad3706f69b12877cd76aab4e17ecd
baseline version:
 qemuue72488cdcf2208f2df334fa88c35b33e695fa93b

Last test of basis66857  2016-07-29 04:46:53 Z  117 days
Testing same since68087  2016-11-23 17:16:10 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  fail
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   fail



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 5fadf00bf21ad3706f69b12877cd76aab4e17ecd
Author: Jan 

Re: [Xen-devel] Xen virtual IOMMU high level design doc V3

[Lan Tianyu]

On 2016年11月22日 18:24, Jan Beulich wrote:
 On 17.11.16 at 16:36,  wrote:
>> 2) Build ACPI DMAR table in toolstack
>> Now tool stack can boot ACPI DMAR table according VM configure and pass
>> though it to hvmloader via xenstore ACPI PT channel. But the vIOMMU MMIO
>> region is managed by Qemu and it's need to be populated into DMAR
>> table. We may hardcore an address in both Qemu and toolstack and use the 
>> same address to create vIOMMU and build DMAR table.
> 
> Let's try to avoid any new hard coding of values. Both tool stack
> and qemu ought to be able to retrieve a suitable address range
> from the hypervisor. Or if the tool stack was to allocate it, it could
> tell qemu.
> 
> Jan
> 

Hi Jan:
The address range is allocated by Qemu or toolstack and pass to
hypervisor when create vIOMMU. The vIOMMU's address range should be
under PCI address sapce and so we need to reserve a piece of PCI region
for vIOMMU in the toolstack. Then, populate base address in the vDMAR
table and tell Qemu the region via new xenstore interface if we want to
create vIOMMU in the Qemu dummy hypercall wrapper.

Another point, I am not sure whether we can create/destroy vIOMMU
directly in toolstack because virtual device models usually are handled
by Qemu. If yes, we don't need new Xenstore interface. In this case, the
dummy vIOMMU in Qemu will just cover L2 translation for virtual device.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc

[Tian, Kevin]

> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: Thursday, November 24, 2016 3:09 AM
> 
> On Wed, 23 Nov 2016, Edgar E. Iglesias wrote:
> > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote:
> > > Hi All:
> > >  The following is our Xen vIOMMU high level design for detail
> > > discussion. Please have a look. Very appreciate for your comments.
> > > This design doesn't cover changes when root port is moved to hypervisor.
> > > We may design it later.
> >
> > Hi,
> >
> > I have a few questions.
> >
> > If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
> > So guests will essentially create intel iommu style page-tables.
> >
> > If we were to use this on Xen/ARM, we would likely be modelling an ARM
> > SMMU as a vIOMMU. Since Xen on ARM does not use QEMU for emulation, the
> > hypervisor OPs for QEMUs xen dummy IOMMU queries would not really be used.
> > Do I understand this correctly?
> 
> I think they could be called from the toolstack. This is why I was
> saying in the other thread that the hypercalls should be general enough
> that QEMU is not the only caller.
> 
> For PVH and ARM guests, the toolstack should be able to setup the vIOMMU
> on behalf of the guest without QEMU intervention.
> 
> 
> > Has a platform agnostic PV-IOMMU been considered to support 2-stage
> > translation (i.e VFIO in the guest)? Perhaps that would hurt map/unmap
> > performance too much?
> 
> That's an interesting idea. I don't know if that's feasible, but if it
> is not, then we need to be able to specify the PV-IOMMU type in the
> hypercalls, so that you would get Intel IOMMU on x86 and SMMU on ARM.
> 
> 

Not considered yet. PV is always possible as we've done for other I/O
devices. Ideally it could be designed being more efficient than full
emulation of vendor specific IOMMU, but also means requirement of
maintaining a new guest IOMMU driver and limitation of supporting
only newer version guest OSes. It's a tradeoff... at least not compelling 
now (may consider when we see a real need in the future).

Thanks
Kevin

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

[Xen-devel] PATCH v3] Compile TianoCore under Fedora Core 25

[Konrad Rzeszutek Wilk]

Hey!

Changelog:
v3: It is perfect!
  - Redid commit per Jordan suggestion
  - Redid the failure scenario per Laszlo suggestion
  - Redid the testing

v2:
 - Redid it per Laszlo suggestion, added the URL to the bugzilla system
 - Tested it under more OSes

This patch allows me to compile TianoCore under Fedora Core 25.

I've also tested it (v2 and also this v3) under some more ancient distros, such 
as:

Ubuntu 16.04.1 (GCC 5.4.0), uses GCC5
Debian 8.6 (GCC 4.9.2), uses GCC49
Fedora Core 13 (GCC 4.4.4), uses GCC44
RHEL6 (GCC 4.4.7), uses GCC44

And on earlier versions, such as RHEL5:

[konrad@ol5 ovmf-dir]$ OvmfPkg/build.sh -a X64 -b RELEASE -n 4
Initializing workspace
/home/konrad/ovmf-dir/BaseTools
Loading previous configuration from /home/konrad/ovmf-dir/Conf/BuildEnv.sh
WORKSPACE: /home/konrad/ovmf-dir
EDK_TOOLS_PATH: /home/konrad/ovmf-dir/BaseTools
CONF_PATH: /home/konrad/ovmf-dir/Conf
OvmfPkg requires GCC4.4 or later

[konrad@ol5 ovmf-dir]$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54)

[Oddly enough the previous run (v2) - on an different RHEL5 guest - had
a different issue.]


Konrad Rzeszutek Wilk (1):
  OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

 OvmfPkg/build.sh | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)


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

[Xen-devel] [PATCH v3] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

[Konrad Rzeszutek Wilk]

v2:
 * Changes suggested by Laszlo:
   - change the catch-all (*) to GCC5, from GCC44
   - remove the (5.*.*) pattern from GCC49
   - generate error for GCC < 4.4

In v3, also generate error for really GCC < 4.4, like GCC 1.

Reviewed-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Konrad Rzeszutek Wilk 
---
v1: Initial
v2: Redo it per Laszlo suggestions
v3: Fix up commit message per Jordan
Also generate error for prehistoric versions of GCC, like 1.
---
 OvmfPkg/build.sh | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
index eb5eb73..95fe8fb 100755
--- a/OvmfPkg/build.sh
+++ b/OvmfPkg/build.sh
@@ -83,6 +83,13 @@ case `uname` in
   Linux*)
 gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
 case $gcc_version in
+  [1-3].*|4.[0-3].*)
+echo OvmfPkg requires GCC4.4 or later
+exit 1
+;;
+  4.4.*)
+TARGET_TOOLS=GCC44
+;;
   4.5.*)
 TARGET_TOOLS=GCC45
 ;;
@@ -95,11 +102,11 @@ case `uname` in
   4.8.*)
 TARGET_TOOLS=GCC48
 ;;
-  4.9.*|4.1[0-9].*|5.*.*)
+  4.9.*)
 TARGET_TOOLS=GCC49
 ;;
   *)
-TARGET_TOOLS=GCC44
+TARGET_TOOLS=GCC5
 ;;
 esac
 esac
-- 
2.9.3


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

[Xen-devel] [PATCH LIVEPATCH-BUILD-TOOLS] create-diff-object: Update fixup offsets in .rela.ex_table

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

When pruning entries from the fixup table, update the offsets in
.rela.ex_table otherwise the relas might point to the wrong fixup entry
or even out of the .fixup section.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
v2: Squashed fix from kpatch upstream
   [see https://github.com/dynup/kpatch/pull/616]
---
 create-diff-object.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/create-diff-object.c b/create-diff-object.c
index 69bcd88..58f7c4c 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1057,6 +1057,34 @@ static int should_keep_rela_group(struct section *sec, 
int start, int size)
return found;
 }
 
+/*
+ * When updating .fixup, the corresponding addends in .ex_table need to be
+ * updated too. Stash the result in rela.r_addend so that the calculation in
+ * fixup_group_size() is not affected.
+ */
+void kpatch_update_ex_table_addend(struct kpatch_elf *kelf,
+  struct special_section *special,
+  int src_offset, int dest_offset,
+  int group_size)
+{
+   struct rela *rela;
+   struct section *sec;
+
+   if (strcmp(special->name, ".fixup"))
+   return;
+
+   sec = find_section_by_name(>sections, ".rela.ex_table");
+   if (!sec)
+   ERROR("missing .rela.ex_table section");
+
+   list_for_each_entry(rela, >relas, list) {
+   if (!strcmp(rela->sym->name, ".fixup") &&
+   rela->addend >= src_offset &&
+   rela->addend < src_offset + group_size)
+   rela->rela.r_addend = rela->addend - (src_offset - 
dest_offset);
+   }
+}
+
 static void kpatch_regenerate_special_section(struct kpatch_elf *kelf,
  struct special_section *special,
  struct section *sec)
@@ -1073,6 +1101,14 @@ static void kpatch_regenerate_special_section(struct 
kpatch_elf *kelf,
if (!dest)
ERROR("malloc");
 
+   /* Restore the stashed r_addend from kpatch_update_ex_table_addend. */
+   if (!strcmp(special->name, ".ex_table")) {
+   list_for_each_entry(rela, >relas, list) {
+   if (!strcmp(rela->sym->name, ".fixup"))
+   rela->addend = rela->rela.r_addend;
+   }
+   }
+
group_size = 0;
src_offset = 0;
dest_offset = 0;
@@ -1100,6 +1136,11 @@ static void kpatch_regenerate_special_section(struct 
kpatch_elf *kelf,
rela->rela.r_offset = rela->offset;
 
rela->sym->include = 1;
+
+   kpatch_update_ex_table_addend(kelf, special,
+ src_offset,
+ dest_offset,
+ group_size);
}
}
 
-- 
2.9.3


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

Re: [Xen-devel] Problems with livepatching

[Konrad Rzeszutek Wilk]

On Thu, Nov 24, 2016 at 12:13:43AM +, M A Young wrote:
> On Wed, 23 Nov 2016, Andrew Cooper wrote:
> 
> > On 23/11/2016 23:06, M A Young wrote:
> > > I have been experimenting with live patching with the recent batch of 
> > > security updates on Fedora xen with very limited success. I had most 
> > > attempts with a test build of xen-4.8.0-rc6, and of the updates I have 
> > > tried only xsa192.patch uploads successfully. For example with 
> > > xsa191.patch the upload fails with the output
> > > Uploading /tmp/xen-debuginfo/out1/xsa191.livepatch (1561400 bytes)
> > > Upload failed: /tmp/xen-debuginfo/out1/xsa191.livepatch, error: 2(No such 
> > > file or directory)!
> > > and in xl dmesg a long debugging output ends with the line
> > > (XEN) livepatch_elf.c:295: livepatch: xsa191: Unknown symbol: .LC0
> > > with a similar line (mostly with .LC0 but with .LC3 in one case) for the 
> > > other failed attempts. Am I doing something wrong or is there a problem 
> > > with live patching in this case?
> > 
> > This looks like a problem generating the livepatch itself, not the
> > livepatching mechanism.
> > 
> > Make sure you are completely up to date with the livepatch tools
> > userspace.  There was one bug in livepatch generation which was
> > discovered due to XSA-191 and fixed (actually a preexisting bug even in
> > Linux), but its symptoms were innocuous until you patched, at which vcpu
> > context switch blew up.
> 
> Where is this latest version available from? I had checked the git repo on 
> xenbits 
> http://xenbits.xenproject.org/gitweb/?p=livepatch-build-tools.git;a=summary 
> but the last commit was 4 months ago.

Here is the patch that Ross has been working on - it is being first reviewed
for merge in the upstream version of kpatch. Hence hasn't been posted. But
posting it here.


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

[Xen-devel] [qemu-upstream-4.7-testing test] 102532: regressions - FAIL

[osstest service owner]

flight 102532 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102532/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
100711

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-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
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuue27a2f17bc2d9d7f8afce2c5918f4f23937b268e
baseline version:
 qemuue927b5f5a809f07b73b063831527c8a87f053933

Last test of basis   100711  2016-09-02 02:46:43 Z   82 days
Testing same since   102532  2016-11-22 20:11:32 Z1 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  

Re: [Xen-devel] Problems with livepatching

[M A Young]

On Wed, 23 Nov 2016, Andrew Cooper wrote:

> On 23/11/2016 23:06, M A Young wrote:
> > I have been experimenting with live patching with the recent batch of 
> > security updates on Fedora xen with very limited success. I had most 
> > attempts with a test build of xen-4.8.0-rc6, and of the updates I have 
> > tried only xsa192.patch uploads successfully. For example with 
> > xsa191.patch the upload fails with the output
> > Uploading /tmp/xen-debuginfo/out1/xsa191.livepatch (1561400 bytes)
> > Upload failed: /tmp/xen-debuginfo/out1/xsa191.livepatch, error: 2(No such 
> > file or directory)!
> > and in xl dmesg a long debugging output ends with the line
> > (XEN) livepatch_elf.c:295: livepatch: xsa191: Unknown symbol: .LC0
> > with a similar line (mostly with .LC0 but with .LC3 in one case) for the 
> > other failed attempts. Am I doing something wrong or is there a problem 
> > with live patching in this case?
> 
> This looks like a problem generating the livepatch itself, not the
> livepatching mechanism.
> 
> Make sure you are completely up to date with the livepatch tools
> userspace.  There was one bug in livepatch generation which was
> discovered due to XSA-191 and fixed (actually a preexisting bug even in
> Linux), but its symptoms were innocuous until you patched, at which vcpu
> context switch blew up.

Where is this latest version available from? I had checked the git repo on 
xenbits 
http://xenbits.xenproject.org/gitweb/?p=livepatch-build-tools.git;a=summary 
but the last commit was 4 months ago.

Michael Young

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

Re: [Xen-devel] Problems with livepatching

[Andrew Cooper]

On 23/11/2016 23:06, M A Young wrote:
> I have been experimenting with live patching with the recent batch of 
> security updates on Fedora xen with very limited success. I had most 
> attempts with a test build of xen-4.8.0-rc6, and of the updates I have 
> tried only xsa192.patch uploads successfully. For example with 
> xsa191.patch the upload fails with the output
> Uploading /tmp/xen-debuginfo/out1/xsa191.livepatch (1561400 bytes)
> Upload failed: /tmp/xen-debuginfo/out1/xsa191.livepatch, error: 2(No such 
> file or directory)!
> and in xl dmesg a long debugging output ends with the line
> (XEN) livepatch_elf.c:295: livepatch: xsa191: Unknown symbol: .LC0
> with a similar line (mostly with .LC0 but with .LC3 in one case) for the 
> other failed attempts. Am I doing something wrong or is there a problem 
> with live patching in this case?

This looks like a problem generating the livepatch itself, not the
livepatching mechanism.

Make sure you are completely up to date with the livepatch tools
userspace.  There was one bug in livepatch generation which was
discovered due to XSA-191 and fixed (actually a preexisting bug even in
Linux), but its symptoms were innocuous until you patched, at which vcpu
context switch blew up.

With that one bug fixed, I can confirm that all of the recent XSAs are
properly livepatchable with the available tools, and confirmed to work.

~Andrew

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

[Xen-devel] Problems with livepatching

[M A Young]

I have been experimenting with live patching with the recent batch of 
security updates on Fedora xen with very limited success. I had most 
attempts with a test build of xen-4.8.0-rc6, and of the updates I have 
tried only xsa192.patch uploads successfully. For example with 
xsa191.patch the upload fails with the output
Uploading /tmp/xen-debuginfo/out1/xsa191.livepatch (1561400 bytes)
Upload failed: /tmp/xen-debuginfo/out1/xsa191.livepatch, error: 2(No such 
file or directory)!
and in xl dmesg a long debugging output ends with the line
(XEN) livepatch_elf.c:295: livepatch: xsa191: Unknown symbol: .LC0
with a similar line (mostly with .LC0 but with .LC3 in one case) for the 
other failed attempts. Am I doing something wrong or is there a problem 
with live patching in this case?

Michael Young

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

[Xen-devel] [qemu-upstream-unstable test] 102534: tolerable FAIL - PUSHED

[osstest service owner]

flight 102534 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102534/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101634
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101642
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101642
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101642
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101642
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101642

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu53307d7a9c749237386eb2ccaa709c786cb5f8a5
baseline version:
 qemuu6cfcdf037edadba984ccf8476b5d1e2a0940b789

Last test of basis   101642  2016-10-24 06:52:42 Z   30 days
Testing same since   102534  2016-11-22 20:11:17 Z1 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm 

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

[Olaf Hering]

Am 23. November 2016 21:44:50 MEZ, schrieb Olaf Hering :

>Is this a can for 2.x?
 candidate 


Olaf 


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

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

[Laszlo Ersek]

On 11/23/16 16:01, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 23, 2016 at 03:55:11PM +0100, Laszlo Ersek wrote:
>> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote:
>>> From Laszlo:
>>> " change the catch-all (*) to GCC5, from GCC44
>>> - remove the (5.*.*) pattern from GCC49
>>> - add a branch (with multiple patterns if necessary) for gcc-4.3 and
>>>   earlier to exit with an error message / failure (those compiler
>>>   versions are unsupported)"
>>>
>>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Konrad Rzeszutek Wilk 
>>> ---
>>> v1: First submission
>>> v2: Redo it per Laszlo suggestion.
>>>
>>>  OvmfPkg/build.sh | 11 +--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
>>> index eb5eb73..cab7c70 100755
>>> --- a/OvmfPkg/build.sh
>>> +++ b/OvmfPkg/build.sh
>>> @@ -83,6 +83,13 @@ case `uname` in
>>>Linux*)
>>>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>>>  case $gcc_version in
>>> +  4.1.[0-0].*|4.2.*|4.3.*)
>>
>> * The [0-0] bracketed expression will work as expected, but it's
>> somewhat unusual :) Is it intentional?
>>
>> * If it's a typo, are you okay if I replace it with a plain 0 on commit?
> 
> It is a typo! It was 0-9 but I forgot to type 'git commit --amend'. Argh!
> 
> Are you OK doing:
> 
>  s/[0-0]/[0-9]/
> 
> when you commit or would you prefer I repost this with this in _and_ with
> your Reviewed-by?

I highly appreciate that you are willing to repost :) So yes, I'd like
to request you do that.

However, since you are willing to repost :), I also ask that you to
reformat the commit message as suggested by Jordan:

  https://lists.01.org/pipermail/edk2-devel/2016-November/005087.html

and to update the line that you are about to modify anyway, to:

  [1-3].*|4.[0-3].*)

  https://lists.01.org/pipermail/edk2-devel/2016-November/005129.html

If you agree, of course. (I'm not trying to be an annoyance on purpose.)

Thank you for working on this!
Laszlo

> 
>>
>> * Also, IIRC, Olaf considered pre-4.0 gcc releases as well (rejecting
>> them of course), which is sort of meant as part of "gcc-4.3 and
>> earlier". But, given your extensive testing with old distros (thanks for
> 
> Oh gosh.
>> that!), I think it's safe to ignore pre-4.0 gcc releases altogether.
> 
> Yes :-)
>>
>> Reviewed-by: Laszlo Ersek 
>>
>> Thanks!
>> Laszlo
>>
>>> +echo OvmfPkg requires GCC4.4 or later
>>> +exit 1
>>> +;;
>>> +  4.4.*)
>>> +TARGET_TOOLS=GCC44
>>> +;;
>>>4.5.*)
>>>  TARGET_TOOLS=GCC45
>>>  ;;
>>> @@ -95,11 +102,11 @@ case `uname` in
>>>4.8.*)
>>>  TARGET_TOOLS=GCC48
>>>  ;;
>>> -  4.9.*|4.1[0-9].*|5.*.*)
>>> +  4.9.*)
>>>  TARGET_TOOLS=GCC49
>>>  ;;
>>>*)
>>> -TARGET_TOOLS=GCC44
>>> +TARGET_TOOLS=GCC5
>>>  ;;
>>>  esac
>>>  esac
>>>
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel


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

[Xen-devel] [qemu-upstream-4.5-testing test] 102533: regressions - FAIL

[osstest service owner]

flight 102533 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102533/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd   6 xen-boot  fail REGR. vs. 99725
 test-armhf-armhf-libvirt 13 saverestore-support-check fail REGR. vs. 99725

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 99725
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 99725
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 99725
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 99725

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  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-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass

version targeted for testing:
 qemuu37a460ca696381bb14dfbf012d7a062c7c05c324
baseline version:
 qemuu835c204f1196ab8f5213a9dc5299ed76e748cdca

Last test of basis99725  2016-07-27 18:10:31 Z  119 days
Testing same since   102533  2016-11-22 20:11:10 Z1 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 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-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-armhf-armhf-xl-arndale  pass
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-amd64-xl-pvh-intelfail   

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

[Olaf Hering]

Am 23. November 2016 13:27:13 MEZ, schrieb Kevin Wolf :
>Am 23.11.2016 um 12:40 hat Eric Blake geschrieben:

>> Qualifies as a bug fix, so requesting 2.8 inclusion.
>> Reviewed-by: Eric Blake 

Is this a can for 2.x?

Olaf 


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

[Xen-devel] [xen-unstable-smoke test] 102576: tolerable all pass - PUSHED

[osstest service owner]

flight 102576 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102576/

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  7b5266abfdf7f842c49ce4a52d250e523bc0172d
baseline version:
 xen  e5745b86e6e114f0e5b15bf67ed8d37a3d019f66

Last test of basis   102568  2016-11-23 14:20:53 Z0 days
Testing same since   102576  2016-11-23 18:03:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monne 
  Roger Pau Monné 
  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=7b5266abfdf7f842c49ce4a52d250e523bc0172d
+ . ./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 
7b5266abfdf7f842c49ce4a52d250e523bc0172d
+ branch=xen-unstable-smoke
+ revision=7b5266abfdf7f842c49ce4a52d250e523bc0172d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x7b5266abfdf7f842c49ce4a52d250e523bc0172d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git

Re: [Xen-devel] xenbits.xen.org gitweb summaries advertise https version, but that url leads to a blank page.

[Sander Eikelenboom]

On 23/11/16 21:26, Julien Grall wrote:



On 23/11/16 20:10, Sander Eikelenboom wrote:

Hi Sander,


The summaries [1] on the xenbits.xen.org gitweb advertise that it should
be reachable with http, git and https urls, however the https url [2]
leads to a blank page.
Is that expected (I can imagine it was switched off to lower serverload,
however I wouldn't expect it to be advertised in that case.


The http url also leads to a blank page. They are URL to be used for
cloning the git, not browsing it.



Ah thanks you are completely right, my stupid user error.
Sorry for the noise !




Regards,


--
Sander


[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
[2] https://xenbits.xen.org/git-http/xen.git

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





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

Re: [Xen-devel] xenbits.xen.org gitweb summaries advertise https version, but that url leads to a blank page.

[Julien Grall]

On 23/11/16 20:10, Sander Eikelenboom wrote:

Hi Sander,


The summaries [1] on the xenbits.xen.org gitweb advertise that it should
be reachable with http, git and https urls, however the https url [2]
leads to a blank page.
Is that expected (I can imagine it was switched off to lower serverload,
however I wouldn't expect it to be advertised in that case.


The http url also leads to a blank page. They are URL to be used for 
cloning the git, not browsing it.


Regards,


--
Sander


[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
[2] https://xenbits.xen.org/git-http/xen.git

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


--
Julien Grall

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

[Xen-devel] xenbits.xen.org gitweb summaries advertise https version, but that url leads to a blank page.

[Sander Eikelenboom]

Hi Lars,

The summaries [1] on the xenbits.xen.org gitweb advertise that it should 
be reachable with http, git and https urls, however the https url [2] 
leads to a blank page.
Is that expected (I can imagine it was switched off to lower serverload, 
however I wouldn't expect it to be advertised in that case.


--
Sander


[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
[2] https://xenbits.xen.org/git-http/xen.git

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

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

[Andrew Cooper]

On 23/11/16 19:41, Boris Ostrovsky wrote:
> On 11/23/2016 02:28 PM, Andrew Cooper wrote:
>>> SVM requires attributes of any NULL segment to be zero.
>> Where is this claim made?  Vol2 recommends that the VMM clear all
>> attributes, but the wording of the previous paragraph suggests that the
>> attributes would be ignored in this case.   The %ss bug, and some
>> experimentation on my behalf also indicate that they are ignored.
> 15.5.1 Basic Operation, Segment State in the VMCB:
>
> The VMM should follow these rules when storing segment attributes into
> the VMCB
> * For NULL segments, set all attribute bits to zero; otherwise, write
> the concatenation of bits 55:52 and 47:40 from the original 64-bit
> (in-memory) segment descriptors.
>
> I guess the preceding text is indeed unclear as to whether this is
> somehow enforced (in which case I am not sure I see the point of having
> this rule).

The quality if information in this regard is very poor.  Both Intel and
AMD expose the segment cache to hypervisors, without actually
documenting the behaviour and expectations.  I spent several weeks
during the development of XSA-191 trying to divide what actually
happens, especially in terms of what a guest can do to the segment cache
without suffering a VMEXIT.

One point I deliberately didn't highlight at the time in c/s 12bc22f791
is that such an emulated instruction, on AMD, discards the non-canonical
part of the base, and happily runs with a truncated address implicitly
sign extended.  If you happen to look back through my submissions, you
will find quite a few patches drip-feeding segmentation fixes and
improvements.  c/s ed00f17616 was another curious issue to stumble across.

~Andrew

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Stefano Stabellini]

On Tue, 22 Nov 2016, Julien Grall wrote:
> On 22/11/16 19:06, Stefano Stabellini wrote:
> > On Mon, 21 Nov 2016, Julien Grall wrote:
> > > On 21/11/2016 21:13, Edgar E. Iglesias wrote:
> > > > On Mon, Nov 21, 2016 at 01:01:15PM -0800, Stefano Stabellini wrote:
> > > > > On Mon, 21 Nov 2016, Edgar E. Iglesias wrote:
> > > > > > On Fri, Nov 18, 2016 at 10:58:42AM -0800, Stefano Stabellini wrote:
> > > > > > > On Thu, 17 Nov 2016, Julien Grall wrote:
> > > > > > > > Hi Stefano,
> > > > > > > > 
> > > > > > > > On 17/11/2016 11:26, Stefano Stabellini wrote:
> > > > > > > > > On Mon, 14 Nov 2016, Julien Grall wrote:
> > > > > > > > > > On 11/11/2016 13:55, Stefano Stabellini wrote:
> > > > > > > > > > > On Fri, 11 Nov 2016, Julien Grall wrote:
> > > > > > > > > > > > On 11/11/2016 02:24, Stefano Stabellini wrote:
> > > > > > > > > > > > > On Thu, 10 Nov 2016, Julien Grall wrote:
> > > > > > > > > > > > > > (CC Stefano and change the title)
> > > > > > > > > > > > > > On 10/11/16 12:13, casionwoo wrote:
> > > > > > > > > > > > > > > I’m pleased about your reply and you have a lot of
> > > > > > > > > > > > > > > code to
> > > > > > > > > > > > > > > clean-up.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > As you mentioned, It’s really huge to digest at
> > > > > > > > > > > > > > > once.
> > > > > > > > > > > > > > > Thank you
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > understanding me.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > And that’s why i need a small fix up and todo
> > > > > > > > > > > > > > > list.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I feel familiar with ARM and c language and
> > > > > > > > > > > > > > > there’s no
> > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > area
> > > > > > > > > > > > > > > yet.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I think that i can find interesting area with
> > > > > > > > > > > > > > > following up the
> > > > > > > > > > > > > > > codes.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I’m looking forward to being stuck on Xen.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Then it would be easier for me to understand about
> > > > > > > > > > > > > > > Xen
> > > > > > > > > > > > > > > on ARM.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Please let me know the TODO and bug-fix lists.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Stefano, before giving a list of code clean-up, do
> > > > > > > > > > > > > > you
> > > > > > > > > > > > > > have any
> > > > > > > > > > > > > > small
> > > > > > > > > > > > > > TODO
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > ARM in mind?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > A simple task we talked about recently is to enable
> > > > > > > > > > > > > the
> > > > > > > > > > > > > vuart
> > > > > > > > > > > > > (xen/arch/arm/vuart.c) for all guests. At the moment
> > > > > > > > > > > > > it is
> > > > > > > > > > > > > only
> > > > > > > > > > > > > emulated
> > > > > > > > > > > > > for Dom0, but some guests, in particular BareMetal
> > > > > > > > > > > > > guests
> > > > > > > > > > > > > (https://en.wikipedia.org/wiki/BareMetal), would
> > > > > > > > > > > > > benefit
> > > > > > > > > > > > > from it.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > It would be best to introduce an option in libxl to
> > > > > > > > > > > > > explicitly
> > > > > > > > > > > > > enable/disable the vuart for DomUs. Something like
> > > > > > > > > > > > > vuart=1
> > > > > > > > > > > > > in the VM
> > > > > > > > > > > > > config file.
> > > > > > > > > > > > 
> > > > > > > > > > > > The vuart has not been enabled for DomU because it the
> > > > > > > > > > > > UART
> > > > > > > > > > > > region may
> > > > > > > > > > > > clash
> > > > > > > > > > > > with the guest memory layout (which is static).
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't think this option should be available until we
> > > > > > > > > > > > allow
> > > > > > > > > > > > the guest
> > > > > > > > > > > > to
> > > > > > > > > > > > use
> > > > > > > > > > > > the same memory layout as the host (see e820_host
> > > > > > > > > > > > parameter
> > > > > > > > > > > > for x86).
> > > > > > > > > > > 
> > > > > > > > > > > Actually there is no reason for the vuart to use the same
> > > > > > > > > > > address as
> > > > > > > > > > > the physical uart on the platform, is there?
> > > > > > > > > > > In fact it doesn't even
> > > > > > > > > > > have to prentend to be the same uart as the one on the
> > > > > > > > > > > board,
> > > > > > > > > > > right?
> > > > > > > > > > > The vuart MMIO address could be completely configurable
> > > > > > > > > > > and
> > > > > > > > > > > independent
> > > > > > > > > > > from the one of the physical uart.
> > > > > > > > > > 
> > > > > > > > > > There is no reason to use the same information as the
> > > > > > > > > > 

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

[Boris Ostrovsky]

On 11/23/2016 02:28 PM, Andrew Cooper wrote:
>
>> SVM requires attributes of any NULL segment to be zero.
> Where is this claim made?  Vol2 recommends that the VMM clear all
> attributes, but the wording of the previous paragraph suggests that the
> attributes would be ignored in this case.   The %ss bug, and some
> experimentation on my behalf also indicate that they are ignored.

15.5.1 Basic Operation, Segment State in the VMCB:

The VMM should follow these rules when storing segment attributes into
the VMCB
* For NULL segments, set all attribute bits to zero; otherwise, write
the concatenation of bits 55:52 and 47:40 from the original 64-bit
(in-memory) segment descriptors.

I guess the preceding text is indeed unclear as to whether this is
somehow enforced (in which case I am not sure I see the point of having
this rule).

-boris

>
>> I don't know about Intel but if it's the same then should we ASSERT this as 
>> well?
> On Intel if unusable is set, all other bits are ignored.
>
> However, the behaviour of both Intel and AMD is to occasionally set
> upper attribute bits.  At some point I intend to make emulated segment
> loading match d->arch.vendor's behaviour, at which point such an
> ASSERT() would definitely trip.
>
> ~Andrew



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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

[Andrew Cooper]

On 23/11/16 19:28, Julien Grall wrote:
>
>
> On 23/11/16 15:47, Andrii Anisov wrote:
>> Hello Julien,
>
> Hi Andrii,
>
>>> The ACPI support is pretty much contained in a single file and I am
>>> not sure you will win much space.
>>> Can you explain why the ACPI guest support should be optional?
>> This would increase the system configurability and would let one
>> shrink a system to a minimal footprint with required functionality
>> only. Such possibility is very useful in embedded applications.
>>
>> Unfortunately I don't know the exact space impact of this particular
>> feature 'cause I can't build it. From other hand I do not need it in
>> my system. So I would like to have a way to drop not needed
>> functionality easily.
>
> I agree with this argument however...
>
>> BTW, excessive functionality reduction is also a way to get more
>> stable and predictable system.
>
> this statement is not entirely true. There is no automatic test on all
> the possible configurations, although we have travis to test build
> (and not booting) a random Kconfig. Even if we try our best to see any
> problem when reviewing code, we cannot guarantee an error when using a
> different configuration.
>
> And this is becoming a problem as today we have no way to know the
> configuration used when a problem is reported. This is because the
> Kconfig is not embedded in the Xen binary.
>
> I got bitten quite a few times in my development because I had a
> binary but not the Kconfig. It was re-written because I forgot to add
> XEN_CONFIG_EXPERT on the command line.
>
> I might be more inclined to make more feature optional when we will
> have a way to track the configuration of a hypervisor binary.

+10 to this idea.

It isn't hard to compress .config and stash it in .rodata during
compilation, offering it back to the toolstack via a hypercall.  We
already do similar things for the XSM policy.

~Andrew

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

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

[Andrew Cooper]

On 23/11/16 19:01, Boris Ostrovsky wrote:
> On 11/23/2016 10:38 AM, Andrew Cooper wrote:
>> Intel VT-x and AMD SVM provide access to the full segment descriptor cache 
>> via
>> fields in the VMCB/VMCS.  However, the bits which are actually checked by
>> hardware and preserved across vmentry/exit are inconsistent, and the vendor
>> accessor functions perform inconsistent modification to the raw values.
>>
>> Convert {svm,vmx}_{get,set}_segment_register() into raw accessors, and alter
>> hvm_{get,set}_segment_register() to cook the values consistently.  This 
>> allows
>> the common emulation code to better rely on finding architecturally-expected
>> values.
>>
>> This does cause some functional changes because of the modifications being
>> applied uniformly.  A side effect of this fixes latent bugs where
>> vmx_set_segment_register() didn't correctly fix up .G for segments, and
>> inconsistent fixing up of the GDTR/IDTR limits.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Jun Nakajima 
>> CC: Kevin Tian 
>> CC: Boris Ostrovsky 
>> CC: Suravee Suthikulpanit 
>> ---
>>  xen/arch/x86/hvm/hvm.c| 151 
>> ++
>>  xen/arch/x86/hvm/svm/svm.c|  20 +-
>>  xen/arch/x86/hvm/vmx/vmx.c|   6 +-
>>  xen/include/asm-x86/desc.h|   6 ++
>>  xen/include/asm-x86/hvm/hvm.h |  17 ++---
>>  5 files changed, 164 insertions(+), 36 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index ef83100..804cd88 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -6051,6 +6051,157 @@ void hvm_domain_soft_reset(struct domain *d)
>>  }
>>  
>>  /*
>> + * Segment caches in VMCB/VMCS are inconsistent about which bits are 
>> checked,
>> + * important, and preserved across vmentry/exit.  Cook the values to make 
>> them
>> + * closer to what is architecturally expected from entries in the segment
>> + * cache.
>> + */
>> +void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
>> +  struct segment_register *reg)
>> +{
>> +hvm_funcs.get_segment_register(v, seg, reg);
>> +
>> +switch ( seg )
>> +{
>> +case x86_seg_ss:
>> +/* SVM may retain %ss.DB when %ss is loaded with a NULL selector. */
>> +if ( !reg->attr.fields.p )
>> +reg->attr.fields.db = 0;
> Removed SVM code relied on type being zero to indicate a NULL segment.
> Looking at P bit is the correct way and I think it's worth mentioning
> this in the commit message.

Oh yes.  As far as I can tell, that was simply broken before.

>
>
>> +}
>> +
>> +void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
>> +  struct segment_register *reg)
>> +{
>> +/* Set G to match the limit field.  VT-x cares, while SVM doesn't. */
>> +if ( reg->attr.fields.p )
>> +reg->attr.fields.g = !!(reg->limit >> 20);
>> +
>> +switch ( seg )
>> +{
>> +case x86_seg_cs:
>> +ASSERT(reg->attr.fields.p);  /* Usable. */
>> +ASSERT(reg->attr.fields.s);  /* User segment. */
>> +ASSERT((reg->base >> 32) == 0);  /* Upper bits clear. */
>> +break;
>> +
>> +case x86_seg_ss:
>> +if ( reg->attr.fields.p )
>> +{
>> +ASSERT(reg->attr.fields.s);  /* User segment. */
>> +ASSERT(!(reg->attr.fields.type & 0x8));  /* Data segment. */
>> +ASSERT(reg->attr.fields.type & 0x2); /* Writeable. */
>> +ASSERT((reg->base >> 32) == 0);  /* Upper bits clear. */
>> +}
>> +break;
> SVM requires attributes of any NULL segment to be zero.

Where is this claim made?  Vol2 recommends that the VMM clear all
attributes, but the wording of the previous paragraph suggests that the
attributes would be ignored in this case.   The %ss bug, and some
experimentation on my behalf also indicate that they are ignored.

> I don't know about Intel but if it's the same then should we ASSERT this as 
> well?

On Intel if unusable is set, all other bits are ignored.

However, the behaviour of both Intel and AMD is to occasionally set
upper attribute bits.  At some point I intend to make emulated segment
loading match d->arch.vendor's behaviour, at which point such an
ASSERT() would definitely trip.

~Andrew

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

Re: [Xen-devel] [PATCH v1] libxl: Make an ACPI support build for ARM64 configurable.

[Julien Grall]

On 23/11/16 15:47, Andrii Anisov wrote:

Hello Julien,


Hi Andrii,


The ACPI support is pretty much contained in a single file and I am not sure 
you will win much space.
Can you explain why the ACPI guest support should be optional?

This would increase the system configurability and would let one
shrink a system to a minimal footprint with required functionality
only. Such possibility is very useful in embedded applications.

Unfortunately I don't know the exact space impact of this particular
feature 'cause I can't build it. From other hand I do not need it in
my system. So I would like to have a way to drop not needed
functionality easily.


I agree with this argument however...


BTW, excessive functionality reduction is also a way to get more
stable and predictable system.


this statement is not entirely true. There is no automatic test on all 
the possible configurations, although we have travis to test build (and 
not booting) a random Kconfig. Even if we try our best to see any 
problem when reviewing code, we cannot guarantee an error when using a 
different configuration.


And this is becoming a problem as today we have no way to know the 
configuration used when a problem is reported. This is because the 
Kconfig is not embedded in the Xen binary.


I got bitten quite a few times in my development because I had a binary 
but not the Kconfig. It was re-written because I forgot to add 
XEN_CONFIG_EXPERT on the command line.


I might be more inclined to make more feature optional when we will have 
a way to track the configuration of a hypervisor binary.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC] Shared coprocessor framework

[Andrii Anisov]

> I was thinking of something trivial but enough to prove the point.
It is already implemented in a hack'n'slash way.
So we are pretty confident in the approach and looking forward to make
generic and scalable implementation.
And upstreamable, of course.

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc

[Stefano Stabellini]

On Wed, 23 Nov 2016, Edgar E. Iglesias wrote:
> On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote:
> > Hi All:
> >  The following is our Xen vIOMMU high level design for detail
> > discussion. Please have a look. Very appreciate for your comments.
> > This design doesn't cover changes when root port is moved to hypervisor.
> > We may design it later.
> 
> Hi,
> 
> I have a few questions.
> 
> If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
> So guests will essentially create intel iommu style page-tables.
> 
> If we were to use this on Xen/ARM, we would likely be modelling an ARM
> SMMU as a vIOMMU. Since Xen on ARM does not use QEMU for emulation, the
> hypervisor OPs for QEMUs xen dummy IOMMU queries would not really be used.
> Do I understand this correctly?

I think they could be called from the toolstack. This is why I was
saying in the other thread that the hypercalls should be general enough
that QEMU is not the only caller.

For PVH and ARM guests, the toolstack should be able to setup the vIOMMU
on behalf of the guest without QEMU intervention.


> Has a platform agnostic PV-IOMMU been considered to support 2-stage
> translation (i.e VFIO in the guest)? Perhaps that would hurt map/unmap
> performance too much?
 
That's an interesting idea. I don't know if that's feasible, but if it
is not, then we need to be able to specify the PV-IOMMU type in the
hypercalls, so that you would get Intel IOMMU on x86 and SMMU on ARM.


> > 
> > 
> > Content:
> > ===
> > 1. Motivation of vIOMMU
> > 1.1 Enable more than 255 vcpus
> > 1.2 Support VFIO-based user space driver
> > 1.3 Support guest Shared Virtual Memory (SVM)
> > 2. Xen vIOMMU Architecture
> > 2.1 2th level translation overview
> > 2.2 Interrupt remapping overview
> > 3. Xen hypervisor
> > 3.1 New vIOMMU hypercall interface
> > 3.2 2nd level translation
> > 3.3 Interrupt remapping
> > 3.4 1st level translation
> > 3.5 Implementation consideration
> > 4. Qemu
> > 4.1 Qemu vIOMMU framework
> > 4.2 Dummy xen-vIOMMU driver
> > 4.3 Q35 vs. i440x
> > 4.4 Report vIOMMU to hvmloader
> > 
> > 
> > 1 Motivation for Xen vIOMMU
> > ===
> > 1.1 Enable more than 255 vcpu support
> > HPC virtualization requires more than 255 vcpus support in a single VM
> > to meet parallel computing requirement. More than 255 vcpus support
> > requires interrupt remapping capability present on vIOMMU to deliver
> > interrupt to #vcpu >255 Otherwise Linux guest fails to boot up with >255
> > vcpus if interrupt remapping is absent.
> > 
> > 
> > 1.2 Support VFIO-based user space driver (e.g. DPDK) in the guest
> > It relies on the 2nd level translation capability (IOVA->GPA) on
> > vIOMMU. pIOMMU 2nd level becomes a shadowing structure of
> > vIOMMU to isolate DMA requests initiated by user space driver.
> > 
> > 
> > 1.3 Support guest SVM (Shared Virtual Memory)
> > It relies on the 1st level translation table capability (GVA->GPA) on
> > vIOMMU. pIOMMU needs to enable both 1st level and 2nd level translation
> > in nested mode (GVA->GPA->HPA) for passthrough device. IGD passthrough
> > is the main usage today (to support OpenCL 2.0 SVM feature). In the
> > future SVM might be used by other I/O devices too.
> > 
> > 2. Xen vIOMMU Architecture
> > 
> > 
> > * vIOMMU will be inside Xen hypervisor for following factors
> > 1) Avoid round trips between Qemu and Xen hypervisor
> > 2) Ease of integration with the rest of the hypervisor
> > 3) HVMlite/PVH doesn't use Qemu
> > * Dummy xen-vIOMMU in Qemu as a wrapper of new hypercall to create
> > /destory vIOMMU in hypervisor and deal with virtual PCI device's 2th
> > level translation.
> > 
> > 2.1 2th level translation overview
> > For Virtual PCI device, dummy xen-vIOMMU does translation in the
> > Qemu via new hypercall.
> > 
> > For physical PCI device, vIOMMU in hypervisor shadows IO page table from
> > IOVA->GPA to IOVA->HPA and load page table to physical IOMMU.
> > 
> > The following diagram shows 2th level translation architecture.
> > +-+
> > |Qemu++   |
> > || Virtual|   |
> > ||   PCI device   |   |
> > |||   |
> > |++   |
> > ||DMA |
> > |V|
> > |  ++   Request  ++   |
> > |  |+<---+|   |
> > |  |  Dummy xen vIOMMU  | Target GPA | 

Re: [Xen-devel] [RFC] Shared coprocessor framework

[Andrii Anisov]

> I was thinking of something trivial but enough to prove the point.
> Something like a very simple accelerator, maybe a data copy accelerator.
> A GPU is certainly not trivial :-)
Indeed.
But we still have targets to reach and shortage in resources to spread
over simple examples ;)

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] Low-hanging fruit bugs for starting contributor

[Andrew Cooper]

On 22/11/16 15:49, Elazar Leibovich wrote:
> Hi,
> For someone wishing to start contributing to  Xen hypervisor, what
> would you recommend as an easy, educational, bug he could start with?

Not a bug pe say, but something I have just tripped over again and
remember that I had already decided to fix it when 4.9 opened up again.

There has previously been discussion of following the Linux way of
arranging architecture header files, by placing them in
arch/$FOO/include/asm/* rather than include/$symlink/*

This prevents the need for the build system to go symlinking things, and
makes cscope/tags/gtags happier indexing all the source.

If you fancy adjusting this, it should be fairly easy.

~Andrew

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

Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

[Boris Ostrovsky]

On 11/23/2016 10:38 AM, Andrew Cooper wrote:
> Intel VT-x and AMD SVM provide access to the full segment descriptor cache via
> fields in the VMCB/VMCS.  However, the bits which are actually checked by
> hardware and preserved across vmentry/exit are inconsistent, and the vendor
> accessor functions perform inconsistent modification to the raw values.
>
> Convert {svm,vmx}_{get,set}_segment_register() into raw accessors, and alter
> hvm_{get,set}_segment_register() to cook the values consistently.  This allows
> the common emulation code to better rely on finding architecturally-expected
> values.
>
> This does cause some functional changes because of the modifications being
> applied uniformly.  A side effect of this fixes latent bugs where
> vmx_set_segment_register() didn't correctly fix up .G for segments, and
> inconsistent fixing up of the GDTR/IDTR limits.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
> ---
>  xen/arch/x86/hvm/hvm.c| 151 
> ++
>  xen/arch/x86/hvm/svm/svm.c|  20 +-
>  xen/arch/x86/hvm/vmx/vmx.c|   6 +-
>  xen/include/asm-x86/desc.h|   6 ++
>  xen/include/asm-x86/hvm/hvm.h |  17 ++---
>  5 files changed, 164 insertions(+), 36 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index ef83100..804cd88 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -6051,6 +6051,157 @@ void hvm_domain_soft_reset(struct domain *d)
>  }
>  
>  /*
> + * Segment caches in VMCB/VMCS are inconsistent about which bits are checked,
> + * important, and preserved across vmentry/exit.  Cook the values to make 
> them
> + * closer to what is architecturally expected from entries in the segment
> + * cache.
> + */
> +void hvm_get_segment_register(struct vcpu *v, enum x86_segment seg,
> +  struct segment_register *reg)
> +{
> +hvm_funcs.get_segment_register(v, seg, reg);
> +
> +switch ( seg )
> +{
> +case x86_seg_ss:
> +/* SVM may retain %ss.DB when %ss is loaded with a NULL selector. */
> +if ( !reg->attr.fields.p )
> +reg->attr.fields.db = 0;

Removed SVM code relied on type being zero to indicate a NULL segment.
Looking at P bit is the correct way and I think it's worth mentioning
this in the commit message.


> +}
> +
> +void hvm_set_segment_register(struct vcpu *v, enum x86_segment seg,
> +  struct segment_register *reg)
> +{
> +/* Set G to match the limit field.  VT-x cares, while SVM doesn't. */
> +if ( reg->attr.fields.p )
> +reg->attr.fields.g = !!(reg->limit >> 20);
> +
> +switch ( seg )
> +{
> +case x86_seg_cs:
> +ASSERT(reg->attr.fields.p);  /* Usable. */
> +ASSERT(reg->attr.fields.s);  /* User segment. */
> +ASSERT((reg->base >> 32) == 0);  /* Upper bits clear. */
> +break;
> +
> +case x86_seg_ss:
> +if ( reg->attr.fields.p )
> +{
> +ASSERT(reg->attr.fields.s);  /* User segment. */
> +ASSERT(!(reg->attr.fields.type & 0x8));  /* Data segment. */
> +ASSERT(reg->attr.fields.type & 0x2); /* Writeable. */
> +ASSERT((reg->base >> 32) == 0);  /* Upper bits clear. */
> +}
> +break;

SVM requires attributes of any NULL segment to be zero. I don't know
about Intel but if it's the same then should we ASSERT this as well?


-boris


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

Re: [Xen-devel] [RFC] Shared coprocessor framework

[Stefano Stabellini]

On Wed, 23 Nov 2016, Andrii Anisov wrote:
> Stefano,
> 
> Please see my answers below:
> >
> > Thank you for the document, I think is a very good start. I also see the
> > need for this framework. Please add more details about the proposed
> > interface (Xen API, hypercalls, etc) in the next version; I am looking
> > forward to it.
> 
> We will come up with the document update once we have it agreed internally.
> 
> >> AA> Due to the fact that some domain assigned a vcoproc could access 
> >> coproc when
> >> AA> it is running another domain context, framework will implement iomem 
> >> access
> >> AA> emulation for domains which are not provided coproc at the moment of 
> >> access.
> >
> > This is certainly going to be the hardest part. I take the framework is
> > just going to provide a generic API for implementing a coprocessor
> > emulator and it is going to be up to each coprocessor implementation to
> > provide the code.
> 
> This piece together with the context switching logic is definitely a
> platform specific stuff and its complexity could be different
> coprocessor to coprocessor.
> Registers access emultaion for not running vcopro is expected to be
> not very complex for our case:
> - saved context return on register read
> - stacking on writes to be executed during switching context to that 
> vcoproc
> - rare more complex corner cases
> 
> > Is the emulator going to live in the Xen hypervisor?
> That is the idea.
> 
> > It would be nice to provide a simple coprocessor example, if you have one.
> I'm not really sure about a simple functional example. We are
> targeting GPU sharing for the first drop.
 
I was thinking of something trivial but enough to prove the point.
Something like a very simple accelerator, maybe a data copy accelerator.
A GPU is certainly not trivial :-)

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

Re: [Xen-devel] [PATCH v9 07/13] x86: add multiboot2 protocol support for EFI platforms

[Andrew Cooper]

On 29/09/16 22:42, Daniel Kiper wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper 
> ---
> v9 - suggestions/fixes:
>- use .L labels instead of numeric ones in multiboot2 data scanning loops
>  (suggested by Jan Beulich).
>
> v8 - suggestions/fixes:
>- use __bss_start(%rip)/__bss_end(%rip) instead of
>  of .startof.(.bss)(%rip)/$.sizeof.(.bss) because
>  latter is not tested extensively in different
>  built environments yet
>  (suggested by Andrew Cooper),
>- fix multiboot2 data scanning loop in x86_32 code
>  (suggested by Jan Beulich),
>- add check for extra mem for mbi data if Xen is loaded
>  via multiboot2 protocol on EFI platform
>  (suggested by Jan Beulich),
>- improve comments
>  (suggested by Jan Beulich).
>
> v7 - suggestions/fixes:
>- do not allocate twice memory for trampoline if we were
>  loaded via multiboot2 protocol on EFI platform,
>- wrap long line
>  (suggested by Jan Beulich),
>- improve comments
>  (suggested by Jan Beulich).
>
> v6 - suggestions/fixes:
>- improve label names in assembly
>  error printing code
>  (suggested by Jan Beulich),
>- improve comments
>  (suggested by Jan Beulich),
>- various minor cleanups and fixes
>  (suggested by Jan Beulich).
>
> v4 - suggestions/fixes:
>- remove redundant BSS alignment,
>- update BSS alignment check,
>- use __set_bit() instead of set_bit() if possible
>  (suggested by Jan Beulich),
>- call efi_arch_cpu() from efi_multiboot2()
>  even if the same work is done later in
>  other place right now
>  (suggested by Jan Beulich),
>- xen/arch/x86/efi/stub.c:efi_multiboot2()
>  fail properly on EFI platforms,
>- do not read data beyond the end of multiboot2
>  information in xen/arch/x86/boot/head.S
>  (suggested by Jan Beulich),
>- use 32-bit registers in x86_64 code if possible
>  (suggested by Jan Beulich),
>- multiboot2 information address is 64-bit
>  in x86_64 code, so, treat it is as is
>  (suggested by Jan Beulich),
>- use cmovcc if possible,
>- leave only one space between rep and stosq
>  (suggested by Jan Beulich),
>- improve error handling,
>- improve early error messages,
>  (suggested by Jan Beulich),
>- improve early error messages printing code,
>- improve label names
>  (suggested by Jan Beulich),
>- improve comments
>  (suggested by Jan Beulich),
>- various minor cleanups.
>
> v3 - suggestions/fixes:
>- take into account alignment when skipping multiboot2 fixed part
>  (suggested by Konrad Rzeszutek Wilk),
>- improve segment registers initialization
>  (suggested by Jan Beulich),
>- improve comments
>  (suggested by Jan Beulich and Konrad Rzeszutek Wilk),
>- improve commit message
>  (suggested by Jan Beulich).
>
> v2 - suggestions/fixes:
>- generate multiboot2 header using macros
>  (suggested by Jan Beulich),
>- switch CPU to x86_32 mode before
>  jumping to 32-bit code
>  (suggested by Andrew Cooper),
>- reduce code changes to increase patch readability
>  (suggested by Jan Beulich),
>- improve comments
>  (suggested by Jan Beulich),
>- ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform
>  and find on my own multiboot2.mem_lower value,
>- stop execution if EFI platform is detected
>  in legacy BIOS path.
> ---
>  xen/arch/x86/boot/head.S  |  260 
> ++---
>  xen/arch/x86/efi/efi-boot.h   |   54 +++-
>  xen/arch/x86/efi/stub.c   |   38 ++
>  xen/arch/x86/x86_64/asm-offsets.c |2 +
>  xen/arch/x86/xen.lds.S|4 +-
>  xen/common/efi/boot.c |   11 ++
>  6 files changed, 346 insertions(+), 23 deletions(-)
>
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index d423fd8..0155b32 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -89,6 +89,13 @@ multiboot2_header_start:
> 0, /* Number of the lines - no preference. */ \
> 0  /* Number of bits per pixel - no preference. */
>  
> +/* Inhibit bootloader from calling ExitBootServices(). */
> +mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
> +
> +/* EFI64 entry point. */
> +mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
> +   sym_phys(__efi64_start)
> +
>  /* Multiboot2 header end tag. */
>  mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
>  .Lmultiboot2_header_end:
> @@ -100,20 +107,49 @@ multiboot2_header_start:
>  gdt_boot_descr:
>  .word   6*8-1
>  .long   sym_phys(trampoline_gdt)
> +.long   0 /* Needed for 64-bit lgdt */
> +
> +cs32_switch_addr:
> +.long   

Re: [Xen-devel] [PATCH] xen_disk: convert discard input to byte ranges

[Stefano Stabellini]

On Wed, 23 Nov 2016, Olaf Hering wrote:
> On Wed, Nov 23, Olaf Hering wrote:
> 
> > > > +if (!blk_split_discard(ioreq, req->sector_number, 
> > > > req->nr_sectors)) {
> > > > +goto err;
> > > How is error handling supposed to work here?
> 
> In the guest the cmd is stuck, instead of getting an IO error:
> 
> [   91.966404] mkfs.ext4   D  0  2878   2831 
> 0x
> [   91.966406]  88002204bc48 880030530480 88002fae5800 
> 88002204c000
> [   91.966407]   7fff 8000 
> 024000c0
> [   91.966409]  88002204bc60 815dd985 880038815c00 
> 88002204bd08
> [   91.966409] Call Trace:
> [   91.966413]  [] schedule+0x35/0x80
> [   91.966416]  [] schedule_timeout+0x237/0x2d0
> [   91.966419]  [] io_schedule_timeout+0xa6/0x110
> [   91.966421]  [] wait_for_completion_io+0xa3/0x110
> [   91.966425]  [] submit_bio_wait+0x50/0x60
> [   91.966430]  [] blkdev_issue_discard+0x78/0xb0
> [   91.966433]  [] blk_ioctl_discard+0x7b/0xa0
> [   91.966436]  [] blkdev_ioctl+0x730/0x920
> [   91.966440]  [] block_ioctl+0x3d/0x40
> [   91.966444]  [] do_vfs_ioctl+0x2cd/0x4a0
> [   91.966453]  [] SyS_ioctl+0x74/0x80
> [   91.966456]  [] entry_SYSCALL_64_fastpath+0x12/0x6d

The error should be sent back to the frontend via the status field. Not
sure why blkfront is not hanlding it correctly.

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

Re: [Xen-devel] [PATCH v3] xen_disk: split discard input to match internal representation

[Stefano Stabellini]

On Wed, 23 Nov 2016, Olaf Hering wrote:
> The guest sends discard requests as u64 sector/count pairs, but the
> block layer operates internally with s64/s32 pairs. The conversion
> leads to IO errors in the guest, the discard request is not processed.
> 
>   domU.cfg:
>   'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
>   domU:
>   mkfs.ext4 -F /dev/xvda
>   Discarding device blocks: failed - Input/output error
> 
> Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
> Add input range checking to avoid overflow.
> 
> Fixes f313520 ("xen_disk: add discard support")
> 
> Signed-off-by: Olaf Hering 

Reviewed-by: Stefano Stabellini 


> v3:
>  turn tab into spaces to fix checkpatch warning
> v2:
>  adjust overflow check
>  add Fixes revspec because the initial commit also failed to convert u64 to 
> s32
>  adjust summary
> 
>  hw/block/xen_disk.c | 42 --
>  1 file changed, 36 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 3a7dc19..456a2d5 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -660,6 +660,38 @@ static void qemu_aio_complete(void *opaque, int ret)
>  qemu_bh_schedule(ioreq->blkdev->bh);
>  }
>  
> +static bool blk_split_discard(struct ioreq *ioreq, blkif_sector_t 
> sector_number,
> +  uint64_t nr_sectors)
> +{
> +struct XenBlkDev *blkdev = ioreq->blkdev;
> +int64_t byte_offset;
> +int byte_chunk;
> +uint64_t byte_remaining, limit;
> +uint64_t sec_start = sector_number;
> +uint64_t sec_count = nr_sectors;
> +
> +/* Wrap around, or overflowing byte limit? */
> +if (sec_start + sec_count < sec_count ||
> +sec_start + sec_count > INT64_MAX >> BDRV_SECTOR_BITS) {
> +return false;
> +}
> +
> +limit = BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS;
> +byte_offset = sec_start << BDRV_SECTOR_BITS;
> +byte_remaining = sec_count << BDRV_SECTOR_BITS;
> +
> +do {
> +byte_chunk = byte_remaining > limit ? limit : byte_remaining;
> +ioreq->aio_inflight++;
> +blk_aio_pdiscard(blkdev->blk, byte_offset, byte_chunk,
> + qemu_aio_complete, ioreq);
> +byte_remaining -= byte_chunk;
> +byte_offset += byte_chunk;
> +} while (byte_remaining > 0);
> +
> +return true;
> +}
> +
>  static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
>  {
>  struct XenBlkDev *blkdev = ioreq->blkdev;
> @@ -708,12 +740,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
>  break;
>  case BLKIF_OP_DISCARD:
>  {
> -struct blkif_request_discard *discard_req = (void *)>req;
> -ioreq->aio_inflight++;
> -blk_aio_pdiscard(blkdev->blk,
> - discard_req->sector_number << BDRV_SECTOR_BITS,
> - discard_req->nr_sectors << BDRV_SECTOR_BITS,
> - qemu_aio_complete, ioreq);
> +struct blkif_request_discard *req = (void *)>req;
> +if (!blk_split_discard(ioreq, req->sector_number, req->nr_sectors)) {
> +goto err;
> +}
>  break;
>  }
>  default:
> 

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

Re: [Xen-devel] [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

[Stefano Stabellini]

On Wed, 23 Nov 2016, Kevin Wolf wrote:
> Am 23.11.2016 um 12:40 hat Eric Blake geschrieben:
> > On 11/23/2016 04:39 AM, Olaf Hering wrote:
> > > The guest sends discard requests as u64 sector/count pairs, but the
> > > block layer operates internally with s64/s32 pairs. The conversion
> > > leads to IO errors in the guest, the discard request is not processed.
> > > 
> > >   domU.cfg:
> > >   'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
> > >   domU:
> > >   mkfs.ext4 -F /dev/xvda
> > >   Discarding device blocks: failed - Input/output error
> > > 
> > > Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
> > > Add input range checking to avoid overflow.
> > > 
> > > Fixes f313520 ("xen_disk: add discard support")
> > > 
> > > Signed-off-by: Olaf Hering 
> > > ---
> > 
> > Qualifies as a bug fix, so requesting 2.8 inclusion.
> > Reviewed-by: Eric Blake 
> 
> Stefano, are you going to merge this or should I take a look?

I can merge it.

Cheers,

Stefano

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Julien Grall]

Hi Edgar,

On 23/11/16 16:38, Edgar E. Iglesias wrote:

On Wed, Nov 23, 2016 at 06:26:06PM +0200, Artem Mygaiev wrote:

On 23.11.16 17:19, Julien Grall wrote:

There is a couple of usecase where we cannot use PV console:
- Running unmodified baremetal application as guest. Those
applications will not have PV driver.

Well, I somehow missed that requirement is to run *unmodified*
applications... I think it will be pretty hard to provide all the HW
infrastructure expected and UARTs as I know them have all possible
issues & workarounds.


Hi Artem,

The way I see this is not for Xen to provide support for any HW for any
platform on all platforms.

The way I see it is that on a given platform, for example the ZynqMP.
You can run Xen as a partitioning Hypervisor essentially using device
passthrough to assign various real HW devices to each VM.

The various guests can run unmodified because they each see a subset
of the platform.

It is useful to have vuarts that go are shared into a single one.


To expand on the vuart, this is a small emulator to handle write from a 
guest. This was originally designed to handle DOM0 early console that is 
hardcoded on ARM32.


As mentioned by Artem, read would be more complex as it will mean 
per-UART emulator. IIRC, this would not be a problem for you, right?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] xen: ignore direction in bufioreq handling

[Stefano Stabellini]

On Wed, 23 Nov 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 23 November 2016 09:25
> > To: qemu-de...@nongnu.org
> > Cc: Anthony Perard ; Paul Durrant
> > ; Stefano Stabellini ; xen-
> > devel 
> > Subject: [PATCH 3/3] xen: ignore direction in bufioreq handling
> > 
> > There's no way to communicate back read data, so only writes can ever
> > be usefully specified. Ignore the field, paving the road for eventually
> > re-using the bit for something else in a few (many?) years time.
> > 
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Paul Durrant 

Acked-by: Stefano Stabellini 


> > 
> > --- a/xen-hvm.c
> > +++ b/xen-hvm.c
> > @@ -997,6 +997,7 @@ static int handle_buffered_iopage(XenIOS
> >  memset(, 0x00, sizeof(req));
> >  req.state = STATE_IOREQ_READY;
> >  req.count = 1;
> > +req.dir = IOREQ_WRITE;
> > 
> >  for (;;) {
> >  uint32_t rdptr = buf_page->read_pointer, wrptr;
> > @@ -1014,7 +1015,6 @@ static int handle_buffered_iopage(XenIOS
> >  req.size = 1U << buf_req->size;
> >  req.addr = buf_req->addr;
> >  req.data = buf_req->data;
> > -req.dir = buf_req->dir;
> >  req.type = buf_req->type;
> >  xen_rmb();
> >  qw = (req.size == 8);
> > @@ -1031,10 +1031,12 @@ static int handle_buffered_iopage(XenIOS
> >  handle_ioreq(state, );
> > 
> >  /* Only req.data may get updated by handle_ioreq(), albeit even 
> > that
> > - * should not happen as such data would never make it to the guest.
> > + * should not happen as such data would never make it to the guest 
> > (we
> > + * can only usefully see writes here after all).
> >   */
> >  assert(req.state == STATE_IOREQ_READY);
> >  assert(req.count == 1);
> > +assert(req.dir == IOREQ_WRITE);
> >  assert(!req.data_is_ptr);
> > 
> >  atomic_add(_page->read_pointer, qw + 1);
> > 
> > 
> 

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc

[Edgar E. Iglesias]

On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote:
> Hi All:
>  The following is our Xen vIOMMU high level design for detail
> discussion. Please have a look. Very appreciate for your comments.
> This design doesn't cover changes when root port is moved to hypervisor.
> We may design it later.

Hi,

I have a few questions.

If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
So guests will essentially create intel iommu style page-tables.

If we were to use this on Xen/ARM, we would likely be modelling an ARM
SMMU as a vIOMMU. Since Xen on ARM does not use QEMU for emulation, the
hypervisor OPs for QEMUs xen dummy IOMMU queries would not really be used.
Do I understand this correctly?

Has a platform agnostic PV-IOMMU been considered to support 2-stage
translation (i.e VFIO in the guest)? Perhaps that would hurt map/unmap
performance too much?

Best regards,
Edgar




> 
> 
> Content:
> ===
> 1. Motivation of vIOMMU
>   1.1 Enable more than 255 vcpus
>   1.2 Support VFIO-based user space driver
>   1.3 Support guest Shared Virtual Memory (SVM)
> 2. Xen vIOMMU Architecture
>   2.1 2th level translation overview
>   2.2 Interrupt remapping overview
> 3. Xen hypervisor
>   3.1 New vIOMMU hypercall interface
>   3.2 2nd level translation
>   3.3 Interrupt remapping
>   3.4 1st level translation
>   3.5 Implementation consideration
> 4. Qemu
>   4.1 Qemu vIOMMU framework
>   4.2 Dummy xen-vIOMMU driver
>   4.3 Q35 vs. i440x
>   4.4 Report vIOMMU to hvmloader
> 
> 
> 1 Motivation for Xen vIOMMU
> ===
> 1.1 Enable more than 255 vcpu support
> HPC virtualization requires more than 255 vcpus support in a single VM
> to meet parallel computing requirement. More than 255 vcpus support
> requires interrupt remapping capability present on vIOMMU to deliver
> interrupt to #vcpu >255 Otherwise Linux guest fails to boot up with >255
> vcpus if interrupt remapping is absent.
> 
> 
> 1.2 Support VFIO-based user space driver (e.g. DPDK) in the guest
> It relies on the 2nd level translation capability (IOVA->GPA) on
> vIOMMU. pIOMMU 2nd level becomes a shadowing structure of
> vIOMMU to isolate DMA requests initiated by user space driver.
> 
> 
> 1.3 Support guest SVM (Shared Virtual Memory)
> It relies on the 1st level translation table capability (GVA->GPA) on
> vIOMMU. pIOMMU needs to enable both 1st level and 2nd level translation
> in nested mode (GVA->GPA->HPA) for passthrough device. IGD passthrough
> is the main usage today (to support OpenCL 2.0 SVM feature). In the
> future SVM might be used by other I/O devices too.
> 
> 2. Xen vIOMMU Architecture
> 
> 
> * vIOMMU will be inside Xen hypervisor for following factors
>   1) Avoid round trips between Qemu and Xen hypervisor
>   2) Ease of integration with the rest of the hypervisor
>   3) HVMlite/PVH doesn't use Qemu
> * Dummy xen-vIOMMU in Qemu as a wrapper of new hypercall to create
> /destory vIOMMU in hypervisor and deal with virtual PCI device's 2th
> level translation.
> 
> 2.1 2th level translation overview
> For Virtual PCI device, dummy xen-vIOMMU does translation in the
> Qemu via new hypercall.
> 
> For physical PCI device, vIOMMU in hypervisor shadows IO page table from
> IOVA->GPA to IOVA->HPA and load page table to physical IOMMU.
> 
> The following diagram shows 2th level translation architecture.
> +-+
> |Qemu++   |
> || Virtual|   |
> ||   PCI device   |   |
> |||   |
> |++   |
> ||DMA |
> |V|
> |  ++   Request  ++   |
> |  |+<---+|   |
> |  |  Dummy xen vIOMMU  | Target GPA |  Memory region |   |
> |  |+--->+|   |
> |  +-+--++---++   |
> ||   ||
> ||Hypercall  ||
> +++
> |Hypervisor  |   ||
> ||   ||
> |v   ||
> | +--+--+||
> | |   vIOMMU|||
> | +--+--+|  

Re: [Xen-devel] [PATCH 2/3] xen: slightly simplify bufioreq handling

[Stefano Stabellini]

On Wed, 23 Nov 2016, Jan Beulich wrote:
> There's no point setting fields always receiving the same value on each
> iteration, as handle_ioreq() doesn't alter them anyway. Set state and
> count once ahead of the loop, drop the redundant clearing of
> data_is_ptr, and avoid the meaningless setting of df altogether.

Why setting df is meaningless?


> Also avoid doing an unsigned long calculation of size when the field to
> be initialized is only 32 bits wide (and the shift value in the range
> 0...3).
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOS
>  }
>  
>  memset(, 0x00, sizeof(req));
> +req.state = STATE_IOREQ_READY;
> +req.count = 1;
>  
>  for (;;) {
>  uint32_t rdptr = buf_page->read_pointer, wrptr;
> @@ -1009,15 +1011,11 @@ static int handle_buffered_iopage(XenIOS
>  break;
>  }
>  buf_req = _page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
> -req.size = 1UL << buf_req->size;
> -req.count = 1;
> +req.size = 1U << buf_req->size;
>  req.addr = buf_req->addr;
>  req.data = buf_req->data;
> -req.state = STATE_IOREQ_READY;
>  req.dir = buf_req->dir;
> -req.df = 1;
>  req.type = buf_req->type;
> -req.data_is_ptr = 0;
>  xen_rmb();
>  qw = (req.size == 8);
>  if (qw) {
> @@ -1032,6 +1030,13 @@ static int handle_buffered_iopage(XenIOS
>  
>  handle_ioreq(state, );
>  
> +/* Only req.data may get updated by handle_ioreq(), albeit even that
> + * should not happen as such data would never make it to the guest.
> + */
> +assert(req.state == STATE_IOREQ_READY);
> +assert(req.count == 1);
> +assert(!req.data_is_ptr);
> +
>  atomic_add(_page->read_pointer, qw + 1);
>  }
>  
> 
> 
> 

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

Re: [Xen-devel] [PATCH 1/3] xen: fix quad word bufioreq handling

[Stefano Stabellini]

On Wed, 23 Nov 2016, Jan Beulich wrote:
> >>> On 23.11.16 at 11:45,  wrote:
> > No, if QEMU is using a default ioreq server (i.e. the legacy way of doing 
> > things) then it's vulnerable to the guest messing with the rings and I'd 
> > forgotten that migrated-in guests from old QEMUs also end up using the 
> > default 
> > server, so I guess this is a worthy checkt to make... although maybe it's 
> > best to just bail if the check fails, since it would indicate a malicious 
> > guest.
> 
> Okay, that's basically the TBD note I have in the patch; I'll wait for
> at least one of the qemu maintainers to voice their preference.
 
I think we should just print an error and destroy_hvm_domain(false) or
hw_error if the check fails.

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

Re: [Xen-devel] [qemu-mainline test] 102527: regressions - trouble: broken/fail/pass

[Anthony PERARD]

On Wed, Nov 23, 2016 at 04:49:40PM +, osstest service owner wrote:
> flight 102527 qemu-mainline real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/102527/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 
> 101909

In QEMU logs:
gnttab: error: ioctl GRANT COPY failed 25 : Inappropriate ioctl for device
xen be: qdisk-51712: xen be: qdisk-51712: write I/O error
write I/O error


>  test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
> 101909

Don't know what went wrong with this one.

>  test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
> REGR. vs. 101909

In QEMU logs:
gnttab: error: ioctl GRANT COPY failed 25 : Inappropriate ioctl for device
xen be: qdisk-768: xen be: qdisk-768: write I/O error
write I/O error


-- 
Anthony PERARD

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

[Xen-devel] [xen-unstable-smoke test] 102568: tolerable all pass - PUSHED

[osstest service owner]

flight 102568 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102568/

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  e5745b86e6e114f0e5b15bf67ed8d37a3d019f66
baseline version:
 xen  986f790e0184d4bf575462077378e14fa9f85aa9

Last test of basis   102526  2016-11-22 17:05:48 Z1 days
Testing same since   102568  2016-11-23 14:20:53 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Roger Pau Monne 
  Roger Pau Monné 

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=e5745b86e6e114f0e5b15bf67ed8d37a3d019f66
+ . ./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 
e5745b86e6e114f0e5b15bf67ed8d37a3d019f66
+ branch=xen-unstable-smoke
+ revision=e5745b86e6e114f0e5b15bf67ed8d37a3d019f66
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xe5745b86e6e114f0e5b15bf67ed8d37a3d019f66 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH] libxl: fix creation of pkgconf install dir

[Wei Liu]

On Wed, Nov 23, 2016 at 04:56:39PM +, Roger Pau Monne wrote:
> When PKG_INSTALLDIR was introduced the creation of the previous pkgconf 
> install
> directory was not changed. Fix this by correctly using PKG_INSTALLDIR for the
> directory creation in libxl Makefile.
> 
> Signed-off-by: Roger Pau Monné 

Acked + applied.

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

Re: [Xen-devel] [PATCH 13/15] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

[Andrew Cooper]

On 23/11/16 16:39, Tim Deegan wrote:
> At 15:38 + on 23 Nov (1479915536), Andrew Cooper wrote:
>> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
>> to inject the pagefault themselves.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper 
>> index afacd5f..88d4642 100644
>> --- a/xen/arch/x86/mm/shadow/common.c
>> +++ b/xen/arch/x86/mm/shadow/common.c
>> @@ -198,6 +198,7 @@ hvm_read(enum x86_segment seg,
>>  case HVMCOPY_okay:
>>  return X86EMUL_OKAY;
>>  case HVMCOPY_bad_gva_to_gfn:
>> +hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
>>  return X86EMUL_EXCEPTION;
>>  case HVMCOPY_bad_gfn_to_mfn:
>>  case HVMCOPY_unhandleable:
> Should this also be converted to pass the injection to the emulator
> rather than injecting it directly?

Yes.

emulate_gva_to_mfn() also needs similar treatment, but will include some
PV pagetable fun as well.

~Andrew

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

Re: [Xen-devel] [PATCH 04/15] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

[Boris Ostrovsky]

On 11/23/2016 10:38 AM, Andrew Cooper wrote:
> and move it to live with the other x86_event infrastructure in x86_emulate.h.
> Switch it and x86_event.error_code to being signed, matching the rest of the
> code.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by: Boris Ostrovsky 



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

[Xen-devel] [qemu-upstream-4.4-testing test] 102531: tolerable FAIL - PUSHED

[osstest service owner]

flight 102531 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102531/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 99724

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass

version targeted for testing:
 qemuu5fadf00bf21ad3706f69b12877cd76aab4e17ecd
baseline version:
 qemuue72488cdcf2208f2df334fa88c35b33e695fa93b

Last test of basis99724  2016-07-27 18:09:58 Z  118 days
Testing same since   102531  2016-11-22 20:04:12 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 pass
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-4.4-testing
+ revision=5fadf00bf21ad3706f69b12877cd76aab4e17ecd
+ . ./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
+++ 

Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

[Andrew Cooper]

On 23/11/16 16:50, Tim Deegan wrote:
> At 16:40 + on 23 Nov (1479919254), Andrew Cooper wrote:
>> On 23/11/16 16:31, Tim Deegan wrote:
>>> At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote:
 Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), 
 and
 use this instead of hvm_inject_page_fault() from emulation codepaths.

 Replace one hvm_inject_hw_exception() in the shadow emulation codepaths.

 Signed-off-by: Andrew Cooper 
 NOTE: this is a functional change for the shadow code, as a #PF previously
 raised properly with the guest will now cause X86EMUL_UNHANDLABLE. It is my
 understanding after a discusion with Tim that this is ok, but I haven't 
 done
 extenstive testing yet.
>>> Do you plan to?  I think this is indeed OK, but there may be some edge
>>> case, e.g. an instruction that writes to both the current top-level
>>> pagetable (which can't be unshadowed) and an unmapped virtual address.
>>> That ought to raise #PF in the guest but might now spin retrying?
>> That is a devious corner case.  I take it you have been there before?
> In similar situations, yes. :)
>
>> The more I think about these changes, the more I think that the shadow
>> code would be better by selectively looking a pending event, injecting
>> pagefaults, but rejecting and retrying if any other event shows up.
> That sounds like a good idea, and seems like the smallest deviation
> from the current behaviour.  It might also be OK to inject any event
> that the emulator raises.  That's a bigger change but maybe a more
> coherent end result?

Well - now this isn't hidden in a security fix, I am less averse to
functional changes.

My only concern is that the previous lack of the ->inject_hw_exception()
hook cut off large chunks of functionality from the shadow and PV PT
emulation paths, and I am not sure opening this up in general is a good
idea.

Longterm the plan is to fully split the decode and emulate calls even
for external callers, at which point the the pagetable code could check
that the instruction is write which matches %cr2 before proceeding with
emulation.  Even then however, I am not sure it would be a good idea to
follow anything other than a pagefault which surfaces from emulation.

~Andrew

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

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

[Boris Ostrovsky]

On 11/23/2016 10:38 AM, Andrew Cooper wrote:
> The x86 emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.  The naming choice is to match both the Intel and
> AMD terms, and to avoid 'trap' specifically as it has an architectural meaning
> different to its current usage.
>
> While making this change, make other changes for consistency
>
>  * Rename *_trap() infrastructure to *_event()
>  * Rename trapnr/trap parameters to vector
>  * Convert hvm_inject_hw_exception() and hvm_inject_page_fault() to being
>static inlines, as they are only thin wrappers around hvm_inject_event()
>
> No functional change.
>
> Signed-off-by: Andrew Cooper 
>


Reviewed-by: Boris Ostrovsky 

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

[Xen-devel] [PATCH] libxl: fix creation of pkgconf install dir

[Roger Pau Monne]

When PKG_INSTALLDIR was introduced the creation of the previous pkgconf install
directory was not changed. Fix this by correctly using PKG_INSTALLDIR for the
directory creation in libxl Makefile.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
Not sure whether this should be considered for 4.8. IMHO, it's a harmless fix
for Linux (where PKG_INSTALLDIR is already $(SHAREDIR)/pkgconfig), but it might
be more important for FreeBSD.
---
 tools/libxl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index f5053a0..ef01785 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -308,7 +308,7 @@ install: all
$(INSTALL_DIR) $(DESTDIR)$(includedir)
$(INSTALL_DIR) $(DESTDIR)$(BASH_COMPLETION_DIR)
$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-   $(INSTALL_DIR) $(DESTDIR)$(SHAREDIR)/pkgconfig
+   $(INSTALL_DIR) $(DESTDIR)$(PKG_INSTALLDIR)
$(INSTALL_PROG) xl $(DESTDIR)$(sbindir)
$(INSTALL_PROG) libxl-save-helper $(DESTDIR)$(LIBEXEC_BIN)
$(INSTALL_SHLIB) libxenlight.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
-- 
2.9.3 (Apple Git-75)


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

Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

[Tim Deegan]

At 16:40 + on 23 Nov (1479919254), Andrew Cooper wrote:
> On 23/11/16 16:31, Tim Deegan wrote:
> > At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote:
> >> Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), 
> >> and
> >> use this instead of hvm_inject_page_fault() from emulation codepaths.
> >>
> >> Replace one hvm_inject_hw_exception() in the shadow emulation codepaths.
> >>
> >> Signed-off-by: Andrew Cooper 
> >> NOTE: this is a functional change for the shadow code, as a #PF previously
> >> raised properly with the guest will now cause X86EMUL_UNHANDLABLE. It is my
> >> understanding after a discusion with Tim that this is ok, but I haven't 
> >> done
> >> extenstive testing yet.
> > Do you plan to?  I think this is indeed OK, but there may be some edge
> > case, e.g. an instruction that writes to both the current top-level
> > pagetable (which can't be unshadowed) and an unmapped virtual address.
> > That ought to raise #PF in the guest but might now spin retrying?
> 
> That is a devious corner case.  I take it you have been there before?

In similar situations, yes. :)

> The more I think about these changes, the more I think that the shadow
> code would be better by selectively looking a pending event, injecting
> pagefaults, but rejecting and retrying if any other event shows up.

That sounds like a good idea, and seems like the smallest deviation
from the current behaviour.  It might also be OK to inject any event
that the emulator raises.  That's a bigger change but maybe a more
coherent end result?

Cheers,

Tim.

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

[Xen-devel] [qemu-mainline test] 102527: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 102527 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102527/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
101909
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 101909

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  3 host-install(3)broken REGR. vs. 101909
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101909
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101909
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101909
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101909
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101909
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101909

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   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-qcow2 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuua7764f1548ef9946af30a8f96be9cef10761f0c1
baseline version:
 qemuu199a5bde46b0eab898ab1ec591f423000302569f

Last test of basis   101909  2016-11-03 23:21:40 Z   19 days
Failing since101943  2016-11-04 22:40:48 Z   18 days   41 attempts
Testing same since   102527  2016-11-22 17:27:55 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Williamson 
  Alexey Kardashevskiy 
  Ankit Kumar 
  ann.zhuangyany...@huawei.com
  Anthony PERARD 
  Ashijeet Acharya 
  Balbir singh 
  Bharata B Rao 
  Brian Candler 
  Christian Borntraeger 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel Oram 
  Daniel P. Berrange 
  David Gibson 
  Doug Evans 
  Ed Maste 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Farhan Ali 
  Gautham R. Shenoy 
  Gerd Hoffmann 
  Gonglei 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  Jason Wang 

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

[Tim Deegan]

At 09:33 -0700 on 23 Nov (1479893609), Jan Beulich wrote:
> >>> On 23.11.16 at 17:19,  wrote:
> > Hi,
> > 
> > At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote:
> >> The emulator needs to gain an understanding of interrupts and exceptions
> >> generated by its actions.
> >> 
> >> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so 
> > they
> >> are visible to the emulator.  This removes the need for the
> >> inject_{hw,sw}_interrupt() hooks, which are dropped and replaced with
> >> x86_emul_{hw_exception,software_event}() instead.
> >> 
> >> The shadow pagetable and PV uses of x86_emulate() previously failed with
> >> X86EMUL_UNHANDLEABLE due to the lack of inject_*() hooks, but this 
> >> behaviour
> >> has subtly changed.  Adjust the return value checking to cause a pending 
> > event
> >> to fall back into the previous codepath.
> >> 
> >> No overall functional change.
> > 
> > AIUI this does have a change in the shadow callers in the case where
> > the emulated instruction would inject an event.  Previously we would
> > have failed the emulation, perhaps unshadowed something, and returned
> > to the guest to retry.
> > 
> > Now the emulator records the event in the context struct, updates the
> > register state and returns success, so we'll return on the *next*
> > instruction.  I think that's OK, though.
> 
> Not exactly - instead of success, X86EMUL_EXCEPTION is being
> returned, which would suppress register updates.

Oh right.  In that case AFAICS neither invocation of x86_emulate() in
shadow/multi.c needs any adjustment.

Tim.

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

Re: [Xen-devel] [PATCH 14/15] x86/hvm: Prepare to allow use of system segments for memory references

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 23 November 2016 15:39
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant 
> Subject: [PATCH 14/15] x86/hvm: Prepare to allow use of system segments
> for memory references
> 
> All system segments (GDT/IDT/LDT and TR) describe a linear address and
> limit,
> and act similarly to user segments.  However all current uses of these tables
> in the emulator opencode the address calculations and limit checks.  In
> particular, no care is taken for access which wrap around the 4GB or
> non-canonical boundaries.
> 
> Alter hvm_virtual_to_linear_addr() to cope with performing segmentation
> checks
> on system segments.  This involves restricting access checks in the 32bit case
> to user segments only, and adding presence/limit checks in the 64bit case.
> 
> When suffering a segmentation fault for a system segments, return
> X86EMUL_EXCEPTION but leave the fault injection to the caller.  The fault
> type
> depends on the higher level action being performed.
> 
> Signed-off-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 
> Reviewed-by: George Dunlap 
> ---
> CC: Paul Durrant 

Reviewed-by: Paul Durrant 

> ---
>  xen/arch/x86/hvm/emulate.c | 14 
>  xen/arch/x86/hvm/hvm.c | 40 ++---
> -
>  xen/arch/x86/mm/shadow/common.c| 12 +++---
>  xen/arch/x86/x86_emulate/x86_emulate.h | 26 ++
>  4 files changed, 62 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index c248eca..3a7d1f3 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -567,10 +567,16 @@ static int hvmemul_virtual_to_linear(
>  if ( *reps != 1 )
>  return X86EMUL_UNHANDLEABLE;
> 
> -/* This is a singleton operation: fail it with an exception. */
> -x86_emul_hw_exception((seg == x86_seg_ss)
> -  ? TRAP_stack_error
> -  : TRAP_gp_fault, 0, _ctxt->ctxt);
> +/*
> + * Leave exception injection to the caller for non-user segments: We
> + * neither know the exact error code to be used, nor can we easily
> + * determine the kind of exception (#GP or #TS) in that case.
> + */
> +if ( is_x86_user_segment(seg) )
> +x86_emul_hw_exception((seg == x86_seg_ss)
> +  ? TRAP_stack_error
> +  : TRAP_gp_fault, 0, _ctxt->ctxt);
> +
>  return X86EMUL_EXCEPTION;
>  }
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e1f2c9e..2bcef1f 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2497,24 +2497,28 @@ bool_t hvm_virtual_to_linear_addr(
>  if ( !reg->attr.fields.p )
>  goto out;
> 
> -switch ( access_type )
> +/* Read/write restrictions only exist for user segments. */
> +if ( reg->attr.fields.s )
>  {
> -case hvm_access_read:
> -if ( (reg->attr.fields.type & 0xa) == 0x8 )
> -goto out; /* execute-only code segment */
> -break;
> -case hvm_access_write:
> -if ( (reg->attr.fields.type & 0xa) != 0x2 )
> -goto out; /* not a writable data segment */
> -break;
> -default:
> -break;
> +switch ( access_type )
> +{
> +case hvm_access_read:
> +if ( (reg->attr.fields.type & 0xa) == 0x8 )
> +goto out; /* execute-only code segment */
> +break;
> +case hvm_access_write:
> +if ( (reg->attr.fields.type & 0xa) != 0x2 )
> +goto out; /* not a writable data segment */
> +break;
> +default:
> +break;
> +}
>  }
> 
>  last_byte = (uint32_t)offset + bytes - !!bytes;
> 
>  /* Is this a grows-down data segment? Special limit check if so. */
> -if ( (reg->attr.fields.type & 0xc) == 0x4 )
> +if ( reg->attr.fields.s && (reg->attr.fields.type & 0xc) == 0x4 )
>  {
>  /* Is upper limit 0x or 0x? */
>  if ( !reg->attr.fields.db )
> @@ -2530,10 +2534,18 @@ bool_t hvm_virtual_to_linear_addr(
>  else
>  {
>  /*
> - * LONG MODE: FS and GS add segment base. Addresses must be
> canonical.
> + * User segments are always treated as present.  System segment may
> + * not be, and also incur limit checks.
>   */
> +if ( is_x86_system_segment(seg) &&
> + (!reg->attr.fields.p || (offset + bytes - !!bytes) > 
> 

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

[Andrew Cooper]

On 23/11/16 16:41, Boris Ostrovsky wrote:
> On 11/23/2016 10:38 AM, Andrew Cooper wrote:
>>  * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
>>very closely related.
>>  * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
>>hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how 
>> to
>>and when to use them.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Paul Durrant 
>> CC: Jun Nakajima 
>> CC: Kevin Tian 
>> CC: Boris Ostrovsky 
>> CC: Suravee Suthikulpanit 
>> CC: Wei Liu 
> Reviewed-by: Boris Ostrovsky 
>
> (although I am having trouble parsing the first bullet in the commit
> message)

Ah "to immediately after".  I will fix up the text.

~Andrew

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

Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

[Andrew Cooper]

On 23/11/16 16:31, Tim Deegan wrote:
> At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote:
>> Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and
>> use this instead of hvm_inject_page_fault() from emulation codepaths.
>>
>> Replace one hvm_inject_hw_exception() in the shadow emulation codepaths.
>>
>> Signed-off-by: Andrew Cooper 
>> NOTE: this is a functional change for the shadow code, as a #PF previously
>> raised properly with the guest will now cause X86EMUL_UNHANDLABLE. It is my
>> understanding after a discusion with Tim that this is ok, but I haven't done
>> extenstive testing yet.
> Do you plan to?  I think this is indeed OK, but there may be some edge
> case, e.g. an instruction that writes to both the current top-level
> pagetable (which can't be unshadowed) and an unmapped virtual address.
> That ought to raise #PF in the guest but might now spin retrying?

That is a devious corner case.  I take it you have been there before?

The more I think about these changes, the more I think that the shadow
code would be better by selectively looking a pending event, injecting
pagefaults, but rejecting and retrying if any other event shows up.

~Andrew

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

Re: [Xen-devel] [PATCH 11/15] x86/hvm: Reimplement hvm_copy_*_nofault() in terms of no pagefault_info

[Tim Deegan]

At 16:35 + on 23 Nov (1479918931), Tim Deegan wrote:
> At 15:38 + on 23 Nov (1479915534), Andrew Cooper wrote:
> > No functional change.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Shouldn't this also update the comments to describe the new semantics
> of hvm_copy_*()?

Right, now I see that this all goes away later in the series.  So, Ack.

Tim.

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

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

[Jan Beulich]

 >>> On 23.11.16 at 16:38,  wrote:
> * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
>very closely related.
>  * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
>hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how to
>and when to use them.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with one further cosmetic request:

> @@ -2006,6 +1956,57 @@ void hvm_emulate_prepare(
>  hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
>  }
>  
> +void hvm_emulate_init_per_insn(
> +struct hvm_emulate_ctxt *hvmemul_ctxt,
> +const unsigned char *insn_buf,
> +unsigned int insn_bytes)
> +{
> +struct vcpu *curr = current;
> +unsigned int pfec = PFEC_page_present;
> +unsigned long addr;
> +
> +if ( hvm_long_mode_enabled(curr) &&
> + hvmemul_ctxt->seg_reg[x86_seg_cs].attr.fields.l )
> +{
> +hvmemul_ctxt->ctxt.addr_size = hvmemul_ctxt->ctxt.sp_size = 64;
> +}

Please consider dropping the stray braces here.

Jan


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

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

[Andrew Cooper]

On 23/11/16 16:19, Tim Deegan wrote:
> Hi,
>
> At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote:
>> The emulator needs to gain an understanding of interrupts and exceptions
>> generated by its actions.
>>
>> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
>> are visible to the emulator.  This removes the need for the
>> inject_{hw,sw}_interrupt() hooks, which are dropped and replaced with
>> x86_emul_{hw_exception,software_event}() instead.
>>
>> The shadow pagetable and PV uses of x86_emulate() previously failed with
>> X86EMUL_UNHANDLEABLE due to the lack of inject_*() hooks, but this behaviour
>> has subtly changed.  Adjust the return value checking to cause a pending 
>> event
>> to fall back into the previous codepath.
>>
>> No overall functional change.
> AIUI this does have a change in the shadow callers in the case where
> the emulated instruction would inject an event.  Previously we would
> have failed the emulation, perhaps unshadowed something, and returned
> to the guest to retry.
> Now the emulator records the event in the context struct, updates the
> register state and returns success, so we'll return on the *next*
> instruction.  I think that's OK, though.

We are still passing X86EMUL_EXCEPTION back into the emulator, so
nothing changes immediately from that point of view.  It will still
"goto done" and skip the writeback phase.

> Also, handle_mmio() and other callers of the emulator check for that
> pending event and pass it to the hardware but you haven't added
> anything in the shadow code to do that.  Does the event get dropped?

Yes.  That was the intended purpose of these hunks:

diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index d70b1c6..84cb6b6 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3378,7 +3378,7 @@ static int sh_page_fault(struct vcpu *v,
  * would be a good unshadow hint. If we *do* decide to unshadow-on-fault
  * then it must be 'failable': we cannot require the unshadow to succeed.
  */
-if ( r == X86EMUL_UNHANDLEABLE )
+if ( r == X86EMUL_UNHANDLEABLE || emul_ctxt.ctxt.event_pending )
 {
 perfc_incr(shadow_fault_emulate_failed);
 #if SHADOW_OPTIMIZATIONS & SHOPT_FAST_EMULATION
@@ -3433,7 +3433,7 @@ static int sh_page_fault(struct vcpu *v,
 shadow_continue_emulation(_ctxt, regs);
 v->arch.paging.last_write_was_pt = 0;
 r = x86_emulate(_ctxt.ctxt, emul_ops);
-if ( r == X86EMUL_OKAY )
+if ( r == X86EMUL_OKAY && !emul_ctxt.ctxt.event_pending )
 {
 emulation_count++;
 if ( v->arch.paging.last_write_was_pt )

To take the failure path any time an event is seen pending.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

[Boris Ostrovsky]

On 11/23/2016 10:38 AM, Andrew Cooper wrote:
>  * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
>very closely related.
>  * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
>hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how to
>and when to use them.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Paul Durrant 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
> CC: Wei Liu 

Reviewed-by: Boris Ostrovsky 

(although I am having trouble parsing the first bullet in the commit
message)


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

Re: [Xen-devel] [PATCH 13/15] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

[Tim Deegan]

At 15:38 + on 23 Nov (1479915536), Andrew Cooper wrote:
> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
> to inject the pagefault themselves.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

> index afacd5f..88d4642 100644
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -198,6 +198,7 @@ hvm_read(enum x86_segment seg,
>  case HVMCOPY_okay:
>  return X86EMUL_OKAY;
>  case HVMCOPY_bad_gva_to_gfn:
> +hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
>  return X86EMUL_EXCEPTION;
>  case HVMCOPY_bad_gfn_to_mfn:
>  case HVMCOPY_unhandleable:

Should this also be converted to pass the injection to the emulator
rather than injecting it directly?

Tim.

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

Re: [Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 23 November 2016 15:39
> To: Xen-devel 
> Cc: Andrew Cooper ; Paul Durrant
> ; Tim (Xen.org) ; Jun Nakajima
> ; Kevin Tian 
> Subject: [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a
> pagefault_info pointer
> 
> which is filled with pagefault information should one occur.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Reviewed-by: Paul Durrant 

> ---
> CC: Paul Durrant 
> CC: Tim Deegan 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> ---
>  xen/arch/x86/hvm/emulate.c|  8 ---
>  xen/arch/x86/hvm/hvm.c| 49 +-
> -
>  xen/arch/x86/hvm/vmx/vvmx.c   |  9 ---
>  xen/arch/x86/mm/shadow/common.c   |  5 ++--
>  xen/include/asm-x86/hvm/support.h | 23 +-
>  5 files changed, 63 insertions(+), 31 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 3ebb200..e50ee24 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -770,6 +770,7 @@ static int __hvmemul_read(
>  struct hvm_emulate_ctxt *hvmemul_ctxt)
>  {
>  struct vcpu *curr = current;
> +pagefault_info_t pfinfo;
>  unsigned long addr, reps = 1;
>  uint32_t pfec = PFEC_page_present;
>  struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
> @@ -790,8 +791,8 @@ static int __hvmemul_read(
>  pfec |= PFEC_user_mode;
> 
>  rc = ((access_type == hvm_access_insn_fetch) ?
> -  hvm_fetch_from_guest_virt(p_data, addr, bytes, pfec) :
> -  hvm_copy_from_guest_virt(p_data, addr, bytes, pfec));
> +  hvm_fetch_from_guest_virt(p_data, addr, bytes, pfec, ) :
> +  hvm_copy_from_guest_virt(p_data, addr, bytes, pfec, ));
> 
>  switch ( rc )
>  {
> @@ -878,6 +879,7 @@ static int hvmemul_write(
>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>  struct vcpu *curr = current;
> +pagefault_info_t pfinfo;
>  unsigned long addr, reps = 1;
>  uint32_t pfec = PFEC_page_present | PFEC_write_access;
>  struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
> @@ -896,7 +898,7 @@ static int hvmemul_write(
>   (hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3) )
>  pfec |= PFEC_user_mode;
> 
> -rc = hvm_copy_to_guest_virt(addr, p_data, bytes, pfec);
> +rc = hvm_copy_to_guest_virt(addr, p_data, bytes, pfec, );
> 
>  switch ( rc )
>  {
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 804cd88..afba51f 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2859,6 +2859,7 @@ void hvm_task_switch(
>  struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
>  bool_t otd_writable, ntd_writable;
>  unsigned long eflags;
> +pagefault_info_t pfinfo;
>  int exn_raised, rc;
>  struct {
>  u16 back_link,__blh;
> @@ -2925,7 +2926,7 @@ void hvm_task_switch(
>  }
> 
>  rc = hvm_copy_from_guest_virt(
> -, prev_tr.base, sizeof(tss), PFEC_page_present);
> +, prev_tr.base, sizeof(tss), PFEC_page_present, );
>  if ( rc != HVMCOPY_okay )
>  goto out;
> 
> @@ -2963,12 +2964,12 @@ void hvm_task_switch(
>  ,
>  offsetof(typeof(tss), trace) -
>  offsetof(typeof(tss), eip),
> -PFEC_page_present);
> +PFEC_page_present, );
>  if ( rc != HVMCOPY_okay )
>  goto out;
> 
>  rc = hvm_copy_from_guest_virt(
> -, tr.base, sizeof(tss), PFEC_page_present);
> +, tr.base, sizeof(tss), PFEC_page_present, );
>  /*
>   * Note: The HVMCOPY_gfn_shared case could be optimised, if the callee
>   * functions knew we want RO access.
> @@ -3008,7 +3009,8 @@ void hvm_task_switch(
>  tss.back_link = prev_tr.sel;
> 
>  rc = hvm_copy_to_guest_virt(tr.base + offsetof(typeof(tss), 
> back_link),
> -_link, sizeof(tss.back_link), 
> 0);
> +_link, sizeof(tss.back_link), 0,
> +);
>  if ( rc == HVMCOPY_bad_gva_to_gfn )
>  exn_raised = 1;
>  else if ( rc != HVMCOPY_okay )
> @@ -3045,7 +3047,8 @@ void hvm_task_switch(
>  16 << segr.attr.fields.db,
>  _addr) )
>  {
> -rc = hvm_copy_to_guest_virt(linear_addr, , opsz, 0);
> +rc 

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Edgar E. Iglesias]

On Wed, Nov 23, 2016 at 06:26:06PM +0200, Artem Mygaiev wrote:
> On 23.11.16 17:19, Julien Grall wrote:
> > There is a couple of usecase where we cannot use PV console:
> > - Running unmodified baremetal application as guest. Those
> > applications will not have PV driver.
> Well, I somehow missed that requirement is to run *unmodified*
> applications... I think it will be pretty hard to provide all the HW
> infrastructure expected and UARTs as I know them have all possible
> issues & workarounds.

Hi Artem,

The way I see this is not for Xen to provide support for any HW for any
platform on all platforms.

The way I see it is that on a given platform, for example the ZynqMP.
You can run Xen as a partitioning Hypervisor essentially using device
passthrough to assign various real HW devices to each VM.

The various guests can run unmodified because they each see a subset
of the platform.

It is useful to have vuarts that go are shared into a single one.

Cheers,
Edgar



> > - Guest compliant with the VM system specification for ARM [1]. A
> > pl011 is required.
> Yes, indeed, a subset of PL011 registers is required, unfortunately I
> was not familiar with that spec, thanks.

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

[Xen-devel] [PATCH v9] sndif: add ABI for para-virtual sound

[Oleksandr Andrushchenko]

Hi, all!

First of all we would like to thank you for valuable comments!

Please find the next version of the ABI for the PV sound.

Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov

Oleksandr Andrushchenko (1):
  xen: add para-virtual sound interface header files

 include/xen/interface/io/sndif.h   | 609 +
 include/xen/interface/io/sndif_linux.h | 112 ++
 2 files changed, 721 insertions(+)
 create mode 100644 include/xen/interface/io/sndif.h
 create mode 100644 include/xen/interface/io/sndif_linux.h

-- 
2.7.4


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

[Xen-devel] [PATCH v9] xen: add para-virtual sound interface header files

[Oleksandr Andrushchenko]

This is the ABI for the two halves of a para-virtualized
sound driver to communicate with each to other.

Signed-off-by: Oleksandr Andrushchenko 
Signed-off-by: Oleksandr Grytsov 
Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Iurii Konovalenko 

---
Changes since v1:
 * removed __attribute__((__packed__)) from all structures definitions

Changes since v2:
 * removed all C structures
 * added protocol description between frontend and backend drivers

Changes since v3:
 * fixed some typos
 * renamed XENSND_PCM_FORMAT_FLOAT_** to XENSND_PCM_FORMAT_F32_**
 * renamed XENSND_PCM_FORMAT_FLOAT64_** to XENSND_PCM_FORMAT_F64_**
 * added 'id' field to the request and response packets
 * renamed 'stream_id' to 'stream' in the packets description
 * renamed 'pcm_data_rate' to 'pcm_rate' in the packets description
 * renamed 'pcm_stream_type' to 'pcm_type' in the packets description
 * removed 'stream_id' field from the response packets

Changes since v4:
 * renamed 'stream_id' back to the to 'stream' in the packets description
 * moved 'id' field to the upper position in the response packets

Changes since v5:
 * Slightly reworked request/response packets
 * Size of the request/response packet is changed to the 64 bytes
 * Now parameters for the XENSND_OP_SET_VOLUME/XENSND_OP_GET_VOLUME are
   passed via shared page
 * Added parameters for the XenBus nodes (now each stream can be mapped
   to the defined sound device in the backend using those parameters)
 * Added XenBus state diagrams description

Changes since v6:
 * Reworked streams description  in the Backend XenBus Nodes

Changes since v7:
 * re-worked backend device parameters to be more generic and flexible
 * extended frontend device parameters
 * slightly updated state machine description added mute/unmute commands
 * added constants for XenStore configuration strings
   (fields, PCM formats etc.)
 * changed request/response structure size from 64 octets to 16
 * introduced dynamic buffer allocation instead of
   static XENSND_MAX_PAGES_PER_REQUEST
 * re-worked open request to allow dynamic buffer allocation
 * re-worked read/write/volume requests, so they don't pass grefs:
   buffer from the open request is used for these operations to pass data
 * specified type of the volume value to be a signed value in steps
   of 0.001 dBm, while 0 being 0dBm.
 * added Linux include file with structure definitions

Changes since v8:
 * changed frontend-id to frontend_id
 * single sound card support, configured with bunch of
   devices/streams
 * clarifucation made on sample rates and formats expressed as
   decimals w/o any particular ordering
 * put description of migration/disconnection state
 * replaced __attribute__((packed)) to __packed
 * changed padding of ring structures to 64 to fit cache line
 * removeed #ifdef __KERNEL
 * explicitly stated which indices in XenStore configuration
   are contiguous
 * added description to what frontend's defaults are
 * made names of virtual card/devices optional
 * removed PCM_FORMAT_SPECIAL
 * changed volume units from dBm to dB
---
 include/xen/interface/io/sndif.h   | 609 +
 include/xen/interface/io/sndif_linux.h | 112 ++
 2 files changed, 721 insertions(+)
 create mode 100644 include/xen/interface/io/sndif.h
 create mode 100644 include/xen/interface/io/sndif_linux.h

diff --git a/include/xen/interface/io/sndif.h b/include/xen/interface/io/sndif.h
new file mode 100644
index 000..06079c7
--- /dev/null
+++ b/include/xen/interface/io/sndif.h
@@ -0,0 +1,609 @@
+/**
+ * sndif.h
+ *
+ * Unified sound-device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2013-2015 GlobalLogic Inc.
+ * Copyright (C) 2016 EPAM Systems 

Re: [Xen-devel] [PATCH 12/15] x86/hvm: Rename hvm_copy_*_guest_virt() to hvm_copy_*_guest_linear()

[Tim Deegan]

At 15:38 + on 23 Nov (1479915535), Andrew Cooper wrote:
> The functions use linear addresses, not virtual addresses, as no segmentation
> is used.  (Lots of other code in Xen makes this mistake.)
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Tim Deegan 

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

Re: [Xen-devel] [PATCH 11/15] x86/hvm: Reimplement hvm_copy_*_nofault() in terms of no pagefault_info

[Tim Deegan]

At 15:38 + on 23 Nov (1479915534), Andrew Cooper wrote:
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Shouldn't this also update the comments to describe the new semantics
of hvm_copy_*()?

Tim.


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

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

[Jan Beulich]

>>> On 23.11.16 at 17:19,  wrote:
> Hi,
> 
> At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote:
>> The emulator needs to gain an understanding of interrupts and exceptions
>> generated by its actions.
>> 
>> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so 
> they
>> are visible to the emulator.  This removes the need for the
>> inject_{hw,sw}_interrupt() hooks, which are dropped and replaced with
>> x86_emul_{hw_exception,software_event}() instead.
>> 
>> The shadow pagetable and PV uses of x86_emulate() previously failed with
>> X86EMUL_UNHANDLEABLE due to the lack of inject_*() hooks, but this behaviour
>> has subtly changed.  Adjust the return value checking to cause a pending 
> event
>> to fall back into the previous codepath.
>> 
>> No overall functional change.
> 
> AIUI this does have a change in the shadow callers in the case where
> the emulated instruction would inject an event.  Previously we would
> have failed the emulation, perhaps unshadowed something, and returned
> to the guest to retry.
> 
> Now the emulator records the event in the context struct, updates the
> register state and returns success, so we'll return on the *next*
> instruction.  I think that's OK, though.

Not exactly - instead of success, X86EMUL_EXCEPTION is being
returned, which would suppress register updates. Also I don't
think continuing on the next instruction would be okay, as we'd
then basically have skipped the one having caused the (not
delivered) exception.

Jan


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

Re: [Xen-devel] [PATCH 10/15] x86/hvm: Extend the hvm_copy_*() API with a pagefault_info pointer

[Tim Deegan]

At 15:38 + on 23 Nov (1479915533), Andrew Cooper wrote:
> which is filled with pagefault information should one occur.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 

Acked-by: Tim Deegan 

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

Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

[Tim Deegan]

At 15:38 + on 23 Nov (1479915532), Andrew Cooper wrote:
> Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), and
> use this instead of hvm_inject_page_fault() from emulation codepaths.
> 
> Replace one hvm_inject_hw_exception() in the shadow emulation codepaths.
> 
> Signed-off-by: Andrew Cooper 

> NOTE: this is a functional change for the shadow code, as a #PF previously
> raised properly with the guest will now cause X86EMUL_UNHANDLABLE. It is my
> understanding after a discusion with Tim that this is ok, but I haven't done
> extenstive testing yet.

Do you plan to?  I think this is indeed OK, but there may be some edge
case, e.g. an instruction that writes to both the current top-level
pagetable (which can't be unshadowed) and an unmapped virtual address.
That ought to raise #PF in the guest but might now spin retrying?  

Tim.

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Artem Mygaiev]

On 23.11.16 17:19, Julien Grall wrote:
> There is a couple of usecase where we cannot use PV console:
> - Running unmodified baremetal application as guest. Those
> applications will not have PV driver.
Well, I somehow missed that requirement is to run *unmodified*
applications... I think it will be pretty hard to provide all the HW
infrastructure expected and UARTs as I know them have all possible
issues & workarounds.
> - Guest compliant with the VM system specification for ARM [1]. A
> pl011 is required.
Yes, indeed, a subset of PL011 registers is required, unfortunately I
was not familiar with that spec, thanks.

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

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

[Andrew Cooper]

On 23/11/16 16:12, Paul Durrant wrote:
>> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
>> index f24e211..d0c3185 100644
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -1679,7 +1679,7 @@ static int hvmemul_invlpg(
>>   * violations, so squash them.
>>   */
>>  hvmemul_ctxt->exn_pending = 0;
>> -hvmemul_ctxt->trap = (struct hvm_trap){};
>> +hvmemul_ctxt->trap = (struct x86_event){};
> Can't say I like that way of initializing but...
>
> Reviewed-by: Paul Durrant 

Think of it like memcpy/memset, but typesafe.  Either way, this is a
strict renaming patch, I wouldn't want to change the method of
initialisation here anyway.

~Andrew

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

Re: [Xen-devel] [PATCH 04/15] x86/emul: Rename HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 23 November 2016 15:39
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Jun
> Nakajima ; Kevin Tian ;
> Boris Ostrovsky ; Suravee Suthikulpanit
> 
> Subject: [PATCH 04/15] x86/emul: Rename
> HVM_DELIVER_NO_ERROR_CODE to X86_EVENT_NO_EC
> 
> and move it to live with the other x86_event infrastructure in
> x86_emulate.h.
> Switch it and x86_event.error_code to being signed, matching the rest of the
> code.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Paul Durrant 

> ---
> CC: Jan Beulich 
> CC: Paul Durrant 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
> ---
>  xen/arch/x86/hvm/emulate.c |  2 +-
>  xen/arch/x86/hvm/hvm.c |  6 +++---
>  xen/arch/x86/hvm/nestedhvm.c   |  2 +-
>  xen/arch/x86/hvm/svm/nestedsvm.c   |  6 +++---
>  xen/arch/x86/hvm/svm/svm.c | 22 +++---
>  xen/arch/x86/hvm/vmx/intr.c|  2 +-
>  xen/arch/x86/hvm/vmx/vmx.c | 23 ---
>  xen/arch/x86/hvm/vmx/vvmx.c|  2 +-
>  xen/arch/x86/x86_emulate/x86_emulate.h |  3 ++-
>  xen/include/asm-x86/hvm/support.h  |  2 --
>  10 files changed, 35 insertions(+), 35 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index d0c3185..790e9c1 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1609,7 +1609,7 @@ static int hvmemul_inject_sw_interrupt(
> 
>  hvmemul_ctxt->exn_pending = 1;
>  hvmemul_ctxt->trap.vector = vector;
> -hvmemul_ctxt->trap.error_code = HVM_DELIVER_NO_ERROR_CODE;
> +hvmemul_ctxt->trap.error_code = X86_EVENT_NO_EC;
>  hvmemul_ctxt->trap.insn_len = insn_len;
> 
>  return X86EMUL_OKAY;
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 7b434aa..b950842 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -502,7 +502,7 @@ void hvm_do_resume(struct vcpu *v)
>  kind = EMUL_KIND_SET_CONTEXT_INSN;
> 
>  hvm_emulate_one_vm_event(kind, TRAP_invalid_op,
> - HVM_DELIVER_NO_ERROR_CODE);
> + X86_EVENT_NO_EC);
> 
>  v->arch.vm_event->emulate_flags = 0;
>  }
> @@ -3054,7 +3054,7 @@ void hvm_task_switch(
>  }
> 
>  if ( (tss.trace & 1) && !exn_raised )
> -hvm_inject_hw_exception(TRAP_debug,
> HVM_DELIVER_NO_ERROR_CODE);
> +hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
> 
>   out:
>  hvm_unmap_entry(optss_desc);
> @@ -4073,7 +4073,7 @@ void hvm_ud_intercept(struct cpu_user_regs
> *regs)
>  switch ( hvm_emulate_one() )
>  {
>  case X86EMUL_UNHANDLEABLE:
> -hvm_inject_hw_exception(TRAP_invalid_op,
> HVM_DELIVER_NO_ERROR_CODE);
> +hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
>  break;
>  case X86EMUL_EXCEPTION:
>  if ( ctxt.exn_pending )
> diff --git a/xen/arch/x86/hvm/nestedhvm.c
> b/xen/arch/x86/hvm/nestedhvm.c
> index caad525..c4671d8 100644
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -17,7 +17,7 @@
>   */
> 
>  #include 
> -#include  /* for
> HVM_DELIVER_NO_ERROR_CODE */
> +#include 
>  #include 
>  #include /* for struct p2m_domain */
>  #include 
> diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c
> b/xen/arch/x86/hvm/svm/nestedsvm.c
> index b6b8526..8c9b073 100644
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -756,7 +756,7 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct
> cpu_user_regs *regs)
>  default:
>  gdprintk(XENLOG_ERR,
>  "nsvm_vcpu_vmentry failed, injecting #UD\n");
> -hvm_inject_hw_exception(TRAP_invalid_op,
> HVM_DELIVER_NO_ERROR_CODE);
> +hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
>  /* Must happen after hvm_inject_hw_exception or it doesn't work
> right. */
>  nv->nv_vmswitch_in_progress = 0;
>  return 1;
> @@ -1581,7 +1581,7 @@ void svm_vmexit_do_stgi(struct cpu_user_regs
> *regs, struct vcpu *v)
>  unsigned int inst_len;
> 
>  if ( !nestedhvm_enabled(v->domain) ) {
> -hvm_inject_hw_exception(TRAP_invalid_op,
> HVM_DELIVER_NO_ERROR_CODE);
> +hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
>  return;
>  }
> 
> @@ -1601,7 +1601,7 @@ void svm_vmexit_do_clgi(struct cpu_user_regs
> *regs, struct vcpu *v)
>  vintr_t intr;

Re: [Xen-devel] [PATCH 06/15] x86/emul: Rework emulator event injection

[Tim Deegan]

Hi,

At 15:38 + on 23 Nov (1479915529), Andrew Cooper wrote:
> The emulator needs to gain an understanding of interrupts and exceptions
> generated by its actions.
> 
> Move hvm_emulate_ctxt.{exn_pending,trap} into struct x86_emulate_ctxt so they
> are visible to the emulator.  This removes the need for the
> inject_{hw,sw}_interrupt() hooks, which are dropped and replaced with
> x86_emul_{hw_exception,software_event}() instead.
> 
> The shadow pagetable and PV uses of x86_emulate() previously failed with
> X86EMUL_UNHANDLEABLE due to the lack of inject_*() hooks, but this behaviour
> has subtly changed.  Adjust the return value checking to cause a pending event
> to fall back into the previous codepath.
> 
> No overall functional change.

AIUI this does have a change in the shadow callers in the case where
the emulated instruction would inject an event.  Previously we would
have failed the emulation, perhaps unshadowed something, and returned
to the guest to retry.

Now the emulator records the event in the context struct, updates the
register state and returns success, so we'll return on the *next*
instruction.  I think that's OK, though.

Also, handle_mmio() and other callers of the emulator check for that
pending event and pass it to the hardware but you haven't added
anything in the shadow code to do that.  Does the event get dropped?

Tim.

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

Re: [Xen-devel] [PATCH 13/15] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

[Andrew Cooper]

On 23/11/16 15:38, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
> index afacd5f..88d4642 100644
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -198,6 +198,7 @@ hvm_read(enum x86_segment seg,
>  case HVMCOPY_okay:
>  return X86EMUL_OKAY;
>  case HVMCOPY_bad_gva_to_gfn:
> +hvm_inject_page_fault(pfinfo.ec, pfinfo.linear);
>  return X86EMUL_EXCEPTION;
>  case HVMCOPY_bad_gfn_to_mfn:
>  case HVMCOPY_unhandleable:

I realise I have forgotten to adjust this change to being
x86_emul_pagefault().  emulate_gva_to_mfn() also needs modifying in a
similar vein.

~Andrew

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

Re: [Xen-devel] [PATCH KERNEL] xen/events: use xen_vcpu_id mapping for EVTCHNOP_status

[Boris Ostrovsky]

On 11/23/2016 07:38 AM, Vitaly Kuznetsov wrote:
> EVTCHNOP_status hypercall returns Xen's idea of vcpu id so we need to
> compare it against xen_vcpu_id mapping, not the Linux cpu id.
>
> Suggested-by: Radim Krcmar 
> Signed-off-by: Vitaly Kuznetsov 

Reviewed-by: Boris Ostrovsky 


> ---
>  drivers/xen/events/events_base.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/xen/events/events_base.c 
> b/drivers/xen/events/events_base.c
> index 9ecfcdc..137bd0e 100644
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -948,7 +948,7 @@ static int find_virq(unsigned int virq, unsigned int cpu)
>   continue;
>   if (status.status != EVTCHNSTAT_virq)
>   continue;
> - if (status.u.virq == virq && status.vcpu == cpu) {
> + if (status.u.virq == virq && status.vcpu == xen_vcpu_nr(cpu)) {
>   rc = port;
>   break;
>   }


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

Re: [Xen-devel] [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and move it into the emulation infrastructure

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 23 November 2016 15:39
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Jun
> Nakajima ; Kevin Tian ;
> Boris Ostrovsky ; Suravee Suthikulpanit
> 
> Subject: [PATCH 03/15] x86/emul: Rename hvm_trap to x86_event and
> move it into the emulation infrastructure
> 
> The x86 emulator needs to gain an understanding of interrupts and
> exceptions
> generated by its actions.  The naming choice is to match both the Intel and
> AMD terms, and to avoid 'trap' specifically as it has an architectural meaning
> different to its current usage.
> 
> While making this change, make other changes for consistency
> 
>  * Rename *_trap() infrastructure to *_event()
>  * Rename trapnr/trap parameters to vector
>  * Convert hvm_inject_hw_exception() and hvm_inject_page_fault() to
> being
>static inlines, as they are only thin wrappers around hvm_inject_event()
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Paul Durrant 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Boris Ostrovsky 
> CC: Suravee Suthikulpanit 
> ---
>  xen/arch/x86/hvm/emulate.c  |  6 +--
>  xen/arch/x86/hvm/hvm.c  | 33 
>  xen/arch/x86/hvm/io.c   |  2 +-
>  xen/arch/x86/hvm/svm/nestedsvm.c|  7 ++--
>  xen/arch/x86/hvm/svm/svm.c  | 62 ++---
>  xen/arch/x86/hvm/vmx/vmx.c  | 66 +++
>  xen/arch/x86/hvm/vmx/vvmx.c | 11 +++---
>  xen/arch/x86/x86_emulate/x86_emulate.c  | 11 ++
>  xen/arch/x86/x86_emulate/x86_emulate.h  | 22 +++
>  xen/include/asm-x86/hvm/emulate.h   |  2 +-
>  xen/include/asm-x86/hvm/hvm.h   | 69 --
> ---
>  xen/include/asm-x86/hvm/svm/nestedsvm.h |  6 +--
>  xen/include/asm-x86/hvm/vcpu.h  |  2 +-
>  xen/include/asm-x86/hvm/vmx/vvmx.h  |  4 +-
>  14 files changed, 159 insertions(+), 144 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index f24e211..d0c3185 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1679,7 +1679,7 @@ static int hvmemul_invlpg(
>   * violations, so squash them.
>   */
>  hvmemul_ctxt->exn_pending = 0;
> -hvmemul_ctxt->trap = (struct hvm_trap){};
> +hvmemul_ctxt->trap = (struct x86_event){};

Can't say I like that way of initializing but...

Reviewed-by: Paul Durrant 

>  rc = X86EMUL_OKAY;
>  }
> 
> @@ -1868,7 +1868,7 @@ int hvm_emulate_one_mmio(unsigned long mfn,
> unsigned long gla)
>  break;
>  case X86EMUL_EXCEPTION:
>  if ( ctxt.exn_pending )
> -hvm_inject_trap();
> +hvm_inject_event();
>  /* fallthrough */
>  default:
>  hvm_emulate_writeback();
> @@ -1928,7 +1928,7 @@ void hvm_emulate_one_vm_event(enum
> emul_kind kind, unsigned int trapnr,
>  break;
>  case X86EMUL_EXCEPTION:
>  if ( ctx.exn_pending )
> -hvm_inject_trap();
> +hvm_inject_event();
>  break;
>  }
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 25dc759..7b434aa 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -535,7 +535,7 @@ void hvm_do_resume(struct vcpu *v)
>  /* Inject pending hw/sw trap */
>  if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>  {
> -hvm_inject_trap(>arch.hvm_vcpu.inject_trap);
> +hvm_inject_event(>arch.hvm_vcpu.inject_trap);
>  v->arch.hvm_vcpu.inject_trap.vector = -1;
>  }
>  }
> @@ -1676,19 +1676,19 @@ void hvm_triple_fault(void)
>  domain_shutdown(d, reason);
>  }
> 
> -void hvm_inject_trap(const struct hvm_trap *trap)
> +void hvm_inject_event(const struct x86_event *event)
>  {
>  struct vcpu *curr = current;
> 
>  if ( nestedhvm_enabled(curr->domain) &&
>   !nestedhvm_vmswitch_in_progress(curr) &&
>   nestedhvm_vcpu_in_guestmode(curr) &&
> - nhvm_vmcx_guest_intercepts_trap(
> - curr, trap->vector, trap->error_code) )
> + nhvm_vmcx_guest_intercepts_event(
> + curr, event->vector, event->error_code) )
>  {
>  enum nestedhvm_vmexits nsret;
> 
> -nsret = nhvm_vcpu_vmexit_trap(curr, trap);
> +nsret = nhvm_vcpu_vmexit_event(curr, event);
> 
>  switch ( nsret )
>  {
> @@ -1704,26 +1704,7 @@ void hvm_inject_trap(const struct 

Re: [Xen-devel] [PATCH 02/15] x86/emul: Simplfy emulation state setup

[Tim Deegan]

At 15:38 + on 23 Nov (1479915525), Andrew Cooper wrote:
> The current code to set up emulation state is ad-hoc and error prone.
> 
>  * Consistently zero all emulation state structures.
>  * Avoid explicitly initialising some state to 0.
>  * Explicitly identify all input and output state in x86_emulate_ctxt.  This
>involves rearanging some fields.
>  * Have x86_decode() explicitly initalise all output state at its start.
> 
> In addition, move the calculation of hvmemul_ctxt->ctxt.swint_emulate from
> _hvm_emulate_one() to hvm_emulate_init_once(), as it doesn't need
> recalculating for each instruction.
> 
> Signed-off-by: Andrew Cooper 

Shadow code changes Acked-by: Tim Deegan 

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

Re: [Xen-devel] [PATCH 02/15] x86/emul: Simplfy emulation state setup

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper
> Sent: 23 November 2016 16:01
> To: Paul Durrant ; Xen-devel  de...@lists.xen.org>
> Cc: Jan Beulich ; Tim (Xen.org) ; George
> Dunlap 
> Subject: Re: [PATCH 02/15] x86/emul: Simplfy emulation state setup
> 
> On 23/11/16 15:58, Paul Durrant wrote:
> >> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
> >> b/xen/arch/x86/x86_emulate/x86_emulate.c
> >> index 04f0dac..c5d9664 100644
> >> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> >> @@ -1904,6 +1904,8 @@ x86_decode(
> >>  state->regs = ctxt->regs;
> >>  state->eip = ctxt->regs->eip;
> >>
> >> +/* Initialise output state in x86_emulate_ctxt */
> >> +ctxt->opcode = ~0u;
> >>  ctxt->retire.byte = 0;
> > In the commit message you state that x86_decode() will "explicitly initalise
> all output state at its start". This doesn't seem to be all the output state. 
> In
> fact you appear to be removing some initialization.
> 
> There are only two fields of output state, as delineated by the extra
> comments in x86_emulate_ctxt.  Most of x86_emulate_ctxt is input state.

D'oh, yes. Sorry, got confused by the field movements... my eyes were seeing 
'+' as '-' for some reason.

  Paul

> 
> >
> >>  op_bytes = def_op_bytes = ad_bytes = def_ad_bytes = ctxt-
> >>> addr_size/8;
> >> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h
> >> b/xen/arch/x86/x86_emulate/x86_emulate.h
> >> index 993c576..93b268e 100644
> >> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> >> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> >> @@ -412,6 +412,10 @@ struct cpu_user_regs;
> >>
> >>  struct x86_emulate_ctxt
> >>  {
> >> +/*
> >> + * Input state:
> >> + */
> >> +
> >>  /* Register state before/after emulation. */
> >>  struct cpu_user_regs *regs;
> >>
> >> @@ -421,14 +425,21 @@ struct x86_emulate_ctxt
> >>  /* Stack pointer width in bits (16, 32 or 64). */
> >>  unsigned int sp_size;
> >>
> >> -/* Canonical opcode (see below). */
> >> -unsigned int opcode;
> >> -
> >>  /* Software event injection support. */
> >>  enum x86_swint_emulation swint_emulate;
> >>
> >>  /* Set this if writes may have side effects. */
> >> -uint8_t force_writeback;
> >> +bool force_writeback;
> > Is this type change intentional? I assume it is, but you didn't call it out.
> 
> Yes.  I thought I had it in the commit message, but will update for v2.
> 
> ~Andrew
> 
> >
> >   Paul
> >
> >> +
> >> +/* Caller data that can be used by x86_emulate_ops' routines. */
> >> +void *data;
> >> +
> >> +/*
> >> + * Output state:
> >> + */
> >> +
> >> +/* Canonical opcode (see below). */
> >> +unsigned int opcode;
> >>
> >>  /* Retirement state, set by the emulator (valid only on
> X86EMUL_OKAY).
> >> */
> >>  union {
> >> @@ -439,9 +450,6 @@ struct x86_emulate_ctxt
> >>  } flags;
> >>  uint8_t byte;
> >>  } retire;
> >> -
> >> -/* Caller data that can be used by x86_emulate_ops' routines. */
> >> -void *data;
> >>  };
> >>
> >>  /*
> >> --
> >> 2.1.4


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

Re: [Xen-devel] [PATCH v3] xen_disk: split discard input to match internal representation

[Anthony PERARD]

On Wed, Nov 23, 2016 at 10:39:12AM +, Olaf Hering wrote:
> The guest sends discard requests as u64 sector/count pairs, but the
> block layer operates internally with s64/s32 pairs. The conversion
> leads to IO errors in the guest, the discard request is not processed.
> 
>   domU.cfg:
>   'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
>   domU:
>   mkfs.ext4 -F /dev/xvda
>   Discarding device blocks: failed - Input/output error
> 
> Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
> Add input range checking to avoid overflow.
> 
> Fixes f313520 ("xen_disk: add discard support")
> 
> Signed-off-by: Olaf Hering 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 02/15] x86/emul: Simplfy emulation state setup

[Andrew Cooper]

On 23/11/16 15:58, Paul Durrant wrote:
>> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
>> b/xen/arch/x86/x86_emulate/x86_emulate.c
>> index 04f0dac..c5d9664 100644
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -1904,6 +1904,8 @@ x86_decode(
>>  state->regs = ctxt->regs;
>>  state->eip = ctxt->regs->eip;
>>
>> +/* Initialise output state in x86_emulate_ctxt */
>> +ctxt->opcode = ~0u;
>>  ctxt->retire.byte = 0;
> In the commit message you state that x86_decode() will "explicitly initalise 
> all output state at its start". This doesn't seem to be all the output state. 
> In fact you appear to be removing some initialization.

There are only two fields of output state, as delineated by the extra
comments in x86_emulate_ctxt.  Most of x86_emulate_ctxt is input state.

>
>>  op_bytes = def_op_bytes = ad_bytes = def_ad_bytes = ctxt-
>>> addr_size/8;
>> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h
>> b/xen/arch/x86/x86_emulate/x86_emulate.h
>> index 993c576..93b268e 100644
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>> @@ -412,6 +412,10 @@ struct cpu_user_regs;
>>
>>  struct x86_emulate_ctxt
>>  {
>> +/*
>> + * Input state:
>> + */
>> +
>>  /* Register state before/after emulation. */
>>  struct cpu_user_regs *regs;
>>
>> @@ -421,14 +425,21 @@ struct x86_emulate_ctxt
>>  /* Stack pointer width in bits (16, 32 or 64). */
>>  unsigned int sp_size;
>>
>> -/* Canonical opcode (see below). */
>> -unsigned int opcode;
>> -
>>  /* Software event injection support. */
>>  enum x86_swint_emulation swint_emulate;
>>
>>  /* Set this if writes may have side effects. */
>> -uint8_t force_writeback;
>> +bool force_writeback;
> Is this type change intentional? I assume it is, but you didn't call it out.

Yes.  I thought I had it in the commit message, but will update for v2.

~Andrew

>
>   Paul
>
>> +
>> +/* Caller data that can be used by x86_emulate_ops' routines. */
>> +void *data;
>> +
>> +/*
>> + * Output state:
>> + */
>> +
>> +/* Canonical opcode (see below). */
>> +unsigned int opcode;
>>
>>  /* Retirement state, set by the emulator (valid only on X86EMUL_OKAY).
>> */
>>  union {
>> @@ -439,9 +450,6 @@ struct x86_emulate_ctxt
>>  } flags;
>>  uint8_t byte;
>>  } retire;
>> -
>> -/* Caller data that can be used by x86_emulate_ops' routines. */
>> -void *data;
>>  };
>>
>>  /*
>> --
>> 2.1.4


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

Re: [Xen-devel] [RFC PATCH 02/24] ARM: GICv3: allocate LPI pending and property table

[Julien Grall]

Hi Andre,

On 15/11/16 11:32, Andre Przywara wrote:

On 01/11/16 17:22, Julien Grall wrote:

On 28/09/2016 19:24, Andre Przywara wrote:

The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate the required memory, initialize it and hand it over to each
ITS. We limit the number of LPIs we use with a compile time constant to
avoid wasting memory.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Kconfig  |  6 
 xen/arch/arm/efi/efi-boot.h   |  1 -
 xen/arch/arm/gic-its.c| 76
+++
 xen/arch/arm/gic-v3.c | 27 ++
 xen/include/asm-arm/cache.h   |  4 +++
 xen/include/asm-arm/gic-its.h | 22 +++-
 xen/include/asm-arm/gic_v3_defs.h | 48 -
 7 files changed, 181 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 9fe3b8e..66e2bb8 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -50,6 +50,12 @@ config HAS_ITS
 depends on ARM_64
 depends on HAS_GICV3

+config HOST_LPI_BITS
+depends on HAS_ITS
+int "Maximum bits for GICv3 host LPIs (14-32)"
+range 14 32
+default "20"
+


This would be better to be defined as a parameter command line. So the
user does not need to rebuild Xen in order to increase the number of
bits supported. It would also be useful to get a rational behind the
default number in the commit message.


Yeah, a command line option sounds useful, though I have to check
whether this changes compile-time computation into actual runtime one.

The number is made-up, based on some reasoning on the possible memory
consumption and the number of LPIs provided. 8 MB and 1 million LPIs
sounded like a sweet spot.
If I got this correctly, Linux atm doesn't use more than 65536 LPIs.


You know my answer here ;). Linux is not the only guests OS supports on 
Xen, so we should avoid making assumptions on the best behavior based on 
this.


[...]


+
+/*
+ * The pending table holds one bit per LPI, so we need three bits
less
+ * than the number of LPI_BITs. But the alignment requirement
from the
+ * ITS is 64K, so make order at least 16 (-12).
+ */
+pendtable = alloc_xenheap_pages(MAX(lpi_data.host_lpi_bits - 3,
16) - 12, 0);
+if ( !pendtable )
+return 0;
+
+memset(pendtable, 0, BIT(lpi_data.host_lpi_bits - 3));


Same remark for BIT here.


+this_cpu(pending_table) = pendtable;
+
+reg  = attr | GICR_PENDBASER_PTZ;
+reg |= virt_to_maddr(pendtable) & GENMASK(51, 16);


I don't think the mask is useful and would need to be changed if the
physical address bits increased as it was done in ARMv8.2.


Mmmh, not so sure we can extend the mask to cover the region that it
RES0 at the moment. We need some mask anyway (to not clobber the upper
bits), so I figured we just use what the spec says.


The masked PA should always be equal to the PA. Otherwise we would 
program the wrong address into the register and who knows what can 
happen. So this mask is pointless.


[..]


 #endif /* CONFIG_HAS_ITS */

 #endif /* __ASSEMBLY__ */
diff --git a/xen/include/asm-arm/gic_v3_defs.h
b/xen/include/asm-arm/gic_v3_defs.h
index 6bd25a5..da5fb77 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -44,7 +44,8 @@
 #define GICC_SRE_EL2_ENEL1   (1UL << 3)

 /* Additional bits in GICD_TYPER defined by GICv3 */
-#define GICD_TYPE_ID_BITS_SHIFT 19
+#define GICD_TYPE_ID_BITS_SHIFT  19
+#define GICD_TYPE_LPIS   (1U << 17)


I was about to say that this should be named GICD_TYPER... but it looks
like we already defined and use GIC_TYPE_ID_BITS_SHIFTS. So it is up to
you if you rename it to get the correct register name.


Yeah, I was unsure about this as well. My hunch is we should avoid the
churn and keep existing names around. Experience shows that those simple
renames tend to introduce nasty rebase issues, especially with a
long-standing series like this.


Clean up are always welcomed ;). I am fine if it comes after.

Regards,

--
Julien Grall

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

[Xen-devel] [xen-unstable test] 102522: tolerable FAIL - PUSHED

[osstest service owner]

flight 102522 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102522/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-3   65 leak-check/check fail in 102500 pass in 102522
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail pass in 102500
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 102500

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 102465
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102465
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102465
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102465
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102465
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102465
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102465
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102465
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102465
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102465

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f678e2c78110e73431217306bbd33c736802d700
baseline version:
 xen  58bd0c7985890e0292212f94a56235228a3445c3

Last test of basis   102465  2016-11-21 01:58:00 Z2 days
Failing since102489  2016-11-21 17:49:05 Z1 days3 attempts
Testing same since   102500  2016-11-22 03:12:15 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 

Re: [Xen-devel] [PATCH 01/15] x86/hvm: Rename hvm_emulate_init() and hvm_emulate_prepare() for clarity

[Wei Liu]

On Wed, Nov 23, 2016 at 03:38:44PM +, Andrew Cooper wrote:
>  * Move hvm_emulate_init() to immediately hvm_emulate_prepare(), as they are
>very closely related.
>  * Rename hvm_emulate_prepare() to hvm_emulate_init_once() and
>hvm_emulate_init() to hvm_emulate_init_per_insn() to make it clearer how to
>and when to use them.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 
Release-acked-by: Wei Liu 

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