[Xen-devel] [PATCH 2/3] blkif: enable multi-page ring supporting

Remove the 'DEPRECATED' and next patch will follow the protocol defined here to support multi-page ring. Signed-off-by: Bob Liu --- xen/include/public/io/blkif.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h i

[Xen-devel] [PATCH v3 3/3] xen/block: add multi-page ring support

Extend xen/block to support multi-page ring, so that more requests can be issued by using more than one pages as the request ring between blkfront and backend. As a result, the performance can get improved significantly. We got some impressive improvements on our highend iscsi storage cluster bac

[Xen-devel] [PATCH v6 1/3] xenbus_client: Extend interface to support multi-page ring

From: Wei Liu Originally Xen PV drivers only use single-page ring to pass along information. This might limit the throughput between frontend and backend. The patch extends Xenbus driver to support multi-page ring, which in general should improve throughput if ring is the bottleneck. Changes to

[Xen-devel] [PATCH v2 2/2] xen/grant: introduce func gnttab_unmap_refs_sync()

There are several place using gnttab async unmap and wait for completion, so move the common code to a function gnttab_unmap_refs_sync(). v2: Rename to gnttab_unmap_refs_sync() Signed-off-by: Bob Liu --- drivers/block/xen-blkback/blkback.c | 31 +++ drivers/xen/gnt

[Xen-devel] [PATCH 1/2] xen/blkback: safely unmap purge persistent grants

Commit c43cf3ea8385 ("xen-blkback: safely unmap grants in case they are still in use") use gnttab_unmap_refs_async() to wait until the mapped pages are no longer in use before unmapping them, but that commit missed the persistent case. Purge persistent pages can't be unmapped either unless no longe

Re: [Xen-devel] implementing a classic Xen front/back pv driver pair to provide a transport for 9P FS Protocol

Here is the log file inline: /bin/sh: 1: ./checker: Permission denied make[4]: *** [check-headers] Error 126 make[3]: *** [xen-foreign] Error 2 make[2]: *** [subdir-install-include] Error 2 make[1]: *** [subdirs-install] Error 2 make: *** [install-tools] Error 2 if anybody has any insights into t

[Xen-devel] [linux-3.16 test] 50289: regressions - FAIL

flight 50289 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/50289/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167 Regressions which are

Re: [Xen-devel] [PATCH 8/9] qspinlock: Generic paravirt support

