Re: [Xen-devel] [V9 2/3] Refactor rangeset structure for better performance.

[Paul Durrant]

> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Jan Beulich
> Sent: 06 January 2016 09:59
> To: Paul Durrant; Zhang Yu
> Cc: Kevin Tian; Wei Liu; Shuai Ruan; Andrew Cooper; xen-
> de...@lists.xen.org; Stefano Stabellini; zhiyuan...@intel.com; Ian Jackson;
> Keir (Xen.org)
> Subject: Re: [Xen-devel] [V9 2/3] Refactor rangeset structure for better
> performance.
> 
> >>> On 06.01.16 at 10:46,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 06 January 2016 08:53
> >> >>> On 31.12.15 at 10:33,  wrote:
> >> > On 12/21/2015 10:38 PM, Jan Beulich wrote:
> >> > On 15.12.15 at 03:05,  wrote:
> >> >>> This patch refactors struct rangeset to base it on the red-black
> >> >>> tree structure, instead of on the current doubly linked list. By
> >> >>> now, ioreq leverages rangeset to keep track of the IO/memory
> >> >>> resources to be emulated. Yet when number of ranges inside one
> >> >>> ioreq server is very high, traversing a doubly linked list could
> >> >>> be time consuming. With this patch, the time complexity for
> >> >>> searching a rangeset can be improved from O(n) to O(log(n)).
> >> >>> Interfaces of rangeset still remain the same, and no new APIs
> >> >>> introduced.
> >> >>
> >> >> So this indeed addresses one of the two original concerns. But
> >> >> what about the other (resource use due to thousands of ranges
> >> >> in use by a single VM)? IOW I'm still unconvinced this is the way
> >> >> to go.
> >> >
> >> > Thank you, Jan. As you saw in patch 3/3, the other concern was solved
> >> > by extending the rangeset size, which may not be convictive for you.
> >> > But I believe this patch - refactoring the rangeset to rb_tree, does
> >> > not only solve XenGT's performance issue, but may also be helpful in
> >> > the future, e.g. if someday the rangeset is not allocated in xen heap
> >> > and can have a great number of ranges in it. :)
> >>
> >> I don't follow: Patch 3 makes things worse resource consumption
> >> wise, not better.
> >>
> >
> > Yes, it allows the rangeset to grow larger. Would it be better to tie
> > emulation rangesets to a specific domain and have the rangeset limits
> defined
> > for the domain by the toolstack?
> 
> In fact that's what I had suggested in reply to 3/3 at about the same
> time as the mail you've replied to here.
>

Sounds like the way to go then :-)

  Paul
 
> Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH OSSTEST] sg-report-job-history: alternate color of osstest column only when it changes

[Ian Campbell]

Currently the bgcolor of the osstest column alternates on each line,
rather than only when it changes as the other revision columns do.

A given flight might touch multiple osstest revisions (although in
practice they rarely do) but it seems reasonable to simply consider
any change as a change.

Signed-off-by: Ian Campbell 
---
 sg-report-job-history | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sg-report-job-history b/sg-report-job-history
index 0e2a3f9..e2e5806 100755
--- a/sg-report-job-history
+++ b/sg-report-job-history
@@ -234,6 +234,7 @@ END
 my @last_revs;
 my @alt_revs;
 my $alt_hosts;
+my $alt_osstest;
 foreach my $r (@test_rows) {
 my $altcolour= report_altcolour($alternate);
 print H "";
@@ -254,16 +255,15 @@ END
 my $hosts_colour = report_altchangecolour(\$alt_hosts, $hosts);
 print H "".encode_entities($hosts)."\n";
 $osstestverq->execute($r->{Flight}{flight});
-print H
-"",
-(join ' ',
+my $osstestrevs = join ' ',
  map {
 $_ = $_->{harness};
 s/^([0-9a-f]{12})[0-9a-f]+\b/$1/;
 "".encode_entities($_)."";
  }
- @{ $osstestverq->fetchall_arrayref({}) }),
-"\n";
+ @{ $osstestverq->fetchall_arrayref({}) };
+my $osstest_colour = report_altchangecolour(\$alt_osstest, 
$osstestrevs);
+print H "$osstestrevs\n";
 foreach my $i (0..$#rev_grid_cols) {
 my $v= $r->{Revisions}[$i];
my $rev_colour = report_altchangecolour(\$alt_revs[$i], $v);
-- 
2.6.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Andrew Cooper]

On 06/01/16 11:42, Tamas K Lengyel wrote:
>
>
> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich  > wrote:
>
> >>> On 23.12.15 at 15:53,  > wrote:
> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
> vm_event_request_t *req)
> >  vm_event_vcpu_pause(curr);
> >  }
> >
> > +if ( altp2m_active(currd) )
> > +{
> > +req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> > +req->altp2m_idx = vcpu_altp2m(curr).p2midx;
> > +}
>
> So far this info was provided just for MEM_ACCESS events. Now
> you provide it for a few more ones, but wouldn't this then better
> be supplied for all of them, namely also the other two MEM ones?
>
>
> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure
> but I think it's also incompatible with paging.

I don't think they are strictly incompatible; I don't see a technical
reason preventing some development work to make them function together.

Whether this happens or not is a very different matter.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [xen-unstable test] 76919: regressions - FAIL

[Ian Campbell]

On Wed, 2016-01-06 at 11:14 +, Ian Campbell wrote:
> On Tue, 2016-01-05 at 02:26 +, osstest service owner wrote:
> > flight 76919 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/76919/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-
> > install fail REGR. vs. 66879
> 
> ISTR someone (Wei?) at some point saying that a 32-bit stubdom (as used
> here) isn't actually something we wish to support. Shall we either drop
> this test altogether or mark it as allow? Or will someone investigate why
> it apparently can't find its disks.
> 
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html

4.6 exhibits the same pattern, as do linux-3.14 and 3.16:
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-4.6-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/linux-3.14.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/linux-3.16.html

(more or less, 3.14 seems to have never gotten lucky)

But recent linux 3.18 and 4.1 results look relatively positive:
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/linux-3.18.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/linux-4.1.html

Could this have been a dom0 kernel issue, previously masked by merlot*
specific issues, which is since fixed (or less prevalent at least)?

Ian.

> seems to suggest it has a very low probability of success (both merlot
> and
> italia failed dozens of times before passing)
> 
> Nothing in the xen.git range bf925a9f1254..8e4d18e113c9 looks especially
> relevant.
> 
> Bisection couldn't reproduce the basis pass:
> http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/t
> est-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-
> install.html
> 
> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [V9 3/3] Differentiate IO/mem resources tracked by ioreq server

[Jan Beulich]

>>> On 31.12.15 at 10:33,  wrote:
> On 12/21/2015 10:45 PM, Jan Beulich wrote:
> On 15.12.15 at 03:05,  wrote:
>>> @@ -2593,6 +2597,16 @@ struct hvm_ioreq_server 
>>> *hvm_select_ioreq_server(struct domain *d,
>>>   type = (p->type == IOREQ_TYPE_PIO) ?
>>>   HVMOP_IO_RANGE_PORT : HVMOP_IO_RANGE_MEMORY;
>>>   addr = p->addr;
>>> +if ( type == HVMOP_IO_RANGE_MEMORY )
>>> +{
>>> + ram_page = get_page_from_gfn(d, p->addr >> PAGE_SHIFT,
>>> +  , P2M_UNSHARE);
>>> + if ( p2mt == p2m_mmio_write_dm )
>>> + type = HVMOP_IO_RANGE_WP_MEM;
>>> +
>>> + if ( ram_page )
>>> + put_page(ram_page);
>>> +}
>>
>> You evaluate the page's current type here - what if it subsequently
>> changes? I don't think it is appropriate to leave the hypervisor at
>> the mercy of the device model here.
> 
> Well. I do not quite understand your concern. :)
> Here, the get_page_from_gfn() is used to determine if the addr is a MMIO
> or a write-protected ram. If this p2m type is changed, it should be
> triggered by the guest and device model, e.g. this RAM is not supposed
> to be used as the graphic translation table. And it should be fine.
> But I also wonder, if there's any other routine more appropriate to get
> a p2m type from the gfn?

No, the question isn't the choice of method to retrieve the
current type, but the lack of measures against the retrieved
type becoming stale by the time you actually use it.

>>> --- a/xen/include/asm-x86/hvm/domain.h
>>> +++ b/xen/include/asm-x86/hvm/domain.h
>>> @@ -48,8 +48,8 @@ struct hvm_ioreq_vcpu {
>>>   bool_t   pending;
>>>   };
>>>
>>> -#define NR_IO_RANGE_TYPES (HVMOP_IO_RANGE_PCI + 1)
>>> -#define MAX_NR_IO_RANGES  256
>>> +#define NR_IO_RANGE_TYPES (HVMOP_IO_RANGE_WP_MEM + 1)
>>> +#define MAX_NR_IO_RANGES  8192
>>
>> I'm sure I've objected before to this universal bumping of the limit:
>> Even if I were to withdraw my objection to the higher limit on the
>> new kind of tracked resource, I would continue to object to all
>> other resources getting their limits bumped too.
>>
> 
> Hah. So how about we keep MAX_NR_IO_RANGES as 256, and use a new value,
> say MAX_NR_WR_MEM_RANGES, set to 8192 in this patch? :)

That would at least limit the damage to the newly introduced type.
But I suppose you realize it would still be a resource consumption
concern. In order for this to not become a security issue, you
might e.g. stay with the conservative old limit and allow a command
line or even better guest config file override to it (effectively making
the admin state his consent with the higher resource use).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [V9 3/3] Differentiate IO/mem resources tracked by ioreq server

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 06 January 2016 08:59
> To: Zhang Yu
> Cc: Andrew Cooper; Paul Durrant; Wei Liu; Ian Jackson; Stefano Stabellini;
> Kevin Tian; zhiyuan...@intel.com; Shuai Ruan; xen-devel@lists.xen.org; Keir
> (Xen.org)
> Subject: Re: [Xen-devel] [V9 3/3] Differentiate IO/mem resources tracked by
> ioreq server
> 
> >>> On 31.12.15 at 10:33,  wrote:
> > On 12/21/2015 10:45 PM, Jan Beulich wrote:
> > On 15.12.15 at 03:05,  wrote:
> >>> @@ -2593,6 +2597,16 @@ struct hvm_ioreq_server
> *hvm_select_ioreq_server(struct domain *d,
> >>>   type = (p->type == IOREQ_TYPE_PIO) ?
> >>>   HVMOP_IO_RANGE_PORT : HVMOP_IO_RANGE_MEMORY;
> >>>   addr = p->addr;
> >>> +if ( type == HVMOP_IO_RANGE_MEMORY )
> >>> +{
> >>> + ram_page = get_page_from_gfn(d, p->addr >> PAGE_SHIFT,
> >>> +  , P2M_UNSHARE);
> >>> + if ( p2mt == p2m_mmio_write_dm )
> >>> + type = HVMOP_IO_RANGE_WP_MEM;
> >>> +
> >>> + if ( ram_page )
> >>> + put_page(ram_page);
> >>> +}
> >>
> >> You evaluate the page's current type here - what if it subsequently
> >> changes? I don't think it is appropriate to leave the hypervisor at
> >> the mercy of the device model here.
> >
> > Well. I do not quite understand your concern. :)
> > Here, the get_page_from_gfn() is used to determine if the addr is a MMIO
> > or a write-protected ram. If this p2m type is changed, it should be
> > triggered by the guest and device model, e.g. this RAM is not supposed
> > to be used as the graphic translation table. And it should be fine.
> > But I also wonder, if there's any other routine more appropriate to get
> > a p2m type from the gfn?
> 
> No, the question isn't the choice of method to retrieve the
> current type, but the lack of measures against the retrieved
> type becoming stale by the time you actually use it.
> 

I don't think that issue is specific to this code. AFAIK nothing in the I/O 
emulation system protects against a type change whilst a request is in flight.
Also, what are the consequences of a change? Only that the wrong range type is 
selected and the emulation goes to the wrong place. This may be a problem for 
the VM but should cause no other problems.

  Paul

> >>> --- a/xen/include/asm-x86/hvm/domain.h
> >>> +++ b/xen/include/asm-x86/hvm/domain.h
> >>> @@ -48,8 +48,8 @@ struct hvm_ioreq_vcpu {
> >>>   bool_t   pending;
> >>>   };
> >>>
> >>> -#define NR_IO_RANGE_TYPES (HVMOP_IO_RANGE_PCI + 1)
> >>> -#define MAX_NR_IO_RANGES  256
> >>> +#define NR_IO_RANGE_TYPES (HVMOP_IO_RANGE_WP_MEM + 1)
> >>> +#define MAX_NR_IO_RANGES  8192
> >>
> >> I'm sure I've objected before to this universal bumping of the limit:
> >> Even if I were to withdraw my objection to the higher limit on the
> >> new kind of tracked resource, I would continue to object to all
> >> other resources getting their limits bumped too.
> >>
> >
> > Hah. So how about we keep MAX_NR_IO_RANGES as 256, and use a new
> value,
> > say MAX_NR_WR_MEM_RANGES, set to 8192 in this patch? :)
> 
> That would at least limit the damage to the newly introduced type.
> But I suppose you realize it would still be a resource consumption
> concern. In order for this to not become a security issue, you
> might e.g. stay with the conservative old limit and allow a command
> line or even better guest config file override to it (effectively making
> the admin state his consent with the higher resource use).
> 
> Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [qemu-mainline test] 76949: regressions - FAIL

[Ian Campbell]

Stefano, Anthony,

On Mon, 2016-01-04 at 14:17 +, osstest service owner wrote:
> flight 76949 qemu-mainline real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/76949/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i3865 xen-build fail REGR. vs. 
> 66433
>  build-amd64-xsm   5 xen-build fail REGR. vs. 
> 66433
>  build-amd64   5 xen-build fail REGR. vs. 
> 66433
>  build-i386-xsm5 xen-build fail REGR. vs. 
> 66433
>  build-armhf-xsm   5 xen-build fail REGR. vs. 
> 66433
>  build-armhf   5 xen-build fail REGR. vs. 
> 66433

Any idea what is going on here or if there is a fix in the works? It's been
failing since 17/12 last year.

It looks like lots of:

In file included from 
/home/osstest/build.76949.build-armhf/xen/tools/qemu-xen-dir/include/trace.h:4:0,
 from util/oslib-posix.c:58:
./trace/generated-tracers.h: In function 'trace_user_setup_frame':
./trace/generated-tracers.h:17455:25: error: too many arguments for format 
[-Werror=format-extra-args]
 , env, frame_addr);
 ^
./trace/generated-tracers.h: In function 'trace_user_setup_rt_frame':
./trace/generated-tracers.h:17467:25: error: too many arguments for format 
[-Werror=format-extra-args]
 , env, frame_addr);
 ^
./trace/generated-tracers.h: In function 'trace_user_do_rt_sigreturn':
./trace/generated-tracers.h:17479:25: error: too many arguments for format 
[-Werror=format-extra-args]
 , env, frame_addr);
 ^
./trace/generated-tracers.h: In function 'trace_user_do_sigreturn':
./trace/generated-tracers.h:17491:25: error: too many arguments for format 
[-Werror=format-extra-args]
 , env, frame_addr);
 ^
./trace/generated-tracers.h: In function 'trace_user_s390x_restore_sigregs':
./trace/generated-tracers.h:17551:25: error: too many arguments for format 
[-Werror=format-extra-args]
 , env, sc_psw_addr, env_psw_addr);
 ^

Bisection is on going:
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/build-amd64.xen-build.html
but still has a ways to go.

Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] RFC Userspace hypercalls

[Andrew Cooper]

Hi,

I am in the middle of getting my Xen Test Framework working and usable.

Embarrassingly, the unit test I hacked up for investigating XSA-106
(which was the inspiration to make the framework) correctly identifies
the regression caused by XSA-156.  To avoid similar situations in the
future, I am getting the XTF usable as a matter of priority.

The XTF uses a flat, shared address space, with the test free to change
cpl at part of normal operation.  For the XSA-106 usecase, this was to
confirm that the x86 emulator correctly performed dpl checks on emulated
exception injection.

All console logging is synchronous (to ensure that log messages have
escaped the VM before an action occurs) and by default, an HVM test will
use the qemu debug port, console_io hypercall, and PV console (which
uses evtchn hypercalls).

This causes problems when the test moves into userspace.  The qemu debug
port can trivially be fixed by setting IOPL=3, but the hypercalls are
more problematic.  The HVM ABI (for whatever reason) unilaterally fails
a userspace hypercall with -EPERM, making it impossible for the kernel
to trap-and-forward even it wanted to.

There are already scenarios under test where we cannot rely on the test
kernel having a fully functioning set of entry points (e.g. the DPL part
of the test above).  Therefore I specifically want to make it possible
to make userspace hypercalls, rather than simply making them possible to
be trapped-and-forwarded.


As a result, I proposing introducing a hypercall which allows a domain
to adjust its entry criteria for hypercalls (e.g. set_hypercall_iopl). 
Doing this for HVM guests is straight forward, but PV guests are harder,
as they bounce through Xen entrypoints.

For PV guests, I propose that userspace hypercalls get implemented with
the int $0x82 path exclusively.  i.e. enabling userspace hypercalls
causes the hypercall page writing logic to consider the guest a ring1
kernel, and the int $0x82 entrypoint suitably delegates between a
regular hypercall and a compat hypercall.

Thoughts?

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [V9 2/3] Refactor rangeset structure for better performance.

[Jan Beulich]

>>> On 31.12.15 at 10:33,  wrote:
> On 12/21/2015 10:38 PM, Jan Beulich wrote:
> On 15.12.15 at 03:05,  wrote:
>>> This patch refactors struct rangeset to base it on the red-black
>>> tree structure, instead of on the current doubly linked list. By
>>> now, ioreq leverages rangeset to keep track of the IO/memory
>>> resources to be emulated. Yet when number of ranges inside one
>>> ioreq server is very high, traversing a doubly linked list could
>>> be time consuming. With this patch, the time complexity for
>>> searching a rangeset can be improved from O(n) to O(log(n)).
>>> Interfaces of rangeset still remain the same, and no new APIs
>>> introduced.
>>
>> So this indeed addresses one of the two original concerns. But
>> what about the other (resource use due to thousands of ranges
>> in use by a single VM)? IOW I'm still unconvinced this is the way
>> to go.
> 
> Thank you, Jan. As you saw in patch 3/3, the other concern was solved
> by extending the rangeset size, which may not be convictive for you.
> But I believe this patch - refactoring the rangeset to rb_tree, does
> not only solve XenGT's performance issue, but may also be helpful in
> the future, e.g. if someday the rangeset is not allocated in xen heap
> and can have a great number of ranges in it. :)

I don't follow: Patch 3 makes things worse resource consumption
wise, not better.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Jan Beulich]

>>> On 05.01.16 at 17:53,  wrote:
> On 12/22/15 10:09 AM, Jan Beulich wrote:
> On 22.12.15 at 17:02,  wrote:
>>> How does it not make sense in this case? That's what Andrew and I are
>>> asking you to explain.
>> 
>> But I already explained it: The file isn't needed for booting.
> 
> One use of it in /boot would be to check the file in 20_linux_xen like
> we check the kernel config for different options to add different
> parameters.

