[Xen-devel] [xen-4.6-testing test] 64505: regressions - FAIL

flight 64505 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/64505/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 5 xen-build fail REGR. vs. 63449 build-i386-prev

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On 18/11/15 15:49, Wei Liu wrote: > Hi Juergen > > Looks like there is something we missed after all. > > On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote: >> flight 64494 xen-unstable real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/64494/ >> >> Regressions

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On Wed, Nov 18, 2015 at 04:54:34PM +0100, Juergen Gross wrote: > On 18/11/15 15:49, Wei Liu wrote: > > Hi Juergen > > > > Looks like there is something we missed after all. > > > > On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote: > >> flight 64494 xen-unstable real [real] >

Re: [Xen-devel] [PATCH v5 8/9] libxc: rework of domain builder's page table handler

On Wed, Nov 18, 2015 at 11:11:16AM -0500, Boris Ostrovsky wrote: > On 11/12/2015 08:43 AM, Juergen Gross wrote: > >In order to prepare a p2m list outside of the initial kernel mapping > >do a rework of the domain builder's page table handler. The goal is > >to be able to use common helpers for

Re: [Xen-devel] [PATCH 1/2] rwlock: add per-cpu reader-writer locks

On 18/11/15 14:15, Jan Beulich wrote: On 18.11.15 at 14:49, wrote: >> On 17/11/15 17:00, Jan Beulich wrote: >> On 03.11.15 at 18:58, wrote: Per-cpu read-write locks allow for the fast path read case to have low

Re: [Xen-devel] [PATCH 4.6] Config: Switch to unified qemu trees.

Ian Campbell writes ("Re: [PATCH 4.6] Config: Switch to unified qemu trees."): > This looks like what my local backport got when I was developing this, > which I erroneously posted as the patch for unstable in [0] so: > > Acked-by: Ian Campbell Great, thanks. > Are you

[Xen-devel] [PATCH v3 3/4] xen/hvm: introduce a fpu_uninitialised field to the CPU save record

Introduce a new field to signal if the FPU has been initialised or not. Xen needs this new field in order to know whether to set the FPU as initialised or not during restore of CPU context. Previously Xen always wrongly assumed the FPU was initialised on restore. Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v3 1/4] xen/save: pass a size parameter to the HVM compat functions

In order to cope with types having multiple compat versions pass a size parameter to the fixup function so we can identify which compat version Xen is dealing with. Signed-off-by: Roger Pau Monné Cc: Ian Campbell Cc: Ian Jackson

[Xen-devel] [PATCH v3 2/4] xen/save: allow the usage of zeroextend and a fixup function

With the current compat implementation in the save/restore context handling, only one compat structure is allowed, and using _zeroextend prevents the fixup function from being called. In order to allow for the compat handling layer to be able to handle different compat versions allow calling the

[Xen-devel] [PATCH v3 4/4] Revert "libxc: create an initial FPU state for HVM guests"

This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad: Xen always set the FPU as initialized when loading a HVM context, so libxc has to provide a valid FPU context when setting the CPU registers. This was a stop-gap measure in order to unblock OSSTest Windows 7 failures while a proper

Re: [Xen-devel] [PATCH 2/9] xen/arm: vgic-v3: Only emulate identification registers requested by the spec

Hi Ian, On 16/11/15 13:27, Ian Campbell wrote: > On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote: >> Most of the identification registers space contains implementation >> defined registers (see 8.1.13 in ARM IHI 0069A) and only GIC{D,R}_PIDR2 >> is required to be implemented. > > I think

[Xen-devel] [PATCH v6 6/6] xen/arm: vgic-v3: Support 32-bit access for 64-bit registers

Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers supports both 32-bit and 64-bits access. All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access. For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway, emulating 32-bit access for

[Xen-devel] [PATCH v6 5/6] xen/arm: vgic: Introduce helpers to extract/update/clear/set vGIC register ...

and use them in the vGIC emulation. The GIC registers may support different access sizes. Rather than open coding the access for every registers, provide a set of helpers to access them. The caller will have to call vgic_regN_* where N is the size of the emulated registers. The new helpers

[Xen-devel] [PATCH v6 1/6] xen/arm: vgic-v2: Implement correctly ITARGETSR0 - ITARGETSR7 read-only

