> -Original Message-
> From: xen-devel-boun...@lists.xen.org
> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Hu, Robert
> Sent: Wednesday, August 5, 2015 2:22 PM
> To: ian.jack...@eu.citrix.com; Ian Campbell; wei.l...@citrix.com
> Cc: xen-devel@lists.xen.org
> Subject: [Xen-devel] O
Hi Ians,
Current ts-guest-destory will invoke guest_await_dhcp_tcp();
but in nested case, after l1 turns into Xen environment, it then has
fixed IP address; which in turn has failed at dhcp lease check.
So, how about if I in ts-guest-destroy bypass guest_await_dhcp_tcp()
if we have $r{guest->Gue
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Monday, August 03, 2015 6:02 PM
> To: Wu, Feng
> Cc: xen-devel@lists.xen.org; Keir Fraser; Jan Beulich; Andrew Cooper; Tian,
> Kevin; George Dunlap
> Subject: Re: [v4 16/17] vmx: Add some scheduler hook
flight 60395 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 59963
Tests which are f
This patch corrects a logic error when handling 64-bt bar with
more than 4G size.
With 64-bit Bar, it has two items in PCIDevice: io_regions[x]
and io_regions[x+1], io_regions[x] has all the informations for
this BAR, while io_regions[x+1] contains nothing, so we need to
get the size from io_regio
xsaves/xrstors only use compact format, so format convertion
is needed when perform save/restore.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/domain.c| 3 +
xen/arch/x86/hvm/hvm.c | 16 +++--
xen/arch/x86/xstate.c| 138 +++
xen/incl
This patch enables xsaves for hvm guest, includes:
1.handle xsaves vmcs init and vmexit.
2.add logic to write/read the XSS msr.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/hvm/hvm.c | 44 ++
xen/arch/x86/hvm/vmx/vmcs.c| 7 +-
xen/arch/x
This patch emualtes xsaves/xrstors instructions and
XSS msr access.
As xsaves/xrstors instructions and XSS msr access
required be executed only in ring0. So emulation are
needed when pv guest uses these instructions.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/domain.c | 3 +
xen/arc
As xsaves/xgetbv1 already support, so switch on.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/xstate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 0eea146..a3f5c67 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/
This patch exposes xsaves/xgetbv1/xsavec to hvm guest.
The reserved bits of eax/ebx/ecx/edx must be cleaned up
when call cpuid(0dh) with leaf 1 or 2..63.
According to the spec the following bits must be reseved:
For leaf 1, bits 03-04/08-31 of ecx is reserved. Edx is reserved.
For leaf 2...63, bit
This patch uses xsaves/xrstors instead of xsaveopt/xrstor
to perform the xsave_area switching so that xen itself
can benefit from them when available.
Please note that xsaves/xrstors only use compact format.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/i387.c | 5
xen/arch/x86/xsta
Changes in v3:
* Address comments from Jan/Konrad
* Change the bits of eax/ebx/ecx/edx passed to guest in patch 4.
* Add code to verify whether host supports xsaves or not in patch 1.
Changes in v2:
* Address comments from Andrew/chao/Jan, mainly:
* Add details information of xsaves/xrstors featur
flight 60389 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl 13 guest-saverestore fail REGR. vs. 59254
test-amd64-i386-xl-xs
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned long
mfn)
/* VIRT <-> MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
Hey David,
Sorry for the premature response on my phone earlier. Real reply follows.
>> rcu_read_lock, when using Xen PV. Relevant excerpts of the
> ^^ PV guest?
Yes. The lockup occurs on a PV guest. Nothing special at all about the
configuration. Vanilla upstream
On 04/08/2015 22:25, Wei Liu wrote:
> On Tue, Aug 04, 2015 at 07:58:38PM +0100, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
> [...]
>> index bfc9699..13dc2de 100644
>> --- a/tools/libxl/libxl_utils.c
>> +++ b/tools/libxl/libxl_utils.c
>> @@ -848,11 +848,10 @@ int libxl__count_physi
On Tue, Aug 04, 2015 at 07:58:38PM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
[...]
> index bfc9699..13dc2de 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -848,11 +848,10 @@ int libxl__count_physical_sockets(libxl__gc *gc, int
> *sockets)
>
On 04/08/15 15:39, Matthew Vernon wrote:
Hi,
On 04/08/15 15:22, Ian Campbell wrote:
On Tue, 2015-08-04 at 14:52 +0100, Matthew Vernon wrote:
Hi,
Hello,
I'm getting dom0 kernel panics, relating to moderately heavy use of
drbd. I think this is a Xen bug.
It is remarkably similar looking to
flight 60384 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60384/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 7669f7349829f0e472ba0d6e600492fd8170
baseline version:
ovmf 88656abf1b3a690969851880ba2b134e0d1
Signed-off-by: Andrew Cooper
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
For my cpuid work which I have just started, I added an array to physinfo.
Coverity then frowned at me when it spotted all the memory leaks.
Technically speaking, 4.6 isn't broken due to not having an allocation to
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.
Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: G
All the caller of xen_tmem_{get,put}_page have a struct page * in hand
and call pfn_to_gfn for the only benefits of these 2 functions.
Rather than passing the pfn in parameter, pass directly the page and use
directly page_to_gfn.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris O
ARM guests are always HVM. The current implementation is assuming a 1:1
mapping which is only true for DOM0 and may not be at all in the future.
Furthermore, all the helpers but arbitrary_virt_to_machine are used in
x86 specific code (or only compiled for).
The helper arbitrary_virt_to_machine is
The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename
all the occurence of MFN to GFN.
Also take the opportunity to replace to usage of pfn_to_gfn by
page_to_pfn.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc:
The privcmd code is mixing the usage of GFN and MFN within the same
functions which make the code difficult to understand when you only work
with auto-translated guests.
The privcmd driver is only dealing with GFN so replace all the mention
of MFN into GFN.
The ioctl structure used to map foreign
After the commit introducing convertion between DMA and guest address,
all the callers of pfn_to_mfn are expecting to get a GFN (Guest Frame
Number). On ARM, all the guests are auto-translated so the GFN is equal
to the Linux PFN (Pseudo-physical Frame Number).
The current implementation may retur
Hi all,
This patch series aims to use the memory terminologies described in
include/xen/mm.h [1] for Linux xen code.
Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first support of Xen was for PV. This has brought some misimplementation
of memory helpers on ARM and
The swiotlb is required when programming a DMA address on ARM when a
device is not protected by an IOMMU.
In this case, the DMA address should always be equal to the machine address.
For DOM0 memory, Xen ensure it by have an identity mapping between the
guest address and host address. However, whe
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This resulted in some misimplementation of helpers on ARM and
confused developers about the expected behavior.
For instance, with pfn_to_mfn, we expect to
On 03/08/15 18:31, Roger Pau Monné wrote:
> El 03/08/15 a les 18.55, Andrew Cooper ha escrit:
>> On 24/07/15 17:54, Roger Pau Monné wrote:
> struct vcpu_hvm_context {
> /* 16bit fields of the strucutre will be used. */
> #define _VCPUHVM_MODE_16B 0
> #define VCPUHVM_MOD
PV guest domU. PV host dom0.
On Aug 4, 2015 7:14 PM, "David Vrabel" wrote:
> On 04/08/15 17:41, Jason A. Donenfeld wrote:
> > Hi folks,
> >
> > Paul McKenney and I had an offline discussion about some rcu questions
> > that eventually lead into me investigating a strange full lock-up I'm
> > expe
The libxl blob for toolstack records was not 32/64bit safe. In 64bit
builds, it had an extra 4 bytes of padding due to alignment, and because
of the pointer arithmatic used to build it, leaked 4 bytes of libxl heap
into the stream.
Respecify XENSTORE_DATA as EMULATOR_XENSTORE_DATA and take remedi
Read and write "toolstack" information using the new
EMULATOR_XENSTORE_DATA record, and have the conversion script take care
of the old format.
The entire libxc and libxl migration v2 streams are now bitness-neutral
in their records.
Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
---
CC: Ian Ca
The new EMULATOR_XENSTORE_DATA content is a sequence of NUL terminated
key/value strings, with the key relative to the device model's xenstore
tree.
A sample might look like (as decoded by verify-stream-v2):
Emulator Xenstore Data (Qemu Upstream, idx 0)
'physmap/1f0/start_addr' = 'f
With the newly specified EMULATOR_XENSTORE_DATA record, there are two
libxl records with an emulator subheader. Refactor the existing code to
make future additions easier, and rename some functions for consistency
with the new scheme.
* Calculate the subheader at stream start time, rather than on
The legacy "toolstack" record as implemented in libxl turns out not to
be 32/64bit safe. As migration v2 has not shipped yet, take this
opportunity to adjust the specification and fix the incompatibility.
Libxl shall loose all knowledge of the old "toolstack" blob and use this
EMULATOR_XENSTORE_D
No functional change. It is not used any more.
Signed-off-by: Andrew Cooper
Acked-by: Ian Jackson
Acked-by: Wei Liu
---
CC: Ian Campbell
---
tools/libxl/libxl_dom.c | 223 --
tools/libxl/libxl_internal.h |4 -
tools/libxl/libxl_sr_str
Previously, in the case of an error causing a call to
libxl__conversion_helper_abort() on a stream without legacy conversion,
libxl would fall over a NULL pointer because chs->ao was not set up.
Arrange for all ->ao's to be set up at _init() time, by having each
_init() function assert that their
flight 60224 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60224/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511
Tests which are failing
On 04/08/15 17:41, Jason A. Donenfeld wrote:
> Hi folks,
>
> Paul McKenney and I had an offline discussion about some rcu questions
> that eventually lead into me investigating a strange full lock-up I'm
> experiencing as a consequence of a printk in softirq inside of an
> rcu_read_lock, when usin
flight 60374 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60374/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR.
vs. 59059
test-amd64
Hi folks,
Paul McKenney and I had an offline discussion about some rcu questions
that eventually lead into me investigating a strange full lock-up I'm
experiencing as a consequence of a printk in softirq inside of an
rcu_read_lock, when using Xen PV. Relevant excerpts of the
conversation follow:
Hi,
On 31/07/15 11:55, Ian Campbell wrote:
>>> +/* Only used in PV code. However ARM guest is always assimilated as
>>> HVM. */
>>^ "However" doesn't make sense here from an
>>english grammer point of view.
>
> "English grammar" :-P
flight 60217 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60217/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in
60152 pass in 60217
test-armhf-arm
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-qemut-debianhvm-amd64
test guest-saverestore
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/sta
On 2015/8/4 22:43, Christoffer Dall wrote:
Hi Shannon,
On Tue, Aug 4, 2015 at 3:43 PM, Shannon Zhao wrote:
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
To Xen itself booting with ACP
On 2015/8/4 22:37, Stefano Stabellini wrote:
On Tue, 4 Aug 2015, Shannon Zhao wrote:
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
Good start!
To Xen itself booting with ACPI, this
On 31/07/15 14:30, Ross Lagerwall wrote:
> When a channel is closed and the event is still linked into a queue,
> ensure that it is unlinked before completing. If it is not unlinked and
> the port is subsequently reused, events may be missed.
>
> If the CPU to which the event channel bound is onli
Hi Vijay,
On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Allocate and initialize irq descriptor for LPIs and
> route LPIs to guest
On v4, I've asked to see a commit message explaining how you route the
LPI and why you don't set GICH_LR.HW.
I don't see it know, so I
-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 for-linus-4.2-rc5-tag
xen: bug fixes for 4.2-rc5
- - Don't lose interrupts when offlining CPUs.
- - Fix gntdev oops during unmap.
- - Drop the ball
On Tue, Aug 04, 2015 at 03:40:59PM +0100, Ross Lagerwall wrote:
> Waking the dealloc thread before decrementing inflight_packets is racy
> because it means the thread may go to sleep before inflight_packets is
> decremented. If kthread_stop() has already been called, the dealloc
> thread may wait f
Waking the dealloc thread before decrementing inflight_packets is racy
because it means the thread may go to sleep before inflight_packets is
decremented. If kthread_stop() has already been called, the dealloc
thread may wait forever with nothing to wake it. Instead, wake the
thread only after decr
Hi Shannon,
On Tue, Aug 4, 2015 at 3:43 PM, Shannon Zhao wrote:
> This document is going to explain the design details of Xen booting with
> ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
> welcome.
>
> To Xen itself booting with ACPI, this is similar to Linux kernel exce
Hi,
On 04/08/15 15:22, Ian Campbell wrote:
On Tue, 2015-08-04 at 14:52 +0100, Matthew Vernon wrote:
Hi,
Hello,
I'm getting dom0 kernel panics, relating to moderately heavy use of
drbd. I think this is a Xen bug.
It is remarkably similar looking to
http://blog.chinewalking.com/drbd-kernel-
On Tue, 4 Aug 2015, Shannon Zhao wrote:
> This document is going to explain the design details of Xen booting with
> ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
> welcome.
Good start!
> To Xen itself booting with ACPI, this is similar to Linux kernel except
> that Xen
On Tue, 2015-08-04 at 14:52 +0100, Matthew Vernon wrote:
> Hi,
Hello,
> I'm getting dom0 kernel panics, relating to moderately heavy use of
> drbd. I think this is a Xen bug.
It is remarkably similar looking to
http://blog.chinewalking.com/drbd-kernel-oops-w-trim/ . Do you have trim?
Ian.
>
On Mon, Aug 3, 2015 at 6:05 PM, Andrew Cooper wrote:
> It is not used, and can cause a spurious failure of the set_gdt() hypercall in
> low memory situations.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: George Dunlap
> ---
> CC: Jan Beulich
> ---
> xen/arch/x86/mm.c |9 +
> 1 f
On 04/08/15 14:59, Ian Campbell wrote:
> On Tue, 2015-08-04 at 10:34 +0100, Wei Liu wrote:
>> On Mon, Aug 03, 2015 at 06:05:43PM +0100, Andrew Cooper wrote:
>>> It is not used, and can cause a spurious failure of the set_gdt()
>>> hypercall in
>>> low memory situations.
>>>
>>> Signed-off-by: Andr
On Tue, 2015-08-04 at 14:47 +0100, Stefano Stabellini wrote:
> On Tue, 4 Aug 2015, Ian Campbell wrote:
> > On Tue, 2015-08-04 at 14:18 +0100, Stefano Stabellini wrote:
> > > On Tue, 4 Aug 2015, Ian Campbell wrote:
> > > > On Tue, 2015-08-04 at 12:18 +0100, Stefano Stabellini wrote:
> > > > > > It h
On Tue, 2015-08-04 at 10:34 +0100, Wei Liu wrote:
> On Mon, Aug 03, 2015 at 06:05:43PM +0100, Andrew Cooper wrote:
> > It is not used, and can cause a spurious failure of the set_gdt()
> > hypercall in
> > low memory situations.
> >
> > Signed-off-by: Andrew Cooper
> > ---
> > CC: Jan Beulich
>
Hi,
I'm getting dom0 kernel panics, relating to moderately heavy use of
drbd. I think this is a Xen bug.
My Xen hosts are Debian jessie amd64 boxes, on slightly elderly Intel
kit.
Linux ophon 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24)
x86_64 GNU/Linux
Linux opus 3.16.0-4-am
On Tue, 2015-08-04 at 15:47 +0200, Roger Pau Monné wrote:
> El 04/08/15 a les 15.41, Ian Campbell ha escrit:
> > On Tue, 2015-08-04 at 14:18 +0100, Stefano Stabellini wrote:
> > > On Tue, 4 Aug 2015, Ian Campbell wrote:
> > > > On Tue, 2015-08-04 at 12:18 +0100, Stefano Stabellini wrote:
> > > > >
On Tue, 4 Aug 2015, Ian Campbell wrote:
> On Tue, 2015-08-04 at 14:18 +0100, Stefano Stabellini wrote:
> > On Tue, 4 Aug 2015, Ian Campbell wrote:
> > > On Tue, 2015-08-04 at 12:18 +0100, Stefano Stabellini wrote:
> > > > > It hasn't actually failed though, is that normal?
> > > >
> > > > It is a
On Mon, Aug 3, 2015 at 3:34 PM, Ian Campbell wrote:
> On Mon, 2015-08-03 at 14:54 +0100, Andrew Cooper wrote:
>> On 03/08/15 14:35, Ben Catterall wrote:
>> > Hi all,
>> >
>> > I am working on an x86 proof-of-concept to evaluate if it is feasible
>> > to move device models and x86 emulation code fo
El 04/08/15 a les 15.41, Ian Campbell ha escrit:
> On Tue, 2015-08-04 at 14:18 +0100, Stefano Stabellini wrote:
>> On Tue, 4 Aug 2015, Ian Campbell wrote:
>>> On Tue, 2015-08-04 at 12:18 +0100, Stefano Stabellini wrote:
> It hasn't actually failed though, is that normal?
It is an "o
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
To Xen itself booting with ACPI, this is similar to Linux kernel except
that Xen doesn't parse DSDT table. So I'll skip this part and focus on
h
Hi Vijay,
On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Implements hw_irq_controller api's required
> to handle LPI's
You need to explain in your commit message why you switched to callback.
Relevant maintainers should be CCed too (see scripts/get_maintainers.pl).
On Tue, 2015-08-04 at 14:18 +0100, Stefano Stabellini wrote:
> On Tue, 4 Aug 2015, Ian Campbell wrote:
> > On Tue, 2015-08-04 at 12:18 +0100, Stefano Stabellini wrote:
> > > > It hasn't actually failed though, is that normal?
> > >
> > > It is an "optional" dependency, without it passthrough is d
On Tue, 4 Aug 2015, Ian Campbell wrote:
> On Thu, 2015-07-23 at 17:52 +0100, Stefano Stabellini wrote:
> >
> > +./cs-job-create $flight build-$arch-raisin build-raisin
> > \
> > +arch=$arch
> > \
> > +
Hi Vijay,
On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Allocate irq descriptors for LPIs dynamically and
> also update irq_to_pending helper for LPIs
You are mixing irq_desc and pending_irq aspect in the code which made
quite difficult to review.
It would have be
On Tue, 4 Aug 2015, Ian Campbell wrote:
> On Tue, 2015-08-04 at 12:18 +0100, Stefano Stabellini wrote:
> > On Tue, 4 Aug 2015, Ian Campbell wrote:
> > > On Thu, 2015-07-23 at 17:52 +0100, Stefano Stabellini wrote:
> > > > +sub build () {
> > > > +target_cmd_build($ho, 9000, $builddir, < > > > +
On Tue, Aug 04, 2015 at 01:50:58PM +0100, Ross Lagerwall wrote:
> Waking the dealloc thread before decrementing inflight_packets is racy
> because it means the thread may go to sleep before inflight_packets is
> decremented. If kthread_stop() has already been called, the dealloc
> thread may wait f
On Tue, 2015-08-04 at 13:56 +0100, Ian Campbell wrote:
> On Thu, 2015-07-23 at 17:52 +0100, Stefano Stabellini wrote:
> > diff --git a/ap-fetch-version b/ap-fetch-version
> > index 33aaf00..2788d9f 100755
> > --- a/ap-fetch-version
> > +++ b/ap-fetch-version
> > @@ -80,6 +80,9 @@ libvirt)
> > rump
This removes the possibility of the various bits (ENABLED_COMPONENTS,
TREE/REVISION_* and store_revision) getting out of sync. Use a hash
table to store overrides where the Raising and runvar names for a
component differ.
Also switch to using a shell heredoc to populate config, this was
necessary
Sends clones via any configured proxy.
XXX this only affects URLs explicitly configured by osstest, so not
any implicit ones. Perhaps there is a better Raisin way to achieve
this?
Signed-off-by: Ian Campbell
---
ts-raisin-build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On Thu, 2015-07-23 at 17:52 +0100, Stefano Stabellini wrote:
> diff --git a/ap-fetch-version b/ap-fetch-version
> index 33aaf00..2788d9f 100755
> --- a/ap-fetch-version
> +++ b/ap-fetch-version
> @@ -80,6 +80,9 @@ libvirt)
> rumpuserxen)
> repo_tree_rev_fetch_git rumpuserxen \
>
Hi all,
I have been asked by a number of people to kick off a retrospective for
* what worked well
* didn't work well
in the Xen 4.6 release cycle.
As most of the stress of the last few weeks is now out of the way, I
thought it would be appropriate to start this process now, and let it run
for a
Waking the dealloc thread before decrementing inflight_packets is racy
because it means the thread may go to sleep before inflight_packets is
decremented. If kthread_stop() has already been called, the dealloc
thread may wait forever with nothing to wake it. Instead, wake the
thread only after decr
flight 60214 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60214/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-vhd 5 xen-install fail baseline untested
test-amd64-i386-
-
| PCI Pass-through in Xen ARM |
-
manish.ja...@caviumnetworks.com
---
Draft-3
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for t
Hi all,
This series aims to fix the 32-bit access on 64-bit register. Some guest
OS such as FreeBSD and Linux (only in the ITS) use those access and will
crash when starting on Xen.
The first patch introduces generic helpers to read/write/clear/set a register.
While the second is the main purpose
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers suppo
On Tue, 2015-08-04 at 12:18 +0100, Stefano Stabellini wrote:
> On Tue, 4 Aug 2015, Ian Campbell wrote:
> > On Thu, 2015-07-23 at 17:52 +0100, Stefano Stabellini wrote:
> > > +sub build () {
> > > +target_cmd_build($ho, 9000, $builddir, < > > +cd $raisindir
> > > +./raise -n buil
flight 60210 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60210/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 58581
Tests which are failin
On Tue, 4 Aug 2015, Ian Campbell wrote:
> On Thu, 2015-07-23 at 17:52 +0100, Stefano Stabellini wrote:
> > +sub build () {
> > +target_cmd_build($ho, 9000, $builddir, < > +cd $raisindir
> > +./raise -n build
> > +END
> > +#/;
>
> Running this is pretty quiet it seems, which is
On Thu, 2015-07-23 at 17:52 +0100, Stefano Stabellini wrote:
> +sub build () {
> +target_cmd_build($ho, 9000, $builddir, < +cd $raisindir
> +./raise -n build
> +END
> +#/;
Running this is pretty quiet it seems, which is normally good but I think
for automated test we likely wan
On Mon, 2015-08-03 at 17:59 +0100, Stefano Stabellini wrote:
>
> > > +echo >>config ENABLED_COMPONENTS=\\"seabios ovmf xen qemu
> > > qemu_traditional libvirt\\"
> > > +END
> > > + (nonempty($r{tree_xen}) && nonempty($r{revision_xen})
> > > ? < > > +echo >>config XEN_URL=\\
On Mon, 2015-08-03 at 18:09 +0100, Stefano Stabellini wrote:
> +case "$branch" in
> +xen*) ;;
> +*) enable_raisin=false;;
> +esac
BTW, this doesn't actually enable raisin for builds on the raisin branch...
Ian.
___
Xen-devel mailing lis
On Tue, 2015-08-04 at 10:30 +, Hu, Robert wrote:
> >
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Friday, July 31, 2015 4:59 PM
> > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com
> > Cc: xen-devel@lists.xen.org
> > Subject: Re
On Thu, Jul 30, 2015 at 04:04:41PM +0100, Wei Liu wrote:
> Hi all
>
> Here are some bugs that I'm aware of. The name after a item is the
> person who is working on it.
>
> # Blockers
>
> 1. Toolstack record breaks migration v2 (Andrew Cooper)
Patches posted.
> 2. Block hotplug scripts invoked
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, July 31, 2015 4:59 PM
> To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com
> Cc: xen-devel@lists.xen.org
> Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of guest
> au
On Tue, Aug 04, 2015 at 12:02:55PM +0200, Roger Pau Monne wrote:
> The default libxl timeout for hotplug scripts execution is too low, when
> launching 40 HVM guests in parallel, all using the same file as disk,
> execution times of ~20s are expected. Increase the timeout to 40s in order
> to be su
On Tue, 2015-08-04 at 11:16 +0100, Wei Liu wrote:
> That function was removed in 2ba368d1 ("libxl: Remove linux udev rules")
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
Trivially fine for 4.6 IMHO.
> ---
> tools/libxl/libxl_internal.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff
On 04/08/15 11:06, Ian Campbell wrote:
>
+
+ 0 1 2 3 4 5 6 7 octet
++++
+| emulator_id| index |
++++
That function was removed in 2ba368d1 ("libxl: Remove linux udev rules")
Signed-off-by: Wei Liu
---
tools/libxl/libxl_internal.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 911de2d..2771c71 100644
--- a/tools/libxl/libxl
On Tue, 2015-08-04 at 10:42 +0100, Andrew Cooper wrote:
> On 04/08/15 10:40, Ian Campbell wrote:
> > On Mon, 2015-08-03 at 16:56 +0100, Andrew Cooper wrote:
> > > The legacy "toolstack" record as implemented in libxl turns out not
> > > to
> > > be 32/64bit safe. As migration v2 has not shipped y
The default libxl timeout for hotplug scripts execution is too low, when
launching 40 HVM guests in parallel, all using the same file as disk,
execution times of ~20s are expected. Increase the timeout to 40s in order
to be sure hotplug scripts have enough time to execute.
Signed-off-by: Roger Pau
On Mon, 2015-08-03 at 16:56 +0100, Andrew Cooper wrote:
> With the newly specified EMULATOR_XENSTORE_DATA record, there are two
> libxl records with an emulator subheader. Refactor the existing code to
> make future additions easier, and rename some functions for consistency
> with the new scheme.
On Mon, 2015-08-03 at 16:56 +0100, Andrew Cooper wrote:
> The new EMULATOR_XENSTORE_DATA content is a sequence of NUL terminated
> key/value strings, with the key relative to the device model's xenstore
> tree.
>
> A sample might look like (as decoded by verify-stream-v2):
>
> Emulator Xensto
1 - 100 of 118 matches
Mail list logo