Which, if you search for it, is a very controversial thing: I agree
with the side demanding for grub to not inspect the kernel's
.config.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 12/31] tools: Utility for dealing with featuresets

[Ian Campbell]

On Wed, 2015-12-16 at 21:24 +, Andrew Cooper wrote:
> 
> +xen-cpuid.o: CFLAGS += -I$(XEN_ROOT)/xen/arch/x86/cpuid

Would it be possible to arrange for the headers we need here to be visible
in tools/include/xen instead via the links, like we do for libelf?


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4.4 2/2] libxl: Fix building libxlu_cfg_y.y with bison 3.0

[Jan Beulich]

>>> On 06.01.16 at 11:30,  wrote:
> On Wed, 2016-01-06 at 02:10 -0700, Jan Beulich wrote:
>> > > > On 04.01.16 at 15:50,  wrote:
>> > From: Ed Swierk 
>> > 
>> > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex
>> > scanner
>> >   parameter
>> > - Change deprecated %name-prefix= to %name-prefix
>> > 
>> > Tested against bison 2.4.1 and 3.0.2.
>> > 
>> > This is expected to sometimes (depending on timestamps and whether the
>> > bison input files are edited) break building on systems with ancient
>> > versions of bison.  Bison 2.4.1 is known to work and was released in
>> > December 2008.
>> > 
>> > Also, consquentially, regenerate bison output files with bison
>> > 1:2.5.dfsg-2.1 from Debian wheezy.
>> > 
>> > Signed-off-by: Ed Swierk 
>> > Acked-by: Ian Jackson 
>> > Tested-by: Wei Liu 
>> > Signed-off-by: Ian Jackson 
>> > Release-Acked-by: Konrad Rzeszutek Wilk 
>> > 
>> > (cherry picked from commit 7ba4cdfadd4f3c45d65ffe50e621759f458fedc0)
>> > 
>> > [ I have checked that rebuilding the bison and flex input produces no
>> >   further changes. -iwj ]
>> > 
>> > Signed-off-by: Ian Jackson 
>> 
>> Well, as indicated already when the original change went in, a
>> statement of compatibility back to a bison released in 2008 is
>> fine, but not really sufficient considering that e.g. compiler and
>> and binutils are permitted to older. I stopped objecting to the
>> change for -unstable at that time, but I'm not sure we want to
>> introduce such an incompatibility (the %name-prefix change)
>> with older bison in a wrap-up release. In the end the question
>> certainly is whether updating the build host distro for released
>> branches is a proper thing to do.
> 
> The outputs are checked in, which mitigates things somewhat since you
> wouldn't expect bison to actually be run unless you had edited the input
> files.
> 
> I suspect that in reality it is run needlessly in some cases, I'd say we
> should either fix that (might be hard, since it involves VCS setting 
> timestamps consistently) or at least provide a manual "never run bison" 
> switch.

But that's again something we may well do on -unstable, but I'd
be hesitant to backport such to (almost) retired branches.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xenfb.c: avoid expensive loops when prod <= out_cons

[Stefano Stabellini]

If the frontend sets out_cons to a value higher than out_prod, it will
cause xenfb_handle_events to loop about 2^32 times. Avoid that by using
better checks at the beginning of the function.

Signed-off-by: Stefano Stabellini 

diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 4e2a27a..f963cf2 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -789,10 +789,11 @@ static void xenfb_handle_events(struct XenFB *xenfb)
 
 prod = page->out_prod;
 out_cons = page->out_cons;
-if (prod == out_cons)
-   return;
+if (prod <= out_cons) {
+return;
+}
 xen_rmb(); /* ensure we see ring contents up to prod */
-for (cons = out_cons; cons != prod; cons++) {
+for (cons = out_cons; cons < prod; cons++) {
union xenfb_out_event *event = _OUT_RING_REF(page, cons);
 uint8_t type = event->type;
int x, y, w, h;

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-squeeze test] 38595: all pass

[Platform Team regression test user]

flight 38595 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38595/

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38573

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubpass
 test-amd64-i386-amd64-squeeze-netboot-pygrub pass
 test-amd64-amd64-i386-squeeze-netboot-pygrub pass
 test-amd64-i386-i386-squeeze-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] question about migration

[Ian Campbell]

On Tue, 2016-01-05 at 18:17 +, Ian Jackson wrote:

> So any code trying to use this for your snapshotting case is already
> broken and cannot be fixed without introducing a new API (probably one
> which generates separate suspend/unsuspend events).

Remus does seem to work at least to the extent that it seems not to be
hitting this case though? Or at least I assume so since people have
reported various cases as working. Or maybe no one ever did "xl shutdown"
after checkpointing so this went unnoticed.

I'm trying to decide if this is "it's completely knackered" for "fails in
some corner cases".

> (We can't have libxl_evenable_domain_death generate new unsuspend
> events because existing callers won't understand.)

Can we make it so that the new API can be extended in this way, even if we
just document "ignore unknown events"?

> I therefore propose that:
> 
> libxl_evenable_domain_death should never generate DOMAIN_SHUTDOWN with
> reason code suspended.

FWIW libvirt ignores these (and as we know xl incorrectly exits). I guess
we think it unlikely that anything could be relying on the current
behaviour?

OOI would calling libxl_evdisable_domain_death+libxl_evenable_domain_death
reset the one-shot nature of this event?

>   Instead, it should hope that the domain will
> go back to running.  If the domain ends up shut down for some other
> reason, or is destroyed, it should report those things.
> 
> In the future we introduce libxl_evenable_domain_state which generates
> the existing events from libxl_evenable_domain_death but also two new
> events DOMAIN_SUSPENDED or DOMAIN_RUNNING.

I infer that this new function will take a mask of domain states which the
caller is interested in (and hence is extensible)?

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Ian Campbell]

On Wed, 2016-01-06 at 02:22 -0700, Jan Beulich wrote:
> > > > On 05.01.16 at 17:53,  wrote:
> > On 12/22/15 10:09 AM, Jan Beulich wrote:
> > > > > > On 22.12.15 at 17:02,  wrote:
> > > > How does it not make sense in this case? That's what Andrew and I
> > > > are
> > > > asking you to explain.
> > > 
> > > But I already explained it: The file isn't needed for booting.
> > 
> > One use of it in /boot would be to check the file in 20_linux_xen like
> > we check the kernel config for different options to add different
> > parameters.
> 
> Which, if you search for it, is a very controversial thing: I agree
> with the side demanding for grub to not inspect the kernel's
> .config.

What is the preferred mechanism for determining from the contents of /boot
whether an XSM entry should be produced or not?

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4.4 2/2] libxl: Fix building libxlu_cfg_y.y with bison 3.0

[Ian Campbell]

On Wed, 2016-01-06 at 02:10 -0700, Jan Beulich wrote:
> > > > On 04.01.16 at 15:50,  wrote:
> > From: Ed Swierk 
> > 
> > - Use %lex-param instead of obsolete YYLEX_PARAM to override lex
> > scanner
> >   parameter
> > - Change deprecated %name-prefix= to %name-prefix
> > 
> > Tested against bison 2.4.1 and 3.0.2.
> > 
> > This is expected to sometimes (depending on timestamps and whether the
> > bison input files are edited) break building on systems with ancient
> > versions of bison.  Bison 2.4.1 is known to work and was released in
> > December 2008.
> > 
> > Also, consquentially, regenerate bison output files with bison
> > 1:2.5.dfsg-2.1 from Debian wheezy.
> > 
> > Signed-off-by: Ed Swierk 
> > Acked-by: Ian Jackson 
> > Tested-by: Wei Liu 
> > Signed-off-by: Ian Jackson 
> > Release-Acked-by: Konrad Rzeszutek Wilk 
> > 
> > (cherry picked from commit 7ba4cdfadd4f3c45d65ffe50e621759f458fedc0)
> > 
> > [ I have checked that rebuilding the bison and flex input produces no
> >   further changes. -iwj ]
> > 
> > Signed-off-by: Ian Jackson 
> 
> Well, as indicated already when the original change went in, a
> statement of compatibility back to a bison released in 2008 is
> fine, but not really sufficient considering that e.g. compiler and
> and binutils are permitted to older. I stopped objecting to the
> change for -unstable at that time, but I'm not sure we want to
> introduce such an incompatibility (the %name-prefix change)
> with older bison in a wrap-up release. In the end the question
> certainly is whether updating the build host distro for released
> branches is a proper thing to do.

The outputs are checked in, which mitigates things somewhat since you
wouldn't expect bison to actually be run unless you had edited the input
files.

I suspect that in reality it is run needlessly in some cases, I'd say we
should either fix that (might be hard, since it involves VCS setting timestamps 
consistently) or at least provide a manual "never run bison" switch.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [xen-unstable test] 76919: regressions - FAIL

[Ian Campbell]

On Tue, 2016-01-05 at 02:26 +, osstest service owner wrote:
> flight 76919 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/76919/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
> fail REGR. vs. 66879

ISTR someone (Wei?) at some point saying that a 32-bit stubdom (as used
here) isn't actually something we wish to support. Shall we either drop
this test altogether or mark it as allow? Or will someone investigate why
it apparently can't find its disks.

http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html

seems to suggest it has a very low probability of success (both merlot and
italia failed dozens of times before passing)

Nothing in the xen.git range bf925a9f1254..8e4d18e113c9 looks especially
relevant.

Bisection couldn't reproduce the basis pass:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.html

Ian.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/5] ns16550: widen an integer constant for Coverity.

[Jan Beulich]

>>> On 04.01.16 at 17:36,  wrote:
> On Mon, 2015-12-28 at 00:16 -0500, Joshua Otto wrote:
>> Fix CID 1343302 by widening a constant used with uart_param.reg_shift to
>> avoid overflow for large values of reg_shift.
> 
> A reg_shift large enough to actually expose this would be infeasibly large
> (since it would imply a UART taking practically the entire virtual address
> space of the processor).
> 
> So while Coverity is likely correct here, it is probably also a bit
> misguided in the context.
> 
> I don't especially object to this change as means to quieten coverity, but
> perhaps checking for some sane limit to reg_shift would also serve to
> quieten coverity?

Indeed I'd prefer an alternative change to be found, as 64-bit
arithmetic is quite pointless here.

>> Signed-off-by: Harley Armstrong 
>> ---
>>  xen/drivers/char/ns16550.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
>> index bc24015..546bba1 100644
>> --- a/xen/drivers/char/ns16550.c
>> +++ b/xen/drivers/char/ns16550.c
>> @@ -913,7 +913,7 @@ pci_uart_config(struct ns16550 *uart, bool_t
>> skip_amt, unsigned int bar_idx)
>>   * Force length of mmio region to be at least
>>   * 8 bytes times (1 << reg_shift)
>>  */
>> -if ( size < (0x8 * (1 << uart_param[p].reg_shift)) )
>> +if ( size < (0x8 * (1ull << 
>> uart_param[p].reg_shift)) )
> 
> It looks from the surrounding code like
>   ... < (0x8 * ((u64)1 << uart_param[p].reg_shift)) )
> 
> would be the preferred way of tackling this.

If we were to really stay with a change to this line, then the
multiplication should go away altogether, since just a shift
will always suffice.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue.

[Xu, Quan]

> On December 25 2015, 11:06 AM,  wrote: 
> > From: Xu, Quan
> > Sent: Wednesday, December 23, 2015 4:26 PM
> >
> > Now if IOTLB/Context/IETC flush is timeout, panic hypervisor.
> > The coming patch set will fix it.
> 
> again, please adjust comment to reflect what this patch is doing, i.e. only 
> about
> improvement on Device-TLB flush.
> 

Agreed.

> >
> > If Device-TLB flush is timeout, we'll hide the target ATS device and
> > crash the domain owning this ATS device.
> >
> > If impacted domain is hardware domain, just throw out a warning.
> >
> > The hided Device will be disallowed to be further assigned to any
> > domain.
> 
> hided Device -> hidden device
> 

Agreed.

[...]

> > diff --git a/xen/drivers/passthrough/vtd/qinval.c
> > b/xen/drivers/passthrough/vtd/qinval.c
> > index b227e4e..7330c5d 100644
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -190,9 +190,19 @@ static int queue_invalidate_wait(struct iommu
> > *iommu,  static int invalidate_sync(struct iommu *iommu)  {
> >  struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
> > +int rc;
> >
> >  if ( qi_ctrl->qinval_maddr )
> > -return queue_invalidate_wait(iommu, 0, 1, 1);
> > +{
> > +rc = queue_invalidate_wait(iommu, 0, 1, 1);
> > +if ( rc )
> > +{
> > +if ( rc == -ETIMEDOUT )
> > +panic("Queue invalidate wait descriptor was
> timeout.\n");
> > +return rc;
> > +}
> > +}
> > +
> 
> why do you still do panic here? w/ PATCH 1/3 you should return rc to caller
> directly, right?
> 

This panic is original in queue_invalidate_wait(). Patch 1/3 is just for 
Device-TLB flush error ( Actually it covers iotlb flush error).
If I fix VT-d iotlb/context/iec flush error to propagated callers, then I can 
remove this panic and return rc to propagated caller directly.



> > +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
> > + u16 seg, u8 bus, u8 devfn)
> {
> > +struct domain *d;
> > +struct pci_dev *pdev;
> > +
> > +d = rcu_lock_domain_by_id(iommu->domid_map[did]);
> > +ASSERT(d);
> > +for_each_pdev(d, pdev)
> > +{
> > +if ( (pdev->seg == seg) &&
> > + (pdev->bus == bus) &&
> > + (pdev->devfn == devfn) )
> > +{
> > +if ( pdev->domain )
> > +{
> > +list_del(>domain_list);
> > +pdev->domain = NULL;
> > +}
> > +
> > +if ( pci_hide_device(bus, devfn) )
> > +{
> > +printk(XENLOG_ERR
> > +   "IOMMU hide device %04x:%02x:%02x error.",
> > +   seg, bus, devfn);
> > +break;
> > +}
> 
> I'm not sure whether using pci_hide_device is enough or not break other code
> path here? For example, now you have errors propagated to callers.

More information, after call pci_hide_device(),
..
 pdev->domain = dom_xen;
 list_add(>domain_list, _xen->arch.pdev_list);
..

Hidden PCI devices are associated with 'dom_xen'.
Now I found it may not clear rmrr mapping / context mapping. .i.e 
iommu_remove_device() -- [hd->platform_ops is NULL for dom_xen].
But I think it is acceptable, IMO dom_xen is a part hypervisor, and there 
mappings would not a security issue.
Or I can remove these mappings before to hide this device.

So I think it will not break other code break other code.

> What's the
> final policy against flush error? 
>

If Device-TLB flush is timeout, we'll hide the target ATS device and crash the 
domain owning this ATS device.
If impacted domain is hardware domain, just throw out a warning, instead of 
crash the hardware domain.
The hided Device will be disallowed to be further assigned to any domain.



>If they will finally go to cleanup some more state
> relying on pdev->domain, then that code path might be broken. If it's fine to 
> do
> cleanup at this point, then just hidden is not enough. If you look at
> pci_remove_device, there's quite some state to be further cleaned up...
> 


As the pdev->domain is 'dom_xen';
So for this case, it is still working. Correct me if it is not correct.
BTW, a quick question, which case to call pci_remove_device()?


> I didn't think about the full logic thoroughly now. But it would always be 
> good
> to not hide device now until a point where all related states have been 
> cleaned
> up in error handling path chained up.
> 
 
Quan



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5] x86/VPMU: implement ipc and arch filter flags

[Jan Beulich]

>>> On 05.01.16 at 02:43,  wrote:
> This introduces a way to have a restricted VPMU, by specifying one of two
> predefined groups of PMCs to make available. For secure environments, this
> allows the VPMU to be used without needing to enable all PMCs.
> 
> Signed-off-by: Brendan Gregg 
> Reviewed-by: Boris Ostrovsky 

Does this hold with ...

> ---
> Changes in v5:
> * addressing review comments from Kevin:
> * simplified BTS DS_AREA filter
> * improvements to comments, incl. matching Intel SDM descriptions

... all of these?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Tamas K Lengyel]

On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich  wrote:

> >>> On 23.12.15 at 15:53,  wrote:
> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
> vm_event_request_t *req)
> >  vm_event_vcpu_pause(curr);
> >  }
> >
> > +if ( altp2m_active(currd) )
> > +{
> > +req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> > +req->altp2m_idx = vcpu_altp2m(curr).p2midx;
> > +}
>
> So far this info was provided just for MEM_ACCESS events. Now
> you provide it for a few more ones, but wouldn't this then better
> be supplied for all of them, namely also the other two MEM ones?
>

AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure but
I think it's also incompatible with paging.

Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [qemu-mainline test] 76949: regressions - FAIL

[Ian Campbell]

On Wed, 2016-01-06 at 11:52 +, Anthony PERARD wrote:
> On Wed, Jan 06, 2016 at 11:32:31AM +, Ian Campbell wrote:
> > Stefano, Anthony,
> > 
> > On Mon, 2016-01-04 at 14:17 +, osstest service owner wrote:
> > > flight 76949 qemu-mainline real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/76949/
> > > 
> > > Regressions :-(
> > > 
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  build-i3865 xen-build fail REGR.
> > > vs. 66433
> > >  build-amd64-xsm   5 xen-build fail REGR.
> > > vs. 66433
> > >  build-amd64   5 xen-build fail REGR.
> > > vs. 66433
> > >  build-i386-xsm5 xen-build fail REGR.
> > > vs. 66433
> > >  build-armhf-xsm   5 xen-build fail REGR.
> > > vs. 66433
> > >  build-armhf   5 xen-build fail REGR.
> > > vs. 66433
> > 
> > Any idea what is going on here or if there is a fix in the works? It's
> > been
> > failing since 17/12 last year.
> 
> There are several patches on the qemu-devel list for this broken build.
> Should be fix soon-ish.

Thanks.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4.4 2/2] libxl: Fix building libxlu_cfg_y.y with bison 3.0

[Jan Beulich]

>>> On 04.01.16 at 15:50,  wrote:
> From: Ed Swierk 
> 
> - Use %lex-param instead of obsolete YYLEX_PARAM to override lex scanner
>   parameter
> - Change deprecated %name-prefix= to %name-prefix
> 
> Tested against bison 2.4.1 and 3.0.2.
> 
> This is expected to sometimes (depending on timestamps and whether the
> bison input files are edited) break building on systems with ancient
> versions of bison.  Bison 2.4.1 is known to work and was released in
> December 2008.
> 
> Also, consquentially, regenerate bison output files with bison
> 1:2.5.dfsg-2.1 from Debian wheezy.
> 
> Signed-off-by: Ed Swierk 
> Acked-by: Ian Jackson 
> Tested-by: Wei Liu 
> Signed-off-by: Ian Jackson 
> Release-Acked-by: Konrad Rzeszutek Wilk 
> 
> (cherry picked from commit 7ba4cdfadd4f3c45d65ffe50e621759f458fedc0)
> 
> [ I have checked that rebuilding the bison and flex input produces no
>   further changes. -iwj ]
> 
> Signed-off-by: Ian Jackson 

Well, as indicated already when the original change went in, a
statement of compatibility back to a bison released in 2008 is
fine, but not really sufficient considering that e.g. compiler and
and binutils are permitted to older. I stopped objecting to the
change for -unstable at that time, but I'm not sure we want to
introduce such an incompatibility (the %name-prefix change)
with older bison in a wrap-up release. In the end the question
certainly is whether updating the build host distro for released
branches is a proper thing to do.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Lars Kurth]

