On 2014/12/3 4:01, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
We need to use reserved device memory maps with multiple times, so
provide just one common function should be friend.
We need to call reserved device memory maps hypercall
(XENMEM_reser
>>> On 05.12.14 at 18:10, wrote:
> On 12/05/2014 11:03 AM, Jan Beulich wrote:
> On 05.12.14 at 16:55, wrote:
>> On 02.12.14 at 22:34, wrote:
+struct xen_sysctl_iotopo {
+uint16_t seg;
+uint8_t bus;
+uint8_t devfn;
+uint32_t node;
+};
>>> This
>>> On 07.12.14 at 14:43, wrote:
> On 12/05/2014 08:24 PM, Jan Beulich wrote:
> On 05.12.14 at 11:00, wrote:
>>> 5. Potential workaround
>>> 5.1 Use per-cpu list in idle_loop()
>>> Delist a batch of pages from heap_list to a per-cpu list, then scrub the
>>> per-cpu list and free back to heap
flight 32137 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32137/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start
>>> On 08.12.14 at 07:06, wrote:
> On 2014/12/4 23:33, Jan Beulich wrote:
> On 01.12.14 at 10:24, wrote:
> Looks this could be fine,
>
> d->arch.hvm_domain.pci_force = xdsr->flags & PCI_DEV_RDM_CHECK;
Which is correct only because PCI_DEV_RDM_CHECK happens to be
1. Such hidden dependencies
On 2014/12/8 16:09, Chen, Tiejun wrote:
On 2014/12/3 4:01, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
We need to use reserved device memory maps with multiple times, so
provide just one common function should be friend.
We need to call reserved d
>>> On 08.12.14 at 08:11, wrote:
> On 2014/12/4 23:50, Jan Beulich wrote:
> On 01.12.14 at 10:24, wrote:
>>>
>>> -if ( __copy_to_compat_offset(grdm->map.buffer, grdm->used_entries,
>>> - &rdm, 1) )
>>> -return -EFAULT;
>>> +if ( d )
On 2014/12/4 23:52, Jan Beulich wrote:
On 01.12.14 at 10:24, wrote:
We need to use reserved device memory maps with multiple times, so
provide just one common function should be friend.
I'm not going to repeat earlier comments; the way this is done right
now it's neither a proper runtime func
>>> On 06.12.14 at 01:05, wrote:
> On 05/12/2014 16:55, Jan Beulich wrote:
> > I didn't change ARM, as I wasn't sure how far ahead this call could be
>> pulled.
>
> AFAIU, the new function only requires that the page table are setup
> (because of the alloc_xenheap_pages).
>
> So console_init_
>>> On 05.12.14 at 18:22, wrote:
> On Fri, Dec 05, 2014 at 04:55:24PM +, Jan Beulich wrote:
>> @@ -763,17 +762,28 @@ void __init console_init_postirq(void)
>> }
>> opt_conring_size = PAGE_SIZE << order;
>>
>> -spin_lock_irq(&console_lock);
>> +spin_lock_irqsave(&console_lock,
>>> On 05.12.14 at 18:59, wrote:
> On Fri, Dec 05, 2014 at 05:00:52PM +, Jan Beulich wrote:
>> >>> On 05.12.14 at 17:40, wrote:
>> > On Fri, Dec 05, 2014 at 03:00:14PM +, Jan Beulich wrote:
>> >> but I don't think this possibility of renaming warrants a much longer
>> >> discussion. Pleas
On 2014/12/2 17:11, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
We need to make sure all mmio allocation don't overlap
any rdm, reserved device memory. Here we just skip
all reserved device memory range in mmio space.
Signed-off-by: Tiejun Chen
---
tools/fir
>>> On 06.12.14 at 02:50, wrote:
> On Fri, 05 Dec 2014 14:06:53 +
> "Jan Beulich" wrote:
>
>> PVH guests are not supposed to access I/O ports they weren't given
>> access to (there's nothing to handle emulation of such accesses).
>>
>> Reported-by: Roger Pau Monné
>> Signed-off-by: Jan Beul
On 2014/12/5 0:04, Jan Beulich wrote:
On 01.12.14 at 10:24, wrote:
We need to make sure all mmio allocation don't overlap
any rdm, reserved device memory. Here we just skip
all reserved device memory range in mmio space.
I think someone else already suggested that this and patch 9 should
Wh
PVH guests accessing I/O ports via string ops is not supported yet.
Reported-by: Roger Pau Monné
Signed-off-by: Jan Beulich
---
v2: handle_pio() is already safe (pointed out by Mukesh), so only refuse
entering handle_mmio().
Note: Only compile tested so far.
--- unstable.orig/xen/arch/x86/hv
>>> On 08.12.14 at 09:52, wrote:
> On 2014/12/4 23:52, Jan Beulich wrote:
> On 01.12.14 at 10:24, wrote:
>>> We need to use reserved device memory maps with multiple times, so
>>> provide just one common function should be friend.
>>
>> I'm not going to repeat earlier comments; the way this i
On 12/08/2014 04:34 PM, Jan Beulich wrote:
On 07.12.14 at 14:43, wrote:
>
>> On 12/05/2014 08:24 PM, Jan Beulich wrote:
>> On 05.12.14 at 11:00, wrote:
5. Potential workaround
5.1 Use per-cpu list in idle_loop()
Delist a batch of pages from heap_list to a per-cpu list, t
On Fri, Dec 05, Konrad Rzeszutek Wilk wrote:
> OK. That might be complicated in that the context could change between
> bootup and run-time (I think that is what Michael told me).
The proper place to handle mount options is /etc/fstab. My version of
systemd is kind enough to use the values frm fs
>>> On 08.12.14 at 10:28, wrote:
> On 12/08/2014 04:34 PM, Jan Beulich wrote:
> On 07.12.14 at 14:43, wrote:
>>
>>> On 12/05/2014 08:24 PM, Jan Beulich wrote:
>>> On 05.12.14 at 11:00, wrote:
> 5. Potential workaround
> 5.1 Use per-cpu list in idle_loop()
> Delist a batch o
On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> The example XSM policy was missing permission for dom0_t to migrate
> domains; add these permissions.
>
> Reported-by: Wei Liu
> Signed-off-by: Daniel De Graaf
Acked-by: Ian Campbell
Konrad, we should take this for 4.5, in order to h
These are the usual PV debian flights with pvh=1 added to the
configuration file.
A job is created for each of Intel and AMD, although obviously AMD is
expected to fail at the moment.
In my testing I got:
(XEN) Attempt to create a PVH guest on a system without necessary hardware
support
beca
>>> On 08.12.14 at 07:17, wrote:
> On 2014/12/3 3:47, Konrad Rzeszutek Wilk wrote:
>> On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
>>> @@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>> break;
>>> }
>>>
>>> +#ifdef
On Sun, 2014-12-07 at 18:54 +0100, Samuel Thibault wrote:
> Hello,
>
> Martin Lucina, le Fri 05 Dec 2014 19:22:08 +0100, a écrit :
> > What's up with the -DHAVE_LIBC codepaths in mini-os? Who or what uses
> > these? Grepping around in stubdom/ doesn't come up with anything...
>
> HAVE_LIBC gets d
On Mon, Dec 08, 2014 at 06:44:26AM +, Zhangleiqiang (Trump) wrote:
> > On Fri, Dec 05, 2014 at 01:17:16AM +, Zhangleiqiang (Trump) wrote:
> > [...]
> > > > I think that's expected, because guest RX data path still uses
> > > > grant_copy while guest TX uses grant_map to do zero-copy transmi
Ping?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 08.12.14 at 03:30, wrote:
> +#ifndef NDEBUG
> +static bool_t xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
> +{
> +while ( b )
> +{
> +int __fl;
> +int __sl;
> +
> +MAPPING_INSERT(b->size, &__fl, &__sl);
> +if ( __fl != fl || __sl != sl )
The references Environment file does not exist, and the service file
does not make use of variables anyway.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 -
1 file chang
The referenced sysconfig/xenconsoled does not exist. If anything needs to be
specified it has to go into the existing sysconfig/xencommons file.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/hotplug/Linux/systemd/xenconsoled.service.
This is a resend of this series, with just the low hanging fruits:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00669.html
The mentioned wrapper to run xenstored from systemd without duplicate
functionality found in the sysv runlevel script will be send in another patch,
once it
Using SELinux mount options per default breaks several systems. Either
the context= mount option is not known at all to the kernel, or the
default value "none" is unknown to SELinux. In both cases the unit will
fail.
The proper place to specify mount options is /etc/fstab. Appearently
systemd is k
There is no need to export XENSTORED_ROOTDIR. This variable can be
enabled in sysconfig/xencommons. If the variable is unset xenstored
will automatically use @XEN_LIB_STORED@.
Signed-off-by: Olaf Hering
Acked-by: Ian Jackson
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
>>> On 08.12.14 at 10:58, wrote:
> Ping?
Please be a little more patient - with this series not to go into 4.5,
there's no need to urgently review it. The hypervisor side parts sit
in my to-be-reviewed queue.
Jan
___
Xen-devel mailing list
Xen-devel@
On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
> On 11.08.2014 19:32, Zoltan Kiss wrote:
> > There is a long known problem with the netfront/netback interface: if the
> > guest
> > tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring
> > slots,
> > it gets dropp
On Fri, 2014-12-05 at 15:15 -0800, manish jaggi wrote:
> Hi,
>
> I am trying to find a tutorial to jumpstart installing XenServer / XCP
> on an ARM 64bit platform.
> Could the mailing list help.
TTBOMK there has been no work done on an ARM64 port of XenServer/XCP at
this time and only minimal wor
On 08/12/14 00:19, Mihai Donțu wrote:
> Both __warn() and __bug() take as first parameter the file name of the
> current compilation unit (__FILE__). Mark that parameter as constant to
> better reflect that.
>
> Signed-off-by: Mihai Donțu
This seems reasonable, but for 4.6 at this point.
Reviewe
On Mon, Dec 08, 2014 at 07:49:08AM +, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen-tip tree got a conflict in
> arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
> ("dma-mapping: replace set_arch_dma_coherent_ops with
> arch_setup_dma_ops") and 4bb257
On Thu, 2014-11-27 at 18:30 +, Ian Jackson wrote:
> Konrad: here is a set of fixes for libxl which ought IMO to be in 4.5.
> See below, or the rest of the thread, for details. It's broken up
> into 6 tiny patches for ease of review.
Konrad did I miss you reply/ack here or has one yet to be gi
On 05/12/14 21:31, Greg Kroah-Hartman wrote:
> On Fri, Dec 05, 2014 at 02:08:00PM +, David Vrabel wrote:
>> A generic dma_get_required_mask() is useful even for architectures (such
>> as ia64) that define ARCH_HAS_GET_REQUIRED_MASK.
>>
>> Signed-off-by: David Vrabel
>> Reviewed-by: Stefano Sta
On 05/12/14 17:22, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 05, 2014 at 10:30:01AM +, David Vrabel wrote:
>> On 04/12/14 15:39, Alex Williamson wrote:
>>>
>>> I don't know what workaround you're talking about. As devices are
>>> released from the user, vfio-pci attempts to reset them. If
>>
On 08/12/14 05:32, Juergen Gross wrote:
> Commit 5b8e7d80542487ff1bf17b4cf2922a01dee13d3a removed the __init
> annotation from xen_set_identity_and_remap_chunk(). Add it again.
Applied, thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
h
flight 32139 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32139/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 4 xen-install fail REGR. vs. 32093
build-armhf-pvops
On 02/12/14 16:13, Thanos Makatos wrote:
>
> +struct gntdev_grant_copy_segment {
> +
> + union {
> + /* copy from (to) self to (from) guest */
> + struct {
> + /*
> + * source address and length
> + */
> +
On 08/12/14 10:19, Luis Henriques wrote:
> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>> On 11.08.2014 19:32, Zoltan Kiss wrote:
>>> There is a long known problem with the netfront/netback interface: if the
>>> guest
>>> tries to send a packet which constitues more than MAX_SKB_
On Mon, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote:
>
>
> >>> On 12/6/2014 at 12:06 AM, in message
> <20141205160615.ga24...@zion.uk.xensource.com>, Wei Liu
> wrote:
> > I have to admit I'm confused by the back and forth discussion. It's hard
> > to justify the design of new API with
On 08.12.2014 12:11, David Vrabel wrote:
> On 08/12/14 10:19, Luis Henriques wrote:
>> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
>>> On 11.08.2014 19:32, Zoltan Kiss wrote:
There is a long known problem with the netfront/netback interface: if the
guest
tries to s
On Mon, Dec 08, 2014 at 11:12:14AM +, Wei Liu wrote:
> On Mon, Dec 08, 2014 at 12:34:47AM -0700, Chun Yan Liu wrote:
> >
> >
> > >>> On 12/6/2014 at 12:06 AM, in message
> > <20141205160615.ga24...@zion.uk.xensource.com>, Wei Liu
> >
> > wrote:
> > > I have to admit I'm confused by the bac
On 08/12/14 11:21, Stefan Bader wrote:
> On 08.12.2014 12:11, David Vrabel wrote:
>> On 08/12/14 10:19, Luis Henriques wrote:
>>> On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
On 11.08.2014 19:32, Zoltan Kiss wrote:
> There is a long known problem with the netfront/netback
On 08/12/14 08:52, Jan Beulich wrote:
On 06.12.14 at 01:05, wrote:
>> On 05/12/2014 16:55, Jan Beulich wrote:
>> > I didn't change ARM, as I wasn't sure how far ahead this call could be
>>> pulled.
>>
>> AFAIU, the new function only requires that the page table are setup
>> (because of the
On Fri, 2014-12-05 at 16:30 +, Anthony PERARD wrote:
Jim Fehlig maintains the libxl driver in libvirt, so you should CC him
(I've done so here...)
> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done b
Hi Oleksandr,
Please avoid top-post.
On 08/12/14 06:34, Oleksandr Dmytryshyn wrote:
> In our case We've added an additional fake node to the device tree with
> UART MMIO range for Xen and Xen mapped this MMIO range
> for the Kernel 3.8. By default UART has wrong configuration in OMAP.
Ok. So it
On 28/11/14 15:19, Anthony Wright wrote:
> We have a 64 bit PV DomU that we recently upgraded from linux 3.3.2 to
> 3.17.3 running on a 64 bit 3.17.3 Dom0 with Xen 4.4.0.
>
> Shortly after the upgrade we started to lose network connectivity to the
> DomU a few times a day that required a reboot to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2014-9065,CVE-2014-9066 / XSA-114
version 3
p2m lock starvation
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
The c
On 08.12.2014 12:31, David Vrabel wrote:
> On 08/12/14 11:21, Stefan Bader wrote:
>> On 08.12.2014 12:11, David Vrabel wrote:
>>> On 08/12/14 10:19, Luis Henriques wrote:
On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
> On 11.08.2014 19:32, Zoltan Kiss wrote:
>> There is
On Fri, Dec 05, Ian Jackson wrote:
> I think the only way to make this work properly is to factor the
> necessary parts out of init.d/xencommons into a new script which can
> be used by both xencommons and systemd. I'm not sure such a patch
> would be appropriate for 4.5 at this stage.
I came up
On Sat, 2014-12-06 at 14:28 +0530, Sagun Garg wrote:
> Links
> http://labs.online.net/press and http://labs.online.net/ Will it be ok
> to install Xen on this? They are still in their trial mode.
I'm not aware of anyone having run Xen on a marvel chipset, but in
principal a port should be doable
On Sun, 2014-12-07 at 15:00 +0530, Sagun Garg wrote:
> Hi Ian/Julien,
You only mailed me, not Julien or the list. Given you addressed it to
Julien I have assumed that the lack of CC was in error and added both
back. Please keep things on the list in future.
> I happened to find this link :
> htt
> On Mon, Dec 08, 2014 at 06:44:26AM +, Zhangleiqiang (Trump) wrote:
> > > On Fri, Dec 05, 2014 at 01:17:16AM +, Zhangleiqiang (Trump) wrote:
> > > [...]
> > > > > I think that's expected, because guest RX data path still uses
> > > > > grant_copy while guest TX uses grant_map to do zero-co
On Mon, Dec 8, 2014 at 2:02 PM, Julien Grall wrote:
>
> Hi Oleksandr,
>
> Please avoid top-post.
>
> On 08/12/14 06:34, Oleksandr Dmytryshyn wrote:
> > In our case We've added an additional fake node to the device tree with
> > UART MMIO range for Xen and Xen mapped this MMIO range
> > for the Ker
On 06/12/14 00:45, Zir Blazer wrote:
Replying somewhat out of order:
> I hope someone finds my questions interesing to answer.
It is certainly an interesting read - I will answer what I can.
> While I am not a developer myself (I always sucked hard when it comes to read
> and write code), ther
On Mon, 8 Dec 2014, Ian Campbell wrote:
> On Fri, 2014-12-05 at 15:15 -0800, manish jaggi wrote:
> > Hi,
> >
> > I am trying to find a tutorial to jumpstart installing XenServer / XCP
> > on an ARM 64bit platform.
> > Could the mailing list help.
>
> TTBOMK there has been no work done on an ARM64
Hi Vijay,
You are fixing the pl011 driver, not all the UART. So the commit title
should at least contain the word "pl011".
On 06/12/14 01:42, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> On pl011.c when TX interrupt is received and
Why do you give the filename rather than the UART?
UART is not able to receive bytes when idle mode is not
configured properly. When we use Xen with old Linux
Kernel (for example 3.8) this kernel configures hwmods
for all devices even if the device tree nodes for those
devices is absent in device tree. Thus UART idle mode
is configured too. The fak
On Mon, Dec 08, 2014 at 01:08:18PM +, Zhangleiqiang (Trump) wrote:
> > On Mon, Dec 08, 2014 at 06:44:26AM +, Zhangleiqiang (Trump) wrote:
> > > > On Fri, Dec 05, 2014 at 01:17:16AM +, Zhangleiqiang (Trump) wrote:
> > > > [...]
> > > > > > I think that's expected, because guest RX data p
If a command we run times out, the machinery in tcmdex() will arrange
for the ts-* script to spot the timeout, and stop waiting for it.
However it is also necessary for the command we ran to die. It has a
copy of the owner daemon fd, so if it doesn't, our resources won't get
freed. In sufficient
On Mon, 2014-12-08 at 14:08 +, Ian Jackson wrote:
> If a command we run times out, the machinery in tcmdex() will arrange
> for the ts-* script to spot the timeout, and stop waiting for it.
>
> However it is also necessary for the command we ran to die. It has a
> copy of the owner daemon fd,
flush_op is unambiguously defined by feature_flush:
REQ_FUA | REQ_FLUSH -> BLKIF_OP_WRITE_BARRIER
REQ_FLUSH -> BLKIF_OP_FLUSH_DISKCACHE
0 -> 0
and thus can be removed. This is just a cleanup.
The patch was suggested by Boris Ostrovsky.
Signed-off-by: Vitaly Kuznetsov
---
The patch is
Additionally please add IN and OUT annotations. When I first saw
this I assumed they would all be OUT (in which case the long running
loop problem mentioned in the reply to one of the other patches
wouldn't have been there), matching their CPU counterpart...
I don't follow this. Are you saying
On Mon, Dec 08, 2014 at 11:59:44AM +, Ian Campbell wrote:
> On Fri, 2014-12-05 at 16:30 +, Anthony PERARD wrote:
>
> Jim Fehlig maintains the libxl driver in libvirt, so you should CC him
> (I've done so here...)
Thanks.
> > The path to the pty of a Xen PV console is set only in
> > virD
On Mon, 2014-12-08 at 15:11 +, Anthony PERARD wrote:
> > > The patch intend to get the tty path on the first call of GetXMLDesc.
> >
> > Doesn't it actually do it on domain start (which makes more sense to me
> > anyway).
>
> Just a wording issue. I meant: Have GetXMLDesc always return the pa
>>> On 08.12.14 at 15:56, wrote:
Additionally please add IN and OUT annotations. When I first saw
this I assumed they would all be OUT (in which case the long running
loop problem mentioned in the reply to one of the other patches
wouldn't have been there), matching their CPU
On 08/12/14 15:19, Jan Beulich wrote:
On 08.12.14 at 15:56, wrote:
> Additionally please add IN and OUT annotations. When I first saw
> this I assumed they would all be OUT (in which case the long running
> loop problem mentioned in the reply to one of the other patches
> woul
On 12/05/2014 05:30 PM, Anthony PERARD wrote:
> Hi,
>
> I'm trying to fix an issue when using OpenStack with libvirt+xen
> (libxenlight).
> OpenStack cannot access the console output of a Xen PV guest, because the XML
> generated by libvirt for a domain is missing the path to the pty. The path
>
Hi,
while I was porting D01 platform
(https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
trying to describe the step I made and problems I encountered hoping
it could useful to other people. The idea is to put such documentation
in a wiki page or in the docs directory.
Let me kn
On Mon, Dec 08, 2014 at 09:48:07AM +, Ian Campbell wrote:
> On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > The example XSM policy was missing permission for dom0_t to migrate
> > domains; add these permissions.
> >
> > Reported-by: Wei Liu
> > Signed-off-by: Daniel De Graaf
>
On Mon, Dec 08, 2014 at 03:25:12PM +0800, Chen, Tiejun wrote:
> On 2014/12/3 3:50, Konrad Rzeszutek Wilk wrote:
> >On Mon, Dec 01, 2014 at 05:24:23PM +0800, Tiejun Chen wrote:
> >>We will introduce that hypercall xc_reserved_device_memory_map
> >>approach to libxc.
> >>
> >>Signed-off-by: Tiejun Ch
On Mon, 2014-12-08 at 10:52 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 08, 2014 at 09:48:07AM +, Ian Campbell wrote:
> > On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > > The example XSM policy was missing permission for dom0_t to migrate
> > > domains; add these permission
On Mon, Dec 08, 2014 at 11:16:07AM +0800, Chen, Tiejun wrote:
>
> On 2014/12/3 3:39, Konrad Rzeszutek Wilk wrote:
> >On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
> >>This should be based on a new parameter globally, 'pci_rdmforce'.
> >>
> >>pci_rdmforce = 1 => Of course this should
On Monday 08 December 2014 10:18:01 Jan Beulich wrote:
> >>> On 08.12.14 at 03:30, wrote:
> > +#ifndef NDEBUG
> > +static bool_t xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
> > +{
> > +while ( b )
> > +{
> > +int __fl;
> > +int __sl;
> > +
> > +MAPPIN
On Mon, Dec 08, 2014 at 10:38:09AM +, David Vrabel wrote:
> On 05/12/14 17:22, Konrad Rzeszutek Wilk wrote:
> > On Fri, Dec 05, 2014 at 10:30:01AM +, David Vrabel wrote:
> >> On 04/12/14 15:39, Alex Williamson wrote:
> >>>
> >>> I don't know what workaround you're talking about. As devices
On Mon, 2014-12-08 at 18:00 +0200, Mihai Donțu wrote:
> On Monday 08 December 2014 10:18:01 Jan Beulich wrote:
> > >>> On 08.12.14 at 03:30, wrote:
> > > +#ifndef NDEBUG
> > > +static bool_t xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
> > > +{
> > > +while ( b )
> > > +{
> >
On Mon, Dec 08, 2014 at 03:54:06PM +, Ian Campbell wrote:
> On Mon, 2014-12-08 at 10:52 -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Dec 08, 2014 at 09:48:07AM +, Ian Campbell wrote:
> > > On Fri, 2014-12-05 at 12:03 -0500, Daniel De Graaf wrote:
> > > > The example XSM policy was missin
On Fri, Nov 28, 2014 at 01:05:39PM +, Ian Campbell wrote:
> On Thu, 2014-11-27 at 18:30 +, Ian Jackson wrote:
> > Konrad: here is a set of fixes for libxl which ought IMO to be in 4.5.
> > See below, or the rest of the thread, for details. It's broken up
> > into 6 tiny patches for ease of
>>> On 06.12.14 at 04:55, wrote:
> From: Yu Zhang
>
> A new p2m type, p2m_mmio_write_dm, is added to trap and emulate
> the write operations on GPU's page tables. Handling of this new
> p2m type are similar with existing p2m_ram_ro in most condition
> checks, with only difference on final policy
>>> On 08.12.14 at 17:00, wrote:
> On Monday 08 December 2014 10:18:01 Jan Beulich wrote:
>> >>> On 08.12.14 at 03:30, wrote:
>> > +#ifndef NDEBUG
>> > +static bool_t xmem_pool_check_size(const struct bhdr *b, int fl, int sl)
>> > +{
>> > +while ( b )
>> > +{
>> > +int __fl;
>> >
On Monday 08 December 2014 16:04:55 Ian Campbell wrote:
> On Mon, 2014-12-08 at 18:00 +0200, Mihai Donțu wrote:
> > On Monday 08 December 2014 10:18:01 Jan Beulich wrote:
> > > >>> On 08.12.14 at 03:30, wrote:
> > > > +#ifndef NDEBUG
> > > > +static bool_t xmem_pool_check_size(const struct bhdr *b
On 12/08/2014 05:00 AM, Jan Beulich wrote:
On 08.12.14 at 07:17, wrote:
On 2014/12/3 3:47, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
@@ -1101,6 +1129,29 @@ long do_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
On Mon, Dec 08, 2014 at 04:40:04PM +0100, Ján Tomko wrote:
> On 12/05/2014 05:30 PM, Anthony PERARD wrote:
> > Hi,
> >
> > I'm trying to fix an issue when using OpenStack with libvirt+xen
> > (libxenlight).
> > OpenStack cannot access the console output of a Xen PV guest, because the
> > XML
> >
>>> On 08.12.14 at 17:45, wrote:
> If a guest who has control of a passthrough device can cause these
> reserved ranges to change, then there may be reason to prevent others
> from querying them, but that doesn't appear to be the case here.
Right, in that case we definitely would need a check.
J
>>> On 01.12.14 at 16:33, wrote:
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -363,10 +363,13 @@ EXPORT_SYMBOL(node_data);
> static void dump_numa(unsigned char key)
> {
> s_time_t now = NOW();
> -int i;
> +unsigned int i, j, n;
> +int err;
> struct domain *
>>> On 01.12.14 at 16:33, wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -302,6 +302,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> {
> case 0:
> fi.submap = 0;
> +fi.submap |= (1U << XENFEAT_memory_op_vnode_support
On Fri, Dec 05, Olaf Hering wrote:
> But even with that change xendomains is hanging if it cant talk to
> xenstored for whatever reason. The result is that the sytem hangs
> forever at shutdown.
This looks like a bug in the tools. xl or xenstore-ls hang forever if xenstored
disappears. Looks li
On Mon, Dec 08, 2014 at 06:19:49PM +0100, Olaf Hering wrote:
> On Fri, Dec 05, Olaf Hering wrote:
>
> > But even with that change xendomains is hanging if it cant talk to
> > xenstored for whatever reason. The result is that the sytem hangs
> > forever at shutdown.
>
> This looks like a bug in
On Mon, Dec 08, Wei Liu wrote:
> I think we have xenstored stubdom in tree, don't we?
If we do, isnt that a "special" setup which does not appear all by
its own? If so, shouldnt there be some config file knob to let xs_open
use socket only unless told otherwise by the to-be-created knob?
Olaf
_
On Mon, Dec 08, 2014 at 06:37:08PM +0100, Olaf Hering wrote:
> On Mon, Dec 08, Wei Liu wrote:
>
> > I think we have xenstored stubdom in tree, don't we?
>
> If we do, isnt that a "special" setup which does not appear all by
> its own? If so, shouldnt there be some config file knob to let xs_open
flight 32146 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32146/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen fbf232c42ae2dea512a2c34b154e1d63f3dad3c4
baseline version:
rumpuserxen 66b09d00078908e61d0f0c1b87fc
Hi,
Over the weekend, XenServer testing managed to run a side-by-side test
of XenServer trunk and XenServer experimental xen-4.5. These are
identical other than the version of Xen (and associated libraries) in
use, i.e. identical dom0 kernel, Xapi toolstack and dom0 userspace,
other than as linke
Anthony PERARD wrote:
> Hi,
>
> I'm trying to fix an issue when using OpenStack with libvirt+xen
> (libxenlight).
> OpenStack cannot access the console output of a Xen PV guest, because the XML
> generated by libvirt for a domain is missing the path to the pty. The path
> actually appear in the XM
Anthony PERARD wrote:
> The path to the pty of a Xen PV console is set only in
> virDomainOpenConsole. But this is done too late. A call to
> virDomainGetXMLDesc done before OpenConsole will not have the path to
> the pty, but a call after OpenConsole will.
>
Hi Anthony,
Thanks for the patch.
flight 32141 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32141/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 8 guest-start fail REGR. vs. 31241
test-amd64-amd64-xl-q
On Mon, Dec 08, 2014 at 07:03:19PM +, Andrew Cooper wrote:
> Hi,
Hey Andrew!
>
> Over the weekend, XenServer testing managed to run a side-by-side test
> of XenServer trunk and XenServer experimental xen-4.5. These are
> identical other than the version of Xen (and associated libraries) in
>
1 - 100 of 118 matches
Mail list logo