Each ITARGETSR register are 4-byte wide and the offset is in byte. The current implementation is computing the end of the range wrongly resulting to emulate only ITARGETSR{0,1} read-only. The rest will be treated as read-write. As 8 registers should be read-only, the end of the range should be

[Xen-devel] [PATCH v6 0/6] xen/arm: vgic: Support 32-bit access for 64-bit registers

Hi all, This series aims to fix the 32-bit access on 64-bit registers. Some guest OS such as FreeBSD and Linux (ITS and recently 32-bit guest using GICv3) use 32-bit access and will crash at boot time. For all the changes see in each patch. Sincerely yours, Julien Grall (6): xen/arm:

[Xen-devel] [PATCH v6 4/6] xen/arm: vgic: Optimize the way to store the target vCPU in the rank

Xen is currently directly storing the value of GICD_ITARGETSR register (for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the emulation of the registers access very simple but makes the code to get the target vCPU for a given vIRQ more complex. While the target vCPU of an vIRQ is

[Xen-devel] [PATCH v6 3/6] xen/arm: vgic-v2: Don't ignore a write in ITARGETSR if one field is 0

The current implementation ignores the whole write if one of the field is 0. Although, based on the spec (4.3.12 IHI 0048B.b), 0 is a valid value when: - The interrupt is not wired in the distributor. From the Xen point of view, it means that the corresponding bit is not set in

[Xen-devel] [PATCH v6 2/6] xen/arm: vgic-v2: Handle correctly byte write in ITARGETSR

During a store, the byte is always in the low part of the register (i.e [0:7]). We are incorrectly masking the register by using a shift of the byte offset in the ITARGETSR while the byte is alwasy in r[0:7]. This will result in a target list equal to 0 which is ignored by the emulation. Because

Re: [Xen-devel] [PATCH 4.6] Config: Switch to unified qemu trees.

On Wed, 2015-11-18 at 17:11 +, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH 4.6] Config: Switch to unified qemu > trees."): > > Are you going to apply this to 4.5 and older now too? Given the obvious > > s/4.6/$X.$Y/g on this patch you may keep my ack on those too. > > Now done.  

