flight 105658 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105658/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 41ccec58e07376fe3086d3fb4cf6290c53ca2303
baseline version:
ovmf ad1cd1aa09c0a8660c857
On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote:
On 08.02.17 at 08:31, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Monday, February 06, 2017 11:38 PM
>>>
>>> >>> On 06.02.17 at 15:48, wrote:
>>> > On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
>>> >
On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote:
. snip..
Reviewed-by: Konrad Rzeszutek Wilk
Couple of issues I found in sndif while preparing displif for review:
1. missing string constants
+#define XENSND_FIELD_BE_VERSIONS"versions"
+#define XENSND_FIELD_FE_VERSION "v
On February 08, 2017 4:22 PM, Chao Gao wrote:
>On Wed, Feb 08, 2017 at 10:15:28AM +, Xuquan (Quan Xu) wrote:
>>On February 08, 2017 4:52 PM, Jan Beulich wrote:
>> On 08.02.17 at 09:27, wrote:
Assumed vCPU is in guest_mode..
When apicv is enabled, hypervisor calls vmx_deliver_post
>>> On 09.02.17 at 09:27, wrote:
> On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote:
> On 08.02.17 at 08:31, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, February 06, 2017 11:38 PM
>>> On 06.02.17 at 15:48, wrote:
> On Mon, 2017-02-0
On Thu, 2017-02-09 at 01:56 -0700, Jan Beulich wrote:
>
> > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> > index 86c71be..3d9386a 100644
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -784,6 +784,8 @@ int epte_get_entry_emt(struct domain *d, unsigned
On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
> On Thu, 9 Feb 2017, Julien Grall wrote:
> > On 08/02/2017 23:28, Tamas K Lengyel wrote:
> > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall wrote:
> > > > Hi Tamas,
> > > >
> > > > Can you please try to configure your e-mail cli
>>> On 08.02.17 at 19:55, wrote:
> As per 4.7, I've prepared a branch for you:
Thanks.
> git://xenbits.xen.org/people/dariof/xen.git
> for-jan/staging-4.7/credit2-cpupool-fixes
>
> http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/head
> s/for-jan/staging-4.7/credit2-
On Thu, 2017-02-09 at 02:17 -0700, Jan Beulich wrote:
> > > > On 08.02.17 at 19:55, wrote:
> > I've only quickly tested it so far, and I have to leave now. I'll
> > play
> > with it a bit more tomorrow morning and let you know how it goes.
>
> Well, looking at the topmost commit, you've clearly m
On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote:
> On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2017, Julien Grall wrote:
> > > On 08/02/2017 23:28, Tamas K Lengyel wrote:
> > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall
> > > > wrote
libxl.c has grown to an uncomfortable size. Carve out the domain
related functions to libxl_domain.c.
Signed-off-by: Juergen Gross
---
tools/libxl/Makefile |1 +
tools/libxl/libxl.c| 1722 ---
tools/libxl/libxl_domain.c | 1744 +++
Splitting up libxl.c will require two functions to be globally visible.
Add their prototypes to libxl_internal.h.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 12 ++--
tools/libxl/libxl_internal.h | 7 +++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --
The copyright of libxl.c is a little bit outdated.
Adjust it to reality.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d400fa2..0641a8a 100644
--- a/tools/libxl/libxl.c
Before moving code to new sources clean up some white space issues in
libxl.c.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ea66149..6b87f48 10064
libxl.c has grown to an uncomfortable size. Carve out the scheduler
related functions to libxl_sched.c.
Signed-off-by: Juergen Gross
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.c | 891
tools/libxl/libxl_sched.c | 915 +
Move the few generic device specific functions left in libxl.c to
libxl_device.c.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c| 416 -
tools/libxl/libxl_device.c | 414
2 files changed, 414 i
libxl.c has become rather large. Split it up into multiple files.
Changes are:
- modification of Copyright comment (patch 1)
- made two functions non-static: libxl__get_memory_target(),
xcinfo2xlinfo() (patch 2)
- white space cleanup of libxl.c (patch 3)
- moving functions into new or existing s
libxl.c has grown to an uncomfortable size. Carve out the tmem
related functions to libxl_tmem.c.
Signed-off-by: Juergen Gross
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.c | 142
tools/libxl/libxl_tmem.c | 167 ++
libxl.c has grown to an uncomfortable size. Carve out the cpupool
related functions to libxl_cpupool.c.
Signed-off-by: Juergen Gross
---
tools/libxl/Makefile| 1 +
tools/libxl/libxl.c | 418 -
tools/libxl/libxl_cpupool.c | 443 +++
libxl.c has grown to an uncomfortable size. Carve out the console
related functions (including channels, keyboard and frame buffer)
to libxl_console.c.
Signed-off-by: Juergen Gross
---
tools/libxl/Makefile| 2 +-
tools/libxl/libxl.c | 846 ---
libxl.c has grown to an uncomfortable size. Carve out the disk
related functions to libxl_disk.c.
Signed-off-by: Juergen Gross
---
tools/libxl/Makefile |2 +-
tools/libxl/libxl.c | 1233 -
tools/libxl/libxl_disk.c | 1258 ++
libxl__device_frontend_path() is used in libxl_device.c only. Make it
static.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl_device.c | 2 +-
tools/libxl/libxl_internal.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_dev
libxl.c has grown to an uncomfortable size. Carve out the memory
related functions to libxl_mem.c.
Signed-off-by: Juergen Gross
---
tools/libxl/Makefile| 2 +-
tools/libxl/libxl.c | 577 --
tools/libxl/libxl_mem.c | 601 ++
On Thu, Feb 09, 2017 at 09:51:48AM +0800, Zhang Chen wrote:
>
>
> On 02/09/2017 12:54 AM, Wei Liu wrote:
> > And CC Zhangchen
>
> Thanks, I will apply this patch set before test my patch.
>
This is not yet the final form. Please need to wait until this work gets
applied.
Wei.
___
flight 68541 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68541/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops
All,
these stable releases are due in about 3 weeks time. Please indicate
backports you consider necessary but find still missing. Commits
already marked for backporting:
e719192026 xen: credit2: never consider CPUs outside of our cpupool.
(for 4.7.5 only, unless anyone cares to also provide 4.6
On Thu, Feb 09, 2017 at 02:52:49AM -0700, Jan Beulich wrote:
> All,
>
> these stable releases are due in about 3 weeks time. Please indicate
> backports you consider necessary but find still missing. Commits
> already marked for backporting:
>
> e719192026 xen: credit2: never consider CPUs outsid
flight 105655 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105655/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 14 guest-saverestore fail REGR. vs. 59254
test-amd64-amd64-xl
>>> On 07.02.17 at 18:35, wrote:
> @@ -3178,9 +3179,9 @@ static enum hvm_copy_result __hvm_copy(
> {
> static unsigned long lastpage;
> if ( xchg(&lastpage, gfn) != gfn )
> -gdprintk(XENLOG_DEBUG, "guest attempted write to
> read-
This run is configured for baseline tests only.
flight 68542 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68542/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestor
On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote:
> On 02/08/17 10:31 +, Wei Liu wrote:
> > On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote:
> > > On 01/27/17 17:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang
flight 105660 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105660/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
Hmm... not sure why my reply didn't have you in the To: field.
On Thu, Feb 09, 2017 at 10:13:13AM +, Wei Liu wrote:
> On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote:
> > On 02/08/17 10:31 +, Wei Liu wrote:
> > > On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote
On Thu, Feb 09, 2017 at 10:30:14AM +0100, Juergen Gross wrote:
> The copyright of libxl.c is a little bit outdated.
>
> Adjust it to reality.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
ht
On Thu, Feb 09, 2017 at 10:30:13AM +0100, Juergen Gross wrote:
> libxl.c has become rather large. Split it up into multiple files.
>
> Changes are:
> - modification of Copyright comment (patch 1)
> - made two functions non-static: libxl__get_memory_target(),
> xcinfo2xlinfo() (patch 2)
> - white
On 09/02/17 09:52, Jan Beulich wrote:
> All,
>
> these stable releases are due in about 3 weeks time. Please indicate
> backports you consider necessary but find still missing. Commits
> already marked for backporting:
>
> e719192026 xen: credit2: never consider CPUs outside of our cpupool.
> (for
On Thu, Feb 09, 2017 at 03:10:10AM -0700, Jan Beulich wrote:
> >>> On 07.02.17 at 18:35, wrote:
> > @@ -3178,9 +3179,9 @@ static enum hvm_copy_result __hvm_copy(
> > {
> > static unsigned long lastpage;
> > if ( xchg(&lastpage, gfn) != gfn )
> > -
On Thu, 2017-02-09 at 02:17 -0700, Jan Beulich wrote:
> > > > On 08.02.17 at 19:55, wrote:
> I'm going to commit what I have later today, and
> I'll pull in the one extra backport next time round.
>
Ok, patch attached.
I've tested it on top of current tip of staging-4.7.
Regards,
Dario
--
<>
On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
> On 08/02/17 16:11, Dario Faggioli wrote:
> > On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
> >> Callers to libxl_cpupool_create() can either request a specific pool
> >> id, or request that Xen do it for them. But at the mo
On Wed, Feb 08, 2017 at 02:51:45PM +, George Dunlap wrote:
> Callers to xc_cpupool_create() can either request a specific pool id,
> or request that Xen do it for them. But at the moment, the
> "automatic" selection is indicated by using a magic value, 0. This is
> undesirable both because it
Current code in acpi_os_map_memory uses the direct map in order to map memory
in the low 1MB, but acpi_os_unmap_memory doesn't takes that into account, and
always tries to perform a vunmap, which results in the following WARN:
(XEN) Xen WARN at vmap.c:185
(XEN) [ Xen-4.9-unstable x86_64 debu
On Thu, Feb 09, 2017 at 08:51:46AM +, Xuquan (Quan Xu) wrote:
>On February 08, 2017 4:22 PM, Chao Gao wrote:
>>On Wed, Feb 08, 2017 at 10:15:28AM +, Xuquan (Quan Xu) wrote:
>>>On February 08, 2017 4:52 PM, Jan Beulich wrote:
>>> On 08.02.17 at 09:27, wrote:
> Assumed vCPU is in gue
On Thu, 2017-02-09 at 10:00 +, osstest service owner wrote:
> flight 105655 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105655/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl
>>> On 09.02.17 at 11:37, wrote:
> Current code in acpi_os_map_memory uses the direct map in order to map memory
> in the low 1MB, but acpi_os_unmap_memory doesn't takes that into account,
> and
> always tries to perform a vunmap, which results in the following WARN:
>
> (XEN) Xen WARN at vmap.c
On Thu, Feb 09, 2017 at 01:56:14AM -0700, Jan Beulich wrote:
On 09.02.17 at 09:27, wrote:
>> On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote:
>> On 08.02.17 at 08:31, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, February 06, 2017 11:38 PM
>>>
On 17-02-08 11:34:16, Konrad Rzeszutek Wilk wrote:
> > +/* No valid value so do not enable feature. */
> > +if ( !regs.a || !regs.b )
>
> You use regs.d below. Would it make sense to check for that value as
> well?
>
> Or is a value of 0 for cox_max OK? I would think so, but not exactly
>
On Wed, Feb 08, 2017 at 04:15:59PM +0800, Yi Sun wrote:
> static void __init parse_psr_bool(char *s, char *value, char *feature,
> @@ -479,12 +495,14 @@ static struct psr_socket_info *get_socket_info(unsigned
> int socket)
> return socket_info + socket;
> }
>
> -int psr_get_info(unsigned
On Wed, Feb 08, 2017 at 04:15:55PM +0800, Yi Sun wrote:
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index 96a8589..4656936 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -17,12 +17,118 @@
> #include
> #include
> #include
> +#include
Please move the inclusion
On 17-02-08 14:03:15, Konrad Rzeszutek Wilk wrote:
> > > +static void cpu_fini_work(unsigned int cpu)
> > > +{
> > > +unsigned int socket = cpu_to_socket(cpu);
> > > +
> > > +if ( !socket_cpumask[socket] ||
> > > cpumask_empty(socket_cpumask[socket]) )
> >
> > I fear I don't understand th
On Thu, 2017-02-09 at 11:54 +0800, Chao Gao wrote:
>
> Jan is right. When the assertion fails, the value of gfn is 0xfee00.
>
> Do you mean that is_iomem_page() is equal to direct_mmio except some
> corner cases such as APIC access MFN and INVALID_MFN( any others? ) ?
That was the hypothesis, an
On 09/02/17 10:35, Wei Liu wrote:
> On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
>> On 08/02/17 16:11, Dario Faggioli wrote:
>>> On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
Callers to libxl_cpupool_create() can either request a specific pool
id, or request th
On Thu, Feb 09, 2017 at 11:17:46AM +, George Dunlap wrote:
> On 09/02/17 10:35, Wei Liu wrote:
> > On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
> >> On 08/02/17 16:11, Dario Faggioli wrote:
> >>> On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
> Callers to libxl_c
The usage of the __transparent__ attribute in 991033fa introduces some issues
when compiled with clang 3.8.0:
xen/include/asm/hvm/vmx/vmx.h:605:15: error: transparent_union attribute can
only be
applied to a union definition; attribute ignored
[-Werror,-Wignored-attributes]
typedef union _
On 09/02/17 11:24, Wei Liu wrote:
> On Thu, Feb 09, 2017 at 11:17:46AM +, George Dunlap wrote:
>> On 09/02/17 10:35, Wei Liu wrote:
>>> On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
On 08/02/17 16:11, Dario Faggioli wrote:
> On Wed, 2017-02-08 at 14:51 +, George Du
Juergen Gross writes ("[PATCH v2 02/12] libxl: make some functions global to
prepare splitting up libxl.c"):
> Splitting up libxl.c will require two functions to be globally visible.
> Add their prototypes to libxl_internal.h.
Thanks. However,
> -static void xcinfo2xlinfo(libxl_ctx *ctx,
> -
Juergen Gross writes ("[PATCH v2 01/12] libxl: adjust copyright comment of
libxl.c"):
> The copyright of libxl.c is a little bit outdated.
Acked-by: Ian Jackson
If you felt like doing a similar thing to the other files that would
be nice (but of course not required for this series).
Regards,
I
Juergen Gross writes ("[PATCH v2 03/12] libxl: white space cleanup"):
> Before moving code to new sources clean up some white space issues in
> libxl.c.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-
Juergen Gross writes ("[PATCH v2 00/12] libxl: split up libxl.c"):
> libxl: carve out cpupool specific functions from libxl.c
> libxl: carve out scheduler specific functions from libxl.c
> libxl: carve out disk specific functions from libxl.c
> libxl: carve out console specific functions fr
Juergen Gross writes ("[PATCH v2 12/12] libxl: make one function static"):
> libxl__device_frontend_path() is used in libxl_device.c only. Make it
> static.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/
On 09/02/17 12:36, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH v2 02/12] libxl: make some functions global to
> prepare splitting up libxl.c"):
>> Splitting up libxl.c will require two functions to be globally visible.
>> Add their prototypes to libxl_internal.h.
>
> Thanks. However,
>
>
CC Roger and Konrad
On Mon, Feb 06, 2017 at 12:31:20AM +0100, Håkon Alstadheim wrote:
> I get the BUG below in dom0 when trying to start a windows 10 domu (hvm,
> with some pv-drivers installed ) . Below is "xl info", then comes dmesg
> output, and finally domu config attached at end.
>
> This do
flight 105666 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105666/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On 09/02/17 11:33, Roger Pau Monne wrote:
> The usage of the __transparent__ attribute in 991033fa introduces some issues
> when compiled with clang 3.8.0:
>
> xen/include/asm/hvm/vmx/vmx.h:605:15: error: transparent_union attribute can
> only be
> applied to a union definition; attribute ig
>>> On 09.02.17 at 13:49, wrote:
> On 09/02/17 11:33, Roger Pau Monne wrote:
>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>> @@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain *d);
>> void vmx_pi_hooks_deassign(struct domain *d);
>>
>> /* EPT
On 09/02/17 13:01, Jan Beulich wrote:
On 09.02.17 at 13:49, wrote:
>> On 09/02/17 11:33, Roger Pau Monne wrote:
>>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>>> @@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain *d);
>>> void vmx_pi_hooks_
>>> On 09.02.17 at 14:05, wrote:
> On 09/02/17 13:01, Jan Beulich wrote:
> On 09.02.17 at 13:49, wrote:
>>> On 09/02/17 11:33, Roger Pau Monne wrote:
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(s
On 02/09/2017 05:44 AM, Dario Faggioli wrote:
On Thu, 2017-02-09 at 10:00 +, osstest service owner wrote:
flight 105655 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105655/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which cou
The xenbus driver has an awful mixture of internally and globally
visible headers: some of the internally used only stuff is defined in
the global header include/xen/xenbus.h while some stuff defined in
internal headers is used by other drivers, too.
Clean this up by moving the externally used sym
Handling of multiple concurrent Xenstore accesses through xenbus driver
either from the kernel or user land is rather lame today: xenbus is
capable to have one access active only at one point of time.
Rewrite xenbus to handle multiple requests concurrently by making use
of the request id of the Xe
Today a Xenstore watch event is delivered via a callback function
declared as:
void (*callback)(struct xenbus_watch *,
const char **vec, unsigned int len);
As all watch events only ever come with two parameters (path and token)
changing the prototype to:
void (*callback)(struct
The xenbus driver used for communication with Xenstore (all kernel
accesses to Xenstore and in case of Xenstore living in another domain
all accesses of the local domain to Xenstore) is rather simple
especially regarding multiple concurrent accesses: they are just being
serialized in spite of Xenst
On 09/02/17 13:14, Jan Beulich wrote:
On 09.02.17 at 14:05, wrote:
>> On 09/02/17 13:01, Jan Beulich wrote:
>> On 09.02.17 at 13:49, wrote:
On 09/02/17 11:33, Roger Pau Monne wrote:
> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
> @@
On 02/03/2017 04:38 AM, Juergen Gross wrote:
On 30/01/17 18:45, Boris Ostrovsky wrote:
rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
On Thu, Feb 09, 2017 at 06:14:54AM -0700, Jan Beulich wrote:
> >>> On 09.02.17 at 14:05, wrote:
> > On 09/02/17 13:01, Jan Beulich wrote:
> > On 09.02.17 at 13:49, wrote:
> >>> On 09/02/17 11:33, Roger Pau Monne wrote:
> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ b/xen/include/as
On 30/01/17 16:10, Juergen Gross wrote:
> Instead of using the default resolution of 800*600 for the pointing
> device of xen-kbdfront try to read the resolution of the (virtual)
> framebuffer device. Use the default as fallback only.
>
> Signed-off-by: Juergen Gross
Ping?
> ---
> V3: add case
Since we are doing cpumask manipulation already, clear a bit
in the mask at once. Doing that will save us an if, later in
the code.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
Changes from v1:
* rebased on current staging.
---
xen/common/sched_credit2
Most of the comments describing the meaning of the
vCPU flags used by the scheduler miss the 'wings' (or
have other minor style issues).
Also, use 1U (instead of 1) as the base of shiftings.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
-
Information we currently print for idle pCPUs is
rather useless. Credit2 already stopped showing that,
do the same for Credit and RTDS.
Also, define a new CPU status dump hook, which is
not defined by those schedulers which already dump
such info in other ways (e.g., Credit2, which does
that while
There isn't any particular reason for the accessor helpers
to be macro, so turn them into 'static inline'-s, which are
better.
Note that it is necessary to move the function definitions
below the structure declarations.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George
Hello,
This series contains mostly style or cosmetic fixes for Credit2, with the
following two exceptions:
- 2 actual fixes for (not so severe) behavioral bugs (patches 5 and 6);
- some tracing improvements (last 3 patches).
More info on the specific changelogs.
This is basically a resubmissio
There is no reason for having pretty much all of the
functions whose names begin with double underscores
('__') to actually look like that.
In fact, that is misleading and makes the code hard
to read and understand. So, remove the '__'-s.
The only two that we keep are __runq_assign() and
__runq_d
In fact, whether or not a pCPU has been tickled, and is
therefore about to re-schedule, is something we look at
and base decisions on in various places.
So, let's make sure that we do that basing on accurate
information.
While there, also tweak a little bit smt_idle_mask_clear()
(used for impleme
A credit reset basically means going through all the
vCPUs of a runqueue and altering their credits, as a
consequence of a 'scheduling epoch' having come to an
end.
Blocked or runnable vCPUs are fine, all the credits
they've spent running so far have been accounted to
them when they were scheduled
When traversing a Credit2 runqueue to select the
best candidate vCPU to be run next, show in the
trace which vCPUs we consider.
A bit verbose, but quite useful, considering that
we may end up looking at, but then discarding, one
of more vCPU. This will help understand which ones
are skipped and wh
In fact, it is quite useful a pice of information,
to know how long it is the "next time slice" a vCPU
has been granted. It allows one to assume (and then
check) when the scheduler is supposed to run next,
and other things.
While this information is indeed reported when a
context switch happens, i
On February 9, 2017 3:46:10 AM EST, Oleksandr Andrushchenko
wrote:
>
>
>On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote:
>> . snip..
Reviewed-by: Konrad Rzeszutek Wilk
>>>
>Couple of issues I found in sndif while preparing displif for review:
>1. missing string constants
>+#define XENSN
So that they're all close among each other, and
also near to the comment describind the runqueue
organization (which is also moved).
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
---
xen/common/sched_credit2.c | 572 +
On 09/02/17 13:58, Dario Faggioli wrote:
> @@ -441,6 +429,40 @@ struct csched2_dom {
> };
>
> /*
> + * Accessor helpers functions.
> + */
> +static always_inline
The always_inline isn't necessary. For one, the compiler is always
going to inline these, and IMO should be reserved for when you a
Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
for restricting device emulators (such as QEMU) to a limited set of
hypervisor operations, and being able to audit those operations in the
kernel of the domain in which they run.
This patch adds IOCTL_PRIVCMD_DM_OP as gatewa
This patch series follows on from my recent Xen series [1], to provide
support in privcmd for de-privileging of device emulators.
[1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg02558.html
Paul Durrant (3):
xen/privcmd: return -ENOSYS for unimplemented IOCTLs
xen/privcmd: Add IOC
The purpose if this ioctl is to allow a user of privcmd to restrict its
operation such that it will no longer service arbitrary hypercalls via
IOCTL_PRIVCMD_HYPERCALL, and will check for a matching domid when
servicing IOCTL_PRIVCMD_DM_OP. The aim of this is to limit the attack
surface for a compro
The code goes so far as to set the default return code to -ENOSYS but
then overrides this to -EINVAL in the switch() statement's default
case.
This patch removes this pointless and incorrect override.
Signed-off-by: Paul Durrant
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
---
drivers/xen/privcm
On 02/09/2017 02:48 PM, Konrad Rzeszutek Wilk wrote:
On February 9, 2017 3:46:10 AM EST, Oleksandr Andrushchenko
wrote:
On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote:
. snip..
Reviewed-by: Konrad Rzeszutek Wilk
Couple of issues I found in sndif while preparing displif for review:
1.
>>> On 09.02.17 at 14:42, wrote:
> On 09/02/17 13:14, Jan Beulich wrote:
> On 09.02.17 at 14:05, wrote:
>>> On 09/02/17 13:01, Jan Beulich wrote:
>>> On 09.02.17 at 13:49, wrote:
> On 09/02/17 11:33, Roger Pau Monne wrote:
>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>> +++ b/x
>>> On 09.02.17 at 14:45, wrote:
> On Thu, Feb 09, 2017 at 06:14:54AM -0700, Jan Beulich wrote:
>> >>> On 09.02.17 at 14:05, wrote:
>> > On 09/02/17 13:01, Jan Beulich wrote:
>> > On 09.02.17 at 13:49, wrote:
>> >>> On 09/02/17 11:33, Roger Pau Monne wrote:
>> --- a/xen/include/asm-x86/
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 09 February 2017 14:18
> To: xen-de...@lists.xenproject.org; linux-ker...@vger.kernel.org
> Cc: Paul Durrant ; Boris Ostrovsky
> ; Juergen Gross
> Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
>
flight 105659 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105659/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 105629
Regressions which
flight 105665 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105665/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
>>> On 09.02.17 at 15:14, wrote:
> On 09/02/17 13:58, Dario Faggioli wrote:
>> +struct csched2_private *csched2_priv(const struct scheduler *ops)
>
> You should either return a const csched2_private *, or not take a const
> ops. (Your choice.)
>
> Despite being allowed by the C typesystem, it i
>>> On 09.02.17 at 14:58, wrote:
> +/* CPU to runq_id macro */
> +static always_inline int c2r(const struct scheduler *ops, unsigned cpu)
> +{
> +return (csched2_priv(ops))->runq_map[(cpu)];
Any reason for having the (pointless) parentheses here but not ...
> +}
> +
> +/* CPU to runqueue str
1 - 100 of 193 matches
Mail list logo