On 2/1/2016 7:56 PM, Andrew Cooper wrote:
c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE" introduced a
use-after-free error during domain destruction, because of the order in which
timers are torn down.
(XEN) Xen call trace:
(XEN)[] spinlock.c#check_lock+0x1e/0x40
(
> From: Zhang, Haozhong
> Sent: Tuesday, February 02, 2016 3:53 PM
>
> On 02/02/16 15:48, Tian, Kevin wrote:
> > > From: Zhang, Haozhong
> > > Sent: Tuesday, February 02, 2016 3:39 PM
> > >
> > > > btw, how is persistency guaranteed in KVM/QEMU, cross guest
> > > > power off/on? I guess since Qemu
Thanks for your reply, Ian.
On 2/2/2016 1:05 AM, Ian Jackson wrote:
Yu, Zhang writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
max_wp_ram_ranges."):
On 2/2/2016 12:35 AM, Jan Beulich wrote:
On 01.02.16 at 17:19, wrote:
So, we need also validate this param in hvm_allow_set_
On Tue, 2016-02-02 at 01:18 -0500, Tianyang Chen wrote:
> The following script caused an unresponsive dom0 and it can not be
> reproduced all the time. The dom0 is using credit2 scheduler.
>
> #!/bin/bash
> xl cpupool-list -c
> xl cpupool-cpu-remove Pool-0 3
> xl cpupool-cpu-remove Pool-0 2
> xl
On 02/02/16 16:03, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Tuesday, February 02, 2016 3:53 PM
> >
> > On 02/02/16 15:48, Tian, Kevin wrote:
> > > > From: Zhang, Haozhong
> > > > Sent: Tuesday, February 02, 2016 3:39 PM
> > > >
> > > > > btw, how is persistency guaranteed in KVM/QEMU
Hi,
> > I'd have qemu copy the data on 0xfc write then, so things continue to
> > work without updating seabios. So, the firmware has to allocate space,
> > reserve it etc., and programming the 0xfc register. Qemu has to make
> > sure the opregion appears at the address written by the firmwar
>>> On 01.02.16 at 20:17, wrote:
> On 02/01/2016 11:56 AM, Jan Beulich wrote:
> On 01.02.16 at 15:54, wrote:
>
>
> This looks very much like it needs backport of 33c19df9a ("x86/PCI:
> intercept accesses to RO MMIO from dom0s in HVM containers") from
> unstable, which fixe
> -Original Message-
> From: Bob Liu [mailto:bob@oracle.com]
> Sent: 02 February 2016 05:02
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v7 0/2] public/io/netif.h: support for
> toeplitz hashing
>
> Hi Paul,
>
> On 01/12/2016 05:58 PM, Paul
>>> On 02.02.16 at 07:31, wrote:
> On Tue, Jan 26, 2016 at 08:12:20AM -0700, Jan Beulich wrote:
>> >>> On 26.01.16 at 15:33, wrote:
>> > originally I only meant to inquire about the state of the promised
>> > alternatives improvement to the XSAVE code. However, while
>> > looking over the code in
>>> On 02.02.16 at 05:48, wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, January 29, 2016 5:32 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper ; Dario Faggioli
>> ; George Dunlap ;
>> Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser
>>
>> Subj
On Fri, 2016-01-29 at 11:59 +0100, Juergen Gross wrote:
> On 29/01/16 11:46, Jan Beulich wrote:
> > > > > On 29.01.16 at 11:21, wrote:
> > > --- a/xen/common/sched_credit.c
> > > +++ b/xen/common/sched_credit.c
> > > @@ -1086,12 +1086,19 @@ csched_dom_cntl(
> > > static inline void
> > > __csche
On 02/01/2016 07:00 PM, Andy Lutomirski wrote:
> This switches virtio to use the DMA API on Xen and if requested by
> module option.
>
> This fixes virtio on Xen, and it should break anything because it's
> off by default on everything except Xen PV on x86.
>
> To the Xen people: is this okay? I
On 02/02/16 08:00, Corneliu ZUZU wrote:
> On 2/1/2016 7:56 PM, Andrew Cooper wrote:
>> c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE"
>> introduced a
>> use-after-free error during domain destruction, because of the order
>> in which
>> timers are torn down.
>>
>>(XEN) Xen cal
On 02/02/16 07:40, Li, Liang Z wrote:
> Hi David,
>
> We found dom0 will crash when booing on HSW-EX server, the dom0 kernel
> version is v4.4. By debugging I found the your patch
> ' x86/xen: discard RAM regions above the maximum reservation' , which the
> commit ID is : f5775e0b6116b7e2425ccf53
>>> On 01.02.16 at 18:31, wrote:
> On 01/02/16 16:51, Jan Beulich wrote:
> On 01.02.16 at 17:34, wrote:
>>> On 01/02/16 16:28, Jan Beulich wrote:
>>> On 01.02.16 at 15:07, wrote:
> On 01/02/16 13:20, Jan Beulich wrote:
>> Ping? (I'd really like to get this resolved, so we don't n
On 02/02/16 10:11, Andrew Cooper wrote:
> On 02/02/16 07:40, Li, Liang Z wrote:
>> Hi David,
>>
>> We found dom0 will crash when booing on HSW-EX server, the dom0 kernel
>> version is v4.4. By debugging I found the your patch
>> ' x86/xen: discard RAM regions above the maximum reservation' , which
On 02/02/16 06:20, Dongli Zhang wrote:
> While npo.copy and npo.meta are initialized in xenvif_rx_action, fields
> such as npo.meta_prod are directly used later in xenvif_gop_skb without
> being initialized first. Although the output of xenvif_rx_action is based
> on the difference between new npo-
flight 38721 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38721/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-daily-netboot-pvgrub 10 guest-start fail blocked in
38664
Tests which
>>> On 01.02.16 at 18:05, wrote:
> Having said that, if the hypervisor maintainers are happy with a
> situation where this value is configured explicitly, and the
> configurations where a non-default value is required is expected to be
> rare, then I guess we can live with it.
Well, from the very
On 02/02/16 10:53, Dario Faggioli wrote:
> On Fri, 2016-01-29 at 11:59 +0100, Juergen Gross wrote:
>> On 29/01/16 11:46, Jan Beulich wrote:
>> On 29.01.16 at 11:21, wrote:
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1086,12 +1086,19 @@ csched_dom_cntl(
>>
On 02/02/16 04:43, Shuai Ruan wrote:
>
>>> I tried booting staging branch but results were identical. Following
>>> line repeats endlessly.
>>> (XEN) traps.c:3290: GPF (): 82d0801c1cce -> 82d080252e5c
>>>
>>> $ 'addr2line -e xen-syms 82d0801c1cce' returns
>>> 'xen/xen/arch/x86/xstat
>>> On 01.02.16 at 18:56, wrote:
> For safety, NULL out the pointers after freeing them, in an attempt to make
> mistakes more obvious in the future.
Except that NULLing isn't really adding that much safety, and we'd
be better off poisoning such pointers. Nevertheless ...
> Signed-off-by: Andrew
Processing commands for x...@bugs.xenproject.org:
> close 48
Closing bug #48
> thanks
Finished processing.
Modified/created Bugs:
- 48: http://bugs.xenproject.org/xen/bug/48
---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on
reporting bugs
On 02/02/16 10:43, Jan Beulich wrote:
On 01.02.16 at 18:56, wrote:
>> For safety, NULL out the pointers after freeing them, in an attempt to make
>> mistakes more obvious in the future.
> Except that NULLing isn't really adding that much safety, and we'd
> be better off poisoning such pointer
>>> On 02.02.16 at 11:48, wrote:
> On 02/02/16 10:43, Jan Beulich wrote:
> On 01.02.16 at 18:56, wrote:
>>> For safety, NULL out the pointers after freeing them, in an attempt to make
>>> mistakes more obvious in the future.
>> Except that NULLing isn't really adding that much safety, and we'
On 02/02/16 10:52, Jan Beulich wrote:
On 02.02.16 at 11:48, wrote:
>> On 02/02/16 10:43, Jan Beulich wrote:
>> On 01.02.16 at 18:56, wrote:
For safety, NULL out the pointers after freeing them, in an attempt to make
mistakes more obvious in the future.
>>> Except that NULLing i
On 2/2/2016 6:32 PM, Jan Beulich wrote:
On 01.02.16 at 18:05, wrote:
Having said that, if the hypervisor maintainers are happy with a
situation where this value is configured explicitly, and the
configurations where a non-default value is required is expected to be
rare, then I guess we can l
On 02/02/2016 05:33 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Bob Liu [mailto:bob@oracle.com]
>> Sent: 02 February 2016 05:02
>> To: Paul Durrant
>> Cc: xen-de...@lists.xenproject.org
>> Subject: Re: [Xen-devel] [PATCH v7 0/2] public/io/netif.h: support for
>> toeplitz has
On Mon, Feb 01, 2016 at 02:40:53PM +, Paul Durrant wrote:
[...]
> +static int xen_register_mcast_ctrl_watch(struct xenbus_device *dev,
> + struct xenvif *vif)
> +{
> + int err = 0;
> + char *node;
> + unsigned maxlen = strlen(dev->otherend) +
> +
On 02/02/16 03:44, Haozhong Zhang wrote:
> On 02/01/16 18:25, Andrew Cooper wrote:
>> On 01/02/16 05:44, Haozhong Zhang wrote:
>>> Hi,
>>>
>>> The following document describes the design of adding vNVDIMM support
>>> for Xen. Any comments are welcome.
>>>
>>> Thanks,
>>> Haozhong
>> Thankyou for do
>>> On 02.02.16 at 11:56, wrote:
> I understand your concern, and to be honest, I do not think
> this is an optimal solution. But I also have no better idea
> in mind. :(
> Another option may be: instead of opening this parameter to
> the tool stack, we use a XenGT flag, which set the rangeset
>
On Mon, Feb 01, 2016 at 10:00:56AM -0800, Andy Lutomirski wrote:
> This leaves vring_new_virtqueue alone for compatbility, but it
> adds two new improved APIs:
>
> vring_create_virtqueue: Creates a virtqueue backed by automatically
> allocated coherent memory. (Some day it this could be extended
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 02 February 2016 11:09
> To: Paul Durrant
> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org; Ian Campbell;
> Wei Liu
> Subject: Re: [PATCH net-next v1] xen-netback: implement dynamic multicast
> control
>
When the timeslice of Xen's credit scheduler is changed via tools the
domain weights are no longer honored correctly.
Changes in V2:
- moved locking to csched_sys_cntl() as suggested by Jan
- split up into two patches as requested by Dario
Juergen Gross (2):
xen: update timeslice under lock
x
When updating the timeslice of the credit scheduler protect the
scheduler's private data by it's lock. Today a possible race could
result only in some weird scheduling decisions during one timeslice,
but further adjustments will need the lock anyway.
Signed-off-by: Juergen Gross
---
xen/common/s
When modifying the timeslice of the credit scheduler in a cpupool the
cpupool global credit value (n_cpus * credits_per_tslice) isn't
recalculated. This will lead to wrong scheduling decisions later.
Do the recalculation when updating the timeslice.
Signed-off-by: Juergen Gross
Tested-by: Alan.R
On 02/02/16 10:32, Jan Beulich wrote:
On 01.02.16 at 18:05, wrote:
>> Having said that, if the hypervisor maintainers are happy with a
>> situation where this value is configured explicitly, and the
>> configurations where a non-default value is required is expected to be
>> rare, then I gues
flight 79817 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
On Tue, 2016-02-02 at 11:35 +0100, Juergen Gross wrote:
> On 02/02/16 10:53, Dario Faggioli wrote:
> >
> > In any case, since the lack of locking and lack of recalculation
> > look
> > like two pretty independent existing bugs to me, can we have
> > either:
> > a. two patches;
> > b. one patch b
From: Roger Pau Monne
Due to the HVMlite changes there's a chance that the value in rc is checked
without being initialised. Fix this by initialising it to 0.
Signed-off-by: Roger Pau Monné
Reported-by: Olaf Hering
---
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxc/xc_dom_x86
My recent patch to the Xen Project documents a protocol for 'dynamic
multicast control' in netif.h. This extends the previous multicast control
protocol to not require a shared ring reconnection to turn the feature off.
Instead the backend watches the "request-multicast-control" key in xenstore
and
On 2/2/2016 12:52 PM, Jan Beulich wrote:
NULLing the pointers would cause things like rtc_deinit() to always blow
up when it followed the NULL pointer.
IMO, we should unconditionally always NULL pointers when freeing a
pointer which isn't in local scope. It would make issues such as these
compl
On 29/01/16 18:20, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Doug Goldstein
> CC: Tim Deegan
> CC: George Dunlap
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.o
>>> On 02.02.16 at 12:31, wrote:
> This specific issue concerns resource allocation during domain building
> and is an area which can never ever be given to a less privileged entity.
Which is because of ...? (And if so, why would we have put
XEN_DOMCTL_createdomain on the XSA-77 waiver list?)
Ja
On Thu, 2016-01-28 at 22:27 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 28, 2016 at 03:10:57PM +, Dario Faggioli wrote:
> >
> > So, may I ask what piece of (Linux) code are we actually talking
> > about?
> > Because I had a quick look, and could not find where what you
> > describe
> > h
>>> On 02.02.16 at 12:39, wrote:
> On 2/2/2016 12:52 PM, Jan Beulich wrote:
>>> NULLing the pointers would cause things like rtc_deinit() to always blow
>>> up when it followed the NULL pointer.
>>>
>>> IMO, we should unconditionally always NULL pointers when freeing a
>>> pointer which isn't in l
On Tue, Feb 02, 2016 at 11:31:08AM +, Paul Durrant wrote:
[...]
> +static int xen_register_mcast_ctrl_watch(struct xenbus_device *dev,
> + struct xenvif *vif)
> +{
> + int err = 0;
> + char *node;
> + unsigned maxlen = strlen(dev->otherend) +
> +
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 02 February 2016 11:47
> To: Paul Durrant
> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org; Ian Campbell;
> Wei Liu
> Subject: Re: [PATCH net-next v2] xen-netback: implement dynamic multicast
> control
>
On Tue, 2016-02-02 at 06:42 +, Tian, Kevin wrote:
> > From: Kay, Allen M
> > Sent: Tuesday, February 02, 2016 8:04 AM
> > >
> > > David notes in the latter commit above:
> > >
> > > "We should be able to successfully assign graphics devices to guests too,
> > > as
> > > long as the initial h
On Tue, Feb 02, 2016 at 04:04:14PM +0800, Yu, Zhang wrote:
> Thanks for your reply, Ian.
>
> On 2/2/2016 1:05 AM, Ian Jackson wrote:
> >Yu, Zhang writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
> >max_wp_ram_ranges."):
> >>On 2/2/2016 12:35 AM, Jan Beulich wrote:
> >>>On 01.02.
On Tue, 2016-02-02 at 11:48 +, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 02 February 2016 11:47
> > To: Paul Durrant
> > Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org; Ian
> > Campbell;
> > Wei Liu
> > Subject: Re: [
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 02 February 2016 11:54
> To: Paul Durrant; Wei Liu
> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org
> Subject: Re: [PATCH net-next v2] xen-netback: implement dynamic multicast
> control
>
> On Tu
On Fri, 2016-01-29 at 16:59 -0500, Elena Ufimtseva wrote:
>
> Hey Dario
>
> Please disregard the previous email with topology information.
> It was incorrect and I am attaching the topology that is actually
> result
> of Joao smt patches application.
>
Ok :-)
Well, this:
...
physical id :
My recent patch to the Xen Project documents a protocol for 'dynamic
multicast control' in netif.h. This extends the previous multicast control
protocol to not require a shared ring reconnection to turn the feature off.
Instead the backend watches the "request-multicast-control" key in xenstore
and
On Tue, Feb 02, 2016 at 11:55:05AM +, Paul Durrant wrote:
> My recent patch to the Xen Project documents a protocol for 'dynamic
> multicast control' in netif.h. This extends the previous multicast control
> protocol to not require a shared ring reconnection to turn the feature off.
> Instead t
On 02/02/16 11:39, Corneliu ZUZU wrote:
> On 2/2/2016 12:52 PM, Jan Beulich wrote:
>>> NULLing the pointers would cause things like rtc_deinit() to always
>>> blow
>>> up when it followed the NULL pointer.
>>>
>>> IMO, we should unconditionally always NULL pointers when freeing a
>>> pointer which
On 02/02/2016 01:23 AM, Jim Fehlig wrote:
> On 01/20/2016 12:00 PM, Joao Martins wrote:
>> . From libxlMigrationBegin to libxlDomainMigrateBegin3Params().
>> This is a preparatory patch to be able to begin a job in the
>> perform phase.
>>
>> Signed-off-by: Joao Martins
>> ---
>> src/libxl/libx
On Tue, 2016-02-02 at 12:29 +0100, Juergen Gross wrote:
> When the timeslice of Xen's credit scheduler is changed via tools the
> domain weights are no longer honored correctly.
>
> Changes in V2:
> - moved locking to csched_sys_cntl() as suggested by Jan
> - split up into two patches as requested
On Tue, Feb 02, 2016 at 12:33:20PM +0100, Roger Pau Monne wrote:
> From: Roger Pau Monne
>
> Due to the HVMlite changes there's a chance that the value in rc is checked
> without being initialised. Fix this by initialising it to 0.
>
> Signed-off-by: Roger Pau Monné
> Reported-by: Olaf Hering
All,
while looking into some of the DEBUG_WX issues I came across
aforementioned function and started wondering how pv-ops gets
away without the unmapping XenoLinux has always been doing
(in free_init_pages()). Inspecting
/sys/kernel/debug/kernel_page_tables, I indeed see the area
mapped (and even
On 2/2/2016 2:05 PM, Andrew Cooper wrote:
Xen and PV guests share the virtual address space, in exactly the same
way as a native kernel and its userspace. PV guests can map pages at
0. Therefore, if Xen were to accidentally follow a NULL pointer, it
may not result in a pagefault. (Hardware mech
> This is a -EBUSY. Is there anything magic about mfn 188d903? It just looks
> like plain RAM in the E820 table.
> Have you got dom0 configured to use linear p2m mode? Without it, dom0 can
> only have a maximum of 512GB of RAM.
> ~Andrew
No special configuration for dom0, actually, the ser
This platform is no longer actively used, but it makes GICv2 development
harder.
Signed-off-by: Zoltan Kiss
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 7c1bf82..12f147c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -177,11 +177,6 @@ S: Supported
F: xen/arch/x86/debug.c
F: tools/deb
> >> We found dom0 will crash when booing on HSW-EX server, the dom0
> >> kernel version is v4.4. By debugging I found the your patch '
> >> x86/xen: discard RAM regions above the maximum reservation' , which
> the commit ID is : f5775e0b6116b7e2425ccf535243b21 caused the regression.
> The debug me
>>> On 01.02.16 at 16:00, wrote:
> On 01/02/16 09:14, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -899,48 +899,64 @@ void p2m_change_type_range(struct domain
>> p2m_unlock(p2m);
>> }
>>
>> -/* Returns: 0 for success, -errno for failure */
>> +/*
>
On 02/02/16 12:44, Jan Beulich wrote:
> All,
>
> while looking into some of the DEBUG_WX issues I came across
> aforementioned function and started wondering how pv-ops gets
> away without the unmapping XenoLinux has always been doing
> (in free_init_pages()).
Um. I'm not sure why you think some
On 02/02/16 13:15, Li, Liang Z wrote:
We found dom0 will crash when booing on HSW-EX server, the dom0
kernel version is v4.4. By debugging I found the your patch '
x86/xen: discard RAM regions above the maximum reservation' , which
>> the commit ID is : f5775e0b6116b7e2425ccf535243b2
On 2/2/2016 7:51 PM, Wei Liu wrote:
On Tue, Feb 02, 2016 at 04:04:14PM +0800, Yu, Zhang wrote:
Thanks for your reply, Ian.
On 2/2/2016 1:05 AM, Ian Jackson wrote:
Yu, Zhang writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
max_wp_ram_ranges."):
On 2/2/2016 12:35 AM, Jan Be
>>> On 01.02.16 at 18:31, wrote:
> On 01/02/16 16:51, Jan Beulich wrote:
> On 01.02.16 at 17:34, wrote:
>>> On 01/02/16 16:28, Jan Beulich wrote:
>>> On 01.02.16 at 15:07, wrote:
> On 01/02/16 13:20, Jan Beulich wrote:
>> Ping? (I'd really like to get this resolved, so we don't n
On Wed, 2016-01-27 at 12:05 +, Ian Campbell wrote:
> On Wed, 2016-01-27 at 11:18 +, Ian Campbell wrote:
> > On Tue, 2016-01-26 at 13:11 +, osstest service owner wrote:
> > > flight 79008 linux-4.1 real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/79008/
> > >
> > > Reg
>>> On 02.02.16 at 14:30, wrote:
> On 02/02/16 12:44, Jan Beulich wrote:
>> All,
>>
>> while looking into some of the DEBUG_WX issues I came across
>> aforementioned function and started wondering how pv-ops gets
>> away without the unmapping XenoLinux has always been doing
>> (in free_init_pages
On 2/2/2016 7:12 PM, Jan Beulich wrote:
On 02.02.16 at 11:56, wrote:
I understand your concern, and to be honest, I do not think
this is an optimal solution. But I also have no better idea
in mind. :(
Another option may be: instead of opening this parameter to
the tool stack, we use a XenGT
On 02/02/16 11:43, Jan Beulich wrote:
On 02.02.16 at 12:31, wrote:
>> This specific issue concerns resource allocation during domain building
>> and is an area which can never ever be given to a less privileged entity.
> Which is because of ...? (And if so, why would we have put
> XEN_DOMCTL_
On 02/02/16 13:24, Jan Beulich wrote:
On 01.02.16 at 16:00, wrote:
>> On 01/02/16 09:14, Jan Beulich wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -899,48 +899,64 @@ void p2m_change_type_range(struct domain
>>> p2m_unlock(p2m);
>>> }
>>>
>>> -/* Returns
On Tue, 2016-02-02 at 00:04 +, Kay, Allen M wrote:
>
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Sunday, January 31, 2016 9:42 AM
> > To: Kay, Allen M; Gerd Hoffmann; David Woodhouse
> > Cc: igv...@ml01.01.org; xen-de...@lists.xensourc
I followed this guide:
http://ssup2.iptime.org/wiki/Xen_4.5.0_on_Arndale
to get xen installed on the arndale 5250 with an ubuntu Dom0 and I am
able to create guests without problems. Now I am would like to pass a
device to a guest, as a proof of concept. I choose the ethernet port
because tha
>>> On 02.02.16 at 15:01, wrote:
> On 2/2/2016 7:12 PM, Jan Beulich wrote:
> On 02.02.16 at 11:56, wrote:
>>> I understand your concern, and to be honest, I do not think
>>> this is an optimal solution. But I also have no better idea
>>> in mind. :(
>>> Another option may be: instead of open
>>> On 02.02.16 at 15:33, wrote:
> On 02/02/16 13:24, Jan Beulich wrote:
> On 01.02.16 at 16:00, wrote:
>>> On 01/02/16 09:14, Jan Beulich wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -899,48 +899,64 @@ void p2m_change_type_range(struct domain
p2m
On Tue, 2016-02-02 at 11:50 +, David Woodhouse wrote:
> On Tue, 2016-02-02 at 06:42 +, Tian, Kevin wrote:
> > > From: Kay, Allen M
> > > Sent: Tuesday, February 02, 2016 8:04 AM
> > > >
> > > > David notes in the latter commit above:
> > > >
> > > > "We should be able to successfully assi
On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
> I would like to hear the community's opinion on supporting more qdisk types in
> xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk
> types
> in libxl over apps like xl or libvirt doing all the setup, producing a
On Tue, 2016-02-02 at 07:54 -0700, Alex Williamson wrote:
>
> I first glance I like it, but there's a problem, it assumes there is a
> host driver for the device that will permanently release the device from
> the RMRR even after the device is unbound. Currently we don't have a
> requirement that
On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
> v4 is meant for discussion on the addition of replq.
>
In which cases, you should always put something like RFC in the
subject, so people knows what the intent is even by just skimming their
inboxes.
> Changes since v3:
> removed run
On 2/2/2016 10:42 PM, Jan Beulich wrote:
On 02.02.16 at 15:01, wrote:
On 2/2/2016 7:12 PM, Jan Beulich wrote:
On 02.02.16 at 11:56, wrote:
I understand your concern, and to be honest, I do not think
this is an optimal solution. But I also have no better idea
in mind. :(
Another option may
On 02/02/16 14:10, Jan Beulich wrote:
On 02.02.16 at 14:30, wrote:
>> On 02/02/16 12:44, Jan Beulich wrote:
>>> All,
>>>
>>> while looking into some of the DEBUG_WX issues I came across
>>> aforementioned function and started wondering how pv-ops gets
>>> away without the unmapping XenoLinux
On Mon, 1 Feb 2016 10:00:53 -0800
Andy Lutomirski wrote:
> From: Christian Borntraeger
>
> As virtio-ccw will have dma ops, we can no longer default to the
> zPCI ones. Make use of dev_archdata to keep the dma_ops per device.
> The pci devices now use that to override the default, and the
> de
This went unnoticed until a backport of this to an older Xen got used,
causing migration of guests enabling this VM assist to fail, because
page table pinning there precedes vCPU context loading, and hence L4
tables get initialized for the wrong mode. Fix this by post-processing
L4 tables when sett
When mapping large BARs (e.g. the frame buffer of a graphics card) the
overhead of establishing such mappings using only 4k pages has,
particularly after the XSA-125 fix, become unacceptable. Alter the
XEN_DOMCTL_memory_mapping semantics once again, so that there's no
longer a fixed amount of guest
On Tue, 2016-02-02 at 08:37 -0600, xen sandberg wrote:
> I followed this guide:
>
> http://ssup2.iptime.org/wiki/Xen_4.5.0_on_Arndale
>
> to get xen installed on the arndale 5250 with an ubuntu Dom0 and I am
> able to create guests without problems.
Did you install something newer than 4.5.0?
On 02/02/16 15:14, Jan Beulich wrote:
> This went unnoticed until a backport of this to an older Xen got used,
> causing migration of guests enabling this VM assist to fail, because
> page table pinning there precedes vCPU context loading, and hence L4
> tables get initialized for the wrong mode. F
>>> On 02.02.16 at 16:00, wrote:
> The limit of 4G is to avoid the data missing from uint64 to uint32
> assignment. And I can accept the 8K limit for XenGT in practice.
> After all, it is vGPU page tables we are trying to trap and emulate,
> not normal page frames.
>
> And I guess the reason that
On 2/2/2016 11:21 PM, Jan Beulich wrote:
On 02.02.16 at 16:00, wrote:
The limit of 4G is to avoid the data missing from uint64 to uint32
assignment. And I can accept the 8K limit for XenGT in practice.
After all, it is vGPU page tables we are trying to trap and emulate,
not normal page frames
On 02/02/16 15:15, Jan Beulich wrote:
> @@ -2095,6 +2131,30 @@ void *map_domain_gfn(struct p2m_domain *
> return map_domain_page(*mfn);
> }
>
> +static unsigned int mmio_order(const struct domain *d,
> + unsigned long start_fn, unsigned long nr)
> +{
> +if
flight 79891 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79891/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 79451
build-i386-libvirt
On 02/01/2016 06:49 PM, Brendan Gregg wrote:
On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky
mailto:boris.ostrov...@oracle.com>> wrote:
Current PVH implementation has never been described as
production-ready. What is happening now with HVMlite is
essentially bringing PVH to pro
Joao Martins wrote:
>
> On 02/02/2016 01:23 AM, Jim Fehlig wrote:
>> On 01/20/2016 12:00 PM, Joao Martins wrote:
>>> . From libxlMigrationBegin to libxlDomainMigrateBegin3Params().
>>> This is a preparatory patch to be able to begin a job in the
>>> perform phase.
>>>
>>> Signed-off-by: Joao Marti
>>> On 02.02.16 at 16:27, wrote:
> On 02/02/16 15:15, Jan Beulich wrote:
>> @@ -2095,6 +2131,30 @@ void *map_domain_gfn(struct p2m_domain *
>> return map_domain_page(*mfn);
>> }
>>
>> +static unsigned int mmio_order(const struct domain *d,
>> + unsigned long s
flight 79875 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79875/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 65543
test-amd64-i386-
flight 79852 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79852/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-qemuu-nested-
>>> On 01.02.16 at 15:54, wrote:
> This looks very much like it needs backport of 33c19df9a ("x86/PCI:
> intercept accesses to RO MMIO from dom0s in HVM containers") from
> unstable, which fixes PVH regression introduced by 9256f66c1606
> ("x86/PCI: intercept all PV Dom0 MMCFG writes")
So woul
flight 79969 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79969/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 79786
Tests which di
1 - 100 of 191 matches
Mail list logo
