Re: [Xen-devel] [PATCH v7 00/28] Add ITS support

[Vijay Kilari]

On Fri, Sep 18, 2015 at 7:21 PM, Julien Grall  wrote:
> On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K 
>>
>> This is based on DraftG version
>> http://xenbits.xen.org/people/ianc/vits/draftG.pdf
>>
>> Following major features are supported
>>  - GICv3 ITS support for arm64 platform
>>  - Only Dom0 is supported. For DomU pci passthrough feature
>>is required.
>>
>> Changes in v7:
>>
>>  - Rebased to latest staging branch.
>>  - Compiled all the patches individually for both arm32 and arm64
>>  - Patch xen-arm-ITS-implement-hw_irq_controller-for-LPIs.patch
>>split into two patches.
>>   - xen-arm-ITS-implement-hw_irq_controller-for-LPIs.patch and
>>   - xen-arm-ITS-Plumbing-hw_irq_controller-for-LPIs.patch.
>>  - Moved patch xen-arm-ITS-Add-GITS-registers-emulation.patch
>>before vITS compilation.
>>  - Merged xen-arm-ITS-Enable-virtual-ITS-driver.patch with
>>patch xen-arm-ITS-Export-ITS-info-to-Virtual-ITS.patch.
>>  - Dropped patch xen-arm-ITS-Add-32-bit-access-to-GICR_TYPER.patch.
>>This is only minor change. Hence merged with
>>xen-arm-ITS-Add-GICR-register-emulation.patch.
>>  - Dropped patch xen-arm-ITS-Introduce-helper-to-get-number-of-event-.patch
>>  - Dropped gic_lpi_supported helper function.
>>  - Changed LPI property table usage and handling.
>>  - Added support to pass nr_lpis from bootargs.
>>  - Added support to enable/disable its support from bootargs.
>>  - Fixed issues around freeing of its_device on error.
>>  - Introduced vits.h file
>>  - Dropped xen-dt-Handle-correctly-node-with-interrupt-map-in-d.patch
>>from this series as it is already merged.
>>
>>   Could not share code via Github. Network is very slow.
>>   Please, let me know if required.
>
> One of the major reason to provide a branch is to know exactly your
> baseline.
>
> In this case, your baseline is not staging because I'm not able to apply
> cleanly this branch when there was no {,v}gic change at all in the last
> 2 months.
>
> I bet it's staging + my vgic series + some of your modification to this
> series.

  Yes it depends on your vgic series. New branch 'staging_its_v7" is
pushed to github

https://github.com/vijaykilari/its_v6.git

>
> In general, you should mention what is the baseline, if you not staging,
> so people can apply your series to try it and understand the changes.
>
> So please provide a git branch with this series and required patch applied.
>
>> Changes in v6:
>>
>>  - Rebased to latest staging branch.
>>  - Compiled all the patches individually for both arm32 and arm64
>>  - Split the patch "xen/arm: ITS: Allocate irq descriptors for LPIs" into 
>> two.
>>One for allocating LPI irq_desc and other patch for allocating 
>> pending_irq desc
>>for LPIs
>>  - Following new patches are introduced
>>  1) xen/arm: Rename NR_IRQs and vgic_num_irqs helper function
>>  2) xen/arm: ITS: Introduce msi_desc for LPIs
>>  3) xen/arm: Move vgic locking inside get_irq_priority callback
>>  4) xen/arm: ITS: Store LPIs allocated and IRQ ID bits per domain
>>  5) xen/arm: ITS: Introduce helper to get number of event IDs
>>  6) xen/arm: ITS: Add virtual ITS availability check helper
>>  7) xen/arm: ITS: Add 32-bit access to GICR_TYPER)
>>  8) xen/arm: ITS: Allocate pending_lpi descriptors for LPIs
>>
>>  - Based on below patch set
>>  http://lists.xen.org/archives/html/xen-devel/2015-08/msg00168.html
>>
>>  Some Major TODOs:
>>1) Avoid making vits_process_cmd() static in later point of time
>>2) How to handle LPI that does not have LPI config table entry.
>>3) Enable/disable ITS to Dom0
>
> The TODO in the middle of the changelog is a bit strange. Is the current
> TODO list or the one of the previous version?

These are previous version TODOs that are under changes in v6.

>
> I was also expected to see in the TODO  some item mentioned by Ian on
> the previous version [1] such as:
>
>C. The issue regarding what to do with physical LPIs which arrive
> before the guest has mapped the corresponding event in the vits or which
> is masked

yes, I will add this TODO to v7.

>
> Regards,
>
> [1]
> http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg01134.html
>
> --
> Julien Grall

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

[Xen-devel] [PATCH 2/2] xen: arm: traps: correct cond

[Peng Fan]

>From "G6.2.29 CPSR, Current Program Status Register" of Aarch64 ARM
and "B1.3.3 Program Status Registers (PSRs)" of ARMv7-A ARM:
"
IT[7:5] holds the base condition for the IT block. The base condition is
the top 3 bits of the condition code specified by the first
condition field of the IT instruction.
IT[4:0] encodes the size of the IT block, which is the number of
instructions that are to be conditionally executed, by the
position of the least significant 1 in this field. It also
encodes the value of the least significant bit of the condition
code for each instruction in the block.
"

So should be "cond = ( it >> 5 );" but not "cond = ( it >> 4 );"

Signed-off-by: Peng Fan 
Cc: Ian Campbell 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/traps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 2e2b1f2..b2879b7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1561,8 +1561,8 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 if ( it == 0 )
 return 1;
 
-/* The cond for this instruction works out as the top 4 bits. */
-cond = ( it >> 4 );
+/* The cond for this instruction works out as the top 3 bits. */
+cond = ( it >> 5 );
 }
 
 cpsr_cond = cpsr >> 28;
-- 
1.8.4



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

Re: [Xen-devel] Kbuild and Kconfig

[Jan Beulich]

>>> On 18.09.15 at 21:31,  wrote:
> So locally I have in the xen/ (the hypervisor) "make menuconfig" working
> but I'd likely address any concerns you might have upfront in the
> patches. Effectively the xen/ directory now when built runs "make
> defconfig" before it builds to generate the configuration. The default
> configs I've used match what the tree currently contains. However you
> expressed interest in having from the top level certain variables
> controlled from that level like debug. I can pretty easily make it that
> the effective command line is "make debug=y/1/n/0 defconfig" and that
> would set CONFIG_DEBUG appropriately. If that's desired I can also
> include that. Are there other flags that it would be desirable to have
> them controllable from the top level?

First of all I think top level settings should only be used to set values
that currently have no setting at all in .config (or however you intend
to name that file). And then I think all top level setting currently
effectable via make command line option and affecting the hypervisor
build) should be treated the same.

Jan


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

[Xen-devel] [qemu-upstream-4.4-testing test] 62142: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60565
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
60565
 test-amd64-i386-xl-qcow2  9 debian-di-install fail REGR. vs. 60565

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-raw   9 debian-di-install fail REGR. vs. 60565
 test-amd64-i386-libvirt  11 guest-start  fail   like 60565
 test-amd64-amd64-libvirt 11 guest-start  fail   like 60565

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-raw   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  never pass
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0
baseline version:
 qemuu0fc147387f0b683d2dfefec7b1af569f17b72e9c

Last test of basis60565  2015-08-04 01:59:38 Z   48 days
Failing since 61617  2015-09-08 12:10:54 Z   12 days6 attempts
Testing same since62062  2015-09-16 11:15:04 Z4 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  P J P 
  Peter Lieven 
  Stefan Hajnoczi 
  Stefano Stabellini 

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-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt fail
 test-amd64-i386-libvirt  fail
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair fail
 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-libvirt-qcow2   pass
 test-amd64-i386-libvirt-qcow2fail
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-qcow2 fail
 test-amd64-amd64-libvirt-raw pass
 test-amd64-i386-libvirt-raw  fail
 test-amd64-amd64-xl-raw  fail
 

Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Daney, David]

I apologize for the top post, but for the record;

The Thunder Linux implementation will be obtaining the PCI requester id from 
the OF device tree, or ACPI IORT table.  It will *not* be derived from any 
hardware address.

It may make sense to use the same technique to get the PCI requester id in the 
XEN environment too.

David Daney.

From: Julien Grall 
Sent: Saturday, September 19, 2015 1:48:43 PM
To: Jaggi, Manish; Jaggi, Manish; Xen Devel
Cc: Konrad Rzeszutek Wilk; ★ Stefano Stabellini; Ian Campbell; Daney, David; 
prasun.kap...@cavium.com; Kumar, Vijaya
Subject: Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

Hi Manish,

On 19/09/2015 21:24, Manish Jaggi wrote:
> On Wednesday 16 September 2015 06:28 PM, Julien Grall wrote:
>> On 15/09/15 19:58, Jaggi, Manish wrote:
 I can see 2 different solutions:
  1) Let DOM0 pass the first requester ID when registering the bus
 Pros:
  * Less per-platform code in Xen
 Cons:
  * Assume that the requester ID are contiguous. (Is it really a
 cons?)
  * Still require quirk for buggy device (i.e requester ID not
 correct)
  2) Do it in Xen
 Pros:
  * We are not relying on DOM0 giving the requester ID
  => Not assuming contiguous requester ID
  Cons:
  * Per PCI bridge code to handle the mapping

>>>We can have (3) that when PHYSDEVOP_pci_add_device is called the sbdf
>>> and requesterID both are passed in hypercall.
>> The name of the physdev operation is PHYSDEVOP_pci_device_add and not
>> PHYSDEVOP_pci_add_device. Please rename it all the usage in the design
>> doc.
>>
>> Although, we can't modify PHYSDEVOP_pci_device_add because it's part of
>> the ABI which is stable.
>>
>> Based on David's mail, the requester ID of a given device can be found
>> using base + devfn where base is the first requesterID of the bus.
>>
>> IIRC, this is also match the IORT ACPI spec.
>>
>> So for now, I would extend the physdev you've introduced to add an host
>> bridge (PHYSDEV_pci_host_bridge_add) to pass the base requesterID.
> The requester-ID is derived from the Node# and ECAM# as per David. I
> guess the ECAM and Node# can be derived from
> the cfg_addr.

There is no place for "I guess". Any approximation here would lead to
add more hypercalls because we design the first one on speculation.

> Each Ecam has a cfg_addr in Thunder, which is mentioned in the pci node
> in device tree.

IIUC what you said, you suggest to retrieve the ECAM based on the
cfg_addr in Xen, right?

If so, this is the wrong way to go we should avoid to have platform
specific code in Xen as much as possible and get everything either via
the firmware table (ACPI or DT) or via hypercall.

> For thunder I think we don't need to pass requester-ID in the phydevop.

May I remind you that this design doc is not about Thunder-X but PCI
passthrough in general. If your platform already requires specific code
in Xen to get the requester ID, what prevents other to not do the same?

So it looks like to me that adding the base requester-ID in the
PHYSDEVOP_pci_host_bridge_add is the right way to go.

Regards,

--
Julien Grall

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

[Xen-devel] [PATCH 1/2] xen: arm: traps: check hsr.ec for ARM32

[Peng Fan]

To ARM64, "if ( hsr.ec >= 0x10 ) return 1;" is ok for unconditional
check, but to ARM32, we need to use 'hsr.ec >> 30' to check.

Signed-off-by: Peng Fan 
Cc: Ian Campbell 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/traps.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9d2bd6a..2e2b1f2 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1531,8 +1531,13 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 int cond;
 
 /* Unconditional Exception classes */
+#ifdef CONFIG_ARM_64
 if ( hsr.ec >= 0x10 )
 return 1;
+#else
+if ( hsr.ec >> 30 )
+return 1;
+#endif
 
 /* Check for valid condition in hsr */
 cond = hsr.cond.ccvalid ? hsr.cond.cc : -1;
-- 
1.8.4



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

[Xen-devel] libxen-light

[kumara rathnavel]

Hello,

I do not find any proper documentation regarding API provided by the
Libxenlight. All I find is the documentation for the xl that in turn uses
Libxl Library. But I would like to use the library calls directly, I am
able to basic operations like listing vm, reboot and all those . But when
it comes to creation of domain or attaching device , I am filling the
structures the same way as xl is doing. But I get a Seg Fault. Can you
share some documentation on the Libxenlight API if possible or guidance
would do,,.

Thank you,
Kumar,...
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.10 test] 62141: regressions - FAIL

[osstest service owner]

flight 62141 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62141/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-vhd   9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-i386-freebsd10-amd64 14 guest-localmigrate fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-i386-qemuu-rhel6hvm-intel 10 guest-stopfail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 60670
 test-amd64-i386-qemut-rhel6hvm-intel 12 guest-start/redhat.repeat fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail REGR. vs. 
60670
 test-amd64-i386-xl-qcow2  9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install  fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-i386-xl-vhd   10 guest-start  fail in 61983 REGR. vs. 60670
 test-amd64-i386-xl-qemuu-ovmf-amd64 12 guest-saverestore fail in 61983 REGR. 
vs. 60670
 test-amd64-i386-qemuu-rhel6hvm-amd 11 guest-start.2 fail in 61983 REGR. vs. 
60670
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail in 
61983 REGR. vs. 60670
 test-amd64-i386-xl-qemuu-debianhvm-amd64 14 guest-saverestore.2 fail in 61983 
REGR. vs. 60670
 test-amd64-i386-freebsd10-i386 14 guest-localmigrate fail in 62060 REGR. vs. 
60670
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-saverestore.2 fail in 62060 
REGR. vs. 60670

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 13 guest-saverestore fail in 61983 pass in 
62141
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore  fail in 61983 pass in 62141
 test-amd64-i386-libvirt 15 guest-saverestore.2 fail in 61983 pass in 62141
 test-amd64-i386-qemut-rhel6hvm-intel 10 guest-stop fail in 61983 pass in 62141
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 61983 
pass in 62141
 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail in 61983 pass in 62141
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
in 61983 pass in 62141
 test-amd64-i386-libvirt-raw   9 debian-di-install  fail in 61983 pass in 62141
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 guest-saverestore fail in 62060 
pass in 61983
 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-install fail in 62060 pass in 
62141
 test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail in 62060 pass in 62141
 test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail in 62060 pass in 
62141
 test-amd64-i386-xl-qemut-debianhvm-amd64 12 guest-saverestore fail in 62060 
pass in 62141
 test-amd64-i386-xl-vhd9 debian-di-install   fail pass in 61983
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install   fail pass in 61983
 test-amd64-i386-qemuu-rhel6hvm-amd 10 guest-stopfail pass in 61983
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 
61983
 test-amd64-i386-libvirt-qcow2  9 debian-di-install  fail pass in 61983
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 61983
 test-amd64-i386-libvirt-vhd   9 debian-di-install   fail pass in 61983
 test-amd64-i386-freebsd10-i386 13 guest-saverestore fail pass in 62060
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
62060
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-install fail pass in 62060

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-raw  9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-libvirt-qcow2  9 

Re: [Xen-devel] [PATCH] xen-blkback: free requests on disconnection

[Julien Grall]

Hi Konrad,

On 09/09/2015 16:02, Konrad Rzeszutek Wilk wrote:

Konrad, would you like me to resend the patch with the modified commit
message, or do you plan to amend it yourself while committing?


I will amend it. Thanks!


What the status for this patch?

Regards,

--
Julien Grall

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

[Xen-devel] [xen-unstable test] 62156: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 61627

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-qcow2  5 xen-install fail REGR. vs. 61627
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 61627
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 61627
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 61627

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-xsm 14 guest-saverestorefail   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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 xen  4600d7560425f89b32cd90ecf6084bae9293dfab
baseline version:
 xen  a7b39c8bd6cba3fe1c8012987b9e28bdbac7e92d

Last test of basis61627  2015-09-08 14:33:27 Z   13 days
Failing since 61739  2015-09-10 06:45:52 Z   11 days5 attempts
Testing same since62156  2015-09-19 05:43:02 Z2 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Chris Brand 
  Christoph Egger 
  Chunyan Liu 
  Daniel De Graaf 
  Daniel Kiper 
  David Vrabel 
  George Dunlap 
  Hanjun Guo 
  Haozhong Zhang 
  Ian Campbell 
  Ian Jackson 
  Jan 

[Xen-devel] [qemu-mainline bisection] complete test-armhf-armhf-xl-raw

[osstest service owner]