Hi folks,
let me introduce you to Xudong from Intel, who is willing to help out.
Best Regards
Lars

> On 4 Jan 2016, at 15:41, Stefano Stabellini 
>  wrote:
> 
> On Mon, 4 Jan 2016, Lars Kurth wrote:
>> On 04/01/2016 14:47, "Stefano Stabellini"
>>  wrote:
>> 
>>> Unfortunately I don't have a setup to test this either. Maybe Lars can
>>> find out who should be involved on the Intel side on this.
>> 
>> I can certainly help to this and get back to you. What exactly are we
>> asking Intel to do?
>> It is not clear to me from this email thread
> 
> Tiejun Chen, the author of the Intel graphic card passthrough patches
> for QEMU, seems to have left the company. It would be nice if somebody
> else tested this patch with an intel graphic card assigned to a guest
> VM.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Jan Beulich]

>>> On 06.01.16 at 11:31,  wrote:
> On Wed, 2016-01-06 at 02:22 -0700, Jan Beulich wrote:
>> > > > On 05.01.16 at 17:53,  wrote:
>> > On 12/22/15 10:09 AM, Jan Beulich wrote:
>> > > > > > On 22.12.15 at 17:02,  wrote:
>> > > > How does it not make sense in this case? That's what Andrew and I
>> > > > are
>> > > > asking you to explain.
>> > > 
>> > > But I already explained it: The file isn't needed for booting.
>> > 
>> > One use of it in /boot would be to check the file in 20_linux_xen like
>> > we check the kernel config for different options to add different
>> > parameters.
>> 
>> Which, if you search for it, is a very controversial thing: I agree
>> with the side demanding for grub to not inspect the kernel's
>> .config.
> 
> What is the preferred mechanism for determining from the contents of /boot
> whether an XSM entry should be produced or not?

I don't think this can be inferred - iirc even an XSM-enabled build
can be booted without unless in some kind of strict mode? IOW
this needs to be configured on the host, not guessed by
inspecting .config. (And as a side note, inspecting .config doesn't
truly require .config to be on the boot partition, unless such
inspection would happen at boot time, which I don't think is the
case.)

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3.16.y-ckt 019/126] x86/cpu: Fix SMAP check in PVOPS environments

[Luis Henriques]

3.16.7-ckt22 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andrew Cooper 

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper 
Reviewed-by: David Vrabel 
Tested-by: Rusty Russell 
Cc: Rusty Russell 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: 
Cc: Xen-devel 
Link: 
http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.coop...@citrix.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Luis Henriques 
---
 arch/x86/kernel/cpu/common.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8fc57acf86f4..3b12b4d1a560 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -282,10 +282,9 @@ __setup("nosmap", setup_disable_smap);
 
 static __always_inline void setup_smap(struct cpuinfo_x86 *c)
 {
-   unsigned long eflags;
+   unsigned long eflags = native_save_fl();
 
/* This should have been cleared long ago */
-   raw_local_save_flags(eflags);
BUG_ON(eflags & X86_EFLAGS_AC);
 
if (cpu_has(c, X86_FEATURE_SMAP)) {

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Jan Beulich]

>>> On 23.12.15 at 15:53,  wrote:
> @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync, 
> vm_event_request_t *req)
>  vm_event_vcpu_pause(curr);
>  }
>  
> +if ( altp2m_active(currd) )
> +{
> +req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> +req->altp2m_idx = vcpu_altp2m(curr).p2midx;
> +}

So far this info was provided just for MEM_ACCESS events. Now
you provide it for a few more ones, but wouldn't this then better
be supplied for all of them, namely also the other two MEM ones?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [xen-4.4-testing test] 66583: regressions - FAIL

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [xen-4.4-testing test] 66583: regressions 
- FAIL"):
> Aha, this failure is in tools/blktap/drivers/block-qcow.c and not
> tools/blktap2/drivers/block-qcow.c. 

Well spotted.

> 345e44a85d71 was writing after blktap1 was remove from the tree so
> backporting it wouldn't have helped.

Right.

