On Thu, Jan 15, Wen Congyang wrote:
> Commit 1166ecf7 disables optimization. But python's build
> process may use CFLAGS -Wp,-D_FORTIFY_SOURCE=2, and suppose
> the 3rd party python modules to use. The macro _FORTIFY_SOURCE
> requires compiling with optimization (-O). Disable _FORTIFY_SOURCE
> by a
flight 33416 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail REGR. vs. 33401
version targeted for
Commit 1166ecf7 disables optimization. But python's build
process may use CFLAGS -Wp,-D_FORTIFY_SOURCE=2, and suppose
the 3rd party python modules to use. The macro _FORTIFY_SOURCE
requires compiling with optimization (-O). Disable _FORTIFY_SOURCE
by appending -Wp,-U_FORTIFY_SOURCE to CFLAGS.
Sign
On 01/13/2015 07:30 PM, Ian Campbell wrote:
> On Tue, 2015-01-13 at 19:17 +0800, Wen Congyang wrote:
>> On 01/13/2015 06:11 PM, Ian Campbell wrote:
>>> On Tue, 2015-01-13 at 13:52 +0800, Wen Congyang wrote:
On 12/01/2014 10:21 PM, Euan Harris wrote:
> Tools debug builds are built with opti
Hi Maintainers,
We are facing issue collecting coredump using the xm dump mechanism in
Dom0.
We face couple of such issues daily, where the VMs panic s and the SA
team is supposed to collect the core.
The actual problem is that where the VMs are having huge RAM like 32+ GB
RAMs dumping the cor
flight 33408 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail REGR. vs. 33377
test-amd64-amd64-xl-qe
2015-01-14 11:29 GMT-05:00 Jan Beulich :
On 14.01.15 at 16:27, wrote:
>> 2015-01-14 10:02 GMT-05:00 Jan Beulich :
>> On 14.01.15 at 15:45, wrote:
Yes. I try to use the bits [A16, A12] to isolate different colors in a
shared cache. A 2MB 16-way associate shared cache uses [A16,
On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin 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
On Mon, Jan 12, 2015 at 12:12:50PM +, Ian Campbell wrote:
> On Fri, 2015-01-09 at 15:27 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote:
> > > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote:
> > > On 08.01.15 at 16:59, wrote:
> > >
flight 33407 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33407/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 7 windows-installfail REGR. vs. 33379
Regressions which
From: "Luis R. Rodriguez"
We'll be adding options for xen as well.
Cc: Josh Triplett
Cc: Borislav Petkov
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Michal Marek
Cc: Randy Dunlap
Cc: penb...@kernel.org
Cc: levinsasha...@gmail.com
Cc: mtosa...@redhat.com
Cc: fengguang...@intel.com
Cc: David Vra
From: "Luis R. Rodriguez"
This v3 addresses Stefano's feedback from the v2 series, namely
moving PCI stuff to x86 as its all x86 specific and also just
removing the CONFIG_TCG_XEN=m from the general config. To be
clear the changes from the v2 series are below.
Luis R. Rodriguez (2):
x86, platf
From: "Luis R. Rodriguez"
This lets you build a kernel which can support xen dom0
or xen guests by just using:
make xenconfig
on both x86 and arm64 kernels. This also splits out the
options which are available currently to be built with x86
and 'make ARCH=arm64' under a shared config.
Techn
flight 33406 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33406/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 32879
test-amd64-i386-freebsd10-amd6
On Tue, Jan 13, 2015 at 08:44:29PM +, Wei Liu wrote:
> On Tue, Jan 13, 2015 at 01:15:21PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 13, 2015 at 12:11:43PM +, Wei Liu wrote:
> > > The algorithm is more or less the same as the one used for PV guest.
> > > Libxc gets hold of the mapp
On Wed, Jan 14, 2015 at 11:43:31AM +, Jan Beulich wrote:
> >>> 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 neverthe
On Wed, Jan 14, 2015 at 09:06:37AM +, Jan Beulich wrote:
> >>> 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_ENABL
On Wed, Jan 14, 2015 at 11:29:41AM +, Stefano Stabellini wrote:
> 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 let
On 01/14/2015 02:47 PM, Jan Beulich wrote:
On 14.01.15 at 15:37, wrote:
>> On 01/14/2015 02:32 PM, Jan Beulich wrote:
>> On 14.01.15 at 13:01, wrote:
On 01/14/2015 10:24 AM, Jan Beulich wrote:
On 14.01.15 at 10:43, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.co
On 01/14/2015 02:42 PM, Jan Beulich wrote:
On 14.01.15 at 13:29, wrote:
>> 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
>>> har
On 01/14/2015 02:39 PM, Jan Beulich wrote:
On 14.01.15 at 13:16, wrote:
>> On 01/14/2015 09:43 AM, Tian, Kevin 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 r
On 01/14/2015 03:43 PM, Ian Campbell wrote:
> On Wed, 2015-01-14 at 15:39 +, George Dunlap wrote:
>> On 01/14/2015 03:18 PM, Ian Campbell wrote:
> Host BIOSes are generally large compared to the guest BIOS, but with the
> amount of decompression and relocation etc they do I don't know h
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.
Signed-off-by: Julien Grall
---
This patch is candidate to backport for Xen 4.5 and Xen 4.4.
It may not app
Hi Ian,
On 14/01/15 16:16, Ian Campbell wrote:
> As well as the existing common perf counters add a bunch of ARM
> specifics, including the various trap types, vuart/vgic/vtimer
> accesses and different types of interrupt.
>
> Adjust the common code so that the columns line up again, not sure
> w
On 01/14/2015 03:28 AM, Tamas K Lengyel wrote:
> 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
On Wed, Jan 14, 2015 at 02:49:17PM +, Jan Beulich wrote:
> >>> On 14.01.15 at 12:45, 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}
> >>>
Ian Campbell writes ("Re: [PATCH OSSTEST v2 08/18] Toolstack: Refactor guest
lifecycle."):
> On Tue, 2014-12-02 at 16:04 +, Ian Campbell wrote:
> > +sub create ($$) {
> > +my ($self,$cfg) = @_;
> > +my $ho = $self->{Host};
> > +my $lcfg = $cfg;
> > +$lcfg =~ s,/,-,g;
> > +$
Ian Campbell writes ("Re: [PATCH] libxl: provide xenlight.pc"):
> On Fri, 2015-01-09 at 14:32 +, Wei Liu wrote:
> > A pkg-config file for libxl. It also contains two variables
> > (xenfirmwaredir and libexec_bin) so that tools that are very keen on
> > knowing the locations of Xen binaries (say
[stuff]
Thanks to both of you for that helpful summary. I will try to find
some time for reviewing these.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Dario Faggioli writes ("Re: [OSSTEST PATCH] make-flight: reorganize scheduling
related test jobs"):
> On Mon, 2015-01-12 at 16:52 +, Ian Jackson wrote:
> > This looks plausible but can you include the output of a diff between
> > the two sets of runvars, please ?
...
> I will put down here a d
Changing param varibales in sched_credit2.c as static where required.
Signed-off-by: Uma Sharma
---
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 1ca521b..9dd8e84 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -163,7 +163,7 @@
#define CS
Hi Ian,
On 14/01/15 16:33, Ian Campbell wrote:
> On Thu, 2014-09-11 at 09:43 +0100, Ian Campbell wrote:
>> On Wed, 2014-09-10 at 11:54 -0700, Julien Grall wrote:
>>> Hi Ian,
>>>
>>> On 10/09/14 02:46, Ian Campbell wrote:
On Tue, 2014-09-09 at 16:31 -0700, Julien Grall wrote:
> Hi Ian,
>>>
Ian Campbell writes ("[PATCH v1 1/2] tools: unhook blktap1 from the build and
remove all references to it"):
> This was disabled by default in Xen 4.4. Since xend has now been
> removed from the tree I don't believe anything is using it.
>
> We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xe
Eric Blake wrote:
> On 01/14/2015 08:50 AM, Jim Fehlig wrote:
>
>> V5 of xen-xl parser. V4 was close
>>
>> https://www.redhat.com/archives/libvir-list/2015-January/msg00429.html
>>
>> but the tests did not exersice the spice parsing/formatting code. It is
>> now fixed in V5, along with address
On Thu, 2014-09-11 at 09:43 +0100, Ian Campbell wrote:
> On Wed, 2014-09-10 at 11:54 -0700, Julien Grall wrote:
> > Hi Ian,
> >
> > On 10/09/14 02:46, Ian Campbell wrote:
> > > On Tue, 2014-09-09 at 16:31 -0700, Julien Grall wrote:
> > >> Hi Ian,
> > >>
> > >> On 09/09/14 09:23, Ian Campbell wrote
On 14/01/15 16:22, Boris Ostrovsky wrote:
> On 01/14/2015 11:00 AM, David Vrabel wrote:
>> On 14/01/15 15:47, Boris Ostrovsky wrote:
+static void xen_blkbk_unmap_and_respond_callback(int result, struct
gntab_unmap_queue_data *data)
+{
+struct pending_req* pending_req = (s
>>> On 14.01.15 at 16:27, wrote:
> 2015-01-14 10:02 GMT-05:00 Jan Beulich :
> On 14.01.15 at 15:45, wrote:
>>> Yes. I try to use the bits [A16, A12] to isolate different colors in a
>>> shared cache. A 2MB 16-way associate shared cache uses [A16, A6] to
>>> index the cache set. Because page s
>>> On 14.01.15 at 16:39, wrote:
> On 01/14/2015 03:18 PM, Ian Campbell wrote:
Host BIOSes are generally large compared to the guest BIOS, but with the
amount of decompression and relocation etc they do I don't know how much
of them generally remains in the <1MB region.
>>>
>>> Reca
As well as the existing common perf counters add a bunch of ARM
specifics, including the various trap types, vuart/vgic/vtimer
accesses and different types of interrupt.
Adjust the common code so that the columns line up again, not sure
when/where this went wrong.
This is mostly the set of stuff
On 01/14/2015 11:00 AM, David Vrabel wrote:
On 14/01/15 15:47, Boris Ostrovsky wrote:
+static void xen_blkbk_unmap_and_respond_callback(int result, struct
gntab_unmap_queue_data *data)
+{
+struct pending_req* pending_req = (struct pending_req*)
(data->data);
+struct xen_blkif *blkif =
On Wed, 2015-01-14 at 16:03 +, Julien Grall wrote:
> Hi Ian,
>
> On 14/01/15 11:02, Ian Campbell wrote:
> > 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
On 01/14/2015 08:50 AM, Jim Fehlig wrote:
> V5 of xen-xl parser. V4 was close
>
> https://www.redhat.com/archives/libvir-list/2015-January/msg00429.html
>
> but the tests did not exersice the spice parsing/formatting code. It is
> now fixed in V5, along with addressing a few V4 comments from eb
Hi Ian,
On 14/01/15 11:02, Ian Campbell wrote:
> 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.
>
>
On 14/01/15 15:47, Boris Ostrovsky wrote:
>
>> +static void xen_blkbk_unmap_and_respond_callback(int result, struct
>> gntab_unmap_queue_data *data)
>> +{
>> +struct pending_req* pending_req = (struct pending_req*)
>> (data->data);
>> +struct xen_blkif *blkif = pending_req->blkif;
>> +
>
Eric Blake wrote:
> On 01/13/2015 04:47 PM, Jim Fehlig wrote:
>
>
+++ b/src/Makefile.am
@@ -1005,6 +1005,10 @@ XENCONFIG_SOURCES =
\
xenconfig/xen_common.c xenconfig/xen_common.h \
xenconfig/xen_sxpr.c xenc
V5 of xen-xl parser. V4 was close
https://www.redhat.com/archives/libvir-list/2015-January/msg00429.html
but the tests did not exersice the spice parsing/formatting code. It is
now fixed in V5, along with addressing a few V4 comments from eblake.
Jim Fehlig (1):
Introduce support for parsing
From: Kiarie Kahurani
Now that xenconfig supports parsing and formatting Xen's
XL config format, integrate it into the libxl driver's
connectDomainXML{From,To}Native functions.
Signed-off-by: Kiarie Kahurani
Signed-off-by: Jim Fehlig
---
No change from V4.
src/libxl/libxl_driver.c | 32
Introduce a parser/formatter for the xl config format. Since the
deprecation of xm/xend, the VM config file format has diverged as
new features are added to libxl. This patch adds support for parsing
and formating the xl config format. It supports the existing xm config
format, plus adds support
From: Kiarie Kahurani
Add disk and spice config tests for the xen_xl config parser
Signed-off-by: Kiarie Kahurani
Signed-off-by: Jim Fehlig
---
V5:
Enable spice test. Fix invalid config in the test data files and
an actual bug in the spice formatting code.
tests/Makefile.am
On Wed, 2015-01-14 at 15:39 +, George Dunlap wrote:
> On 01/14/2015 03:18 PM, Ian Campbell wrote:
> >>> Host BIOSes are generally large compared to the guest BIOS, but with the
> >>> amount of decompression and relocation etc they do I don't know how much
> >>> of them generally remains in the
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
Reviewed-by: Julien Grall
---
xen/arch/arm/smpboot.c | 27 +--
1 file changed, 25 insertions(+),
+static void xen_blkbk_unmap_and_respond_callback(int result, struct gntab_unmap_queue_data *data)
+{
+ struct pending_req* pending_req = (struct pending_req*) (data->data);
+ struct xen_blkif *blkif = pending_req->blkif;
+
+ /* BUG_ON used to reproduce existing behaviour,
+
On 01/14/2015 03:18 PM, Ian Campbell wrote:
>>> Host BIOSes are generally large compared to the guest BIOS, but with the
>>> amount of decompression and relocation etc they do I don't know how much
>>> of them generally remains in the <1MB region.
>>
>> Recall the example: (host) RMRR naming E-
Hi Jan,
2015-01-14 10:02 GMT-05:00 Jan Beulich :
On 14.01.15 at 15:45, wrote:
>> Yes. I try to use the bits [A16, A12] to isolate different colors in a
>> shared cache. A 2MB 16-way associate shared cache uses [A16, A6] to
>> index the cache set. Because page size is 4KB, we have page frame
>>> On 14.01.15 at 16:11, wrote:
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -163,7 +163,7 @@
> #define CSFLAG_runq_migrate_request (1<<__CSFLAG_runq_migrate_request)
>
>
> -int opt_migrate_resist=500;
> +static int __initdata opt_migrate_resist=500;
> integer_
On Wed, 2015-01-14 at 15:19 +, Julien Grall wrote:
> On 14/01/15 15:14, Ian Campbell wrote:
> >>> diff --git a/xen/include/asm-arm/perfc_defn.h
> >>> b/xen/include/asm-arm/perfc_defn.h
> >>> new file mode 100644
> >>> index 000..df86879
> >>> --- /dev/null
> >>> +++ b/xen/include/asm-arm/p
On Wed, 2015-01-14 at 15:07 +, Jan Beulich wrote:
> >>> On 14.01.15 at 13:17, wrote:
> > 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 a
flight 33402 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33402/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33372
Tests which did not succeed,
On 14/01/15 15:14, Ian Campbell wrote:
>>> diff --git a/xen/include/asm-arm/perfc_defn.h
>>> b/xen/include/asm-arm/perfc_defn.h
>>> new file mode 100644
>>> index 000..df86879
>>> --- /dev/null
>>> +++ b/xen/include/asm-arm/perfc_defn.h
>>> @@ -0,0 +1,74 @@
>>> +/* This file is legiimately inc
On Wed, 2015-01-14 at 15:07 +, Julien Grall wrote:
> Hi Ian,
>
> On 14/01/15 14:33, Ian Campbell wrote:
> > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> > index 25ecf1d..604fc81 100644
> > --- a/xen/arch/arm/irq.c
> > +++ b/xen/arch/arm/irq.c
> > @@ -179,7 +179,12 @@ void do_IRQ(stru
@@ -982,6 +1075,9 @@ static void __end_block_io_op(struct pending_req
*pending_req, int error)
* the grant references associated with 'request' and provide
* the proper response on the ring.
*/
+ if (atomic_dec_and_test(&pending_req->pendcnt))
+ xe
On 14/01/15 14:56, Ian Campbell wrote:
>>> Where do you mean exactly?
>>
>> See for instance exynos5_cpu_power_up.
>
> Appears to be waiting the h/w to acknowledge that the CPU power is on,
> which is no guarantee that it is going to actually boot, or even make it
> to Xen code.
Right. This is wh
Changing param varibales in sched_credit2.c as static and marking them
as __initdata where required.
Signed-off-by: Uma Sharma
---
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 1ca521b..581493d 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
Hi Ian,
On 14/01/15 14:33, Ian Campbell wrote:
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 25ecf1d..604fc81 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -179,7 +179,12 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int
> irq, int is_fiq)
> {
> st
>>> On 14.01.15 at 13:17, wrote:
> 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 hos
>>> On 14.01.15 at 13:02, wrote:
> 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}
>> >>
>>> On 14.01.15 at 15:45, wrote:
> Yes. I try to use the bits [A16, A12] to isolate different colors in a
> shared cache. A 2MB 16-way associate shared cache uses [A16, A6] to
> index the cache set. Because page size is 4KB, we have page frame
> number's bits [A16, A12] overlapped with the bits us
On 14/01/15 14:15, Sander Eikelenboom wrote:
> Hi Gerry / David / Konrad,
>
> Some more testing uncovered another issue under Xen, this time with
> PCI-passthrough.
What device? In particular what interrupts is it using?
> I have bisected it to the following commit:
> cffe0a2b5a34c95a4dadc9ec
On Wed, 2015-01-14 at 14:51 +, Julien Grall wrote:
> On 14/01/15 14:39, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 14:27 +, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 14/01/15 14:01, Ian Campbell wrote:
> >>> Otherwise continue without it, which is preferable to the current
> >>> infi
On 14/01/15 14:39, Ian Campbell wrote:
> On Wed, 2015-01-14 at 14:27 +, Julien Grall wrote:
>> Hi Ian,
>>
>> On 14/01/15 14:01, Ian Campbell wrote:
>>> Otherwise continue without it, which is preferable to the current
>>> infinite hang.
>>
>> Nice!
>>
>>> Slightly tweak the grammar of a comment
>>> On 14.01.15 at 15:37, wrote:
> On 01/14/2015 02:32 PM, Jan Beulich wrote:
> On 14.01.15 at 13:01, wrote:
>>> 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
>>> On 14.01.15 at 12:45, 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
>>> 2: pnode 1, vcpus {10-20}
>>>
Hi Andrew,
Thank you very much for your quick reply!
2015-01-14 7:20 GMT-05:00 Andrew Cooper :
> 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
>>> On 14.01.15 at 13:29, wrote:
> 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 low
On Wed, 2015-01-14 at 14:27 +, Julien Grall wrote:
> Hi Ian,
>
> On 14/01/15 14:01, Ian Campbell wrote:
> > Otherwise continue without it, which is preferable to the current
> > infinite hang.
>
> Nice!
>
> > Slightly tweak the grammar of a comment in the same function.
> >
> > Signed-off-b
>>> On 14.01.15 at 13:16, wrote:
> On 01/14/2015 09:43 AM, Tian, Kevin 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
On 13/01/15 18:50, Ed White wrote:
> On 01/12/2015 05:06 AM, Andrew Cooper wrote:
>> On 09/01/15 21:26, Ed White wrote:
>>> Currently, neither is enabled globally but may be enabled on a per-VCPU
>>> basis by the altp2m code.
>>>
>>> Everything can be force-disabled globally by specifying vmfunc=0
On 01/14/2015 02:32 PM, Jan Beulich wrote:
On 14.01.15 at 13:01, wrote:
>> 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,
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 14 January 2015 14:33
> To: Xen-devel
> Cc: Andrew Cooper; Keir (Xen.org); Jan Beulich; Paul Durrant; Xen Coverity
> Team
> Subject: [PATCH] x86/viridian: Do not leak page refs and mappings if the host
> t
>>> On 14.01.15 at 13:12, wrote:
> 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
>>> expl
>>> On 14.01.15 at 13:03, wrote:
>> 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
As well as the existing common perf counters add a bunch of ARM specifics,
including the various trap types, vuart/vgic/vtimer accesses and different
types of interrupt.
Adjust the common code so that the columns line up again, not sure when/where
this went wrong.
This is mostly the set of stuff
Signed-off-by: Andrew Cooper
Coverity-ID: 1264360
CC: Keir Fraser
CC: Jan Beulich
CC: Paul Durrant
CC: Xen Coverity Team
---
xen/arch/x86/hvm/viridian.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index cb6
>>> On 14.01.15 at 13:01, wrote:
> 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 fa
Hi Ian,
On 14/01/15 14:01, Ian Campbell wrote:
> Otherwise continue without it, which is preferable to the current
> infinite hang.
Nice!
> Slightly tweak the grammar of a comment in the same function.
>
> Signed-off-by: Ian Campbell
> ---
> xen/arch/arm/smpboot.c | 26 +
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
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
-
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
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
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 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
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 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
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 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
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 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
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
---
[ 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
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
1 - 100 of 185 matches
Mail list logo