On 04/02/2015 03:48 PM, Peter Zijlstra wrote: On Thu, Apr 02, 2015 at 07:20:57PM +0200, Peter Zijlstra wrote: pv_wait_head(): pv_hash() /* MB as per cmpxchg */ cmpxchg(&l->locked, _Q_LOCKED_VAL, _Q_SLOW_VAL); VS __pv_queue_spin_unlock(): if (xchg(&l->locked, 0

Re: [Xen-devel] [RFC v1 12/15] vmx: Properly handle notification event when vCPU is running

> -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: Friday, April 03, 2015 3:15 AM > To: Tian, Kevin > Cc: Wu, Feng; Zhang, Yang Z; xen-devel@lists.xen.org; k...@xen.org; > jbeul...@suse.com > Subject: Re: [Xen-devel] [RFC v1 12/15] vmx: Properly han

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Thu, Apr 02, 2015 at 05:52:16PM -0600, Toshi Kani wrote: > On Thu, 2015-04-02 at 23:49 +0200, Luis R. Rodriguez wrote: > > On Sat, Mar 28, 2015 at 12:56:30AM +0100, Luis R. Rodriguez wrote: > > > On Fri, Mar 27, 2015 at 02:40:17PM -0600, Toshi Kani wrote: > > > > On Fri, 2015-03-20 at 16:17 -070

[Xen-devel] [xen-4.2-testing test] 50288: regressions - FAIL

flight 50288 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50288/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-start.2 fail REGR. vs. 36512 Tests which did

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Thu, 2015-04-02 at 23:49 +0200, Luis R. Rodriguez wrote: > On Sat, Mar 28, 2015 at 12:56:30AM +0100, Luis R. Rodriguez wrote: > > On Fri, Mar 27, 2015 at 02:40:17PM -0600, Toshi Kani wrote: > > > On Fri, 2015-03-20 at 16:17 -0700, Luis R. Rodriguez wrote: > > > : > > > > @@ -734,6 +742,7 @@ voi

Re: [Xen-devel] [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()

On Thu, Apr 2, 2015 at 3:35 PM, Bjorn Helgaas wrote: > [-cc Venkatesh, Suresh] > > On Thu, Apr 2, 2015 at 3:55 PM, Luis R. Rodriguez wrote: >> On Thu, Apr 02, 2015 at 03:21:22PM -0500, Bjorn Helgaas wrote: >>> On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez >>> wrote: >>> > From: "Luis R. Rod

Re: [Xen-devel] [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()

[-cc Venkatesh, Suresh] On Thu, Apr 2, 2015 at 3:55 PM, Luis R. Rodriguez wrote: > On Thu, Apr 02, 2015 at 03:21:22PM -0500, Bjorn Helgaas wrote: >> On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez >> wrote: >> > From: "Luis R. Rodriguez" >> > This is *only* a transitive API -- and as such n

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Thu, Apr 2, 2015 at 3:09 PM, Bjorn Helgaas wrote: > On Thu, Apr 2, 2015 at 4:02 PM, Luis R. Rodriguez wrote: > >> --- >> It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT >> and end up with a system with MTRR functionality disabled >> PAT functionality enabled. > > This is missing a conj

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Thu, Apr 2, 2015 at 4:02 PM, Luis R. Rodriguez wrote: > --- > It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT > and end up with a system with MTRR functionality disabled > PAT functionality enabled. This is missing a conjunction or something in "MTRR functionality disabled PAT functio

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Sat, Mar 28, 2015 at 12:56:30AM +0100, Luis R. Rodriguez wrote: > On Fri, Mar 27, 2015 at 02:40:17PM -0600, Toshi Kani wrote: > > On Fri, 2015-03-20 at 16:17 -0700, Luis R. Rodriguez wrote: > > : > > > @@ -734,6 +742,7 @@ void __init mtrr_bp_init(void) > > > } > > > > > > if (mtrr_if) { >

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

flight 50287 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50287/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 13 guest-localmigrate.2fail REGR. vs. 50268 test-amd64-i386-f

Re: [Xen-devel] implementing a classic Xen front/back pv driver pair to provide a transport for 9P FS Protocol

Konrad - Here's the log. Maybe someone can make sense of this. Thanks. Linda log Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Thu, Apr 02, 2015 at 03:28:51PM -0500, Bjorn Helgaas wrote: > On Thu, Apr 2, 2015 at 3:20 PM, Luis R. Rodriguez wrote: > > On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas wrote: > >> > >> On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote: > >> > >> > I'll rephrase this to: > >> > > >> >

Re: [Xen-devel] [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()

On Thu, Apr 02, 2015 at 03:21:22PM -0500, Bjorn Helgaas wrote: > On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez > wrote: > > From: "Luis R. Rodriguez" > > > > Ideally on systems using PAT we can expect a swift > > transition away from MTRR. There can be a few exceptions > > to this, one is wh

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Thu, Apr 2, 2015 at 3:20 PM, Luis R. Rodriguez wrote: > On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas wrote: >> >> On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote: >> >> > I'll rephrase this to: >> > >> > --- >> > It is possible to enable CONFIG_MTRR and up with it >> > disabled at r

Re: [Xen-devel] [PATCH v1 06/47] mtrr: add __arch_phys_wc_add()

On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Ideally on systems using PAT we can expect a swift > transition away from MTRR. There can be a few exceptions > to this, one is where device drivers are known to exist > on PATs with errata, This probably m

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas wrote: > > On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote: > > > I'll rephrase this to: > > > > --- > > It is possible to enable CONFIG_MTRR and up with it > > disabled at run time and yet CONFIG_X86_PAT continues > > to kick through with al

Re: [Xen-devel] [PATCH v2] xen-netfront: transmit fully GSO-sized packets

From: Jonathan Davies Date: Tue, 31 Mar 2015 11:05:15 +0100 > xen-netfront limits transmitted skbs to be at most 44 segments in size. > However, > GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448 > bytes each. This slight reduction in the size of packets means a slight

Re: [Xen-devel] [PATCH v1 02/47] x86: mtrr: generalize run time disabling of MTRR

On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez wrote: > I'll rephrase this to: > > --- > It is possible to enable CONFIG_MTRR and up with it > disabled at run time and yet CONFIG_X86_PAT continues > to kick through with all functionally enabled. This > can happen for instance on Xen where MTR

Re: [Xen-devel] [PATCH v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO "hole" work around

On Thu, Apr 2, 2015 at 12:45 PM, Luis R. Rodriguez wrote: > On Wed, Apr 01, 2015 at 05:04:08PM -0700, Andy Lutomirski wrote: >> On Wed, Apr 1, 2015 at 4:52 PM, Luis R. Rodriguez wrote: >> > On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote: >> >> On Sat, Mar 28, 2015 at 01:28:18AM +01

Re: [Xen-devel] [PATCH 8/9] qspinlock: Generic paravirt support

On Thu, Apr 02, 2015 at 07:20:57PM +0200, Peter Zijlstra wrote: > pv_wait_head(): > > pv_hash() > /* MB as per cmpxchg */ > cmpxchg(&l->locked, _Q_LOCKED_VAL, _Q_SLOW_VAL); > > VS > > __pv_queue_spin_unlock(): > > if (xchg(&l->locked, 0) != _Q_SLOW_VAL) > r

Re: [Xen-devel] [PATCH RFC v2 3/3] xen: rework paging_log_dirty_op to work with hvm guests

On 02/04/15 11:26, Roger Pau Monne wrote: > When the caller of paging_log_dirty_op is a hvm guest Xen would choke when > trying to copy the dirty bitmap to the guest because the paging lock is > already held. Are you sure? Presumably you get an mm lock ordering violation, because paging_log_dirty_

Re: [Xen-devel] [PATCH v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO "hole" work around

On Wed, Apr 01, 2015 at 05:04:08PM -0700, Andy Lutomirski wrote: > On Wed, Apr 1, 2015 at 4:52 PM, Luis R. Rodriguez wrote: > > On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote: > >> On Sat, Mar 28, 2015 at 01:28:18AM +0100, Luis R. Rodriguez wrote: > >> > On Fri, Mar 27, 2015 at 03:0

Re: [Xen-devel] implementing a classic Xen front/back pv driver pair to provide a transport for 9P FS Protocol

On Thu, Apr 02, 2015 at 01:16:36PM -0600, Linda wrote: > Thanks Konrad. > > I came close to doing your suggestions on git, and got it, sort of, to work. > I will follow your instructions exactly for updates. Heh. The git manual is also a very good resource. > > There were also, some problems wit

Re: [Xen-devel] [PATCH] tools/libxl new bitmap functions

On Thu, Apr 02, 2015 at 11:38:16AM -0600, Linda Jacobson wrote: > From: Linda > > Added bitmap functions for union intersection and difference betweenn two > bitmaps > > Signed-off-by: Linda > --- > tools/libxl/libxl_utils.c | 115 > ++ > tools/lib

Re: [Xen-devel] Outstanding fixes for Linux 4.1?

On Thu, Apr 02, 2015 at 05:21:50PM +0100, David Vrabel wrote: > All, > > Are there any outstanding patches that should be added to Linux 4.1 > (the merge window for which will be opening shortly)? Bob's two patches to the deferred grant mechanism. Also the XSA-120 addendum. Will send that out on

Re: [Xen-devel] implementing a classic Xen front/back pv driver pair to provide a transport for 9P FS Protocol

Thanks Konrad. I came close to doing your suggestions on git, and got it, sort of, to work. I will follow your instructions exactly for updates. There were also, some problems with the way the smtp server needed to be set up (compounded by typos of course), which are all fixed. As far as y

Re: [Xen-devel] [RFC v1 12/15] vmx: Properly handle notification event when vCPU is running

On Thu, Apr 02, 2015 at 06:08:12AM +, Tian, Kevin wrote: > > From: Wu, Feng > > Sent: Friday, March 27, 2015 12:58 PM > > > > > > > > > -Original Message- > > > From: Zhang, Yang Z > > > Sent: Friday, March 27, 2015 12:44 PM > > > To: Wu, Feng; xen-devel@lists.xen.org > > > Cc: jbeul

Re: [Xen-devel] [PATCH RFC v2 2/3] xen/shadow: fix shadow_track_dirty_vram to work on hvm guests

On 02/04/15 11:26, Roger Pau Monne wrote: > Modify shadow_track_dirty_vram to use a local buffer and then flush to the > guest without the paging_lock held. This is modeled after > hap_track_dirty_vram. > > Signed-off-by: Roger Pau Monné > Cc: Tim Deegan > Cc: Jan Beulich > Cc: Andrew Cooper R

Re: [Xen-devel] sudden hang on boot on AMD Notebook

On Thu, Apr 02, 2015 at 08:15:59AM +0200, Olaf Hering wrote: > On Wed, Apr 01, Konrad Rzeszutek Wilk wrote: > > > You can also use the USB EHCI debug port. It works great on laptops. > > Is there an howto for that? xen_commandline: console=vga,dbgp dbgp=ehci1 loglvl=all iommu=verbose,de

Re: [Xen-devel] implementing a classic Xen front/back pv driver pair to provide a transport for 9P FS Protocol

On Wed, Apr 01, 2015 at 07:36:49PM -0600, Linda wrote: > First, Julien, your suggestion worked like a charm. > So here's what's happened tonight. I tried to build the tools directory of > my git repository. Although I used the sudo command in my virtual ubuntu, I > got a permission denied error

[Xen-devel] [PATCH v8 14/15] docs: libxc migration stream specification

Add the specification for a new migration stream format. The document includes all the details but to summarize: The existing (legacy) format is dependant on the word size of the toolstack. This prevents domains from migrating from hosts running 32-bit toolstacks to hosts running 64-bit toolstac

[Xen-devel] [PATCH v8 13/15] tools/libxc: noarch restore code

Restore a domain from the new format. This reads and validates the domain and image header and loads the guest memory from the PAGE_DATA records, populating the p2m as it does so. This provides the xc_domain_restore2() function as an alternative to the existing xc_domain_restore(). Signed-off-by

[Xen-devel] [PATCH v8 15/15] tools/libxc: Migration v2 compatibility for unmodified libxl

These changes cause migration v2 to behave similarly enough to legacy migration to function for HVM guests under an unmodified xl/libxl. The migration v2 work for libxl will fix the layering issues with the toolstack and qemu records, at which point this patch will be unneeded. It is however incl

[Xen-devel] [PATCH v8 11/15] tools/libxc: x86 HVM restore code

Restore the x86 HVM specific parts of a domain. This is the HVM_CONTEXT and HVM_PARAMS records. There is no need for any page localisation. This also includes writing the trailing qemu save record to a file because this is what libxc currently does. This is intended to be moved into libxl prope

[Xen-devel] [PATCH v8 12/15] tools/libxc: noarch save code

Save a domain, calling domain type specific function at the appropriate points. This implements the xc_domain_save2() API function which is equivalent to the existing xc_domain_save(). This writes the image and domain headers, and writes all the PAGE_DATA records using a "live" process. Signed-o

[Xen-devel] [PATCH v8 10/15] tools/libxc: x86 HVM save code

Save the x86 HVM specific parts of the domain. This is considerably simpler than an x86 PV domain. Only the HVM_CONTEXT and HVM_PARAMS records are needed. There is no need for any page normalisation. Signed-off-by: Andrew Cooper CC: Ian Campbell CC: Ian Jackson CC: Wei Liu --- tools/libxc/

Re: [Xen-devel] Testing Xen 4.5 and PCI/VGA Passthrough - my regression was fixed

On 02/04/15 18:26, Zir Blazer wrote: > This E-Mail is a followup of the previous one about the regression I had in > Xen 4.4 compared to 4.3, here: > http://www.gossamer-threads.com/lists/xen/devel/351336 > http://lists.xen.org/archives/html/xen-devel/2014-10/msg01341.html (This one > is missing

[Xen-devel] [PATCH v8 07/15] tools/libxc: x86 PV common code

Add functions common to save and restore of x86 PV guests. This includes functions for dealing with the P2M and M2P and the VCPU context. Signed-off-by: Andrew Cooper CC: Ian Campbell CC: Ian Jackson CC: Wei Liu --- tools/libxc/Makefile |1 + tools/libxc/xc_sr_common_x86_pv.

[Xen-devel] [PATCH v8 01/15] tools/libxc: Implement writev_exact() in the same style as write_exact()

This implementation of writev_exact() will cope with an iovcnt greater than IOV_MAX because glibc will actually let this work anyway, and it is very useful not to have to work about this in the caller of writev_exact(). The caller is still required to ensure that the sum of iov_len's doesn't overf

[Xen-devel] [PATCH v8 09/15] tools/libxc: x86 PV restore code

Restore the x86 PV specific parts. The X86_PV_INFO, the P2M_FRAMES, SHARED_INFO, and VCPU context records. The localise_page callback is called from the common PAGE_DATA code to convert PFNs in page tables to MFNs. Page tables are pinned and the guest's P2M is updated when the stream is complete

[Xen-devel] [PATCH v8 08/15] tools/libxc: x86 PV save code

Save the x86 PV specific parts of a domain. This is the X86_PV_INFO record, the P2M_FRAMES, the X86_PV_SHARED_INFO, the three different VCPU context records, and the MSR records. The normalise_page callback used by the common code when writing the PAGE_DATA records, converts MFNs in page tables t

[Xen-devel] [PATCH v8 02/15] libxc/progress: Extend the progress interface

Not everything which needs reporting as progress comes with a range. Extend the interface to allow reporting of a single statement. The programming interface now looks like: xc_set_progress_prefix() set the prefix string to be used xc_report_progress_single() report a single action

[Xen-devel] [PATCH v8 04/15] tools/libxc: C implementation of stream format

Provide the C structures matching the binary (wire) format of the new stream format. All header/record fields are naturally aligned and explicit padding fields are used to ensure the correct layout (i.e., there is no need for any non-standard structure packing pragma or attribute). Provide some h

[Xen-devel] [PATCH v8 06/15] tools/libxc: x86 common code

Save/restore records common to all x86 domain types (HVM, PV). This is only the TSC_INFO record. Signed-off-by: Andrew Cooper Acked-by: Ian Campbell CC: Ian Jackson CC: Wei Liu --- tools/libxc/Makefile |1 + tools/libxc/xc_sr_common_x86.c | 54

[Xen-devel] [PATCH v8 00/15] Migration v2 (libxc)

Presented here is v8 of the Migration v2 series (libxc subset), which is able to function when transparently inserted under an unmodified xl/libxl. There are numerous tweaks in v8 (fix build with MiniOS, tweak some code to appease Coverity, style fixes, clarification of some error messages) but no

[Xen-devel] [PATCH v8 05/15] tools/libxc: noarch common code

Add the context structure used to keep state during the save/restore process. Define the set of architecture or domain type specific operations with a set of callbacks (save_ops, and restore_ops). Add common functions for writing records. Signed-off-by: Andrew Cooper CC: Ian Campbell CC: Ian J

[Xen-devel] [PATCH v8 03/15] tools/libxc: Migration v2 framework

For testing purposes, the environmental variable "XG_MIGRATION_V2" allows the two save/restore codepaths to coexist, and have a runtime switch. Signed-off-by: Andrew Cooper CC: Ian Campbell CC: Ian Jackson CC: Wei Liu --- v8: Adjust layout to compile with MiniOS --- tools/libxc/Makefile

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

flight 50285 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50285/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate/x10 fail REGR. vs. 50266 Regressions

Re: [Xen-devel] ENC:[Xen-users] Failed to insert 'xen_evtchn': No such device

> Which instructions were you following which didn't mention them, so we > can update them? I was installing starting from the Quick-start Guide from the README file. I thought that was the installation page and any specific case should be searched in other files... Sorry for the misunderstanding

Re: [Xen-devel] ENC:[Xen-users] Failed to insert 'xen_evtchn': No such device

On Thu, 2015-04-02 at 14:42 -0300, Carlos Gustavo Ramirez Rodriguez wrote: > >make install will not enable sysv or systemd services. Distro > packages > >are supposed to enable themselve. If that is not desired by distro > >maintainers the distro should provide ways to easily enable services. > >Ub

Re: [Xen-devel] ENC:[Xen-users] Failed to insert 'xen_evtchn': No such device

>make install will not enable sysv or systemd services. Distro packages >are supposed to enable themselve. If that is not desired by distro >maintainers the distro should provide ways to easily enable services. >Ubuntu probably has code to enable the sysv "xencommons" script. Perhaps >Ubuntu is not

[Xen-devel] [PATCH] tools/libxl new bitmap functions

From: Linda Added bitmap functions for union intersection and difference betweenn two bitmaps Signed-off-by: Linda --- tools/libxl/libxl_utils.c | 115 ++ tools/libxl/libxl_utils.h | 10 2 files changed, 125 insertions(+) diff --git a/tools/l

[Xen-devel] Testing Xen 4.5 and PCI/VGA Passthrough - my regression was fixed

This E-Mail is a followup of the previous one about the regression I had in Xen 4.4 compared to 4.3, here: http://www.gossamer-threads.com/lists/xen/devel/351336 http://lists.xen.org/archives/html/xen-devel/2014-10/msg01341.html (This one is missing from the previous link, here I discovered a wor

Re: [Xen-devel] [PATCH 8/9] qspinlock: Generic paravirt support

On Thu, Apr 02, 2015 at 12:28:30PM -0400, Waiman Long wrote: > On 04/01/2015 05:03 PM, Peter Zijlstra wrote: > >On Wed, Apr 01, 2015 at 03:58:58PM -0400, Waiman Long wrote: > >>On 04/01/2015 02:48 PM, Peter Zijlstra wrote: > >>I am sorry that I don't quite get what you mean here. My point is that i

Re: [Xen-devel] ENC:[Xen-users] Failed to insert 'xen_evtchn': No such device

On Thu, Apr 02, Carlos Gustavo Ramirez Rodriguez wrote: > >systemctl enable xen-qemu-dom0-disk-backend.service > >systemctl enable xen-init-dom0.service > >systemctl enable xenconsoled.service > These MAGIC lines did the trick! Thanks for the help, this solved the First > Problem, BUT, if you know

Re: [Xen-devel] failed to boot FreeBSD 11-CURRENT as Xen PVH Dom0

On 02/04/15 17:39, Roger Pau Monné wrote: > Hello, (Inserted PVH into subject. Please note that PVH is still experimental in Xen.) > > El 02/04/15 a les 18.23, Gavin Mu ha escrit: >> Today I tried Xen Dom0 on one SuperMicro X9SRW-F machine, but it failed to >> bootup. Is there anybody can help?

Re: [Xen-devel] [PATCH v2 1/4] x86/MSI-X: be more careful during teardown

On Wed, 25 Mar 2015, Jan Beulich wrote: > When a device gets detached from a guest, pciback will clear its > command register, thus disabling both memory and I/O decoding. The > disabled memory decoding, however, has an effect on the MSI-X table > accesses the hypervisor does: These won't have the

Re: [Xen-devel] failed to boot FreeBSD 11-CURRENT as Xen Dom0

Hello, El 02/04/15 a les 18.23, Gavin Mu ha escrit: > Today I tried Xen Dom0 on one SuperMicro X9SRW-F machine, but it failed to > bootup. Is there anybody can help? thanks. > > (XEN) Xen version 4.6-unstable (root@) (gcc47 (FreeBSD Ports Collection) > 4.7.4) debug=y Fri Apr 3 00:04:50 CST 201

[Xen-devel] Outstanding fixes for Linux 4.1?

All, Are there any outstanding patches that should be added to Linux 4.1 (the merge window for which will be opening shortly)? So far I have queued: Dan Carpenter (1): xen/mce: fix up xen_late_init_mcelog() error handling David Vrabel (2): xen: unify foreign GFN map/unmap for auto-x

Re: [Xen-devel] [PATCH 3/3] libxl: datacopier: Avoid theoretical eof/POLLHUP race

Ian Jackson writes ("[PATCH 3/3] libxl: datacopier: Avoid theoretical eof/POLLHUP race"): > We solve the race with a poll of the reading fd, to double-check, when > we detect eof via read. (This is only necessary if the caller has > specified callback_pollhup, as otherwise POLLHUP|POLLIN - and, >

Re: [Xen-devel] [PATCH 8/9] qspinlock: Generic paravirt support

On 04/01/2015 05:03 PM, Peter Zijlstra wrote: On Wed, Apr 01, 2015 at 03:58:58PM -0400, Waiman Long wrote: On 04/01/2015 02:48 PM, Peter Zijlstra wrote: I am sorry that I don't quite get what you mean here. My point is that in the hashing step, a cpu will need to scan an empty bucket to put the

Re: [Xen-devel] [PATCH 04/19] xen: arm: provide and use a handle_raz_wi helper

On Thu, 2015-04-02 at 17:01 +0100, Ian Campbell wrote: > On Thu, 2015-04-02 at 16:50 +0100, Ian Campbell wrote: > > > Writing to the bottom half (e.g. w0) of a register implicitly clears the > > top half, IIRC, so I think a kernel is unlikely to want to do this, even > > if it could (which I'm not

[Xen-devel] [GIT PULL] xen: regression fixes for 4.0-rc6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-linus-4.0-rc6-tag xen: regression fixes for 4.0-rc6 - - Fix two regressions in the balloon driver's use of memory hotplug when used i

Re: [Xen-devel] [PATCH 04/19] xen: arm: provide and use a handle_raz_wi helper

On Thu, 2015-04-02 at 16:50 +0100, Ian Campbell wrote: > Writing to the bottom half (e.g. w0) of a register implicitly clears the > top half, IIRC, so I think a kernel is unlikely to want to do this, even > if it could (which I'm not quite convinced of). That said, I'll see if I can make somethin

Re: [Xen-devel] [libvirt] [PATCH V3] libxl: fix dom0 balloon logic

Martin Kletzander wrote: > On Wed, Apr 01, 2015 at 11:08:54AM -0600, Jim Fehlig wrote: >> Recent testing on large memory systems revealed a bug in the Xen xl >> tool's freemem() function. When autoballooning is enabled, freemem() >> is used to ensure enough memory is available to start a domain, >

Re: [Xen-devel] [PATCH] xentop: fix potential memory leak

On Thu, 2015-04-02 at 09:42 -0600, Charles Arnold wrote: > On a read failure the qstats buffer is not freed. > > Signed-off-by: Charles Arnold Acked + applied, thanks for the quick response! ___ Xen-devel mailing list Xen-devel@lists.xen.org http:/

Re: [Xen-devel] [PATCH 04/19] xen: arm: provide and use a handle_raz_wi helper

On Thu, 2015-04-02 at 16:45 +0100, Julien Grall wrote: > > On 02/04/2015 16:31, Ian Campbell wrote: > > On Thu, 2015-04-02 at 16:14 +0100, Julien Grall wrote: > >> Hi Ian, > >> > >> On 31/03/2015 11:07, Ian Campbell wrote: > >>> Reduces the use of goto in the trap handlers to none. > >>> > >>> Som

Re: [Xen-devel] [PATCH 04/19] xen: arm: provide and use a handle_raz_wi helper

On 02/04/2015 16:31, Ian Campbell wrote: On Thu, 2015-04-02 at 16:14 +0100, Julien Grall wrote: Hi Ian, On 31/03/2015 11:07, Ian Campbell wrote: Reduces the use of goto in the trap handlers to none. Some explcitily 32-bit types become register_t here, but that's OK, on s/explcitily/explic

Re: [Xen-devel] New Defects reported by Coverity Scan for XenProject

>>> On 4/2/2015 at 08:32 AM, Ian Campbell wrote: > Hi Charles, > > I'm not sure if this is a real issue in the qdisk support for xenstat, > but I think it may relate to the first return 0 in qmp_read which may > not free the accumulated array. Yes. That is a leak on the failure case. > > Coul

[Xen-devel] [PATCH] xentop: fix potential memory leak

On a read failure the qstats buffer is not freed. Signed-off-by: Charles Arnold diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c b/tools/xenstat/libxenstat/src/xenstat_qmp.c index c217b8e..2cb99e9 100644 --- a/tools/xenstat/libxenstat/src/xenstat_qmp.c +++ b/tools/xenstat/libxenstat/src/

Re: [Xen-devel] Size of irq field

(CC Stefano and Ian) On 02/04/2015 16:05, Iurii Konovalenko wrote: Hi, Julien! Hello Iurii, During bringing up Xen on Renesas Lager board we faced with problem. A lot of Xen sources relies on statement, that IRQ number is less then 256 and variables, parameters, fields etc. are of type uint

Re: [Xen-devel] [PATCH OSSTEST 5/5] cambridge: Stop publishing logs to chiark

On Thu, 2015-04-02 at 12:25 +0100, Ian Campbell wrote: > Shall I run an adhoc flight with this change in it? FYI, I think I've now figured out how to run something approximating a "proper" osstest flight from something other than ~osstest/testing.git via the cronjob, so one is in progress now...

Re: [Xen-devel] [PATCH 04/19] xen: arm: provide and use a handle_raz_wi helper

On Thu, 2015-04-02 at 16:14 +0100, Julien Grall wrote: > Hi Ian, > > On 31/03/2015 11:07, Ian Campbell wrote: > > Reduces the use of goto in the trap handlers to none. > > > > Some explcitily 32-bit types become register_t here, but that's OK, on > > s/explcitily/explicitly/ > > > 32-bit they ar

Re: [Xen-devel] [PATCH 1/3] Revert "tools/libxl: Adjust datacopiers POLLHUP handling when the fd is also readable"

Ian Campbell writes ("Re: [PATCH 1/3] Revert "tools/libxl: Adjust datacopiers POLLHUP handling when the fd is also readable""): > On Thu, 2015-04-02 at 16:04 +0100, Ian Jackson wrote: > > The bootloader code is relying on detecting POLLHUP, and 7e9ec50b > > breaks that. 7e9ec50b, when handling a

Re: [Xen-devel] [PATCH 1/3] Revert "tools/libxl: Adjust datacopiers POLLHUP handling when the fd is also readable"

Ian Jackson writes ("[PATCH 1/3] Revert "tools/libxl: Adjust datacopiers POLLHUP handling when the fd is also readable""): > The bootloader code is relying on detecting POLLHUP, and 7e9ec50b > breaks that. 7e9ec50b, when handling a pty master, violates the > specification of the datacopier interf

Re: [Xen-devel] [PATCH 2/3] libxl: Cope with pipes which signal POLLHUP|POLLIN on read eof

On Thu, 2015-04-02 at 16:04 +0100, Ian Jackson wrote: > Some operating systems (including FreeBSD[1]) signal not just POLLIN > when a reading pipe reaches EOF, but also POLLHUP. This is > permitted[2]. But datacopiers mishandle this, because they always > treat POLLHUP exceptionally (either repor

Re: [Xen-devel] [PATCH 1/3] Revert "tools/libxl: Adjust datacopiers POLLHUP handling when the fd is also readable"

On 02/04/15 16:04, Ian Jackson wrote: > The bootloader code is relying on detecting POLLHUP, and 7e9ec50b > breaks that. 7e9ec50b, when handling a pty master, violates the > specification of the datacopier interface (as defined). > > When the bootloader exits, several things change, all at once: >

Re: [Xen-devel] Size of irq field

On Thu, 2015-04-02 at 18:05 +0300, Iurii Konovalenko wrote: > Hi, Julien! > > During bringing up Xen on Renesas Lager board we faced with problem. > A lot of Xen sources relies on statement, that IRQ number is less then > 256 and variables, parameters, fields etc. are of type uint8_t. Please can

Re: [Xen-devel] [PATCH 02/19] xen: arm: add missing break

Hi Ian, On 31/03/2015 11:07, Ian Campbell wrote: Signed-off-by: Ian Campbell xen: arm: Fix handling of ICC_{SGI1R,SGI0R,ASGI1R}_EL1 Having injected an undefined instruction we don't want to also advance pc. So return. THe ICC_{SGI0R,ASGI1R}_EL1 case was previously missing a break, so would h

Re: [Xen-devel] [PATCH 0/3] datacopier POLLHUP fixes handling when the fd is also readable

Ian Jackson writes ("[PATCH 0/3] datacopier POLLHUP fixes handling when the fd is also readable"): > I think this small series will fix the problem. The commit messages > have more detailed explanations. Now here: http://xenbits.xen.org/gitweb/?p=people/iwj/xen.git;a=shortlog;h=refs/heads/wip

Re: [Xen-devel] [PATCH 03/19] xen: arm: call inject_undef_exception directly

Hi Ian, On 31/03/2015 11:07, Ian Campbell wrote: Reducing the amount of goto maze considerably. Signed-off-by: Ian Campbell Reviewed-by: Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.or

Re: [Xen-devel] [PATCH 3/3] libxl: datacopier: Avoid theoretical eof/POLLHUP race

On Thu, 2015-04-02 at 16:04 +0100, Ian Jackson wrote: > When the bootloader exits, several things change, all at once: > (a) The master pty fd (held by libxl) starts to signal POLLHUP > and maybe also POLLIN. > (b) The child exits (so that the SIGCHLD self-pipe signals POLLIN, > which wil

Re: [Xen-devel] [PATCH 01/19] xen: arm: constify union hsr and struct hsr_* where possible.

On 02/04/2015 11:44, Julien Grall wrote: Hi Ian, On 31/03/2015 11:07, Ian Campbell wrote: Signed-off-by: Ian Campbell Reviewed-by: Julien Grall Hmmm... Sorry I'm not use to use my citrix mail anymore. It should be Reviewed-by: Julien Grall -- Julien Grall

Re: [Xen-devel] [PATCH 04/19] xen: arm: provide and use a handle_raz_wi helper

Hi Ian, On 31/03/2015 11:07, Ian Campbell wrote: Reduces the use of goto in the trap handlers to none. Some explcitily 32-bit types become register_t here, but that's OK, on s/explcitily/explicitly/ 32-bit they are 32-bit already and on 64-bit it is fine/harmless to set the larger register,

[Xen-devel] Size of irq field

Hi, Julien! During bringing up Xen on Renesas Lager board we faced with problem. A lot of Xen sources relies on statement, that IRQ number is less then 256 and variables, parameters, fields etc. are of type uint8_t. But we can have IRQs, that are greater then 255, for example on RCar H2 SoC. Also,

Re: [Xen-devel] [PATCH 1/3] Revert "tools/libxl: Adjust datacopiers POLLHUP handling when the fd is also readable"

On Thu, 2015-04-02 at 16:04 +0100, Ian Jackson wrote: > The bootloader code is relying on detecting POLLHUP, and 7e9ec50b > breaks that. 7e9ec50b, when handling a pty master, violates the > specification of the datacopier interface (as defined). > > When the bootloader exits, several things chang

[Xen-devel] [PATCH 3/3] libxl: datacopier: Avoid theoretical eof/POLLHUP race

When the bootloader exits, several things change, all at once: (a) The master pty fd (held by libxl) starts to signal POLLHUP and maybe also POLLIN. (b) The child exits (so that the SIGCHLD self-pipe signals POLLIN, which will be handled by the libxl child process code. (c) reads on the

[Xen-devel] [PATCH 1/3] Revert "tools/libxl: Adjust datacopiers POLLHUP handling when the fd is also readable"

The bootloader code is relying on detecting POLLHUP, and 7e9ec50b breaks that. 7e9ec50b, when handling a pty master, violates the specification of the datacopier interface (as defined). When the bootloader exits, several things change, all at once: (a) The master pty fd (held by libxl) starts to

[Xen-devel] [PATCH 2/3] libxl: Cope with pipes which signal POLLHUP|POLLIN on read eof

Some operating systems (including FreeBSD[1]) signal not just POLLIN when a reading pipe reaches EOF, but also POLLHUP. This is permitted[2]. But datacopiers mishandle this, because they always treat POLLHUP exceptionally (either reporting it via callback_pollhup, or treating it as an error). da

Re: [Xen-devel] ENC:[Xen-users] Failed to insert 'xen_evtchn': No such device

Hello, First Problem: >Which systemd services files from xen are enabled? See the systemd part >of the INSTALL file: >http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=INSTALL;hb=staging When compiled from source,

[Xen-devel] [PATCH 0/3] datacopier POLLHUP fixes handling when the fd is also readable

Andrew Cooper writes ("Re: [Xen-devel] [PATCH v3 6/6] tools/libxl: Adjust datacopiers POLLHUP handling when the fd is also readable"): > > > > libxl: error: libxl_bootloader.c:596:bootloader_copyfail: > > unexpected eof copying bootloader output > > > > libxl: debug: libxl_bootloader.c:638:bootl

[Xen-devel] [xen-4.3-testing test] 50286: regressions - FAIL

flight 50286 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50286/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 8 guest-start fail REGR. vs. 36755 test-amd64-i386-f

  1   2   3   >