> $ git show 345e44a85d71a | patch tools/blktap/drivers/block-qcow.c
> patching file tools/blktap/drivers/block-qcow.c
> Hunk #1 succeeded at 440 (offset 13 lines).
> Hunk #2 succeeded at 614 (offset 13 lines).
> $ 
> 
> Seems like the way to go for all branches which still have blktap1 (4.5 and
> back, although it was disabled by default in 76c66c689b85 which was in
> 4.4.0-rc1.

I have done roughly this, to 4.3-4.5 inclusive.

Ian.

commit a64bfae49ae845ba4cb8cb6923fa08c41439872a
Author: Dario Faggioli 
Date:   Fri Jun 20 16:09:00 2014 +0200

blktap: Fix two 'maybe uninitialized' variables

[ Cross-ported to blktap1 from 345e44a85d71a
  "blktap2: Fix two 'maybe uninitialized' variables" -iwj;
  Remainder of commit message is from blktap2's version. ]

for which gcc 4.9.0 complains about, like this:

block-qcow.c: In function `get_cluster_offset':
block-qcow.c:431:3: error: `tmp_ptr' may be used uninitialized in this 
function
[-Werror=maybe-uninitialized]
   memcpy(tmp_ptr, l1_ptr, 4096);
   ^
block-qcow.c:606:7: error: `tmp_ptr2' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
   if (write(s->fd, tmp_ptr2, 4096) != 4096) {
   ^
cc1: all warnings being treated as errors

/home/dario/Sources/xen/xen/xen.git/tools/blktap2/drivers/../../../tools/Rules.mk:89:
 recipe for target 'block-qcow.o' failed
make[5]: *** [block-qcow.o] Error 1

The proper behavior is to return upon allocation failure.
About what to return, 0 seems the best option, looking
at both the function and the call sites.

Signed-off-by: Dario Faggioli 
Acked-by: Ian Jackson 

Backport-requested-by: Ian Campbell 
Signed-off-by: Ian Jackson 
(cherry picked from commit 845e8c1653242bbd9b9de5a081182db0f3f39054)
(cherry picked from commit e003d429d8c63523df40663b4586c572ce796659)

diff --git a/tools/blktap/drivers/block-qcow.c 
b/tools/blktap/drivers/block-qcow.c
index 0e4e9cf..8fb6023 100644
--- a/tools/blktap/drivers/block-qcow.c
+++ b/tools/blktap/drivers/block-qcow.c
@@ -440,6 +440,7 @@ static uint64_t get_cluster_offset(struct tdqcow_state *s,
 
if (posix_memalign((void **)_ptr, 4096, 4096) != 0) {
DPRINTF("ERROR allocating memory for L1 table\n");
+return 0;
}
memcpy(tmp_ptr, l1_ptr, 4096);
 
@@ -613,6 +614,7 @@ found:

if (posix_memalign((void **)_ptr2, 4096, 4096) != 0) {
DPRINTF("ERROR allocating memory for L1 table\n");
+return 0;
}
memcpy(tmp_ptr2, l2_ptr, 4096);
lseek(s->fd, l2_offset + (l2_sector << 12), SEEK_SET);

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [V9 2/3] Refactor rangeset structure for better performance.

[Jan Beulich]

>>> On 06.01.16 at 10:46,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 06 January 2016 08:53
>> >>> On 31.12.15 at 10:33,  wrote:
>> > On 12/21/2015 10:38 PM, Jan Beulich wrote:
>> > On 15.12.15 at 03:05,  wrote:
>> >>> This patch refactors struct rangeset to base it on the red-black
>> >>> tree structure, instead of on the current doubly linked list. By
>> >>> now, ioreq leverages rangeset to keep track of the IO/memory
>> >>> resources to be emulated. Yet when number of ranges inside one
>> >>> ioreq server is very high, traversing a doubly linked list could
>> >>> be time consuming. With this patch, the time complexity for
>> >>> searching a rangeset can be improved from O(n) to O(log(n)).
>> >>> Interfaces of rangeset still remain the same, and no new APIs
>> >>> introduced.
>> >>
>> >> So this indeed addresses one of the two original concerns. But
>> >> what about the other (resource use due to thousands of ranges
>> >> in use by a single VM)? IOW I'm still unconvinced this is the way
>> >> to go.
>> >
>> > Thank you, Jan. As you saw in patch 3/3, the other concern was solved
>> > by extending the rangeset size, which may not be convictive for you.
>> > But I believe this patch - refactoring the rangeset to rb_tree, does
>> > not only solve XenGT's performance issue, but may also be helpful in
>> > the future, e.g. if someday the rangeset is not allocated in xen heap
>> > and can have a great number of ranges in it. :)
>> 
>> I don't follow: Patch 3 makes things worse resource consumption
>> wise, not better.
>> 
> 
> Yes, it allows the rangeset to grow larger. Would it be better to tie 
> emulation rangesets to a specific domain and have the rangeset limits defined 
> for the domain by the toolstack?

In fact that's what I had suggested in reply to 3/3 at about the same
time as the mail you've replied to here.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [V9 3/3] Differentiate IO/mem resources tracked by ioreq server

[Jan Beulich]

>>> On 06.01.16 at 10:44,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 06 January 2016 08:59
>> To: Zhang Yu
>> Cc: Andrew Cooper; Paul Durrant; Wei Liu; Ian Jackson; Stefano Stabellini;
>> Kevin Tian; zhiyuan...@intel.com; Shuai Ruan; xen-devel@lists.xen.org; Keir
>> (Xen.org)
>> Subject: Re: [Xen-devel] [V9 3/3] Differentiate IO/mem resources tracked by
>> ioreq server
>> 
>> >>> On 31.12.15 at 10:33,  wrote:
>> > On 12/21/2015 10:45 PM, Jan Beulich wrote:
>> > On 15.12.15 at 03:05,  wrote:
>> >>> @@ -2593,6 +2597,16 @@ struct hvm_ioreq_server
>> *hvm_select_ioreq_server(struct domain *d,
>> >>>   type = (p->type == IOREQ_TYPE_PIO) ?
>> >>>   HVMOP_IO_RANGE_PORT : HVMOP_IO_RANGE_MEMORY;
>> >>>   addr = p->addr;
>> >>> +if ( type == HVMOP_IO_RANGE_MEMORY )
>> >>> +{
>> >>> + ram_page = get_page_from_gfn(d, p->addr >> PAGE_SHIFT,
>> >>> +  , P2M_UNSHARE);
>> >>> + if ( p2mt == p2m_mmio_write_dm )
>> >>> + type = HVMOP_IO_RANGE_WP_MEM;
>> >>> +
>> >>> + if ( ram_page )
>> >>> + put_page(ram_page);
>> >>> +}
>> >>
>> >> You evaluate the page's current type here - what if it subsequently
>> >> changes? I don't think it is appropriate to leave the hypervisor at
>> >> the mercy of the device model here.
>> >
>> > Well. I do not quite understand your concern. :)
>> > Here, the get_page_from_gfn() is used to determine if the addr is a MMIO
>> > or a write-protected ram. If this p2m type is changed, it should be
>> > triggered by the guest and device model, e.g. this RAM is not supposed
>> > to be used as the graphic translation table. And it should be fine.
>> > But I also wonder, if there's any other routine more appropriate to get
>> > a p2m type from the gfn?
>> 
>> No, the question isn't the choice of method to retrieve the
>> current type, but the lack of measures against the retrieved
>> type becoming stale by the time you actually use it.
> 
> I don't think that issue is specific to this code. AFAIK nothing in the I/O 
> emulation system protects against a type change whilst a request is in 
> flight.
> Also, what are the consequences of a change? Only that the wrong range type 
> is selected and the emulation goes to the wrong place. This may be a problem 
> for the VM but should cause no other problems.

Okay, I buy this argument, but I think it would help if that was spelled
out this way in the commit message.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH v2] support XSM/FLASK via Kconfig

[Ian Campbell]

On Tue, 2016-01-05 at 23:25 -0600, Doug Goldstein wrote:
> In antcipation of XSM and FLASK migrating to Kconfig add support for
> building them via Kconfig or the existing mechanism.
> 
> Signed-off-by: Doug Goldstein 
> ---
> Still untested but visually looks correct.
> 
> Changes since v2:
> - Support Xen versions prior to Kconfig being integrated

Do we not need the gate on the first hunk as well? 

A non-Kconfig aware would ignore the xen/.config but osstest will collect
it later on and that might confuse folks reading the logs.

Such a Xen also won't have a .gitignore entry for xen/.config, so various
git commands might show this tree as dirty. I don't think osstest would
rely on such though, so maybe this doesn't really matter. I don't think
xen/scripts/scmversion adds -dirty in this case either.

> ---
>  ts-xen-build | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/ts-xen-build b/ts-xen-build
> index 80b1faa..8dde146 100755
> --- a/ts-xen-build
> +++ b/ts-xen-build
> @@ -55,6 +55,8 @@ sub checkout () {
>   echo >>.config KERNELS=''
>  END
> (nonempty($r{enable_xsm}) ? < + echo >>xen/.config CONFIG_XSM='${build_xsm}'
> + echo >>xen/.config CONFIG_FLASK='${build_xsm}'
>   echo >>.config XSM_ENABLE='${build_xsm}'
>  END
> (nonempty($r{tree_qemu}) ? < @@ -126,6 +128,9 @@ END
>  END
>  #/;
>  buildcmd_stamped_logged(9000, 'build', '',< +if test -f xen/Kconfig; then
> +$make_prefix make -C xen olddefconfig
> +fi
>  $make_prefix make $makeflags @ARGV
>  END
>  

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC 12/31] tools: Utility for dealing with featuresets

[Ian Campbell]

On Wed, 2016-01-06 at 10:40 +, Ian Campbell wrote:
> On Wed, 2015-12-16 at 21:24 +, Andrew Cooper wrote:
> >  
> > +xen-cpuid.o: CFLAGS += -I$(XEN_ROOT)/xen/arch/x86/cpuid
> 
> Would it be possible to arrange for the headers we need here to be visible
> in tools/include/xen instead via the links, like we do for libelf?

... assuming this is still necessary once the mechanism for exporting this
data to applications via libxc is fixed, which now I think about it it
probably won't be.

Ian.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Tamas K Lengyel]

On Wed, Jan 6, 2016 at 12:48 PM, Andrew Cooper 
wrote:

> On 06/01/16 11:42, Tamas K Lengyel wrote:
>
>
>
> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich  wrote:
>
>> >>> On 23.12.15 at 15:53, < ta...@tklengyel.com>
>> wrote:
>> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
>> vm_event_request_t *req)
>> >  vm_event_vcpu_pause(curr);
>> >  }
>> >
>> > +if ( altp2m_active(currd) )
>> > +{
>> > +req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>> > +req->altp2m_idx = vcpu_altp2m(curr).p2midx;
>> > +}
>>
>> So far this info was provided just for MEM_ACCESS events. Now
>> you provide it for a few more ones, but wouldn't this then better
>> be supplied for all of them, namely also the other two MEM ones?
>>
>
> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure but
> I think it's also incompatible with paging.
>
>
> I don't think they are strictly incompatible; I don't see a technical
> reason preventing some development work to make them function together.
>
> Whether this happens or not is a very different matter.
>

Sure, the two systems can be made to work in tandem, this work just hasn't
been done yet. I would very much like to get that to work in the future.

Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [PATCH] build: save generated config in 
/boot"):
> On 06.01.16 at 11:31,  wrote:
> > What is the preferred mechanism for determining from the contents of /boot
> > whether an XSM entry should be produced or not?
> 
> I don't think this can be inferred - iirc even an XSM-enabled build
> can be booted without unless in some kind of strict mode? IOW
> this needs to be configured on the host, not guessed by
> inspecting .config. (And as a side note, inspecting .config doesn't
> truly require .config to be on the boot partition, unless such
> inspection would happen at boot time, which I don't think is the
> case.)

Well, actually, it _can_ be inferred.  Therefore it should be.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xenfb.c: avoid expensive loops when prod <= out_cons

[David Vrabel]

On 06/01/16 12:08, Stefano Stabellini wrote:
> If the frontend sets out_cons to a value higher than out_prod, it will
> cause xenfb_handle_events to loop about 2^32 times. Avoid that by using
> better checks at the beginning of the function.

You can't use less than to compare prod and cons because they wrap.

You need to compare (prod - cons) against ring size (or similar) to
check for overflow.  See RING_REQUEST_PROD_OVERFLOW() etc.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH] xenfb.c: avoid expensive loops when prod <= out_cons

[Paul Durrant]

> -Original Message-
> From: qemu-devel-bounces+paul.durrant=citrix@nongnu.org
> [mailto:qemu-devel-bounces+paul.durrant=citrix@nongnu.org] On
> Behalf Of Stefano Stabellini
> Sent: 06 January 2016 12:08
> To: qemu-de...@nongnu.org
> Cc: liuling...@360.cn; xen-de...@lists.xensource.com; Stefano Stabellini
> Subject: [Qemu-devel] [PATCH] xenfb.c: avoid expensive loops when prod
> <= out_cons
> 
> If the frontend sets out_cons to a value higher than out_prod, it will
> cause xenfb_handle_events to loop about 2^32 times. Avoid that by using
> better checks at the beginning of the function.
> 

What happens when out_prod wraps?

  Paul

> Signed-off-by: Stefano Stabellini 
> 
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 4e2a27a..f963cf2 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -789,10 +789,11 @@ static void xenfb_handle_events(struct XenFB
> *xenfb)
> 
>  prod = page->out_prod;
>  out_cons = page->out_cons;
> -if (prod == out_cons)
> - return;
> +if (prod <= out_cons) {
> +return;
> +}
>  xen_rmb();   /* ensure we see ring contents up to prod */
> -for (cons = out_cons; cons != prod; cons++) {
> +for (cons = out_cons; cons < prod; cons++) {
>   union xenfb_out_event *event = _OUT_RING_REF(page,
> cons);
>  uint8_t type = event->type;
>   int x, y, w, h;


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Jan Beulich]

>>> On 06.01.16 at 12:58,  wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH] build: save generated config in 
> /boot"):
>> On 06.01.16 at 11:31,  wrote:
>> > What is the preferred mechanism for determining from the contents of /boot
>> > whether an XSM entry should be produced or not?
>> 
>> I don't think this can be inferred - iirc even an XSM-enabled build
>> can be booted without unless in some kind of strict mode? IOW
>> this needs to be configured on the host, not guessed by
>> inspecting .config. (And as a side note, inspecting .config doesn't
>> truly require .config to be on the boot partition, unless such
>> inspection would happen at boot time, which I don't think is the
>> case.)
> 
> Well, actually, it _can_ be inferred.  Therefore it should be.

You mean from the presence of the policy file (which ends up
being a container of garbage for a non-XSM-Xen)? If not -
what else do you think the need for an XSM entry can be
derived from?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Lenovo X200 IOMMU support through Xen 4.6 iommu=no-igfx switch

[Jan Beulich]

>>> On 22.12.15 at 19:04,  wrote:
> iommu=no-igfx is a gamechanger for Qubes support through 3.1 RC1 release,
> thanks to Xen 4.6 :)
> 
> The Lenovo X200 supports vt-x, vt-d and TPM as reported and required by
> Qubes in the HCL attached to this e-mail. The problem is that when Qubes
> launches it's netvm which uses IOMMU to talk to it's network card, it
> freezes the whole system up. Even when specifying sync_console, I don't get
> much more verbosity. I ordered a PCMCIA to serial adapter which will be
> shipped to my door late January... Meanwhile, booting with iommu=0 makes
> things work, but a potential hardware component being compromised has
> chances to compromise the whole system since compartmentalization is not
> guaranteed without IOMMU (vt-d).
> 
> A little more love is needed from xen to make that laptop line supported by
> Qubes and a nice alternative to the costy Librem currently promoted by
> Qubes-Purism
> partnership

Is all of the above and below a quite complicated way of expressing
that you'd like to see commit 146341187a backported to 4.6.x?

Jan

>  urisms-security-focused-librem-13-laptop/>which
> suggest that the laptop will be Respect Your Freedom compliant in the
> future with Intel participation in removing ME and AMT
> , which is not guaranteed at all.
>   
> d>
> If Xen 4.6 can cooperate with Penryn GM45 chipset, it's all MiniFree laptops
>  (and Libreboot support of
> those ) that will be potential
> candidates!
> Please share the love so that the community has a cheap alternative.
> 
> Requirements to replicate bug:
> Model: X200 745434U with p8700 CPU running 1067a microcode(important),
> upgrable to 8go
> BIOS: Lenovo 3.22/1.07 (latest from 2013
> )
> Network card supports FLReset+ as requested here
> .
> Bios settings: vt-d and vt-x needs to be enforced.
> Xen command line option required
>  to boot:
> iommu=no-igfx
> 
> Here is the current debug trace/status on Qubes side of things
> .
> If you have any hint, please contribute :)
> 
> Help me say happy new years to all security conscious people out there :)
> 
> Merry Christmas all,
> Thierry Laurion
> 
> 
> 
> 
> 
> -- 
> Thierry Laurion




___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] OVMF related osstest failures on multiple branches

[Ian Campbell]

These two tests are failing all over the place at the moment:
test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install
test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install

For the rest of this mail I will only consider the test-amd64-amd64-* one,
assuming they are the same.

The issues appear to have started on 18/12 last year.

Affected branches seem to be:
xen-4.6-testing, xen-4.5-testing, xen-4.4-testing
qemu-upstream-4.6-testing, qemu-upstream-4.5-testing, 
qemu-upstream-4.4-testing

xen-unstable appears to be unaffected.

qemu-mainline is blocked by a build failure.

qemu-upstream-unstable is OK, it had a pass on 18/12, so it's possible that
if the issue is elsewhere this tree simply hasn't seen it yet.

(links to all branch histories are below for convenience)

All branches have had a pass with ovmf revision cb9a7ebabcd6 and are still
using that version now during the failures. I don't think this is an
ovmf.git issue.

In all trees multiple revisions changed over the "event horizon" (i.e. when
the failures occurred), the following summarises what changed for each:

pass/fail host  osstest linux   qemuu   xen
xen 4.6 godello1/rimava0Y[0]N[4]N[6]Y[8]
xen 4.5 pinot0/huxelrebe1   Y[0]N[4]N[6]Y[8]
xen 4.4 rimava1/italia0 Y[0]N[4]N[6]Y[9]

qemu 4.6rimava1/baroque1Y[1]Y[5]Y[7]Y[10]
qemu 4.5[11]chardonay0/chardonay1   Y[2]Y[5]Y[7]Y[10]
qemu 4.4elbling1/huxelrebe1 Y[3]Y[5]Y[7]Y

[0] osstest: af4a02e671de..f610ea162836 == update to Jessie
[1] osstest: 54f237784d4b..f610ea162836
[2] osstest: f795781327c0..f610ea162836
[3] osstest: 3cd8b12a4fb1..f610ea162836
[4] Linux 3.14.58
[5] Linux updated from various versions (54, 50, 54) to 3.14.58
[6] qemuu 980dfcf5b8d8
[7] Two XSA-155 fixes
[8] qemut updated for XSA-155.
[9] Fixes for XSA-165 and XSA-166
[10] Lots of changes, from September/October 2015 until now, not including 
     XSA-155, -165 or -166.
[11] Flight before event horizon is 62414, which failed a later step, but 
     is considered a pass of the debian-hvm-install step.

The hosts also all changed, but there is no apparent pattern to the failing
hosts.

Given that Xen * passes with Linux 3.14.58 I doubt the change of Linux in
the QEMU flights to use that version is the issue.

Given that QEMU didn't change in Xen * it seems unlikely that it is the
XSA-155 fixes in the QEMU flights which are causing this.

Given that the xen changes in the Xen * branches all post date the version
of Xen ones in the QEMU * branches, I doubt it is those (especially the
qemut only changes).

Which basically only leaves the switch to using a Debian Jessie build and
runtime environment. As well as the host side stuff we also change the
Debian HVM ISO from Wheezy to Jessie. The fact that none of the bisects
have made any progress (Xen * failed to repro basis pass, QEMU * didn't
seem to find a basis pass to start with) seems to support this.

The fly in the ointment of this theory is that the Jessie upgrade doesn't
seem to have broken unstable in this way, for some reason, which is what I
intend to investigate first.

Ian.

Job histories:

http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/xen-4.6-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/xen-4.5-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/xen-4.4-testing.html

http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/qemu-upstream-4.6-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/qemu-upstream-4.5-testing.html
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-ovmf-amd64/qemu-upstream-4.4-testing.html

Bisects:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.6-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
(4.4 hasn't tackled this one yet)

http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-4.6-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-4.5-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-upstream-4.4-testing/test-amd64-amd64-xl-qemuu-ovmf-amd64.debian-hvm-install.html


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Jan Beulich]

>>> On 06.01.16 at 13:17,  wrote:
> On Wed, Jan 06, 2016 at 03:38:36AM -0700, Jan Beulich wrote:
>> >>> On 06.01.16 at 11:31,  wrote:
>> > On Wed, 2016-01-06 at 02:22 -0700, Jan Beulich wrote:
>> >> > > > On 05.01.16 at 17:53,  wrote:
>> >> > On 12/22/15 10:09 AM, Jan Beulich wrote:
>> >> > > > > > On 22.12.15 at 17:02,  wrote:
>> >> > > > How does it not make sense in this case? That's what Andrew and I
>> >> > > > are
>> >> > > > asking you to explain.
>> >> > > 
>> >> > > But I already explained it: The file isn't needed for booting.
>> >> > 
>> >> > One use of it in /boot would be to check the file in 20_linux_xen like
>> >> > we check the kernel config for different options to add different
>> >> > parameters.
>> >> 
>> >> Which, if you search for it, is a very controversial thing: I agree
>> >> with the side demanding for grub to not inspect the kernel's
>> >> .config.
>> > 
>> > What is the preferred mechanism for determining from the contents of /boot
>> > whether an XSM entry should be produced or not?
>> 
>> I don't think this can be inferred - iirc even an XSM-enabled build
>> can be booted without unless in some kind of strict mode? IOW
>> this needs to be configured on the host, not guessed by
>> inspecting .config. (And as a side note, inspecting .config doesn't
> 
> It's better to lower the hurdle for XSM adoption by instructing grub to
> do sensible default than requiring users to produce entries by hand,
> isn't it?
> 
>> truly require .config to be on the boot partition, unless such
>> inspection would happen at boot time, which I don't think is the
>> case.)
>> 
> 
> Yes and no.
> 
> It's true that it can be placed anywhere on the file system as long as
> grub (or any other tools that need to inspect it) can find it.
> 
> But how would you propose grub to deal with this? The location needs to
> be "fixed" from then on and present forever. Either we need to persuade
> every distro to accept our new less-well-known location to always place
> .config there or we make them patch grub as they package Xen. This is
> just unnecessary work.  Anywhere other than /boot is inferior IMHO.

I think we need to separate the two issues: First we need to
settle on whether inspecting .config for XSM purposes is (a)
necessary and if so (b) the right approach (which I doubt).
See also my other reply to Ian sent a minute or two ago. Only
then do we need to get concerned about whether .config
really has a use when placed on /boot.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xenfb.c: avoid expensive loops when prod <= out_cons

[Stefano Stabellini]

On Wed, 6 Jan 2016, David Vrabel wrote:
> On 06/01/16 12:08, Stefano Stabellini wrote:
> > If the frontend sets out_cons to a value higher than out_prod, it will
> > cause xenfb_handle_events to loop about 2^32 times. Avoid that by using
> > better checks at the beginning of the function.
> 
> You can't use less than to compare prod and cons because they wrap.
> 
> You need to compare (prod - cons) against ring size (or similar) to
> check for overflow.  See RING_REQUEST_PROD_OVERFLOW() etc.

Yes, you are right. I think that the right fix should be:


diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 4e2a27a..594baff 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -789,8 +789,9 @@ static void xenfb_handle_events(struct XenFB *xenfb)
 
 prod = page->out_prod;
 out_cons = page->out_cons;
-if (prod == out_cons)
-   return;
+if (prod - out_cons >= XENFB_OUT_RING_LEL) {
+return;
+}
 xen_rmb(); /* ensure we see ring contents up to prod */
 for (cons = out_cons; cons != prod; cons++) {
union xenfb_out_event *event = _OUT_RING_REF(page, cons);

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] MAINTAINERS: add myself for kconfig

[Tim Deegan]

At 06:45 -0700 on 06 Jan (1452062722), Jan Beulich wrote:
> >>> On 05.01.16 at 13:07,  wrote:
> > On Wed, 2015-12-16 at 08:41 -0600, Doug Goldstein wrote:
> >> Added myself as the maintainer of kconfig.
> >> 
> >> CC: Ian Campbell 
> >> CC: Ian Jackson 
> >> CC: Jan Beulich 
> >> CC: Keir Fraser 
> >> CC: Tim Deegan 
> >> 
> >> Signed-off-by: Doug Goldstein 
> > 
> > Acked-by: Ian Campbell 
> 
> Which reminds me that I meant to reply before the holidays,
> but then didn't get around to.
> 
> To be honest, I'm not convinced. On one hand I'm certainly
> happy for this to not fall under THE REST, but on the other
> hand I've checked your, Doug, history on both Xen and Linux
> without finding (on the Linux side) any Kconfig related
> contribution, and only few earlier ones on either side. I hope
> you understand that I'm uncertain about a relative newcomer
> to be immediately granted maintainership over a non-negligible
> (both in terms of size and functionality) piece of code.

The usual failure mode for Xen contributors is that they leave the
code and never follow up; this is a strong sign that Doug is going to
stick around, and IMO ought to be encouraged!  And in any case Xen as
a whole has a chronic lack of reviewer bandwidth which will only be
fixed by welcoming new reviewers.

If you feel like he may need some shepherding in the short term, maybe
someone more experienced could be co-maintainer for a bit?

Tim.

> I'm open to be convinced otherwise, but for the moment I'm
> NAKing this change.
> 
> Jan
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] svm: rephrase local variable use for Coverity.

[Jan Beulich]

>>> On 01.01.16 at 04:14,  wrote:
> Coverity CID 1343310
> 
> No functional changes.
> 
> Signed-off-by: Joshua Otto 
> ---
> On Mon, Dec 28, 2015 at 09:34:28AM +, Andrew Cooper wrote:
>> The error message isn't fantastic, but the complaint that Coverity
>> has is that we store intr here, then unilaterally store it again
>> slightly lower in the function, no matter what value it had (with
>> the early return presumably not being taken into account).
>>
>> The error would probably be resolved if lines 95 and 96 turned into
>> "if ( vmcb_get_vintr(gvmcb).fields.irq )"
> 
> This patch implements that change - as a general rule, is maintainer
> preference to resolve false positives like this by suppressing them in
> the tool or through code changes like this one?

Asking such a question it would be helpful if you included the
maintainers of the code in question, since to a good part this
is a matter of taste, especially when ...

> --- a/xen/arch/x86/hvm/svm/intr.c
> +++ b/xen/arch/x86/hvm/svm/intr.c
> @@ -92,8 +92,7 @@ static void svm_enable_intr_window(struct vcpu *v, struct 
> hvm_intack intack)
>   * return here or l2 guest looses interrupts, otherwise.
>   */
>  ASSERT(gvmcb != NULL);
> -intr = vmcb_get_vintr(gvmcb);
> -if ( intr.fields.irq )
> +if ( vmcb_get_vintr(gvmcb).fields.irq )

... some people (not me) frown upon complex expressions like the
one resulting here.

Also please note that while perhaps minor here, obvious with
the quote from an earlier mail conversation, naming the person
having suggested the change would be appropriate - if you
look for them, you'll find quite a few Suggested-by: tags in the
commit history.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] RFC Userspace hypercalls

[Jan Beulich]

>>> On 06.01.16 at 12:44,  wrote:
> The HVM ABI (for whatever reason) unilaterally fails
> a userspace hypercall with -EPERM, making it impossible for the kernel
> to trap-and-forward even it wanted to.

Perhaps just to match PV behavior?

> There are already scenarios under test where we cannot rely on the test
> kernel having a fully functioning set of entry points (e.g. the DPL part
> of the test above).  Therefore I specifically want to make it possible
> to make userspace hypercalls, rather than simply making them possible to
> be trapped-and-forwarded.
> 
> 
> As a result, I proposing introducing a hypercall which allows a domain
> to adjust its entry criteria for hypercalls (e.g. set_hypercall_iopl). 
> Doing this for HVM guests is straight forward, but PV guests are harder,
> as they bounce through Xen entrypoints.

The primary question I have is whether this proposal is going to be
of use to anything other than your test framework (i.e. namely any
"ordinary" guests). A second question then would be whether the PV
case really needs to be handled.

> For PV guests, I propose that userspace hypercalls get implemented with
> the int $0x82 path exclusively.  i.e. enabling userspace hypercalls
> causes the hypercall page writing logic to consider the guest a ring1
> kernel, and the int $0x82 entrypoint suitably delegates between a
> regular hypercall and a compat hypercall.

With int $0x82 being the primary hypercall path for 32-bit guests,
I'd be concerned of any code addition, especially that of further
conditionals.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [xen-unstable test] 76919: regressions - FAIL

[Wei Liu]

On Wed, Jan 06, 2016 at 11:14:21AM +, Ian Campbell wrote:
> On Tue, 2016-01-05 at 02:26 +, osstest service owner wrote:
> > flight 76919 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/76919/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
> > fail REGR. vs. 66879
> 
> ISTR someone (Wei?) at some point saying that a 32-bit stubdom (as used
> here) isn't actually something we wish to support. Shall we either drop
> this test altogether or mark it as allow? Or will someone investigate why
> it apparently can't find its disks.
> 

Last time I looked at it I could only attributed such error to emulation
bug. To be honest the ROI of investigating this bug (and other yaks of
32bit stubdom) is very low so I would say let's mark it as allow.

Wei.

> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
> 
> seems to suggest it has a very low probability of success (both merlot and
> italia failed dozens of times before passing)
> 
> Nothing in the xen.git range bf925a9f1254..8e4d18e113c9 looks especially
> relevant.
> 
> Bisection couldn't reproduce the basis pass:
> http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.html
> 
> Ian.
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Wei Liu]

On Wed, Jan 06, 2016 at 03:38:36AM -0700, Jan Beulich wrote:
> >>> On 06.01.16 at 11:31,  wrote:
> > On Wed, 2016-01-06 at 02:22 -0700, Jan Beulich wrote:
> >> > > > On 05.01.16 at 17:53,  wrote:
> >> > On 12/22/15 10:09 AM, Jan Beulich wrote:
> >> > > > > > On 22.12.15 at 17:02,  wrote:
> >> > > > How does it not make sense in this case? That's what Andrew and I
> >> > > > are
> >> > > > asking you to explain.
> >> > > 
> >> > > But I already explained it: The file isn't needed for booting.
> >> > 
> >> > One use of it in /boot would be to check the file in 20_linux_xen like
> >> > we check the kernel config for different options to add different
> >> > parameters.
> >> 
> >> Which, if you search for it, is a very controversial thing: I agree
> >> with the side demanding for grub to not inspect the kernel's
> >> .config.
> > 
> > What is the preferred mechanism for determining from the contents of /boot
> > whether an XSM entry should be produced or not?
> 
> I don't think this can be inferred - iirc even an XSM-enabled build
> can be booted without unless in some kind of strict mode? IOW
> this needs to be configured on the host, not guessed by
> inspecting .config. (And as a side note, inspecting .config doesn't

It's better to lower the hurdle for XSM adoption by instructing grub to
do sensible default than requiring users to produce entries by hand,
isn't it?

> truly require .config to be on the boot partition, unless such
> inspection would happen at boot time, which I don't think is the
> case.)
> 

Yes and no.

It's true that it can be placed anywhere on the file system as long as
grub (or any other tools that need to inspect it) can find it.

But how would you propose grub to deal with this? The location needs to
be "fixed" from then on and present forever. Either we need to persuade
every distro to accept our new less-well-known location to always place
.config there or we make them patch grub as they package Xen. This is
just unnecessary work.  Anywhere other than /boot is inferior IMHO.

Wei.

> Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3 3/3] public/io/netif.h: document new extra info for passing hash values

[Paul Durrant]

To properly support NDIS RSS, the Windows frontend PV driver needs the
toeplitz hash value calculated by the backend (otherwise it would have to
duplicate the calculation).

This patch adds documentation for "feature-hash" and a definition of a
new XEN_NETIF_EXTRA_TYPE_HASH extra info segment which both frontends
and backends can use to pass hash values to the other end.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/public/io/netif.h | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index ace74f3..e12c73f 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -151,6 +151,12 @@
  */
 
 /*
+ * "feature-hash" advertises the capability to accept extra info slots of
+ * type XEN_NETIF_EXTRA_TYPE_HASH. They will not be sent by either end
+ * unless the other end advertises this feature.
+ */
+
+/*
  * Control ring
  * 
  *
@@ -574,6 +580,18 @@ DEFINE_RING_TYPES(netif_ctrl, struct netif_ctrl_request, 
struct netif_ctrl_respo
  * type: Must be XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}
  * flags: XEN_NETIF_EXTRA_FLAG_*
  * addr: address to add/remove
+ *
+ * XEN_NETIF_EXTRA_TYPE_HASH:
+ *
+ *0 1 2 3 4 5 6 7  octet
+ * +-+-+-+-+-+-+-+-+
+ * |type |flags|htype| pad |LSB  value  MSB|
+ * +-+-+-+-+-+-+-+-+
+ *
+ * type: Must be XEN_NETIF_EXTRA_TYPE_HASH
+ * flags: XEN_NETIF_EXTRA_FLAG_*
+ * htype: XEN_NETIF_HASH_TYPE_*
+ * value: Hash value
  */
 
 /* Protocol checksum field is blank in the packet (hardware offload)? */
@@ -607,7 +625,8 @@ typedef struct netif_tx_request netif_tx_request_t;
 #define XEN_NETIF_EXTRA_TYPE_GSO   (1)  /* u.gso */
 #define XEN_NETIF_EXTRA_TYPE_MCAST_ADD (2)  /* u.mcast */
 #define XEN_NETIF_EXTRA_TYPE_MCAST_DEL (3)  /* u.mcast */
-#define XEN_NETIF_EXTRA_TYPE_MAX   (4)
+#define XEN_NETIF_EXTRA_TYPE_HASH  (4)  /* u.hash */
+#define XEN_NETIF_EXTRA_TYPE_MAX   (5)
 
 /* netif_extra_info_t flags. */
 #define _XEN_NETIF_EXTRA_FLAG_MORE (0)
@@ -619,6 +638,16 @@ typedef struct netif_tx_request netif_tx_request_t;
 #define XEN_NETIF_GSO_TYPE_TCPV6(2)
 
 /*
+ * Hash types. (See NETIF_CTRL_TOEPLITZ_FLAG_* definitions above
+ * for more information).
+ */
+#define XEN_NETIF_HASH_TYPE_NONE0
+#define XEN_NETIF_HASH_TYPE_IPV41
+#define XEN_NETIF_HASH_TYPE_IPV4_TCP2
+#define XEN_NETIF_HASH_TYPE_IPV63
+#define XEN_NETIF_HASH_TYPE_IPV6_TCP4
+
+/*
  * This structure needs to fit within both netif_tx_request_t and
  * netif_rx_response_t for compatibility.
  */
@@ -635,6 +664,11 @@ struct netif_extra_info {
 struct {
 uint8_t addr[6];
 } mcast;
+struct {
+uint8_t type;
+uint8_t pad;
+uint8_t value[4];
+} hash;
 uint16_t pad[3];
 } u;
 };
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/3] public/io/netif.h: document control ring and toeplitz hashing

[Paul Durrant]

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 06 January 2016 13:07
> To: xen-de...@lists.xenproject.org
> Cc: Paul Durrant; Ian Campbell; Ian Jackson; Jan Beulich; Keir (Xen.org); Tim
> (Xen.org)
> Subject: [PATCH v2 2/3] public/io/netif.h: document control ring and toeplitz
> hashing
> 
> This patch documents a new shared (variable message length) ring between

Sorry, I should have dropped the 'variable message length' bit here. I'll send 
v3 to fix this.

  Paul

> frontend and backend that can be used to pass bulk out-of-band data, such
> as that required to implement toeplitz hashing in the backend that is
> configurable by the frontend.
> 
> The patch then goes on to document the messages passed over the control
> ring that can be used to configure toeplitz hashing.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Campbell 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> ---
> 
> v2:
>  - Use a balanced fix-sized message ring for the control ring
>(bulk data now passed by grant reference).
> ---
>  xen/include/public/io/netif.h | 264
> ++
>  1 file changed, 264 insertions(+)
> 
> diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
> index 1790ea0..ace74f3 100644
> --- a/xen/include/public/io/netif.h
> +++ b/xen/include/public/io/netif.h
> @@ -151,6 +151,270 @@
>   */
> 
>  /*
> + * Control ring
> + * 
> + *
> + * Some features, such as toeplitz hashing (detailed below), require a
> + * significant amount of out-of-band data to be passed from frontend to
> + * backend. Use of xenstore is not suitable for large quantities of data
> + * because of quota limitations and so a dedicated 'control ring' is used.
> + * The ability of the backend to use a control ring is advertised by
> + * setting:
> + *
> + * /local/domain/X/backend///feature-control-ring = "1"
> + *
> + * The frontend provides a control ring to the backend by setting:
> + *
> + * /local/domain//device/vif//ctrl-ring-ref = 
> + * /local/domain//device/vif//event-channel-ctrl = 
> + *
> + * where  is the grant reference of the shared page used to
> + * implement the control ring and  is an event channel to be used
> + * as a mailbox interrupt, before the frontend moves into the connected
> + * state.
> + *
> + * The control ring uses a fixed request/response message size and is
> + * balanced (i.e. one request to one response), so operationally it is much
> + * the same as a tramsmit or receive ring.
> + */
> +
> +/*
> + * Toeplitz hash types
> + * ===
> + *
> + * For the purposes of the definitions below, 'Packet[]' is an array of
> + * octets containing an IP packet without options, 'Array[X..Y]' means a
> + * sub-array of 'Array' containing bytes X thru Y inclusive, and '+' is
> + * used to indicate concatenation of arrays.
> + */
> +
> +/*
> + * A hash calculated over an IP version 4 header as follows:
> + *
> + * Buffer[0..8] = Packet[12..15] + Packet[16..19]
> + * Result = ToeplitzHash(Buffer, 8)
> + */
> +#define _NETIF_CTRL_TOEPLITZ_FLAG_IPV4 0
> +#define NETIF_CTRL_TOEPLITZ_FLAG_IPV4  (1 <<
> _NETIF_CTRL_TOEPLITZ_FLAG_IPV4)
> +
> +/*
> + * A hash calculated over an IP version 4 header and TCP header as
> + * follows:
> + *
> + * Buffer[0..12] = Packet[12..15] + Packet[16..19] +
> + * Packet[20..21] + Packet[22..23]
> + * Result = ToeplitzHash(Buffer, 12)
> + */
> +#define _NETIF_CTRL_TOEPLITZ_FLAG_IPV4_TCP 1
> +#define NETIF_CTRL_TOEPLITZ_FLAG_IPV4_TCP  (1 <<
> _NETIF_CTRL_TOEPLITZ_FLAG_IPV4_TCP)
> +
> +/*
> + * A hash calculated over an IP version 6 header as follows:
> + *
> + * Buffer[0..32] = Packet[8..23] + Packet[24..39]
> + * Result = ToeplitzHash(Buffer, 32)
> + */
> +#define _NETIF_CTRL_TOEPLITZ_FLAG_IPV6 2
> +#define NETIF_CTRL_TOEPLITZ_FLAG_IPV6  (1 <<
> _NETIF_CTRL_TOEPLITZ_FLAG_IPV4)
> +
> +/*
> + * A hash calculated over an IP version 6 header and TCP header as
> + * follows:
> + *
> + * Buffer[0..36] = Packet[8..23] + Packet[24..39] +
> + * Packet[40..41] + Packet[42..43]
> + * Result = ToeplitzHash(Buffer, 36)
> + */
> +#define _NETIF_CTRL_TOEPLITZ_FLAG_IPV6_TCP 3
> +#define NETIF_CTRL_TOEPLITZ_FLAG_IPV6_TCP  (1 <<
> _NETIF_CTRL_TOEPLITZ_FLAG_IPV4_TCP)
> +
> +/*
> + * Control requests (netif_ctrl_request_t)
> + * ===
> + *
> + * All requests have the following format:
> + *
> + *0 1 2 3 4 5 6 7  octet
> + * +-+-+-+-+-+-+-+-+
> + * |id |   type| data[0]   |
> + * +-+-+-+-+-+-+-+-+
> + * | data[1]   |
> + * +-+-+-+-+
> + *
> + * id: the request identifier, echoed in response.
> + * type: the type of request 

Re: [Xen-devel] [PATCH] MAINTAINERS: add myself for kconfig

[Jan Beulich]

>>> On 05.01.16 at 13:07,  wrote:
> On Wed, 2015-12-16 at 08:41 -0600, Doug Goldstein wrote:
>> Added myself as the maintainer of kconfig.
>> 
>> CC: Ian Campbell 
>> CC: Ian Jackson 
>> CC: Jan Beulich 
>> CC: Keir Fraser 
>> CC: Tim Deegan 
>> 
>> Signed-off-by: Doug Goldstein 
> 
> Acked-by: Ian Campbell 

Which reminds me that I meant to reply before the holidays,
but then didn't get around to.

To be honest, I'm not convinced. On one hand I'm certainly
happy for this to not fall under THE REST, but on the other
hand I've checked your, Doug, history on both Xen and Linux
without finding (on the Linux side) any Kconfig related
contribution, and only few earlier ones on either side. I hope
you understand that I'm uncertain about a relative newcomer
to be immediately granted maintainership over a non-negligible
(both in terms of size and functionality) piece of code.

I'm open to be convinced otherwise, but for the moment I'm
NAKing this change.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 5/5] tools/libxl: remove unused function libxl__domain_save_device_model()

[Wei Liu]

On Tue, Jan 05, 2016 at 10:06:21AM +0800, Wen Congyang wrote:
> After the commit d77570e7, libxl__domain_save_device_model() can
> be dropped.
> 
> Signed-off-by: Wen Congyang 

This is incomplete as far as I can tell.

There are several references to the said function:

$ git grep libxl__domain_save_device_model

libxl.c: * On suspend libxl__domain_save_device_model will have already
libxl_dom.c:void libxl__domain_save_device_model(libxl__egc *egc,
libxl_internal.h:/* private for libxl__domain_save_device_model */
libxl_internal.h:_hidden void libxl__domain_save_device_model(libxl__egc *egc,

I think you haven't handled the instances showed up in line 1 and line
3.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 04/11] igd: switch TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE to realize

[Stefano Stabellini]

On Tue, 5 Jan 2016, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann 

Reviewed-by: Stefano Stabellini 


>  hw/pci-host/igd.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/pci-host/igd.c b/hw/pci-host/igd.c
> index ef0273b..d1eeafb 100644
> --- a/hw/pci-host/igd.c
> +++ b/hw/pci-host/igd.c
> @@ -53,7 +53,7 @@ out:
>  return ret;
>  }
>  
> -static int igd_pt_i440fx_initfn(struct PCIDevice *pci_dev)
> +static void igd_pt_i440fx_realize(PCIDevice *pci_dev, Error **errp)
>  {
>  uint32_t val = 0;
>  int rc, i, num;
> @@ -65,12 +65,11 @@ static int igd_pt_i440fx_initfn(struct PCIDevice *pci_dev)
>  len = igd_host_bridge_infos[i].len;
>  rc = host_pci_config_read(pos, len, val);
>  if (rc) {
> -return -ENODEV;
> +error_setg(errp, "failed to read host config");
> +return;
>  }
>  pci_default_write_config(pci_dev, pos, val, len);
>  }
> -
> -return 0;
>  }
>  
>  static void igd_passthrough_i440fx_class_init(ObjectClass *klass, void *data)
> @@ -78,7 +77,7 @@ static void igd_passthrough_i440fx_class_init(ObjectClass 
> *klass, void *data)
>  DeviceClass *dc = DEVICE_CLASS(klass);
>  PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>  
> -k->init = igd_pt_i440fx_initfn;
> +k->realize = igd_pt_i440fx_realize;
>  dc->desc = "IGD Passthrough Host bridge";
>  }
>  
> -- 
> 1.8.3.1
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] svm: rephrase local variable use for Coverity.

[Boris Ostrovsky]

On 01/06/2016 08:24 AM, Jan Beulich wrote:

On 01.01.16 at 04:14,  wrote:

Coverity CID 1343310

No functional changes.

Signed-off-by: Joshua Otto 
---
On Mon, Dec 28, 2015 at 09:34:28AM +, Andrew Cooper wrote:

The error message isn't fantastic, but the complaint that Coverity
has is that we store intr here, then unilaterally store it again
slightly lower in the function, no matter what value it had (with
the early return presumably not being taken into account).

The error would probably be resolved if lines 95 and 96 turned into
"if ( vmcb_get_vintr(gvmcb).fields.irq )"

This patch implements that change - as a general rule, is maintainer
preference to resolve false positives like this by suppressing them in
the tool or through code changes like this one?


I'd rather suppress this in the tool as I am one of those people that 
Jan refers to below ;-)


However, if it's too much of a hassle then this patch would be OK.

-boris


Asking such a question it would be helpful if you included the
maintainers of the code in question, since to a good part this
is a matter of taste, especially when ...


--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -92,8 +92,7 @@ static void svm_enable_intr_window(struct vcpu *v, struct 
hvm_intack intack)
   * return here or l2 guest looses interrupts, otherwise.
   */
  ASSERT(gvmcb != NULL);
-intr = vmcb_get_vintr(gvmcb);
-if ( intr.fields.irq )
+if ( vmcb_get_vintr(gvmcb).fields.irq )

... some people (not me) frown upon complex expressions like the
one resulting here.

Also please note that while perhaps minor here, obvious with
the quote from an earlier mail conversation, naming the person
having suggested the change would be appropriate - if you
look for them, you'll find quite a few Suggested-by: tags in the
commit history.

Jan




___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] igd-passthrough-i440FX: convert to realize()

[Stefano Stabellini]

Hello Xudong,

please test this patch:

http://marc.info/?l=qemu-devel=145137863501079

with an intel graphic card assigned to a Xen guest. If everything still
works as expected, please reply with your Tested-by.

Thanks,

Stefano

On Wed, 6 Jan 2016, Lars Kurth wrote:
> Hi folks,
> let me introduce you to Xudong from Intel, who is willing to help out.
> Best Regards
> Lars
> 
> > On 4 Jan 2016, at 15:41, Stefano Stabellini 
> >  wrote:
> > 
> > On Mon, 4 Jan 2016, Lars Kurth wrote:
> >> On 04/01/2016 14:47, "Stefano Stabellini"
> >>  wrote:
> >> 
> >>> Unfortunately I don't have a setup to test this either. Maybe Lars can
> >>> find out who should be involved on the Intel side on this.
> >> 
> >> I can certainly help to this and get back to you. What exactly are we
> >> asking Intel to do?
> >> It is not clear to me from this email thread
> > 
> > Tiejun Chen, the author of the Intel graphic card passthrough patches
> > for QEMU, seems to have left the company. It would be nice if somebody
> > else tested this patch with an intel graphic card assigned to a guest
> > VM.
> > 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 1/3] public/io/netif.h: document transmit and receive wire formats separately

[Paul Durrant]

Currently there is no documented wire format for guest receive-side
packets but the location of the 'wire format' comment block suggests
it is the same as transmit-side. This is almost true but there is a
subtle difference in the use of the 'size' field for the first fragment.

For clarity this patch creates separate comment blocks for receive
and transmit side packet wire formats, tries to be more clear about the
distinction between 'fragments' and 'extras', and documents the subtlety
concerning the size field of the first fragment.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/public/io/netif.h | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index e103cf3..1790ea0 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -151,22 +151,22 @@
  */
 
 /*
- * This is the 'wire' format for packets:
- *  Request 1: netif_tx_request_t -- NETTXF_* (any flags)
- * [Request 2: netif_extra_info_t] (only if request 1 has
- *  NETTXF_extra_info)
- * [Request 3: netif_extra_info_t] (only if request 2 has
- *  XEN_NETIF_EXTRA_MORE)
- *  Request 4: netif_tx_request_t -- NETTXF_more_data
- *  Request 5: netif_tx_request_t -- NETTXF_more_data
- *  ...
- *  Request N: netif_tx_request_t -- 0
- */
-
-/*
  * Guest transmit
  * ==
  *
+ * This is the 'wire' format for packets:
+ *  Fragment 1: netif_tx_request_t  - flags = NETTXF_*
+ *size = total packet size
+ * [Extra 1: netif_extra_info_t]- (only if fragment 1 flags include
+ * NETTXF_extra_info)
+ * [Extra N: netif_extra_info_t]- (only if extra N-1 flags include
+ * XEN_NETIF_EXTRA_MORE)
+ *  ...
+ *  Fragment N: netif_tx_request_t  - (only if fragment N-1 flags include
+ * NETTXF_more_data)
+ *flags = 0
+ *size = fragment size
+ *
  * Ring slot size is 12 octets, however not all request/response
  * structs use the full size.
  *
@@ -202,6 +202,19 @@
  * Guest receive
  * =
  *
+ * This is the 'wire' format for packets:
+ *  Fragment 1: netif_rx_request_t  - flags = NETRXF_*
+ *size = fragment size
+ * [Extra 1: netif_extra_info_t]- (only if fragment 1 flags include
+ * NETRXF_extra_info)
+ * [Extra N: netif_extra_info_t]- (only if extra N-1 flags include
+ * XEN_NETIF_EXTRA_MORE)
+ *  ...
+ *  Fragment N: netif_rx_request_t  - (only if fragment N-1 flags include
+ * NETRXF_more_data)
+ *flags = 0
+ *size = fragment size
+ *
  * Ring slot size is 8 octets.
  *
  * rx request (netif_rx_request_t)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 3/3] public/io/netif.h: document new extra info for passing hash values

[Paul Durrant]

To properly support NDIS RSS, the Windows frontend PV driver needs the
toeplitz hash value calculated by the backend (otherwise it would have to
duplicate the calculation).

This patch adds documentation for "feature-hash" and a definition of a
new XEN_NETIF_EXTRA_TYPE_HASH extra info segment which both frontends
and backends can use to pass hash values to the other end.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/public/io/netif.h | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index ace74f3..e12c73f 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -151,6 +151,12 @@
  */
 
 /*
+ * "feature-hash" advertises the capability to accept extra info slots of
+ * type XEN_NETIF_EXTRA_TYPE_HASH. They will not be sent by either end
+ * unless the other end advertises this feature.
+ */
+
+/*
  * Control ring
  * 
  *
@@ -574,6 +580,18 @@ DEFINE_RING_TYPES(netif_ctrl, struct netif_ctrl_request, 
struct netif_ctrl_respo
  * type: Must be XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}
  * flags: XEN_NETIF_EXTRA_FLAG_*
  * addr: address to add/remove
+ *
+ * XEN_NETIF_EXTRA_TYPE_HASH:
+ *
+ *0 1 2 3 4 5 6 7  octet
+ * +-+-+-+-+-+-+-+-+
+ * |type |flags|htype| pad |LSB  value  MSB|
+ * +-+-+-+-+-+-+-+-+
+ *
+ * type: Must be XEN_NETIF_EXTRA_TYPE_HASH
+ * flags: XEN_NETIF_EXTRA_FLAG_*
+ * htype: XEN_NETIF_HASH_TYPE_*
+ * value: Hash value
  */
 
 /* Protocol checksum field is blank in the packet (hardware offload)? */
@@ -607,7 +625,8 @@ typedef struct netif_tx_request netif_tx_request_t;
 #define XEN_NETIF_EXTRA_TYPE_GSO   (1)  /* u.gso */
 #define XEN_NETIF_EXTRA_TYPE_MCAST_ADD (2)  /* u.mcast */
 #define XEN_NETIF_EXTRA_TYPE_MCAST_DEL (3)  /* u.mcast */
-#define XEN_NETIF_EXTRA_TYPE_MAX   (4)
+#define XEN_NETIF_EXTRA_TYPE_HASH  (4)  /* u.hash */
+#define XEN_NETIF_EXTRA_TYPE_MAX   (5)
 
 /* netif_extra_info_t flags. */
 #define _XEN_NETIF_EXTRA_FLAG_MORE (0)
@@ -619,6 +638,16 @@ typedef struct netif_tx_request netif_tx_request_t;
 #define XEN_NETIF_GSO_TYPE_TCPV6(2)
 
 /*
+ * Hash types. (See NETIF_CTRL_TOEPLITZ_FLAG_* definitions above
+ * for more information).
+ */
+#define XEN_NETIF_HASH_TYPE_NONE0
+#define XEN_NETIF_HASH_TYPE_IPV41
+#define XEN_NETIF_HASH_TYPE_IPV4_TCP2
+#define XEN_NETIF_HASH_TYPE_IPV63
+#define XEN_NETIF_HASH_TYPE_IPV6_TCP4
+
+/*
  * This structure needs to fit within both netif_tx_request_t and
  * netif_rx_response_t for compatibility.
  */
@@ -635,6 +664,11 @@ struct netif_extra_info {
 struct {
 uint8_t addr[6];
 } mcast;
+struct {
+uint8_t type;
+uint8_t pad;
+uint8_t value[4];
+} hash;
 uint16_t pad[3];
 } u;
 };
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 2/3] public/io/netif.h: document control ring and toeplitz hashing

[Paul Durrant]

This patch documents a new shared (variable message length) ring between
frontend and backend that can be used to pass bulk out-of-band data, such
as that required to implement toeplitz hashing in the backend that is
configurable by the frontend.

The patch then goes on to document the messages passed over the control
ring that can be used to configure toeplitz hashing.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---

v2:
 - Use a balanced fix-sized message ring for the control ring
   (bulk data now passed by grant reference).
---
 xen/include/public/io/netif.h | 264 ++
 1 file changed, 264 insertions(+)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index 1790ea0..ace74f3 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -151,6 +151,270 @@
  */
 
 /*
+ * Control ring
+ * 
+ *
+ * Some features, such as toeplitz hashing (detailed below), require a
+ * significant amount of out-of-band data to be passed from frontend to
+ * backend. Use of xenstore is not suitable for large quantities of data
+ * because of quota limitations and so a dedicated 'control ring' is used.
+ * The ability of the backend to use a control ring is advertised by
+ * setting:
+ *
+ * /local/domain/X/backend///feature-control-ring = "1"
+ *
+ * The frontend provides a control ring to the backend by setting:
+ *
+ * /local/domain//device/vif//ctrl-ring-ref = 
+ * /local/domain//device/vif//event-channel-ctrl = 
+ *
+ * where  is the grant reference of the shared page used to
+ * implement the control ring and  is an event channel to be used
+ * as a mailbox interrupt, before the frontend moves into the connected
+ * state.
+ *
+ * The control ring uses a fixed request/response message size and is
+ * balanced (i.e. one request to one response), so operationally it is much
+ * the same as a tramsmit or receive ring.
+ */
+
+/*
+ * Toeplitz hash types
+ * ===
+ *
+ * For the purposes of the definitions below, 'Packet[]' is an array of
+ * octets containing an IP packet without options, 'Array[X..Y]' means a
+ * sub-array of 'Array' containing bytes X thru Y inclusive, and '+' is
+ * used to indicate concatenation of arrays.
+ */
+
+/*
+ * A hash calculated over an IP version 4 header as follows:
+ *
+ * Buffer[0..8] = Packet[12..15] + Packet[16..19]
+ * Result = ToeplitzHash(Buffer, 8)
+ */
+#define _NETIF_CTRL_TOEPLITZ_FLAG_IPV4 0
+#define NETIF_CTRL_TOEPLITZ_FLAG_IPV4  (1 << 
_NETIF_CTRL_TOEPLITZ_FLAG_IPV4)
+
+/*
+ * A hash calculated over an IP version 4 header and TCP header as
+ * follows:
+ *
+ * Buffer[0..12] = Packet[12..15] + Packet[16..19] +
+ * Packet[20..21] + Packet[22..23]
+ * Result = ToeplitzHash(Buffer, 12)
+ */
+#define _NETIF_CTRL_TOEPLITZ_FLAG_IPV4_TCP 1
+#define NETIF_CTRL_TOEPLITZ_FLAG_IPV4_TCP  (1 << 
_NETIF_CTRL_TOEPLITZ_FLAG_IPV4_TCP)
+
+/*
+ * A hash calculated over an IP version 6 header as follows:
+ *
+ * Buffer[0..32] = Packet[8..23] + Packet[24..39]
+ * Result = ToeplitzHash(Buffer, 32)
+ */
+#define _NETIF_CTRL_TOEPLITZ_FLAG_IPV6 2
+#define NETIF_CTRL_TOEPLITZ_FLAG_IPV6  (1 << 
_NETIF_CTRL_TOEPLITZ_FLAG_IPV4)
+
+/*
+ * A hash calculated over an IP version 6 header and TCP header as
+ * follows:
+ *
+ * Buffer[0..36] = Packet[8..23] + Packet[24..39] +
+ * Packet[40..41] + Packet[42..43]
+ * Result = ToeplitzHash(Buffer, 36)
+ */
+#define _NETIF_CTRL_TOEPLITZ_FLAG_IPV6_TCP 3
+#define NETIF_CTRL_TOEPLITZ_FLAG_IPV6_TCP  (1 << 
_NETIF_CTRL_TOEPLITZ_FLAG_IPV4_TCP)
+
+/*
+ * Control requests (netif_ctrl_request_t)
+ * ===
+ *
+ * All requests have the following format:
+ *
+ *0 1 2 3 4 5 6 7  octet
+ * +-+-+-+-+-+-+-+-+
+ * |id |   type| data[0]   |
+ * +-+-+-+-+-+-+-+-+
+ * | data[1]   |
+ * +-+-+-+-+
+ *
+ * id: the request identifier, echoed in response.
+ * type: the type of request (see below)
+ * data[]: any data associated with the request (determined by type)
+ */
+
+struct netif_ctrl_request {
+uint16_t id;
+uint16_t type;
+
+#define NETIF_CTRL_TYPE_INVALID  0
+#define NETIF_CTRL_TYPE_GET_TOEPLITZ_FLAGS   1
+#define NETIF_CTRL_TYPE_SET_TOEPLITZ_FLAGS   2
+#define NETIF_CTRL_TYPE_SET_TOEPLITZ_KEY 3
+#define NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING 4
+
+uint32_t data[2];
+};
+typedef struct netif_ctrl_request netif_ctrl_request_t;
+
+/*
+ * type = NETIF_CTRL_TYPE_GET_TOEPLITZ_FLAGS:
+ *
+ * This is sent by the frontend to query the types of toeplitz
+ * hash supported by the backend. No data is required and to the
+ * data[] field is 

[Xen-devel] [PATCH v2 0/3] public/io/netif.h: support for toeplitz hashing

[Paul Durrant]

This series documents changes needed to support toeplitz hashing in a
backend, configurable by the frontend.

Patch #1 is a clean-up patch that clarifies the guest transmit and
receive side packet formats.

Patch #2 documents a new 'control ring' for passing bulk data between
frontend and backend. This is needed for passing the hash mapping table
and hash key. It also documents messages to allow a frontend to configure
toeplitz hashing.

Patch #3 documents a new extra info segment that can be used for passing
hash values along with packets on both the transmit and receive side.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.7 Development Update

[Jan Beulich]

>>> On 05.01.16 at 07:57,  wrote:
 On 1/4/2016 at 06:15 PM, in message , Wei Liu 
  wrote: 

Chun Yan (and others),

please remember to limit quoting especially (but not limited to)
when replying to Development Update mails: Commonly (like in
your case) people really just reply to a single or very few items:

>> *  PV USB passthrough 
>>   -  Chunyan Liu 
> 
> Reviewed by George Dunlap.
> V12:
> http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html 
> 
>[...]  
>> *  Domain snapshot API 
>>   -  Chunyan Liu 
> 
> Doc:
> http://lists.xen.org/archives/html/xen-devel/2015-08/msg00884.html 
> 
> RFC implementation, has many limitations, call for comments:
> http://lists.xen.org/archives/html/xen-devel/2015-08/msg02384.html 

Hence the writer of the response can save everyone's time by
making sure readers don't have to hunt/scroll for that one item
through the entire quoted original mail.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF related osstest failures on multiple branches

[Ian Campbell]

On Wed, 2016-01-06 at 12:35 +, Ian Campbell wrote:
> The fly in the ointment of this theory is that the Jessie upgrade doesn't
> seem to have broken unstable in this way, for some reason, which is what I
> intend to investigate first.

One difference between all the failing versions and xen-unstable is that
unstable has a newer OVMF 52a99493cce8 (works) vs cb9a7ebabcd6 (fails).

It's possible there is a fix in there which would explain this, but its a
lot of commits to trawl through.

That said, one did stand out (below). A hang would correlate with a
complete lack of output (serial, vga) in the failure case (e.g. the 4.6-
testing one at [0]). Jessie is GCC49.

Next step is I'm trying 4.6-testing with the newer OVMF to see if this is
worth pursuing.

Ian.

[0] 
http://logs.test-lab.xenproject.org/osstest/logs/76950/test-amd64-amd64-xl-qemuu-ovmf-amd64/info.html)

Ian.


commit 55e96f9c601781b8dc52c40747922f6ca3521f9e
Author: Ruiyu Ni 
Date:   Thu Jul 9 08:55:23 2015 +

OvmfPkg: Fix GCC49 build hang in PeiCore

PeiCore hang when loads a PEIM whose section alignment requirement is 0x40
but the actual base address is 0x20 aligned.

The issue is caused by the following facts, in order:

1. GCC49 requires the section alignment of .data to be 0x40. So a new link
   script gcc4.9-ld-script was added for GCC49 to specify the 0x40
   alignment.

2. GenFw tool was enhanced to sync ELF's section alignment to PE header.
   Before the enhancement, the section alignment of converted PE image
   always equals to 0x20.

If only with #1 change, GCC49 build image won't hang in PeiCore because
the converted PE image still claims 0x20 section alignment which is
aligned to the align setting set in FDF file. But later with #2 change,
the converted PE image starts to claims 0x40 section alignment, while
build tool still puts the PEIM in 0x20 aligned address, resulting the
PeCoffLoaderLoadImage() reports IMAGE_ERROR_INVALID_SECTION_ALIGNMENT
error.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Reviewed-by: Liming Gao 
Reviewed-by: Laszlo Ersek 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17902 
6f19259b-4bc3-4df7-8a09-765794883524


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/4] tools/xl: add a new xl configuration 'nvdimm'

[Jan Beulich]

>>> On 29.12.15 at 12:31,  wrote:
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -962,6 +962,25 @@ FIFO-based event channel ABI support up to 131,071 event 
> channels.
>  Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
>  x86).
>  
> +=item 

Re: [Xen-devel] [PATCH v3 02/11] pc: remove has_igd_gfx_passthru global

[Stefano Stabellini]

On Tue, 5 Jan 2016, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann 

Reviewed-by: Stefano Stabellini 


>  hw/xen/xen_pt.h |  5 +++--
>  vl.c| 10 --
>  2 files changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 3749711..cdd73ff 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -4,6 +4,7 @@
>  #include "qemu-common.h"
>  #include "hw/xen/xen_common.h"
>  #include "hw/pci/pci.h"
> +#include "hw/boards.h"
>  #include "xen-host-pci-device.h"
>  
>  void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
> @@ -322,10 +323,10 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice 
> *dev,
>  unsigned int domain,
>  unsigned int bus, unsigned int 
> slot,
>  unsigned int function);
> -extern bool has_igd_gfx_passthru;
>  static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev)
>  {
> -return (has_igd_gfx_passthru
> +MachineState *machine = MACHINE(qdev_get_machine());
> +return (machine->igd_gfx_passthru
>  && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>  }
>  int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
> diff --git a/vl.c b/vl.c
> index 5aaea77..d4e51ec 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1365,13 +1365,6 @@ static inline void semihosting_arg_fallback(const char 
> *file, const char *cmd)
>  }
>  }
>  
> -/* Now we still need this for compatibility with XEN. */
> -bool has_igd_gfx_passthru;
> -static void igd_gfx_passthru(void)
> -{
> -has_igd_gfx_passthru = current_machine->igd_gfx_passthru;
> -}
> -
>  /***/
>  /* USB devices */
>  
> @@ -4550,9 +4543,6 @@ int main(int argc, char **argv, char **envp)
>  exit(1);
>  }
>  
> -/* Check if IGD GFX passthrough. */
> -igd_gfx_passthru();
> -
>  /* init generic devices */
>  if (qemu_opts_foreach(qemu_find_opts("device"),
>device_init_func, NULL, NULL)) {
> -- 
> 1.8.3.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Failed vm entry with heavy use of emulator

[Jan Beulich]

>>> On 05.01.16 at 13:05,  wrote:
> On Tue, Jan 5, 2016 at 12:56 PM, Andrew Cooper 
> wrote:
>> Do you have a log of the instructions emulated?
> 
> I don't. Is there an easy way to get that beside manually sprinkling debug
> messages around in the emulator?

Assuming you have the guest kernel binary (or binaries, in e.g. the
Windows case), just disassemble the kernel binary. Considering
later replies, maybe you even see crashes on different instructions,
which may allow deriving a pattern.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 77175: regressions - FAIL

[osstest service owner]

flight 77175 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77175/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 66433
 build-amd64-xsm   5 xen-build fail REGR. vs. 66433
 build-amd64   5 xen-build fail REGR. vs. 66433
 build-i386-xsm5 xen-build fail REGR. vs. 66433
 build-armhf   5 xen-build fail REGR. vs. 66433
 build-armhf-xsm   5 xen-build fail REGR. vs. 66433

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 

[Xen-devel] [qemu-upstream-4.5-testing test] 77137: regressions - FAIL

[osstest service owner]

flight 77137 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77137/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 62414
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 62414
 build-armhf-pvops 4 host-build-prep  fail in 67079 REGR. vs. 62414

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 66752 pass in 
77137
 test-armhf-armhf-xl-rtds  9 debian-install  fail pass in 66752
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail pass 
in 67079

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 67079 
like 62321
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 67079 like 62414
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 62075
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 62414
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 62414

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)blocked in 67079 n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)  blocked in 67079 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)blocked in 67079 n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)blocked in 67079 n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)blocked in 67079 n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked in 67079 n/a
 test-armhf-armhf-xl   1 build-check(1)blocked in 67079 n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)blocked in 67079 n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)  blocked in 67079 n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)blocked in 67079 n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 66752 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 66752 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for testing:
 qemuu32bba3499008c847e08858f310d65806e0bade36
baseline version:
 qemuue5a1bb22cfb307db909dbd3404c48e5bbeb9e66d

Last test of basis62414  2015-09-26 20:34:49 Z  101 days
Testing same since66534  2015-12-18 15:48:15 Z   18 days7 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops 

Re: [Xen-devel] [PATCH 0/4] Allow schedulers to be selectable through Kconfig

[Ian Campbell]

On Fri, 2015-12-18 at 11:56 -0600, Doug Goldstein wrote:
> In the end I really see the primary people that build Xen on their own
> as project maintainers (XenServer, Qubes, OpenXT) or distro maintainers
> (Ubuntu, Debian, Gentoo, Yocto) or "expert" users. Most people will use
> Xen as it comes packaged for them already and the Kconfig changes give
> the project/distro/experts the flexibility they need to build up Xen
> without maintaining downstream patches. So these won't really be shiny
> knobs for users to twiddle.

In this context I would consider the distro maintainers (at least for
generic, non-Xen specialised distros, e.g. XenServer and QUBES don't fit
here) to be users.

I don't think we want such distros to all be shipping subtly varying
versions of Xen any more than I want individual end users to be doing so.
Users of community (rather than Enterprise/Commercial) distros use many of
our upstream resources, including reporting bugs on xen-users and -devel.

But of course you (quite naturally, I think) expect that they will want to
play with these things, and I think that they will be no less prone to
fiddling with the shiny nobs than a individual user would be.

I don't want to distro users coming to use for support because they tried
to follow http://wiki.xenproject.org/wiki/Credit2_Scheduler_Development#Usi
ng_Credit2 and it didn't work, only to find that their distro has decided
to turn off credit2 in the packages, for whatever random reason the package
maintainer had.

I don't see this as contrary to your stated goals (e.g. ripping out all the
other schedulers), but I consider you to be within the expert camp for
wanting to do so (and having the chops to handle whatever pieces you find
yourselves with). I have no objections at all to allowing experts such as
yourselves to configure things and I applaud you for doing this in an
upstream way (it is the right thing to do).

My concern is that while you rightly consider yourselves expert enough and
are building something for a specific (and AIUI targeted) use case many
normal users tend to think that if they are expert enough to find and flip
the switch then they are expert enough to deal with the consequences, when
they are not and/or they do not have the specific use case which the switch
was added to support i.e. they want common or garden Xen and we want that
to mean the same for everyone.

It's those people (including general purpose distro maintainers) who I
think need to be strongly discouraged from messing with these options
because there will be a strong gravity towards them doing so.

> What provides the defaults that users should use are the defconfig
> files. The reason this doesn't work out so well for Linux is that there
> are really not defaults that work for everyone.

... and sadly by switching Xen to Kconfig this expectation _is_ going to
flow over to us, once someone sees "make menuconfig" mentioned somewhere
they are going to get their Linux head on and start messing with it.

>  But on the flip
> side of the coin Ian Campbell has been helping Debian to upstream
> changes they need [2].

BTW, I'm also a Debian Developer (although not the Xen package maintainer),
so I am doing this with as much downstream as upstream hat on.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.3-testing test] 77074: regressions - FAIL

[osstest service owner]

flight 77074 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77074/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-build fail REGR. vs. 65650
 build-amd64-prev  5 xen-build fail REGR. vs. 65650
 build-i3865 xen-build fail REGR. vs. 65650
 build-i386-prev   5 xen-build fail REGR. vs. 65650

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass

version targeted for testing:
 xen  0fe03d7ed26d41e9434fb007d6fe4d05077efa7d
baseline version:
 xen  54dd84062d4e0f0298508826fc06990415da431e

Last test of basis65650  2015-12-10 

[Xen-devel] [xen-4.6-testing test] 76950: regressions - FAIL

[osstest service owner]

flight 76950 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/76950/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 65639
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65639
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65639

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  6 xen-boot   fail in 67098 pass in 76950
 test-armhf-armhf-xl-rtds  6 xen-boot   fail in 67098 pass in 76950
 test-armhf-armhf-xl-credit2   6 xen-bootfail pass in 67098

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 67098 like 65639
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 67098 like 65639
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 65639
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 65639

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 67098 never 
pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check fail in 67098 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  eb32a519f5945dc7465f1f4f555e2dd9654250b7
baseline version:
 xen  850bcd0f42e4912b6605a2caa42d5c466ed58bd1

Last test of basis65639  2015-12-09 21:22:40 Z   26 days
Failing since 66394  2015-12-15 18:17:32 Z   20 days9 attempts
Testing same since66942  2015-12-22 11:53:37 Z   14 days3 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Brendan Gregg 
  Daniel Kiper 
  Dario Faggioli 
  David Vrabel 
  Ed Swierk 
  Haozhong Zhang 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Malcolm Crossley 

jobs:
 build-amd64-xsm  

[Xen-devel] [qemu-mainline test] 77011: regressions - FAIL

[osstest service owner]

flight 77011 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77011/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 66433
 build-amd64-xsm   5 xen-build fail REGR. vs. 66433
 build-amd64   5 xen-build fail REGR. vs. 66433
 build-i386-xsm5 xen-build fail REGR. vs. 66433
 build-armhf   5 xen-build fail REGR. vs. 66433
 build-armhf-xsm   5 xen-build fail REGR. vs. 66433

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 

[Xen-devel] [xen-unstable-smoke test] 77147: tolerable all pass - PUSHED

[osstest service owner]

flight 77147 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77147/

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 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ce0fac22e7f367ba72ebd762331f8c9bdf1e2519
baseline version:
 xen  dcdb6588779ac8a0cab513d9a2d5ee0bb1dda1cd

Last test of basis77025  2016-01-04 18:03:22 Z0 days
Testing same since77147  2016-01-05 15:01:04 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Ian Jackson 
  Julien Grall 
  Kevin Tian 
  Samuel Thibault 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=ce0fac22e7f367ba72ebd762331f8c9bdf1e2519
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
ce0fac22e7f367ba72ebd762331f8c9bdf1e2519
+ branch=xen-unstable-smoke
+ revision=ce0fac22e7f367ba72ebd762331f8c9bdf1e2519
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' xce0fac22e7f367ba72ebd762331f8c9bdf1e2519 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig 

Re: [Xen-devel] [PATCH v3 4/4] libxc: set flag for support of linear p2m list in domain builder

[Wei Liu]

On Wed, Dec 16, 2015 at 10:24:20AM +0100, Juergen Gross wrote:
> Set the SIF_VIRT_P2M_4TOOLS flag for pv-domUs in the domain builder
> to indicate the Xen tools have full support for the virtual mapped
> linear p2m list.
> 
> This will enable pv-domUs to drop support of the 3 level p2m tree
> and use the linear list only. Without setting this flag some kernels
> might limit themselves to 512 GB memory size in order not to break
> migration.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Andrew Cooper 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/4] libxc: stop migration in case of p2m list structural changes

[Wei Liu]

On Wed, Dec 16, 2015 at 10:24:19AM +0100, Juergen Gross wrote:
> With support of the virtual mapped linear p2m list for migration it is
> now possible to detect structural changes of the p2m list which before
> would either lead to a crashing or otherwise wrong behaving domU.
> 
> A guest supporting the linear p2m list will increment the
> p2m_generation counter located in the shared info page before and after
> each modification of a mapping related to the p2m list. A change of
> that counter can be detected by the tools and reacted upon.
> 
> As such a change should occur only very rarely once the domU is up the
> most simple reaction is to cancel migration in such an event.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Andrew Cooper 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/4] add support for vNVDIMM

[Haozhong Zhang]

On 01/06/16 15:37, Ian Campbell wrote:
> On Tue, 2015-12-29 at 19:31 +0800, Haozhong Zhang wrote:
> > This patch series is the Xen part patch to provide virtual NVDIMM to
> > guest. The corresponding QEMU patch series is sent separately with the
> > title "[PATCH 0/2] add vNVDIMM support for Xen".
> 
> When you send multiple related series like this please could you tag them
> in the 0/N subject line somehow as to the tree they are for. Either tagging
> with "[PATCH XEN 0/4]" (via git send-email --subject-prefix="PATCH XEN") or
> using something like "xen: add support for ..." (and the equivalent for
> other trees).
> 
> In this case I incorrectly categorised this based on the subject as a
> repost of a QEMU series I had seen just before and hence ignored it. I
> spotted a bit of diffstat in a reply and have now put it into my queue to
> look at, but that was pure luck.
> 
> Ian.

Sorry for the trouble. I'll add tags in new versions.

Haozhong

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 02/13] libxc: support new xenstore domain flag in libxc

[Ian Campbell]

On Fri, 2015-12-18 at 14:14 +0100, Juergen Gross wrote:
> Support the xenstore domain flag for obtaining domain info.
> 
> Signed-off-by: Juergen Gross 
> ---
>  tools/libxc/include/xenctrl.h |  2 +-
>  tools/libxc/xc_domain.c   | 17 +
>  2 files changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h
> b/tools/libxc/include/xenctrl.h
> index 01a6dda..45d8ff6 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -456,7 +456,7 @@ typedef struct xc_dominfo {
>  uint32_t  ssidref;
>  unsigned int  dying:1, crashed:1, shutdown:1,
>    paused:1, blocked:1, running:1,
> -  hvm:1, debugged:1, pvh:1;
> +  hvm:1, debugged:1, pvh:1, xs_domain:1;

All the other flags omit the _domain/_guest since it is implicit in the
context I think.

"xs" would be ok, so would "xenstore" or "xenstored" I think.

You might want to consider similar arguments for DOMINF and the create
flag, or you might want to argue that this field should be xs_domain for
consistency with those.

Apart from what colour to paint the shed to code looks trivially correct.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv4] xen/gntdev: add ioctl for grant copy

[David Vrabel]

On 01/12/15 16:43, David Vrabel wrote:
> Add IOCTL_GNTDEV_GRANT_COPY to allow applications to copy between user
> space buffers and grant references.
> 
> This interface is similar to the GNTTABOP_copy hypercall ABI except
> the local buffers are provided using a virtual address (instead of a
> GFN and offset).  To avoid userspace from having to page align its
> buffers the driver will use two or more ops if required.
> 
> If the ioctl returns 0, the application must check the status of each
> segment with the segments status field.  If the ioctl returns a -ve
> error code (EINVAL or EFAULT), the status of individual ops is
> undefined.

Applied to for-linus-4.5.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 5/5] tools/libxl: remove unused function libxl__domain_save_device_model()

[Wen Congyang]

在 2016/1/6 22:10, Wei Liu 写道:

On Tue, Jan 05, 2016 at 10:06:21AM +0800, Wen Congyang wrote:

After the commit d77570e7, libxl__domain_save_device_model() can
be dropped.

Signed-off-by: Wen Congyang 


This is incomplete as far as I can tell.

There are several references to the said function:

$ git grep libxl__domain_save_device_model

libxl.c: * On suspend libxl__domain_save_device_model will have already


libxl__domain_save_device_model() will remove the dm_savefile. But we 
don't remove

it when using migration v2.


libxl_dom.c:void libxl__domain_save_device_model(libxl__egc *egc,
libxl_internal.h:/* private for libxl__domain_save_device_model */
libxl_internal.h:_hidden void libxl__domain_save_device_model(libxl__egc *egc,

I think you haven't handled the instances showed up in line 1 and line
3.


Yes, I will fix it in the next version.
Thanks
Wen Congyang



Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/4] add support for vNVDIMM

[Ian Campbell]

On Tue, 2015-12-29 at 19:31 +0800, Haozhong Zhang wrote:
> This patch series is the Xen part patch to provide virtual NVDIMM to
> guest. The corresponding QEMU patch series is sent separately with the
> title "[PATCH 0/2] add vNVDIMM support for Xen".

When you send multiple related series like this please could you tag them
in the 0/N subject line somehow as to the tree they are for. Either tagging
with "[PATCH XEN 0/4]" (via git send-email --subject-prefix="PATCH XEN") or
using something like "xen: add support for ..." (and the equivalent for
other trees).

In this case I incorrectly categorised this based on the subject as a
repost of a QEMU series I had seen just before and hence ignored it. I
spotted a bit of diffstat in a reply and have now put it into my queue to
look at, but that was pure luck.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/4] libxc: support of linear p2m list for migration of pv-domains

[Wei Liu]

On Wed, Dec 16, 2015 at 10:24:18AM +0100, Juergen Gross wrote:
[...]
> @@ -698,21 +868,19 @@ static int normalise_pagetable(struct xc_sr_context 
> *ctx, const uint64_t *src,
>  /* 32bit guests can only use the first 4 entries of their L3 
> tables.
>   * All other are potentially used by Xen. */
>  xen_first = 4;
> -xen_last = 512;
> +xen_last = 511;

Is this a bug fix in its own right?

Wei.

>  break;
>  
>  case XEN_DOMCTL_PFINFO_L2TAB:
>  /* It is hard to spot Xen mappings in a 32bit guest's L2.  Most
>   * are normal but only a few will have Xen mappings.
> - *
> - * 428 = (HYPERVISOR_VIRT_START_PAE >> 
> L2_PAGETABLE_SHIFT_PAE)&0x1ff
> - *
> - * ...which is conveniently unavailable to us in a 64bit build.
>   */
> -if ( pte_to_frame(src[428]) == ctx->x86_pv.compat_m2p_mfn0 )
> +i = (HYPERVISOR_VIRT_START_X86_32 >> L2_PAGETABLE_SHIFT_PAE) & 
> 511;
> +if ( pte_to_frame(src[i]) == ctx->x86_pv.compat_m2p_mfn0 )
>  {
> -xen_first = 428;
> -xen_last = 512;
> +xen_first = i;
> +xen_last = (HYPERVISOR_VIRT_END_X86_32 >>
> +L2_PAGETABLE_SHIFT_PAE) & 511;
>  }
>  break;
>  }
> -- 
> 2.6.2
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 05/11] igd: TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE: call parent realize

[Gerd Hoffmann]

> >  
> > +static void (*i440fx_realize)(PCIDevice *pci_dev, Error **errp);
> >  static void igd_pt_i440fx_realize(PCIDevice *pci_dev, Error **errp)
> >  {
> > +Error *err = NULL;
> >  uint32_t val = 0;
> >  int rc, i, num;
> >  int pos, len;
> 
> Can't we get the parent PCIDeviceClass realize function from pci_dev? So
> that we don't have to introduce i440fx_realize?

I don't think so ...

> >  
> > +i440fx_realize = k->realize;
> >  k->realize = igd_pt_i440fx_realize;

... because we are overriding it right here.

cheers,
  Gerd


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 05/11] igd: TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE: call parent realize

[Stefano Stabellini]

On Tue, 5 Jan 2016, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann 
> ---
>  hw/pci-host/igd.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/hw/pci-host/igd.c b/hw/pci-host/igd.c
> index d1eeafb..6f52ab1 100644
> --- a/hw/pci-host/igd.c
> +++ b/hw/pci-host/igd.c
> @@ -53,12 +53,20 @@ out:
>  return ret;
>  }
>  
> +static void (*i440fx_realize)(PCIDevice *pci_dev, Error **errp);
>  static void igd_pt_i440fx_realize(PCIDevice *pci_dev, Error **errp)
>  {
> +Error *err = NULL;
>  uint32_t val = 0;
>  int rc, i, num;
>  int pos, len;

Can't we get the parent PCIDeviceClass realize function from pci_dev? So
that we don't have to introduce i440fx_realize?


> +i440fx_realize(pci_dev, );
> +if (err != NULL) {
> +error_propagate(errp, err);
> +return;
> +}
> +
>  num = ARRAY_SIZE(igd_host_bridge_infos);
>  for (i = 0; i < num; i++) {
>  pos = igd_host_bridge_infos[i].offset;
> @@ -77,6 +85,7 @@ static void igd_passthrough_i440fx_class_init(ObjectClass 
> *klass, void *data)
>  DeviceClass *dc = DEVICE_CLASS(klass);
>  PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>  
> +i440fx_realize = k->realize;
>  k->realize = igd_pt_i440fx_realize;
>  dc->desc = "IGD Passthrough Host bridge";
>  }
> -- 
> 1.8.3.1
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/4] tools/xl: add a new xl configuration 'nvdimm'

[Haozhong Zhang]

On 01/06/16 05:40, Jan Beulich wrote:
> >>> On 29.12.15 at 12:31,  wrote:
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -962,6 +962,25 @@ FIFO-based event channel ABI support up to 131,071 
> > event channels.
> >  Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
> >  x86).
> >  
> > +=item 

Re: [Xen-devel] [PATCH v3 1/4] libxc: split mapping p2m leaves into a separate function

[Wei Liu]

On Wed, Dec 16, 2015 at 10:24:17AM +0100, Juergen Gross wrote:
> In order to prepare using the virtual mapped linear p2m list for
> migration split mapping of the p2m leaf pages into a separate function.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Andrew Cooper 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] libxc: Defer initialization of start_page for HVM guests

[Wei Liu]

On Tue, Jan 05, 2016 at 05:26:10PM -0500, Boris Ostrovsky wrote:
> With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
> builder if supported") location of ramdisk may not be available to
> HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
> guest supports unmapped initrd.
> 
> So let's move ramdisk info initialization (along with a few other
> operations that are not directly related to allocating magic/special
> pages) from alloc_magic_pages_hvm() to bootlate_hvm().
> 
> Signed-off-by: Boris Ostrovsky 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 04/13] xenstore: move init-xenstore-domain to tools/helpers

[Ian Campbell]

On Fri, 2015-12-18 at 14:14 +0100, Juergen Gross wrote:
> The program init-xenstore-domain to start a xenstore domain instead
> of the xenstored daemon is built, but not installed. Change that.
> 
> Move the program to a new tools subdirectory "helpers" to be able to
> use libxl in a later patch. Otherwise a dependency loop will be
> created.
> 
> While moving modify the coding style to the standard style used in
> the tools directory.

Please don't combine such things with moving the whole file. Or at the very
least please use git send-email/format-patch -M (ideally both do it
separately and use -M).

So long as the file is self consistent I'm not convinced it is actually
worth changing, plus it doesn't actually seem to be following CODING_STYLE
(which is the default style for tools/* as well as xen/*), since hasn't
gained e.g. spaces inside of the if ( x ).

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] RFC Userspace hypercalls

[Jan Beulich]

>>> On 06.01.16 at 15:44,  wrote:
> On 06/01/16 14:14, Jan Beulich wrote:
> On 06.01.16 at 12:44,  wrote:
>>> The HVM ABI (for whatever reason) unilaterally fails
>>> a userspace hypercall with -EPERM, making it impossible for the kernel
>>> to trap-and-forward even it wanted to.
>> Perhaps just to match PV behavior?
> 
> But it doesn't.  PV userspace hypercalls currently end up in the guest
> kernel at the sysenter or int $0x82 handler.

That's not the part I meant it could have been intended to match
in behavior; I only referred to the privilege aspect.

>>> For PV guests, I propose that userspace hypercalls get implemented with
>>> the int $0x82 path exclusively.  i.e. enabling userspace hypercalls
>>> causes the hypercall page writing logic to consider the guest a ring1
>>> kernel, and the int $0x82 entrypoint suitably delegates between a
>>> regular hypercall and a compat hypercall.
>> With int $0x82 being the primary hypercall path for 32-bit guests,
>> I'd be concerned of any code addition, especially that of further
>> conditionals.
> 
> The overhead of one extra conditional in the hypercall path is lost in
> the noise, compared to the overhead of the task switch itself.

Task switch? On the hypercall path?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] MAINTAINERS: add myself for kconfig

[Jan Beulich]

>>> On 06.01.16 at 15:26,  wrote:
> At 06:45 -0700 on 06 Jan (1452062722), Jan Beulich wrote:
>> >>> On 05.01.16 at 13:07,  wrote:
>> > On Wed, 2015-12-16 at 08:41 -0600, Doug Goldstein wrote:
>> >> Added myself as the maintainer of kconfig.
>> >> 
>> >> CC: Ian Campbell 
>> >> CC: Ian Jackson 
>> >> CC: Jan Beulich 
>> >> CC: Keir Fraser 
>> >> CC: Tim Deegan 
>> >> 
>> >> Signed-off-by: Doug Goldstein 
>> > 
>> > Acked-by: Ian Campbell 
>> 
>> Which reminds me that I meant to reply before the holidays,
>> but then didn't get around to.
>> 
>> To be honest, I'm not convinced. On one hand I'm certainly
>> happy for this to not fall under THE REST, but on the other
>> hand I've checked your, Doug, history on both Xen and Linux
>> without finding (on the Linux side) any Kconfig related
>> contribution, and only few earlier ones on either side. I hope
>> you understand that I'm uncertain about a relative newcomer
>> to be immediately granted maintainership over a non-negligible
>> (both in terms of size and functionality) piece of code.
> 
> The usual failure mode for Xen contributors is that they leave the
> code and never follow up; this is a strong sign that Doug is going to
> stick around, and IMO ought to be encouraged!  And in any case Xen as
> a whole has a chronic lack of reviewer bandwidth which will only be
> fixed by welcoming new reviewers.

True, except anyone can be reviewer, not just maintainers.

> If you feel like he may need some shepherding in the short term, maybe
> someone more experienced could be co-maintainer for a bit?

Shepherding isn't the problem, nor would a co-maintainer solve
it (after all any maintainer can approve changes). What I'd like
to see before granting maintainership is some meaningful amount
of (own, i.e. not just pulled over) contributions as well as reviews.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 77087: regressions - FAIL

[osstest service owner]

flight 77087 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77087/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 66879

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 66879
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66879
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66879
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 66879

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  dcdb6588779ac8a0cab513d9a2d5ee0bb1dda1cd
baseline version:
 xen  bf925a9f1254391749f569c1b8fc606036340488

Last test of basis66879  2015-12-21 21:25:56 Z   15 days
Failing since 67053  2015-12-23 06:54:21 Z   13 days3 attempts
Testing same since77087  2016-01-05 02:56:28 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Feng Wu 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev  

Re: [Xen-devel] [PATCH v3 10/11] igd: handle igd-passthrough-isa-bridge setup in realize()

[Stefano Stabellini]

On Tue, 5 Jan 2016, Gerd Hoffmann wrote:
> That way a simple '-device igd-passthrough-isa-bridge,addr=1f' will
> do the setup.

Is this going to change the QEMU command line arguments to use it?


> Also instead of looking up reasonable PCI IDs based on the graphic
> device id simply copy over the ids from the host, thereby reusing the
> infrastructure we have in place for the igd host bridges.  Less code,
> and should be more robust as we don't have to maintain the id table
> to keep things going.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  hw/pci-host/igd.c| 115 
> +--
>  hw/xen/xen_pt.c  |   2 +-
>  include/hw/i386/pc.h |   2 +-
>  3 files changed, 30 insertions(+), 89 deletions(-)
> 
> diff --git a/hw/pci-host/igd.c b/hw/pci-host/igd.c
> index 96b679d..8f32c39 100644
> --- a/hw/pci-host/igd.c
> +++ b/hw/pci-host/igd.c
> @@ -123,111 +123,52 @@ static const TypeInfo igd_passthrough_q35_info = {
>  .class_init= igd_passthrough_q35_class_init,
>  };
>  
> -typedef struct {
> -uint16_t gpu_device_id;
> -uint16_t pch_device_id;
> -uint8_t pch_revision_id;
> -} IGDDeviceIDInfo;
> -
> -/* In real world different GPU should have different PCH. But actually
> - * the different PCH DIDs likely map to different PCH SKUs. We do the
> - * same thing for the GPU. For PCH, the different SKUs are going to be
> - * all the same silicon design and implementation, just different
> - * features turn on and off with fuses. The SW interfaces should be
> - * consistent across all SKUs in a given family (eg LPT). But just same
> - * features may not be supported.
> - *
> - * Most of these different PCH features probably don't matter to the
> - * Gfx driver, but obviously any difference in display port connections
> - * will so it should be fine with any PCH in case of passthrough.
> - *
> - * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
> - * scenarios, 0x9cc3 for BDW(Broadwell).
> - */
> -static const IGDDeviceIDInfo igd_combo_id_infos[] = {
> -/* HSW Classic */
> -{0x0402, 0x8c4e, 0x04}, /* HSWGT1D, HSWD_w7 */
> -{0x0406, 0x8c4e, 0x04}, /* HSWGT1M, HSWM_w7 */
> -{0x0412, 0x8c4e, 0x04}, /* HSWGT2D, HSWD_w7 */
> -{0x0416, 0x8c4e, 0x04}, /* HSWGT2M, HSWM_w7 */
> -{0x041E, 0x8c4e, 0x04}, /* HSWGT15D, HSWD_w7 */
> -/* HSW ULT */
> -{0x0A06, 0x8c4e, 0x04}, /* HSWGT1UT, HSWM_w7 */
> -{0x0A16, 0x8c4e, 0x04}, /* HSWGT2UT, HSWM_w7 */
> -{0x0A26, 0x8c4e, 0x06}, /* HSWGT3UT, HSWM_w7 */
> -{0x0A2E, 0x8c4e, 0x04}, /* HSWGT3UT28W, HSWM_w7 */
> -{0x0A1E, 0x8c4e, 0x04}, /* HSWGT2UX, HSWM_w7 */
> -{0x0A0E, 0x8c4e, 0x04}, /* HSWGT1ULX, HSWM_w7 */
> -/* HSW CRW */
> -{0x0D26, 0x8c4e, 0x04}, /* HSWGT3CW, HSWM_w7 */
> -{0x0D22, 0x8c4e, 0x04}, /* HSWGT3CWDT, HSWD_w7 */
> -/* HSW Server */
> -{0x041A, 0x8c4e, 0x04}, /* HSWSVGT2, HSWD_w7 */
> -/* HSW SRVR */
> -{0x040A, 0x8c4e, 0x04}, /* HSWSVGT1, HSWD_w7 */
> -/* BSW */
> -{0x1606, 0x9cc3, 0x03}, /* BDWULTGT1, BDWM_w7 */
> -{0x1616, 0x9cc3, 0x03}, /* BDWULTGT2, BDWM_w7 */
> -{0x1626, 0x9cc3, 0x03}, /* BDWULTGT3, BDWM_w7 */
> -{0x160E, 0x9cc3, 0x03}, /* BDWULXGT1, BDWM_w7 */
> -{0x161E, 0x9cc3, 0x03}, /* BDWULXGT2, BDWM_w7 */
> -{0x1602, 0x9cc3, 0x03}, /* BDWHALOGT1, BDWM_w7 */
> -{0x1612, 0x9cc3, 0x03}, /* BDWHALOGT2, BDWM_w7 */
> -{0x1622, 0x9cc3, 0x03}, /* BDWHALOGT3, BDWM_w7 */
> -{0x162B, 0x9cc3, 0x03}, /* BDWHALO28W, BDWM_w7 */
> -{0x162A, 0x9cc3, 0x03}, /* BDWGT3WRKS, BDWM_w7 */
> -{0x162D, 0x9cc3, 0x03}, /* BDWGT3SRVR, BDWM_w7 */
> +static const IGDHostInfo igd_isa_bridge_infos[] = {
> +{PCI_VENDOR_ID,   2},
> +{PCI_DEVICE_ID,   2},
> +{PCI_REVISION_ID, 2},
> +{PCI_SUBSYSTEM_VENDOR_ID, 2},
> +{PCI_SUBSYSTEM_ID,2},
>  };
>  
> +static void igd_pt_isa_bridge_realize(PCIDevice *pci_dev, Error **errp)
> +{
> +Error *err = NULL;
> +
> +if (pci_dev->devfn != PCI_DEVFN(0x1f, 0)) {
> +error_setg(errp, "igd isa bridge must have address 1f.0");
> +return;
> +}
> +
> +host_pci_config_copy(pci_dev, ":00:1f.0",
> + igd_isa_bridge_infos,
> + ARRAY_SIZE(igd_isa_bridge_infos),
> + );
> +if (err != NULL) {
> +error_propagate(errp, err);
> +return;
> +}
> +}
> +
>  static void isa_bridge_class_init(ObjectClass *klass, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
>  PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>  
>  dc->desc= "ISA bridge faked to support IGD PT";
> -k->vendor_id= PCI_VENDOR_ID_INTEL;
> +k->realize  = igd_pt_isa_bridge_realize;
>  k->class_id = PCI_CLASS_BRIDGE_ISA;
>  };
>  
>  static TypeInfo igd_passthrough_isa_bridge_info = {
>  .name  = "igd-passthrough-isa-bridge",
>  .parent= 

Re: [Xen-devel] [PATCH] MAINTAINERS: add myself for kconfig

[Lars Kurth]

On 06/01/2016 14:26, "Tim Deegan"  wrote:

>At 06:45 -0700 on 06 Jan (1452062722), Jan Beulich wrote:
>> >>> On 05.01.16 at 13:07,  wrote:
>> > On Wed, 2015-12-16 at 08:41 -0600, Doug Goldstein wrote:
>> >> Added myself as the maintainer of kconfig.
>> >> 
>> >> CC: Ian Campbell 
>> >> CC: Ian Jackson 
>> >> CC: Jan Beulich 
>> >> CC: Keir Fraser 
>> >> CC: Tim Deegan 
>> >> 
>> >> Signed-off-by: Doug Goldstein 
>> > 
>> > Acked-by: Ian Campbell 
>> 
>> Which reminds me that I meant to reply before the holidays,
>> but then didn't get around to.
>> 
>> To be honest, I'm not convinced. On one hand I'm certainly
>> happy for this to not fall under THE REST, but on the other
>> hand I've checked your, Doug, history on both Xen and Linux
>> without finding (on the Linux side) any Kconfig related
>> contribution, and only few earlier ones on either side. I hope
>> you understand that I'm uncertain about a relative newcomer
>> to be immediately granted maintainership over a non-negligible
>> (both in terms of size and functionality) piece of code.
>
>The usual failure mode for Xen contributors is that they leave the
>code and never follow up; this is a strong sign that Doug is going to
>stick around, and IMO ought to be encouraged!  And in any case Xen as
>a whole has a chronic lack of reviewer bandwidth which will only be
>fixed by welcoming new reviewers.
>
>If you feel like he may need some shepherding in the short term, maybe
>someone more experienced could be co-maintainer for a bit?

That sounds like a very a reasonable compromise to me. In addition, the
concern raised by Jan is also somewhat moot in practice: it is just
another instance of the unresolved mismatch between the boundaries of the
maintainer and committer role and the different expectations different
people have.

As we have seen last year in the survey, in theory - aka according to our
governance - committers should always act on the wishes (ACKs) of
maintainers. In practice it comes down to whether the committers trusts a
maintainer enough to apply patches without a re-review. If we follow the
trust principle, which IMHO is not really in conflict with the governance,
there shouldn't be an issue. That is unless, we plan to make changes to
how we operate, for which there does not seem to be consensus.

I was wondering how others see this.

Regards
Lars

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] MAINTAINERS: add myself for kconfig

[Ian Campbell]

On Wed, 2016-01-06 at 14:26 +, Tim Deegan wrote:
> At 06:45 -0700 on 06 Jan (1452062722), Jan Beulich wrote:
> > > > > On 05.01.16 at 13:07,  wrote:
> > > On Wed, 2015-12-16 at 08:41 -0600, Doug Goldstein wrote:
> > > > Added myself as the maintainer of kconfig.
> > > > 
> > > > CC: Ian Campbell 
> > > > CC: Ian Jackson 
> > > > CC: Jan Beulich 
> > > > CC: Keir Fraser 
> > > > CC: Tim Deegan 
> > > > 
> > > > Signed-off-by: Doug Goldstein 
> > > 
> > > Acked-by: Ian Campbell 
> > 
> > Which reminds me that I meant to reply before the holidays,
> > but then didn't get around to.
> > 
> > To be honest, I'm not convinced. On one hand I'm certainly
> > happy for this to not fall under THE REST, but on the other
> > hand I've checked your, Doug, history on both Xen and Linux
> > without finding (on the Linux side) any Kconfig related
> > contribution, and only few earlier ones on either side. I hope
> > you understand that I'm uncertain about a relative newcomer
> > to be immediately granted maintainership over a non-negligible
> > (both in terms of size and functionality) piece of code.
> 
> The usual failure mode for Xen contributors is that they leave the
> code and never follow up; this is a strong sign that Doug is going to
> stick around, and IMO ought to be encouraged!  And in any case Xen as
> a whole has a chronic lack of reviewer bandwidth which will only be
> fixed by welcoming new reviewers.

FWIW I agree with this

A MAINTAINERS entry is also a point of contact and it does seem to me to be
absolutely appropriate for Doug to get CCd on any Kconfig related issues.

We shouldn't be expecting (or encouraging) Kconfig development work in the
context of Xen either, since we do not want to fork this code. So from our
PoV maintenance of the code means liaising with upstream and importing new
versions when appropriate, a bar which I think Doug has easily reached.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 77013: regressions - FAIL

[osstest service owner]

flight 77013 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77013/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 62112
 build-amd64   5 xen-build fail REGR. vs. 62112

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuu6e184363e64a0610c35ca231bfc73cea56eb02f3
baseline version:
 qemuub188780861662e8cf1847ec562799b32bb44f05e

Last test of basis62112  2015-09-18 04:07:28 Z  109 days
Testing same since66538  2015-12-18 16:12:07 Z   18 days8 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 test-amd64-amd64-pairblocked 
 test-amd64-i386-pair blocked 
 test-amd64-amd64-pv  blocked 
 

[Xen-devel] [libvirt test] 77096: regressions - FAIL

[osstest service owner]

flight 77096 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77096/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 66919

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 66919

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 libvirt  ead30f4dd55b2e7f125b6852062f7cc9f727795e
baseline version:
 libvirt  d5a0cf10bcc2088420c6c29545a69fd613f1cc4f

Last test of basis66919  2015-12-22 04:20:28 Z   14 days
Testing same since77096  2016-01-05 04:27:06 Z0 days1 attempts


People who touched revisions under test:
  Dmitry Mishin 
  Eric Blake 
  Laine Stump 
  Maxim Nestratov 
  Michael Chapman 
  Michal Privoznik 
  Wido den Hollander 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   fail
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair blocked 
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 386 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] pc-nvdimm acpi: build ACPI tables for pc-nvdimm devices

[Konrad Rzeszutek Wilk]

On Tue, Jan 05, 2016 at 10:01:26PM +0800, Haozhong Zhang wrote:
> On 01/05/16 11:00, Stefano Stabellini wrote:
> > On Mon, 4 Jan 2016, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 04, 2016 at 04:01:08PM +, Stefano Stabellini wrote:
> > > > CC'ing the Xen tools maintainers and Anthony.
> > > > 
> > > > On Tue, 29 Dec 2015, Haozhong Zhang wrote:
> > > > > Reuse existing NVDIMM ACPI code to build ACPI tables for pc-nvdimm
> > > > > devices. The resulting tables are then copied into Xen guest domain so
> > > > > tha they can be later loaded by Xen hvmloader.
> > > > > 
> > > > > Signed-off-by: Haozhong Zhang 
> > > > 
> > > > How much work would it be to generate the nvdimm acpi tables from the
> > > > Xen toolstack?
> > > 
> > > Why duplicate the code? The QEMU generates the NFIT tables and its 
> > > sub-tables.
> > >
> > >
> > > > Getting the tables from QEMU doesn't seem like a good idea to me, unless
> > > > we start getting the whole set of ACPI tables that way.
> > > 
> > > There is also the ACPI DSDT code - which requires an memory region
> > > to be reserved for the AML code to drop the parameters so that QEMU
> > > can scan the NVDIMM for failures. The region (and size) should be
> > > determined by QEMU since it works on this data.
> > 
> > QEMU can generate the whole set of ACPI tables. Why should we take only
> > the nvdimm tables and not the others?
> >
> NVDIMM tables are the only tables required to support vNVDIMM in this
> patch series, and they are self-contained and not conflict with other
> existing tables built by hvmloader. For other tables built by QEMU, I
> have no idea whether they could work with Xen, so I only take nvdimm
> tables from QEMU.

But you also have to deal with the SSDT code right? And I was under the
impression that if you use hvmloader - it loads the ACPI DSDT which
it had compiled at build-time - only - but not the SSDT?

In other way - just having the ACPI NFIT won't give you the whole
picture - unless you also jam in ACPI _DSM (ACPI0012) methods as
part of the SSDT right?

Or does the ACPI tables generation also include an ACPI SSDT with the
ACPI _DSM methods as part of it? I only see 'nvdimm_build_acpi' and
NFIT comments, nothing about SSDT?

> 
> > I don't think it is wise to have two components which both think are in
> > control of generating ACPI tables, hvmloader (soon to be the toolstack
> > with Anthony's work) and QEMU. From an architectural perspective, it
> > doesn't look robust to me.
> >
> Do you mean whenever nvdimm code in QEMU is changed, we would have to
> make more efforts to ensure it still works with Xen?

Not sure I follow that. How is it different from the efforts to ensure
that the patches here (which only add one ACPI MADT table)
provide the proper support? Wouldn't you do the same type of checking
every time you modify the nvdimm_build_acpi code?


> 
> > Could we take this opportunity to switch to QEMU generating the whole
> > set of ACPI tables?
> >
> Not quite sure how much effort would be taken on this change. CCed
> hvmloader maintainers for their comments.
> 
> Thanks,
> Haozhong

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 77119: regressions - FAIL

[osstest service owner]

flight 77119 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77119/

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. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543

version targeted for testing:
 ovmf c2a892d7c8a78143006bb7fdc95fb18f7e2fc685
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   29 days
Failing since 65593  2015-12-08 23:44:51 Z   28 days   15 attempts
Testing same since77119  2016-01-05 09:02:24 Z1 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Cecil Sheng 
  Chao Zhang 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Paulo Alcantara 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 3888 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] MAINTAINERS: add myself for kconfig

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH] MAINTAINERS: add myself for kconfig"):
> On 06.01.16 at 15:26,  wrote:
> > If you feel like he may need some shepherding in the short term, maybe
> > someone more experienced could be co-maintainer for a bit?
> 
> Shepherding isn't the problem, nor would a co-maintainer solve
> it (after all any maintainer can approve changes). What I'd like
> to see before granting maintainership is some meaningful amount
> of (own, i.e. not just pulled over) contributions as well as reviews.

The work that Doug has been doing to adapt this to our tree, to bring
it in, to negotiate with us, and all of that, _is_ real work.

I'm with Tim and Ian C.

Acked-by: Ian Jackson 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.6-testing test] 77101: regressions - FAIL

[osstest service owner]

flight 77101 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77101/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 63071
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 63071

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd   3 host-install(3)  broken in 76942 pass in 77101
 test-armhf-armhf-xl-xsm   6 xen-boot   fail in 76942 pass in 77101
 test-amd64-amd64-xl-qcow2 9 debian-di-install   fail pass in 76942

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  9 debian-installfail REGR. vs. 63071
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 63071
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 63071

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu9e304f572ac98265f5e7433b6490077962acda97
baseline version:
 qemuu980dfcf5b8d8161871f81d1987b2f8ea5d7d4db9

Last test of basis63071  2015-10-19 15:10:58 Z   78 days
Testing same since66535  2015-12-18 15:50:42 Z   18 days7 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  

[Xen-devel] [qemu-upstream-4.4-testing test] 77082: regressions - FAIL

[osstest service owner]

flight 77082 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77082/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-build fail REGR. vs. 62702

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a

version targeted for testing:
 qemuu2264b0c66075cc34c252a1386f019f8be6240890
baseline version:
 qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0

Last test of basis62702  2015-10-06 15:32:13 Z   91 days
Testing same since66539  2015-12-18 16:12:10 Z   18 days7 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  fail
 build-i386   pass
 build-amd64-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 

Re: [Xen-devel] OVMF related osstest failures on multiple branches

[Ian Campbell]

(Adding Wei and Jan who I should have included before, thread starts at
 http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00442.html )

On Wed, 2016-01-06 at 14:27 +, Ian Campbell wrote:


> Next step is I'm trying 4.6-testing with the newer OVMF to see if this is
> worth pursuing.

Running xen-4.6-testing with ovmf.git 52a99493cce8 instead of cb9a7ebabcd6
does seem to have worked (i.e. the flight hasn't actually finished yet but
it has passed the debian-hvm-install step).

We have in the past, after much discussion[0], backported changes to
Config.mk:OVMF_UPSTREAM_REVISION to pull forward wholesale to a newer ovmf.

On another (more recent) occasion there have been strong objections to
doing so[1]. I think we concluded there that we should add stable-X.Y
branches to git://xenbits.xen.org/ovmf.git and cherry-pick fixes, the
reason nothing happened then was that the backport in question was a
feature request for ovmf on arm64 which is not something we test and was
not therefore something I was comfortable with.

If we consider [0] as precedent then we would want to backport
xen.git 04c5efb0a141 and f046e501bbc to staging-4.4, -4.5 and -4.6 to bring
those branches up to ovmf.git 52a99493cce8.

If we want to follow [1] then the plan of attack is:
 * I need to identify the patch(es) which actually fix this issue and
   cherrypick it into new stable branches in ovmf.git for 4.4, 4.5 and 4.6.
 * Ian J to update OVMF_UPSTREAM_REVISION in the corresponding xen.git
   stable branches to point to all those commits (either branch name or
   SHA, not sure).
 * The release checklist needs updating to include tagging this new tree
   and updating OVMF_UPSTREAM_REVISION to point to the tag instead of the
   commit (I think this is strictly speaking option, but we should do it).
 * We might want to consider retroactively tagging the versions of ovmf
   used in 4.4.[01234], 4.5.[012] and 4.6.0 in ovmf.git, which would be
   helpful for people using gitk etc to look at the history I suppose 

That assumes a seabios/qemut style model to updating ovmf, i.e. ungated
manual Config.mk update, if we were to switch to a gate it would be
different but regardless of the merits of doing things that way it does't
seem like a thing to do on a stable branch.

Ian.

[0] http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04428.html
[1] http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02381.html
 stemming from
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01534.html

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Ian Campbell]

On Wed, 2015-12-23 at 15:53 +0100, Tamas K Lengyel wrote:
> Introduce new vm_event domctl option which allows an event subscriber
> to request all vCPUs not currently pending a vm_event request to be
> paused,
> thus allowing the subscriber to sync up on the state of the domain. This
> is especially useful when the subscribed wants to disable certain events
> from being delivered and wants to ensure no more requests are pending on
> the
> ring before doing so.
> 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> Cc: Razvan Cojocaru 
> Signed-off-by: Tamas K Lengyel 
> ---
>  tools/libxc/include/xenctrl.h | 11 +++
>  tools/libxc/xc_vm_event.c | 16 

Tools side is pretty trivial, assuming there is agreement on the underlying
hypercall interface:

Acked-by: Ian Campbell 

> +/***
>   * Memory sharing operations.

Do you also maintain this? If so do you fancy sending a patch to fix:

>   *
>   * Unles otherwise noted, these calls return 0 on succes, -1 and errno on

"Unless" and "success" ?

Ian..

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 07/11] igd: revamp host config read

[Gerd Hoffmann]

> > +for (i = 0; i < len; i++) {
> > +rc = pread(config_fd, guest->config + list[i].offset,
> > +   list[i].len, list[i].offset);
> > +if (rc != list[i].len) {
> 
> pread is allowed to return early, returning the number of bytes read.
> 

This is a sysfs file though, not a socket or pipe where a partial read
makes sense and will actually happen.  If we can't read something
that'll be because the kernel denies access.

So IMHO it should be fine to treat anything which doesn't give us the
amount of bytes we asked for as an error condition.

cheers,
  Gerd


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel