flight 95849 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95849/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 95718
test-amd64-amd64-xl-qemuu-
flight 95848 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95848/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl 3 host-install(3) broken in 95666 pass in 95848
test-amd64-i386-xl3 host-
On Wed, Jun 15, 2016 at 9:14 AM, Jan Beulich wrote:
> >>> On 15.06.16 at 12:45, wrote:
> > In reply to -
> > http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html
> >
> > HI, I am working with Jurgen on the issue, as per Jan's request I tried
> to
> > write explicitly only latency t
On Fri, Jun 17, 2016 at 7:11 PM, Dario Faggioli
wrote:
>
> In fact, what we have right now, i.e., tickle_idlers_none
> and tickle_idlers_some, is not good enough for describing
> what really happens in the various tickling functions of
> the various scheduler.
>
> Switch to a more descriptive set
flight 95846 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95846/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
flight 95844 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95844/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail in 95521 pass in 95844
test-amd64-i386-freebsd10-amd64 10 g
On 06/17/2016 01:21 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 17, 2016 at 01:18:47PM -0400, Daniel De Graaf wrote:
On 06/17/2016 01:14 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 17, 2016 at 01:04:01PM -0400, Daniel De Graaf wrote:
On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
On T
In fact, right now, we recommend keepeing runqueues
arranged per-core, so that it is the inter-runqueue load
balancing code that automatically spreads the work in an
SMT friendly way. This means that any other runq
arrangement one may want to use falls short of SMT
scheduling optimizations.
This c
because it is cheaper, and there is no much point in
randomizing which cpu gets selected anyway, as such
choice will be overridden shortly after, in runq_tickle().
If we really feel the need (e.g., we prove it worth with
benchmarking), we can record the last cpu which was used
by csched2_cpu_pick(
more specifically, with: TICKLE_NEW, RUNQ_MAX_WEIGHT,
MIGRATE, LOAD_CHECK, LOAD_BALANCE and PICKED_CPU, and
in both both xenalyze and formats (for xentrace_format).
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anshul Makkar
---
tools/xentrace/formats
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
Cc: David Vrabel
---
xen/common/sched_credit2.c | 114 +++-
1 file changed, 59 insertions(+), 55 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
ind
In fact, the data it protects only change either at init-time,
during cpupools manipulation, or when changing domains' weights.
In all other cases (namely, load balancing, reading weights
and status dumping), information is only read.
Therefore, let the lock be an read/write one. This means there
The existing load tracking code was hard to understad and
maintain, and not entirely consistent. This is due to a
number of reasons:
- code and comments were not in perfect sync, making it
difficult to figure out what the intent of a particular
choice was (e.g., the choice of 18 for load_win
(and fix the style of two labels as well.)
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
Cc: David Vrabel
---
xen/common/sched_credit2.c | 58 +---
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/xen/common/sched
Mainly, almost all of the BUG_ON-s can be converted into
ASSERTS, and the debug printk either removed or turned
into tracing.
The 'TODO' list, in a comment at the beginning of the file,
was also stale, so remove items that were still there but
are actually done.
Signed-off-by: Dario Faggioli
---
by not resetting the variable that should guard against
that at the beginning of each step of the outer loop.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
Cc: David Vrabel
---
xen/common/sched_credit2.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
d
as all the accesses to both the masks and the flags are
serialized by the runqueues locks already.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
Cc: David Vrabel
---
xen/common/sched_credit2.c | 48 ++--
1 file changed, 24 inse
in both xenalyze and formats (for xentrace_format).
In particular, in xenalyze, now that we have the precision
of the fixed point load values in the tracepoint, show both
the raw value and the (easier to interpreet) percentage.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
If there are idle pCPUs, it's always better to try to
"ship" the new vCPU there, instead than letting it
preempting on a currently busy one.
This commit also adds a cpumask_test_or_cycle() helper
function, to make it easier to code the preference for
the pCPU where the vCPU was running before.
Si
This really should not happen, but:
1. it does happen! Investigation is ongoing here:
http://lists.xen.org/archives/html/xen-devel/2016-06/msg00922.html
2. even when 1 will be fixed it makes sense and is easy enough
to have a 'safety catch' for it.
The reason why this is particularly bad
Yet another situation very similar to 779511f4bf5ae
("sched: avoid races on time values read from NOW()").
In fact, when more than one runqueue is involved, we need
to make sure that the following does not happen:
1. take the lock of 1st runq
2. now = NOW()
3. take the lock of 2nd runq
4. use
In fact, it has the same signature of csched2_cpu_pick,
which also is its uniqe caller.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
Cc: David Vrabel
---
xen/common/sched_credit2.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/x
on the same vcpu, without NOW() having changed.
This is, in fact, a legitimate use case. If it happens,
we should just do nothing, without producing any warning
or debug message.
While there, fix style and add a couple of branching
hints.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc:
Hi everyone,
Here you go a collection of pseudo-random fixes and improvement to Credit2.
In the process of working on Soft Affinity and Caps support, I stumbled upon
them, one after the other, and decided to take care.
It's been hard to test and run benchmark, due to the "time goes backwards" bu
In fact, they always operate on the svc->processor of
the csched2_vcpu passed to them.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Anshul Makkar
Cc: David Vrabel
---
xen/common/sched_credit2.c | 19 ++-
1 file changed, 10 insertion
In both Credit1 and Credit2, stop considering a pCPU idle,
if the reason why the idle vCPU is being selected, is to
do tasklet work.
Not doing so means that the tickling and load balancing
logic, seeing the pCPU as idle, considers it a candidate
for picking up vCPUs. But the pCPU won't actually pi
In fact, what we have right now, i.e., tickle_idlers_none
and tickle_idlers_some, is not good enough for describing
what really happens in the various tickling functions of
the various scheduler.
Switch to a more descriptive set of counters, such as:
- tickled_no_cpu: for when we don't tickle any
On Fri, 2016-06-17 at 19:32 +0200, Dario Faggioli wrote:
> Hi everyone,
>
Mmm... I'm not sure why, but this time, 'stg mail' only managed to send
the cover letter, then it terminated with no errors! :-O
In any case, I'm resending... apologies for the noise.
Regards,
Dario
--
<> (Raistlin Majere
flight 95842 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95842/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 95801
On Thu, Jun 2, 2016 at 4:52 PM, Tamas K Lengyel wrote:
> Mechanical renaming and relocation to the monitor subsystem.
>
> Signed-off-by: Tamas K Lengyel
> Acked-by: Razvan Cojocaru
> Acked-by: Jan Beulich
> ---
> Cc: Stefano Stabellini
> Cc: Julien Grall
> Cc: Andrew Cooper
Pinging the rest
On Thu, Jun 2, 2016 at 4:52 PM, Tamas K Lengyel wrote:
> The return value has not been clearly defined, with the function
> never returning 0 which seemingly indicated a condition where the
> guest should crash. In this patch we define -rc as error condition
> where the notification was not sent,
On Thu, Jun 2, 2016 at 4:52 PM, Tamas K Lengyel wrote:
> The monitor_get_capabilities check actually belongs to the monitor subsystem
> so
> relocating and renaming it to sanitize the code's name and location.
> Mechanical
> patch, no code changes introduced.
>
> Signed-off-by: Tamas K Lengyel
On Fri, Jun 17, 2016 at 3:33 AM, Jan Beulich wrote:
On 17.06.16 at 10:36, wrote:
>> On 06/17/2016 11:33 AM, Corneliu ZUZU wrote:
>>> Ah, ok. Didn't that patch make it to staging yet? I pulled the latest.
>>> Since you already have a patch for that I guess it's ok to remove those
>>> comments
flight 95840 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95840/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 86412
test-amd64-amd64-qemuu
flight 95838 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95838/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 94856
test-
Hi everyone,
Here you go a collection of pseudo-random fixes and improvement to Credit2.
In the process of working on Soft Affinity and Caps support, I stumbled upon
them, one after the other, and decided to take care.
It's been hard to test and run benchmark, due to the "time goes backwards" bu
On Fri, 2016-06-17 at 17:43 +0100, Wei Liu wrote:
> On Thu, Jun 16, 2016 at 01:16:54PM +0100, Wei Liu wrote:
> [...]
> [...]
> > > diff --git a/tools/libs/gnttab/private.h b/tools/libs/gnttab/private.h
> > > index d286c86..22ad53a 100644
> > > --- a/tools/libs/gnttab/private.h
> > > +++ b/tools/lib
flight 95866 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95866/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Fri, Jun 17, 2016 at 01:18:47PM -0400, Daniel De Graaf wrote:
> On 06/17/2016 01:14 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jun 17, 2016 at 01:04:01PM -0400, Daniel De Graaf wrote:
> >>On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
> >>>On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel
On 06/17/2016 01:13 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 17, 2016 at 01:02:58PM -0400, Daniel De Graaf wrote:
On 06/17/2016 11:45 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jun 09, 2016 at 10:47:14AM -0400, Daniel De Graaf wrote:
When an unknown domctl, sysctl, or other operation is enco
On 06/17/2016 01:14 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jun 17, 2016 at 01:04:01PM -0400, Daniel De Graaf wrote:
On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
Since FLASK is the only implementation of XSM hooks in Xen
On Fri, Jun 17, 2016 at 01:04:01PM -0400, Daniel De Graaf wrote:
> On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
> >On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
> >>Since FLASK is the only implementation of XSM hooks in Xen, using an
> >>iterated initcall dispatch for set
On Fri, Jun 17, 2016 at 01:02:58PM -0400, Daniel De Graaf wrote:
> On 06/17/2016 11:45 AM, Konrad Rzeszutek Wilk wrote:
> >On Thu, Jun 09, 2016 at 10:47:14AM -0400, Daniel De Graaf wrote:
> >>When an unknown domctl, sysctl, or other operation is encountered in the
> >>FLASK security server, use the
On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
Since FLASK is the only implementation of XSM hooks in Xen, using an
iterated initcall dispatch for setup is overly complex. Change this to
As such, should the Kconfig file en
On 06/17/2016 11:45 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jun 09, 2016 at 10:47:14AM -0400, Daniel De Graaf wrote:
When an unknown domctl, sysctl, or other operation is encountered in the
FLASK security server, use the allow_unknown bit in the security policy
to decide if the permission shoul
On 06/17/2016 11:28 AM, Konrad Rzeszutek Wilk wrote:
diff --git a/tools/flask/policy/modules/modules.conf
b/tools/flask/policy/modules/modules.conf
index d875dbf..9aac6a0 100644
--- a/tools/flask/policy/modules/modules.conf
+++ b/tools/flask/policy/modules/modules.conf
@@ -34,6 +34,13 @@ nomigra
On Thu, Jun 16, 2016 at 01:16:54PM +0100, Wei Liu wrote:
[...]
[...]
> > diff --git a/tools/libs/gnttab/private.h b/tools/libs/gnttab/private.h
> > index d286c86..22ad53a 100644
> > --- a/tools/libs/gnttab/private.h
> > +++ b/tools/libs/gnttab/private.h
> > @@ -9,6 +9,20 @@ struct xengntdev_handle
>>> On 17.06.16 at 18:13, wrote:
> On Wed, Jun 08, 2016 at 06:52:58AM -0600, Jan Beulich wrote:
>> There's no point in registering the internal MSI-X table intercept
>> functions on all domains - it is sufficient to do so once a domain gets
>> an MSI-X capable device assigned.
>
> I think this wi
On Wed, Jun 08, 2016 at 06:52:58AM -0600, Jan Beulich wrote:
> There's no point in registering the internal MSI-X table intercept
> functions on all domains - it is sufficient to do so once a domain gets
> an MSI-X capable device assigned.
I think this will break on SR-IOV devices that are created
On Fri, 17 Jun 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Juergen Gross [mailto:jgr...@suse.com]
> > Sent: 17 June 2016 11:40
> > To: Paul Durrant; Jan Beulich
> > Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> > de...@nongnu.org; kra...@redhat.com
> > Subjec
On Thu, 16 Jun 2016, Juergen Gross wrote:
> On 16/06/16 15:07, Stefano Stabellini wrote:
> > On Thu, 16 Jun 2016, Juergen Gross wrote:
> >> On 16/06/16 12:54, Jan Beulich wrote:
> >> On 16.06.16 at 12:02, wrote:
> In case the word size of the domU and qemu running the qdisk backend
>
On Thu, Jun 09, 2016 at 10:47:03AM -0400, Daniel De Graaf wrote:
> Some of these patches have been posted before (patch 11 was posted in
> 2014; an earlier variant of 1-6 and 15 were posted recently as RFC).
> The rest are mostly removal of unused code or other cleanup.
Hey Daniel,
I reviewed mos
On Thu, Jun 09, 2016 at 10:47:18AM -0400, Daniel De Graaf wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor. The p
On Thu, Jun 09, 2016 at 10:47:17AM -0400, Daniel De Graaf wrote:
> The only possible value of original_ops was &dummy_xsm_ops, and
> unregister_xsm was never used.
>
> Signed-off-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> xen/include/xsm/xsm.h| 1 -
> xen/xsm/flask/fl
On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
> Since FLASK is the only implementation of XSM hooks in Xen, using an
> iterated initcall dispatch for setup is overly complex. Change this to
As such, should the Kconfig file enable the FLASK by default?
Or make the XSM entry have
On Thu, Jun 09, 2016 at 10:47:14AM -0400, Daniel De Graaf wrote:
> When an unknown domctl, sysctl, or other operation is encountered in the
> FLASK security server, use the allow_unknown bit in the security policy
> to decide if the permission should be allowed or denied. This bit is
> off by defa
On Thu, Jun 09, 2016 at 10:47:10AM -0400, Daniel De Graaf wrote:
> These permissions were initially split because they were in separate
> domctls, but this split is very unlikely to actually provide security
> benefits: it would require a carefully contrived situation for a domain
> to both need ac
On Thu, Jun 09, 2016 at 10:47:09AM -0400, Daniel De Graaf wrote:
> The access vectors defined here have never been used by xenstore.
>
> Signed-off-by: Daniel De Graaf
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> tools/flask/policy/policy/access_vectors | 23 ++-
> tools/fl
On Thu, Jun 09, 2016 at 10:47:08AM -0400, Daniel De Graaf wrote:
> This adds the xenstore_t type to the example policy for use by a
> xenstore stub domain.
>
> Signed-off-by: Daniel De Graaf
> ---
> tools/flask/policy/modules/modules.conf | 3 +++
> tools/flask/policy/modules/xenstore.te | 24
> diff --git a/tools/flask/policy/modules/modules.conf
> b/tools/flask/policy/modules/modules.conf
> index d875dbf..9aac6a0 100644
> --- a/tools/flask/policy/modules/modules.conf
> +++ b/tools/flask/policy/modules/modules.conf
> @@ -34,6 +34,13 @@ nomigrate = on
> nic_dev = on
>
> # This allow
On Fri, Jun 17, 2016 at 08:55:04AM -0600, Jan Beulich wrote:
> >>> On 17.06.16 at 16:44, wrote:
> > On Fri, Jun 17, 2016 at 08:40:40AM -0600, Jan Beulich wrote:
> >> >>> On 17.06.16 at 16:32, wrote:
> >> > On Fri, Jun 17, 2016 at 08:28:34AM -0600, Jan Beulich wrote:
> >> >> >>> On 17.06.16 at 15:
>>> On 17.06.16 at 16:44, wrote:
> On Fri, Jun 17, 2016 at 08:40:40AM -0600, Jan Beulich wrote:
>> >>> On 17.06.16 at 16:32, wrote:
>> > On Fri, Jun 17, 2016 at 08:28:34AM -0600, Jan Beulich wrote:
>> >> >>> On 17.06.16 at 15:51, wrote:
>> >> > On 17/06/16 12:34, Jan Beulich wrote:
>> >> > O
>>> On 17.06.16 at 15:50, wrote:
> On 17/06/16 12:05, Wei Liu wrote:
>> @@ -182,6 +183,28 @@ static int __init hvm_enable(void)
>> if ( !opt_altp2m_enabled )
>> hvm_funcs.altp2m_supported = 0;
>>
>> +if ( opt_hvm_fep )
>> +{
>> +unsigned int i, j;
>> +
>> +p
On Fri, Jun 17, 2016 at 08:40:40AM -0600, Jan Beulich wrote:
> >>> On 17.06.16 at 16:32, wrote:
> > On Fri, Jun 17, 2016 at 08:28:34AM -0600, Jan Beulich wrote:
> >> >>> On 17.06.16 at 15:51, wrote:
> >> > On 17/06/16 12:34, Jan Beulich wrote:
> >> > On 17.06.16 at 13:05, wrote:
> >> >>> ---
>>> On 17.06.16 at 16:32, wrote:
> On Fri, Jun 17, 2016 at 08:28:34AM -0600, Jan Beulich wrote:
>> >>> On 17.06.16 at 15:51, wrote:
>> > On 17/06/16 12:34, Jan Beulich wrote:
>> > On 17.06.16 at 13:05, wrote:
>> >>> --- a/xen/arch/x86/Kconfig
>> >>> +++ b/xen/arch/x86/Kconfig
>> >>> @@ -59,6
On Fri, Jun 17, 2016 at 08:28:34AM -0600, Jan Beulich wrote:
> >>> On 17.06.16 at 15:51, wrote:
> > On 17/06/16 12:34, Jan Beulich wrote:
> > On 17.06.16 at 13:05, wrote:
> >>> --- a/xen/arch/x86/Kconfig
> >>> +++ b/xen/arch/x86/Kconfig
> >>> @@ -59,6 +59,20 @@ config BIGMEM
> >>>
> >>>
Hao, Xudong writes ("RE: [Xen-devel] qemu-traditional build problem for Xen
4.7.0 RC6"):
> Actually it's not compile error, it's a repo clone issue. Error log is:
>
> ...
> Initialized empty Git repository in
> /home/www/builds_xen_unstable/xen-src-xen-4.7.0-rc6-20160616/tools/qemu-xen-tradition
>>> On 17.06.16 at 15:51, wrote:
> On 17/06/16 12:34, Jan Beulich wrote:
> On 17.06.16 at 13:05, wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -59,6 +59,20 @@ config BIGMEM
>>>
>>> If unsure, say N.
>>>
>>> +config HVM_FEP
>>> + bool "HVM Forced Emula
On Fri, Jun 17, 2016 at 12:31:00PM +0200, Dario Faggioli wrote:
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
>>> On 17.06.16 at 13:51, wrote:
> On 06/17/2016 02:00 AM, Jan Beulich wrote:
> On 16.06.16 at 18:49, wrote:
>>> On 06/16/2016 05:40 AM, Jan Beulich wrote:
The IO-APIC address has variable bits determined by the PCI-to-ISA
bridge, and the IO-APIC version should be read from the IO-A
Signed-off-by: Wei Liu
---
tests/fep/Makefile | 12
tests/fep/main.c | 31 +++
2 files changed, 43 insertions(+)
create mode 100644 tests/fep/Makefile
create mode 100644 tests/fep/main.c
diff --git a/tests/fep/Makefile b/tests/fep/Makefile
new file mo
On 17/06/16 11:31, Dario Faggioli wrote:
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
> likely not what one w
On 6/17/16 5:31 AM, Dario Faggioli wrote:
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
> likely not what one
On 17/06/16 12:34, Jan Beulich wrote:
On 17.06.16 at 13:05, wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -59,6 +59,20 @@ config BIGMEM
>>
>>If unsure, say N.
>>
>> +config HVM_FEP
>> +bool "HVM Forced Emulation Prefix support"
> And no "if EXPERT"?
flight 95858 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95858/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 17/06/16 12:05, Wei Liu wrote:
> Originally hvm_fep was guarded by NDEBUG, which means it was only
> available to debug builds.
>
> However there is value to have it for non-debug builds as well. User can
> use that to run tests in setup that replicates production setup.
>
> Make it clear with a
> On Jun 17, 2016, at 5:31 AM, Dario Faggioli wrote:
>
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
> like
flight 95833 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95833/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
On Fri, Jun 17, 2016 at 05:34:07AM -0600, Jan Beulich wrote:
> >>> On 17.06.16 at 13:05, wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -59,6 +59,20 @@ config BIGMEM
> >
> > If unsure, say N.
> >
> > +config HVM_FEP
> > + bool "HVM Forced Emulation Prefix s
Hi Quan,
On 17/06/16 09:51, Xu, Quan wrote:
+ arm/amd maintainers..
On June 01, 2016 5:05 PM, Xu, Quan wrote:
If Device-TLB flush timed out, we hide the target ATS device immediately and
crash the domain owning this ATS device. If impacted domain is hardware
domain, just throw out a warning.
On 17/06/16 10:15, Stefano Stabellini wrote:
On Fri, 17 Jun 2016, Julien Grall wrote:
Hello Shannon,
On 17/06/16 04:29, Shannon Zhao wrote:
On 2016/6/6 19:40, Stefano Stabellini wrote:
ACPI tables for ARM guests should be user configurable: acpi=1 in the VM
config file enables them, with de
Hello,
On 17/06/16 12:40, Corneliu ZUZU wrote:
On 6/17/2016 11:55 AM, Julien Grall wrote:
On 16/06/16 15:08, Corneliu ZUZU wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d31f821..ba248c8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -19,6 +19,7 @@
Hello Corneliu,
On 17/06/16 11:36, Corneliu ZUZU wrote:
On 6/16/2016 7:49 PM, Julien Grall wrote:
On 16/06/16 15:13, Corneliu ZUZU wrote:
[...]
Please mention that PRRR and NMRR are aliased to respectively MAIR0
and MAIR1. This will avoid to spend time trying to understanding why
the spec s
flight 95836 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95836/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 95164
test-amd64-amd64-qemuu
On 6/17/2016 2:27 PM, Jan Beulich wrote:
On 17.06.16 at 13:13, wrote:
On 6/17/2016 10:17 AM, Jan Beulich wrote:
(And to be clear, I much appreciate any form of reduction of the
sometimes extremely long lists of #include-s, just not [apparently
or really] randomly mixed with other, substantial
On 06/17/2016 02:00 AM, Jan Beulich wrote:
On 16.06.16 at 18:49, wrote:
>> On 06/16/2016 05:40 AM, Jan Beulich wrote:
>>> The IO-APIC address has variable bits determined by the PCI-to-ISA
>>> bridge, and the IO-APIC version should be read from the IO-APIC. (Note
>>> that there's still implic
On 6/17/2016 12:28 AM, Julien Grall wrote:
On 16/06/2016 20:24, Corneliu ZUZU wrote:
On 6/16/2016 5:26 PM, Julien Grall wrote:
Hi Julien. Yes, I agree that it's complex, I would have preferred to
split it up too and I actually tried, but the changes are tightly
coupled and they don't seem to b
On 6/17/2016 11:55 AM, Julien Grall wrote:
Hello,
On 16/06/16 15:08, Corneliu ZUZU wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d31f821..ba248c8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#incl
>>> On 17.06.16 at 13:05, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -59,6 +59,20 @@ config BIGMEM
>
> If unsure, say N.
>
> +config HVM_FEP
> + bool "HVM Forced Emulation Prefix support"
And no "if EXPERT"?
> @@ -95,9 +96,9 @@ unsigned long __section("
On 6/17/2016 11:38 AM, Jan Beulich wrote:
On 17.06.16 at 10:25, wrote:
On 6/16/2016 6:16 PM, Jan Beulich wrote:
And looking at all the uses of this variable I get the impression that
you really want a shorthand for &d->arch.monitor (if any such
helper variable is worthwhile to have here in the
>>> On 17.06.16 at 13:13, wrote:
> On 6/17/2016 10:17 AM, Jan Beulich wrote:
>> (And to be clear, I much appreciate any form of reduction of the
>> sometimes extremely long lists of #include-s, just not [apparently
>> or really] randomly mixed with other, substantial changes. That's
>> namely beca
flight 95853 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/95853/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 6/17/2016 10:20 AM, Jan Beulich wrote:
On 16.06.16 at 22:20, wrote:
On 6/16/2016 6:00 PM, Jan Beulich wrote:
On 16.06.16 at 16:09, wrote:
@@ -1432,18 +1430,16 @@ static void vmx_update_guest_cr(struct vcpu *v,
unsigned int cr)
if ( paging_mode_hap(v->domain) )
{
The qdisk implementation is using the native xenbus protocol only in
case of no protocol specified at all. As using the explicit 32- or
64-bit protocol is slower than the native one due to copying requests
not by memcpy but element for element, this is not optimal.
Correct this by using the native
On 6/17/2016 10:17 AM, Jan Beulich wrote:
On 16.06.16 at 22:10, wrote:
On 6/16/2016 5:51 PM, Jan Beulich wrote:
On 16.06.16 at 16:08, wrote:
@@ -509,6 +508,8 @@ void hvm_do_resume(struct vcpu *v)
}
}
+vm_event_vcpu_enter(v);
Why here?
Why indeed. It made sense bec
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/common/kernel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/common/kernel.c
Wei Liu (2):
xen/kernel: document 'C' in print_tainted
xen: make available hvm_fep to non-debug build as well
docs/misc/xen-command-line.markdown | 8 ++--
xen/arch/x86/Kconfig| 14 ++
xen/arch/x86/hvm/hvm.c | 28 ++--
xen/
Originally hvm_fep was guarded by NDEBUG, which means it was only
available to debug builds.
However there is value to have it for non-debug builds as well. User can
use that to run tests in setup that replicates production setup.
Make it clear with a sync_console style warning that this option c
On 17/06/16 11:31, Dario Faggioli wrote:
> instead of just the first scheduler we find in the array.
>
> In fact, right now, if someone makes a typo when passing
> the "sched=" command line option to Xen, we (with all
> schedulers configured in) pick ARINC653, which is most
> likely not what one wo
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 17 June 2016 11:40
> To: Paul Durrant; Jan Beulich
> Cc: Anthony Perard; xen-devel; sstabell...@kernel.org; qemu-
> de...@nongnu.org; kra...@redhat.com
> Subject: Re: [Xen-devel] [PATCH v2] xen: fix qdisk BLKIF_OP_D
1 - 100 of 168 matches
Mail list logo
