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

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

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

>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

Re: [Xen-devel] Kbuild and Kconfig

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

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

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

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

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

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

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-devel] libxen-light

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

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

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

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

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] [xen-unstable test] 62156: regressions - FAIL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

Re: [Xen-devel] 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 ... ? > > All versions of libxl which

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

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 >

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

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

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

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.

[Xen-devel] 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 ISSUE DESCRIPTION = Callers of libxl can specify that a disk should be read-only to the guest. However, there is no code in libxl

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

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

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

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,

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

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

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

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 |

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

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-devel] [V5 3/4] x86/xsaves: enable xsaves/xrstors for hvm guest

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Xen-devel] [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. Without this the force-mac-address workaround (needed on Arndale) doesn't work. Signed-off-by: Ian Campbell ---

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

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:

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

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

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

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

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

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

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

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;

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

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

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

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) ({\ >>> +

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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?

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

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

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

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

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

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

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

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

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

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

  1   2   >