>>> On 26.11.15 at 00:27, wrote:
> A few more data points: I also tested Xen 4.6 on VMware ESXi 5.5, and
> it yields similar results. Not surprising, since Fusion uses basically
> the same virtualization engine.
>
> However, ESXi offers many more choices of number of processors, number
> of cores
Hi all, I'm not a developer but I would like to set up my Xen system to
get bug reports as useful as possible. At present I am logging the xen
console via serial port, and I am running Xen compiled from gentoo
ebuild with "debug" use flag. Is there anything more I need to set up to
be able to colle
>>> On 25.11.15 at 20:32, wrote:
> On 11/25/2015 10:31 AM, Jan Beulich wrote:
>>> However, I just noticed that various control and status registers are
>>> not available for v1. I wonder whether we should even support version 1
>>> since we'd need to add whole lot of 'if (supported)' throughout th
>>> On 25.11.15 at 17:26, wrote:
> On Wed, 2015-11-25 at 09:16 -0700, Jan Beulich wrote:
>> The use of $(basename ...) here was wrong (yet I'm sure I tested it).
>
> Is the issue here that xen/arch/x86/x86_64/.compat.o.d ought really to be
> xen/arch/x86/.x86_64.compat.o.d?
No, xen/arch/x86/x86_
On 25/11/15 17:12, Boris Ostrovsky wrote:
> On 11/12/2015 08:43 AM, Juergen Gross wrote:
>> In case the kernel of a new pv-domU indicates it is supporting an
>> unmapped initrd, don't waste precious virtual space for the initrd,
>> but allocate only guest physical memory for it.
>
> This patch bre
> From: Malcolm Crossley [mailto:malcolm.cross...@citrix.com]
> Sent: Wednesday, November 25, 2015 11:59 PM
>
> On 25/11/15 15:38, Jan Beulich wrote:
> On 25.11.15 at 16:13, wrote:
> >> On 25/11/15 10:49, Jan Beulich wrote:
> >> On 25.11.15 at 11:28, wrote:
> On 24/11/15 17:41, Jan
On 11/26/2015 10:57 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 26, 2015 at 10:28:10AM +0800, Bob Liu wrote:
>>
>> On 11/26/2015 06:12 AM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk wrote:
On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konra
flight 65101 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65101/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 3 host-install(3) broken REGR. vs. 65059
test-amd64-i386-xl6
On 25/11/15 20:24, Konrad Rzeszutek Wilk wrote:
> We could return EINVAL but EBUSY (or EALREADY?)is more appropiate.
>
> CC: jgr...@suse.com
> Signed-off-by: Konrad Rzeszutek Wilk
While it doesn't really matter it's cleaner.
Reviewed-by: Juergen Gross
> ---
> drivers/xen/xen-scsiback.c | 2 +
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Saturday, November 07, 2015 12:06 AM
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Andrew Cooper
> Acked-by: Jan Beulich
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Jun Nakajima
> Cc: Eddie Dong
> Cc: Kevin Tian
Acked-by: K
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Saturday, November 07, 2015 12:06 AM
>
> The HVM related code (SVM, VMX) generally assumed that a local apic is
> always present. With the introduction of a HVM mode were the local apic can
> be removed, some of this broken code paths a
On 26/11/15 06:06, Juergen Gross wrote:
> On 25/11/15 17:12, Boris Ostrovsky wrote:
>> On 11/12/2015 08:43 AM, Juergen Gross wrote:
>>> In case the kernel of a new pv-domU indicates it is supporting an
>>> unmapped initrd, don't waste precious virtual space for the initrd,
>>> but allocate only gue
On 25/11/15 17:12, Boris Ostrovsky wrote:
> On 11/12/2015 08:43 AM, Juergen Gross wrote:
>> In case the kernel of a new pv-domU indicates it is supporting an
>> unmapped initrd, don't waste precious virtual space for the initrd,
>> but allocate only guest physical memory for it.
>
> This patch bre
flight 65100 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 64579
test-amd64-amd64-xl
On Thu, Nov 26, 2015 at 10:28:10AM +0800, Bob Liu wrote:
>
> On 11/26/2015 06:12 AM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
> xen/blkback: separate ri
On 11/26/2015 06:12 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
xen/blkback: separate ring information out of struct xen_blkif
xen/blkback: pseudo s
I installed a nested xen (L1) on xen (L0). Is it possible to read or write
the physical memory of L1 from dom0 of L0? Is the L1 directly access the
physical memory or need to translate through L0?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://
On 2015/11/26 0:40, Stefano Stabellini wrote:
> Implement GICD_ICACTIVER and GICD_ISACTIVER reads by looking for the
> GIC_IRQ_GUEST_ACTIVE bit in the relevant struct pending_irq. However
> given that the pending to active transaction for irqs in LRs in done in
> hardware, the GIC_IRQ_GUEST_ACTIV
This introduces a way to have a restricted VPMU, by specifying one of two
predefined groups of PMCs to make available. For secure environments, this
allows the VPMU to be used without needing to enable all PMCs.
Signed-off-by: Brendan Gregg
---
Changes in v3:
* addressing review comments from Bor
flight 65095 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65095/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 6 xen-boot fail REGR. vs. 60684
test-amd64
On Wed, Nov 25, 2015 at 7:13 AM, Boris Ostrovsky wrote:
> On 11/24/2015 06:53 PM, Brendan Gregg wrote:
>
>> This introduces a way to have a restricted VPMU, by specifying one of two
>> predefined groups of PMCs to make available. For secure environments, this
>> allows the VPMU to be used without
A few more data points: I also tested Xen 4.6 on VMware ESXi 5.5, and
it yields similar results. Not surprising, since Fusion uses basically
the same virtualization engine.
However, ESXi offers many more choices of number of processors, number
of cores, hyperthreading, etc. The weird processor ID
This run is configured for baseline tests only.
flight 38345 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38345/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 capture-logs
On Wed, Nov 25, 2015 at 03:56:03PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
> > > xen/blkback: separate ring information out of struct xen_blkif
> > > xen/blkback: pseudo support for multi hardware queues/rings
> > > xen/blkb
flight 65098 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65098/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 9f419739d1ae849e0c4d75a131502f9367ca4a7d
baseline version:
ovmf 3164361121526318f278a7c1b84bdcc475d
getpwnam_r() has fairly complicated return rules. From man pages:
RETURN VALUE
...
On success, getpwnam_r() and getpwuid_r() return zero, and set
*result to pwd. If no matching password record was found, these
functions return 0 and store NULL in *result. In case of err
On Wed, Nov 25, 2015 at 02:25:07PM -0500, Konrad Rzeszutek Wilk wrote:
> > xen/blkback: separate ring information out of struct xen_blkif
> > xen/blkback: pseudo support for multi hardware queues/rings
> > xen/blkback: get the number of hardware queues/rings from blkfront
> > xen/blkback: m
flight 65096 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65096/
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
test-amd64-amd64-libvirt-
On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez"
> > >
> > > Using deprecate gnutls_*_set() triggers a
On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > Using deprecate gnutls_*_set() triggers a failure to compile
> > with gnutls30-3.4.4, used on OpenSUSE factory:
> >
>
Hey,
As I was reviewing Bob's backend patches I spotted a couple of
oddities that I thought should be fixed.
Please review at your leisure.
drivers/block/xen-blkback/xenbus.c | 10 --
drivers/block/xen-blkfront.c | 4 ++--
2 files changed, 10 insertions(+), 4 deletions(-)
Konra
With the multi-queue support we could fail at setting up
some of the rings and fail the connection. That meant that
all resources tied to rings[0..n-1] (where n is the ring
that failed to be setup). Eventually the frontend will switch
to the states and we will call xen_blkif_disconnect.
However we
Lets return sensible values instead of -1.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/block/xen-blkback/xenbus.c | 2 +-
drivers/block/xen-blkfront.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkba
On 11/25/2015 10:31 AM, Jan Beulich wrote:
However, I just noticed that various control and status registers are
not available for v1. I wonder whether we should even support version 1
since we'd need to add whole lot of 'if (supported)' throughout the code
plus there are some assumptions about
flight 65113 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65113/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
flight 65094 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64035
Regressions which ar
We could return EINVAL but EBUSY (or EALREADY?)is more appropiate.
CC: jgr...@suse.com
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/xen-scsiback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 43bcae8..28
> xen/blkback: separate ring information out of struct xen_blkif
> xen/blkback: pseudo support for multi hardware queues/rings
> xen/blkback: get the number of hardware queues/rings from blkfront
> xen/blkback: make pool of persistent grants and free pages per-queue
OK, got to those as wel
On Sat, Nov 14, 2015 at 11:12:17AM +0800, Bob Liu wrote:
> Backend advertises "multi-queue-max-queues" to front, also get the negotiated
> number from "multi-queue-num-queues" written by blkfront.
>
> Signed-off-by: Bob Liu
> ---
> drivers/block/xen-blkback/blkback.c | 12
> drive
> @@ -113,19 +115,55 @@ static void xen_update_blkif_status(struct xen_blkif
> *blkif)
> }
> invalidate_inode_pages2(blkif->vbd.bdev->bd_inode->i_mapping);
>
> - blkif->ring.xenblkd = kthread_run(xen_blkif_schedule, &blkif->ring,
> "%s", name);
> - if (IS_ERR(blkif->ring.xen
On Wed, Nov 25, 2015 at 3:11 AM, Chun Yan Liu wrote:
>
>
On 11/24/2015 at 10:40 PM, in message
> <1448376011-20217-1-git-send-email-george.dun...@eu.citrix.com>, George Dunlap
> wrote:
>> We have several outstanding patch series which add devices that have
>> two levels: a controller and ind
On Wed, Nov 25, 2015 at 06:26:01PM +0800, Peng Fan wrote:
> According to this piece code:
> "
> pr_info("Invalid max_ring_order (%d), will use default max: %d.\n",
> xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER);
> "
> if xen_blkif_max_ring_order is bigger that XENBUS_MA
Implement GICD_ICACTIVER and GICD_ISACTIVER reads by looking for the
GIC_IRQ_GUEST_ACTIVE bit in the relevant struct pending_irq. However
given that the pending to active transaction for irqs in LRs in done in
hardware, the GIC_IRQ_GUEST_ACTIVE bit might be out of date. We'll have
to live with that
On 11/25/2015 11:29 AM, Ian Campbell wrote:
On Wed, 2015-11-25 at 16:18 +, Wei Liu wrote:
On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:
On 11/12/2015 08:43 AM, Juergen Gross wrote:
In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't w
On Wed, Nov 25, 2015 at 04:29:13PM +, Ian Campbell wrote:
> On Wed, 2015-11-25 at 16:18 +, Wei Liu wrote:
> > On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:
> > > On 11/12/2015 08:43 AM, Juergen Gross wrote:
> > > > In case the kernel of a new pv-domU indicates it is suppo
On Wed, 2015-11-25 at 16:18 +, Wei Liu wrote:
> On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:
> > On 11/12/2015 08:43 AM, Juergen Gross wrote:
> > > In case the kernel of a new pv-domU indicates it is supporting an
> > > unmapped initrd, don't waste precious virtual space for
On Wed, 2015-11-25 at 09:16 -0700, Jan Beulich wrote:
> The use of $(basename ...) here was wrong (yet I'm sure I tested it).
Is the issue here that xen/arch/x86/x86_64/.compat.o.d ought really to be
xen/arch/x86/.x86_64.compat.o.d?
Otherwise xen/arch/x86/Makefile (which contains obj-y := ...
x86
On 11/25/2015 11:18 AM, Wei Liu wrote:
On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:
On 11/12/2015 08:43 AM, Juergen Gross wrote:
In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate
Paul Durrant writes ("[PATCH v2 2/2] libxl: implement libxl__xs_mknod using
XS_WRITE rather than XS_MKDIR"):
> This patch modifies the implentation of libxl__xs_mknod() to use XS_WRITE
> rather than XS_MKDIR since passing an empty value to the former will
> ensure that the path is both existent an
On Wed, Nov 25, 2015 at 11:12:12AM -0500, Boris Ostrovsky wrote:
> On 11/12/2015 08:43 AM, Juergen Gross wrote:
> >In case the kernel of a new pv-domU indicates it is supporting an
> >unmapped initrd, don't waste precious virtual space for the initrd,
> >but allocate only guest physical memory for
The use of $(basename ...) here was wrong (yet I'm sure I tested it).
Signed-off-by: Jan Beulich
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -105,7 +105,7 @@ include Makefile
DEPS = .*.d
define gendep
ifneq ($(1),$(subst /,:,$(1)))
-DEPS += $(dir $(1)).$(basename $(notdir $(1))).d
+
On 11/12/2015 08:43 AM, Juergen Gross wrote:
In case the kernel of a new pv-domU indicates it is supporting an
unmapped initrd, don't waste precious virtual space for the initrd,
but allocate only guest physical memory for it.
This patch breaks 32-bit pygrub.
I am not 100% sure yet but it may
>>> On 25.11.15 at 14:07, wrote:
>> On Nov 25, 2015, at 2:58 AM, Jan Beulich wrote:
>>
> On 24.11.15 at 19:19, wrote:
>>
On Nov 24, 2015, at 11:30 AM, Jan Beulich wrote:
>>> On 24.11.15 at 18:22, wrote:
>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore
>
On 25/11/15 15:38, Jan Beulich wrote:
On 25.11.15 at 16:13, wrote:
>> On 25/11/15 10:49, Jan Beulich wrote:
>> On 25.11.15 at 11:28, wrote:
On 24/11/15 17:41, Jan Beulich wrote:
On 24.11.15 at 18:17, wrote:
>> --- a/xen/drivers/passthrough/vtd/quirks.c
>> +++ b/xen
flight 65108 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65108/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Patch #1 is purely a search and replace
Patch #2 changes the underlying implementation
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
...to denote what it actually does.
The name libxl__xs_write() suggests something taking a buffer and length,
akin to write(2), whereas the semantics of the function are actually more
akin to printf(3).
This patch is a textual substitution of libxl__xs_write with
libxl__xs_printf with some associ
>>> On 25.11.15 at 15:26, wrote:
> On 11/25/2015 04:55 AM, Jan Beulich wrote:
> On 25.11.15 at 00:53, wrote:
>>> --- a/xen/arch/x86/cpu/vpmu_intel.c
>>> +++ b/xen/arch/x86/cpu/vpmu_intel.c
>>> @@ -166,10 +166,10 @@ static int core2_get_arch_pmc_count(void)
>>>*/
>>> static int core2_get
>>> On 25.11.15 at 16:13, wrote:
> On 25/11/15 10:49, Jan Beulich wrote:
> On 25.11.15 at 11:28, wrote:
>>> On 24/11/15 17:41, Jan Beulich wrote:
>>> On 24.11.15 at 18:17, wrote:
> --- a/xen/drivers/passthrough/vtd/quirks.c
> +++ b/xen/drivers/passthrough/vtd/quirks.c
> @@ -3
On Wed, 2015-11-25 at 14:37 +, Ian Campbell wrote:
> 2015-11-21 23:06:44 Z executing ssh ... root@172.16.144.44 virsh
> domxml-from-native xen-xl /etc/xen/debian.jessie.guest.osstest.cfg >
> /etc/xen/debian.jessie.guest.osstest.cfg.xml
> error: An error occurred, but the cause is unknown
Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory XSA-161
version 2
WITHDRAWN: missing XSETBV intercept privilege check on AMD SVM
UPDATES IN VERSION 2
Upon further inspection the necessary privilege le
This patch adds a new libxl__xs_vprintf() which actually checks the
success of the underlying call to xs_write() (logging if it fails) and
then re-implements libxl__xs_printf() using this (and replacing the
call to vasprintf() with a call to libxl__vsprintf()).
libxl__xs_vprintf() is added to the
flight 65088 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65088/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16
guest-localmigrate/x10 fail REGR. vs. 6
Introduce a new flags field and use bit 0 to signal if the FPU has been
initialised or not. Previously Xen always wrongly assumed the FPU was
initialised on restore.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v3:
- Don't add a comment in the compat struc
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
http://lists.xen.org/xen-devel
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 fix
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é
Reviewed-by: Andrew Cooper
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Tim Deegan
---
C
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 f
On 25/11/15 10:49, Jan Beulich wrote:
On 25.11.15 at 11:28, wrote:
>> On 24/11/15 17:41, Jan Beulich wrote:
>> On 24.11.15 at 18:17, wrote:
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -320,6 +320,20 @@ void __init platform_quirk
On 11/24/2015 06:53 PM, Brendan Gregg wrote:
This introduces a way to have a restricted VPMU, by specifying one of two
predefined groups of PMCs to make available. For secure environments, this
allows the VPMU to be used without needing to enable all PMCs.
Signed-off-by: Brendan Gregg
---
doc
This patch modifies the implentation of libxl__xs_mknod() to use XS_WRITE
rather than XS_MKDIR since passing an empty value to the former will
ensure that the path is both existent and empty upon return, rather than
merely existent. The function return type is also changed to a libxl
error value ra
On Wed, Nov 25, 2015 at 08:09:58AM +0100, Gerd Hoffmann wrote:
> Commit "c7628bf vnc: only alloc server surface with clients connected"
> missed one rarely used codepath (cirrus with guest drivers using 2d
> accel) where we have to check for the server surface being present,
> to avoid qemu crashin
This patch is purely cosmetic, it contains no functional change. A
change in the implementation of libxl__xs_mknod() will be made in a
subsequent patch.
Signed-off-by: Paul Durrant
Acked-by: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxl/libxl_create.c | 26
Patch #1 is purely a search and replace
Patch #2 changes the underlying implementation
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Tue, 2015-11-24 at 09:34 +, Ian Campbell wrote:
> Thinking about this some more overnight, it occurred to me that the
> real issue is that gnttab and gntshr are actually two quite difference
> APIs. gnttab is all about consuming grant references which are given to
> you from elsewhere while
On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Using deprecate gnutls_*_set() triggers a failure to compile
> with gnutls30-3.4.4, used on OpenSUSE factory:
>
> ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> ~/devel/xen/tools/qemu-x
Hi Jim,
On Sun, 2015-11-22 at 08:54 +, osstest service owner wrote:
This flight was an attempt to update osstest to use Debian Jessie instead
of Wheezy as the OS used on hosts and in guests. This should mean that the
test-armhf-armhf-* jobs which use d-i should now start working (since
Jessie
On 11/25/2015 04:55 AM, Jan Beulich wrote:
On 25.11.15 at 00:53, wrote:
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -166,10 +166,10 @@ static int core2_get_arch_pmc_count(void)
*/
static int core2_get_fixed_pmc_count(void)
{
-u32 eax;
+u32 edx;
-
This run is configured for baseline tests only.
flight 38342 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38342/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build
On 25/11/15 13:53, Jan Beulich wrote:
On 25.11.15 at 14:43, wrote:
>> On 25/11/15 12:35, Jan Beulich wrote:
>> On 20.11.15 at 17:03, wrote:
@@ -208,8 +210,6 @@ active_entry_acquire(struct grant_table *t,
grant_ref_t
>> e)
{
struct active_grant_entry *act;
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 25 November 2015 14:04
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell; Wei Liu
> Subject: Re: [PATCH 2/2] libxl: implement libxl__xs_mknod using XS_WRITE
> rather t
On Wed, Nov 25, 2015 at 1:23 PM, Big Strong wrote:
> Thanks for your replying and sorry for the behavior. Can I get that using
> libxc? Because I can't access the structure directly from dom0.
Also, please don't top-post. :-)
Hypercalls are made from the guest to the hypervisor; it's in the
hype
Paul Durrant writes ("[PATCH 2/2] libxl: implement libxl__xs_mknod using
XS_WRITE rather than XS_MKDIR"):
> This patch modifies the implentation of libxl__xs_mknod() to use XS_WRITE
> rather than XS_MKDIR since passing an empty value to the former will
> ensure that the path is both existent and e
flight 65086 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65086/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254
test-amd64-amd64-xl-p
Paul Durrant writes ("[PATCH 1/2] libxl: replace libxl__xs_mkdir() with
libxl__xs_mknod()"):
> This patch is purely cosmetic, it contains no functional change. A
> change in the implementation of libxl__xs_mknod() will be made in a
> subsequent patch.
Acked-by: Ian Jackson
_
>>> On 25.11.15 at 14:43, wrote:
> On 25/11/15 12:35, Jan Beulich wrote:
> On 20.11.15 at 17:03, wrote:
>>> @@ -208,8 +210,6 @@ active_entry_acquire(struct grant_table *t, grant_ref_t
> e)
>>> {
>>> struct active_grant_entry *act;
>>>
>>> -ASSERT(rw_is_locked(&t->lock));
>>
>> E
On 25/11/15 12:35, Jan Beulich wrote:
On 20.11.15 at 17:03, wrote:
>> @@ -208,8 +210,6 @@ active_entry_acquire(struct grant_table *t, grant_ref_t
>> e)
>> {
>> struct active_grant_entry *act;
>>
>> -ASSERT(rw_is_locked(&t->lock));
>
> Even if not covering all cases, I don't thin
rg/people/sstabellini/qemu-dm.git tags/xen-20151125
>
> for you to fetch changes up to 22037db38ccfe497bd13a94edead6657781b9b37:
>
> xen_disk: Remove ioreq.postsync (2015-11-25 11:04:55 +)
>
> --
Thanks for your replying and sorry for the behavior. Can I get that using
libxc? Because I can't access the structure directly from dom0.
2015-11-25 18:44 GMT+08:00 George Dunlap :
> On Wed, Nov 25, 2015 at 7:18 AM, Big Strong wrote:
> > I write a program to intercept all hypercalls happend on a
> On Nov 25, 2015, at 2:58 AM, Jan Beulich wrote:
>
On 24.11.15 at 19:19, wrote:
>
>>> On Nov 24, 2015, at 11:30 AM, Jan Beulich wrote:
>>>
>> On 24.11.15 at 18:22, wrote:
>>>
> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore
wrote:
>
> So, the files in xen/ w
>>> On 25.11.15 at 13:43, wrote:
> Currently check for not allowed sections is performed just after
> compilation. However, if compilation succeeds and check fails then
> second build will create xen.gz/xen.efi without any visible error.
> This happens because %.o: %.c recipe created object file d
On Wed, Nov 25, 2015 at 05:42:29AM -0700, Jan Beulich wrote:
> >> Mind explaining the point of the second XRSTOR_FIXUP?
> >> Alternative patching doesn't deal with multiple sections at a time,
> >> and I told you on the previous iteration that no second instance
> >> should be necessary. If there i
On 25/11/15 12:38, Jan Beulich wrote:
On 20.11.15 at 17:03, wrote:
>> @@ -115,7 +117,7 @@ static inline void _mm_write_lock(mm_rwlock_t *l, const
>> char *func, int level)
>> if ( !mm_write_locked_by_me(l) )
>> {
>> __check_lock_level(level);
>> -write_lock(&l->loc
Currently check for not allowed sections is performed just after
compilation. However, if compilation succeeds and check fails then
second build will create xen.gz/xen.efi without any visible error.
This happens because %.o: %.c recipe created object file during first
run and make do not execute th
>>> On 25.11.15 at 13:37, wrote:
> On Wed, Nov 25, 2015 at 02:35:30AM -0700, Jan Beulich wrote:
>> >>> On 25.11.15 at 08:51, wrote:
>> > @@ -197,20 +373,26 @@ void xrstor(struct vcpu *v, uint64_t mask)
>> Mind explaining the point of the second XRSTOR_FIXUP?
>> Alternative patching doesn't deal w
On Wed, 2015-11-18 at 15:49 +, Julien Grall wrote:
> 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 supe
>>> On 20.11.15 at 17:03, wrote:
> @@ -115,7 +117,7 @@ static inline void _mm_write_lock(mm_rwlock_t *l, const
> char *func, int level)
> if ( !mm_write_locked_by_me(l) )
> {
> __check_lock_level(level);
> -write_lock(&l->lock);
> + percpu_write_lock(p2m_percpu_rwlo
flight 65104 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65104/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Wed, Nov 25, 2015 at 02:35:30AM -0700, Jan Beulich wrote:
> >>> On 25.11.15 at 08:51, wrote:
> > @@ -197,20 +373,26 @@ void xrstor(struct vcpu *v, uint64_t mask)
> Mind explaining the point of the second XRSTOR_FIXUP?
> Alternative patching doesn't deal with multiple sections at a time,
> and I
>>> On 20.11.15 at 17:03, wrote:
> @@ -208,8 +210,6 @@ active_entry_acquire(struct grant_table *t, grant_ref_t e)
> {
> struct active_grant_entry *act;
>
> -ASSERT(rw_is_locked(&t->lock));
Even if not covering all cases, I don't think this should be dropped,
just like you don't drop r
1 - 100 of 176 matches
Mail list logo
