Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

> From: Tim Deegan [mailto:t...@xen.org] > Sent: Thursday, January 08, 2015 8:43 PM > > Hi, > > > > Not really. The IOMMU tables are also 64-bit so there must be enough > > > addresses to map all of RAM. There shouldn't be any need for these > > > mappings to be _contiguous_, btw. You just nee

Re: [Xen-devel] [PATCH 1/3] x86: also allow REP STOS emulation acceleration

>>> On 08.01.15 at 20:29, wrote: > On 08/01/15 15:50, Jan Beulich wrote: >> +if ( !buf ) >> +buf = p_data; >> +else >> +switch ( bytes_per_rep ) >> +{ >> +#define CASE(bits, suffix) \ >> +case (bit

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

Hi all, We're pleased to announce a public update to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors

Re: [Xen-devel] (v2) Design proposal for RMRR fix

>>> On 08.01.15 at 19:02, wrote: > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote: > On 08.01.15 at 16:59, wrote: >>> It seems a lot cleaner to me to have the toolstack tell Xen what >>> ranges are reserved for RMRR per VM, and then have Xen check again >>> when assigning a device to make

Re: [Xen-devel] (v2) Design proposal for RMRR fix

>>> On 09.01.15 at 03:27, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Thursday, January 08, 2015 9:55 PM >> >>> On 26.12.14 at 12:23, wrote: >> > 3) hvmloader >> > Hvmloader allocates other resources (ACPI, PCI MMIO, etc.) and >> > internal data structures in gfn space, and

Re: [Xen-devel] (v2) Design proposal for RMRR fix

>>> On 09.01.15 at 03:29, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Thursday, January 08, 2015 8:59 PM >> >> >>> On 08.01.15 at 13:49, wrote: >> > One question: where are these RMRRs typically located in memory? Are >> > they normally up in the MMIO region? Or can they o

[Xen-devel] [linux-3.10 test] 33271: regressions - trouble: broken/fail/pass

flight 33271 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33271/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Tests which are failin

Re: [Xen-devel] [libvirt test] 33157: regressions - trouble: blocked/fail/pass/preparing/queued

On Thu, 2015-01-08 at 14:56 -0700, Jim Fehlig wrote: > Jim Fehlig wrote: > > Ian Campbell wrote: > > > > > >> I must confess that I thought you already did use libxlu... > >> > >> > > > > No, not directly. But I will be doing so now. I should try to revert > > all this nonsense and use

Re: [Xen-devel] (v2) Design proposal for RMRR fix

>>> On 09.01.15 at 07:57, wrote: > 1) 'fail' vs. 'warn' upon gfn confliction > > Assigning device which fails RMRR confliction check (i.e. intended gfns > already allocated for other resources) actually brings unknown stability > problem (device may clobber those valid resources) and potentiall

Re: [Xen-devel] [PATCH 3/3] xen: use correct type for physical addresses

>>> On 08.01.15 at 18:01, wrote: > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -140,7 +140,7 @@ static void __init xen_del_extra_mem(u64 start, u64 size) > unsigned long __ref xen_chk_extra_mem(unsigned long pfn) > { > int i; > - unsigned long addr = PFN_PHYS(pfn); > +

Re: [Xen-devel] [RFC V9 4/4] domain snapshot design: libxl/libxlu

>>> On 1/8/2015 at 08:11 PM, in message <1420719107.19787.53.ca...@citrix.com>, >>> Ian Campbell wrote: > On Mon, 2014-12-22 at 02:36 -0700, Chun Yan Liu wrote: > > > > b). For internal snapshot, like qcow2, lvm too. For lvm, it doesn't > support > > > > snapshot of snapshot, so out of sc

Re: [Xen-devel] xen-ringwatch issues

On Thu, 2015-01-08 at 14:07 -0500, moftah moftah wrote: > Hi All, > We are using Xenserver 6.2 FYI xenserver is developed as a separate project over at www.xenserver.org, so in general you should be reporting issue/requesting help over on their forums and lists etc. However, since xen-ringwatch i

Re: [Xen-devel] (v2) Design proposal for RMRR fix

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, January 09, 2015 5:24 PM > > >>> On 09.01.15 at 03:29, wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: Thursday, January 08, 2015 8:59 PM > >> > >> >>> On 08.01.15 at 13:49, wrote: > >> > One question: where are

Re: [Xen-devel] (v2) Design proposal for RMRR fix

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, January 09, 2015 5:21 PM > > >>> On 09.01.15 at 03:27, wrote: > >> From: Jan Beulich [mailto:jbeul...@suse.com] > >> Sent: Thursday, January 08, 2015 9:55 PM > >> >>> On 26.12.14 at 12:23, wrote: > >> > 3) hvmloader > >> > Hvmload

Re: [Xen-devel] [PATCH 0/3] XSA-114 follow-ups

On 08/01/15 16:28, Tim Deegan wrote: > At 16:00 + on 08 Jan (1420729255), Jan Beulich wrote: >> 1: spinlock: use local_irq_disable() instead of local_irq_save() where >> possible >> 2: rwlock: allow arch to override read_unlock() atomic >> 3: rwlock: allow arch to override write_unlock() atomi

Re: [Xen-devel] [PATCH 3/3] x86/HVM: vMSI simplification

On 08/01/15 15:52, Jan Beulich wrote: > - struct msixtbl_entry's table_len field can be unsigned int, and by > moving it down a little the structure size can be reduced slightly > - a disjoint xmalloc()/memset() pair can be converted to xzalloc() > - a pointless local variable can be dropped > >

[Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

While the REP MOVS acceleration appears to have helped qemu-traditional based guests, qemu-upstream (or really the respective video BIOSes) doesn't appear to benefit from that. Instead the acceleration added here provides a visible performance improvement during very early HVM guest boot. Signed-o

Re: [Xen-devel] (v2) Design proposal for RMRR fix

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, January 09, 2015 5:46 PM > > >>> On 09.01.15 at 07:57, wrote: > > 1) 'fail' vs. 'warn' upon gfn confliction > > > > Assigning device which fails RMRR confliction check (i.e. intended gfns > > already allocated for other resources) act

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

flight 33280 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33280/ 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. 32648 build-i386-libvirt

[Xen-devel] [seabios test] 33272: trouble: blocked/broken/fail/pass

flight 33272 seabios real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33272/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3863 host-install(3) broken REGR. vs. 32830 Test

Re: [Xen-devel] (v2) Design proposal for RMRR fix

>>> On 09.01.15 at 11:10, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Boot time device assignment is different: The question isn't whether >> an assigned device works, instead the proper analogy is whether a >> device is _present_. If a device doesn't work on bare metal, it will >>

Re: [Xen-devel] (v2) Design proposal for RMRR fix

>>> On 09.01.15 at 11:26, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >>> On 09.01.15 at 07:57, wrote: >> > 1.1) per-device 'warn' vs. global 'warn' >> > >> > Both Tim/Jan prefer to 'warn' as a per-device option to the admin instead >> > of a global option. >> > >> > In a glimpse a

[Xen-devel] [PATCH] MAINTAINERS: Andrew Cooper to co-maintain x86

Signed-off-by: Jan Beulich --- a/MAINTAINERS +++ b/MAINTAINERS @@ -341,6 +341,7 @@ X86 ARCHITECTURE M: Keir Fraser M: Jan Beulich +M: Andrew Cooper S: Supported L: xen-devel@lists.xen.org F: xen/arch/x86/ ___ Xen-de

