>>> On 26.02.15 at 20:52, wrote:
> On 02/26/15 03:07, Jan Beulich wrote:
> On 25.02.15 at 21:20, wrote:
>>> On 02/24/15 10:34, Jan Beulich wrote:
>>> On 17.02.15 at 00:05, wrote:
> @@ -2474,7 +2594,12 @@ struct hvm_ioreq_server
> *hvm_select_ioreq_server(struct domain *d,
>
>>> On 26.02.15 at 17:53, wrote:
> Monday, February 23, 2015, 12:06:00 PM, you wrote:
>
>> I have no idea how I came to use __cpumask_set_cpu() there, the
>> conversion should have been set_bit() -> __set_bit(). The wrong
>> construct results in problems on systems with relatively few CPUs.
>
>
flight 35525 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
build-amd64-rumpuserx
On 2015/2/27 0:17, Ian Campbell wrote:
On Thu, 2015-02-26 at 14:35 +0800, Chen, Tiejun wrote:
If we are going to do this then I think we need to arrange for the
interface to be able to express the need to force the workarounds for a
particular device. IOW a boolean will not suffice since it doe
On 02/26/2015 07:48 PM, Luis R. Rodriguez wrote:
On Thu, Feb 26, 2015 at 05:42:57PM +, Stefano Stabellini wrote:
On Thu, 26 Feb 2015, Luis R. Rodriguez wrote:
On Thu, Feb 26, 2015 at 11:08:20AM +, Stefano Stabellini wrote:
On Thu, 26 Feb 2015, David Vrabel wrote:
On 26/02/15 04:59, Ju
On 02/26/2015 06:42 PM, Stefano Stabellini wrote:
On Thu, 26 Feb 2015, Luis R. Rodriguez wrote:
On Thu, Feb 26, 2015 at 11:08:20AM +, Stefano Stabellini wrote:
On Thu, 26 Feb 2015, David Vrabel wrote:
On 26/02/15 04:59, Juergen Gross wrote:
So we are again in the situation that pv-driver
2015-02-26 8:37 GMT-05:00 Dario Faggioli :
> and update them from Credit2 and RTDS schedulers.
>
> Signed-off-by: Dario Faggioli
> Cc: Meng Xu
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Keir Fraser
> ---
> xen/common/sched_credit2.c |2 ++
> xen/common/sched_rt.c|2 ++
> x
Not sure if I should comment with Reviewed-by, I will just do it. Please
just ignore if I should not add Reviewed-by.
2015-02-26 8:36 GMT-05:00 Dario Faggioli :
> more specifically, about vCPU initialization and destruction events,
> in line with adb26c09f26e ("xen: sched: introduce a couple of c
flight 35326 linux-3.16 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35326/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167
test-amd64-i386-pair
On 02/26/2015 09:57 AM, Olaf Hering wrote:
While working on pvscsi support for libxl I noticed that assigning a
resource exclusivly to just a single domU via libxl will be a major
effort. Up to now libxl could rely on the fact that a resource can be
either shared or the backend deals with the att
flight 35298 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35298/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. vs. 33480
test-amd64-amd64-xl
Wei Liu wrote:
> On Wed, Feb 11, 2015 at 10:18:18AM -0700, Jim Fehlig wrote:
>
>> At minimum, libvirt will populate the pdev_path, vdev, backend, and
>> format fields. If backend and format (which, in libvirt-speack
>> correspond to the 'name' and 'type' attributes on the optional
>> element) a
On Thursday, February 26, 2015 01:45:16 PM Mike Latimer wrote:
> On Thursday, February 26, 2015 05:53:06 PM Stefano Stabellini wrote:
> > What is the return value of libxl_set_memory_target and
> > libxl_wait_for_free_memory in that case? Isn't it just a matter of
> > properly handle the return val
On Thu, Jan 8, 2015 at 2:43 PM, Andy Lutomirski wrote:
> On Thu, Jan 8, 2015 at 2:31 PM, Marcelo Tosatti wrote:
>> On Tue, Jan 06, 2015 at 11:49:09AM -0800, Andy Lutomirski wrote:
>>> On Tue, Jan 6, 2015 at 10:45 AM, Marcelo Tosatti
>>> wrote:
>>> > On Tue, Jan 06, 2015 at 10:26:22AM -0800, And
On Thu, Feb 26, 2015 at 2:31 PM, Roger Pau Monné wrote:
> El 26/02/15 a les 19.02, Roger Pau Monné ha escrit:
>> El 26/02/15 a les 17.43, Jan Beulich ha escrit:
>> On 26.02.15 at 17:29, wrote:
OK, I will try to take a look. All those faults come from physical
memory ranges that are
On Thursday, February 26, 2015 05:53:06 PM Stefano Stabellini wrote:
> What is the return value of libxl_set_memory_target and
> libxl_wait_for_free_memory in that case? Isn't it just a matter of
> properly handle the return values?
The return from libxl_set_memory_target is 0, as the assignment w
(Sorry for the delayed response, dealing with ENOTIME.)
On Thursday, February 26, 2015 05:47:21 PM Ian Campbell wrote:
> On Thu, 2015-02-26 at 10:38 -0700, Mike Latimer wrote:
>
> >rc = libxl_set_memory_target(ctx, 0, free_memkb - need_memkb, 1, 0);
>
> I think so. In essence we just need to u
On 02/26/15 14:22, Tim Deegan wrote:
> At 19:49 +0200 on 26 Feb (1424976562), Razvan Cojocaru wrote:
>> On 02/26/2015 07:01 PM, Tim Deegan wrote:
>>> +#ifdef __cplusplus
>>> +/* 'private' is a keyword in C++, so we have to use a different name for
>>> + * private state there. Leaving the C name al
On 02/26/15 11:24, Tim Deegan wrote:
> Add a check, like the existing check for non-ANSI C in the public
> headers, that runs the public headers through a C++ compiler to
> flag non-C++-friendly constructs.
>
> Unlike the ANSI C check, we accept GCC-isms (gnu++98), and we also
> check various tool
flight 35257 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs. 34629
Regressions which ar
On 02/26/15 03:07, Jan Beulich wrote:
On 25.02.15 at 21:20, wrote:
>> On 02/24/15 10:34, Jan Beulich wrote:
>> On 17.02.15 at 00:05, wrote:
@@ -501,22 +542,50 @@ static void hvm_free_ioreq_gmfn(struct domain *d,
unsigned long gmfn)
[snip]
@@ -2429,9 +2552,6 @@ struct hv
El 26/02/15 a les 19.02, Roger Pau Monné ha escrit:
> El 26/02/15 a les 17.43, Jan Beulich ha escrit:
> On 26.02.15 at 17:29, wrote:
>>> OK, I will try to take a look. All those faults come from physical
>>> memory ranges that are supposed to be usable, and in fact the CPU seems
>>> to be able
El 26/02/15 a les 20.28, Konrad Rzeszutek Wilk ha escrit:
> On Thu, Feb 26, 2015 at 07:02:22PM +0100, Roger Pau Monné wrote:
>> El 26/02/15 a les 17.43, Jan Beulich ha escrit:
>> On 26.02.15 at 17:29, wrote:
OK, I will try to take a look. All those faults come from physical
memory ra
On Thu, Feb 26, 2015 at 07:02:22PM +0100, Roger Pau Monné wrote:
> El 26/02/15 a les 17.43, Jan Beulich ha escrit:
> On 26.02.15 at 17:29, wrote:
> >> OK, I will try to take a look. All those faults come from physical
> >> memory ranges that are supposed to be usable, and in fact the CPU seem
On Thu, Feb 26, 2015 at 06:53:29PM +, Stefano Stabellini wrote:
[...]
> > > }
> > >
> > > -libxl_dominfo_init(&ptr);
> > > -xcinfo2xlinfo(ctx, &info, &ptr);
> >
> > If I'm not mistaken, &info is only used here. I think you can delete
> > info and relevant code all together.
>
>
At 19:49 +0200 on 26 Feb (1424976562), Razvan Cojocaru wrote:
> On 02/26/2015 07:01 PM, Tim Deegan wrote:
> > +#ifdef __cplusplus
> > +/* 'private' is a keyword in C++, so we have to use a different name for
> > + * private state there. Leaving the C name alone to avoid unnecessary
> > + * pain fo
In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. In the future the offset will
include memory allocated by QEMU for rom files.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- call libxl_dominfo_init;
- move libxl_dominfo_dispose
Hi Jan,
Anything planned concerning this?
BR,
Jeroen.
Jan Beulich schreef op 9-12-2014 om 10:17:
On 09.12.14 at 10:09, wrote:
Did anyone find the time yet? I'm still more then willing testing any
patches.
Just yesterday we were told by Intel that they still can't foresee when
they will find
On Thu, 26 Feb 2015, Wei Liu wrote:
> On Wed, Feb 25, 2015 at 03:18:45PM +, Stefano Stabellini wrote:
> > In libxl_set_memory_target when setting the new maxmem, retain the same
> > offset on top of the current target. In the future the offset will
> > include memory allocated by QEMU for rom f
On Thu, Feb 26, 2015 at 05:42:57PM +, Stefano Stabellini wrote:
> On Thu, 26 Feb 2015, Luis R. Rodriguez wrote:
> > On Thu, Feb 26, 2015 at 11:08:20AM +, Stefano Stabellini wrote:
> > > On Thu, 26 Feb 2015, David Vrabel wrote:
> > > > On 26/02/15 04:59, Juergen Gross wrote:
> > > > >
> > >
On 02/26/2015 12:57 PM, kevin.ma...@gdata.de wrote:
-Ursprüngliche Nachricht-
Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Gesendet: Donnerstag, 26. Februar 2015 17:35
An: Dietmar Hahn; xen-devel@lists.xen.org
Cc: Mayer, Kevin
Betreff: Re: [Xen-devel] Branch Trace Storage f
On Wed, 18 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-18 at 09:50 -0600, Rob Herring wrote:
> > On Wed, Feb 18, 2015 at 7:51 AM, Julien Grall
> > wrote:
> > > From: Ard Biesheuvel
> > >
> > > This patch registers hvc0 as the preferred console if no console
> > > has been specified explicitl
On Wed, 18 Feb 2015, Julien Grall wrote:
> The function irq_of_parse_and_map returns 0 when the IRQ is not found.
>
> Futhermore, move the check before notifying the user that we are running on
> Xen.
>
> Signed-off-by: Julien Grall
> Acked-by: Ian Campbell
Acked-by: Stefano Stabellini
> --
Ian Campbell writes ("Re: [OSSTEST PATCH 8/8] ap-fetch-version: Use osstest's
home to find master tree"):
> On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> > When ap-fetch-version and ap-fetch-version-old are run on the osstest
> > controller but as a different user they should look in ~os
El 26/02/15 a les 17.43, Jan Beulich ha escrit:
On 26.02.15 at 17:29, wrote:
>> OK, I will try to take a look. All those faults come from physical
>> memory ranges that are supposed to be usable, and in fact the CPU seems
>> to be able to read/write from them without problems, or else the gue
On Thu, 26 Feb 2015, Ian Campbell wrote:
> On Wed, 2015-02-25 at 16:34 +, Stefano Stabellini wrote:
> > I think we should disable the build of all drivers in Xen by default,
> > except for the ARM standard compliant ones (for aarch64 the SBSA is a
> > nice summary of what is considered complian
On Thu, 26 Feb 2015, Mike Latimer wrote:
> On Thursday, February 26, 2015 03:57:54 PM Ian Campbell wrote:
> > On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> > > There is still one aspect of my original patch that is important. As the
> > > code currently stands, the target for dom0 is set
Signed-off-by: Ian Jackson
---
README.dev | 18 ++
1 file changed, 18 insertions(+)
diff --git a/README.dev b/README.dev
index aae4f17..03c3e61 100644
--- a/README.dev
+++ b/README.dev
@@ -164,3 +164,21 @@ $HOME/bisects/for-$branch.git/stop
$HOME/testing.git/$xenbranch.stop
Ian Campbell writes ("Re: [OSSTEST PATCH 5/8] standalone: Always set
OSSTEST_NO_BASELINE"):
> On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> > OSSTEST_NO_BASELINE disables the thing where cr-daily-branch decides
> Acked-by: Ian Campbell
>
> Although:
> > - --baseline)nobaseline=n; shi
Signed-off-by: Ian Jackson
CC: Antti Kantee
---
daily-cron-email-real--rumpuserxen |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daily-cron-email-real--rumpuserxen
b/daily-cron-email-real--rumpuserxen
index 67c48bf..a9166a0 100644
--- a/daily-cron-email-real--rumpuserxe
On Wed, 2015-02-25 at 16:34 +, Stefano Stabellini wrote:
> I think we should disable the build of all drivers in Xen by default,
> except for the ARM standard compliant ones (for aarch64 the SBSA is a
> nice summary of what is considered compliant), to keep the size of the
> binary small.
I th
> -Ursprüngliche Nachricht-
> Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Gesendet: Donnerstag, 26. Februar 2015 17:35
> An: Dietmar Hahn; xen-devel@lists.xen.org
> Cc: Mayer, Kevin
> Betreff: Re: [Xen-devel] Branch Trace Storage for guests and
> VPMUinitialization
>
> On
On 02/26/2015 08:44 AM, kevin.ma...@gdata.de wrote:
-Ursprüngliche Nachricht-
Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Gesendet: Mittwoch, 25. Februar 2015 23:20
An: Mayer, Kevin
Betreff: Re: AW: AW: [Xen-devel] Branch Trace Storage for guests
andVPMUinitialization
On 0
On 02/26/2015 07:01 PM, Tim Deegan wrote:
> +#ifdef __cplusplus
> +/* 'private' is a keyword in C++, so we have to use a different name for
> + * private state there. Leaving the C name alone to avoid unnecessary
> + * pain for the existing users. */
> +#define XEN_RING_PRIVATE pvt
> +#else
> +#de
On Thu, 2015-02-26 at 10:38 -0700, Mike Latimer wrote:
> On Thursday, February 26, 2015 03:57:54 PM Ian Campbell wrote:
> > On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> > > There is still one aspect of my original patch that is important. As the
> > > code currently stands, the target f
On Thu, 26 Feb 2015, Luis R. Rodriguez wrote:
> On Thu, Feb 26, 2015 at 11:19:17AM +, Stefano Stabellini wrote:
> > On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
> > > On Wed, Feb 25, 2015 at 12:01:31PM +, Stefano Stabellini wrote:
> > > > On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> > >
Ian Campbell writes ("Re: [OSSTEST PATCH 3/8] emails: honour
OSSTEST_EMAIL_SUBJECT_PREFIX"):
> On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
> > This is prefixed before the other computed prefixes. It makes it
> > easier to distinguish an adhoc cr-daily-branch test runs for a real
> > bra
On Thu, 26 Feb 2015, Luis R. Rodriguez wrote:
> On Thu, Feb 26, 2015 at 11:08:20AM +, Stefano Stabellini wrote:
> > On Thu, 26 Feb 2015, David Vrabel wrote:
> > > On 26/02/15 04:59, Juergen Gross wrote:
> > > >
> > > > So we are again in the situation that pv-drivers always imply the pvops
> >
On Thursday, February 26, 2015 03:57:54 PM Ian Campbell wrote:
> On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> > There is still one aspect of my original patch that is important. As the
> > code currently stands, the target for dom0 is set lower during each
> > iteration of the loop. Unl
Changes from v9:
* Move libxc refactoring code into standalone patch;
* Make libxl get_sample interface more generic;
Changes from v8:
* Merge event mask patch to MBM enabling patch;
* Address comments from Ian Campbell(Detail in patch itself).
Changes from v7:
* Make obfuscating more complex as
At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote:
> Add a check, like the existing check for non-ANSI C in the public
> headers, that runs the public headers through a C++ compiler to
> flag non-C++-friendly constructs.
Oops, this still has the EFI changes in it. v3, rebased, is on its way
Disallow memory relocation when vNUMA is enabled, because relocated
memory ends up off node. Further more, even if we dynamically expand
node coverage in hvmloader, low memory and high memory may reside
in different physical nodes, blindly relocating low memory to high
memory gives us a sub-optimal
Monday, February 23, 2015, 12:06:00 PM, you wrote:
> I have no idea how I came to use __cpumask_set_cpu() there, the
> conversion should have been set_bit() -> __set_bit(). The wrong
> construct results in problems on systems with relatively few CPUs.
> Reported-by: Sander Eikelenboom
> Signed-
This function is used to check whether vNUMA configuration (be it
auto-generated or supplied by user) is valid.
Define a new error code ERROR_VNUMA_CONFIG_INVALID.
The checks performed can be found in the comment of the function.
This vNUMA function (and future ones) is placed in a new file call
On 26/02/15 16:28, Tim Deegan wrote:
>
> BTW, ring.h is the only instance of that, so the extra diff to clear
> that up too is pretty small (see below).
>
> Not sure what people think about that though - it might be
> quite a PITA for downstream users of it, though they ought really to
> be using
Add a new field p2m_size to keep track of the number of pages covered by
p2m. Change total_pages to p2m_size in functions which in fact need
the size of p2m.
This is needed because we are going to ditch the assumption that PV x86
has only one contiguous ram region. Originally the p2m size was alw
>>> On 26.02.15 at 16:45, wrote:
> While testing PVH Dom0 support on a newer Core i3-5010U I've found that
> sharing the page tables between EPT and the IOMMUs don't work. Booting
> with iommu=no-sharept solves the problem, but I'm unsure what causes
> this issue.
Is FreeBSD fiddling with its
>>> On 26.02.15 at 17:28, wrote:
> At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote:
>> Explicitly _not_ addressing the use of 'private' in various fields,
>> since we'd previously decided not to fix that.
>
> BTW, ring.h is the only instance of that, so the extra diff to clear
> that up t
Update OVMF revision to the latest tested commit.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Anthony Perard
---
Before applying this patch, please pull from
git://xenbits.xen.org/osstest/ovmf.git xen-tested-master
and push all changes to
git://xenbits.xen.org/ovmf.git m
On 02/26/2015 03:56 AM, Dietmar Hahn wrote:
Am Mittwoch 25 Februar 2015, 11:31:31 schrieb Boris Ostrovsky:
On 02/25/2015 10:12 AM, kevin.ma...@gdata.de wrote:
-Ursprüngliche Nachricht-
Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Gesendet: Dienstag, 24. Februar 2015 18:13
An
Move a while loop in xc_hvm_build_x86 one block to the right. No
functional change introduced.
Functional changes will be introduced in next patch.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
Acked-by: Ian Campbell
---
tools/libxc/xc_hvm_b
At 15:33 + on 26 Feb (1424961188), Julien Grall wrote:
> Hi,
>
> On 26/02/15 11:09, Lars Kurth wrote:
> > Tim, Andrew, Jan,
> > it seems as if we are slowly coming to some conclusion on this thread. If
> > I am mistaken, I am wondering whether it would make sense to have an IRC
> > meeting wit
Currently all in tree code doesn't set the superpage flag, but Konrad
wants it retained for the moment.
As I'm going to change the p2m_host array allocation, duplicate the code
snippet to allocate p2m_host array in this patch, so that we retain the
behaviour in superpage case.
This patch introduc
On Thu, Feb 26, 2015 at 11:08:20AM +, Stefano Stabellini wrote:
> On Thu, 26 Feb 2015, David Vrabel wrote:
> > On 26/02/15 04:59, Juergen Gross wrote:
> > >
> > > So we are again in the situation that pv-drivers always imply the pvops
> > > kernel (PARAVIRT selected). I started the whole Kconf
Transform the user supplied vNUMA configuration into libxl internal
representations, and finally libxc representations. Check validity of
the configuration along the line.
Signed-off-by: Wei Liu
Reviewed-by: Dario Faggioli
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtsev
>From libxc's point of view, it only needs to know vnode to pnode mapping
and size of each vnode to allocate memory accordingly. Add these fields
to xc_dom structure.
The caller might not pass in vNUMA information. In that case, a dummy
layout is generated for the convenience of libxc's allocation
On Thu, 2015-02-26 at 14:35 +0800, Chen, Tiejun wrote:
> > If we are going to do this then I think we need to arrange for the
> > interface to be able to express the need to force the workarounds for a
> > particular device. IOW a boolean will not suffice since it doesn't
> > indicate that IGD wor
Am Mittwoch 25 Februar 2015, 11:31:31 schrieb Boris Ostrovsky:
> On 02/25/2015 10:12 AM, kevin.ma...@gdata.de wrote:
> >> -Ursprüngliche Nachricht-
> >> Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> >> Gesendet: Dienstag, 24. Februar 2015 18:13
> >> An: Mayer, Kevin; xen-devel@
On Thu, 2015-02-26 at 08:36 -0700, Mike Latimer wrote:
> On Wednesday, February 25, 2015 02:09:50 PM Stefano Stabellini wrote:
> > > Is the upshot that Mike doesn't need to do anything further with his
> > > patch (i.e. can drop it)? I think so?
> >
> > Yes, I think so. Maybe he could help out tes
Hello,
While testing PVH Dom0 support on a newer Core i3-5010U I've found that
sharing the page tables between EPT and the IOMMUs don't work. Booting
with iommu=no-sharept solves the problem, but I'm unsure what causes
this issue.
Here is the output of the system successfully booting with
iom
While working on pvscsi support for libxl I noticed that assigning a
resource exclusivly to just a single domU via libxl will be a major
effort. Up to now libxl could rely on the fact that a resource can be
either shared or the backend deals with the attempt to share.
There are two cases in pvscsi
...
> > /*
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index
> > 390c8b0..e4512a8 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -565,12 +565,13 @@ static void do_sgi(struct cpu_user_regs *regs,
> > enum gic_sgi sgi) void gic_interrupt(struct cpu_user_regs *r
Update NUMA_NO_NODE in Xen code to use the new macro.
No functional change introduced.
Signed-off-by: Wei Liu
Cc: Andrew Cooper
Cc: Jan Beulich
---
xen/arch/x86/hpet.c | 2 +-
xen/arch/x86/irq.c | 4 ++--
xen/arch/x86/numa.c |
Introduce a arch-independent routine to generate one vmemrange per
vnode. Also introduce arch-dependent routines for different
architectures because part of the process is arch-specific -- ARM has
yet have NUMA support and E820 is x86 only.
For those x86 guests who care about machine E820 map (i.e
Use calculated array index instead of hardcoded array index.
No functional change involved.
Signed-off-by: Chao Peng
---
tools/libxc/xc_psr.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index cfae172..
A vnode consists of one or more vmemranges (virtual memory range). One
example of multiple vmemranges is that there is a hole in one vnode.
Currently we haven't exported vmemrange interface to libxl user.
Vmemranges are generated during domain build, so we have relevant
structures in domain build
El 26/02/15 a les 16.57, Jan Beulich ha escrit:
On 26.02.15 at 16:45, wrote:
>> While testing PVH Dom0 support on a newer Core i3-5010U I've found that
>> sharing the page tables between EPT and the IOMMUs don't work. Booting
>> with iommu=no-sharept solves the problem, but I'm unsure what
On 26/02/15 16:28, Tim Deegan wrote:
> At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote:
>> Add a check, like the existing check for non-ANSI C in the public
>> headers, that runs the public headers through a C++ compiler to
>> flag non-C++-friendly constructs.
> Oops, this still has the EFI
At 16:47 + on 26 Feb (1424965651), Jan Beulich wrote:
> >>> On 26.02.15 at 17:28, wrote:
> > At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote:
> >> Explicitly _not_ addressing the use of 'private' in various fields,
> >> since we'd previously decided not to fix that.
> >
> > BTW, ring.
The algorithm is more or less the same as the one used for PV guest.
Libxc gets hold of the mapping of vnode to pnode and size of each vnode
then allocate memory accordingly.
And then the function returns low memory end, high memory end and mmio
start to caller. Libxl needs those values to constru
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
Changes in v6:
1. Join two lines to make code more compact.
2. Use %zu and drop casting.
---
tools/libxl/xl_cmdimpl.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
i
No functional change.
Signed-off-by: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/common/memory.c | 52 +++-
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/xen/common/memory.c b/xen/common/memory.c
index e84ace9..d24b001 100
Add Memory Bandwidth Monitoring(MBM) for VMs. Two types of monitoring
are supported: total and local memory bandwidth monitoring. To use it,
CMT should be enabled in hypervisor.
Signed-off-by: Chao Peng
---
Changes in v10:
1. Move refactoring code into standalone patch.
2. Create generic interfac
>>> On 26.02.15 at 17:29, wrote:
> OK, I will try to take a look. All those faults come from physical
> memory ranges that are supposed to be usable, and in fact the CPU seems
> to be able to read/write from them without problems, or else the guest
> would have crashed much more early. Regarding s
From: pedro
Date: Thu, 26 Feb 2015 09:25:41 +0100
> From: pmarzo
>
> offset and size are of type uint16_t so the %lu gives a warning
> A %u specifier, the same used in size makes gcc happy
> Not sure if a %x would be more correct
>
> Signed-off-by: Pedro Marzo Perez
This patch actually adds
On Thu, 2015-02-26 at 15:55 +, Wei Liu wrote:
> Introduce a arch-independent routine to generate one vmemrange per
> vnode. Also introduce arch-dependent routines for different
> architectures because part of the process is arch-specific -- ARM has
> yet have NUMA support and E820 is x86 only.
Make some internal routines common so that total/local memory bandwidth
monitoring in the next patch can make use of them.
Signed-off-by: Chao Peng
Acked-by: Wei Liu
---
Changes in v10:
1. Merge libxl change into next patch.
2. Minor function name changes to make them more generic.
---
tools/li
On February 26, 2015 8:35:17 AM EST, Juergen Gross wrote:
>Add myself as maintainer for the Xen pvUSB stuff.
>
>Signed-off-by: Juergen Gross
>---
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index ddc5a8c..8ec1e1f 100644
>--- a/MAINTAINER
On Thu, 2015-02-26 at 13:52 +, Jan Beulich wrote:
> ... by introducing a "dom0_nodes" option augmenting the "dom0_mem" and
> "dom0_max_vcpus" ones.
>
> Note that this gives meaning to MEMF_exact_node specified alone (i.e.
> implicitly combined with NUMA_NO_NODE): In such a case any node inside
On 26/02/15 04:59, Juergen Gross wrote:
>
> So we are again in the situation that pv-drivers always imply the pvops
> kernel (PARAVIRT selected). I started the whole Kconfig rework to
> eliminate this dependency.
Yes. Can you produce a series that just addresses this one issue.
In the absence o
Hi all
This is version 6 of this series rebased on top of staging.
This patch series implements virtual NUMA support for both PV and HVM guest.
That is, admin can configure via libxl what virtual NUMA topology the guest
sees.
This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-w
Add a check, like the existing check for non-ANSI C in the public
headers, that runs the public headers through a C++ compiler to
flag non-C++-friendly constructs.
Unlike the ANSI C check, we accept GCC-isms (gnu++98), and we also
check various tools-only headers.
Explicitly _not_ addressing the
A domain can contain several virtual NUMA nodes, hence we introduce an
array in libxl_domain_build_info.
libxl_vnode_info contains the size of memory in that node, the distance
from that node to every nodes, the underlying pnode and a bitmap of
vcpus.
Signed-off-by: Wei Liu
Reviewed-by: Dario Fa
On Thu, Feb 26, 2015 at 11:19:17AM +, Stefano Stabellini wrote:
> On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
> > On Wed, Feb 25, 2015 at 12:01:31PM +, Stefano Stabellini wrote:
> > > On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> > > > On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
This patch includes configuration options parser and documentation.
Please find the hunk to xl.cfg.pod.5 for more information.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
Changes in v6:
1. Disable NUMA auto-placement.
---
docs/man/xl.cfg.pod.5| 54 ++
tool
Make XENMEM_increase_reservation and XENMEM_populate_physmap
vNUMA-aware.
That is, if guest requests Xen to allocate memory for specific vnode,
Xen can translate vnode to pnode using vNUMA information of that guest.
XENMEMF_vnode is introduced for the guest to mark the node number is in
fact virt
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.
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
Reviewed-by: Dario Faggioli
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Ele
Transform user supplied vNUMA configuration into libxl internal
representations then libxc representations. Check validity along the
line.
Libxc has more involvement in building vmemranges in HVM case compared
to PV case. The building of vmemranges is placed after xc_hvm_build
returns, because it
These APIs can be used to manipulate XLU_ConfigValue and XLU_ConfigList.
APIs introduced:
1. xlu_cfg_value_type
2. xlu_cfg_value_get_string
3. xlu_cfg_value_get_list
4. xlu_cfg_get_listitem2
Move some definitions from private header to public header as needed.
Signed-off-by: Wei Liu
Cc: Ian Jac
This patches does following things:
1. Properly define a XLU_ConfigList type. Originally it was defined to
be XLU_ConfigSetting.
2. Define XLU_ConfigValue type, which can be either a string or a list
of XLU_ConfigValue.
3. ConfigSetting now references XLU_ConfigValue. Originally it only
w
1 - 100 of 203 matches
Mail list logo