branch xen-unstable
xen branch xen-unstable
job test-armhf-armhf-xl-raw
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  a2aa09e18186801931763fbd40a751fa39971b18
  Bug not present: 7e4804dafd4689312ef1172b549927a973bb5414


  commit a2aa09e18186801931763fbd40a751fa39971b18
  Merge: 7e4804d 47d4be1
  Author: Peter Maydell 
  Date:   Mon Sep 14 16:13:16 2015 +0100

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
staging

  * Support for jemalloc
  * qemu_mutex_lock_iothread "No such process" fix
  * cutils: qemu_strto* wrappers
  * iohandler.c simplification
  * Many other fixes and misc patches.

  And some MTTCG work (with Emilio's fixes squashed):
  * Signal-free TCG kick
  * Removing spinlock in favor of QemuMutex
  * User-mode emulation multi-threading fixes/docs

  # gpg: Signature made Thu 10 Sep 2015 09:03:07 BST using RSA key ID 
78C7AE83
  # gpg: Good signature from "Paolo Bonzini "
  # gpg: aka "Paolo Bonzini "

  * remotes/bonzini/tags/for-upstream: (44 commits)
cutils: work around platform differences in strto{l,ul,ll,ull}
cpu-exec: fix lock hierarchy for user-mode emulation
exec: make mmap_lock/mmap_unlock globally available
tcg: comment on which functions have to be called with mmap_lock held
tcg: add memory barriers in page_find_alloc accesses
remove unused spinlock.
replace spinlock by QemuMutex.
cpus: remove tcg_halt_cond and tcg_cpu_thread globals
cpus: protect work list with work_mutex
scripts/dump-guest-memory.py: fix after RAMBlock change
configure: Add support for jemalloc
add macro file for coccinelle
configure: factor out adding disas configure
vhost-scsi: fix wrong vhost-scsi firmware path
checkpatch: remove tests that are not relevant outside the kernel
checkpatch: adapt some tests to QEMU
CODING_STYLE: update mixed declaration rules
qmp: Add example usage of strto*l() qemu wrapper
cutils: Add qemu_strtoull() wrapper
cutils: Add qemu_strtoll() wrapper
...

  Signed-off-by: Peter Maydell 

  commit 47d4be12c3997343e436c6cca89aefbbbeb70863
  Author: Paolo Bonzini 
  Date:   Thu Sep 10 10:02:00 2015 +0200

  cutils: work around platform differences in strto{l,ul,ll,ull}

  Linux returns 0 if no conversion was made, while OS X and presumably
  the BSDs return EINVAL.  The OS X convention rejects more invalid
  inputs, so convert to it and adjust the test case.

  Windows returns 1 from strtoul and strtoull (instead of -1) for
  negative out-of-range input; fix it up.

  Reported-by: Peter Maydell 
  Signed-off-by: Paolo Bonzini 

  commit 9fd1a94888cd6a559f95c3596ec1ac28b74838c1
  Author: Paolo Bonzini 
  Date:   Tue Aug 11 11:33:24 2015 +0200

  cpu-exec: fix lock hierarchy for user-mode emulation

  tb_lock has to be taken inside the mmap_lock (example:
  tb_invalidate_phys_range is called by target_mmap), but
  tb_link_page is taking the mmap_lock and it is called
  with the tb_lock held.

  To fix this, take the mmap_lock in tb_find_slow, not
  in tb_link_page.

  Reviewed-by: Peter Maydell 
  Signed-off-by: Paolo Bonzini 

  commit 8fd19e6cfd5b6cdf028c6ac2ff4157ed831ea3a6
  Author: Paolo Bonzini 
  Date:   Tue Aug 11 10:57:52 2015 +0200

  exec: make mmap_lock/mmap_unlock globally available

  There is some iffy lock hierarchy going on in translate-all.c.  To
  fix it, we need to take the mmap_lock in cpu-exec.c.  Make the
  functions globally available.

  Reviewed-by: Peter Maydell 
  Signed-off-by: Paolo Bonzini 

  commit 756920876f60829fad0d15df4f3fa205077a8131
  Author: Paolo Bonzini 
  Date:   Tue Aug 11 10:59:50 2015 +0200

  tcg: comment on which functions have to be called with mmap_lock held

  Reviewed-by: Peter Maydell 
  Signed-off-by: Paolo Bonzini 

  commit 6940fab84b826175cf90d48d0e3da1b76518f5b4
  Author: Paolo Bonzini 
  Date:   Wed Aug 12 09:41:40 2015 +0200

  tcg: add memory barriers in page_find_alloc accesses

  page_find is reading the radix tree outside all locks, so it has to
  use the RCU primitives.  It does not need 

[Xen-devel] [linux-3.14 test] 62161: regressions - FAIL

[osstest service owner]

flight 62161 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62161/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qcow2 13 guest-saverestore fail REGR. vs. 60666
 test-amd64-i386-xl-vhd   13 guest-saverestore fail REGR. vs. 60666
 test-amd64-amd64-xl-vhd  13 guest-saverestore fail REGR. vs. 60666
 test-amd64-amd64-xl-qcow219 guest-start.2fail in 62012 REGR. vs. 60666

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 62012 
pass in 62161
 test-amd64-i386-libvirt 18 guest-start/debian.repeat fail in 62012 pass in 
62161
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 62012 
pass in 62161
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail in 62012 pass in 62161
 test-amd64-i386-libvirt-vhd   9 debian-di-install  fail in 62012 pass in 62161
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail in 62012 pass 
in 62161
 test-amd64-amd64-xl-qcow213 guest-saverestore  fail in 62085 pass in 62012
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 62085 pass in 62161
 test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail in 62085 pass in 
62161
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat 
fail in 62085 pass in 62161
 test-amd64-i386-libvirt-raw  17 guest-start/debian.repeat   fail pass in 62012
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 62085
 test-amd64-amd64-xl-qcow210 guest-start fail pass in 62085
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail pass in 62085
 test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail pass in 62085

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-qcow2 13 guest-saverestore   fail REGR. vs. 60666
 test-amd64-i386-libvirt-vhd  13 guest-saverestore fail REGR. vs. 60666
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 60666
 test-amd64-i386-libvirt-qcow2 13 guest-saverestorefail REGR. vs. 60666
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 62012 like 60666
 test-armhf-armhf-xl   6 xen-boot fail   like 60666
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 60666
 test-armhf-armhf-libvirt  6 xen-boot fail   like 60666
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 60666
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 60666
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60666
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 60666
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 60666

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-vhd  6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-armhf-armhf-xl-raw   6 xen-boot fail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl-xsm   6 xen-boot fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 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-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop 

[Xen-devel] [linux-3.16 baseline-only test] 37997: regressions - trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 37997 linux-3.16 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37997/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 37985
 test-amd64-amd64-xl-qemut-win7-amd64  3 host-install(3) broken REGR. vs. 37985
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 37985
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 37985

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-credit2  18 guest-localmigrate/x10   fail   like 37985

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-multivcpu 18 guest-localmigrate/x10   fail  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  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-raw  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-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 linux76aee4f56fe6a10b449327f83989474be1d8224c
baseline version:
 linux72388a1322d01750228f7852c80c7f9547bd63a8

Last test of basis37985  2015-09-18 16:49:39 Z3 days
Testing same since37997  2015-09-20 17:26:42 Z1 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Al Viro 
  Alan Stern 
  Alex Deucher 
  Alexander Drozdov 
  Alexei Potashnik 

Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[Juergen Gross]

On 09/21/2015 07:49 AM, Juergen Gross wrote:

On 09/15/2015 06:50 PM, Dario Faggioli wrote:

On Thu, 2015-08-20 at 20:16 +0200, Juergen Groß wrote:

On 08/18/2015 05:55 PM, Dario Faggioli wrote:

Hey everyone,

So, as a followup of what we were discussing in this thread:

   [Xen-devel] PV-vNUMA issue: topology is misinterpreted by the guest

http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03241.html


I started looking in more details at scheduling domains in the Linux
kernel. Now, that thread was about CPUID and vNUMA, and their weird way
of interacting, while this thing I'm proposing here is completely
independent from them both.

In fact, no matter whether vNUMA is supported and enabled, and no
matter
whether CPUID is reporting accurate, random, meaningful or completely
misleading information, I think that we should do something about how
scheduling domains are build.

Fact is, unless we use 1:1, and immutable (across all the guest
lifetime) pinning, scheduling domains should not be constructed, in
Linux, by looking at *any* topology information, because that just does
not make any sense, when vcpus move around.

Let me state this again (hoping to make myself as clear as
possible): no
matter in  how much good shape we put CPUID support, no matter how
beautifully and consistently that will interact with both vNUMA,
licensing requirements and whatever else. It will be always possible
for
vCPU #0 and vCPU #3 to be scheduled on two SMT threads at time t1, and
on two different NUMA nodes at time t2. Hence, the Linux scheduler
should really not skew his load balancing logic toward any of those two
situations, as neither of them could be considered correct (since
nothing is!).

For now, this only covers the PV case. HVM case shouldn't be any
different, but I haven't looked at how to make the same thing happen in
there as well.

OVERALL DESCRIPTION
===
What this RFC patch does is, in the Xen PV case, configure scheduling
domains in such a way that there is only one of them, spanning all the
pCPUs of the guest.

Note that the patch deals directly with scheduling domains, and
there is
no need to alter the masks that will then be used for building and
reporting the topology (via CPUID, /proc/cpuinfo, /sysfs, etc.).
That is
the main difference between it and the patch proposed by Juergen here:
http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg05088.html


This means that when, in future, we will fix CPUID handling and make it
comply with whatever logic or requirements we want, that won't have
any
unexpected side effects on scheduling domains.

Information about how the scheduling domains are being constructed
during boot are available in `dmesg', if the kernel is booted with the
'sched_debug' parameter. It is also possible to look
at /proc/sys/kernel/sched_domain/cpu*, and at /proc/schedstat.

With the patch applied, only one scheduling domain is created, called
the 'VCPU' domain, spanning all the guest's (or Dom0's) vCPUs. You can
tell that from the fact that every cpu* folder
in /proc/sys/kernel/sched_domain/ only have one subdirectory
('domain0'), with all the tweaks and the tunables for our scheduling
domain.

EVALUATION
==
I've tested this with UnixBench, and by looking at Xen build time, on a
16, 24 and 48 pCPUs hosts. I've run the benchmarks in Dom0 only, for
now, but I plan to re-run them in DomUs soon (Juergen may be doing
something similar to this in DomU already, AFAUI).

I've run the benchmarks with and without the patch applied ('patched'
and 'vanilla', respectively, in the tables below), and with different
number of build jobs (in case of the Xen build) or of parallel copy of
the benchmarks (in the case of UnixBench).

What I get from the numbers is that the patch almost always brings
benefits, in some cases even huge ones. There are a couple of cases
where we regress, but always only slightly so, especially if comparing
that to the magnitude of some of the improvement that we get.

Bear also in mind that these results are gathered from Dom0, and
without
any overcommitment at the vCPU level (i.e., nr. vCPUs == nr pCPUs). If
we move things in DomU and do overcommit at the Xen scheduler level, I
am expecting even better results.


...

REQUEST FOR COMMENTS

Basically, the kind of feedback I'd be really glad to hear is:
   - what you guys thing of the approach,


Yesterday at the end of the developer meeting we (Andrew, Elena and
myself) discussed this topic again.


Hey,

Sorry for replying so late, I've been on vacation from right after
XenSummit up until yesterday. :-)


Regarding a possible future scenario with credit2 eventually supporting
gang scheduling on hyperthreads (which is desirable due to security
reasons [side channel attack] and fairness) my patch seems to be more
suited for that direction than yours.


Ok. Just let me mention that 'Credit2 + gang scheduling' might not be
exactly around the corner (although, we can 

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Monday, September 21, 2015 10:12 PM
> To: Wu, Feng; George Dunlap
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On Mon, 2015-09-21 at 13:50 +, Wu, Feng wrote:
> >
> > > -Original Message-
> > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> 
> > > Note that, in case of preemptions, we are switching from a non-idle
> > > vcpu to another, non-idle, vcpu, so lazy context switching to the
> > > idle
> > > vcpu should not have much to do with this case...
> >
> > So do you mean in preemptions, we cannot switch from non-idle to idle
> > or
> > Idle to non-idle, i.e, we can only switch from non-idle to non-idle?
> >
> That's what I meant. It's the definition of 'preemption' and of 'idle
> task/vcpu', AFICT. I mean, the idle vcpu has the lowest possible
> priority ever, so it can't really preempt anyone.
> 
> OTOH, if the idle vcpu is running, that means there weren't any active
> vcpus because, e.g., all were blocked; therefore, any active vcpu
> wanting to run would have to wake up (and hence go throught the proper
> wake up logic) before trying to preempt idle.
> 
> There is one possible caveat: tasklets. In fact (as you can check
> yourself by looking, in the code, for tasklet_work_scheduled), it is
> possible that we force the idle vcpu to execute, even when we have
> active and runnable vcpus, to let it process tasklets. I'm not really
> sure whether this could be a problem for you or not, can you have a
> look (and/or, a try) and report back?

Thanks for your information about the tasklets part, it is very important,
consider the following scenario:

non-idle vCPUA --> idle (tasklet) --> non-idle vCPUA

The above context switch will use the lazy context switch and cannot be
covered in __context_switch(), we need to change SN's state during the
"non-idle to idle" and "idle to non-idle" transition, so that means we need
add the PI related logic in context_switch() instead of only in 
__context_switch().

Besides that, it is more robust to do the PI switch in context_switch() which
can cover lazy context switch. Maybe in future, there are some other
feature needing execute task _inside_ an idle context, and it may introduce
some issues due to no PI state transition, and it is a little hard to debug.

Thanks,
Feng

> 
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

[Xen-devel] [PATCH V2 1/2] xen, libxc: Fine grained control of REP emulation optimizations

[Razvan Cojocaru]

Previously, if vm_event emulation support was enabled, then REP
optimizations were disabled when emulating REP-compatible
instructions. This patch allows fine-tuning of this behaviour by
providing a dedicated libxc helper function.

Signed-off-by: Razvan Cojocaru 

---
Changes since V1:
 - Renamed the patch, since this is now a xc_monitor_ function,
   so XEN_DOMCTL_emulate_each_rep no longer applies.
 - As suggested by Andrew Cooper, the function is a no-op unless
   mem_access emulation is enabled.
---
 tools/libxc/include/xenctrl.h |   12 
 tools/libxc/xc_monitor.c  |   13 +
 xen/arch/x86/hvm/emulate.c|3 ++-
 xen/arch/x86/monitor.c|6 ++
 xen/include/asm-x86/domain.h  |1 +
 xen/include/public/domctl.h   |1 +
 6 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3482544..3bfa00b 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2428,6 +2428,18 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
  bool enable, bool sync);
 
+/**
+ * This function enables / disables emulation for each REP for a
+ * REP-compatible instruction.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domain_id the domain id one wants to get the node affinity of.
+ * @parm enable if 0 optimize when possible, else emulate each REP.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t domain_id,
+bool enable);
+
 /***
  * Memory sharing operations.
  *
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 065669c..b1705dd 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -143,3 +143,16 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id, bool enable,
 
 return do_domctl(xch, );
 }
+
+int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t domain_id,
+bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP;
+domctl.u.monitor_op.event = enable;
+
+return do_domctl(xch, );
+}
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 5934c72..c39a883 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -514,7 +514,8 @@ static int hvmemul_virtual_to_linear(
  * being triggered for repeated writes to a whole page.
  */
 *reps = min_t(unsigned long, *reps,
-  unlikely(current->domain->arch.mem_access_emulate_enabled)
+  unlikely(current->domain->arch.mem_access_emulate_enabled &&
+   current->domain->arch.mem_access_emulate_each_rep)
? 1 : 4096);
 
 reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 3d52135..3cb7519 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -79,6 +79,12 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 return 0;
 }
 
+if ( mop->op == XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP )
+{
+d->arch.mem_access_emulate_each_rep = !!mop->event;
+return 0;
+}
+
 /*
  * Sanity check
  */
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 59cf826..a088110 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -386,6 +386,7 @@ struct arch_domain
 
 /* Mem_access emulation control */
 bool_t mem_access_emulate_enabled;
+bool_t mem_access_emulate_each_rep;
 } __cacheline_aligned;
 
 #define has_arch_pdevs(d)(!list_empty(&(d)->arch.pdev_list))
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 794d4d5..ae241f2 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1007,6 +1007,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
 #define XEN_DOMCTL_MONITOR_OP_ENABLE0
 #define XEN_DOMCTL_MONITOR_OP_DISABLE   1
 #define XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES  2
+#define XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP  3
 
 #define XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG 0
 #define XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR1
-- 
1.7.9.5


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

[Xen-devel] [PATCH V2 0/2] Introspection optimization helpers

[Razvan Cojocaru]

Hello,

This series adds two minor patches. The first one allows finer-grained
control over the emulation behaviour of REP instructions. Previously,
once vm_event-based emulation was enabled, no optimizations were allowed.
However, this has a performance impact on the monitored guest, so I've
added a new libxc function to enable / disable this at will at any point.

The second patch addresses an older issue: in my initial series a few
years back, there was a (longish) patch that computed the length of the
current instruction, and advanced the instruction pointer past it if
it was required by the vm_event reply. However, integrating that code
has not been trivial, and so the second patch in this series simply
allows a vm_event reply to say that the instruction pointer should be
set to whatever value it sends back to the hypervisor. This way, the
computation of the instruction length is left to the userspace
application.

This new version addresses the comments received for V1: the first
patch retires xc_domain_emulate_each_rep() in favour of
xc_monitor_emulate_each_rep(), and the second patch now follows
Tamas' suggestion to replace SET_EIP with SET_REGISTERS and allow
any vm_event reply to set the guest registers (though this currently
only applies to EIP).

[PATCH V2 1/2] xen, libxc: Fine grained control of REP emulation
[PATCH V2 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Dario Faggioli]

On Mon, 2015-09-21 at 11:59 +, Wu, Feng wrote:
> 
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]

> > > I think the handling for lazy context switch is not only for the
> > > blocking case,
> > > we still need to do something for lazy context switch even we
> > > handled the
> > > blocking case in vcpu_block(), such as,
> > > 1. For non-idle -> idle
> > > - set 'SN'
> > 
> > If we set SN in vcpu_block(), then we don't need to set it on
> > context
> > switch -- 是不是？
> 
> For preemption case (not blocking case) , we still need to clear/set
> SN, and
> this has no business with vcpu_block()/vcpu_wake(), right? Do I miss
> something
> here? BTW, you Chinese is good! :)
> 
Well, sure, preemptions are fine being dealt with during context
switches.

AFAICR, Geoge was suggesting investigating the possibility of doing
that within the already existing arch specific part of the context
switch itself. Have you checked whether that would be possible? If yes,
it really would be great, IMO.

Note that, in case of preemptions, we are switching from a non-idle
vcpu to another, non-idle, vcpu, so lazy context switching to the idle
vcpu should not have much to do with this case... Was this something
you were saying something/asking about above? (seems so, but I can't be
sure, so I thought I better ask :-) ).

Regards,
Dario

-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH V2 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Razvan Cojocaru]

A previous version of this patch dealing with support for skipping
the current instruction when a vm_event response requested it
computed the instruction length in the hypervisor, adding non-trivial
code dependencies. This patch allows a userspace vm_event client to
simply request that the guest's EIP is set to an arbitary value,
computed by the introspection application. In the future, other
registers can also be set via a vm_event reply by using this flag.
The VCPU needs to be paused for this flag to take effect.

Signed-off-by: Razvan Cojocaru 

---
Changes since V1:
 - Renamed the patch (VM_EVENT_FLAG_SET_EIP ->
   VM_EVENT_FLAG_SET_REGISTERS).
 - As suggested by Tamas Lengyel, EIP is now being set via a dedicated
   generic vm_event_set_registers() function that can be extended to
   set other registers in the future.
---
 xen/arch/x86/vm_event.c|5 +
 xen/common/vm_event.c  |3 +++
 xen/include/asm-arm/vm_event.h |6 ++
 xen/include/asm-x86/vm_event.h |2 ++
 xen/include/public/vm_event.h  |6 ++
 5 files changed, 22 insertions(+)

diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index e4e0aa4..a59ba79 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -95,6 +95,11 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
 }
 }
 
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
+{
+v->arch.user_regs.eip = rsp->data.regs.x86.rip;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index ef84b0f..e1f9580 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -417,6 +417,9 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
 
 if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
 {
+if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
+vm_event_set_registers(v, );
+
 if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
 vm_event_toggle_singlestep(d, v);
 
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 976fdf1..4d0fbf7 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -47,4 +47,10 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
 /* Not supported on ARM. */
 }
 
+static inline
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
+{
+/* Not supported on ARM. */
+}
+
 #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 2ff2cab..5aff834 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -42,4 +42,6 @@ void vm_event_toggle_singlestep(struct domain *d, struct vcpu 
*v);
 
 void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp);
 
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
+
 #endif /* __ASM_X86_VM_EVENT_H__ */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index ff2f217..51539af 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -89,6 +89,12 @@
  * by the altp2m_idx response field if possible.
  */
 #define VM_EVENT_FLAG_ALTERNATE_P2M  (1 << 7)
+/*
+ * Set the vCPU registers to the values in the  vm_event response.
+ * Currently only applies to EIP.
+ * Requires the vCPU to be paused already (synchronous events only).
+ */
+#define VM_EVENT_FLAG_SET_REGISTERS  (1 << 8)
 
 /*
  * Reasons for the vm event request
-- 
1.7.9.5


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

Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Julien Grall]

Hi David,

On 19/09/15 22:51, Daney, David wrote:
> I apologize for the top post, but for the record;
> 
> The Thunder Linux implementation will be obtaining the PCI requester id from 
> the OF device tree, or ACPI IORT table.  It will *not* be derived from any 
> hardware address.

I'm aware about the ACPI IORT table but haven't see anything around a
device tree bindings for the requester ID.

Do you have a link/draft explaining this binding?

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.6] INSTALL: Mention MINIOS_UPSTREAM_URL

[Ian Campbell]

On Thu, 2015-09-17 at 17:32 +0100, Wei Liu wrote:
> On Thu, Sep 17, 2015 at 05:30:50PM +0100, Ian Campbell wrote:
> > All the other ones seem to be there.
> > 
> > Signed-off-by: Ian Campbell 
> > ---
> > For 4.6: trivially
> 
> Documentation update is safe to go in.
> 
> Release-acked-by: Wei Liu 

Since this is such a trivial patch I assumed this included an effective
Acked-by as well and applied to both branches. I hope that was OK.


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

Re: [Xen-devel] [PATCH 1/2] docs: Template for feature documents

[Ian Campbell]

On Tue, 2015-09-15 at 14:54 +0100, Andrew Cooper wrote:
> +# Basics
> +
> +A table with an overview of the support status and applicability.
> +
> + 
> + Status: e.g. **Supported**/**Tech Preview**/**Experimental**

My main concern is still the lack of a precise meaning for these terms.
However this is not a problem with this series per-se and we can always
update the template once we know what they mean.

So I've acked and applied both patches to staging and staging-4.6.


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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Monday, September 21, 2015 5:19 PM
> To: Wu, Feng; Dario Faggioli
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On 09/21/2015 06:08 AM, Wu, Feng wrote:
> >
> >
> >> -Original Message-
> >> From: George Dunlap [mailto:george.dun...@citrix.com]
> >> Sent: Thursday, September 17, 2015 5:38 PM
> >> To: Dario Faggioli; Wu, Feng
> >> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap;
> Andrew
> >> Cooper; Jan Beulich
> >> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> >> handling
> >>
> >> On 09/17/2015 09:48 AM, Dario Faggioli wrote:
> >>> On Thu, 2015-09-17 at 08:00 +, Wu, Feng wrote:
> >>>
> > -Original Message-
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> >>>
> > So, I guess, first of all, can you confirm whether or not it's exploding
> > in debug builds?
> 
>  Does the following information in Config.mk mean it is a debug build?
> 
>  # A debug build of Xen and tools?
>  debug ?= y
>  debug_symbols ?= $(debug)
> 
> >>> I think so. But as I said in my other email, I was wrong, and this is
> >>> probably not an issue.
> >>>
> > And in either case (just tossing out ideas) would it be
> > possible to deal with the "interrupt already raised when blocking" case:
> 
>  Thanks for the suggestions below!
> 
> >>> :-)
> >>>
> >  - later in the context switching function ?
>  In this case, we might need to set a flag in vmx_pre_ctx_switch_pi()
> instead
>  of calling vcpu_unblock() directly, then when it returns to
> context_switch(),
>  we can check the flag and don't really block the vCPU.
> 
> >>> Yeah, and that would still be rather hard to understand and maintain,
> >>> IMO.
> >>>
>  But I don't have a clear
>  picture about how to archive this, here are some questions from me:
>  - When we are in context_switch(), we have done the following changes to
>  vcpu's state:
>   * sd->curr is set to next
>   * vCPU's running state (both prev and next ) is changed by
> vcpu_runstate_change()
>   * next->is_running is set to 1
>   * periodic timer for prev is stopped
>   * periodic timer for next is setup
>   ..
> 
>  So what point should we perform the action to _unblock_ the vCPU? We
>  Need to roll back the formal changes to the vCPU's state, right?
> 
> >>> Mmm... not really. Not blocking prev does not mean that prev would be
> >>> kept running on the pCPU, and that's true for your current solution as
> >>> well! As you say yourself, you're already in the process of switching
> >>> between prev and next, at a point where it's already a thing that next
> >>> will be the vCPU that will run. Not blocking means that prev is
> >>> reinserted to the runqueue, and a new invocation to the scheduler is
> >>> (potentially) queued as well (via raising SCHEDULE_SOFTIRQ, in
> >>> __runq_tickle()), but it's only when such new scheduling happens that
> >>> prev will (potentially) be selected to run again.
> >>>
> >>> So, no, unless I'm fully missing your point, there wouldn't be no
> >>> rollback required. However, I still would like the other solution (doing
> >>> stuff in vcpu_block()) better (see below).
> >>>
> >  - with another hook, perhaps in vcpu_block() ?
> 
>  We could check this in vcpu_block(), however, the logic here is that 
>  before
>  vCPU is blocked, we need to change the posted-interrupt descriptor,
>  and during changing it, if 'ON' bit is set, which means VT-d hardware
>  issues a notification event because interrupts from the assigned devices
>  is coming, we don't need to block the vCPU and hence no need to update
>  the PI descriptor in this case.
> 
> >>> Yep, I saw that. But could it be possible to do *everything* related to
> >>> blocking, including the update of the descriptor, in vcpu_block(), if no
> >>> interrupt have been raised yet at that time? I mean, would you, if
> >>> updating the descriptor in there, still get the event that allows you to
> >>> call vcpu_wake(), and hence vmx_vcpu_wake_prepare(), which would undo
> >>> the blocking, no matter whether that resulted in an actual context
> >>> switch already or not?
> >>>
> >>> I appreciate that this narrows the window for such an event to happen by
> >>> quite a bit, making the logic itself a little less useful (it makes
> >>> things more similar to "regular" blocking vs. event delivery, though,
> >>> AFAICT), but if it's correct, ad if it allows us to save the ugly
> >>> invocation of vcpu_unblock from context switch context, I'd give it a
> >>> try.
> >>>
> >>> After all, this PI thing requires actions to be taken 

[Xen-devel] [PATCH] xen/x86: Don't try to write syscall-related MSRs for PV guests

[Boris Ostrovsky]

For PV guests these registers are set up by hypervisor and thus
should not be written by the guest. The comment in xen_write_msr_safe()
says so but we still write the MSRs, causing the hypervisor to
print a warning.

Signed-off-by: Boris Ostrovsky 
---
 arch/x86/xen/enlighten.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 30d12af..1f1dbd2 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1077,6 +1077,7 @@ static int xen_write_msr_safe(unsigned int msr, unsigned 
low, unsigned high)
/* Fast syscall setup is all done in hypercalls, so
   these are all ignored.  Stub them out here to stop
   Xen console noise. */
+   break;
 
default:
if (!pmu_msr_write(msr, low, high, ))
-- 
2.1.0


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

Re: [Xen-devel] [PATCH v5 7/9] x86/intel_pstate: add a booting param to select the driver to load

[Jan Beulich]

>>> On 17.09.15 at 18:08,  wrote:
> We shouldn't have multiple different top level command line options.  In
> particular, having "mwait-idle" and "intel_pstate" seems wrong, given a
> perfectly good "cpufreq=" option.

"mwait-idle" is C-state related.

Jan


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

Re: [Xen-devel] [PATCH] xen/x86: Record xsave features in c->x86_capabilities

[Andrew Cooper]

On 21/09/15 14:04, Jan Beulich wrote:

On 17.09.15 at 13:40,  wrote:

Jan: I have opted for adding leaf 8 rather than reusing leaf 2, due to the
uncertainty with how this information is exposed in libxl.  This patch
introduces no change with how the information is represented in userspace.

Mind explaining this "uncertainty"? I'd like to avoid extending the array
for no real reason...


libxl exports "hw_caps" as uint32_t caps[8] in its API.

I am uncertain what reusing word 2, or extending the length of the array 
means WRT to the API/ABI guarantees of libxl.


For hw_caps itself, the data is essentially useless as there is no 
defined layout,  Furthermore, some of the leaves are 
arbitrary/synthetic.  One option might be to just drop it from libxl 
entirely, but this will need to be decided by the toolstack maintainers.


For my cpuid levelling series, there is a new set exported which has an 
ABI guarantee of which words map to which cpuid feature leaves, and a 
strict rule of no synthetic values.





@@ -325,20 +321,15 @@ void xstate_init(bool_t bsp)
  
  /* Check extended XSAVE features. */

  cpuid_count(XSTATE_CPUID, 1, , , , );
-if ( bsp )
-{
-cpu_has_xsaveopt = !!(eax & XSTATE_FEATURE_XSAVEOPT);
-cpu_has_xsavec = !!(eax & XSTATE_FEATURE_XSAVEC);
-/* XXX cpu_has_xgetbv1 = !!(eax & XSTATE_FEATURE_XGETBV1); */
-/* XXX cpu_has_xsaves = !!(eax & XSTATE_FEATURE_XSAVES); */
-}
-else
-{
-BUG_ON(!cpu_has_xsaveopt != !(eax & XSTATE_FEATURE_XSAVEOPT));
-BUG_ON(!cpu_has_xsavec != !(eax & XSTATE_FEATURE_XSAVEC));
-/* XXX BUG_ON(!cpu_has_xgetbv1 != !(eax & XSTATE_FEATURE_XGETBV1)); */
-/* XXX BUG_ON(!cpu_has_xsaves != !(eax & XSTATE_FEATURE_XSAVES)); */
-}
+
+/* Mask out features not currently understood by Xen. */
+eax &= (cpufeat_mask(X86_FEATURE_XSAVEOPT) |
+cpufeat_mask(X86_FEATURE_XSAVEC));
+
+c->x86_capability[X86_FEATURE_XSAVEOPT / 32] = eax;
+
+if ( !bsp )
+BUG_ON(eax != boot_cpu_data.x86_capability[X86_FEATURE_XSAVEOPT / 32]);
  }

The !bsp conditional seems pretty pointless. And with the revised
model it looks like it could be relaxed (BUG only when bits the BSP
has set aren't set on the AP).


I would be very wary about allowing a situation where certain amounts of 
heterogeneity would be permitted.  Even moreso with the xsaves 
extensions, any non-homogeneity in the system will result in data 
corruption.


I think it is better to keep this as strictly that the BSP must match 
all APs.  As soon as we encounter a system where this is not the case, 
far more areas will also need modifying.


~Andrew

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

Re: [Xen-devel] [OSSTEST PATCH 21/26] ts-debian-hvm-install: Do not create EFI partition if EFI not in use

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 21/26] ts-debian-hvm-install: Do not 
create EFI partition if EFI not in use"):
> On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote:
> > If we are booting our install ISO using a non-EFI executable, don't
> > try to provide an EFI for the installed system either.
> > 
> > Signed-off-by: Ian Jackson 
> 
> FWIW the default recipes used by d-i use "$iflabel{ gpt }" to achieve the
> same thing. Actually I'm a bit surprised that this isn't the affect of
> "method { efi }" too.
...  
> > -$preseed_file .= (< > +$preseed_file .= (<

[Xen-devel] [PATCH OSSTEST] Correct html syntax error color=="#xxxxxx" => color="#xxxxxx"

[Ian Campbell]

Strangely the effect of this (with iceweasel) was that everything was
cyan (#00fff0?) instead of the intended black or white.

Signed-off-by: Ian Campbell 
---
 ms-planner | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ms-planner b/ms-planner
index 1f996a6..cab32c9 100755
--- a/ms-planner
+++ b/ms-planner
@@ -727,7 +727,7 @@ sub cmd_show_html () {
 my $fgcolour=
 $avail ? "#00" : "#ff";
printf "%s %s",
+" bgcolor=\"%s\">%s %s",
$content->{Rowspan}, $bgcolour, $fgcolour, $show;
$content->{Printed}= 1;
}
-- 
2.5.1


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

Re: [Xen-devel] [PATCH v7 05/28] xen/arm: ITS: Port ITS driver to Xen

[Julien Grall]

Hi Vijay,

The only things I haven't check on this patch was the ITS command structure.

On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> +/* ITS command structure */
> +typedef union {

Can you please sort this union by command name in alphabetical order.
It's way easier to find a command in the list.

> +u64 bits[4];
> +struct __packed {
> +uint8_t cmd;

NIT: Please stay consistent with usage of the type. You are using u8
everywhere within this union except here.

> +uint8_t pad[7];

Why a padding of only 56 bits? Shouldn't it be 248 bits (i.e 31 * 8
bits) to fit all the command?

> +} hdr;
> +struct __packed {
> +u8 cmd;
> +u8 res1[3];
> +u32 devid;
> +u64 size:5;
> +u64 res2:59;
> +/* XXX: Though itt is 40 bit. Keep it 48 to avoid shift */
> +u64 res3:8;

It's very confusing for the reviewer to see a mix of usage (u8 res1[n],
u64 res3:8) within the same structure.

The later (i.e u64 field:n) is the best to use because we can match
quickly the size with the spec.

> +u64 itt:40;
> +u64 res4:15;
> +u64 valid:1;
> +u64 res5;
> +} mapd;

[..]

> +struct __packed {
> +u8 cmd;
> +u8 res1[3];
> +u32 devid;
> +u32 event;
> +u32 res2;
> +u64 res3;
> +u64 res4;
> +} int_cmd;

Maybe you want to add the suffix _cmd to everyone to avoid having only
one because of C spec issue.

> +struct __packed {
> +u8 cmd;
> +u8 res1[3];
> +u32 devid;
> +u32 event;
> +u32 res2;
> +u64 res3;
> +u64 res4;
> +} clear;
> +struct __packed {
> +u8 cmd;
> +u8 res1[7];
> +u64 res2;
> +u16 res3;
> +u32 ta;

It would have been better to have a full name or a description rather
than only a 2 letter field "ta". I won't ask for a documentation of this
field right now, but it would be a nice follow-up of this series.

> +u16 res4;
> +u64 res5;
> +} sync;
> +} its_cmd_block;


Regards,

-- 
Julien Grall

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

Re: [Xen-devel] DRAFT XSA 142 - libxl fails to honour readonly flag on disks with qemu-xen

[M A Young]

On Mon, 21 Sep 2015, Xen.org security team wrote:

> * DRAFT DRAFT DRAFT *
> 
> Xen Security Advisory XSA-142
>
> ...
> 
> xsa142.patch Xen 4.3.x and later
> 
> $ sha256sum xsa142*.patch
> de0d6d19becac199037dce5a6a49e35cb7de5c99b8e2950600ed71fdc2d5a752  xsa142.patch
> $

Of course you still need a separate patch for xen 4.5.1 and earlier as the 
xsa142.patch file attached is only valid for xen 4.6.0. Replacing 
ERROR_INVAL with NULL works for xen 4.5.1 and compiles for xen 4.4.3.

Michael Young

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

Re: [Xen-devel] [PATCH 2/2] xen: arm: traps: correct cond

[Ian Campbell]

On Mon, 2015-09-21 at 17:08 +0800, Peng Fan wrote:
> On Mon, Sep 21, 2015 at 11:10:11AM +0100, Julien Grall wrote:
> > Hi Peng,
> > 
> > On 21/09/15 08:07, Peng Fan wrote:
> > > From "G6.2.29 CPSR, Current Program Status Register" of Aarch64 ARM
> > > and "B1.3.3 Program Status Registers (PSRs)" of ARMv7-A ARM:
> > > "
> > 
> > The section number may change between the different version of the
> > spec.
> > Can you also precise the spec version?
> > 
> > For instance on my ARM64 spec (ARM DDI 0497A.d) the section G6.2.29
> > points to "CSSELR" and not "CPSR".
> > 
> > > IT[7:5] holds the base condition for the IT block. The base condition
> > > is
> > > the top 3 bits of the condition code specified by the first
> > >   condition field of the IT instruction.
> > > IT[4:0] encodes the size of the IT block, which is the number of
> > > instructions that are to be conditionally executed, by the
> > >   position of the least significant 1 in this field. It also
> > >   encodes the value of the least significant bit of the condition
> > >   code for each instruction in the block.
> > > "
> > > So should be "cond = ( it >> 5 );" but not "cond = ( it >> 4 );"
> > 
> > IT[7:5] encodes the top 3 bits of the condition code and one bit of
> > IT[4:0] will contain the least significant bit of the condition code.
> > 
> > In order to get the full condition code you have to use IT[7:4] which
> > the current code does (see A2.5.2 ARM DDI 0406C.b).
> > 
> > So the current code looks valid to me. Did I miss something?
> 
> No, you are correct.

Were these two patches motivated by an actual issue you were seeing? Or
just from code inspection?


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

[Xen-devel] [qemu-upstream-unstable baseline-only test] 37993: regressions - trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 37993 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37993/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 37965
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 37965
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 37965

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 qemuu8ad9e71fc937439730fa68e82d6da11a50eb5c04
baseline version:
 qemuub05befcbea71a979509ce04f02929969a790c923

Last test of basis37965  2015-09-18 06:50:04 Z3 days
Testing same since37993  2015-09-20 01:57:57 Z1 days1 attempts


People who touched revisions under test:
  P J P 
  Stefan Hajnoczi 
  Stefano Stabellini 

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

Re: [Xen-devel] [PATCH v2 for-4.6] libxl: handle read-only drives with qemu-xen

[Ian Campbell]

On Tue, 2015-09-15 at 17:22 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[PATCH v2 for-4.6] libxl: handle read-only
> drives with qemu-xen"):
> > The current libxl code doesn't deal with read-only drives at all.
> > 
> > Upstream QEMU and qemu-xen only support read-only cdrom drives: make
> > sure to specify "readonly=on" for cdrom drives and return error in case
> > the user requested a non-cdrom read-only drive.
> 
> Acked-by: Ian Jackson 

I applied to staging and staging-4.6 with this Ack and Wei's say so
elsewhere.


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

Re: [Xen-devel] [PATCH for-4.6] xen/arm: vgic-v2: Map the GIC virtual CPU interface with the correct size

[Ian Campbell]

On Fri, 2015-09-18 at 09:53 +0100, Ian Campbell wrote:
> On Thu, 2015-09-17 at 19:00 +0100, Julien Grall wrote:
> > On GICv2, the GIC virtual CPU interface is at minimum 8KB. Due some to
> > some necessary quirk for GIC using 64KB stride, we are mapping the
> > region in 2 time.
> > The first mapping is 4KB and the second one is 8KB, i.e 12KB in total.
> > Although the minimum supported size (and widely used) is 8KB. This
> > means
> > that we are mapping 4KB more to any guest using GICv2.
> > 
> > While this looks scary at first glance, the GIC virtual CPU interface
> > is
> > most frequently at the end the GIC I/O region. So we will most likely
> > map an an unused I/O region or a mirrored version of GICV for platform
> > using 64KB stride.
> > 
> > Nonetheless, fix the second mapping to only map 4KB.
> > 
> > Signed-off-by: Julien Grall 
> 
> Acked-by: Ian Campbell 
> 
> > ---
> > 
> > This is a candidate for Xen 4.6 and backport to Xen 4.5.
> 
> I concur and with Wei not being around I shall plan to apply later today
> unless there are objections.

I got distracted. Now applied to staging and staging-4.6 now and noted for
later application to 4.5

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

Re: [Xen-devel] [PATCH for-4.6] tools/libxc: arm: Check the index before accessing the bank

[Ian Campbell]

On Fri, 2015-09-18 at 11:30 +0100, Wei Liu wrote:

> > > H I forgot my Signed-off-by :(.
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > Acked-by: Ian Campbell 
> > 
> > This is a no brainer for 4.6 (and further) IMHO and with Wei not being
> > around I shall plan to apply later today unless there are objections.
> > 
> 
> No objection from me of course.

Applied to staging and staging-4.6.

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

[Xen-devel] [PATCH 0/3] x86: further P2M adjustments

[Jan Beulich]

1: p2m: tighten conditions of IOMMU mapping updates
2: p2m-pt: use pre-calculated IOMMU flags
3: p2m-ept: adjust some types in ept_set_entry()

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] [OSSTEST PATCH 15/26] cr*: Support xen-unstable-smoke

[Ian Campbell]

On Mon, 2015-09-21 at 11:21 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 15/26] cr*: Support xen-unstable
> -smoke"):
> > On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote:
> > > Add this branch to select_xenbranch.  This works like xen-unstable in
> > > most respects.
> > > 
> > > There are only two places in osstest where xenbranch `xen-unstable'
> > > is
> > > treated specially and only one of them needs adjusting to match
> > > xen-unstable-smoke too.
> > 
> > The included one is the one which adds the qemu revisions?
> 
> No, this in cr-daily-branch:
> 
> if [ "x$branch" != "xxen-unstable" ]; then
> export REVISION_LINUX_OLD=disable
> fi

That's the one which didn't need adjusting I think.

> > And the other one is, I think, the thing which sets
> >  REVISION_LINUX_OLD=disable which we want (or maybe don't care about)
> > for
> > the smoked tests. So good.
> 
> Indeed.
> 
> I'm not sure what the qemu revisions thing is you're thinking of but I
> think all the places where the source code matches `xen-unstable[^-]',
> the actual effect is to treat `xen-unstable-smoke' the same way as
> `xen-unstable'.

"qemu revisions thing" is:

@@ -340,7 +340,7 @@ case "$NEW_REVISION/$OLD_REVISION" in
 "$treeurl#$OLD_REVISION-$NEW_REVISION" \
 
 case "$realtree" in
-xen-4*|xen-unstable)
+xen-4*|xen-unstable*)
 oldqemu=`./ap-qemu-revision $realtree $OLD_REVISION`
 newqemu=`./ap-qemu-revision $realtree $NEW_REVISION`
 if [ "$oldqemu" ] && [ "$newqemu" ]; then

> 
> > Acked-by: Ian Campbell 
> 
> Thanks,
> Ian.

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

Re: [Xen-devel] [PATCH v7 04/28] xen/arm: Rename NR_IRQs and vgic_num_irqs helper function

[Julien Grall]

Hi Vijay,

On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> NR_IRQS represents the number of lines (i.e SGIs, PPIs and SPIs).
> With the introduction of LPIs, NR_IRQs is renamed to NR_ITLINES.
> Similarly vgic_num_irqs() is renamed as vgic_num_irq_lines().
> 
> Signed-off-by: Vijaya Kumar K 
Reviewed-by: Julien Grall 

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] DRAFT XSA 142 - libxl fails to honour readonly flag on disks with qemu-xen

[Ian Campbell]

On Tue, 2015-09-15 at 16:22 +, Xen.org security team wrote:

> VULNERABLE SYSTEMS
> ==
> 
[...]
> Only systems using libxl or libxl-based toolstacks are vulnerable.
> (This includes libvirt with the libxl driver.)

^xl and ... ?

> 
> All versions of libxl which support qemu-xen are vulnerable.  Support
> for qemu-xen was introduced in Xen 4.1.

http://wiki.xenproject.org/wiki/Xen_Project_Release_Features says 4.2 as
preview and 4.3 properly. Which is wrong?

Apart from those minor nits this looks good to me, although I confess I've
not fully been following the discussion.

Ian.

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Paolo Bonzini]

On 21/09/2015 10:46, Ingo Molnar wrote:
> Or we could extend exception table entry encoding to include a 'warning bit', 
> to 
> not bloat the kernel. If the exception handler code encounters such an 
> exception 
> it would generate a one-time warning for that entry, but otherwise not crash 
> the 
> kernel and continue execution with an all-zeroes result for the MSR read.

The 'warning bit' already exists, it is the opcode that caused the fault. :)

The concern about bloat is a good one.  However, why is it necessary to
keep native_*_msr* inline?  If they are moved out-of-line, using the
exception table becomes the obvious solution and doesn't cause bloat
anymore.

Paolo

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

Re: [Xen-devel] DRAFT XSA 142 - libxl fails to honour readonly flag on disks with qemu-xen

[Ian Jackson]

Ian Campbell writes ("Re: DRAFT XSA 142 - libxl fails to honour readonly flag 
on disks with qemu-xen"):
> On Tue, 2015-09-15 at 16:22 +, Xen.org security team wrote:
> > VULNERABLE SYSTEMS
> > ==
> > 
> [...]
> > Only systems using libxl or libxl-based toolstacks are vulnerable.
> > (This includes libvirt with the libxl driver.)
> 
> ^xl and ... ?

Good idea, done.

> > All versions of libxl which support qemu-xen are vulnerable.  Support
> > for qemu-xen was introduced in Xen 4.1.
> 
> http://wiki.xenproject.org/wiki/Xen_Project_Release_Features says 4.2 as
> preview and 4.3 properly. Which is wrong?

staging-4.1 contains `libxl_build_device_model_args_new' But maybe the
feature wasn't advertised.  I have reworded. to say `the affected code
was introduced in Xen 4.1'.

Last Call draft just sent.

Ian.

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

Re: [Xen-devel] [PATCH for-4.6] xen/arm: vgic-v2: Map the GIC virtual CPU interface with the correct size

[Ian Campbell]

On Mon, 2015-09-21 at 13:28 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 21/09/15 12:54, Ian Campbell wrote:
> > On Fri, 2015-09-18 at 09:53 +0100, Ian Campbell wrote:
> > > On Thu, 2015-09-17 at 19:00 +0100, Julien Grall wrote:
> > > > On GICv2, the GIC virtual CPU interface is at minimum 8KB. Due some
> > > > to
> > > > some necessary quirk for GIC using 64KB stride, we are mapping the
> > > > region in 2 time.
> > > > The first mapping is 4KB and the second one is 8KB, i.e 12KB in
> > > > total.
> > > > Although the minimum supported size (and widely used) is 8KB. This
> > > > means
> > > > that we are mapping 4KB more to any guest using GICv2.
> > > > 
> > > > While this looks scary at first glance, the GIC virtual CPU
> > > > interface
> > > > is
> > > > most frequently at the end the GIC I/O region. So we will most
> > > > likely
> > > > map an an unused I/O region or a mirrored version of GICV for
> > > > platform
> > > > using 64KB stride.
> > > > 
> > > > Nonetheless, fix the second mapping to only map 4KB.
> > > > 
> > > > Signed-off-by: Julien Grall 
> > > 
> > > Acked-by: Ian Campbell 
> > > 
> > > > ---
> > > > 
> > > > This is a candidate for Xen 4.6 and backport to Xen 4.5.
> > > 
> > > I concur and with Wei not being around I shall plan to apply later
> > > today
> > > unless there are objections.
> > 
> > I got distracted. Now applied to staging and staging-4.6 now and noted
> > for
> > later application to 4.5
> 
> It won't apply cleanly for Xen 4.5, this code was living in the gic
> driver. I will send a backport patch for it.

Thanks.


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

[Xen-devel] DRAFT XSA 142 - libxl fails to honour readonly flag on disks with qemu-xen

[Xen . org security team]

* DRAFT DRAFT DRAFT *

Xen Security Advisory XSA-142

libxl fails to honour readonly flag on disks with qemu-xen

ISSUE DESCRIPTION
=

Callers of libxl can specify that a disk should be read-only to the
guest.  However, there is no code in libxl to pass this information to
qemu-xen (the upstream-based qemu); and indeed there is no way in qemu
to make a disk read-only.

The vulnerability is exploitable only via devices emulated by the
device model, not the parallel PV devices for supporting PVHVM.
Normally the PVHVM device unplug protocol renders the emulated devices
inaccessible early in boot.

IMPACT
==

Malicious guest administrators or (in some situations) users may be
able to write to supposedly read-only disk images.

CDROM devices (that is, devices specified to be presented to the guest
as CDROMs, regardless of the nature of the backing storage on the
host) are not affected.

VULNERABLE SYSTEMS
==

Only systems using qemu-xen (rather than qemu-xen-traditional) as the
device model version are vulnerable.

Only systems using libxl or libxl-based toolstacks are vulnerable.
(This includes xl, and libvirt with the libxl driver.)

All versions of libxl which support qemu-xen are vulnerable.  The
affected code was introduced in Xen 4.1.

If the host and guest together usually support PVHVM, the issue is
exploitable only if the malicious guest administrator has control of
the guest kernel or guest kernel command line.

MITIGATION
==

Switching to qemu-xen-traditional will avoid this vulnerability.
This can be done with
   device_model_version="qemu-xen-traditional"
in the xl configuration file.

Using stub domain device models (which necessarily involves switching
to qemu-xen-traditional) will also avoid this vulnerability.
This can be done with
   device_model_stubdomain_override=true
in the xl configuration file.

Either of these mitigations is liable to have other guest-visible
effects or even regressions.

It may be possible, depending on the configuration, to make the
underlying storage object readonly, or to make it reject writes.

RESOLUTION
==

There is no reasonable resolution because Qemu does not (at the time
of writing) support presenting a read-only block device to a guest as
a disk.

The attached patch corrects the weakness in the libxl code, by
rejecting the unsupported configurations, rather than allowing them to
run but with the device perhaps writeable by the guest.  Applying it
should increase confidence and avoid future configuration errors, but
will break configurations specifying read-only disk devices.

xsa142.patch Xen 4.3.x and later

$ sha256sum xsa142*.patch
de0d6d19becac199037dce5a6a49e35cb7de5c99b8e2950600ed71fdc2d5a752  xsa142.patch
$

NOTE REGARDING LACK OF EMBARGO
==

This issue was discussed in public in the Red Hat bugzilla:
  https://bugzilla.redhat.com/show_bug.cgi?id=1257893

CREDITS
===

Thanks to Michael Young of Durham University for bring this problem to
our attention.



xsa142.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 08/28] xen/arm: ITS: Add APIs to add and assign device

[Julien Grall]

Hi Vijay,

On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Add APIs to add devices to RB-tree, assign and remove
> devices to domain.
> 
> Signed-off-by: Vijaya Kumar K 
> ---
> v7: - Added check for domain in its_assign_device() to avoid
>   assigning device to DomU
> - Added comments whereever requested
> - Called its_remove_device to remove from rb-tree
>   when failed to add device
> - Changed dprintk to printk
> - Store domain pointer instead of domain id in its_device struct
> - Free msi_desc and reset irq_desc when lpis are discarded
> - Add function its_free_msi_descs() to free msi_desc
> v6: - Moved this patch #19 to patch #8
> - Used col_map to store collection id
> - Use helper functions to update msi_desc members
> v5: - Removed its_detach_device API
> - Pass nr_ites as parameter to its_add_device
> v4: - Introduced helper to populate its_device struct
> - Fixed freeing of its_device memory
> - its_device struct holds domain id
> ---
>  xen/arch/arm/gic-v3-its.c |  261 
> +
>  xen/include/asm-arm/gic-its.h |6 +
>  2 files changed, 267 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 4b7d9ed..bc3b73c 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -145,6 +145,19 @@ static struct its_collection *dev_event_to_col(struct 
> its_device *dev,
>  return its->collections + dev->event_map.col_map[event];
>  }
>  
> +static struct its_node *its_get_phys_node(struct dt_device_node *dt)
> +{
> +struct its_node *its;
> +
> +list_for_each_entry(its, _nodes, entry)
> +{
> +if ( its->dt_node == dt )
> +return its;
> +}
> +
> +return NULL;
> +}
> +
>  /* RB-tree helpers for its_device */
>  static struct its_device *its_find_device(u32 devid)
>  {
> @@ -537,8 +550,256 @@ static void its_lpi_free(struct its_device *dev)
>  }
>  
>  spin_unlock(_lock);
> +}
> +
> +static void its_discard_lpis(struct its_device *dev, u32 ids)
> +{
> +int i;

u32 i;

> +
> +for ( i = 0; i < ids; i++ )
> +   its_send_discard(dev, i);
> +}
> +
> +static void its_free_msi_descs(struct its_device *dev, int count)