Re: [Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

On 09/01/15 10:27, Jan Beulich wrote: > While the REP MOVS acceleration appears to have helped qemu-traditional > based guests, qemu-upstream (or really the respective video BIOSes) > doesn't appear to benefit from that. Instead the acceleration added > here provides a visible performance improveme

Re: [Xen-devel] [PATCH] MAINTAINERS: Andrew Cooper to co-maintain x86

On 09/01/15 10:55, Jan Beulich wrote: > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper (or Reviewed-by perhaps? I am not certain of the protocol here) > > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -341,6 +341,7 @@ > X86 ARCHITECTURE > M: Keir Fraser > M: Jan Beulich > +M: Andre

Re: [Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

>>> On 09.01.15 at 11:56, wrote: > On 09/01/15 10:27, Jan Beulich wrote: >> While the REP MOVS acceleration appears to have helped qemu-traditional >> based guests, qemu-upstream (or really the respective video BIOSes) >> doesn't appear to benefit from that. Instead the acceleration added >> here

Re: [Xen-devel] [PATCH] MAINTAINERS: Andrew Cooper to co-maintain x86

>>> On 09.01.15 at 12:01, wrote: > On 09/01/15 10:55, Jan Beulich wrote: >> Signed-off-by: Jan Beulich > > Acked-by: Andrew Cooper > > (or Reviewed-by perhaps? I am not certain of the protocol here) I'd call it Accepted-by in this case, and would be expecting a formal ack from Keir before com

Re: [Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

At 10:56 + on 09 Jan (1420797418), Andrew Cooper wrote: > On 09/01/15 10:27, Jan Beulich wrote: > > While the REP MOVS acceleration appears to have helped qemu-traditional > > based guests, qemu-upstream (or really the respective video BIOSes) > > doesn't appear to benefit from that. Instead th

Re: [Xen-devel] [PATCH 3/3] x86/HVM: make hvm_efer_valid() honor guest features

>>> On 08.01.15 at 19:49, wrote: > On 08/01/15 15:23, Jan Beulich wrote: >> Following the earlier similar change validating CR4 modifications. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -1672,20 +1672,53 @@ static int hvm_save_cpu_ctx

Re: [Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

>>> On 09.01.15 at 12:18, wrote: > At 10:56 + on 09 Jan (1420797418), Andrew Cooper wrote: >> On 09/01/15 10:27, Jan Beulich wrote: >> > While the REP MOVS acceleration appears to have helped qemu-traditional >> > based guests, qemu-upstream (or really the respective video BIOSes) >> > doesn't

Re: [Xen-devel] [PATCH] treewide: Convert clockevents_notify to use int cpu

On Wed, Dec 10, 2014 at 03:28:53PM -0800, Joe Perches wrote: [...] > arch/arm/mach-tegra/cpuidle-tegra114.c | 4 ++-- > arch/arm/mach-tegra/cpuidle-tegra20.c | 8 > arch/arm/mach-tegra/cpuidle-tegra30.c | 8 [...] Acked-by: Thierry Reding pgpsUlJQpYjp_.pgp Description: PG

Re: [Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote: > >>> On 09.01.15 at 12:18, wrote: > >> > +default: > >> > +xfree(buf); > >> > +ASSERT(!buf); > > > > looks dodgy... > > In which way? The "default" is supposed to be unreachable, and sits > in

Re: [Xen-devel] (v2) Design proposal for RMRR fix

On 09/01/15 00:53, Tian, Kevin wrote: >> From: Tim Deegan [mailto:t...@xen.org] >> Sent: Thursday, January 08, 2015 8:32 PM >> >> Hi Kevin, >> >> Thanks for sending out this design document. I think Jan will have >> the most to say about this. Looking just at the hypervisor side of >> things, and

Re: [Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

>>> On 09.01.15 at 12:45, wrote: > At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote: >> >>> On 09.01.15 at 12:18, wrote: >> >> > +default: >> >> > +xfree(buf); >> >> > +ASSERT(!buf); >> > >> > looks dodgy... >> >> In which way? The "default" i

[Xen-devel] [PATCH v3] libxl: Spice streaming video setting support for upstream qemu

Usage: spice_streaming_video=[filter|all|off] Specifies what streaming video setting is to be used by spice (if given), otherwise the qemu default will be used. Signed-off-by: Fabio Fantoni --- Changes in v3: - fixed a mistake in libxl_dm.c Changes in v2: - refresh --- docs/man/xl.cfg.pod.5

Re: [Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

On 09/01/15 12:10, Jan Beulich wrote: On 09.01.15 at 12:45, wrote: >> At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote: >> On 09.01.15 at 12:18, wrote: >> +default: >> +xfree(buf); >> +ASSERT(!buf); looks dodgy... >>> I

Re: [Xen-devel] [PATCH 3/3] xen: use correct type for physical addresses

On 09/01/15 09:57, Jan Beulich wrote: On 08.01.15 at 18:01, wrote: >> --- a/arch/x86/xen/setup.c >> +++ b/arch/x86/xen/setup.c >> @@ -140,7 +140,7 @@ static void __init xen_del_extra_mem(u64 start, u64 size) >> unsigned long __ref xen_chk_extra_mem(unsigned long pfn) >> { >> int i; >>

Re: [Xen-devel] [PATCH 3/3] xen: use correct type for physical addresses

On 08/01/15 17:01, Juergen Gross wrote: > When converting a pfn to a physical address be sure to use 64 bit > wide types. > > Also avoid invalidating memory for zero sized non-aligned extra > memory regions. "Also" means this bit should be in another patch... > Signed-off-by: Juergen Gross > Te

Re: [Xen-devel] [PATCH 3/3] xen: use correct type for physical addresses

>>> On 09.01.15 at 13:51, wrote: > On 09/01/15 09:57, Jan Beulich wrote: > On 08.01.15 at 18:01, wrote: >>> @@ -284,7 +286,7 @@ static void __init xen_update_mem_tables(unsigned long >>> pfn, unsigned long mfn) >>> } >>> >>> /* Update kernel mapping, but not for highmem. */ >>> -

Re: [Xen-devel] [PATCH v3 1/2] gnttab: Introduce rwlock to protect updates to grant table state

On 2014/12/18 12:37, Jan Beulich wrote: On 03.12.14 at 15:29, wrote: >> --- a/xen/common/grant_table.c >> +++ b/xen/common/grant_table.c [...] >> @@ -944,6 +944,7 @@ __gnttab_unmap_common( >> } >> >> op->rd = rd; >> +read_lock(&rgt->lock); >> act = &active_entry(rgt, op->

Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week), GA slip + 1 day

Note that I published the Acknowledgements and most 4.5 documentation is now in place. Bits which you may want to check and fix * Spelling of your name if it contains special characters as the scripts that I use nuke them - http://wiki.xenproject.org/wiki/Xen_Project_4.5_Acknowledgements * Some a

[Xen-devel] [PATCH] libxl: Don't ignore error when we fail to give access to ioport/irq

If we fail to give the access, the domain will unlikely work correctly. So we should bail out at the first error. Signed-off-by: Julien Grall Cc: Ian Jackson Cc: Stefano Stabellini Cc: Ian Campbell Cc: Wei Liu --- This patch is candidate for a backport for at least Xen 4.4 and Xen 4.5. ---

Re: [Xen-devel] [PATCH v3 1/2] gnttab: Introduce rwlock to protect updates to grant table state

>>> On 09.01.15 at 14:05, wrote: > On 2014/12/18 12:37, Jan Beulich wrote: > On 03.12.14 at 15:29, wrote: >>> --- a/xen/common/grant_table.c >>> +++ b/xen/common/grant_table.c > [...] >>> @@ -944,6 +944,7 @@ __gnttab_unmap_common( >>> } >>> >>> op->rd = rd; >>> +read_lock(&rgt

Re: [Xen-devel] [PATCH] libxl: Don't ignore error when we fail to give access to ioport/irq

On Fri, Jan 09, 2015 at 01:54:22PM +, Julien Grall wrote: > If we fail to give the access, the domain will unlikely work correctly. > So we should bail out at the first error. > > Signed-off-by: Julien Grall > Cc: Ian Jackson > Cc: Stefano Stabellini > Cc: Ian Campbell > Cc: Wei Liu > >

Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week), GA slip + 1 day

Sorry, I forgot to CC xen-devel. On 9 January 2015 at 14:19, Julien Grall wrote: > (Dropping most of the CC) > > Hi Lars, > > On 09/01/15 13:51, Lars Kurth wrote: >> Note that I published the Acknowledgements and most 4.5 documentation is now >> in place. Bits which you may want to check and fix

Re: [Xen-devel] [PATCH] libxl: Don't ignore error when we fail to give access to ioport/irq

Hi Wei, On 09/01/15 14:15, Wei Liu wrote: > On Fri, Jan 09, 2015 at 01:54:22PM +, Julien Grall wrote: >> If we fail to give the access, the domain will unlikely work correctly. >> So we should bail out at the first error. >> >> Signed-off-by: Julien Grall >> Cc: Ian Jackson >> Cc: Stefano St

[Xen-devel] [PATCH] libxl: provide xenlight.pc

A pkg-config file for libxl. It also contains two variables (xenfirmwaredir and libexec_bin) so that tools that are very keen on knowing the locations of Xen binaries (say, libvirt) can use them to determine the location of the binaries. Please rerun autogen.sh after applying this patch. Signed-o

Re: [Xen-devel] [PATCH] MAINTAINERS: Andrew Cooper to co-maintain x86

Jan Beulich 9 January 2015 10:55 Signed-off-by: Jan Beulich Acked-by: Keir Fraser --- a/MAINTAINERS +++ b/MAINTAINERS @@ -341,6 +341,7 @@ X86 ARCHITECTURE M: Keir Fraser M: Jan Beulich +M: Andrew Cooper S: Supported L: xen-devel@lists.xen.org F: xen/arch/x86/

Re: [Xen-devel] [PATCH resend] libxl, hotplug/Linux: default to phy backend for raw format file, take 2

On Thu, Jan 08, 2015 at 03:33:17PM +0100, Fabio Fantoni wrote: > Il 08/01/2015 14:46, Wei Liu ha scritto: > >This patch resurrects 11a63a166. The previous patch had a bug that > >wrong "physical-device" was written to xenstore causing block script > >execution fail. This patch fixes that problem. >

Re: [Xen-devel] [PATCH] tools/misc: Cleanup makefile

On Thu, Jan 08, 2015 at 01:34:22PM +, Andrew Cooper wrote: > The existing makefile was awkward with needing to express conditional > inclusion for both the build and install rules, and contained both split and > unsplit long lines. > > The INSTALL_* rules now contain the conditional inclusion

Re: [Xen-devel] [PATCH v3 1/2] gnttab: Introduce rwlock to protect updates to grant table state

On 2015/01/09 15:10, Jan Beulich wrote: On 09.01.15 at 14:05, wrote: >> On 2014/12/18 12:37, Jan Beulich wrote: >> On 03.12.14 at 15:29, wrote: --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c >> [...] @@ -944,6 +944,7 @@ __gnttab_unmap_common( } >>>

Re: [Xen-devel] [PATCH 2/3] xen: correct race in alloc_p2m_pmd()

On 08/01/15 17:01, Juergen Gross wrote: > When allocating a new pmd for the linear mapped p2m list a check is > done for not introducing another pmd when this just happened on > another cpu. In this case the old pte pointer was returned which > points to the p2m_missing or p2m_identity page. The co

Re: [Xen-devel] [PATCH 3/3] x86/HVM: make hvm_efer_valid() honor guest features

On 09/01/15 11:20, Jan Beulich wrote: On 08.01.15 at 19:49, wrote: >> On 08/01/15 15:23, Jan Beulich wrote: >>> Following the earlier similar change validating CR4 modifications. >>> >>> Signed-off-by: Jan Beulich >>> >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -

Re: [Xen-devel] [PATCH 3/3] xen: use correct type for physical addresses

On 09/01/15 12:56, Jan Beulich wrote: On 09.01.15 at 13:51, wrote: >> On 09/01/15 09:57, Jan Beulich wrote: >> On 08.01.15 at 18:01, wrote: @@ -284,7 +286,7 @@ static void __init xen_update_mem_tables(unsigned long pfn, unsigned long mfn) } /* Update ker

[Xen-devel] [PATCH v4 0/2] gnttab: Improve scaleability

This patch series changes the grant table locking to a more fain grained locking protocol. The result is a performance boost measured with blkfront/blkback. Document the locking protocol. v4: * Coding style nits from Jan Beulich * Fixup read locks pointed out by Jan Beulich * renamed double_

[Xen-devel] [PATCH v4 2/2] gnttab: refactor locking for scalability

From: Matt Wilson This patch refactors grant table locking. It splits the previous single spinlock per grant table into multiple locks. The heavily modified components of the grant table (the maptrack state and the active entries) are now protected by their own spinlocks. The remaining elements o

[Xen-devel] [PATCH v4 1/2] gnttab: Introduce rwlock to protect updates to grant table state

Split grant table lock into two separate locks. One to protect maptrack state and change the other into a rwlock. The rwlock is used to prevent readers from accessing inconsistent grant table state such as current version, partially initialized active table pages, etc. Signed-off-by: Matt Wilson

Re: [Xen-devel] [PATCH 2/3] xen: correct race in alloc_p2m_pmd()

On 01/09/2015 04:09 PM, David Vrabel wrote: On 08/01/15 17:01, Juergen Gross wrote: When allocating a new pmd for the linear mapped p2m list a check is done for not introducing another pmd when this just happened on another cpu. In this case the old pte pointer was returned which points to the p

Re: [Xen-devel] [PATCH v2 1/3] x86: also allow REP STOS emulation acceleration

At 12:46 + on 09 Jan (1420804005), Andrew Cooper wrote: > On 09/01/15 12:10, Jan Beulich wrote: > On 09.01.15 at 12:45, wrote: > >> At 11:24 + on 09 Jan (1420799087), Jan Beulich wrote: > >> On 09.01.15 at 12:18, wrote: > >> +default: > >> +xfr

Re: [Xen-devel] [PATCH] MAINTAINERS: Andrew Cooper to co-maintain x86

On Fri, Jan 09, 2015 at 11:01:01AM +, Andrew Cooper wrote: > On 09/01/15 10:55, Jan Beulich wrote: > > Signed-off-by: Jan Beulich > > Acked-by: Andrew Cooper > > (or Reviewed-by perhaps? I am not certain of the protocol here) Congrantulations-by: Konrad Rzeszutek Wilk :-) > > > > > ---

Re: [Xen-devel] [PATCH 3/3] x86/HVM: make hvm_efer_valid() honor guest features

>>> On 09.01.15 at 16:09, wrote: > On 09/01/15 11:20, Jan Beulich wrote: > On 08.01.15 at 19:49, wrote: >>> I think hvm_efer_valid() also needs the current EFER and CR0 to work out >>> what the current LMA should be, and reject any attempt to change it. >> I.e. this would be needed only for t

Re: [Xen-devel] [PATCH v2] libxl: Spice image compression setting support for upstream qemu

On Thu, Jan 08, 2015 at 04:26:30PM +0100, Fabio Fantoni wrote: > Usage: > spice_image_compression=[auto_glz|auto_lz|quic|glz|lz|off] > > Specifies what image compression is to be used by spice (if given), > otherwise the qemu default will be used. > > Signed-off-by: Fabio Fantoni > > --- > > C

Re: [Xen-devel] [PATCH 3/3] x86/HVM: make hvm_efer_valid() honor guest features

On 09/01/15 15:33, Jan Beulich wrote: On 09.01.15 at 16:09, wrote: >> On 09/01/15 11:20, Jan Beulich wrote: >> On 08.01.15 at 19:49, wrote: I think hvm_efer_valid() also needs the current EFER and CR0 to work out what the current LMA should be, and reject any attempt to change

Re: [Xen-devel] [PATCH v3] libxl: Spice streaming video setting support for upstream qemu

On Fri, Jan 09, 2015 at 01:32:12PM +0100, Fabio Fantoni wrote: [...] > * LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS 1 > * > * If this is defined, libxl_domain_create_restore()'s API has changed to > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c > index e1188f4..e80b8d7 100644 > --

Re: [Xen-devel] [PATCH] xen/blkfront: restart request queue when there is enough persistent_gnts_c

El 06/01/15 a les 14.19, Bob Liu ha escrit: > When there is no enough free grants, gnttab_alloc_grant_references() > will fail and block request queue will stop. > If the system is always lack of grants, blkif_restart_queue_callback() can't > be > scheduled and block request queue can't be restart

Re: [Xen-devel] [PATCH 12/12] xen/gntdev: provide a set of pages for each VMA

On Tue, 6 Jan 2015, David Vrabel wrote: > From: Jenny Herbert > > For each VMA for grant maps, provide the correct array of pages so > get_user_pages() on foreign mappings works in PV guests. > > Signed-off-by: Jenny Herbert > Signed-off-by: David Vrabel > --- > drivers/xen/gntdev.c |2 ++

[Xen-devel] [PATCH v2] libxl: Don't ignore error when we fail to give access to ioport/irq/iomem

If we fail to give the access, the domain will unlikely work correctly. So we should bail out at the first error. Signed-off-by: Julien Grall Cc: Ian Jackson Cc: Stefano Stabellini Cc: Ian Campbell Cc: Wei Liu --- This patch is candidate for a backport for at least Xen 4.4 and Xen 4.5.

Re: [Xen-devel] [PATCH 1/3] spinlock: use local_irq_disable() instead of local_irq_save() where possible

On Thu, Jan 08, 2015 at 04:13:03PM +, Jan Beulich wrote: > ... as generally being a cheaper operation. I was wondering if it would be possible to change some of the EFLAGS after when we go in the 'cpu_relax' - and an interrupt happens, we process it, alter the EFLAGS, then when we are done, th

Re: [Xen-devel] [PATCH 06/12] xen: mark grant mapped pages as foreign

On Tue, 6 Jan 2015, David Vrabel wrote: > From: Jenny Herbert > > Use the "foreign" page flag to mark pages that have a grant map. Use > page->private to store information of the grant (the granting domain > and the grant reference). > > Signed-off-by: Jenny Herbert > Signed-off-by: David Vrab

Re: [Xen-devel] [PATCH 12/12] xen/gntdev: provide a set of pages for each VMA

On Fri, 9 Jan 2015, Stefano Stabellini wrote: > On Tue, 6 Jan 2015, David Vrabel wrote: > > From: Jenny Herbert > > > > For each VMA for grant maps, provide the correct array of pages so > > get_user_pages() on foreign mappings works in PV guests. > > > > Signed-off-by: Jenny Herbert > > Signed

Re: [Xen-devel] [PATCH v2] libxl: Don't ignore error when we fail to give access to ioport/irq/iomem

On Fri, Jan 09, 2015 at 03:56:45PM +, Julien Grall wrote: > If we fail to give the access, the domain will unlikely work correctly. > So we should bail out at the first error. > > Signed-off-by: Julien Grall > Cc: Ian Jackson > Cc: Stefano Stabellini > Cc: Ian Campbell Acked-by: Wei Liu

Re: [Xen-devel] [PATCH 1/3] spinlock: use local_irq_disable() instead of local_irq_save() where possible

>>> On 09.01.15 at 17:02, wrote: > On Thu, Jan 08, 2015 at 04:13:03PM +, Jan Beulich wrote: >> ... as generally being a cheaper operation. > > I was wondering if it would be possible to change some of the > EFLAGS after when we go in the 'cpu_relax' - and an interrupt > happens, we process it

Re: [Xen-devel] [PATCH 1/3] spinlock: use local_irq_disable() instead of local_irq_save() where possible

On 09/01/15 16:02, Konrad Rzeszutek Wilk wrote: > On Thu, Jan 08, 2015 at 04:13:03PM +, Jan Beulich wrote: >> ... as generally being a cheaper operation. > I was wondering if it would be possible to change some of the > EFLAGS after when we go in the 'cpu_relax' - and an interrupt > happens, we

Re: [Xen-devel] [PATCH 08/12] xen/grant-table: add a mechanism to safely unmap pages that are in use

On Tue, 6 Jan 2015, David Vrabel wrote: > From: Jenny Herbert > > Introduce gnttab_unmap_refs_async() that can be used to safely unmap > pages that may be in use (ref count > 1). If the pages are in use the > unmap is deferred and retried later. This polling is not very clever > but it should b

[Xen-devel] [PATCH] libxl/arm: Correctly spelled FDT_ERR_* in a comment

Signed-off-by: Julien Grall Cc: Ian Jackson Cc: Stefano Stabellini Cc: Ian Campbell Cc: Wei Liu --- tools/libxl/libxl_arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c index 448ac07..ce0be84 100644 --- a/tools/libxl/lib

Re: [Xen-devel] [PATCH 06/12] xen: mark grant mapped pages as foreign

On Fri, 2015-01-09 at 16:03 +, Stefano Stabellini wrote: > On Tue, 6 Jan 2015, David Vrabel wrote: > > From: Jenny Herbert > > > > Use the "foreign" page flag to mark pages that have a grant map. Use > > page->private to store information of the grant (the granting domain > > and the grant r

Re: [Xen-devel] [PATCH 1/3] spinlock: use local_irq_disable() instead of local_irq_save() where possible

On Fri, Jan 09, 2015 at 04:09:30PM +, Andrew Cooper wrote: > On 09/01/15 16:02, Konrad Rzeszutek Wilk wrote: > > On Thu, Jan 08, 2015 at 04:13:03PM +, Jan Beulich wrote: > >> ... as generally being a cheaper operation. > > I was wondering if it would be possible to change some of the > > EF

Re: [Xen-devel] [PATCH for 2.3 v2 1/1] xen-hvm: increase maxmem before calling xc_domain_populate_physmap

Ping On 12/23/14 09:35, Don Slutz wrote: > Ping. > > On 12/03/14 08:15, Don Slutz wrote: >> From: Stefano Stabellini >> >> Increase maxmem before calling xc_domain_populate_physmap_exact to >> avoid the risk of running out of guest memory. This way we can also >> avoid complex memory calculation

Re: [Xen-devel] [PATCH 06/12] xen: mark grant mapped pages as foreign

On 09/01/15 16:19, Ian Campbell wrote: > On Fri, 2015-01-09 at 16:03 +, Stefano Stabellini wrote: >> On Tue, 6 Jan 2015, David Vrabel wrote: >>> From: Jenny Herbert >>> >>> Use the "foreign" page flag to mark pages that have a grant map. Use >>> page->private to store information of the grant

Re: [Xen-devel] [PATCH 12/12] xen/gntdev: provide a set of pages for each VMA

On 09/01/15 16:05, Stefano Stabellini wrote: > On Fri, 9 Jan 2015, Stefano Stabellini wrote: >> On Tue, 6 Jan 2015, David Vrabel wrote: >>> From: Jenny Herbert >>> >>> For each VMA for grant maps, provide the correct array of pages so >>> get_user_pages() on foreign mappings works in PV guests. >>

Re: [Xen-devel] [PATCH 06/12] xen: mark grant mapped pages as foreign

On Fri, 9 Jan 2015, David Vrabel wrote: > On 09/01/15 16:19, Ian Campbell wrote: > > On Fri, 2015-01-09 at 16:03 +, Stefano Stabellini wrote: > >> On Tue, 6 Jan 2015, David Vrabel wrote: > >>> From: Jenny Herbert > >>> > >>> Use the "foreign" page flag to mark pages that have a grant map. Use

Re: [Xen-devel] [PATCH 06/12] xen: mark grant mapped pages as foreign

On Fri, 2015-01-09 at 16:39 +, David Vrabel wrote: > > ... or stubbed out for arches which don't need this (which might include > > arm*?). > > I'm reasonably certain that this is required for HVM and ARM guests as > well. The grant copy will still fail to get the page by gfn since the > mfn

Re: [Xen-devel] [PATCH] x86/traps: Avoid the #GP slowpath for guest #DB exceptions

On 08/01/15 14:00, Jan Beulich wrote: On 08.01.15 at 14:25, wrote: >> do_debug() is capable of correctly dealing with #DB exceptions in guest >> context, and indeed needs to be as the 'icebp' instruction skips the DPL >> check anyway. > I don't follow: ICEBP doesn't check DPL, right, but what

[Xen-devel] [xen-4.2-testing test] 33282: tolerable FAIL - PUSHED

flight 33282 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33282/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1

Re: [Xen-devel] [libvirt test] 33157: regressions - trouble: blocked/fail/pass/preparing/queued

On Thu, 2015-01-08 at 14:56 -0700, Jim Fehlig wrote: > Jim Fehlig wrote: > > No, not directly. But I will be doing so now. I should try to revert > > all this nonsense and use libxlu before it ends up in the next libvirt > > release. > > > > Hmm, I don't think that is going to be possible sin

Re: [Xen-devel] [PATCH resend] libxl, hotplug/Linux: default to phy backend for raw format file, take 2

On Fri, 2015-01-09 at 14:42 +, Wei Liu wrote: > On Thu, Jan 08, 2015 at 03:33:17PM +0100, Fabio Fantoni wrote: > > Sorry for the probably stupid question, what are the pros and cons of > > default use of phy instead qdisk for raw files as domU disk? > > > > There's no stupid question. :-) >

Re: [Xen-devel] [libvirt test] 33157: regressions - trouble: blocked/fail/pass/preparing/queued

Dario Faggioli wrote: > On Thu, 2015-01-08 at 14:56 -0700, Jim Fehlig wrote: > >> Jim Fehlig wrote: >> >>> No, not directly. But I will be doing so now. I should try to revert >>> all this nonsense and use libxlu before it ends up in the next libvirt >>> release. >>> >>> >> Hmm,

Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week), GA slip + 1 day

On Fri, Jan 09, 2015 at 01:51:56PM +, Lars Kurth wrote: > Note that I published the Acknowledgements and most 4.5 documentation is now > in place. Bits which you may want to check and fix > * Spelling of your name if it contains special characters as the scripts that > I use nuke them - > ht

Re: [Xen-devel] Xen's Linux kernel config options V2

On Tue, Dec 16, 2014 at 05:21:05PM +0100, Juergen Gross wrote: > Hi, > > This is a design proposal for a rework of the config options on the > Linux kernel which are related to Xen. > > The need to do so arose from the fact that it is currently not > possible to build the Xen frontend drivers for

Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

On Fri, Jan 09, 2015 at 08:02:48AM +, Tian, Kevin wrote: > > From: Tim Deegan [mailto:t...@xen.org] > > Sent: Thursday, January 08, 2015 8:43 PM > > > > Hi, > > > > > > Not really. The IOMMU tables are also 64-bit so there must be enough > > > > addresses to map all of RAM. There shouldn't

Re: [Xen-devel] (v2) Design proposal for RMRR fix

On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote: > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote: > On 08.01.15 at 16:59, wrote: > >> On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich wrote: > the 1st invocation of this interface will save all reported reserved > regio

Re: [Xen-devel] [Bugfix] x86/apic: Fix xen IRQ allocation failure caused by commit b81975eade8c

On Thu, Jan 08, 2015 at 02:36:38PM +0800, Jiang Liu wrote: > On 2015/1/7 23:44, Konrad Rzeszutek Wilk wrote: > > On Wed, Jan 07, 2015 at 11:37:52PM +0800, Jiang Liu wrote: > >> On 2015/1/7 22:50, Konrad Rzeszutek Wilk wrote: > >>> On Wed, Jan 07, 2015 at 02:13:49PM +0800, Jiang Liu wrote: > Co

[Xen-devel] [PATCH 00/11] Alternate p2m: support multiple copies of host p2m

This set of patches adds support to hvm domains for EPTP switching by creating multiple copies of the host p2m (currently limited to 10 copies). The primary use of this capability is expected to be in scenarios where access to memory needs to be monitored and/or restricted below the level at which

[Xen-devel] [PATCH 10/11] x86/altp2m: fix log-dirty handling.

Log-dirty, as used to track vram changes, works exclusively on the host p2m. As a result, when running on any other p2m vram changes aren't tracked properly and the domain's console display is corrupted. To fix this, log-dirty pages are never valid in the alternate p2m's, and if the type of any pa

[Xen-devel] [PATCH 11/11] x86/altp2m: alternate p2m memory events.

Add a flag to indicate that a memory event occurred in an alternate p2m and a field containing the p2m index. Allow the response to switch to a different p2m using the same flag and field. Modify p2m_access_check() to handle alternate p2m's. Access_required is always assumed for an alternate p2m.

[Xen-devel] [PATCH 09/11] x86/altp2m: define and implement alternate p2m HVMOP types.

Signed-off-by: Ed White --- xen/arch/x86/hvm/hvm.c | 217 xen/include/public/hvm/hvm_op.h | 68 + 2 files changed, 285 insertions(+) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index e6f64a3..afe16bf 100644 --- a/xen

[Xen-devel] [PATCH 01/11] VMX: VMFUNC and #VE definitions and detection.

Currently, neither is enabled globally but may be enabled on a per-VCPU basis by the altp2m code. Everything can be force-disabled globally by specifying vmfunc=0 on the Xen command line. Remove the check for EPTE bit 63 == zero in ept_split_super_page(), as that bit is now hardware-defined. Sig

[Xen-devel] [PATCH 06/11] VMX/altp2m: add code to support EPTP switching and #VE.

Implement and hook up the code to enable VMX support of VMFUNC and #VE. VMFUNC leaf 0 (EPTP switching) and #VE are emulated on hardware that doesn't support them. Signed-off-by: Ed White --- xen/arch/x86/hvm/vmx/vmx.c | 138 + 1 file changed, 138 inse

[Xen-devel] [PATCH 05/11] x86/altp2m: basic data structures and support routines.

Add the basic data structures needed to support alternate p2m's and the functions to initialise them and tear them down. Although Intel hardware can handle 512 EPTP's per hardware thread concurrently, only 10 per domain are supported in this patch for performance reasons. The iterator in hap_enab

[Xen-devel] [PATCH 03/11] x86/HVM: Hardware alternate p2m support detection.

As implemented here, only supported on platforms with VMX HAP. Signed-off-by: Ed White --- xen/arch/x86/hvm/hvm.c| 8 xen/arch/x86/hvm/vmx/vmx.c| 1 + xen/include/asm-x86/hvm/hvm.h | 6 ++ 3 files changed, 15 insertions(+) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/

  1   2   >