Re: [Xen-devel] [PATCH v2 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

Hi Konrad, On 09/11/15 16:05, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 09, 2015 at 03:51:48PM +, Julien Grall wrote: >> Hi, >> >> Any comments on this new version? > > I completly ignored thinking that the: > > c004a6f block/xen-blkfront: Make it running on 64KB page granularity > 4f503fb

[Xen-devel] [PATCH v2 10/11] xen/arm: vgic-v3: Don't implement write-only register read as zero

A read to a write only register is unknown. Use a memorable value to differentiate from an actual RAZ register. Signed-off-by: Julien Grall Acked-by: Ian Campbell --- Changes in v2: - Add Ian's acked-by --- xen/arch/arm/vgic-v3.c |

[Xen-devel] [PATCH v3 0/4] Introduce a fpu_initilised field to HVM CPU context

Hello, This patch series tries to properly solve the problem seen with the HVMlite series, that Xen always assumes the FPU is initialised on CPU context restore. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org

[Xen-devel] [PATCH v2 11/11] xen/arm: vgic-v3: Make clear that GICD_*SPI_* registers are reserved

Our vGIC emulation have GICD_TYPER.MBIS set to 0 which means that GICD_*SPI_* registers are reserved. Implement them using the *_reserved labels. Also, implement theses registers for the read part. Signed-off-by: Julien Grall Acked-by: Ian Campbell

Re: [Xen-devel] [PATCH 4/9] xen/arm: vgic-v3: Remove GICR_MOVALLR and GICR_MOVLPIR

Hi Ian, On 16/11/15 13:33, Ian Campbell wrote: > On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote: >> The 2 registers are not described in the software spec (ARM IHI 0069A) >> and their offsets are marked "implementation defined". > > They do exist in "PRD03-GENC-010745 24.0", in that they

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

flight 64520 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/64520/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340 Tests which did not

[Xen-devel] [PATCH v2 04/11] xen/arm: vgic-v3: Only emulate identification registers required by the spec

Most of the identification registers space contains implementation defined registers (see 8.1.13 in ARM IHI 0069A) and only GIC{D,R}_PIDR2 is required to be implemented. Currently the emulation of those registers mimic the ARM implementation, but it's untrue to say that we properly emulate a such

[Xen-devel] [PATCH v2 09/11] xen/arm: vgic-v3: Remove spurious return in GICR_INVALLR

Signed-off-by: Julien Grall Acked-by: Ian Campbell --- Changes in v2: - Add Ian's acked-by --- xen/arch/arm/vgic-v3.c | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c index

[Xen-devel] [PATCH v2 02/11] xen/arm: vgic-v3: Don't try to emulate IROUTER which doesn't exist in the spec

The range of valid IROUTER are n = 32 - 1019 (see 8.9.13 in IHI 0069A) which correspond to the offset 0x6100-0x7FD8. Other offset are invalid and therefore should not be emulated. Also remove the now unused label read_as_zero_64 and write_ignore_64. Note that GICD_IROUTER is kept to accomadate

[Xen-devel] [PATCH v2 07/11] xen/arm: vgic: Re-order the register emulations to match the memory map

It helps to find quickly whether we forgot to emulate a register or not. At the same time add the missing reserved/implementation defined registers. All other missing registers will be added in a follow-up if necessary. Note that only the distributor register map explicitely say the size of a

[Xen-devel] [PATCH v2 01/11] xen/arm: vgic-v2: Implement correctly ICFGR{0, 1} read-only

Each ITARGETSR register are 4-byte wide and the offset is in byte. The current implementation is computing the offset of ICFGR1 and ICFG2 wonrgly result to emulate only the first 2 byte of the ICFGR range read-only. The rest will be treated as read-write. For convenience introduce ITARGETSR1 and

[Xen-devel] [PATCH v2 03/11] xen/arm: vgic-v3: Use the correct offset GICR_IGRPMODR0

The offset is 0x0D00 and not 0x0F80. Also re-order the definition to keep all the definitions ordered. Signed-off-by: Julien Grall Acked-by: Ian Campbell --- Changes in v2: - Add Ian's acked-by ---

[Xen-devel] [PATCH v2 05/11] xen/arm: vgic: Properly emulate the full register

The offset in the emulation is based on byte. As most of the registers are 64/32 bits, they will span over multiple bytes. However, the current emulation only cares about the first offset. This will result in not properly emulating any access on the register with any other offset. Introduce new

[Xen-devel] [PATCH v2 06/11] xen/arm: vgic-v3: Remove GICR_MOVALLR and GICR_MOVLPIR

The 2 registers are not described in the software spec (ARM IHI 0069A) and their offsets are marked "implementation defined". Signed-off-by: Julien Grall Acked-by: Ian Campbell --- Note that I didn't combine the 2 cases because a follow-up

[Xen-devel] [PATCH v2 00/11] xen/arm: Bunch of fixes for the vGIC emulation

Hi all, The main purpose of this patch series is to fix the access to any register when the user doesn't write at the base offset of the registers. At the same time, I took the opportunity to re-arrange the emulation and dropping any registers which don't exist or not required by the spec. This

[Xen-devel] [PATCH v2 08/11] xen/arm: vgic-v3: Emulate read to GICD_ICACTIVER

The GICD_ICACTIVER registers are missing in the read emulation of the distributor. Call the common emulation for the whole range. Signed-off-by: Julien Grall Acked-by: Ian Campbell --- Changes in v2: - Add Ian's acked-by ---

Re: [Xen-devel] [PATCH 1/2] rwlock: add per-cpu reader-writer locks

>>> On 18.11.15 at 17:21, wrote: > I have a suggestion to remove the "no accessing two percpu rwlock resources > simultaneously on the same PCPU" restriction: > > On accessing the second resource, we can detect that the percpu read area is > already > in use, if

Re: [Xen-devel] [PATCH 4.6] Config: Switch to unified qemu trees.

Ian Campbell writes ("Re: [PATCH 4.6] Config: Switch to unified qemu trees."): > Are you going to apply this to 4.5 and older now too? Given the obvious > s/4.6/$X.$Y/g on this patch you may keep my ack on those too. Now done. There was some fiddliness around ~4.4. Hopefully the results are

Re: [Xen-devel] [libvirt] [PATCH v3 1/8] libxl: implement virDomainGetCPUStats

On 11/16/2015 07:59 PM, Jim Fehlig wrote: > On 11/13/2015 06:14 AM, Joao Martins wrote: > @@ -5233,6 +5342,7 @@ static virHypervisorDriver libxlHypervisorDriver = { > #endif > .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */ > .nodeGetCellsFreeMemory =

Re: [Xen-devel] Questions for patch "libxl: add basic spice support for pv domUs"

On Wed, Nov 18, 2015 at 12:13:06PM +0100, Fabio Fantoni wrote: > Long time ago, I did a libxl patch for add basic spice support for pv domUs. > I did some improvements based on comments I received, if I remember good I > did all except add of vfb parameters (vfb=['spice=1,...']) > Major of

Re: [Xen-devel] [PATCH v5 8/9] libxc: rework of domain builder's page table handler

On 11/18/2015 11:16 AM, Wei Liu wrote: On Wed, Nov 18, 2015 at 11:11:16AM -0500, Boris Ostrovsky wrote: On 11/12/2015 08:43 AM, Juergen Gross wrote: In order to prepare a p2m list outside of the initial kernel mapping do a rework of the domain builder's page table handler. The goal is to be

Re: [Xen-devel] [PATCH v5 1/6] xen/arm: vgic-v2: Implement correctly ITARGETSR0 - ITARGETSR7 read-only

On 16/11/15 13:23, Ian Campbell wrote: > On Mon, 2015-11-09 at 15:49 +, Julien Grall wrote: >> #define GICD_ITARGETSR (0x800) >> +#define GICD_ITARGETSR7 (0x81C) >> +#define GICD_ITARGETSR8 (0x820) > > As a future change, I wonder if making these take a parameter (N) and do > the necessary

[Xen-devel] [PATCH 2/4] xen/arm: p2m: Store the page for each mapping

The page will be use later for reference counting. So we need a quick access to the page associated to the mapping. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index

[Xen-devel] [PATCH 4/4] xen/arm: p2m: Remove translation table when it's empty

Currently, the translation table is left in place even if no entries is inuse. Because of how the p2m code has been implemented, replacing a translation table by a block (i.e superpage) is not supported. Therefore, any mapping of a superpage size will be split in smaller chunks making the

[Xen-devel] [PATCH 1/4] xen/arm: p2m: Flush for every exit paths in apply_p2m_changes

Currently, the TLB is not flushed if an error occured while updating the stage-2 p2m. However, the TLB will contain stall mappings for any entry updated so far. To avoid a such situation, flush on every exit paths when the variable "flush" is set. Signed-off-by: Julien Grall

[Xen-devel] [PATCH 0/4] xen/arm: p2m: Add support to remove empty translation table

Hello, The main purpose of this patch series is to allow creation of superpage when it has been previously shattered. The first patch is not related to the main purpose of this series but fix a latent bug I've found while looking at the p2m code. Sincerely yours, Julien Grall (4): xen/arm:

[Xen-devel] [PATCH 3/4] xen/arm: p2m: Introduce an helper to remove an entry in the page table

Factorize the code to remove an entry in p2m_remove_pte so we can re-use it later. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index

Re: [Xen-devel] [xen-4.6-testing test] 64505: regressions - FAIL

osstest service owner writes ("[xen-4.6-testing test] 64505: regressions - FAIL"): > flight 64505 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/64505/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run:

Re: [Xen-devel] [PATCH v5 8/9] libxc: rework of domain builder's page table handler

On 11/12/2015 08:43 AM, Juergen Gross wrote: In order to prepare a p2m list outside of the initial kernel mapping do a rework of the domain builder's page table handler. The goal is to be able to use common helpers for page table allocation and setup for initial kernel page tables and page

[Xen-devel] [PATCH 4.6] Config: Switch to unified qemu trees.

Upstream qemu is now in qemu-xen.git and the trad fork is in qemu-xen-traditional.git. QEMU_UPSTREAM_REVISION is currently a tag and QEMU_TRADITIONAL_REVISION is a specific revision, so no changes are required to those. Signed-off-by: Ian Campbell Acked-by: Ian Jackson

Re: [Xen-devel] [PATCH 4.6] Config: Switch to unified qemu trees.

>>> On 18.11.15 at 17:06, wrote: > Upstream qemu is now in qemu-xen.git and the trad fork is in > qemu-xen-traditional.git. > > QEMU_UPSTREAM_REVISION is currently a tag and > QEMU_TRADITIONAL_REVISION is a specific revision, so no changes are > required to those. > >

Re: [Xen-devel] [xen-unstable test] 64494: regressions - FAIL

On 18/11/15 16:59, Wei Liu wrote: > On Wed, Nov 18, 2015 at 04:54:34PM +0100, Juergen Gross wrote: >> On 18/11/15 15:49, Wei Liu wrote: >>> Hi Juergen >>> >>> Looks like there is something we missed after all. >>> >>> On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:

Re: [Xen-devel] Questions for patch "libxl: add basic spice support for pv domUs"

Il 18/11/2015 16:16, Konrad Rzeszutek Wilk ha scritto: On Wed, Nov 18, 2015 at 12:13:06PM +0100, Fabio Fantoni wrote: Long time ago, I did a libxl patch for add basic spice support for pv domUs. I did some improvements based on comments I received, if I remember good I did all except add of vfb

Re: [Xen-devel] [PATCH v3 2/8] libxl: implement virDomainMemorystats

On 11/17/2015 11:15 PM, Jim Fehlig wrote: > Joao Martins wrote: >> Introduce support for domainMemoryStats API call, which >> consequently enables the use of `virsh dommemstat` command to >> query for memory statistics of a domain. We support >> the following statistics: balloon info, available

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[cc +qemu-devel, +paolo, +gerd] On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote: > Hi all, > > We are pleased to announce another update of Intel GVT-g for Xen. > > Intel GVT-g is a full GPU virtualization solution with mediated > pass-through, starting from 4th generation Intel Core(TM)

[Xen-devel] Current LibXL Status

Hello All, I am currently working on the OpenXT project [1]. My work is currently focused on creating a shim layer between XenMgr [2] (written in Haskell) and LibXL. Goal is to replace the current XenOps/XenVM [3] (written in OCaml). I wanted to inquire about the current state of LibXL and in

[Xen-devel] [PATCH v2] xen/events: Always allocate legacy interrupts on PV guests

After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before allocating descs for legacy IRQs") early_irq_init() will no longer preallocate descriptors for legacy interrupts if PIC does not exist, which is the case for Xen PV guests. Therefore we may need to allocate those descriptors

[Xen-devel] [PATCH v3 2/2] block/xen-blkfront: Handle non-indirect grant with 64KB pages

The minimal size of request in the block framework is always PAGE_SIZE. It means that when 64KB guest is support, the request will at least be 64KB. Although, if the backend doesn't support indirect descriptor (such as QDISK in QEMU), a ring request is only able to accommodate 11 segments of 4KB

[Xen-devel] [PATCH v3 1/2] block/xen-blkfront: Introduce blkif_ring_get_request

The code to get a request is always the same. Therefore we can factorize it in a single function. Signed-off-by: Julien Grall Acked-by: Roger Pau Monné --- Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky

[Xen-devel] [PATCH v3 0/2] block/xen-blkfront: Support non-indirect grant with 64KB page granularity

Hi all, This is a follow-up on the previous discussion [1] related to guest using 64KB page granularity which doesn't boot when the backend isn't using indirect descriptor. This has been successfully tested on ARM64 with both 64KB and 4KB page granularity guests and QEMU as the backend. Indeed

[Xen-devel] [linux-mingo-tip-master test] 64510: regressions - FAIL

flight 64510 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/64510/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684

Re: [Xen-devel] [libvirt] [PATCH v3 1/8] libxl: implement virDomainGetCPUStats

On 11/18/2015 05:33 PM, Jim Fehlig wrote: > On 11/16/2015 07:59 PM, Jim Fehlig wrote: >> On 11/13/2015 06:14 AM, Joao Martins wrote: >> @@ -5233,6 +5342,7 @@ static virHypervisorDriver libxlHypervisorDriver = { >> #endif >> .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */ >>

Re: [Xen-devel] [PATCH v3 5/8] libxl: implement virDomainBlockStats

On 11/13/2015 06:14 AM, Joao Martins wrote: > Introduce initial support for domainBlockStats API call that > allow us to query block device statistics. openstack nova > uses this API call to query block statistics, alongside > virDomainMemoryStats and virDomainInterfaceStats. Note that > this

Re: [Xen-devel] [PATCH 2/3] x86: irq_enable_sysexit pv op is no longer needed

On Wed, Nov 18, 2015 at 03:06:18PM -0500, Boris Ostrovsky wrote: > Xen PV guests have been the only ones using it and now they don't. Could you elaborate on the 'now they don't' please? Is Xen not doing it? Did it do it in the past? Is it because the Linux code paths will never run to this in

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On Tue, Nov 17, 2015 at 05:30:59PM +, Andrew Cooper wrote: > On 17/11/15 17:04, Jan Beulich wrote: > On 03.11.15 at 18:58, wrote: > >> --- a/xen/common/grant_table.c > >> +++ b/xen/common/grant_table.c > >> @@ -178,6 +178,10 @@ struct active_grant_entry { >

[Xen-devel] [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack frame that is passed to xen_sysexit is no longer a "standard" one (i.e. it's not pt_regs). Since we end up calling xen_iret from xen_sysexit we don't

[Xen-devel] [PATCH 0/3] Fix and cleanup for 32-bit PV sysexit

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said

[Xen-devel] [PATCH 2/3] x86: irq_enable_sysexit pv op is no longer needed

Xen PV guests have been the only ones using it and now they don't. Signed-off-by: Boris Ostrovsky --- arch/x86/entry/entry_32.S | 8 ++-- arch/x86/include/asm/paravirt.h | 7 --- arch/x86/include/asm/paravirt_types.h | 9 -

[Xen-devel] [PATCH 3/3] x86: usergs_sysret32 pv op is no longer needed

Xen PV guests have been the only ones using it and now they don't. Signed-off-by: Boris Ostrovsky --- arch/x86/entry/entry_64_compat.S | 10 ++ arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 8

Re: [Xen-devel] [PATCH 2/3] x86: irq_enable_sysexit pv op is no longer needed

On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky wrote: > Xen PV guests have been the only ones using it and now they don't. Fantastic! --Andy ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard"

Re: [Xen-devel] [PATCH 2/3] x86: irq_enable_sysexit pv op is no longer needed

On 11/18/2015 03:11 PM, Konrad Rzeszutek Wilk wrote: On Wed, Nov 18, 2015 at 03:06:18PM -0500, Boris Ostrovsky wrote: Xen PV guests have been the only ones using it and now they don't. Could you elaborate on the 'now they don't' please? Is Xen not doing it? Did it do it in the past? Is it

Re: [Xen-devel] [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On Wed, Nov 18, 2015 at 12:50 PM, Brian Gerst wrote: > On Wed, Nov 18, 2015 at 3:21 PM, Andy Lutomirski wrote: >> On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky >> wrote: >>> After 32-bit syscall rewrite, and specifically

Re: [Xen-devel] [PATCH 3/3] x86: usergs_sysret32 pv op is no longer needed

On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky wrote: > Xen PV guests have been the only ones using it and now they don't. Yay! --Andy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests

On Wed, Nov 18, 2015 at 12:21:56PM -0800, Andy Lutomirski wrote: > > diff --git a/arch/x86/include/asm/cpufeature.h > > b/arch/x86/include/asm/cpufeature.h > > index e4f8010..0e4fe5b 100644 > > --- a/arch/x86/include/asm/cpufeature.h > > +++ b/arch/x86/include/asm/cpufeature.h > > @@ -216,6

Re: [Xen-devel] [PATCH v3 2/8] libxl: implement virDomainMemorystats

On 11/18/2015 11:05 AM, Joao Martins wrote: > > On 11/17/2015 11:15 PM, Jim Fehlig wrote: >> Joao Martins wrote: >>> Introduce support for domainMemoryStats API call, which >>> consequently enables the use of `virsh dommemstat` command to >>> query for memory statistics of a domain. We support >>>

Re: [Xen-devel] [PATCH v3 4/8] util: add virDiskNameParse to handle disk and partition idx

On 11/13/2015 06:14 AM, Joao Martins wrote: > Introduce a new helper function "virDiskNameParse" which extends > virDiskNameToIndex but handling both disk index and partition index. > Also rework virDiskNameToIndex to be based on virDiskNameParse. > A test is also added for this function testing

Re: [Xen-devel] missing block script support for qemu in libxl

On Wed, Nov 18, 2015 at 9:35 AM, George Dunlap wrote: > On Wed, Nov 18, 2015 at 9:25 AM, Olaf Hering wrote: >> Why does libxl now allow script= with backend=tap|qdisk? See >> tools/libxl/libxl_device.c:disk_try_backend. >> >> Ideally the script should

Re: [Xen-devel] [PATCH 00/10] x86/hvm: pkeys, add memory protection-key support

On 18/11/15 09:12, Wu, Feng wrote: > >> -Original Message- >> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- >> boun...@lists.xen.org] On Behalf Of Jan Beulich >> Sent: Tuesday, November 17, 2015 6:26 PM >> To: Andrew Cooper >> Cc: Tian, Kevin

Re: [Xen-devel] [PATCH] xen/events: Always allocate legacy interrupts on PV guests

Boris Ostrovsky writes: > After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before > allocating descs for legacy IRQs") early_irq_init() will no longer > preallocate descriptors for legacy interrupts if PIT does not > exist. PIC? > > Therefore we need to

Re: [Xen-devel] [PATCH v5 4/4] docs: Introduce xenstore paths for guest network address information

> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: 18 November 2015 12:00 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; Keir (Xen.org); Ian Campbell; Tim > (Xen.org); Ian Jackson; Jan Beulich > Subject: Re: [Xen-devel] [PATCH v5 4/4] docs: Introduce

[Xen-devel] [ovmf baseline-only test] 38304: all pass

This run is configured for baseline tests only. flight 38304 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38304/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf bd3afeb1d62c68d8144d39e82bb188b2af3ca60c baseline version:

[Xen-devel] [distros-debian-squeeze test] 38305: all pass

flight 38305 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38305/ Perfect :-) All tests in this flight passed baseline version: flight 38266 jobs: build-amd64 pass build-armhf

Re: [Xen-devel] [PATCH v3 01/62] Revert "xen/arm: vgic-v2: Drop cbase from arch_domain"

On 2015/11/18 19:41, Julien Grall wrote: Hi Shannon, On 18/11/15 02:28, Shannon Zhao wrote: On 2015/11/17 21:57, Julien Grall wrote: On 17/11/15 12:32, Shannon Zhao wrote: Hi Julien, On 2015/11/17 19:27, Julien Grall wrote: Hi Shannon, Why do you want to revert this patch? Because

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 12:07, Ian Campbell wrote: > On Wed, 2015-11-18 at 11:56 +, Malcolm Crossley wrote: >> On 18/11/15 11:50, Ian Campbell wrote: >>> On Wed, 2015-11-18 at 11:23 +, Malcolm Crossley wrote: On 18/11/15 10:54, Jan Beulich wrote: On 18.11.15 at 11:36,

Re: [Xen-devel] [PATCH v2 2/3] xen/hvm: introduce a fpu_uninitialised field to the CPU save record

>>> On 18.11.15 at 12:00, wrote: > As for the problem at hand, I don't see what was wrong with v1. > > Fundamentally, we have three different variations of the same structure; > two of which require special compat handling. Pretending otherwise is > just silly. And

Re: [Xen-devel] [PATCH v5 4/4] docs: Introduce xenstore paths for guest network address information

On Tue, Nov 17, Paul Durrant wrote: > This patch documents paths to allow a domain to advertise an interface > name, MAC (unicast and multicast) and IP (version 4 and 6) address > information. How does the domU do that in practice? With some variant of xenstore-write or with the PV vif driver?

[Xen-devel] [PATCH] Config.mk: Update SEABIOS_UPSTREAM_TAG to rel-1.9.0

Signed-off-by: Ian Campbell --- Right now osstest has tested rel-1.9.0~1 (flight 64145 http://lists.xen.org/archives/html/xen-devel/2015-11/msg01380.html ). However the final commit simply updates docs/Releases.md to cover 1.9.0 so I don't anticipate any problems. ---

Re: [Xen-devel] [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio

On 2015/11/18 20:27, Julien Grall wrote: On 18/11/15 06:03, Shannon Zhao wrote: What about the removal of a bus device? No need to handle that? I have thought about removal before. I think there is little(or no) chance for AMBA and platform bus devices to be removed. It's not like the PCI

[Xen-devel] [linux-linus test] 64484: regressions - FAIL

flight 64484 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/64484/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 59254

Re: [Xen-devel] [PATCH v3 38/62] arm/acpi: Add placeholder for efi and acpi load address

On 18/11/15 03:01, Shannon Zhao wrote: > "All above tables will be mapped to Dom0 non-RAM space. Since when > booting through ACPI it doesn't need the grant table region(see below > section 3), it could use this region to store the tables or use the same > way to find one memory region to store

Re: [Xen-devel] [PATCH v3 51/62] arm/acpi: Prepare EFI system table for Dom0

On 17/11/15 09:40, shannon.z...@linaro.org wrote: > From: Shannon Zhao > > Signed-off-by: Parth Dixit > Signed-off-by: Shannon Zhao > --- > xen/arch/arm/domain_build.c | 2 ++ > xen/common/efi/boot.c | 64 >

Re: [Xen-devel] [PATCH v2 2/3] xen/hvm: introduce a fpu_uninitialised field to the CPU save record

On 18/11/15 10:51, Roger Pau Monné wrote: > El 17/11/15 a les 19.02, Andrew Cooper ha escrit: >> On 17/11/15 18:44, Roger Pau Monne wrote: >>> Introduce a new filed to signal if the FPU has been initialised or not. Xen >> field >> >>> needs this new filed in order to know whether to set the FPU as

Re: [Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

On 18/11/15 10:54, Jan Beulich wrote: On 18.11.15 at 11:36, wrote: >> On Tue, 2015-11-17 at 17:53 +, Andrew Cooper wrote: >>> On 17/11/15 17:39, Jan Beulich wrote: >>> On 17.11.15 at 18:30, wrote: > On 17/11/15 17:04, Jan

Re: [Xen-devel] [PATCH v3 01/62] Revert "xen/arm: vgic-v2: Drop cbase from arch_domain"

Hi Shannon, On 18/11/15 02:28, Shannon Zhao wrote: > On 2015/11/17 21:57, Julien Grall wrote: >> On 17/11/15 12:32, Shannon Zhao wrote: Hi Julien, On 2015/11/17 19:27, Julien Grall wrote: >> Hi Shannon, >> >> Why do you want to revert this patch? >> Because

Re: [Xen-devel] [PATCH v3 24/62] arm: Introduce a generic way to use a device from acpi

On 18/11/15 02:37, Shannon Zhao wrote: > > > On 2015/11/17 22:25, Julien Grall wrote: >> On 17/11/15 13:21, Shannon Zhao wrote: AFAICT, it does only works for SPCR table used for UART device. For the GIC you've hardcoded the value and I can't find any version number in the table.

Re: [Xen-devel] [PATCH 06/13] Xen: ARM: Add support for mapping amba device mmio

On 18/11/15 06:03, Shannon Zhao wrote: >> >> What about the removal of a bus device? No need to handle that? >> > I have thought about removal before. I think there is little(or no) > chance for AMBA and platform bus devices to be removed. It's not like > the PCI devices which will be hot-unplug.

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

On Wed, Nov 18, Ian Campbell wrote: > I'd been hoping that someone involved ion this would generate a patch > adding a template for this controller+devices model to libxl.h, I've not > seen anything since George's original RFC[0] "libxl: Introduce a template > for devices with a controller". Its

Re: [Xen-devel] [PATCH v2 2/3] xen/hvm: introduce a fpu_uninitialised field to the CPU save record

El 17/11/15 a les 19.02, Andrew Cooper ha escrit: > On 17/11/15 18:44, Roger Pau Monne wrote: >> Introduce a new filed to signal if the FPU has been initialised or not. Xen > > field > >> needs this new filed in order to know whether to set the FPU as initialised >> or not during restore of CPU

[Xen-devel] Questions for patch "libxl: add basic spice support for pv domUs"

Long time ago, I did a libxl patch for add basic spice support for pv domUs. I did some improvements based on comments I received, if I remember good I did all except add of vfb parameters (vfb=['spice=1,...']) Major of advanced spice features can't be added in pv (also now based on what I

Re: [Xen-devel] [PATCH v2 2/3] xen/hvm: introduce a fpu_uninitialised field to the CPU save record

On 18/11/15 11:04, Jan Beulich wrote: On 18.11.15 at 12:00, wrote: >> As for the problem at hand, I don't see what was wrong with v1. >> >> Fundamentally, we have three different variations of the same structure; >> two of which require special compat handling.

  1   2   >