Hi all,
I apologize for giving the wrong impression. While I agree that I was
trying to avoid going through the source code. I had previously looked
online and found that that Xen did not support MTRR. I guess that is true.
Anyways, thanks for the feedback. I should be more careful in asking
questi
2015-01-12 9:23 GMT+01:00 Jürgen Groß :
> On 01/11/2015 11:35 PM, Rickard Strandqvist wrote:
>>
>> Remove the function set_pte_mfn() that is not used anywhere.
>>
>> This was partially found by using a static code analysis program called
>> cppcheck.
>
>
> Sorry, you seem not to have checked the ne
> > @devs -- we obviously need to do something about this (too late for 4.5,
> > but for 4.6 + backport). Perhaps there is some alternative systemd
> > construction which disassociates the actual path from the abstract
> > service "xenstored dir mounted"?
>
> I dont think we can do anything about
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Tuesday, January 13, 2015 11:59 PM
>
> On 01/13/2015 03:52 PM, Jan Beulich wrote:
> On 13.01.15 at 13:03, wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Tuesday, January 13, 2015 7:56 PM
> >> On 13
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Wednesday, January 14, 2015 12:46 AM
>
>
> Perhaps an easier way of this is to use the existing
> mechanism we have - that is the XENMEM_memory_map (which
> BTW e820_host uses). If all of this is done in the libxl (which
> alre
>>> On 13.01.15 at 17:35, wrote:
> On Tue, 2015-01-13 at 16:21 +, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/include/public/errno.h
>> @@ -0,0 +1,94 @@
>> +#ifndef __XEN_PUBLIC_ERRNO_H__
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +#define XEN_ERRNO(name, value) XEN_##name = value,
>> +enum xe
>>> On 13.01.15 at 17:40, wrote:
> On 13/01/15 16:21, Jan Beulich wrote:
>> Now that we have two cases where patches against hvmloader got
>> submitted needing to include the hypervisor's errno.h (for the host's
>> system header not necessarily reflecting the correct numbers), take
>> this as a st
>>> On 14.01.15 at 09:06, wrote:
> Now the open is whether we want to fail domain creation for all of above
> conflicts. user may choose to bear with conflicts at his own disposal, or
> libxl doesn't want to fail conflicts as preparation for future
> hotplug/migration.
> One possible option is to
>>> On 14.01.15 at 09:13, wrote:
>> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> Sent: Wednesday, January 14, 2015 12:46 AM
>>
>> Perhaps an easier way of this is to use the existing
>> mechanism we have - that is the XENMEM_memory_map (which
>> BTW e820_host uses). If all of t
>>> On 13.01.15 at 21:43, wrote:
> On 01/13/2015 02:27 PM, Konrad Rzeszutek Wilk wrote:
>> I was wondering if there would be any plans for configure.ac
>> (or the m4 scripts) to have an --enable-xsm which would set
>> XSM_ENABLE (or FLASK_ENABLE) to true?
>>
>> Right now by default to build with X
>>> On 13.01.15 at 12:50, wrote:
> I apologize for giving the wrong impression. While I agree that I was
> trying to avoid going through the source code. I had previously looked
> online and found that that Xen did not support MTRR. I guess that is true.
It's not - neither for Xen's own use of th
>>> On 13.01.15 at 21:30, wrote:
> flight 33394 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33394/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xe
>>> On 13.01.15 at 17:22, <"jgr...@suse.com".non-mime.internet> wrote:
> The locking in scsifront_dev_reset_handler() is obviously wrong. In
> case of a full ring the host lock is aquired twice.
>
> Fixing this issue enables to get rid of the endless fo loop with an
> explicit break statement.
Pe
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 5:00 PM
>
> >>> On 14.01.15 at 09:06, wrote:
> > Now the open is whether we want to fail domain creation for all of above
> > conflicts. user may choose to bear with conflicts at his own disposal, or
> > libxl does
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 5:03 PM
>
> >>> On 14.01.15 at 09:13, wrote:
> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> >> Sent: Wednesday, January 14, 2015 12:46 AM
> >>
> >> Perhaps an easier way of this is to use the e
Hi Ian,
I've got a few OSSTEST series out there which could use some review
attention, I'll list in decreasing order of priority (IMHO, YMMV, etc).
support for ARM32 arndale and cubietruck platforms
v3 at <1416505070.26869.2.ca...@citrix.com>
Needed for new colo deployme
flight 33398 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33398/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Tests which are failin
On Wed, 2015-01-14 at 09:12 +, Jan Beulich wrote:
> >>> On 13.01.15 at 21:30, wrote:
> > flight 33394 xen-4.4-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/33394/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests whi
On Wed, Jan 14, 2015 at 09:46:10AM +, Ian Campbell wrote:
> Hi Ian,
>
> I've got a few OSSTEST series out there which could use some review
> attention, I'll list in decreasing order of priority (IMHO, YMMV, etc).
>
> support for ARM32 arndale and cubietruck platforms
>
> v3 at <1416
>>> On 14.01.15 at 10:43, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 14, 2015 5:00 PM
>>
>> >>> On 14.01.15 at 09:06, wrote:
>> > Now the open is whether we want to fail domain creation for all of above
>> > conflicts. user may choose to bear with conflic
>>> On 14.01.15 at 10:44, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 14, 2015 5:03 PM
>>
>> >>> On 14.01.15 at 09:13, wrote:
>> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> >> Sent: Wednesday, January 14, 2015 12:46 AM
>> >>
>> >> Pe
On Wed, 2015-01-14 at 08:46 +, Jan Beulich wrote:
> >>> On 13.01.15 at 17:35, wrote:
> > On Tue, 2015-01-13 at 16:21 +, Jan Beulich wrote:
> >> --- /dev/null
> >> +++ b/xen/include/public/errno.h
> >> @@ -0,0 +1,94 @@
> >> +#ifndef __XEN_PUBLIC_ERRNO_H__
> >> +
> >> +#ifndef __ASSEMBLY__
>
On Tue, Jan 13, 2015 at 09:00:49PM +, Andrew Cooper wrote:
> On 13/01/15 12:11, Wei Liu wrote:
> > This function gets the machine E820 map and sanitize it according to PV
> > guest configuration.
> >
> > This will be used in later patch. No functional change introduced in
> > this patch.
> >
>
On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich wrote:
Ed White 01/13/15 10:32 PM >>>
>>On 01/13/2015 12:45 PM, Andrew Cooper wrote:
>>> On 13/01/15 20:02, Ed White wrote:
The set of mfn's is the same, but I do allow gfn->mfn mappings to be
modified under certain circumstances. One us
flight 33399 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33399/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 8 guest-startfail REGR. vs. 33112
test-amd64-i386-xl-q
On Wed, 2015-01-14 at 10:19 +, Wei Liu wrote:
> On Wed, Jan 14, 2015 at 09:46:10AM +, Ian Campbell wrote:
> > support for ARM32 arndale and cubietruck platforms
[...]
> > Implement for driving libvirt via virsh
[...]
> > add distro domU testing flight
[...]
> And also my XSM test ser
On 01/14/2015 11:22 AM, Xen patchbot-linux-2.6.18-xen wrote:
# HG changeset patch
# User Juergen Gross
# Date 1421228828 -3600
# Node ID 3015a92b2b53825d00dc81c2dd131fc77ce8ab00
# Parent 078f1bb69ea5e3772f3df4b4ee21f3c52e381e51
scsifront: avoid acquiring same lock twice if ring is full
The loc
All,
while we don't have any changes in the public interface depending on
__XEN_INTERFACE_VERSION__ 0x00040500, shouldn't
we nevertheless update xen-compat.h's
__XEN_LATEST_INTERFACE_VERSION__ for 4.5?
Jan
___
Xen-devel mailing list
Xen-devel@lists.
On Wed, 2015-01-14 at 07:11 +, Jan Beulich wrote:
> >>> Julien Grall 01/13/15 7:17 PM >>>
> >QEMU upstream requires the use of pixman. When pixman is not present the
> >system, the configure of QEMU will fail with:
> >
> >ERROR: pixman not present. Your options:
> >(1) Preferred: Install the p
On Wed, Jan 14, 2015 at 10:33:29AM +, Ian Campbell wrote:
> On Wed, 2015-01-14 at 10:19 +, Wei Liu wrote:
> > On Wed, Jan 14, 2015 at 09:46:10AM +, Ian Campbell wrote:
> > > support for ARM32 arndale and cubietruck platforms
> [...]
> > > Implement for driving libvirt via virsh
>
On Wed, Jan 14, 2015 at 10:39:45AM +, Ian Campbell wrote:
> On Wed, 2015-01-14 at 07:11 +, Jan Beulich wrote:
> > >>> Julien Grall 01/13/15 7:17 PM >>>
> > >QEMU upstream requires the use of pixman. When pixman is not present the
> > >system, the configure of QEMU will fail with:
> > >
> >
Hi Ian,
On 14/01/2015 10:28, Ian Campbell wrote:
(I suppose someone needs to patch libxc et al to actually use this)
The primary consumer, as said in the description, is meant to be
hvmloader. But yes, other tools parts may also want to follow
that.
/me wonders how libxc has been getting awa
>>> On 14.01.15 at 11:33, wrote:
> flight 33399 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33399/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-freebsd10-amd64 8 guest-start
On Tue, Jan 13, 2015 at 08:02:17PM +, Andrew Cooper wrote:
[...]
> > +/* vNUMA information */
> > +unsigned int *vnode_to_pnode; /* vnode to pnode mapping array */
> > +uint64_t *vnode_size; /* vnode size array */
>
> Please make it very clear in the comment here that "size
On 14/01/15 10:53, Wei Liu wrote:
>
>>> +return -EINVAL;
>>> +}
>>> +
>>> /* allocate guest memory */
>>> -for ( i = rc = allocsz = 0;
>>> - (i < dom->total_pages) && !rc;
>>> - i += allocsz )
>>> +pfn_base = 0;
>>> +for
>>> On 14.01.15 at 11:36, wrote:
> On 01/14/2015 11:22 AM, Xen patchbot-linux-2.6.18-xen wrote:
>> @@ -463,7 +461,9 @@ static int scsifront_dev_reset_handler(s
>> spin_unlock_irq(host->host_lock);
>> err = wait_event_interruptible(info->wq_sync,
>>
On Wed, Jan 14, 2015 at 10:58:08AM +, Andrew Cooper wrote:
[...]
> >>> + &dom->p2m_host[pfn_base+j]);
> >>> +
> >>> +if ( rc )
> >>> +{
> >>> +if ( dom->vnode_to_pnode[i] != XC_VNUMA_NO_NODE )
> >>> +
On Tue, 2015-01-13 at 20:07 +, Julien Grall wrote:
> Some platform (such as the VFP Base AEMv8 model) has a memory mapped
> timer. We don't want DOM0 use this timer rather than the generic ARM
> timer. So blacklist it for all platforms.
It seems that these registers contain things like the abi
On Tue, 2015-01-13 at 20:10 +, Julien Grall wrote:
> +int
> +xc_core_arch_get_scratch_gpfn(xc_interface *xch, domid_t domid,
> + xen_pfn_t *gpfn)
> +{
> +/*
> + * The Grant Table region space is not used until the guest is
> + * booting. Use the first p
On Tue, Jan 13, 2015 at 06:15:49PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH v3 08/19] libxl: functions to build vmemranges for PV
> guest"):
> > Introduce a arch-independent routine to generate one vmemrange per
> > vnode. Also introduce arch-dependent routines for different
> > archite
On Wed, Jan 7, 2015 at 11:03 AM, Olaf Hering wrote:
> On Wed, Jan 07, Vitaly Kuznetsov wrote:
>
>> The thing is .. we don't have these pages when kexec is being performed,
>> they are already ballooned out and the hypervisor doesn't have the
>> knowledge of which GFNs should be re-populated. I thi
On 13/01/15 20:51, Wei Liu wrote:
>
>>> +
>>> +vnuma = d->vnuma;
>>> +printk(" %u vnodes, %u vcpus:\n", vnuma->nr_vnodes,
>>> d->max_vcpus);
>>> +for ( i = 0; i < vnuma->nr_vnodes; i++ )
>>> +{
>>> +err = snprintf(keyhandler_scratch, 12, "%3u",
>>> +
>>> On 14.01.15 at 11:31, wrote:
> On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich wrote:
> Ed White 01/13/15 10:32 PM >>>
>>>On 01/13/2015 12:45 PM, Andrew Cooper wrote:
On 13/01/15 20:02, Ed White wrote:
> The set of mfn's is the same, but I do allow gfn->mfn mappings to be
> mod
>>> On 14.01.15 at 11:28, wrote:
> On Wed, 2015-01-14 at 08:46 +, Jan Beulich wrote:
>> >>> On 13.01.15 at 17:35, wrote:
>> > On Tue, 2015-01-13 at 16:21 +, Jan Beulich wrote:
>> >> --- /dev/null
>> >> +++ b/xen/include/public/errno.h
>> >> @@ -0,0 +1,94 @@
>> >> +#ifndef __XEN_PUBLIC_ERR
On 14/01/15 10:52, Jan Beulich wrote:
On 14.01.15 at 11:33, wrote:
>> flight 33399 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/33399/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test
>>> On 14.01.15 at 12:06, wrote:
> May I suggest the following sylistic changes:
>
> 2 vnodes, 20 vcpus:
> 1: pnode 0, vcpus {1-9}
> - 5dc0
> 2: pnode 1, vcpus {10-20}
> 5dc0 - bb00
> 0001 - 00010080
>
> Yo
On Wed, 2015-01-14 at 10:52 +, Julien Grall wrote:
> Hi Ian,
>
> On 14/01/2015 10:28, Ian Campbell wrote:
> >>> (I suppose someone needs to patch libxc et al to actually use this)
> >>
> >> The primary consumer, as said in the description, is meant to be
> >> hvmloader. But yes, other tools pa
On Wed, 2015-01-14 at 11:18 +, Jan Beulich wrote:
> >>> On 14.01.15 at 11:28, wrote:
> > On Wed, 2015-01-14 at 08:46 +, Jan Beulich wrote:
> >> >>> On 13.01.15 at 17:35, wrote:
> >> > On Tue, 2015-01-13 at 16:21 +, Jan Beulich wrote:
> >> >> --- /dev/null
> >> >> +++ b/xen/include/pub
On Wed, Jan 14, 2015 at 12:09 PM, Jan Beulich wrote:
On 14.01.15 at 11:31, wrote:
>> On Wed, Jan 14, 2015 at 8:04 AM, Jan Beulich wrote:
>> Ed White 01/13/15 10:32 PM >>>
On 01/13/2015 12:45 PM, Andrew Cooper wrote:
> On 13/01/15 20:02, Ed White wrote:
>> The set of mfn's i
On Tue, 13 Jan 2015, Luis R. Rodriguez wrote:
> On Mon, Dec 15, 2014 at 02:58:26PM +, Stefano Stabellini wrote:
> > On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez"
> > >
> > > This lets you build a kernel which can support xen dom0
> > > or xen guests by just usin
(CCing Konrad==RM)
On Wed, 2015-01-14 at 10:36 +, Jan Beulich wrote:
> All,
>
> while we don't have any changes in the public interface depending on
> __XEN_INTERFACE_VERSION__ 0x00040500, shouldn't
> we nevertheless update xen-compat.h's
> __XEN_LATEST_INTERFACE_VERSION__ for 4.5?
We proba
On Tue, 13 Jan 2015, Don Slutz wrote:
> On 01/13/15 13:07, Stefano Stabellini wrote:
> > On Mon, 12 Jan 2015, Stefano Stabellini wrote:
> >> On Wed, 3 Dec 2014, Don Slutz wrote:
> >>> From: Stefano Stabellini
> >>>
> >>> Increase maxmem before calling xc_domain_populate_physmap_exact to
> >>> avoi
On Wed, 2015-01-14 at 10:43 +, Wei Liu wrote:
> On Wed, Jan 14, 2015 at 10:39:45AM +, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 07:11 +, Jan Beulich wrote:
> > > >>> Julien Grall 01/13/15 7:17 PM >>>
> > > >QEMU upstream requires the use of pixman. When pixman is not present the
>
On Wed, 14 Jan 2015, Wei Liu wrote:
> On Wed, Jan 14, 2015 at 10:39:45AM +, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 07:11 +, Jan Beulich wrote:
> > > >>> Julien Grall 01/13/15 7:17 PM >>>
> > > >QEMU upstream requires the use of pixman. When pixman is not present the
> > > >system, t
On 14/01/15 11:24, Ian Campbell wrote:
> On Wed, 2015-01-14 at 10:52 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 14/01/2015 10:28, Ian Campbell wrote:
> (I suppose someone needs to patch libxc et al to actually use this)
The primary consumer, as said in the description, is meant to be
>
>>> On 14.01.15 at 12:22, wrote:
> On 14/01/15 10:52, Jan Beulich wrote:
> On 14.01.15 at 11:33, wrote:
>>> flight 33399 xen-unstable real [real]
>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/33399/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> incl
On Wed, 2015-01-14 at 10:30 +, Wei Liu wrote:
> On Tue, Jan 13, 2015 at 09:00:49PM +, Andrew Cooper wrote:
> > On 13/01/15 12:11, Wei Liu wrote:
> > > This function gets the machine E820 map and sanitize it according to PV
> > > guest configuration.
> > >
> > > This will be used in later pa
>>> On 14.01.15 at 12:31, wrote:
> On Wed, 2015-01-14 at 10:36 +, Jan Beulich wrote:
>> while we don't have any changes in the public interface depending on
>> __XEN_INTERFACE_VERSION__ 0x00040500, shouldn't
>> we nevertheless update xen-compat.h's
>> __XEN_LATEST_INTERFACE_VERSION__ for 4.5?
On 14/01/15 11:24, Jan Beulich wrote:
On 14.01.15 at 12:06, wrote:
>> May I suggest the following sylistic changes:
>>
>> 2 vnodes, 20 vcpus:
>> 1: pnode 0, vcpus {1-9}
>> - 5dc0
>> 2: pnode 1, vcpus {10-20}
>> 5dc0 - bb00
>>
On 14/01/15 09:52, Ian Campbell wrote:
> On Wed, 2015-01-14 at 09:12 +, Jan Beulich wrote:
> On 13.01.15 at 21:30, wrote:
>>> flight 33394 xen-4.4-testing real [real]
>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/33394/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed an
On 01/14/2015 10:24 AM, Jan Beulich wrote:
On 14.01.15 at 10:43, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Wednesday, January 14, 2015 5:00 PM
>>>
>> On 14.01.15 at 09:06, wrote:
Now the open is whether we want to fail domain creation for all of above
c
On Wed, Jan 14, 2015 at 11:45:25AM +, Andrew Cooper wrote:
> On 14/01/15 11:24, Jan Beulich wrote:
> On 14.01.15 at 12:06, wrote:
> >> May I suggest the following sylistic changes:
> >>
> >> 2 vnodes, 20 vcpus:
> >> 1: pnode 0, vcpus {1-9}
> >> - 5dc0
>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 6:24 PM
>
> >>> On 14.01.15 at 10:43, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Wednesday, January 14, 2015 5:00 PM
> >>
> >> >>> On 14.01.15 at 09:06, wrote:
> >> > Now the open is whet
On Wed, Jan 14, 2015 at 11:40:42AM +, Ian Campbell wrote:
> On Wed, 2015-01-14 at 10:30 +, Wei Liu wrote:
> > On Tue, Jan 13, 2015 at 09:00:49PM +, Andrew Cooper wrote:
> > > On 13/01/15 12:11, Wei Liu wrote:
> > > > This function gets the machine E820 map and sanitize it according to P
On 14/01/15 11:37, Jan Beulich wrote:
On 14.01.15 at 12:22, wrote:
>> On 14/01/15 10:52, Jan Beulich wrote:
>> On 14.01.15 at 11:33, wrote:
flight 33399 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33399/
Regressions :-(
Tests w
On Wed, Jan 14, Ian Campbell wrote:
> A far more heavy weight (but probably better) solution would be to
> arrange for the clone (and necessary downloads) + submodule configure to
> happen at configure rather than build time. That's a much bigger job
> though and I wouldn't expect anyone to take t
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Wednesday, January 14, 2015 8:02 PM
>
> On 01/14/2015 10:24 AM, Jan Beulich wrote:
> On 14.01.15 at 10:43, wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Wednesday, January 14, 2015 5:00 PM
> >>>
> >>>
On 01/14/2015 10:24 AM, Jan Beulich wrote:
>> for other usages like hotplug/migration:
>> reserved_regions = [ 'host, 0/1', 'start, end, 0/1', 'start, end, 0/1',
>> ...]
>> If 'host' is specified, it implies rmrr_host, besides user can specific
>> explicit ranges according to his detail requ
Hi Jan,
On 14/01/15 07:11, Jan Beulich wrote:
Julien Grall 01/13/15 7:17 PM >>>
>> QEMU upstream requires the use of pixman. When pixman is not present the
>> system, the configure of QEMU will fail with:
>>
>> ERROR: pixman not present. Your options:
>> (1) Preferred: Install the pixman dev
On Wed, 2015-01-14 at 06:52 +, Tian, Kevin wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, January 14, 2015 12:06 AM
> >
> > >>> On 13.01.15 at 17:00, wrote:
> > > Another option I was thinking about: Before assigning a device to a
> > > guest, you have to unplug
On 01/14/2015 09:43 AM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 14, 2015 5:00 PM
>>
> On 14.01.15 at 09:06, wrote:
>>> Now the open is whether we want to fail domain creation for all of above
>>> conflicts. user may choose to bear with con
On Wed, 2015-01-14 at 08:06 +, Tian, Kevin wrote:
> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
> hard conflicts
OOI what is the (estimated) probability of such an RMRR existing which
doesn't already conflict with the real host BIOS?
Host BIOSes are generally large com
On 14/01/15 00:41, Meng Xu wrote:
> Hi,
>
> [Goal]
> I want to investigate the impact of the shared cache on the
> performance of workload in guest domain.
> I also want to partition the shared cache via page coloring mechanism
> so that guest domains can use different cache colors of shared cache
On Wed, 2015-01-14 at 09:43 +, Tian, Kevin wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, January 14, 2015 5:00 PM
> >
> > >>> On 14.01.15 at 09:06, wrote:
> > > Now the open is whether we want to fail domain creation for all of above
> > > conflicts. user may ch
On 01/14/2015 12:14 PM, Ian Campbell wrote:
> On Wed, 2015-01-14 at 06:52 +, Tian, Kevin wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Wednesday, January 14, 2015 12:06 AM
>>>
>> On 13.01.15 at 17:00, wrote:
Another option I was thinking about: Before assigning a d
On Wed, 2015-01-14 at 12:13 +, Julien Grall wrote:
> Hi Jan,
>
> On 14/01/15 07:11, Jan Beulich wrote:
> Julien Grall 01/13/15 7:17 PM >>>
> >> QEMU upstream requires the use of pixman. When pixman is not present the
> >> system, the configure of QEMU will fail with:
> >>
> >> ERROR: pix
On 13/01/15 15:58, Ian Campbell wrote:
> They don't actually have to be, but exposing vgic_allocate_virq to the
> tools would be overkill, so hardcoding is the pragmatic choice.
>
> We could e.g. randomise the PPI in the tools, to stop people making
> assumptions. (If we were feeling mean of cours
On Tue, 2015-01-13 at 20:33 +, Julien Grall wrote:
> Hi Ian,
>
> On 13/01/15 15:55, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 14:43 +, Julien Grall wrote:
> >> This help for guest interrupts debugging. If the vIRQ is not allocate,
> >> this means that nothing is wired to it.
> >
> > S
On 14/01/15 12:24, Ian Campbell wrote:
> On Wed, 2015-01-14 at 12:13 +, Julien Grall wrote:
>> Hi Jan,
>>
>> On 14/01/15 07:11, Jan Beulich wrote:
>> Julien Grall 01/13/15 7:17 PM >>>
QEMU upstream requires the use of pixman. When pixman is not present the
system, the configure o
On 01/14/2015 08:06 AM, Tian, Kevin wrote:
> We discussed earlier there are two reasons that some conflicts may not be
> avoided:
> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
> hard conflicts
> - RMRRs conflicting with lowmem which is low enough then avoiding i
On Wed, 2015-01-14 at 12:24 +, Julien Grall wrote:
> On 13/01/15 15:58, Ian Campbell wrote:
> > They don't actually have to be, but exposing vgic_allocate_virq to the
> > tools would be overkill, so hardcoding is the pragmatic choice.
> >
> > We could e.g. randomise the PPI in the tools, to st
On Wed, 2015-01-14 at 12:28 +, Julien Grall wrote:
> On 14/01/15 12:24, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 12:13 +, Julien Grall wrote:
> >> Hi Jan,
> >>
> >> On 14/01/15 07:11, Jan Beulich wrote:
> >> Julien Grall 01/13/15 7:17 PM >>>
> QEMU upstream requires the use o
On 14/01/15 12:31, Ian Campbell wrote:
> On Wed, 2015-01-14 at 12:28 +, Julien Grall wrote:
>> On 14/01/15 12:24, Ian Campbell wrote:
>>> On Wed, 2015-01-14 at 12:13 +, Julien Grall wrote:
Hi Jan,
On 14/01/15 07:11, Jan Beulich wrote:
Julien Grall 01/13/15 7:17 PM >
On Wed, 2015-01-14 at 12:32 +, Julien Grall wrote:
> On x86, glib seems to be required for seabios
Only for make gtkconfig, I think? (surely the actual BIOS doesn't need
glib!). We won't use that in our own builds I think.
> and ipxe.
Really?
If true then there'd be nothing wrong with
AC_I
On 14/01/15 12:38, Ian Campbell wrote:
> On Wed, 2015-01-14 at 12:32 +, Julien Grall wrote:
>> On x86, glib seems to be required for seabios
>
> Only for make gtkconfig, I think? (surely the actual BIOS doesn't need
> glib!). We won't use that in our own builds I think.
Ok.
>
>> and ipxe.
On 14/01/15 12:28, Ian Campbell wrote:
> On Tue, 2015-01-13 at 20:33 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 13/01/15 15:55, Ian Campbell wrote:
>>> On Fri, 2014-12-12 at 14:43 +, Julien Grall wrote:
This help for guest interrupts debugging. If the vIRQ is not allocate,
this me
[ BTW, Konrad, could you do a bit of quote trimming when quoting such a
long e-mail? It takes a non-trivial amount of time to figure out where
you've actually said something. Thanks. :-) ]
On 01/13/2015 04:45 PM, Konrad Rzeszutek Wilk wrote:
>> STEP-1. domain builder
>>
>> say the default layout
Minor updates to the documentation in xen/include/public/arch-arm.h:
- Comments coding style fix
- Typoes
- Update the list of supported hypercalls by ARM
- Remove uncessary comment about 64bit.
Signed-off-by: Julien Grall
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
---
On 13/01/15 20:10, Julien Grall wrote:
> The code to initialize the grant table in libxc uses
> xc_domain_maximum_gpfn() + 1 to get a guest pfn for mapping the grant
> frame and to initialize it.
>
> This solution has two major issues:
> - The check of the return of xc_domain_maximum_gpfn is bu
If we fail to give the access, the domain will unlikely work correctly.
So we should bail out at the first error.
Signed-off-by: Julien Grall
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
(Based on commit 7070eec417934360bf3aed434191246dfe4f8091)
---
The original patch
On 14/01/15 12:58, Andrew Cooper wrote:
> On 13/01/15 20:10, Julien Grall wrote:
>> The code to initialize the grant table in libxc uses
>> xc_domain_maximum_gpfn() + 1 to get a guest pfn for mapping the grant
>> frame and to initialize it.
>>
>> This solution has two major issues:
>> - The che
On 14/01/15 13:20, Julien Grall wrote:
> On 14/01/15 12:58, Andrew Cooper wrote:
>> On 13/01/15 20:10, Julien Grall wrote:
>>> The code to initialize the grant table in libxc uses
>>> xc_domain_maximum_gpfn() + 1 to get a guest pfn for mapping the grant
>>> frame and to initialize it.
>>>
>>> This
On 14/01/15 13:23, Andrew Cooper wrote:
> On 14/01/15 13:20, Julien Grall wrote:
>> On 14/01/15 12:58, Andrew Cooper wrote:
>>> On 13/01/15 20:10, Julien Grall wrote:
The code to initialize the grant table in libxc uses
xc_domain_maximum_gpfn() + 1 to get a guest pfn for mapping the grant
flight 33404 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33404/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 guest-start
On Wed, 2015-01-14 at 13:23 +, Andrew Cooper wrote:
> > ARM is defining a grant table range which is out of the RAM and not
> > mapped at that time. So we can reuse it with any possible issue.
>
> Do you mean to say that there is a grant table range baked into the ABI
> occupying guest physica
Hi Ian,
On 14/01/15 11:03, Ian Campbell wrote:
>> +int
>> +xc_core_arch_get_scratch_gpfn(xc_interface *xch, domid_t domid,
>> + xen_pfn_t *gpfn)
>> +{
>> +int rc;
>> +
>> +rc = xc_domain_maximum_gpfn(xch, domid);
>> +
>> +if ( rc <= 0 )
>> +return r
On 14/01/15 13:31, Ian Campbell wrote:
> On Wed, 2015-01-14 at 13:23 +, Andrew Cooper wrote:
>>> ARM is defining a grant table range which is out of the RAM and not
>>> mapped at that time. So we can reuse it with any possible issue.
>> Do you mean to say that there is a grant table range baked
Otherwise continue without it, which is preferable to the current
infinite hang.
Slightly tweak the grammar of a comment in the same function.
Signed-off-by: Ian Campbell
---
xen/arch/arm/smpboot.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a
Hi Gerry / David / Konrad,
Some more testing uncovered another issue under Xen, this time with
PCI-passthrough.
I have bisected it to the following commit:
cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 "x86, irq: Keep balance of IOAPIC pin
reference count"
It causes these symptoms:
- On Intel
-
On 01/13/2015 11:33 AM, Boris Ostrovsky wrote:
On 01/13/2015 11:17 AM, Boris Ostrovsky wrote:
On 01/13/2015 11:07 AM, David Vrabel wrote:
On 13/01/15 15:42, Boris Ostrovsky wrote:
On 01/13/2015 04:52 AM, David Vrabel wrote:
On 13/01/15 08:14, Imre Palik wrote:
From: "Palik, Imre"
In Dom0's
1 - 100 of 185 matches
Mail list logo