its_free_msi_descs can be merge with its_discard_lpis. It would avoid
looping twice which can be expensive with device having a lot of MSI and
make clear the dependency.

For instance its_free_msi_descs should never be called before
its_discard_lpis.

> +{
> +int i, irq;

Why do you need them signed? Same for the parameter "count".

> +struct irq_desc *desc;
> +
> +for ( i = 0; i < count; i++ )
> +{
> +   irq = dev->event_map.lpi_base + i;

You could have use its_get_plpi here.

> +   desc = irq_to_desc(irq);
> +
> +   spin_lock(>lock);
> +   irqdesc_set_lpi_event(desc, 0);
> +   irqdesc_set_its_device(desc, NULL);

Why do you need these 2 calls?

> +   xfree(irq_get_msi_desc(desc));
> +   irq_set_msi_desc(desc, NULL);

After this, the IRQ desc is still left in an unknown state (give a look
to gic_remove_irq_from_guest).

Although, it may not need necessary for now. So I would be fine with a
TODO in the code.

> +   spin_unlock(>lock);
> +}
> +}
> +
> +static inline u32 its_get_plpi(struct its_device *dev, u32 event)
> +{
> +return dev->event_map.lpi_base + event;
> +}
> +
> +static int its_alloc_device_irq(struct its_device *dev, u32 *hwirq)
> +{
> +int idx;
> +
> +idx = find_first_zero_bit(dev->event_map.lpi_map, 
> dev->event_map.nr_lpis);
> +if ( idx == dev->event_map.nr_lpis )
> +return -ENOSPC;
> +
> +*hwirq = its_get_plpi(dev, idx);
> +set_bit(idx, dev->event_map.lpi_map);
>  
> +return 0;
> +}
> +
> +static void its_free_device(struct its_device *dev)
> +{
> +xfree(dev->itt);
> +its_lpi_free(dev);
>  xfree(dev->event_map.lpi_map);

Why did you move this call from its_lpi_free to here?

> +xfree(dev->event_map.col_map);

This line should have been added in its_lpi_free in patch #5.

> +xfree(dev);
> +}
> +
> +static struct its_device *its_alloc_device(u32 devid, u32 nr_ites,
> +   struct dt_device_node *dt_its)

Can you explain why you weren't able to re-use its_create_device from Linux?

AFAICT there is nothing different and you miss key code such as rounding
to a power of 2 the number of event IDs.

> +{
> +struct its_device *dev;
> +unsigned long *lpi_map;
> +int lpi_base, sz;
> +u16 *col_map = NULL;
> +
> +dev = xzalloc(struct its_device);
> +if ( dev == NULL )
> +return NULL;
> +
> +dev->its = its_get_phys_node(dt_its);

You can re-order the code to get the ITS before allocate the memory. And
then you can drop one goto.

> +if (dev->its == NULL)
> +{
> +printk(XENLOG_G_ERR

As already 

[Xen-devel] [V5 4/4] libxc: expose xsaves/xgetbv1/xsavec to hvm guest

[Shuai Ruan]

This patch exposes xsaves/xgetbv1/xsavec to hvm guest.
The reserved bits of eax/ebx/ecx/edx must be cleaned up
when call cpuid(0dh) with leaf 1 or 2..63.

According to the spec the following bits must be reserved:
For leaf 1, bits 03-04/08-31 of ecx is reserved. Edx is reserved.
For leaf 2...63, bits 01-31 of ecx is reserved. Edx is reserved.

Acked-by: Ian Campbell 
Signed-off-by: Shuai Ruan 
---
 tools/libxc/xc_cpuid_x86.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index e146a3e..538d356 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -210,6 +210,10 @@ static void intel_xc_cpuid_policy(
 }
 
 #define XSAVEOPT(1 << 0)
+#define XSAVEC  (1 << 1)
+#define XGETBV1 (1 << 2)
+#define XSAVES  (1 << 3)
+#define XSS_SUPPORT (1 << 0)
 /* Configure extended state enumeration leaves (0x000D for xsave) */
 static void xc_cpuid_config_xsave(
 xc_interface *xch, domid_t domid, uint64_t xfeature_mask,
@@ -246,8 +250,9 @@ static void xc_cpuid_config_xsave(
 regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
 break;
 case 1: /* leaf 1 */
-regs[0] &= XSAVEOPT;
-regs[1] = regs[2] = regs[3] = 0;
+regs[0] &= (XSAVEOPT | XSAVEC | XGETBV1 | XSAVES);
+regs[2] &= xfeature_mask;
+regs[3] = 0;
 break;
 case 2 ... 63: /* sub-leaves */
 if ( !(xfeature_mask & (1ULL << input[1])) )
@@ -255,8 +260,9 @@ static void xc_cpuid_config_xsave(
 regs[0] = regs[1] = regs[2] = regs[3] = 0;
 break;
 }
-/* Don't touch EAX, EBX. Also cleanup ECX and EDX */
-regs[2] = regs[3] = 0;
+/* Don't touch EAX, EBX. Also cleanup EDX. Cleanup bits 01-32 of ECX*/
+regs[2] &= XSS_SUPPORT;
+regs[3] = 0;
 break;
 }
 }
-- 
1.9.1


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

[Xen-devel] [V5 0/4] add xsaves/xrstors support

[Shuai Ruan]

Changes in v5:
*Address comments from Andrew/Jan,mainly:
*Add lazy writes of the xss_msr.
*Add xsave_area check when save/restore guest.
*Add xsavec support.
*Use word 2 in xen/include/asm-x86/cpufeature.h.
*Fix some code errors.

Changes in v4:
* Address comments from Andrew, mainly:
* No xsaves suporting for pv guest.
* Using xstate_sizes instead of domain_cpuid in hvm_cupid in patch 3.
* Add support for format translation when perform pv guest migration in patch 
2. 
* Fix some code errors.

Changes in v3:
* Address comments from Jan/Konrad
* Change the bits of eax/ebx/ecx/edx passed to guest in patch 4.
* Add code to verify whether host supports xsaves or not in patch 1.

Changes in v2:
* Address comments from Andrew/chao/Jan, mainly:
* Add details information of xsaves/xrstors feature.
* Test migration between xsaves-support machine and none-xsaves-support machine 
* Remove XGETBV1/XSAVEC/XSAVEOPT out of 'else' in patch 3.
* Change macro name XGETBV to XGETBV1 in patch 4.

This patchset enable xsaves/xrstors feature which will be available on 
Intel Skylake and later platform. Like xsave/xrstor, xsaves/xrstors 
feature will save and load processor state from a region of memory called 
XSAVE area. While unlike xsave/xrstor, xsaves/xrstors:

a) use the compacted format only for the extended region 
   of the XSAVE area which saves memory for you;
b) can operate on supervisor state components so the feature
   is prerequisite to support new supervisor state components;
c) execute only if CPL=0. 

Detail hardware spec can be found in chapter 13 (section 13.11 13.12) of the 
Intel SDM [1].

patch1: add basic definition/function to support xsaves
patch2: add xsaves/xrstors support for xen
patch3-4: add xsaves/xrstors support for hvm guest


[1] Intel SDM 
(http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf)


Shuai Ruan (4):
  x86/xsaves: add basic definitions/helpers to support xsaves
  x86/xsaves: enable xsaves/xrstors/xsavec in xen
  x86/xsaves: enable xsaves/xrstors for hvm guest
  libxc: expose xsaves/xgetbv1/xsavec to hvm guest

 tools/libxc/xc_cpuid_x86.c |  14 +-
 xen/arch/x86/domain.c  |   3 +
 xen/arch/x86/domctl.c  |  38 -
 xen/arch/x86/hvm/hvm.c |  51 ++-
 xen/arch/x86/hvm/vmx/vmcs.c|   6 +-
 xen/arch/x86/hvm/vmx/vmx.c |  20 +++
 xen/arch/x86/i387.c|   4 +
 xen/arch/x86/traps.c   |   7 +-
 xen/arch/x86/xstate.c  | 304 -
 xen/include/asm-x86/cpufeature.h   |   6 +-
 xen/include/asm-x86/hvm/vcpu.h |   1 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |   6 +
 xen/include/asm-x86/hvm/vmx/vmx.h  |   2 +
 xen/include/asm-x86/msr-index.h|   2 +
 xen/include/asm-x86/xstate.h   |  19 ++-
 15 files changed, 415 insertions(+), 68 deletions(-)

-- 
1.9.1


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

[Xen-devel] [V5 1/4] x86/xsaves: add basic definitions/helpers to support xsaves

[Shuai Ruan]

This patch add basic definitions/helpers which will be used in
later patches.

Signed-off-by: Shuai Ruan 
---
 xen/arch/x86/xstate.c| 168 +++
 xen/include/asm-x86/cpufeature.h |   6 +-
 xen/include/asm-x86/hvm/vcpu.h   |   1 +
 xen/include/asm-x86/msr-index.h  |   2 +
 xen/include/asm-x86/xstate.h |  14 +++-
 5 files changed, 189 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index d5f5e3b..ff03b31 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -29,12 +29,21 @@ static u32 __read_mostly xsave_cntxt_size;
 /* A 64-bit bitmask of the XSAVE/XRSTOR features supported by processor. */
 u64 __read_mostly xfeature_mask;
 
+unsigned int * __read_mostly xstate_offsets;
+unsigned int * __read_mostly xstate_sizes;
+static unsigned int __read_mostly xstate_features;
+static unsigned int __read_mostly xstate_comp_offsets[sizeof(xfeature_mask)*8];
+
+/* Cached msr_xss for fast read */
+static DEFINE_PER_CPU(uint64_t, msr_xss);
+
 /* Cached xcr0 for fast read */
 static DEFINE_PER_CPU(uint64_t, xcr0);
 
 /* Because XCR0 is cached for each CPU, xsetbv() is not exposed. Users should 
  * use set_xcr0() instead.
  */
+
 static inline bool_t xsetbv(u32 index, u64 xfeatures)
 {
 u32 hi = xfeatures >> 32;
@@ -65,6 +74,165 @@ uint64_t get_xcr0(void)
 return this_cpu(xcr0);
 }
 
+void set_msr_xss(u64 xss)
+{
+wrmsrl(MSR_IA32_XSS, xss);
+this_cpu(msr_xss) = xss;
+}
+
+uint64_t get_msr_xss(void)
+{
+return this_cpu(msr_xss);
+}
+
+bool_t xsave_area_compressed(const struct xsave_struct *xsave_area)
+{
+if ( xsave_area && (xsave_area->xsave_hdr.xcomp_bv
+  & XSTATE_COMPACTION_ENABLED))
+   return 1;
+return 0;
+}
+
+static int setup_xstate_features(bool_t bsp)
+{
+unsigned int leaf, tmp, eax, ebx;
+
+if ( bsp )
+xstate_features = fls(xfeature_mask);
+
+if ( bsp )
+{
+xstate_offsets = xzalloc_array(unsigned int, xstate_features);
+if( !xstate_offsets )
+return -ENOMEM;
+
+xstate_sizes = xzalloc_array(unsigned int, xstate_features);
+if( !xstate_sizes )
+return -ENOMEM;
+}
+
+for (leaf = 2; leaf < xstate_features; leaf++)
+{
+if( bsp )
+cpuid_count(XSTATE_CPUID, leaf, _sizes[leaf],
+_offsets[leaf], , );
+else
+{
+ cpuid_count(XSTATE_CPUID, leaf, ,
+, , );
+ BUG_ON(eax != xstate_sizes[leaf]);
+ BUG_ON(ebx != xstate_offsets[leaf]);
+}
+ }
+ return 0;
+}
+
+static void setup_xstate_comp(void)
+{
+unsigned int i;
+
+/*
+ * The FP xstates and SSE xstates are legacy states. They are always
+ * in the fixed offsets in the xsave area in either compacted form
+ * or standard form.
+ */
+xstate_comp_offsets[0] = 0;
+xstate_comp_offsets[1] = XSAVE_SSE_OFFSET;
+
+xstate_comp_offsets[2] = FXSAVE_SIZE + XSAVE_HDR_SIZE;
+
+for (i = 3; i < xstate_features; i++)
+{
+xstate_comp_offsets[i] = xstate_comp_offsets[i-1] + (((1ul << i)
+ & xfeature_mask) ? xstate_sizes[i-1] : 0);
+ASSERT(xstate_comp_offsets[i] <= xsave_cntxt_size);
+}
+}
+
+static void *get_xsave_addr(struct xsave_struct *xsave, unsigned int 
xfeature_idx)
+{
+if ( !((1ul << xfeature_idx) & xfeature_mask) )
+return NULL;
+
+return (void *)xsave + xstate_comp_offsets[xfeature_idx];
+}
+
+void save_xsave_states(struct vcpu *v, void *dest, unsigned int size)
+{
+struct xsave_struct *xsave = v->arch.xsave_area;
+u64 xstate_bv = xsave->xsave_hdr.xstate_bv;
+u64 valid;
+
+ASSERT(xsave_area_compressed(xsave));
+/*
+ * Copy legacy XSAVE area, to avoid complications with CPUID
+ * leaves 0 and 1 in the loop below.
+ */
+memcpy(dest, xsave, FXSAVE_SIZE);
+
+/* Set XSTATE_BV */
+*(u64 *)(dest + XSAVE_HDR_OFFSET) = xstate_bv;
+
+/*
+ * Copy each region from the possibly compacted offset to the
+ * non-compacted offset.
+ */
+valid = xstate_bv & ~XSTATE_FP_SSE;
+while ( valid )
+{
+u64 feature = valid & -valid;
+int index = fls(feature) - 1;
+void *src = get_xsave_addr(xsave, index);
+
+if ( src )
+{
+ASSERT((xstate_offsets[index] + xstate_sizes[index]) <= size);
+memcpy(dest + xstate_offsets[index], src, xstate_sizes[index]);
+}
+
+valid -= feature;
+}
+
+}
+
+void load_xsave_states(struct vcpu *v, const void *src, unsigned int size)
+{
+struct xsave_struct *xsave = v->arch.xsave_area;
+u64 xstate_bv = *(u64 *)(src + XSAVE_HDR_OFFSET);
+u64 valid;
+
+ASSERT(!xsave_area_compressed((struct xsave_struct *)src));
+/*
+ * Copy legacy XSAVE area, to avoid complications with CPUID
+ * leaves 0 and 

[Xen-devel] [V5 2/4] x86/xsaves: enable xsaves/xrstors/xsavec in xen

[Shuai Ruan]

This patch uses xsaves/xrstors instead of xsaveopt/xrstor
to perform the xsave_area switching so that xen itself
can benefit from them when available.

For xsaves/xrstors only use compact format. Add format conversion
support when perform guest os migration.

Signed-off-by: Shuai Ruan 
---
 xen/arch/x86/domain.c|   3 +
 xen/arch/x86/domctl.c|  38 +++--
 xen/arch/x86/hvm/hvm.c   |  21 +--
 xen/arch/x86/i387.c  |   4 ++
 xen/arch/x86/traps.c |   7 +--
 xen/arch/x86/xstate.c| 132 ++-
 xen/include/asm-x86/xstate.h |   4 --
 7 files changed, 151 insertions(+), 58 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 045f6ff..b25094b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1529,6 +1529,9 @@ static void __context_switch(void)
 if ( xcr0 != get_xcr0() && !set_xcr0(xcr0) )
 BUG();
 }
+if ( cpu_has_xsaves )
+if ( is_hvm_vcpu(n) )
+set_msr_xss(n->arch.hvm_vcpu.msr_xss);
 vcpu_restore_fpu_eager(n);
 n->arch.ctxt_switch_to(n);
 }
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index bf62a88..e2cd0d4 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -867,7 +867,7 @@ long arch_do_domctl(
 if ( domctl->cmd == XEN_DOMCTL_getvcpuextstate )
 {
 unsigned int size;
-
+void * xsave_area;
 ret = 0;
 vcpu_pause(v);
 
@@ -896,9 +896,30 @@ long arch_do_domctl(
 ret = -EFAULT;
 
 offset += sizeof(v->arch.xcr0_accum);
-if ( !ret && copy_to_guest_offset(evc->buffer, offset,
-  (void *)v->arch.xsave_area,
-  size - 2 * sizeof(uint64_t)) )
+
+if ( !ret && (cpu_has_xsaves || cpu_has_xsavec) &&
+ xsave_area_compressed(v->arch.xsave_area) )
+{
+xsave_area = xmalloc_bytes(size);
+if ( !xsave_area )
+{
+ret = -ENOMEM;
+vcpu_unpause(v);
+goto vcpuextstate_out;
+}
+
+save_xsave_states(v, xsave_area,
+  evc->size - 2*sizeof(uint64_t));
+
+if ( !ret && copy_to_guest_offset(evc->buffer, offset,
+ xsave_area, size -
+ 2 * sizeof(uint64_t)) )
+ ret = -EFAULT;
+ xfree(xsave_area);
+   }
+   else if ( !ret && copy_to_guest_offset(evc->buffer, offset,
+ (void *)v->arch.xsave_area,
+ size - 2 * sizeof(uint64_t)) )
 ret = -EFAULT;
 
 vcpu_unpause(v);
@@ -954,8 +975,13 @@ long arch_do_domctl(
 v->arch.xcr0_accum = _xcr0_accum;
 if ( _xcr0_accum & XSTATE_NONLAZY )
 v->arch.nonlazy_xstate_used = 1;
-memcpy(v->arch.xsave_area, _xsave_area,
-   evc->size - 2 * sizeof(uint64_t));
+if ( (cpu_has_xsaves || cpu_has_xsavec) &&
+!xsave_area_compressed(_xsave_area) )
+load_xsave_states(v, _xsave_area,
+  evc->size - 2*sizeof(uint64_t));
+else
+memcpy(v->arch.xsave_area, (void *)_xsave_area,
+   evc->size - 2 * sizeof(uint64_t));
 vcpu_unpause(v);
 }
 else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 615fa89..ad0a53b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2148,8 +2148,13 @@ static int hvm_save_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 ctxt->xfeature_mask = xfeature_mask;
 ctxt->xcr0 = v->arch.xcr0;
 ctxt->xcr0_accum = v->arch.xcr0_accum;
-memcpy(>save_area, v->arch.xsave_area,
-   size - offsetof(struct hvm_hw_cpu_xsave, save_area));
+   if ( (cpu_has_xsaves || cpu_has_xsavec) &&
+ (xsave_area_compressed(v->arch.xsave_area)) )
+save_xsave_states(v, >save_area,
+  size - offsetof(typeof(*ctxt), save_area));
+else
+memcpy(>save_area, v->arch.xsave_area,
+   size - offsetof(struct hvm_hw_cpu_xsave, save_area));
 }
 
 return 0;
@@ -2248,9 +2253,15 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 v->arch.xcr0_accum = ctxt->xcr0_accum;
 if ( ctxt->xcr0_accum & XSTATE_NONLAZY )
 v->arch.nonlazy_xstate_used = 1;
-memcpy(v->arch.xsave_area, >save_area,
-   

[Xen-devel] [V5 3/4] x86/xsaves: enable xsaves/xrstors for hvm guest

[Shuai Ruan]

This patch enables xsaves for hvm guest, includes:
1.handle xsaves vmcs init and vmexit.
2.add logic to write/read the XSS msr.

Reviewed-by: Andrew Cooper 
Signed-off-by: Shuai Ruan 
---
 xen/arch/x86/hvm/hvm.c | 30 ++
 xen/arch/x86/hvm/vmx/vmcs.c|  6 --
 xen/arch/x86/hvm/vmx/vmx.c | 20 
 xen/arch/x86/xstate.c  |  4 ++--
 xen/include/asm-x86/hvm/vmx/vmcs.h |  6 ++
 xen/include/asm-x86/hvm/vmx/vmx.h  |  2 ++
 xen/include/asm-x86/xstate.h   |  1 +
 7 files changed, 65 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ad0a53b..ad2d572 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4550,6 +4550,23 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 *ebx = _eax + _ebx;
 }
 }
+if ( count == 1 )
+{
+if ( cpu_has_xsaves )
+{
+*ebx = XSTATE_AREA_MIN_SIZE;
+if ( v->arch.xcr0 | v->arch.hvm_vcpu.msr_xss )
+for ( sub_leaf = 2; sub_leaf < 63; sub_leaf++ )
+{
+if ( !((v->arch.xcr0 | v->arch.hvm_vcpu.msr_xss)
+   & (1ULL << sub_leaf)) )
+continue;
+*ebx += xstate_sizes[sub_leaf];
+}
+}
+else
+*ebx = *ecx = *edx = 0;
+}
 break;
 
 case 0x8001:
@@ -4649,6 +4666,12 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 *msr_content = v->arch.hvm_vcpu.guest_efer;
 break;
 
+case MSR_IA32_XSS:
+if ( !cpu_has_xsaves )
+goto gp_fault;
+*msr_content = v->arch.hvm_vcpu.msr_xss;
+break;
+
 case MSR_IA32_TSC:
 *msr_content = _hvm_rdtsc_intercept();
 break;
@@ -4781,6 +4804,13 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
return X86EMUL_EXCEPTION;
 break;
 
+case MSR_IA32_XSS:
+/* No XSS features currently supported for guests. */
+if ( !cpu_has_xsaves || msr_content != 0 )
+goto gp_fault;
+v->arch.hvm_vcpu.msr_xss = msr_content;
+break;
+
 case MSR_IA32_TSC:
 hvm_set_guest_tsc(v, msr_content);
 break;
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a0a97e7..258cf17 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -236,7 +236,8 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_PAUSE_LOOP_EXITING |
SECONDARY_EXEC_ENABLE_INVPCID |
SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
-   SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS);
+   SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
+   SECONDARY_EXEC_XSAVES);
 rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
 if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL )
 opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING;
@@ -1238,7 +1239,8 @@ static int construct_vmcs(struct vcpu *v)
 __vmwrite(HOST_PAT, host_pat);
 __vmwrite(GUEST_PAT, guest_pat);
 }
-
+if ( cpu_has_vmx_xsaves )
+__vmwrite(XSS_EXIT_BITMAP, 0);
 vmx_vmcs_exit(v);
 
 /* PVH: paging mode is updated by arch_set_info_guest(). */
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2582cdd..b07e1d2 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2833,6 +2833,18 @@ static void vmx_idtv_reinject(unsigned long idtv_info)
 }
 }
 
+static void vmx_handle_xsaves(void)
+{
+gdprintk(XENLOG_ERR, "xsaves should not cause vmexit\n");
+domain_crash(current->domain);
+}
+
+static void vmx_handle_xrstors(void)
+{
+gdprintk(XENLOG_ERR, "xrstors should not cause vmexit\n");
+domain_crash(current->domain);
+}
+
 static int vmx_handle_apic_write(void)
 {
 unsigned long exit_qualification;
@@ -3404,6 +3416,14 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 vmx_vcpu_flush_pml_buffer(v);
 break;
 
+case EXIT_REASON_XSAVES:
+vmx_handle_xsaves();
+break;
+
+case EXIT_REASON_XRSTORS:
+vmx_handle_xrstors();
+break;
+
 case EXIT_REASON_ACCESS_GDTR_OR_IDTR:
 case EXIT_REASON_ACCESS_LDTR_OR_TR:
 case EXIT_REASON_VMX_PREEMPTION_TIMER_EXPIRED:
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index ae59a60..5940acd 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -14,8 +14,8 @@
 #include 
 #include 
 
-static bool_t __read_mostly cpu_has_xsaveopt;
-static bool_t __read_mostly cpu_has_xsavec;
+bool_t __read_mostly cpu_has_xsaveopt;
+bool_t __read_mostly cpu_has_xsavec;
 bool_t __read_mostly cpu_has_xgetbv1;
 bool_t __read_mostly cpu_has_xsaves;
 

Re: [Xen-devel] Analysis: switch osstest default kernel from 3.14 to 4.1 (Was: Re: [linux-4.1 test] 60785: tolerable FAIL - PUSHED)

[Ian Campbell]

TL;DR: There are issues, but IMHO switching can be justified.

On Thu, 2015-09-03 at 09:59 +0100, Ian Campbell wrote:
> TL;DR: There are issues which need fixing first...
> 
> On Fri, 2015-08-21 at 17:24 +, osstest service owner wrote:
> > flight 60785 linux-4.1 real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/60785/
> > 
> > Failures :-/ but no regressions.
> > 
> > Tests which are failing intermittently (not blocking):
> >  test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 19 guest
> > -start/debianhvm.repeat fail in 60746 pass in 60785
> >  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 guest
> > -start/debianhvm.repeat fail pass in 60746
> >  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest
> > -localmigrate fail pass in 60746
> 
> I've been considering updating osstest to switch from the current baseline
> kernel (the one used for all non linux-* tests) from 3.14 to 4.1.
> 
> The last pass on 3.14 was 60666[0] a little while ago on 13/8 (due to a
> known issue[1]). As well as this pass of 4.1 today I therefore also
> considered 60654[2] on 12/8. Two reports (like this one) are attached
> comparing 3.16:60666 against 4.1:60654 and 4.1:60795 respectively.

Some time has passed and the issues with migration v2 are now fixed.


The most recent pass of 3.14 is (still, sigh) 60666[0].

The most recent fail was 62085[1] which suffers from the same known issue
WRT gntdev (which breaks qdisk based tests for qcow2 and vhd)

The latest 4.1 pass was 62053[2] from Friday.

Attached are two reports of 4.1:62053 vs 3.14:60666 and 3.14:62085.

The failures are:

vs. 60666 only:

 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 60666

vs. 60666 and 62085:

 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail 
REGR. vs. 60666

For the first considering the history:
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/linux-3.14.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/linux-4.1.html

It seems pretty obvious that this is host specific, and in fact 60666
failed, just as guest-localmigrate.2 not guest-localmigrate like 62053 did.

For the second the history:
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/linux-3.14.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/linux-4.1.html

Suggests the issue is pretty intermittent. FWIW the push associated with
62085 justified this failure using 61947[3] where it passed with the exact
same kernel version.

So, I think it could be justified to switch our default kernel version to
linux-4.1. Probably after 4.6 is released though.

Ian.

[0] http://lists.xen.org/archives/html/xen-devel/2015-09/msg00304.html
[1] http://lists.xen.org/archives/html/xen-devel/2015-09/msg02441.html
[2] http://lists.xen.org/archives/html/xen-devel/2015-09/msg02364.html
[3] http://lists.xen.org/archives/html/xen-devel/2015-09/msg01921.html
62053: regressions - FAIL

flight 62053 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62053/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 60666
 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail 
REGR. vs. 60666

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail blocked in 60666
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail blocked in 60666
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 60666
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60666

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-libvirt 12 

Re: [Xen-devel] [PATCH] xen/x86: Record xsave features in c->x86_capabilities

[Jan Beulich]

>>> On 17.09.15 at 13:40,  wrote:
> Jan: I have opted for adding leaf 8 rather than reusing leaf 2, due to the
> uncertainty with how this information is exposed in libxl.  This patch
> introduces no change with how the information is represented in userspace.

Mind explaining this "uncertainty"? I'd like to avoid extending the array
for no real reason...

> @@ -325,20 +321,15 @@ void xstate_init(bool_t bsp)
>  
>  /* Check extended XSAVE features. */
>  cpuid_count(XSTATE_CPUID, 1, , , , );
> -if ( bsp )
> -{
> -cpu_has_xsaveopt = !!(eax & XSTATE_FEATURE_XSAVEOPT);
> -cpu_has_xsavec = !!(eax & XSTATE_FEATURE_XSAVEC);
> -/* XXX cpu_has_xgetbv1 = !!(eax & XSTATE_FEATURE_XGETBV1); */
> -/* XXX cpu_has_xsaves = !!(eax & XSTATE_FEATURE_XSAVES); */
> -}
> -else
> -{
> -BUG_ON(!cpu_has_xsaveopt != !(eax & XSTATE_FEATURE_XSAVEOPT));
> -BUG_ON(!cpu_has_xsavec != !(eax & XSTATE_FEATURE_XSAVEC));
> -/* XXX BUG_ON(!cpu_has_xgetbv1 != !(eax & XSTATE_FEATURE_XGETBV1)); 
> */
> -/* XXX BUG_ON(!cpu_has_xsaves != !(eax & XSTATE_FEATURE_XSAVES)); */
> -}
> +
> +/* Mask out features not currently understood by Xen. */
> +eax &= (cpufeat_mask(X86_FEATURE_XSAVEOPT) |
> +cpufeat_mask(X86_FEATURE_XSAVEC));
> +
> +c->x86_capability[X86_FEATURE_XSAVEOPT / 32] = eax;
> +
> +if ( !bsp )
> +BUG_ON(eax != boot_cpu_data.x86_capability[X86_FEATURE_XSAVEOPT / 
> 32]);
>  }

The !bsp conditional seems pretty pointless. And with the revised
model it looks like it could be relaxed (BUG only when bits the BSP
has set aren't set on the AP).

> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -9,7 +9,7 @@
>  #define __ASM_I386_CPUFEATURE_H
>  #endif
>  
> -#define NCAPINTS 8   /* N 32-bit words worth of info */
> +#define NCAPINTS 9   /* N 32-bit words worth of info */
>  
>  /* Intel-defined CPU features, CPUID level 0x0001 (edx), word 0 */
>  #define X86_FEATURE_FPU  (0*32+ 0) /* Onboard FPU */
> @@ -154,6 +154,12 @@
>  #define X86_FEATURE_ADX  (7*32+19) /* ADCX, ADOX instructions */
>  #define X86_FEATURE_SMAP (7*32+20) /* Supervisor Mode Access Prevention 
> */
>  
> +/* Intel-defined CPU features, CPUID level 0x000D:1 (eax), word 8 */
> +#define X86_FEATURE_XSAVEOPT (8*32+ 0)
> +#define X86_FEATURE_XSAVEC   (8*32+ 1)
> +#define X86_FEATURE_XGETBV1  (8*32+ 2)
> +#define X86_FEATURE_XSAVES   (8*32+ 3)
> +
>  #if !defined(__ASSEMBLY__) && !defined(X86_FEATURES_ONLY)
>  #include 
>  
> @@ -219,6 +225,11 @@
>  
>  #define cpu_has_cx16boot_cpu_has(X86_FEATURE_CX16)
>  
> +#define cpu_has_xsaveopt boot_cpu_has(X86_FEATURE_XSAVEOPT)
> +#define cpu_has_xsavec   boot_cpu_has(X86_FEATURE_XSAVEC)
> +#define cpu_has_xgetbv1  boot_cpu_has(X86_FEATURE_XGETBV1)
> +#define cpu_has_xsaves   boot_cpu_has(X86_FEATURE_XSAVES)
> +
>  enum _cache_type {
>  CACHE_TYPE_NULL = 0,
>  CACHE_TYPE_DATA = 1,
> diff --git a/xen/include/asm-x86/xstate.h b/xen/include/asm-x86/xstate.h
> index 4c690db..f0d8f0b 100644
> --- a/xen/include/asm-x86/xstate.h
> +++ b/xen/include/asm-x86/xstate.h
> @@ -9,16 +9,13 @@
>  #define __ASM_XSTATE_H
>  
>  #include 
> +#include 
>  
>  #define FCW_DEFAULT   0x037f
>  #define FCW_RESET 0x0040
>  #define MXCSR_DEFAULT 0x1f80
>  
>  #define XSTATE_CPUID  0x000d
> -#define XSTATE_FEATURE_XSAVEOPT   (1 << 0)/* sub-leaf 1, eax[bit 0] */
> -#define XSTATE_FEATURE_XSAVEC (1 << 1)/* sub-leaf 1, eax[bit 1] */
> -#define XSTATE_FEATURE_XGETBV1(1 << 2)/* sub-leaf 1, eax[bit 2] */
> -#define XSTATE_FEATURE_XSAVES (1 << 3)/* sub-leaf 1, eax[bit 3] */
>  
>  #define XCR_XFEATURE_ENABLED_MASK 0x  /* index of XCR0 */
>  
> @@ -43,7 +40,6 @@
>  #define XSTATE_LAZY(XSTATE_ALL & ~XSTATE_NONLAZY)
>  
>  extern u64 xfeature_mask;
> -extern bool_t cpu_has_xsaves, cpu_has_xgetbv1;
>  
>  /* extended state save area */
>  struct __packed __attribute__((aligned (64))) xsave_struct
> @@ -91,7 +87,7 @@ struct __packed __attribute__((aligned (64))) xsave_struct
>  /* extended state init and cleanup functions */
>  void xstate_free_save_area(struct vcpu *v);
>  int xstate_alloc_save_area(struct vcpu *v);
> -void xstate_init(bool_t bsp);
> +void xstate_init(struct cpuinfo_x86 *c);
>  unsigned int xstate_ctxt_size(u64 xcr0);
>  
>  #endif /* __ASM_XSTATE_H */
> -- 
> 1.7.10.4



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

Re: [Xen-devel] [PATCH v5 4/9] x86/intel_pstate: relocate the driver register function

[Jan Beulich]

>>> On 17.09.15 at 17:38,  wrote:
> On 14/09/15 03:32, Wei Wang wrote:
>> Move the driver register function to
>> the cpufreq.c.
>>
>> Signed-off-by: Wei Wang 
>> ---
>>  xen/drivers/cpufreq/cpufreq.c  | 15 +++
>>  xen/include/acpi/cpufreq/cpufreq.h | 27 +--
>>  2 files changed, 16 insertions(+), 26 deletions(-)
>>
>>  changes in v5:
>>  1) keep cpufreq_presmp_init() intact.
>>
>> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
>> index 567e9e9..0c437d4 100644
>> --- a/xen/drivers/cpufreq/cpufreq.c
>> +++ b/xen/drivers/cpufreq/cpufreq.c
>> @@ -638,3 +638,18 @@ static int __init cpufreq_presmp_init(void)
>>  }
>>  presmp_initcall(cpufreq_presmp_init);
>>  
>> +int cpufreq_register_driver(struct cpufreq_driver *driver_data)
>> +{
>> +   if ( !driver_data || !driver_data->init ||
>> +!driver_data->verify || !driver_data->exit ||
>> +(!driver_data->target == !driver_data->setpolicy) )
> 
> This line will incur the wrath of newer GCC's which have warnings
> against such logic.

Hmm, I think we have other instances of such, without gcc
complaining. Iirc there was a bug in an early 5.0-rc which got
fixed in the final 5.1.0.

> Either bracket the (!driver_data->$X) or alter the logic itself.

I'd prefer to avoid either change.

Jan


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

Re: [Xen-devel] [OSSTEST PATCH 15/26] cr*: Support xen-unstable-smoke

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 15/26] cr*: Support 
xen-unstable-smoke"):
> On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote:
> > Add this branch to select_xenbranch.  This works like xen-unstable in
> > most respects.
> > 
> > There are only two places in osstest where xenbranch `xen-unstable' is
> > treated specially and only one of them needs adjusting to match
> > xen-unstable-smoke too.
> 
> The included one is the one which adds the qemu revisions?

No, this in cr-daily-branch:

if [ "x$branch" != "xxen-unstable" ]; then
export REVISION_LINUX_OLD=disable
fi

> And the other one is, I think, the thing which sets
>  REVISION_LINUX_OLD=disable which we want (or maybe don't care about) for
> the smoked tests. So good.

Indeed.

I'm not sure what the qemu revisions thing is you're thinking of but I
think all the places where the source code matches `xen-unstable[^-]',
the actual effect is to treat `xen-unstable-smoke' the same way as
`xen-unstable'.

> Acked-by: Ian Campbell 

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 2/2] xen: arm: traps: correct cond

[Peng Fan]

On Mon, Sep 21, 2015 at 11:10:11AM +0100, Julien Grall wrote:
>Hi Peng,
>
>On 21/09/15 08:07, Peng Fan wrote:
>> From "G6.2.29 CPSR, Current Program Status Register" of Aarch64 ARM
>> and "B1.3.3 Program Status Registers (PSRs)" of ARMv7-A ARM:
>> "
>
>The section number may change between the different version of the spec.
>Can you also precise the spec version?
>
>For instance on my ARM64 spec (ARM DDI 0497A.d) the section G6.2.29
>points to "CSSELR" and not "CPSR".
>
>> IT[7:5] holds the base condition for the IT block. The base condition is
>> the top 3 bits of the condition code specified by the first
>>  condition field of the IT instruction.
>> IT[4:0] encodes the size of the IT block, which is the number of
>> instructions that are to be conditionally executed, by the
>>  position of the least significant 1 in this field. It also
>>  encodes the value of the least significant bit of the condition
>>  code for each instruction in the block.
>> "
>> So should be "cond = ( it >> 5 );" but not "cond = ( it >> 4 );"
>
>IT[7:5] encodes the top 3 bits of the condition code and one bit of
>IT[4:0] will contain the least significant bit of the condition code.
>
>In order to get the full condition code you have to use IT[7:4] which
>the current code does (see A2.5.2 ARM DDI 0406C.b).
>
>So the current code looks valid to me. Did I miss something?

No, you are correct.

Thanks,
Peng.

>
>Regards,
>
>> Signed-off-by: Peng Fan 
>> Cc: Ian Campbell 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>>  xen/arch/arm/traps.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 2e2b1f2..b2879b7 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -1561,8 +1561,8 @@ static int check_conditional_instr(struct 
>> cpu_user_regs *regs,
>>  if ( it == 0 )
>>  return 1;
>>  
>> -/* The cond for this instruction works out as the top 4 bits. */
>> -cond = ( it >> 4 );
>> +/* The cond for this instruction works out as the top 3 bits. */
>> +cond = ( it >> 5 );
>>  }
>>  
>>  cpsr_cond = cpsr >> 28;
>> 
>
>-- 
>Julien Grall

-- 

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

Re: [Xen-devel] [OSSTEST PATCH 19/26] ts-debian-hvm-install: Cope with images containing only isolinux

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 19/26] ts-debian-hvm-install: Cope 
with images containing only isolinux"):
> On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote:
> > debian-7.2.0-i386-CD-1.iso contains no grub, only isolinux.
...
> I'm happy to determine experimentally (i.e. by pushing to pretest) if there
> is any meaning to the order of these (the wiki has them the new way around,
> so I presume not).

My tests (which I left running) have determined that this patch was
wrong in the amd64 case: it would work, but by falling back to
isolinux.

This is because $newiso is not populated at the time $bootfile is
determined.  I think this is fairly easily fixed by reordering things
and I will send an update when I have got something that actually
works in both cases.

(This affects the EFI partition creation too, but shouldn't involve
any change to that patch except maybe to context.)

> > +my $bootfile = 'boot/grub/efi.img';
> > +if (!target_file_exists($ho, "$newiso/$bootfile")) {
> > +   $bootfile = "isolinux/isolinux.bin";
> > +   push @isogen_extra, qw(-c isolinux/boot.cat);
> > +}
> 
> My preference would have been to produce an iso which was bootable either
> via EFI (grub) or legacy (isolinux), but that would require more complex
> command lines and I'm sure neither of us wants to figure out what those
> are. So:

Yes.

> Acked-by: Ian Campbell 

Thanks, but given the circmstances I am not going to apply this ack to
whatever revised version I produce.

Ian.

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

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Jan Beulich]

>>> On 21.09.15 at 11:46,  wrote:
>>> >>> On 21.09.15 at 16:51, < jbeul...@suse.com > wrote:
>>- Anything else?
> 
> 
> Just test the extreme case. The ATS specification mandates a timeout of 1 
> _minute_ for cache flush, even though it doesn't take so much time for cache 
> flush.
> In my design, if the Device-TLB is not completed, the domain's vCPUs are not 
> allowed entry guest mode (patch #7), otherwise, the logic is not correct.

Hmm, that would be a serious limitation, and I can't immediately
see a reason: Taking this with virtualization removed, I don't
think such an invalidation would stall a physical CPU for a whole
minute. Sadly I also can't immediately think of a solution, but I
guess first of all I'll have to take a look at the series (which
unfortunately may take a few days to get to).

Jan


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

Re: [Xen-devel] [xen-4.4-testing test] 62047: regressions - FAIL

[Jan Beulich]

>>> On 18.09.15 at 08:53,  wrote:
> flight 62047 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62047/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 
> 60727
>  test-amd64-i386-xl-qcow2  9 debian-di-install fail REGR. vs. 
> 60727

Is there a reason why various other debian-di-install tests are
in the allowable regressions section below, but not these two? I
remember having looked at such failures before, without it
really becoming clear to me what is going wrong there.

> Regressions which are regarded as allowable (not blocking):
>  test-amd64-i386-libvirt-vhd   9 debian-di-install fail REGR. vs. 
> 60727
>  test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 
> 60727
>  test-amd64-amd64-libvirt-raw  9 debian-di-install fail REGR. vs. 
> 60727
>  test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeatfail  like 
> 60696
>  test-amd64-i386-xl-vhd9 debian-di-installfail   like 
> 60727
>  test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  like 
> 60727
>  test-amd64-i386-libvirt  11 guest-start  fail   like 
> 60727
>  test-amd64-amd64-xl-vhd   9 debian-di-installfail   like 
> 60727
>  test-amd64-amd64-libvirt 11 guest-start  fail   like 
> 60727
>  test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 
> 60727

Thanks, Jan


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

Re: [Xen-devel] xhci_hcd intterrupt affinity in Dom0/DomU limited to single interrupt

[Jan Beulich]

>>> On 16.09.15 at 22:31,  wrote:
> I think the lspci -v output is the same in both cases with the exception
> of the xhci_pci which is not present in the Native case lspci -v output.
> xhci_pci is built into the kernel. The same kernel/system is used with
> this system when booted with Dom0 and native cases. I could rebuild the
> kernel without it and see what happens? 

No point in doing so, the only lines we're interesting in here are ...

> Native:
> 
> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB xHCI (rev 05) (prog-if 30 [XHCI])
>   Subsystem: Intel Corporation 8 Series/C220 Series Chipset Family USB
> xHCI
>   Flags: bus master, medium devsel, latency 0, IRQ 27
>   Memory at f7e2 (64-bit, non-prefetchable) [size=64K]
>   Capabilities: [70] Power Management version 2
>   Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+

... this and ...

>   Kernel driver in use: xhci_hcd
> 
> 
> 
> Dom0:
> 
> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB xHCI (rev 05) (prog-if 30 [XHCI])
>   Subsystem: Intel Corporation 8 Series/C220 Series Chipset Family USB
> xHCI
>   Flags: bus master, medium devsel, latency 0, IRQ 76
>   Memory at f7e2 (64-bit, non-prefetchable) [size=64K]
>   Capabilities: [70] Power Management version 2
>   Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+

... this. Them being identical proves what I suspected: The driver
uses only a single interrupt.

Jan


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

Re: [Xen-devel] [PATCH V2 0/2] Introspection optimization helpers

[Razvan Cojocaru]

Hello,

This doesn't have much to do with this series, but when running
scripts/get-maintainer.pl on my patches, I got "Stefano Stabellini
" for my first patch, and "Stefano
Stabellini " for the second one (i.e. the
second address is missing the ".eu" part).

I don't know if this is intended, so this is a heads-up.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v6 2/2] xen/arm: support gzip compressed kernels

[Julien Grall]

Hi Stefano,

On 21/09/2015 23:51, Stefano Stabellini wrote:

Changes in v6:
- use vmap to map pages
- free old module and update mod->start and mod->size from
kernel_decompress


I was expecting you to drop my Reviewed-by given those changes.


diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f641b12..ad7e6bc 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c


[...]



+static __init uint32_t output_length(char *image, unsigned long image_len)
+{
+return *(uint32_t *)[image_len - 4];
+}
+
+static __init int kernel_decompress(struct bootmodule *mod)
+{


[...]


+mfn = _mfn(page_to_mfn(pages));
+output = __vmap(, 1 << kernel_order_out, 1, 1, PAGE_HYPERVISOR);


You may want to use vmap here which is a wrapper to __vmap and will 
setup the granularity, align, and flags automatically for you.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 2/2] xen/arm: support gzip compressed kernels

[Stefano Stabellini]

On Tue, 22 Sep 2015, Julien Grall wrote:
> Hi Stefano,
> 
> On 21/09/2015 23:51, Stefano Stabellini wrote:
> > Changes in v6:
> > - use vmap to map pages
> > - free old module and update mod->start and mod->size from
> > kernel_decompress
> 
> I was expecting you to drop my Reviewed-by given those changes.

fair enough


> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index f641b12..ad7e6bc 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> 
> [...]
> 
> 
> > +static __init uint32_t output_length(char *image, unsigned long image_len)
> > +{
> > +return *(uint32_t *)[image_len - 4];
> > +}
> > +
> > +static __init int kernel_decompress(struct bootmodule *mod)
> > +{
> 
> [...]
> 
> > +mfn = _mfn(page_to_mfn(pages));
> > +output = __vmap(, 1 << kernel_order_out, 1, 1, PAGE_HYPERVISOR);
> 
> You may want to use vmap here which is a wrapper to __vmap and will setup the
> granularity, align, and flags automatically for you.
 
The arguments are different.

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

[Xen-devel] [PATCH v6 2/2] xen/arm: support gzip compressed kernels

[Stefano Stabellini]

Free the memory used for the compressed kernel and update the relative
mod->start and mod->size parameters with the uncompressed ones.

To decompress the kernel, allocate memory from dommheap, because freeing
the modules is done by calling init_heap_pages, which frees to domheap.
Map these pages using vmap, because they might not be in the linear 1:1
map.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Julien Grall 
CC: ian.campb...@citrix.com

---

Changes in v6:
- use vmap to map pages
- free old module and update mod->start and mod->size from
kernel_decompress

Changes in v5:
- code style

Changes in v4:
- return uint32_t from output_length
- __init kernel_decompress
- code style
- add comment
- if kernel_decompress fails with error, return

Changes in v3:
- better error checks in kernel_decompress
- free unneeded pages between output_size and kernel_order_out
- alloc pages from domheap

Changes in v2:
- use gzip_check
- avoid useless casts
- free original kernel image and update the mod with the new address and
size
- remove changes to common Makefile
- remove CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
---
 xen/arch/arm/kernel.c   |   89 ++-
 xen/arch/arm/setup.c|2 +-
 xen/include/asm-arm/setup.h |2 +
 3 files changed, 83 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f641b12..ad7e6bc 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "kernel.h"
 
@@ -257,6 +259,74 @@ static int kernel_uimage_probe(struct kernel_info *info,
 return 0;
 }
 
+static __init uint32_t output_length(char *image, unsigned long image_len)
+{
+return *(uint32_t *)[image_len - 4];
+}
+
+static __init int kernel_decompress(struct bootmodule *mod)
+{
+char *output, *input;
+char magic[2];
+int rc;
+unsigned kernel_order_out;
+paddr_t output_size;
+struct page_info *pages;
+mfn_t mfn;
+int i;
+paddr_t addr = mod->start;
+paddr_t size = mod->size;
+
+if ( size < 2 )
+return -EINVAL;
+
+copy_from_paddr(magic, addr, sizeof(magic));
+
+/* only gzip is supported */
+if ( !gzip_check(magic, size) )
+return -EINVAL;
+
+input = ioremap_cache(addr, size);
+if ( input == NULL )
+return -EFAULT;
+
+output_size = output_length(input, size);
+kernel_order_out = get_order_from_bytes(output_size);
+pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
+if ( pages == NULL )
+{
+iounmap(input);
+return -ENOMEM;
+}
+mfn = _mfn(page_to_mfn(pages));
+output = __vmap(, 1 << kernel_order_out, 1, 1, PAGE_HYPERVISOR);
+
+rc = perform_gunzip(output, input, size);
+clean_dcache_va_range(output, output_size);
+iounmap(input);
+
+/* 
+ * Need to free pages after output_size here because they won't be
+ * freed by discard_initial_modules
+ */
+i = (output_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
+for ( ; i < (1 << kernel_order_out); i++ )
+free_domheap_page(pages + i);
+
+vunmap(output);
+
+/* 
+ * Free the original kernel, update the pointers to the
+ * decompressed kernel
+ */
+dt_unreserved_regions(mod->start, mod->start + mod->size,
+  init_domheap_pages, 0);
+mod->start = page_to_maddr(pages);
+mod->size = output_size;
+
+return 0;
+}
+
 #ifdef CONFIG_ARM_64
 /*
  * Check if the image is a 64-bit Image.
@@ -444,8 +514,6 @@ int kernel_probe(struct kernel_info *info)
 struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
 int rc;
 
-paddr_t start, size;
-
 if ( !mod || !mod->size )
 {
 printk(XENLOG_ERR "Missing kernel boot module?\n");
@@ -453,25 +521,28 @@ int kernel_probe(struct kernel_info *info)
 }
 
 info->kernel_bootmodule = mod;
-start = mod->start;
-size = mod->size;
 
-printk("Loading kernel from boot module @ %"PRIpaddr"\n", start);
+printk("Loading kernel from boot module @ %"PRIpaddr"\n", mod->start);
 
 info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
 if ( info->initrd_bootmodule )
 printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
info->initrd_bootmodule->start);
 
+/* if it is a gzip'ed image, 32bit or 64bit, uncompress it */
+rc = kernel_decompress(mod);
+if (rc < 0 && rc != -EINVAL)
+return rc;
+
 #ifdef CONFIG_ARM_64
-rc = kernel_zimage64_probe(info, start, size);
+rc = kernel_zimage64_probe(info, mod->start, mod->size);
 if (rc < 0)
 #endif
-rc = kernel_uimage_probe(info, start, size);
+rc = kernel_uimage_probe(info, mod->start, mod->size);
 if (rc < 0)
-rc = kernel_zimage32_probe(info, start, size);
+rc = kernel_zimage32_probe(info, mod->start, 

[Xen-devel] [PATCH v6 1/2] xen: move perform_gunzip to common

[Stefano Stabellini]

The current gunzip code to decompress the Dom0 kernel is implemented in
inflate.c which is included by bzimage.c.

I am looking to doing the same on ARM64 but there is quite a bit of
boilerplate definitions that I would need to import in order for
inflate.c to work correctly.

Instead of copying/pasting the code from x86/bzimage.c, move those
definitions to a new common file, gunzip.c. Export only perform_gunzip
and gzip_check. Leave output_length where it is.

Signed-off-by: Stefano Stabellini 
Acked-by: Jan Beulich 
CC: andrew.coop...@citrix.com

---
Changes in v4:
- move gunzip.init.o to its alphabetically correct place

Changes in v3:
- build gunzip.c as gunzip.init.o
- remove #include 
- remove __init from declarations

Changes in v2:
- the patch has been reworked from scratch
---
 xen/arch/x86/bzimage.c   |  134 +
 xen/common/Makefile  |1 +
 xen/common/gunzip.c  |  137 ++
 xen/include/xen/gunzip.h |7 +++
 4 files changed, 146 insertions(+), 133 deletions(-)
 create mode 100644 xen/common/gunzip.c
 create mode 100644 xen/include/xen/gunzip.h

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index c86c39e..50ebb84 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -4,148 +4,16 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
-#define HEAPORDER 3
-
-static unsigned char *__initdata window;
-#define memptr long
-static memptr __initdata free_mem_ptr;
-static memptr __initdata free_mem_end_ptr;
-
-#define WSIZE   0x8000
-
-static unsigned char *__initdata inbuf;
-static unsigned __initdata insize;
-
-/* Index of next byte to be processed in inbuf: */
-static unsigned __initdata inptr;
-
-/* Bytes in output buffer: */
-static unsigned __initdata outcnt;
-
-#define OF(args)args
-#define STATIC  static
-
-#define memzero(s, n)   memset((s), 0, (n))
-
-typedef unsigned char   uch;
-typedef unsigned short  ush;
-typedef unsigned long   ulg;
-
-#define INIT__init
-#define INITDATA__initdata
-
-#define get_byte()  (inptr < insize ? inbuf[inptr++] : fill_inbuf())
-
-/* Diagnostic functions */
-#ifdef DEBUG
-#  define Assert(cond, msg) do { if (!(cond)) error(msg); } while (0)
-#  define Trace(x)  do { fprintf x; } while (0)
-#  define Tracev(x) do { if (verbose) fprintf x ; } while (0)
-#  define Tracevv(x)do { if (verbose > 1) fprintf x ; } while (0)
-#  define Tracec(c, x)  do { if (verbose && (c)) fprintf x ; } while (0)
-#  define Tracecv(c, x) do { if (verbose > 1 && (c)) fprintf x ; } while (0)
-#else
-#  define Assert(cond, msg)
-#  define Trace(x)
-#  define Tracev(x)
-#  define Tracevv(x)
-#  define Tracec(c, x)
-#  define Tracecv(c, x)
-#endif
-
-static long __initdata bytes_out;
-static void flush_window(void);
-
-static __init void error(char *x)
-{
-panic("%s", x);
-}
-
-static __init int fill_inbuf(void)
-{
-error("ran out of input data");
-return 0;
-}
-
-
-#include "../../common/inflate.c"
-
-static __init void flush_window(void)
-{
-/*
- * The window is equal to the output buffer therefore only need to
- * compute the crc.
- */
-unsigned long c = crc;
-unsigned n;
-unsigned char *in, ch;
-
-in = window;
-for ( n = 0; n < outcnt; n++ )
-{
-ch = *in++;
-c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
-}
-crc = c;
-
-bytes_out += (unsigned long)outcnt;
-outcnt = 0;
-}
-
 static __init unsigned long output_length(char *image, unsigned long image_len)
 {
 return *(uint32_t *)[image_len - 4];
 }
 
-static __init int gzip_check(char *image, unsigned long image_len)
-{
-unsigned char magic0, magic1;
-
-if ( image_len < 2 )
-return 0;
-
-magic0 = (unsigned char)image[0];
-magic1 = (unsigned char)image[1];
-
-return (magic0 == 0x1f) && ((magic1 == 0x8b) || (magic1 == 0x9e));
-}
-
-static __init int perform_gunzip(char *output, char *image, unsigned long 
image_len)
-{
-int rc;
-
-if ( !gzip_check(image, image_len) )
-return 1;
-
-window = (unsigned char *)output;
-
-free_mem_ptr = (unsigned long)alloc_xenheap_pages(HEAPORDER, 0);
-free_mem_end_ptr = free_mem_ptr + (PAGE_SIZE << HEAPORDER);
-
-inbuf = (unsigned char *)image;
-insize = image_len;
-inptr = 0;
-
-makecrc();
-
-if ( gunzip() < 0 )
-{
-rc = -EINVAL;
-}
-else
-{
-rc = 0;
-}
-
-free_xenheap_pages((void *)free_mem_ptr, HEAPORDER);
-
-return rc;
-}
-
 struct __packed setup_header {
 uint8_t _pad0[0x1f1];   /* skip uninteresting stuff */
 uint8_t setup_sects;
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 3fdf931..e681aaa 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -10,6 +10,7 @@ obj-y += 

[Xen-devel] [PATCH v6 0/2] support gzipped kernels on arm

[Stefano Stabellini]

Hi all,

this patch series introduces support for gzipped kernels, such as the
standard Image.gz format used by Linux on arm64 by default, in Xen on
arm. Without it, Xen cannot load the default kernel shipped by distros,
such as CentOS 7.


Stefano Stabellini (2):
  xen: move perform_gunzip to common
  xen/arm: support gzip compressed kernels

 xen/arch/arm/kernel.c   |   89 +---
 xen/arch/arm/setup.c|2 +-
 xen/arch/x86/bzimage.c  |  134 +-
 xen/common/Makefile |1 +
 xen/common/gunzip.c |  137 +++
 xen/include/asm-arm/setup.h |2 +
 xen/include/xen/gunzip.h|7 +++
 7 files changed, 229 insertions(+), 143 deletions(-)
 create mode 100644 xen/common/gunzip.c
 create mode 100644 xen/include/xen/gunzip.h

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Jan Beulich]

>>> Ed Swierk  09/21/15 6:01 PM >>>
>The fundamental problem is that Xen tries to access extended config
>space in pci_add_device(), before the Dom0 finally figures out where
>MMCONFIG area is and makes the pci_mmcfg_reserved hypercall. The only
>robust solution seems to be for Xen to defer extended config space
>accesses. It's not clear to me how late is late enough, however.

I don't follow: Surely Dom0 first establishes MCFG areas to be used, and
only then scans the buses for devices, resulting in them to be reported to
the hypervisor?

Jan


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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  09/21/15 8:06 PM >>>
>- Never figured out how much data we should save in the Xen's
>struct pci_device to see if we are 'stale'. Looking back I think
>we just need to do the interogation of the PCI capabilities and see
>if they have somehow changed (the ones we care about).

Didn't we settle on no data to be needed here at all, instead requiring Dom0
to report devices removed on buses about to be re-numbered, adding them
back after the re-numbering?

Jan


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

Re: [Xen-devel] [PATCH v7 15/28] xen/arm: ITS: Add virtual ITS driver

[Julien Grall]

Hi Vijay,

On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> This patch introduces virtual ITS driver with following
> functionality
>  - Introduces helper functions to manage device table and
>ITT table in guest memory
>  - Helper function to handle virtual ITS devices assigned
>to domain
> 
> Signed-off-by: Vijaya Kumar K 

Reviewed-by: Julien Grall 

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH 0/2] GICv3: Clean up + enable support on GICv4

[Julien Grall]

Hi Ian,

I think this series is all acked. Would it be possible to merge it in
unstable?

Regards,

On 14/09/15 16:32, Julien Grall wrote:
> Hi all,
> 
> This small patch series allow Xen to run on platform reporting GICv4
> in the GIC*_PIDR2.
> 
> Sincerely yours,
> 
> Julien Grall (2):
>   xen/arm: gic-v3: Clean-up the GIC*_PIDR2_* definitions
>   xen/arm: gic-v3: Allow Xen to run on hardware reporting GICv4
> 
>  xen/arch/arm/gic-v3.c |  8 
>  xen/include/asm-arm/gic_v3_defs.h | 13 +
>  2 files changed, 9 insertions(+), 12 deletions(-)
> 


-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Ed Swierk]

After testing this change on different platforms, I'm finding some
complications.

As I understand it, the BIOS is supposed to mark the MMCONFIG area
reserved in the E820 table no matter what. And if the ACPI DSDT
includes an MCFG record, then it should also include a PNP0C0x record
for the MMCONFIG area.

Some BIOSes do just one of these. For example, the Intel S2600GL/GZ
BIOS has the correct ACPI records, but does not have the area reserved
in the E820 table. Linux is forgiving enough to use the MMCONFIG area
in this case.

Other BIOSes do neither. For example, the Intel S2600WT BIOS doesn't
even include the PNP0C0x record in the ACPI table, when TXT is
enabled. On this platform the only way to get Linux to see extended
config space at all is by passing memmap=256M$0x8000 on the kernel
command line.

My change works in the latter case, since the memmap parameter causes
it to add the MMCONFIG area in pci_arch_init(). But in the former
case, where the ACPI tables aren't parsed until acpi_init(),
xen_mcfg_late() must come later, unless you also use the memmap kernel
command line parameter.

The fundamental problem is that Xen tries to access extended config
space in pci_add_device(), before the Dom0 finally figures out where
MMCONFIG area is and makes the pci_mmcfg_reserved hypercall. The only
robust solution seems to be for Xen to defer extended config space
accesses. It's not clear to me how late is late enough, however.

--Ed


On Tue, Sep 15, 2015 at 4:29 PM, Ed Swierk  wrote:
> On systems where the ACPI DSDT advertises the PCI MMCONFIG area but the
> E820 table does not reserve it, it's up to Dom0 to inform Xen via
> PHYSDEVOP_pci_mmcfg_reserved.  This needs to happen before Xen tries to
> access extended capabilities like SRIOV in pci_add_device(), which is
> triggered when Linux enumerates PCI devices in acpi_init().  Changing
> xen_mcfg_late() to arch_initcall_sync ensures it gets called before
> acpi_init(), but after pci_mmcfg_list is populated by pci_arch_init().
>
> Without this change, Xen 4.4 and 4.5 emit WARN messsages from
> msix_capability_init() when setting up Intel 82599 VFs, since vf_rlen has
> not been initialized by pci_add_device().  And on Xen 4.5, Xen nukes the
> DomU due to "Potentially insecure use of MSI-X" when the VF driver loads
> in the DomU.  Both problems are fixed by this change.
>
> Signed-off-by: Ed Swierk 
> ---
>  drivers/xen/pci.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> index 7494dbe..7b5bbdb 100644
> --- a/drivers/xen/pci.c
> +++ b/drivers/xen/pci.c
> @@ -253,7 +253,9 @@ static int __init xen_mcfg_late(void)
> return 0;
>  }
>  /*
> - * Needs to be done after acpi_init which are subsys_initcall.
> + * Needs to be called after pci_arch_init (arch_initcall) populates
> + * pci_mmcfg_list, but before acpi_init (subsys_initcall) triggers
> + * pci_add_device() in Xen, since the latter probes extended capabilities.
>   */
> -subsys_initcall_sync(xen_mcfg_late);
> +arch_initcall_sync(xen_mcfg_late);
>  #endif
> --
> 1.9.1
>

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

Re: [Xen-devel] [PATCH OSSTEST] Debian: handle move of ip(8) to /sbin in Jessie

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST] Debian: handle move of ip(8) to /sbin in 
Jessie"):
> Unfortunately udev treats non-absolute commands as relative to
> /lib/udev rather than consulting $PATH, so we have to figure out the
> path based on the suite.

Bah.

Tempting to say `use env(1)' but of course that's in /usr.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH OSSTEST] Debian: Avoid uninitialised string warn when getting host firmware property

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST] Debian: Avoid uninitialised string warn 
when getting host firmware property"):
> Signed-off-by: Ian Campbell 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

[Stefano Stabellini]

It is going to be in QEMU 2.5 and qemu-xen 4.7.

On Mon, 21 Sep 2015, Chen, Tiejun wrote:
> Stefano,
> 
> I have two questions,
> 
> #1. Which qemu version is this igd stuff going into? 2.6?
> #2. Is this igd stuff going into qemu-xen inside xen? Any plan to go into xen
> 4.6?
> 
> Thanks
> Tiejun
> 
> On 9/9/2015 1:21 AM, Stefano Stabellini wrote:
> > The following changes since commit 8611280505119e296757a60711a881341603fa5a:
> > 
> >target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
> > 
> > are available in the git repository at:
> > 
> >git://xenbits.xen.org/people/sstabellini/qemu-dm.git
> > tags/xen-2015-09-08-tag
> > 
> > for you to fetch changes up to ba2250ad148997b1352aba976aac66b55410e7e4:
> > 
> >xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings.
> > (2015-09-08 15:21:56 +)
> > 
> > 
> > Xen branch xen-2015-09-08
> > 
> > 
> > Don Slutz (1):
> >xen-hvm: Add trace to ioreq
> > 
> > Jan Beulich (1):
> >xen/HVM: atomically access pointers in bufioreq handling
> > 
> > Konrad Rzeszutek Wilk (7):
> >xen-hvm: When using xc_domain_add_to_physmap also include errno when
> > reporting
> >xen/pt: Update comments with proper function name.
> >xen/pt: Make xen_pt_msi_set_enable static
> >xen/pt: xen_host_pci_config_read returns -errno, not -1 on failure
> >xen: use errno instead of rc for xc_domain_add_to_physmap
> >xen/pt/msi: Add the register value when printing logging and error
> > messages
> >xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings.
> > 
> > Michael S. Tsirkin (1):
> >i440fx: make types configurable at run-time
> > 
> > Tiejun Chen (9):
> >pc_init1: pass parameters just with types
> >piix: create host bridge to passthrough
> >hw/pci-assign: split pci-assign.c
> >xen, gfx passthrough: basic graphics passthrough support
> >xen, gfx passthrough: retrieve VGA BIOS to work
> >igd gfx passthrough: create a isa bridge
> >xen, gfx passthrough: register a isa bridge
> >xen, gfx passthrough: register host bridge specific to passthrough
> >xen, gfx passthrough: add opregion mapping
> > 
> >   configure |   28 +
> >   hw/core/machine.c |   20 +++
> >   hw/i386/Makefile.objs |1 +
> >   hw/i386/kvm/pci-assign.c  |   82 ++---
> >   hw/i386/pc_piix.c |  139 -
> >   hw/i386/pci-assign-load-rom.c |   93 ++
> >   hw/pci-host/piix.c|   91 +-
> >   hw/xen/Makefile.objs  |1 +
> >   hw/xen/xen-host-pci-device.c  |5 +
> >   hw/xen/xen-host-pci-device.h  |1 +
> >   hw/xen/xen_pt.c   |   42 ++-
> >   hw/xen/xen_pt.h   |   22 +++-
> >   hw/xen/xen_pt_config_init.c   |   59 -
> >   hw/xen/xen_pt_graphics.c  |  272
> > +
> >   hw/xen/xen_pt_msi.c   |2 +-
> >   include/hw/boards.h   |1 +
> >   include/hw/i386/pc.h  |9 +-
> >   include/hw/pci/pci-assign.h   |   27 
> >   include/hw/xen/xen_common.h   |   34 +-
> >   qemu-options.hx   |3 +
> >   trace-events  |7 ++
> >   vl.c  |   10 ++
> >   xen-hvm.c |   55 +++--
> >   23 files changed, 891 insertions(+), 113 deletions(-)
> >   create mode 100644 hw/i386/pci-assign-load-rom.c
> >   create mode 100644 hw/xen/xen_pt_graphics.c
> >   create mode 100644 include/hw/pci/pci-assign.h
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> > 
> 

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

Re: [Xen-devel] [PATCH v7 14/28] xen/arm: ITS: Initialize physical ITS and export lpi support

[Julien Grall]

Hi Vijay,

On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Initialize physical ITS if HW supports LPIs.
> 
> Signed-off-by: Vijaya Kumar K 
> ---
> v7: - Export lpi support information to vgic-v3 driver from gic-v3.
> - Drop gic_lpi_supported() helper function
> - Add boot param to enable or disable physical ITS
> v6: - Updated lpi_supported gic_info member for GICv2 and GICv3
> - Introduced helper gic_lpi_supported() and exported
> v5: - Made check of its dt node availability before
>   setting lpi_supported flag
> ---
>  xen/arch/arm/gic-v3.c |   38 
> ++---
>  xen/arch/arm/vgic-v3.c|5 -
>  xen/include/asm-arm/gic_v3_defs.h |4 +++-
>  xen/include/asm-arm/vgic.h|2 +-
>  4 files changed, 43 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index c4c77a7..ac8a0ea 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -55,6 +55,18 @@ static struct {
>  } gicv3;
>  
>  static struct gic_info gicv3_info;
> +/* Enable/Disable ITS support */
> +static bool_t its_enable  = 1;
> +/* Availability of ITS support after successful ITS initialization */
> +static bool_t its_enabled = 0;
> +
> +static void __init parse_its_param(char *s)
> +{
> +if ( !parse_bool(s) )
> +its_enable = 0;
> +}
> +
> +custom_param("its", parse_its_param);

Why do you need a command line option to enable/disable the physical ITS?

>  
>  /* per-cpu re-distributor base */
>  DEFINE_PER_CPU(struct rdist, rdist);
> @@ -590,7 +602,7 @@ static void __init gicv3_dist_init(void)
>   * Here we override HW supported number of LPIs and
>   * limit to to LPIs specified in nr_lpis.
>   */
> -if ( gicv3_dist_supports_lpis() )
> +if ( its_enabled && gicv3_dist_supports_lpis() )
>  gicv3_info.nr_irq_ids = nr_lpis + FIRST_GIC_LPI;
>  else
>  {
> @@ -714,6 +726,10 @@ static int __cpuinit gicv3_cpu_init(void)
>  if ( gicv3_enable_redist() )
>  return -ENODEV;
>  
> +/* Give LPIs a spin */
> +if ( its_enabled && gicv3_dist_supports_lpis() )

If the ITS is not enabled, the list of ITS nodes will be empty and
therefore its_cpu_init will return directly.

So its_enabled is not necessary.

> +its_cpu_init();
> +
>  /* Set priority on PPI and SGI interrupts */
>  priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI << 8 |
>  GIC_PRI_IPI);
> @@ -1303,14 +1319,30 @@ static int __init gicv3_init(void)
> i, r->base, r->base + r->size);
>  }
>  
> -vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
> - gicv3.rdist_stride);
> +reg = readl_relaxed(GICD + GICD_TYPER);
> +
> +gicv3.rdist_data.id_bits = ((reg >> GICD_TYPE_ID_BITS_SHIFT) &
> +GICD_TYPE_ID_BITS_MASK) + 1;
> +
>  gicv3_init_v2(node, dbase);
>  
>  spin_lock_init();
>  
>  spin_lock();
>  
> +if ( its_enable && gicv3_dist_supports_lpis() )
> +{
> +/*
> + * LPI support is enabled only if HW supports it and
> + * ITS dt node is available
> + */
> +if ( !its_init(_data) )
> +its_enabled = 1;
> +}
> +
> +vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
> + gicv3.rdist_stride, its_enabled);
> +

Why do you need to execute all this new code with the gicv3.lock taken?
AFAICT there is no use of GICv3 registers inside the ITS initialization.

>  gicv3_dist_init();
>  res = gicv3_cpu_init();
>  gicv3_hyp_init();
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 12c5d87..52d4277 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -51,6 +51,8 @@
>  
>  static struct {
>  bool_t enabled;
> +/* Check if its supported */
> +bool_t lpi_support;

While ITS means LPIs is supported, the invert is not true.
Can you please rename this variable to its_enabled.

>  /* Distributor interface address */
>  paddr_t dbase;
>  /* Re-distributor regions */
> @@ -62,9 +64,10 @@ static struct {
>  void vgic_v3_setup_hw(paddr_t dbase,
>unsigned int nr_rdist_regions,
>const struct rdist_region *regions,
> -  uint32_t rdist_stride)
> +  uint32_t rdist_stride, bool_t lpi_support)

Ditto.

>  {
>  vgic_v3_hw.enabled = 1;
> +vgic_v3_hw.lpi_support = lpi_support;

Ditto.

>  vgic_v3_hw.dbase = dbase;
>  vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
>  vgic_v3_hw.regions = regions;
> diff --git a/xen/include/asm-arm/gic_v3_defs.h 
> b/xen/include/asm-arm/gic_v3_defs.h
> index 1bc88f6..f819589 100644
> --- a/xen/include/asm-arm/gic_v3_defs.h
> +++ b/xen/include/asm-arm/gic_v3_defs.h
> @@ -46,7 +46,9 

Re: [Xen-devel] [PATCH] xen/x86: Don't try to write syscall-related MSRs for PV guests

[Konrad Rzeszutek Wilk]

On Mon, Sep 21, 2015 at 09:09:28AM -0400, Boris Ostrovsky wrote:
> For PV guests these registers are set up by hypervisor and thus
> should not be written by the guest. The comment in xen_write_msr_safe()
> says so but we still write the MSRs, causing the hypervisor to
> print a warning.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Konrad Rzeszutek Wilk 

> ---
>  arch/x86/xen/enlighten.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 30d12af..1f1dbd2 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1077,6 +1077,7 @@ static int xen_write_msr_safe(unsigned int msr, 
> unsigned low, unsigned high)
>   /* Fast syscall setup is all done in hypercalls, so
>  these are all ignored.  Stub them out here to stop
>  Xen console noise. */
> + break;
>  
>   default:
>   if (!pmu_msr_write(msr, low, high, ))
> -- 
> 2.1.0
> 

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

Re: [Xen-devel] [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

[Jan Beulich]

>>> On 04.09.15 at 14:09,  wrote:
> Allow the usage of the VCPUOP_initialise, VCPUOP_up, VCPUOP_down and
> VCPUOP_is_up hypercalls from HVM guests.
> 
> This patch introduces a new structure (vcpu_hvm_context) that should be used
> in conjuction with the VCPUOP_initialise hypercall in order to initialize
> vCPUs for HVM guests.
> 
> Signed-off-by: Roger Pau Monné 
> Signed-off-by: Andrew Cooper 

So this bi-modal thing doesn't look too bad, but a concern I have is
with the now different contexts used by XEN_DOMCTL_setvcpucontext
and VCPUOP_initialise.

> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -752,6 +752,30 @@ int arch_set_info_guest(
>  return 0;
>  }
>  
> +int arch_initialize_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
> +{
> +struct vcpu_guest_context *ctxt;
> +struct domain *d = v->domain;
> +int rc;
> +
> +if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
> +return -ENOMEM;
> +
> +if ( copy_from_guest(ctxt, arg, 1) )
> +{
> +free_vcpu_guest_context(ctxt);
> +return -EFAULT;
> +}
> +
> +domain_lock(d);
> +rc = v->is_initialised ? -EEXIST : arch_set_info_guest(v, ctxt);
> +domain_unlock(d);
> +
> +free_vcpu_guest_context(ctxt);
> +
> +return rc;
> +}

I wonder whether this shouldn't instead be kept in common code,
with arch code calling it as needed (e.g. as default_initialize_vcpu()),
since afaict the code is now duplicate with the x86 side PV handling.

> @@ -1140,6 +1141,201 @@ int arch_set_info_guest(
>  #undef c
>  }
>  
> +/* Called by VCPUOP_initialise for HVM guests. */
> +static int arch_set_info_hvm_guest(struct vcpu *v, vcpu_hvm_context_t *ctx)
> +{
> +struct cpu_user_regs *uregs = >arch.user_regs;
> +struct segment_register cs, ds, ss, tr;
> +
> +#define SEG(s, r)   \
> +(struct segment_register){ .base = (r)->s ## _base, \
> +.limit = (r)->s ## _limit, .attr.bytes = (r)->s ## _ar }
> +
> +switch ( ctx->mode )
> +{
> +default:
> +return -EINVAL;
> +
> +case VCPU_HVM_MODE_16B:

I think "MODE" is misleading here, not just because of the register
size issue (see further down) but also because you don't seem to
enforce the respective mode to be chosen in cs_ar. I'm also missing
at least some simple consistency checks (like CS.DPL == SS.DPL,
rIP within CS limit, rSP within SS limit); leaving these to the first VM
entry would likely result in much harder to analyze issues in case of
bad input.

> +{
> +const struct vcpu_hvm_x86_16 *regs = >cpu_regs.x86_16;
> +
> +uregs->rax= regs->ax;
> +uregs->rcx= regs->cx;
> +uregs->rdx= regs->dx;
> +uregs->rbx= regs->bx;
> +uregs->rsp= regs->sp;
> +uregs->rbp= regs->bp;
> +uregs->rsi= regs->si;
> +uregs->rdi= regs->di;
> +uregs->rip= regs->ip;
> +uregs->rflags = regs->flags;
> +
> +v->arch.hvm_vcpu.guest_cr[0] = regs->cr0;
> +v->arch.hvm_vcpu.guest_cr[4] = regs->cr4;
> +
> +cs = SEG(cs, regs);
> +ds = SEG(ds, regs);
> +ss = SEG(ss, regs);
> +tr = SEG(tr, regs);
> +}
> +break;
> +
> +case VCPU_HVM_MODE_32B:
> +{
> +const struct vcpu_hvm_x86_32 *regs = >cpu_regs.x86_32;
> +
> +uregs->rax= regs->eax;
> +uregs->rcx= regs->ecx;
> +uregs->rdx= regs->edx;
> +uregs->rbx= regs->ebx;
> +uregs->rsp= regs->esp;
> +uregs->rbp= regs->ebp;
> +uregs->rsi= regs->esi;
> +uregs->rdi= regs->edi;
> +uregs->rip= regs->eip;
> +uregs->rflags = regs->eflags;
> +
> +v->arch.hvm_vcpu.guest_cr[0] = regs->cr0;
> +v->arch.hvm_vcpu.guest_cr[3] = regs->cr3;
> +v->arch.hvm_vcpu.guest_cr[4] = regs->cr4;
> +v->arch.hvm_vcpu.guest_efer  = regs->efer;
> +
> +cs = SEG(cs, regs);
> +ds = SEG(ds, regs);
> +ss = SEG(ss, regs);
> +tr = SEG(tr, regs);
> +}
> +break;
> +
> +case VCPU_HVM_MODE_64B:
> +{
> +const struct vcpu_hvm_x86_64 *regs = >cpu_regs.x86_64;
> +
> +uregs->rax= regs->rax;
> +uregs->rcx= regs->rcx;
> +uregs->rdx= regs->rdx;
> +uregs->rbx= regs->rbx;
> +uregs->rsp= regs->rsp;
> +uregs->rbp= regs->rbp;
> +uregs->rsi= regs->rsi;
> +uregs->rdi= regs->rdi;
> +uregs->rip= regs->rip;
> +uregs->rflags = regs->rflags;
> +uregs->r8 = regs->r8;
> +uregs->r9 = regs->r9;
> +uregs->r10= regs->r10;
> +uregs->r11= regs->r11;
> +uregs->r12= regs->r12;
> +uregs->r13= regs->r13;
> +uregs->r14= regs->r14;
> +

Re: [Xen-devel] [PATCH v6 26/29] libxc/xen: introduce a start info structure for HVMlite guests

[Jan Beulich]

>>> On 04.09.15 at 14:09,  wrote:

First of all - I suppose it is intentional for this to not consider the Dom0
side (yet)?

> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -560,7 +560,70 @@ static int alloc_magic_pages_hvm(struct xc_dom_image 
> *dom)
>  xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
>   special_pfn(SPECIALPAGE_SHARING));
>  
> -if ( dom->device_model )
> +if ( !dom->device_model )
> +{
> +struct xc_dom_seg seg;
> +struct hvm_start_info *start_info;
> +char *cmdline;
> +struct hvm_modlist_entry *modlist;
> +void *start_page;
> +size_t cmdline_size = 0;
> +size_t start_info_size = sizeof(*start_info);
> +
> +if ( dom->cmdline )
> +{
> +cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
> +start_info_size += cmdline_size;
> +
> +}
> +if ( dom->ramdisk_blob )
> +start_info_size += sizeof(*modlist); /* Limited to one module. */
> +
> +rc = xc_dom_alloc_segment(dom, , "HVMlite start info", 0,
> +  start_info_size);
> +if ( rc != 0 )
> +{
> +DOMPRINTF("Unable to reserve memory for the start info");
> +goto out;
> +}
> +
> +start_page = xc_map_foreign_range(xch, domid, start_info_size,
> +  PROT_READ | PROT_WRITE,
> +  seg.pfn);
> +if ( start_page == NULL )
> +{
> +DOMPRINTF("Unable to map HVM start info page");
> +goto error_out;
> +}
> +
> +start_info = start_page;
> +cmdline = start_page + sizeof(*start_info);
> +modlist = start_page + sizeof(*start_info) + cmdline_size;
> +
> +if ( dom->cmdline )
> +{
> +strncpy(cmdline, dom->cmdline, MAX_GUEST_CMDLINE);
> +cmdline[MAX_GUEST_CMDLINE - 1] = '\0';
> +start_info->cmdline_paddr = (seg.pfn << PAGE_SHIFT) +

Not knowing much about the tools interface used for allocation
above: Does that interface guarantee this shift (and another
one below) to not overflow?

> +((xen_pfn_t)cmdline - (xen_pfn_t)start_info);

xen_pfn_t? Aren't these byte addresses?

> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -784,6 +784,25 @@ struct start_info {
>  };
>  typedef struct start_info start_info_t;
>  
> +/*
> + * Start of day structure passed to PVH guests in %ebx.
> + */

This is a single line comment.

> +struct hvm_start_info {
> +#define HVM_START_MAGIC_VALUE 0x336ec578
> +uint32_t magic; /* Contains the magic value 0x336ec578   
> */
> +/* ("xEn3" with the 0x80 bit of the "E" 
> set).*/
> +uint32_t flags; /* SIF_xxx flags.
> */
> +uint32_t cmdline_paddr; /* Physical address of the command line. 
> */
> +uint32_t nr_modules;/* Number of modules passed to the kernel.   
> */
> +uint32_t modlist_paddr; /* Physical address of an array of   
> */
> +/* hvm_modlist_entry.
> */
> +};
> +
> +struct hvm_modlist_entry {
> +uint32_t paddr; /* Physical address of the module.   
> */
> +uint32_t size;  /* Size of the module in bytes.  
> */
> +};

Iirc this already went back and forth, but - is this meant to be an
x86-specific interface? If not, should we really limit physical
addresses to 32 bits here?

Also this now sits inside a XEN_HAVE_PV_GUEST_ENTRY conditional
- is that intended?

Jan


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

Re: [Xen-devel] [PATCH v7 09/28] xen/arm: ITS: Introduce gic_is_lpi helper function

[Julien Grall]

Hi Vijay,

On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Helper function gic_is_lpi() is used to find
> if irq is lpi or not. For GICv2 platforms this function
> returns number of irq ids which represents only number of line irqs.
> For GICv3 platform irq ids are calculated from nr_lpis if
> HW supports LPIs
> 
> Signed-off-by: Vijaya Kumar K 
> CC: Zoltan Kiss 
> ---
> v7: - Rename gic_info.nr_id_bits as gic_info.nr_irq_ids
> - gic_is_lpi() is common for both ARM64/32
> - Introduce global variable nr_lpis from patch #17
> - Reset nr_lpis to 0 when HW does not support LPIs
> - pass nr_lpis as boot args to Xen. Set minimum to 8192
> v6: - Added gic_info.nr_id_bits to hold number of SPI/LPIs
>   supported
> - Dropped is_lpi() callback
> ---
>  xen/arch/arm/gic-hip04.c  |3 ++-
>  xen/arch/arm/gic-v2.c |3 ++-
>  xen/arch/arm/gic-v3.c |   20 
>  xen/arch/arm/gic.c|   10 ++
>  xen/arch/arm/irq.c|   15 +++
>  xen/include/asm-arm/gic.h |5 +
>  xen/include/asm-arm/irq.h |3 +++
>  7 files changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
> index c5ed545..398881b 100644
> --- a/xen/arch/arm/gic-hip04.c
> +++ b/xen/arch/arm/gic-hip04.c
> @@ -301,7 +301,8 @@ static void __init hip04gic_dist_init(void)
>  
>  /* Only 1020 interrupts are supported */
>  gicv2_info.nr_lines = min(1020U, nr_lines);
> -

This empty line was useful to separate internal initialization from
enabling the distributor. Please retain the empty line.

> +/* Number of IRQ ids supported */
> +gicv2_info.nr_irq_ids = gicv2_info.nr_lines;
>  /* Turn on the distributor */
>  writel_gicd(GICD_CTL_ENABLE, GICD_CTLR);
>  }
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 596126d..6673f29 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -291,7 +291,8 @@ static void __init gicv2_dist_init(void)
>  
>  /* Only 1020 interrupts are supported */
>  gicv2_info.nr_lines = min(1020U, nr_lines);
> -

Ditto.

> +/* Number of IRQ ids supported */
> +gicv2_info.nr_irq_ids = nr_lines;
>  /* Turn on the distributor */
>  writel_gicd(GICD_CTL_ENABLE, GICD_CTLR);
>  }
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 5076706..6680bd2 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -529,6 +529,11 @@ static void gicv3_set_irq_properties(struct irq_desc 
> *desc,
>  spin_unlock();
>  }
>  
> +static int gicv3_dist_supports_lpis(void)
> +{
> +return readl_relaxed(GICD + GICD_TYPER) & GICD_TYPER_LPIS_SUPPORTED;
> +}
> +
>  static void __init gicv3_dist_init(void)
>  {
>  uint32_t type;
> @@ -578,6 +583,21 @@ static void __init gicv3_dist_init(void)
>  
>  /* Only 1020 interrupts are supported */
>  gicv3_info.nr_lines = min(1020U, nr_lines);
> +
> +/*
> + * Number of IRQ ids supported.
> + * Here we override HW supported number of LPIs and
> + * limit to to LPIs specified in nr_lpis.
> + */

You still have to check that the number of LPIs requesting by the user
is supported by the hardware.

The user parameter can be seen as a restriction rather than a blind
overriding.

> +if ( gicv3_dist_supports_lpis() )

I'm sure we already speak about it in a previous series. The GICv3 may
support LPIs even without an ITS. Here you would claim that Xen is
supporting LPIs which is clearly not true.

When the ITS is not present, this value should be the number of
interrupt line supported.

I haven't checked if you fixed it later, but all the patch should be
bisectable. I.e I shouldn't see any unwanted modification on supported
platform with GICv3 (for instance the foundation model).

> +gicv3_info.nr_irq_ids = nr_lpis + FIRST_GIC_LPI;
> +else
> +{
> +gicv3_info.nr_irq_ids = gicv3_info.nr_lines;
> +/* LPIs are not supported by HW. Reset to 0 */
> +nr_lpis = 0;

That's really ugly and you still let GICv2 hardware with nr_lpis != 0.
As said on v6 I don't want to see any usage of nr_lpis in code except
for letting the user restricting the number of LPIs supported.

That means that all the code should use gic_nr_irq_ids to know the
number of LPIs supported. Mixing the 2 usage will lead to big trouble
latter.

So please move nr_lpis in gic-v3 as a parameter and don't export it.

> +}
> +
>  }
>  
>  static int gicv3_enable_redist(void)
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 1d94e5e..a0ed7df 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -62,6 +62,16 @@ enum gic_version gic_hw_version(void)
> return gic_hw_ops->info->hw_version;
>  }
>  
> +unsigned int gic_nr_irq_ids(void)
> +{
> +return gic_hw_ops->info->nr_irq_ids;
> +}
> +
> +bool_t 

[Xen-devel] [PATCH OSSTEST] Debian: Avoid uninitialised string warn when getting host firmware property

[Ian Campbell]

Signed-off-by: Ian Campbell 
---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8675922..a8b62ca 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1169,7 +1169,7 @@ END
 
 preseed_microcode($ho,$sfx);
 
-if (get_host_property($ho, "firmware") eq "uefi") {
+if (get_host_property($ho, "firmware",'') eq "uefi") {
die unless $ho->{Suite} =~ m/jessie/;
# Prevent grub-install from making a new Debian boot entry, so
# we always reboot from PXE. Debian bug #789798 proposes a
-- 
2.5.1


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

[Xen-devel] [PATCH OSSTEST] Debian: handle move of ip(8) to /sbin in Jessie

[Ian Campbell]

Unfortunately udev treats non-absolute commands as relative to
/lib/udev rather than consulting $PATH, so we have to figure out the
path based on the suite.

Without this the force-mac-address workaround (needed on Arndale)
doesn't work.

Signed-off-by: Ian Campbell 
---
 ts-host-install | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ts-host-install b/ts-host-install
index f734a9c..cc91ccb 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -235,10 +235,12 @@ sub setup_pxeboot_firstboot($) {
die "need Ether for $ho->{Name} ($wantphysif)"
unless defined $ho->{Ether};
 system_checked(qw(mkdir -p --), "$initrd_overlay.d/etc/udev/rules.d");
+   # ip(8) moved to /sbin in Jessie
+   my $ipcmd = $ho->{Suite} =~ m/wheezy/ ? "/bin/ip" : "/sbin/ip";
 file_simple_write_contents
 ("$initrd_overlay.d/etc/udev/rules.d/70-persistent-net.rules",
  $ho->{Flags}{'force-mac-address'} ? 

Re: [Xen-devel] [PATCH v7 10/28] xen/arm: ITS: Implement hw_irq_controller for LPIs

[Julien Grall]

Hi Vijay,

On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Implement hw_irq_controller callbacks required to
> handle LPIs.
> 
> Signed-off-by: Vijaya Kumar K 

With the 3 changes requested below:

Reviewed-by: Julien Grall 

> ---
>  xen/arch/arm/gic-v3-its.c |  119 
> +
>  xen/arch/arm/gic-v3.c |2 +-
>  xen/include/asm-arm/gic_v3_defs.h |2 +
>  3 files changed, 122 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index bc3b73c..0d5c61c 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -444,6 +444,125 @@ static void its_send_discard(struct its_device *dev, 
> u32 event)
>  its_send_single_command(dev->its, , col);
>  }
>  
> +static void its_flush_and_invalidate_prop(struct irq_desc *desc, u8 *cfg)

NIT: cfg could be const i.e

const u8 *cfg

> +{
> +struct its_device *its_dev = irqdesc_get_its_device(desc);
> +u32 vid = irqdesc_get_lpi_event(desc);
> +
> +ASSERT(vid < its_dev->event_map.nr_lpis);
> +
> +/*
> + * Make the above write visible to the redistributors.
> + * And yes, we're flushing exactly: One. Single. Byte.
> + * Humpf...
> + */
> +if ( gic_rdists->flags & RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING )
> +clean_and_invalidate_dcache_va_range(cfg, sizeof(*cfg));
> +else
> +dsb(ishst);
> +
> +its_send_inv(its_dev, vid);
> +}

> +const hw_irq_controller its_host_lpi_type = {

As said on v6, the const is not necessary.

> +.typename = "gic-its",
> +.startup  = its_irq_startup,
> +.shutdown = its_irq_shutdown,
> +.enable   = its_irq_enable,
> +.disable  = its_irq_disable,
> +.ack  = its_irq_ack,
> +.end  = its_host_irq_end,
> +.set_affinity = its_irq_set_affinity,
> +};
> +
> +const hw_irq_controller its_guest_lpi_type = {

Ditto.

> +.typename = "gic-its",
> +.startup  = its_irq_startup,
> +.shutdown = its_irq_shutdown,
> +.enable   = its_irq_enable,
> +.disable  = its_irq_disable,
> +.ack  = its_irq_ack,
> +.end  = its_guest_irq_end,
> +.set_affinity = its_irq_set_affinity,
> +};
> +
>  /*
>   * How we allocate LPIs:
>   *

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] DRAFT XSA 142 - libxl fails to honour readonly flag on disks with qemu-xen [and 1 more messages]

[Ian Jackson]

M A Young writes ("Re: DRAFT XSA 142 - libxl fails to honour readonly flag on 
disks with qemu-xen"):
> Of course you still need a separate patch for xen 4.5.1 and earlier as the 
> xsa142.patch file attached is only valid for xen 4.6.0. Replacing 
> ERROR_INVAL with NULL works for xen 4.5.1 and compiles for xen 4.4.3.

Damn, I forgot about that, sorry.

Xen.org security team writes ("DRAFT XSA 142 - libxl fails to honour readonly 
flag on disks with qemu-xen"):
> * DRAFT DRAFT DRAFT *
> Xen Security Advisory XSA-142
> libxl fails to honour readonly flag on disks with qemu-xen

This time for sure.

Ian.

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

[Xen-devel] [xen-4.4-testing baseline-only test] 37995: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 37995 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37995/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-qcow2 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-raw   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-raw   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-raw   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-vhd1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 

Re: [Xen-devel] [PATCH XEN v2 05/15] tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.

[Ian Campbell]

On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> diff --git a/tools/libxenevtchn/include/xenevtchn.h
> [...]

> +/* A port identifier is guaranteed to fit in 31 bits. */
> +typedef int evtchn_port_or_error_t;
> 
[...]
> +/*
> + * Returns a new event port awaiting interdomain connection from the given
> + * domain ID, or -1 on failure, in which case errno will be set 
> appropriately.
> + */
> +evtchn_port_or_error_t
> +xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int domid);
> +
> +/*
> + * Returns a new event port bound to the remote port for the given domain ID,
> + * or -1 on failure, in which case errno will be set appropriately.
> + */
> +evtchn_port_or_error_t
> +xenevtchn_bind_interdomain(xenevtchn_handle *xce, int domid,
> +   evtchn_port_t remote_port);

ISTR that this evtchn_port_or_error_t construct was introduce in order to
correct an incorrect type used here without changing the API in annoying
ways.

Given that this series is already changing the API anyway do we want to
take the opportunity prior to declaring this new library ABI/API stable to
rework these functions such that they return 0 or -1 and take a
evtchn_port_t * output variable which they update on success?

And then abolish evtchn_port_or_error_t except for the
 XC_WANT_COMPAT_EVTCHN_API case.

Ian.

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

Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor 
"xentoollog" into its own library"):
> On 10/06/15 12:36, Ian Campbell wrote:
> > +
> > +#define XTL_NEW_LOGGER(LOGGER,buffer) ({\
> > +xentoollog_logger_##LOGGER *new_consumer;   \
> > +\
> > +(buffer).vtable.vmessage = LOGGER##_vmessage;   \
> > +(buffer).vtable.progress = LOGGER##_progress;   \
> > +(buffer).vtable.destroy  = LOGGER##_destroy;\
> > +\
> > +new_consumer = malloc(sizeof(*new_consumer));   \
> > +if (!new_consumer) {\
> > +xtl_log((xentoollog_logger*),\
> > +XTL_CRITICAL, errno, "xtl", \
> > +"failed to allocate memory for new message logger");\
> > +} else {\
> > +*new_consumer = buffer; \
> > +}   \
> > +\
> > +new_consumer;   \
> > +});

Ian Campbell just pointed me at this.

> This macro should be ditched.
> 
> It is a gnu-ism which shouldn't be present in the public library header,

Do you mean that statement expressions (originally a GNU extension)
should be avoided in tools code ?  A quick git-grep discovered that
xenctrl already contains numerous statement expressions.

> violates several principles of least supprise,

This is just invective.

> and can literally only be
> used by its sole user in xtl_logger_stdio.c because of its internal
> expectations of xentoollog_logger_stdiostream.  (Its sole user could do
> the above in a cleaner manner anyway.)

There is only one place in tree that calls this because there are only
two in-tree loggers and the other one
(tools/ocaml/libs/xentoollog/xentoollog_stubs.c) chose not to use it.
It seems to me that stub_xtl_create_logger could use this macro.

> As part of the tidyup, we should choose a particular C standard (89,
> probably) and ensure that the API/ABI complies with `gcc -std=c$VER
> -pedantic`.  This will help to provide a consistent API on other
> platforms (I seem to recall an effort to port libvchan to windows.)

-pedantic is certainly a bad idea.

> As another thought, it would also be a good time to sort out a
> consistent coding style, although that doesn't necessarily need to be
> folded into the split-out patch.  The current source is very mixed when
> it comes to coding style.

This sounds like it's going to lead to a lot of bikeshedding.  If
there are components with internally inconsistent coding styles that
should be fixed.  But I don't think it is a good idea to go around
reformatting areas that are coherent to make them like other areas
which are differently coherent.

Ian.

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Linus Torvalds]

On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar  wrote:
>
> Linus, what's your preference?

So quite frankly, is there any reason we don't just implement
native_read_msr() as just

   unsigned long long native_read_msr(unsigned int msr)
   {
  int err;
  unsigned long long val;

  val = native_read_msr_safe(msr, );
  WARN_ON_ONCE(err);
  return val;
   }

Note: no inline, no nothing. Just put it in arch/x86/lib/msr.c, and be
done with it. I don't see the downside.

How many msr reads are so critical that the function call
overhead would matter? Get rid of the inline version of the _safe()
thing too, and put that thing there too.

  Linus

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

Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library

[Andrew Cooper]

On 21/09/15 17:17, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor 
> "xentoollog" into its own library"):
>> On 10/06/15 12:36, Ian Campbell wrote:
>>> +
>>> +#define XTL_NEW_LOGGER(LOGGER,buffer) ({\
>>> +xentoollog_logger_##LOGGER *new_consumer;   \
>>> +\
>>> +(buffer).vtable.vmessage = LOGGER##_vmessage;   \
>>> +(buffer).vtable.progress = LOGGER##_progress;   \
>>> +(buffer).vtable.destroy  = LOGGER##_destroy;\
>>> +\
>>> +new_consumer = malloc(sizeof(*new_consumer));   \
>>> +if (!new_consumer) {\
>>> +xtl_log((xentoollog_logger*),\
>>> +XTL_CRITICAL, errno, "xtl", \
>>> +"failed to allocate memory for new message logger");\
>>> +} else {\
>>> +*new_consumer = buffer; \
>>> +}   \
>>> +\
>>> +new_consumer;   \
>>> +});
> Ian Campbell just pointed me at this.
>
>> This macro should be ditched.
>>
>> It is a gnu-ism which shouldn't be present in the public library header,
> Do you mean that statement expressions (originally a GNU extension)
> should be avoided in tools code ?  A quick git-grep discovered that
> xenctrl already contains numerous statement expressions.

It is fine (in principle) to be used internally.  Not in a public header
for what is supposed to be a clean API.

>
>> violates several principles of least supprise,
> This is just invective.

/me googles and discovered a new word.  I stand by my statement.

It requires the user to embed one structure inside another structure
(with half a undocumented magic name), under a specific undocumented
field name, and have three functions (with half undocumented magic
names) in scope with undocumented types.  It also mandates an original
copy of the half-magically-named struct in scope to be partially
initialised, just to have another copy created in the heap.

The error handling is also broken;  It will follow a wild function
pointer, if vtable is not the first element in the structure (again
undocumented).

This macro is not fit for any purpose it attempts to perform.

https://github.com/xenserver/xen-4.5.pg/blob/master/master/xenguest.patch#L609
is the correct way to use a setup like this, even if it does require
embedding other data alongside it.

>
>> and can literally only be
>> used by its sole user in xtl_logger_stdio.c because of its internal
>> expectations of xentoollog_logger_stdiostream.  (Its sole user could do
>> the above in a cleaner manner anyway.)
> There is only one place in tree that calls this because there are only
> two in-tree loggers and the other one
> (tools/ocaml/libs/xentoollog/xentoollog_stubs.c) chose not to use it.
> It seems to me that stub_xtl_create_logger could use this macro.

Or better yet, ditch it completely.

All that needs to happen is for struct xentoollog_logger to have the
three function pointers filled in appropriately.  This in turn does not
mandate that the structure is allocated from the heap, or the prescribed
layout/naming scheme.

>
>> As part of the tidyup, we should choose a particular C standard (89,
>> probably) and ensure that the API/ABI complies with `gcc -std=c$VER
>> -pedantic`.  This will help to provide a consistent API on other
>> platforms (I seem to recall an effort to port libvchan to windows.)
> -pedantic is certainly a bad idea.

Pedantic is absolutely the correct answer.  It will cause gcc to reject
any non C compliant statements.

The APIs of each of these new libraries should be just as usable on
windows systems as Linux systems.

~Andrew

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Linus Torvalds]

On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven  wrote:
>>
>> How many msr reads are so critical that the function call
>> overhead would matter?
>
> if anything qualifies it'd be switch_to() and friends.

Is there anything else than the FS/GS_BASE thing (possibly hidden
behind inlines etc that I didn't get from a quick grep)? And why is
that sometimes using the "safe" version (in do_arch_prctl()), and
sometimes not (switch_to())?

I'm not convinced that mess is a good argument for the status quo ;)

> note that I'm not entirely happy about the notion of "safe" MSRs.
> They're safe as in "won't fault".

I wouldn't object to renaming them.

Linus

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

Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library

[Andrew Cooper]

On 21/09/15 18:13, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor 
> "xentoollog" into its own library"):
>> On 21/09/15 17:17, Ian Jackson wrote:
>>> Do you mean that statement expressions (originally a GNU extension)
>>> should be avoided in tools code ?  A quick git-grep discovered that
>>> xenctrl already contains numerous statement expressions.
>> It is fine (in principle) to be used internally.  Not in a public header
>> for what is supposed to be a clean API.
> I don't understand why this distinction is relevant.  Either the
> compiler supports it, or it doesn't.

There shouldn't be items in a public header which can't be used by all
compilers which might want to compile it.

GCC is not the only compiler liable to encounter this new header file.

>
 violates several principles of least supprise,
>>> This is just invective.
>> /me googles and discovered a new word.  I stand by my statement.
> Well, if you feel so strongly, I won't object to a patch to remove it.

This is exactly why I raise the point now when the ABI is deliberately
changing.  Having said that, it was previously in libxc so anything
went.  I would be happy to submit a patch either to libxc now, or to
libxentoollog later.

>
 As part of the tidyup, we should choose a particular C standard (89,
 probably) and ensure that the API/ABI complies with `gcc -std=c$VER
 -pedantic`.  This will help to provide a consistent API on other
 platforms (I seem to recall an effort to port libvchan to windows.)
>>> -pedantic is certainly a bad idea.
>> Pedantic is absolutely the correct answer.  It will cause gcc to reject
>> any non C compliant statements.
> No, that is not what -pedantic does.  Please RTFM.

Please explain why you believe it to be unsuitable?  It is not perfect,
but is far better than nothing.

~Andrew

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Mon, Sep 21, 2015 at 9:36 AM, Linus Torvalds
 wrote:
> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar  wrote:
>>
>> Linus, what's your preference?
>
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
>
>unsigned long long native_read_msr(unsigned int msr)
>{
>   int err;
>   unsigned long long val;
>
>   val = native_read_msr_safe(msr, );
>   WARN_ON_ONCE(err);
>   return val;
>}
>
> Note: no inline, no nothing. Just put it in arch/x86/lib/msr.c, and be
> done with it. I don't see the downside.

In the interest of sanity, I want to drop the "native_", too, since
there appear to be few or no good use cases for native_read_msr as
such.  I'm tempted to add new functions read_msr and write_msr that
forward to rdmsrl_safe and wrmsrl_safe.

It looks like the msr helpers are every bit as bad as the TSC helpers
used to be :(

--Andy

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven  wrote:
> On 9/21/2015 9:36 AM, Linus Torvalds wrote:
>>
>> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar  wrote:
>>>
>>>
>>> Linus, what's your preference?
>>
>>
>> So quite frankly, is there any reason we don't just implement
>> native_read_msr() as just
>>
>> unsigned long long native_read_msr(unsigned int msr)
>> {
>>int err;
>>unsigned long long val;
>>
>>val = native_read_msr_safe(msr, );
>>WARN_ON_ONCE(err);
>>return val;
>> }
>>
>> Note: no inline, no nothing. Just put it in arch/x86/lib/msr.c, and be
>> done with it. I don't see the downside.
>>
>> How many msr reads are so critical that the function call
>> overhead would matter?
>
>
> if anything qualifies it'd be switch_to() and friends.

And maybe the KVM user return notifier.  Unfortunately, switch_to
might gain another two MSR accesses at some point if we decide to fix
the bugs in there.  Sigh.

>
> note that I'm not entirely happy about the notion of "safe" MSRs.
> They're safe as in "won't fault".
> Reading random MSRs isn't a generic safe operation though, but the name sort
> of gives people
> the impression that it is. Even with _safe variants, you still need to KNOW
> the MSR exists (by means
> of CPUID or similar) unfortunately.
>

I tend to agree.

Anyway, the fully out-of-line approach isn't obviously a bad idea, and
it simplifies the whole mess (we can drop most of the paravirt
patches, too).  I'll give it a try and see what happens.

--Andy

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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Konrad Rzeszutek Wilk]

On Mon, Sep 21, 2015 at 08:58:44AM -0700, Ed Swierk wrote:
> After testing this change on different platforms, I'm finding some
> complications.
> 
> As I understand it, the BIOS is supposed to mark the MMCONFIG area
> reserved in the E820 table no matter what. And if the ACPI DSDT
> includes an MCFG record, then it should also include a PNP0C0x record
> for the MMCONFIG area.
> 
> Some BIOSes do just one of these. For example, the Intel S2600GL/GZ
> BIOS has the correct ACPI records, but does not have the area reserved
> in the E820 table. Linux is forgiving enough to use the MMCONFIG area
> in this case.
> 
> Other BIOSes do neither. For example, the Intel S2600WT BIOS doesn't
> even include the PNP0C0x record in the ACPI table, when TXT is
> enabled. On this platform the only way to get Linux to see extended
> config space at all is by passing memmap=256M$0x8000 on the kernel
> command line.
> 
> My change works in the latter case, since the memmap parameter causes
> it to add the MMCONFIG area in pci_arch_init(). But in the former
> case, where the ACPI tables aren't parsed until acpi_init(),
> xen_mcfg_late() must come later, unless you also use the memmap kernel
> command line parameter.
> 
> The fundamental problem is that Xen tries to access extended config
> space in pci_add_device(), before the Dom0 finally figures out where
> MMCONFIG area is and makes the pci_mmcfg_reserved hypercall. The only
> robust solution seems to be for Xen to defer extended config space
> accesses. It's not clear to me how late is late enough, however.

Or it can deal with PCI config spaces changing.

I wrote some patches (floating around ) where we would walk the full PCI
structure in the xen_mcfg_late() and go over all of them and do
the Xen pci_add_device hypercall.

It (the hypercall) would then need to update its own entries on the subsequent
call. However I never got it completletly working because of:
 - Linux can do 'pci=reassign_devices' which renumbers the bus addresses and
   Xen's idea of the "old" and "new" pci devices goes out the window.
   (for that to work I wrote an patchset that implements this functionality
   in Xen so Linux's pci=reassign_devices in effect will be a nop).
 - Never figured out how much data we should save in the Xen's
   struct pci_device to see if we are 'stale'. Looking back I think
   we just need to do the interogation of the PCI capabilities and see
   if they have somehow changed (the ones we care about).


> 
> --Ed
> 
> 
> On Tue, Sep 15, 2015 at 4:29 PM, Ed Swierk  wrote:
> > On systems where the ACPI DSDT advertises the PCI MMCONFIG area but the
> > E820 table does not reserve it, it's up to Dom0 to inform Xen via
> > PHYSDEVOP_pci_mmcfg_reserved.  This needs to happen before Xen tries to
> > access extended capabilities like SRIOV in pci_add_device(), which is
> > triggered when Linux enumerates PCI devices in acpi_init().  Changing
> > xen_mcfg_late() to arch_initcall_sync ensures it gets called before
> > acpi_init(), but after pci_mmcfg_list is populated by pci_arch_init().
> >
> > Without this change, Xen 4.4 and 4.5 emit WARN messsages from
> > msix_capability_init() when setting up Intel 82599 VFs, since vf_rlen has
> > not been initialized by pci_add_device().  And on Xen 4.5, Xen nukes the
> > DomU due to "Potentially insecure use of MSI-X" when the VF driver loads
> > in the DomU.  Both problems are fixed by this change.
> >
> > Signed-off-by: Ed Swierk 
> > ---
> >  drivers/xen/pci.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> > index 7494dbe..7b5bbdb 100644
> > --- a/drivers/xen/pci.c
> > +++ b/drivers/xen/pci.c
> > @@ -253,7 +253,9 @@ static int __init xen_mcfg_late(void)
> > return 0;
> >  }
> >  /*
> > - * Needs to be done after acpi_init which are subsys_initcall.
> > + * Needs to be called after pci_arch_init (arch_initcall) populates
> > + * pci_mmcfg_list, but before acpi_init (subsys_initcall) triggers
> > + * pci_add_device() in Xen, since the latter probes extended capabilities.
> >   */
> > -subsys_initcall_sync(xen_mcfg_late);
> > +arch_initcall_sync(xen_mcfg_late);
> >  #endif
> > --
> > 1.9.1
> >
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor 
"xentoollog" into its own library"):
> On 21/09/15 17:17, Ian Jackson wrote:
> > Do you mean that statement expressions (originally a GNU extension)
> > should be avoided in tools code ?  A quick git-grep discovered that
> > xenctrl already contains numerous statement expressions.
> 
> It is fine (in principle) to be used internally.  Not in a public header
> for what is supposed to be a clean API.

I don't understand why this distinction is relevant.  Either the
compiler supports it, or it doesn't.

> >> violates several principles of least supprise,
> > This is just invective.
> 
> /me googles and discovered a new word.  I stand by my statement.

Well, if you feel so strongly, I won't object to a patch to remove it.

> >> As part of the tidyup, we should choose a particular C standard (89,
> >> probably) and ensure that the API/ABI complies with `gcc -std=c$VER
> >> -pedantic`.  This will help to provide a consistent API on other
> >> platforms (I seem to recall an effort to port libvchan to windows.)
> > -pedantic is certainly a bad idea.
> 
> Pedantic is absolutely the correct answer.  It will cause gcc to reject
> any non C compliant statements.

No, that is not what -pedantic does.  Please RTFM.

Ian.

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

[Xen-devel] [qemu-upstream-4.6-testing baseline-only test] 37994: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 37930
 test-armhf-armhf-xl  14 guest-stopfail REGR. vs. 37930
 test-amd64-amd64-xl-xsm  11 guest-start   fail REGR. vs. 37930

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 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-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail never pass

version targeted for testing:
 qemuucc31b41210ed66b07822a8c534053273d249dbe6
baseline version:
 qemuub05befcbea71a979509ce04f02929969a790c923

Last test of basis37930  2015-09-15 08:45:54 Z6 days
Testing same since37994  2015-09-20 07:37:25 Z1 days1 attempts


People who touched revisions under test:
  P J P 
  Stefan Hajnoczi 
  Stefano Stabellini 

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

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Arjan van de Ven]

On 9/21/2015 9:36 AM, Linus Torvalds wrote:

On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar  wrote:


Linus, what's your preference?


So quite frankly, is there any reason we don't just implement
native_read_msr() as just

unsigned long long native_read_msr(unsigned int msr)
{
   int err;
   unsigned long long val;

   val = native_read_msr_safe(msr, );
   WARN_ON_ONCE(err);
   return val;
}

Note: no inline, no nothing. Just put it in arch/x86/lib/msr.c, and be
done with it. I don't see the downside.

How many msr reads are so critical that the function call
overhead would matter?


if anything qualifies it'd be switch_to() and friends.

note that I'm not entirely happy about the notion of "safe" MSRs.
They're safe as in "won't fault".
Reading random MSRs isn't a generic safe operation though, but the name sort of 
gives people
the impression that it is. Even with _safe variants, you still need to KNOW the 
MSR exists (by means
of CPUID or similar) unfortunately.



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

Re: [Xen-devel] [PATCH 2/2] xen: arm: traps: correct cond

[Julien Grall]

Hi Peng,

On 21/09/15 08:07, Peng Fan wrote:
> From "G6.2.29 CPSR, Current Program Status Register" of Aarch64 ARM
> and "B1.3.3 Program Status Registers (PSRs)" of ARMv7-A ARM:
> "

The section number may change between the different version of the spec.
Can you also precise the spec version?

For instance on my ARM64 spec (ARM DDI 0497A.d) the section G6.2.29
points to "CSSELR" and not "CPSR".

> IT[7:5] holds the base condition for the IT block. The base condition is
> the top 3 bits of the condition code specified by the first
>   condition field of the IT instruction.
> IT[4:0] encodes the size of the IT block, which is the number of
> instructions that are to be conditionally executed, by the
>   position of the least significant 1 in this field. It also
>   encodes the value of the least significant bit of the condition
>   code for each instruction in the block.
> "
> So should be "cond = ( it >> 5 );" but not "cond = ( it >> 4 );"

IT[7:5] encodes the top 3 bits of the condition code and one bit of
IT[4:0] will contain the least significant bit of the condition code.

In order to get the full condition code you have to use IT[7:4] which
the current code does (see A2.5.2 ARM DDI 0406C.b).

So the current code looks valid to me. Did I miss something?

Regards,

> Signed-off-by: Peng Fan 
> Cc: Ian Campbell 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> ---
>  xen/arch/arm/traps.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 2e2b1f2..b2879b7 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1561,8 +1561,8 @@ static int check_conditional_instr(struct cpu_user_regs 
> *regs,
>  if ( it == 0 )
>  return 1;
>  
> -/* The cond for this instruction works out as the top 4 bits. */
> -cond = ( it >> 4 );
> +/* The cond for this instruction works out as the top 3 bits. */
> +cond = ( it >> 5 );
>  }
>  
>  cpsr_cond = cpsr >> 28;
> 

-- 
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH 21/26] ts-debian-hvm-install: Do not create EFI partition if EFI not in use

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 21/26] ts-debian-hvm-install: Do not 
create EFI partition if EFI not in use"):
> On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote:
> > If we are booting our install ISO using a non-EFI executable, don't
> > try to provide an EFI for the installed system either.
...
> FWIW the default recipes used by d-i use "$iflabel{ gpt }" to achieve the
> same thing. Actually I'm a bit surprised that this isn't the affect of
> "method { efi }" too.

I'm happy to do this some other way but the way I did it avoided me
having to look up how d-i partman-auto works...

> Anyway, this approach is good enough for our purposes so:
> 
> Acked-by: Ian Campbell 

Thanks,
Ian.

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

Re: [Xen-devel] [qemu-mainline bisection] complete test-armhf-armhf-xl-vhd

[Ian Jackson]

Ian Campbell writes ("Re: [qemu-mainline bisection] complete 
test-armhf-armhf-xl-vhd"):
> This looks to be the issue which Anthony investigated last week and for
> which the responsible patch has been reverted.
> 
> I think this bisection just hadn't caught up with the fact that the issue
> is fixed yet.

That is plausible.  The bisector will keep going until a full flight
has picked up and tested the new input version.

(I haven't checked the timeline for this.)

Ian.

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

Re: [Xen-devel] [PATCH v7 06/28] xen/arm: ITS: Add helper functions to manage its_devices

[Julien Grall]

Hi Vijay,

On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
> +static void its_remove_device(struct its_device *dev)
> +{
> +if ( dev )
> +rb_erase(>node, _its_dev);

Either the caller or this function has to take the lock which protect
the RB-tree.

If it's the caller, please add an ASSERT to check the lock is taken. If
not, you know what to do ;).

Regards,

> +}
> +

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts

[Wu, Feng]

> >> Thanks for the comments!
> >>
> >> From my understanding, __sync_local_execstate() can only get called
> >> in the following two cases:
> >> #1) this_cpu(curr_vcpu) == current, in this case, __context_switch() is
> >> not called.
> >> #2) this_cpu(curr_vcpu) != current, and current == idle_vcpu, that means
> >> we just switched from a non-idle vCPU to idle vCPU, so here we need to
> >> call __context_switch() to copy things to the original vcpu struct.
> >>
> >> Please correct me if the above understanding is wrong or incomplete?
> >
> > Hi George / Dario,
> >
> > Could you please confirm the above understanding is correct? (In fact, it is
> > Related to lazy context switch, right?) if so I can continue with the
> > pi_context_switch() way George suggested.
> 
> Yes, that's the general idea.  Normally, you can access the registers of
> a non-running vcpu from the vcpu struct.  But if we've done a lazy
> context switch, that's not true -- so to access those registers properly
> we need to go through and do the full context switch *on that pcpu*.

Thanks for the clarification!

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

Re: [Xen-devel] Xen Project, QEMU and Linux Coverity defect densities

[Lars Kurth]

As an aside,

xen components in QEMU and Linux Coverity scans seem to be also higher than the 
average for those projects

QEMU: .*/xen.* - density 0.52
LINUX: .*/drivers/xen/.* - density 1.40

Regards
Lars

> On 21 Sep 2015, at 13:10, Lars Kurth  wrote:
> 
> Hi folks,
> 
> as preparation for the xen 4.6 release (and putting together PR), I was 
> looking at Coverity stats. It seems that we made a little progress in terms 
> of defect density, but that we have fallen behind compared to Linux & QEMU.
> 
> Defect Density & Outstanding Defects
> Xen: 0.58 & 678
> Linux: 0.51 & 5248
> QEMU: 0.10 & 109
> 
> I attached the stats of Xen, QEMU and Linux as screenshots.
> 
> I am wondering, whether we should go for a push early in the next release 
> cycle to address these.
> 
> Regards
> Lars
> 
> == QEMU ==
> 
> 
> == Linux ==
> 
> 
> == Xen ==
> 
> 


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