Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[Juergen Gross]

On 09/03/2015 05:01 PM, David Vrabel wrote:

On 03/09/15 15:55, Juergen Gross wrote:

On 09/03/2015 04:52 PM, David Vrabel wrote:

On 03/09/15 15:45, David Vrabel wrote:

On 03/09/15 15:38, Roger Pau Monné wrote:

El 03/09/15 a les 14.25, Juergen Gross ha escrit:

On 09/03/2015 02:05 PM, Roger Pau Monne wrote:

On systems with memory maps with ranges that don't end at page
boundaries,
like:

[...]
(XEN)  0010 - dfdf9c00 (usable)
(XEN)  dfdf9c00 - dfe4bc00 (ACPI NVS)
[...]

xen_add_extra_mem will create a protected range that ends up at
0xdfdf9c00,
but the function used to check if a memory address is inside of a
protected
range works with pfns, which means that an attempt to map 0xdfdf9c00
will be
refused because the check is performed against 0xdfdf9000 instead of
0xdfdf9c00.

In order to fix this, make sure that the ranges that are added to the
xen_extra_mem array are aligned to page boundaries.

Signed-off-by: Roger Pau Monné 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Juergen Gross 
Cc: xen-de...@lists.xenproject.org
---
AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
---
arch/x86/xen/setup.c | 6 ++
1 file changed, 6 insertions(+)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 55f388e..dcf5865 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
start, phys_addr_t size)
{
int i;

+start = PAGE_ALIGN(start);
+size &= PAGE_MASK;


This is not correct. If start wasn't page aligned and size was, you'll
add one additional page to xen_extra_mem.


I'm not understanding this, let's put an example:

start = 0x8c00
size = 0x1000

After the fixup added above this would become:

start = 0x9000
size = 0x1000

So if anything, I'm adding one page less (because 0x8000 was partly
added, and with the fixup it is not added).


We expand the reserved (i.e., non-RAM) areas down so they're fully
covered with whole pages when we depopulate and 1:1 map them, we should
add extra memory regions that cover these same areas.


Ignore this.  This was nonsense.

We expand the reserved (i.e., non-RAM) areas so they're fully covered
with whole pages when we depopulate and 1:1 map them, we should add the
extra memory such that it does not overlap with with expanded regions.
i.e., round up the start and round down the end (like Roger's patch
does).


Nearly. Roger's patch rounds up start and rounds down the size. It might
add non-RAM partial pages to xen_extra_mem.


Yes.  You're right.


Hmm, thinking more about it, I'd prefer to change xen_extra_mem to use
pfns instead of physical addresses. This would make things much more
clear.

Roger, do you want to do the patch or should I?


Juergen


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

Re: [Xen-devel] Kbuild and Kconfig

[Doug Goldstein]

On 9/3/15 4:56 AM, Tim Deegan wrote:
> Hi,
> 
> At 12:50 -0500 on 02 Sep (1441198200), Doug Goldstein wrote:
>> I just wanted to bring this to a top level post since Jonathan Creekmore
>> and myself have talked with a few maintainers in different threads and
>> on IRC about potentially using Kconfig and/or Kbuild for Xen.
> 
> If we're going to need a configure step before building the
> hypervisor, maybe we should consider using the autoconf runes instead.
> 
> I'm one of the people who objected to requiring ./configure before
> building the hypervisor, but I think it would be better than having
> _two_ config systems which are not synced with each other, esp. if
> we'll want to enable/disable features with matching tools-side code.
> 
> If we do go this way, I think we'd need a ./configure --hypervisor-only,
> or similar, that _only_ makes the various CONFIG_ flags, and doesn't
> do the tedious library & compiler checks that are needed for the
> user-space code.
> 
> Cheers,
> 
> Tim.
> 

I'd only be concerned about the fact that different config switches
would do different things and you would end up with a lot of configure
switches.

e.g. ./configure --with-kexec --without-xenlinux --with-xsm

Currently there is a top level XSM_ENABLE and FLASK_ENABLE and they do
different things in the tools/ and the xen/ directories. For the tools
directory all it does is disable the Flask policy being built (e.g.
XSM_ENABLE=n does that) while XSM bits in the tools appear to always be
built. Then for the xen/ directory XSM_ENABLE=n will actually turn off
XSM support and Flask support while FLASK_ENABLE=n will keep XSM on and
just build the dummy XSM module.

You may also have cases where you want to build functionality into the
tools but not into the hypervisor to ensure that the hypervisor returns
an error and the tools gracefully handle that case which having a top
level configure script would make more difficult.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH 08/13] Planner: ms-queuedaemon: Prep for multiple walkers

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 08/13] Planner: ms-queuedaemon: Prep 
for multiple walkers"):
> On Wed, 2015-09-02 at 16:45 +0100, Ian Jackson wrote:
> > We are going to introduce multiple concurrent streams of planning
> > processing, called `walkers'.
...
> This mostly seems plausible, in so far as I can speak tcl.

Thanks.

> You spotted a bug while explaining the intricacies of upvar/uplevel to me
> IRL, but I didn't see anything further...

Indeed; I have fixed that bug in my tree.

Ian.

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

Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[Juergen Gross]

On 09/03/2015 04:38 PM, Roger Pau Monné wrote:

El 03/09/15 a les 14.25, Juergen Gross ha escrit:

On 09/03/2015 02:05 PM, Roger Pau Monne wrote:

On systems with memory maps with ranges that don't end at page
boundaries,
like:

[...]
(XEN)  0010 - dfdf9c00 (usable)
(XEN)  dfdf9c00 - dfe4bc00 (ACPI NVS)
[...]

xen_add_extra_mem will create a protected range that ends up at
0xdfdf9c00,
but the function used to check if a memory address is inside of a
protected
range works with pfns, which means that an attempt to map 0xdfdf9c00
will be
refused because the check is performed against 0xdfdf9000 instead of
0xdfdf9c00.

In order to fix this, make sure that the ranges that are added to the
xen_extra_mem array are aligned to page boundaries.

Signed-off-by: Roger Pau Monné 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Juergen Gross 
Cc: xen-de...@lists.xenproject.org
---
AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
---
   arch/x86/xen/setup.c | 6 ++
   1 file changed, 6 insertions(+)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 55f388e..dcf5865 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
start, phys_addr_t size)
   {
   int i;

+start = PAGE_ALIGN(start);
+size &= PAGE_MASK;


This is not correct. If start wasn't page aligned and size was, you'll
add one additional page to xen_extra_mem.


I'm not understanding this, let's put an example:

start = 0x8c00
size = 0x1000

After the fixup added above this would become:

start = 0x9000
size = 0x1000

So if anything, I'm adding one page less (because 0x8000 was partly
added, and with the fixup it is not added).


You'd add 9c00-9cff which shouldn't be added (in this example you
shouldn't add anything as no complete page is covered by the range).

You need something like:

end = (start + size) & PAGE_MASK;
start = PAGE_ALIGN(start);
size = end - start;
if (!size)
 return;


Juergen


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

Re: [Xen-devel] Kbuild and Kconfig

[Doug Goldstein]

On 9/3/15 5:31 AM, Jan Beulich wrote:
 On 02.09.15 at 19:50,  wrote:
>> * target only the xen/ directory tree (i.e. not the toolstack, stubdoms
>> or docs)
> 
> As just said in another reply, allowing for ./configure to pass down
> options to the configure mechanism in xen/ would seem desirable (as
> long as configuring in xen/ alone would still work).

My concern would be that the ./configure options would be pretty
unwieldy. e.g.

./configure --without-kexec --without-xenlinux --with-schedule=credit2

You would effectively have to write a script to contain what your
"distro" (e.g. XenServer, Ubuntu with Xen, Amazon's build) wants.
However the Linux kernel has a nice way to pass around a defconfig
and/or .config files to ensure your build always behaves the same. Users
also have an easy way to see what new options have been added since
their .config was generated but autoconf does not have that.

> 
>> * split top level config bits to not affect xen/ tree (currently only
>> XSM_ENABLE / FLASK_ENABLE do)
> 
> As already said by someone else, this shouldn't be necessary. In fact
> I would hope there's (other than debug-build-or-not) no top level
> setting affecting both tools and hypervisor.

In the case of XSM_ENABLE and FLASK_ENABLE which are at the top level
they do affect both the tools/ directory and the xen/ directory but in
two totally different ways. For the tools side XSM is always enabled no
matter the setting but setting either of those to 'n' results in the
Flask policy not being built. For the xen/ directory it appears to
disable XSM support. Hence why I argue that not having top level
settings would be clearer from a usage standpoint.

> 
>> * convert xen/ to Kbuild first and merge this in (since Kconfig relies
>> on Kbuild-y bits which can be undone but if we're going to go to Kbuild
>> in the end why undo it and then redo it)
> 
> To be honest I'm not convinced we want to pull in Kbuild as a whole.
> Achieving the ability to do out-of-tree builds (viewed as desirable
> by Andrew, and I've also long been meaning to see whether this
> could be made work, as that's also my preferred build setup in other
> projects) should be possible without importing everything (and
> perhaps even without importing anything).
> 
> Jan
> 

I can certainly go that route. The xen/ directory already uses Kbuild's
grandfather with a lot of customization so it probably wouldn't be that
world changing but like I said I can avoid it.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xhci_hcd intterrupt affinity in Dom0/DomU limited to single interrupt

[Jan Beulich]

>>> On 03.09.15 at 14:04,  wrote:
 On 02.09.15 at 19:17,  wrote:
>>  From: Jan Beulich 
>>  Sent: Wednesday, September 2, 2015 4:58 AM
> Justin Acker  09/02/15 1:14 AM >>>
>>> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
> Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI])
>>>Subsystem: Dell Device 053e
>>>Flags: bus master, medium devsel, latency 0, IRQ 78
>>>Memory at f7f2 (64-bit, non-prefetchable) [size=64K]
>>>Capabilities: [70] Power Management version 2
>>>Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
>> 
>> This shows that the driver could use up to 8 MSI IRQs, but chose to use just 
> 
>> one. If
>> this is the same under Xen and the native kernel, the driver likely doesn't 
>> know any
>> better. If under native more interrupts are being used, there might be an 
>> issue with
>> Xen specific code in the kernel or hypervisor code. We'd need to see details 
> 
>> to be
>> able to tell.
>> 
>> Please let me know what details I should provide. 

I'd like to emphasize what I said in my previous reply:

> Please, first of all, get your reply style fixed. Just look at the above
> and tell me how a reader should figure which parts of the text were
> written by whom.
>
>[...]
>
>  I am still confused as to whether any device, or in this case xhci_hcd, 
> can use more than one cpu at any given time. My understanding based on 
> David's response is that it cannot due to the event channel mapping. The 
> device interrupt can be pinned to a specific cpu by specifying the 
> affinity. I was hoping there was a way to allow the driver's interrupt to be 
> scheduled to use more than 1 CPU at any given time. 

The problem is that you're mixing up two things: devices and
interrupts. Any individual interrupt can only be serviced by a single
CPU at a time, due to the way event channels get bound. Any
individual device can have more than one interrupt (MSI or MSI-X),
and then each of these interrupts can be serviced on different
CPUs.

Jan


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

Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[Roger Pau Monné]

El 03/09/15 a les 17.20, Juergen Gross ha escrit:
> On 09/03/2015 05:01 PM, David Vrabel wrote:
>> On 03/09/15 15:55, Juergen Gross wrote:
>>> On 09/03/2015 04:52 PM, David Vrabel wrote:
 On 03/09/15 15:45, David Vrabel wrote:
> On 03/09/15 15:38, Roger Pau Monné wrote:
>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
 On systems with memory maps with ranges that don't end at page
 boundaries,
 like:

 [...]
 (XEN)  0010 - dfdf9c00 (usable)
 (XEN)  dfdf9c00 - dfe4bc00 (ACPI NVS)
 [...]

 xen_add_extra_mem will create a protected range that ends up at
 0xdfdf9c00,
 but the function used to check if a memory address is inside of a
 protected
 range works with pfns, which means that an attempt to map
 0xdfdf9c00
 will be
 refused because the check is performed against 0xdfdf9000
 instead of
 0xdfdf9c00.

 In order to fix this, make sure that the ranges that are added
 to the
 xen_extra_mem array are aligned to page boundaries.

 Signed-off-by: Roger Pau Monné 
 Cc: Konrad Rzeszutek Wilk 
 Cc: Boris Ostrovsky 
 Cc: David Vrabel 
 Cc: Juergen Gross 
 Cc: xen-de...@lists.xenproject.org
 ---
 AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
 ---
 arch/x86/xen/setup.c | 6 ++
 1 file changed, 6 insertions(+)

 diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
 index 55f388e..dcf5865 100644
 --- a/arch/x86/xen/setup.c
 +++ b/arch/x86/xen/setup.c
 @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
 start, phys_addr_t size)
 {
 int i;

 +start = PAGE_ALIGN(start);
 +size &= PAGE_MASK;
>>>
>>> This is not correct. If start wasn't page aligned and size was,
>>> you'll
>>> add one additional page to xen_extra_mem.
>>
>> I'm not understanding this, let's put an example:
>>
>> start = 0x8c00
>> size = 0x1000
>>
>> After the fixup added above this would become:
>>
>> start = 0x9000
>> size = 0x1000
>>
>> So if anything, I'm adding one page less (because 0x8000 was partly
>> added, and with the fixup it is not added).
>
> We expand the reserved (i.e., non-RAM) areas down so they're fully
> covered with whole pages when we depopulate and 1:1 map them, we
> should
> add extra memory regions that cover these same areas.

 Ignore this.  This was nonsense.

 We expand the reserved (i.e., non-RAM) areas so they're fully covered
 with whole pages when we depopulate and 1:1 map them, we should add the
 extra memory such that it does not overlap with with expanded regions.
 i.e., round up the start and round down the end (like Roger's patch
 does).
>>>
>>> Nearly. Roger's patch rounds up start and rounds down the size. It might
>>> add non-RAM partial pages to xen_extra_mem.
>>
>> Yes.  You're right.
> 
> Hmm, thinking more about it, I'd prefer to change xen_extra_mem to use
> pfns instead of physical addresses. This would make things much more
> clear.
> 
> Roger, do you want to do the patch or should I?

I can certainly take care of it if you are busy, otherwise I leave it to
you since you have more expertise on it :).

Roger.


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

Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[David Vrabel]

On 03/09/15 15:38, Roger Pau Monné wrote:
> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>>> On systems with memory maps with ranges that don't end at page
>>> boundaries,
>>> like:
>>>
>>> [...]
>>> (XEN)  0010 - dfdf9c00 (usable)
>>> (XEN)  dfdf9c00 - dfe4bc00 (ACPI NVS)
>>> [...]
>>>
>>> xen_add_extra_mem will create a protected range that ends up at
>>> 0xdfdf9c00,
>>> but the function used to check if a memory address is inside of a
>>> protected
>>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>>> will be
>>> refused because the check is performed against 0xdfdf9000 instead of
>>> 0xdfdf9c00.
>>>
>>> In order to fix this, make sure that the ranges that are added to the
>>> xen_extra_mem array are aligned to page boundaries.
>>>
>>> Signed-off-by: Roger Pau Monné 
>>> Cc: Konrad Rzeszutek Wilk 
>>> Cc: Boris Ostrovsky 
>>> Cc: David Vrabel 
>>> Cc: Juergen Gross 
>>> Cc: xen-de...@lists.xenproject.org
>>> ---
>>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>>> ---
>>>   arch/x86/xen/setup.c | 6 ++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>>> index 55f388e..dcf5865 100644
>>> --- a/arch/x86/xen/setup.c
>>> +++ b/arch/x86/xen/setup.c
>>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>>> start, phys_addr_t size)
>>>   {
>>>   int i;
>>>
>>> +start = PAGE_ALIGN(start);
>>> +size &= PAGE_MASK;
>>
>> This is not correct. If start wasn't page aligned and size was, you'll
>> add one additional page to xen_extra_mem.
> 
> I'm not understanding this, let's put an example:
> 
> start = 0x8c00
> size = 0x1000
> 
> After the fixup added above this would become:
> 
> start = 0x9000
> size = 0x1000
> 
> So if anything, I'm adding one page less (because 0x8000 was partly
> added, and with the fixup it is not added).

We expand the reserved (i.e., non-RAM) areas down so they're fully
covered with whole pages when we depopulate and 1:1 map them, we should
add extra memory regions that cover these same areas.

See the use of PFN_DOWN() and PFN_UP() in xen_set_identify_and_remap().

David

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

Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[David Vrabel]

On 03/09/15 15:45, David Vrabel wrote:
> On 03/09/15 15:38, Roger Pau Monné wrote:
>> El 03/09/15 a les 14.25, Juergen Gross ha escrit:
>>> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
 On systems with memory maps with ranges that don't end at page
 boundaries,
 like:

 [...]
 (XEN)  0010 - dfdf9c00 (usable)
 (XEN)  dfdf9c00 - dfe4bc00 (ACPI NVS)
 [...]

 xen_add_extra_mem will create a protected range that ends up at
 0xdfdf9c00,
 but the function used to check if a memory address is inside of a
 protected
 range works with pfns, which means that an attempt to map 0xdfdf9c00
 will be
 refused because the check is performed against 0xdfdf9000 instead of
 0xdfdf9c00.

 In order to fix this, make sure that the ranges that are added to the
 xen_extra_mem array are aligned to page boundaries.

 Signed-off-by: Roger Pau Monné 
 Cc: Konrad Rzeszutek Wilk 
 Cc: Boris Ostrovsky 
 Cc: David Vrabel 
 Cc: Juergen Gross 
 Cc: xen-de...@lists.xenproject.org
 ---
 AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
 ---
   arch/x86/xen/setup.c | 6 ++
   1 file changed, 6 insertions(+)

 diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
 index 55f388e..dcf5865 100644
 --- a/arch/x86/xen/setup.c
 +++ b/arch/x86/xen/setup.c
 @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
 start, phys_addr_t size)
   {
   int i;

 +start = PAGE_ALIGN(start);
 +size &= PAGE_MASK;
>>>
>>> This is not correct. If start wasn't page aligned and size was, you'll
>>> add one additional page to xen_extra_mem.
>>
>> I'm not understanding this, let's put an example:
>>
>> start = 0x8c00
>> size = 0x1000
>>
>> After the fixup added above this would become:
>>
>> start = 0x9000
>> size = 0x1000
>>
>> So if anything, I'm adding one page less (because 0x8000 was partly
>> added, and with the fixup it is not added).
> 
> We expand the reserved (i.e., non-RAM) areas down so they're fully
> covered with whole pages when we depopulate and 1:1 map them, we should
> add extra memory regions that cover these same areas.

Ignore this.  This was nonsense.

We expand the reserved (i.e., non-RAM) areas so they're fully covered
with whole pages when we depopulate and 1:1 map them, we should add the
extra memory such that it does not overlap with with expanded regions.
i.e., round up the start and round down the end (like Roger's patch does).

David

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

Re: [Xen-devel] Kbuild and Kconfig

[Jan Beulich]

>>> On 03.09.15 at 16:04,  wrote:
> On 9/3/15 5:31 AM, Jan Beulich wrote:
> On 02.09.15 at 19:50,  wrote:
>>> * target only the xen/ directory tree (i.e. not the toolstack, stubdoms
>>> or docs)
>> 
>> As just said in another reply, allowing for ./configure to pass down
>> options to the configure mechanism in xen/ would seem desirable (as
>> long as configuring in xen/ alone would still work).
> 
> My concern would be that the ./configure options would be pretty
> unwieldy. e.g.
> 
> ./configure --without-kexec --without-xenlinux --with-schedule=credit2
> 
> You would effectively have to write a script to contain what your
> "distro" (e.g. XenServer, Ubuntu with Xen, Amazon's build) wants.
> However the Linux kernel has a nice way to pass around a defconfig
> and/or .config files to ensure your build always behaves the same. Users
> also have an easy way to see what new options have been added since
> their .config was generated but autoconf does not have that.

And note that I didn't say this "ordinary" way shouldn't be possible;
in fact I meant it to be the default, with ./configure only allowed to
control things that aren't already set in xen/.config (or whatever
it's going to be named). The idea being that when you say
"--without-" and it affects both parts of the tree, you won't
have to select the option another time in the hypervisor configure
process.

>>> * split top level config bits to not affect xen/ tree (currently only
>>> XSM_ENABLE / FLASK_ENABLE do)
>> 
>> As already said by someone else, this shouldn't be necessary. In fact
>> I would hope there's (other than debug-build-or-not) no top level
>> setting affecting both tools and hypervisor.
> 
> In the case of XSM_ENABLE and FLASK_ENABLE which are at the top level
> they do affect both the tools/ directory and the xen/ directory but in
> two totally different ways. For the tools side XSM is always enabled no
> matter the setting but setting either of those to 'n' results in the
> Flask policy not being built. For the xen/ directory it appears to
> disable XSM support. Hence why I argue that not having top level
> settings would be clearer from a usage standpoint.

I think where top level setting make sense (like enabling debug builds)
they should be made work. For existing things at the top level not
really belonging there I agree.

Jan


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

Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[David Vrabel]

On 03/09/15 15:55, Juergen Gross wrote:
> On 09/03/2015 04:52 PM, David Vrabel wrote:
>> On 03/09/15 15:45, David Vrabel wrote:
>>> On 03/09/15 15:38, Roger Pau Monné wrote:
 El 03/09/15 a les 14.25, Juergen Gross ha escrit:
> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>> On systems with memory maps with ranges that don't end at page
>> boundaries,
>> like:
>>
>> [...]
>> (XEN)  0010 - dfdf9c00 (usable)
>> (XEN)  dfdf9c00 - dfe4bc00 (ACPI NVS)
>> [...]
>>
>> xen_add_extra_mem will create a protected range that ends up at
>> 0xdfdf9c00,
>> but the function used to check if a memory address is inside of a
>> protected
>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>> will be
>> refused because the check is performed against 0xdfdf9000 instead of
>> 0xdfdf9c00.
>>
>> In order to fix this, make sure that the ranges that are added to the
>> xen_extra_mem array are aligned to page boundaries.
>>
>> Signed-off-by: Roger Pau Monné 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Boris Ostrovsky 
>> Cc: David Vrabel 
>> Cc: Juergen Gross 
>> Cc: xen-de...@lists.xenproject.org
>> ---
>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>> ---
>>arch/x86/xen/setup.c | 6 ++
>>1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 55f388e..dcf5865 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>> start, phys_addr_t size)
>>{
>>int i;
>>
>> +start = PAGE_ALIGN(start);
>> +size &= PAGE_MASK;
>
> This is not correct. If start wasn't page aligned and size was, you'll
> add one additional page to xen_extra_mem.

 I'm not understanding this, let's put an example:

 start = 0x8c00
 size = 0x1000

 After the fixup added above this would become:

 start = 0x9000
 size = 0x1000

 So if anything, I'm adding one page less (because 0x8000 was partly
 added, and with the fixup it is not added).
>>>
>>> We expand the reserved (i.e., non-RAM) areas down so they're fully
>>> covered with whole pages when we depopulate and 1:1 map them, we should
>>> add extra memory regions that cover these same areas.
>>
>> Ignore this.  This was nonsense.
>>
>> We expand the reserved (i.e., non-RAM) areas so they're fully covered
>> with whole pages when we depopulate and 1:1 map them, we should add the
>> extra memory such that it does not overlap with with expanded regions.
>> i.e., round up the start and round down the end (like Roger's patch
>> does).
> 
> Nearly. Roger's patch rounds up start and rounds down the size. It might
> add non-RAM partial pages to xen_extra_mem.

Yes.  You're right.

David

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

Re: [Xen-devel] [PATCH v6 16/31] xen/arm: ITS: Add virtual ITS commands support

[Julien Grall]

Hi Vijay,

This patch looks good to me. Mostly coding style comment and question
about your code/comments. See below.

On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 14c38b3..fabbad0 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c

[...]

> +bool_t is_valid_collection(struct domain *d, uint32_t col)

You should have define the prototype of is_valid_collection within this
patch rather than in patch #13.

> +{
> +return (col <= (d->max_vcpus + 1));

col <= (vtis_get_max_collections(d)) to avoid hardcoding the number of
collection in multiple place.

> +}
> +
> +static inline uint16_t vits_get_max_collections(struct domain *d)
> +{
> +/*
> + * ITS only supports upto 256 collections without

up to

> + * provisioning external memory. As per vITS design, number of
> + * vCPUS should not exceed max number of collections.
> + */
> +ASSERT(d->max_vcpus < 256);

The problem with ASSERT is it's disappearing with non-debug build. Do
you ensure somewhere that it's never possible to create a domain with
more than 256 CPUs when vITS is in use?

Otherwise, bad things would happen if we are trying to create a guest
with more than 256 vCPUs.

> +
> +return (d->max_vcpus + 1);

As said on v5, please add a comment to explain why d->max_vcpus + 1. It
could be a reference to the public spec...

> +}
> +

[...]

> +static int vits_process_int(struct vcpu *v, struct vgic_its *vits,
> +its_cmd_block *virt_cmd)
> +{
> +uint32_t event, dev_id ;

Spurious space after dev_id.

> +
> +event = virt_cmd->int_cmd.cmd;
> +dev_id = virt_cmd->int_cmd.devid;
> +
> +DPRINTK("%pv: vITS: INT: Device 0x%"PRIx32" id %"PRIu32"\n",
> +v, dev_id, event);
> +
> +/* TODO: Inject LPI */
> +
> +return 0;
> +}


[...]

> +static int vits_process_mapc(struct vcpu *v, struct vgic_its *vits,
> + its_cmd_block *virt_cmd)
> +{
> +uint16_t vcol_id;
> +uint64_t vta = 0;

Setting vta to 0 is not necessary as you override the value 2 lines below.

Note that you could have directly assign the value in the declaration of
the variables. It would have drop 2 lines.

> +
> +vcol_id = virt_cmd->mapc.col;
> +vta = virt_cmd->mapc.ta;
> +
> +DPRINTK("%pv: vITS: MAPC: vCID %"PRIu16" vTA 0x%"PRIx64" valid 
> %"PRIu8"\n",
> +v, vcol_id, vta, virt_cmd->mapc.valid);
> +
> +if ( !is_valid_collection(v->domain, vcol_id) )
> +return -EINVAL;
> +
> +if ( virt_cmd->mapc.valid )
> +{
> +if ( vta > v->domain->max_vcpus )
> +return -EINVAL;
> +vits->collections[vcol_id].target_address = vta;
> +}
> +else
> +vits->collections[vcol_id].target_address = INVALID_PADDR;
> +
> +return 0;
> +}

[...]

> +static int vits_read_virt_cmd(struct vcpu *v, struct vgic_its *vits,
> +  its_cmd_block *virt_cmd)
> +{
> +paddr_t maddr;
> +struct domain *d = v->domain;
> +int ret;
> +
> +ASSERT(spin_is_locked(>lock));
> +
> +if ( !(vits->cmd_base & GITS_CBASER_VALID) )
> +{
> +dprintk(XENLOG_G_ERR, "%pv: vITS: Invalid CBASER\n", v);
> +return 0;
> +}
> +
> +/* Map only the page that is required */

IHMO the "CMD Q can be more than 1 page" was valid and useful. Sorry if
I wasn't enough clear that I wanted the typo fixed on the second sentence.

> +maddr = (vits->cmd_base & GITS_CBASER_PA_MASK) +
> + atomic_read(>cmd_read);
> +
> +DPRINTK("%pv: vITS: Mapping CMD Q maddr 0x%"PRIx64" read 0x%"PRIx32"\n",
> +v, maddr, atomic_read(>cmd_read));
> +
> +ret = vits_access_guest_table(d, maddr, (void *)virt_cmd,
> +  sizeof(its_cmd_block), 0);
> +if ( ret )
> +{
> +dprintk(XENLOG_G_ERR,
> +"%pv: vITS: Failed to get command page @page 0x%"PRIx32"\n",
> +v, atomic_read(>cmd_read));
> +return -EINVAL;
> +}
> +
> +/* No command queue is created by vits to check on Q full */

I don't understand this comment. What do you mean?

> +atomic_add(sizeof(its_cmd_block), >cmd_read);
> +if ( atomic_read(>cmd_read) == vits->cmd_qsize )
> +{
> + DPRINTK("%pv: vITS: Reset read @ 0x%"PRIx32" qsize 0x%"PRIx64"\n",
> + v, atomic_read(>cmd_read), vits->cmd_qsize);
> +
> + atomic_set(>cmd_read, 0);
> +}
> +
> +return 0;
> +}

[...]

> +int vits_domain_init(struct domain *d)
> +{
> +struct vgic_its *vits;
> +int i;
> +
> +ASSERT(is_hardware_domain(d));
> +
> +d->arch.vgic.vits = xzalloc(struct vgic_its);
> +if ( !d->arch.vgic.vits )
> +return -ENOMEM;
> +
> +vits = d->arch.vgic.vits;
> +
> +spin_lock_init(>lock);
> +
> +vits->collections = xzalloc_array(struct its_collection,
> + 

Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[Roger Pau Monné]

El 03/09/15 a les 14.25, Juergen Gross ha escrit:
> On 09/03/2015 02:05 PM, Roger Pau Monne wrote:
>> On systems with memory maps with ranges that don't end at page
>> boundaries,
>> like:
>>
>> [...]
>> (XEN)  0010 - dfdf9c00 (usable)
>> (XEN)  dfdf9c00 - dfe4bc00 (ACPI NVS)
>> [...]
>>
>> xen_add_extra_mem will create a protected range that ends up at
>> 0xdfdf9c00,
>> but the function used to check if a memory address is inside of a
>> protected
>> range works with pfns, which means that an attempt to map 0xdfdf9c00
>> will be
>> refused because the check is performed against 0xdfdf9000 instead of
>> 0xdfdf9c00.
>>
>> In order to fix this, make sure that the ranges that are added to the
>> xen_extra_mem array are aligned to page boundaries.
>>
>> Signed-off-by: Roger Pau Monné 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Boris Ostrovsky 
>> Cc: David Vrabel 
>> Cc: Juergen Gross 
>> Cc: xen-de...@lists.xenproject.org
>> ---
>> AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
>> ---
>>   arch/x86/xen/setup.c | 6 ++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 55f388e..dcf5865 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
>> start, phys_addr_t size)
>>   {
>>   int i;
>>
>> +start = PAGE_ALIGN(start);
>> +size &= PAGE_MASK;
> 
> This is not correct. If start wasn't page aligned and size was, you'll
> add one additional page to xen_extra_mem.

I'm not understanding this, let's put an example:

start = 0x8c00
size = 0x1000

After the fixup added above this would become:

start = 0x9000
size = 0x1000

So if anything, I'm adding one page less (because 0x8000 was partly
added, and with the fixup it is not added).

Roger.

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

Re: [Xen-devel] [PATCH RFC v2 0/4] HVM x86 deprivileged mode operations

[David Vrabel]

On 03/09/15 17:01, Ben Catterall wrote:
> 
> Intel Intel 2.2GHz Xeon E5-2407 0 processor:
> 
> 1.55e-06 seconds was the average time for performing the write without the
>  deprivileged code running.
> 
> 5.75e-06 seconds was the average time for performing the write with the
>  deprivileged code running.
> 
> So approximately 351% overhead
> 
> AMD Opteron 2376:
> -
> 1.74e-06 seconds was the average time for performing the write without the
>  deprivileged code running.
> 3.10e-06 seconds was the average time for performing the write with an entry 
> and
>  exit from deprvileged mode.
> 
> So approximately 178% overhead.

How does this compare to the overhead of passing the I/O through to qemu?

David

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

[Xen-devel] Commit moratorium

[Wei Liu]

Committers,

Xen tree is going to branch at 4.6 RC3. I don't want to branch when
master != staging, so please avoid committing new patches to staging now
to let master catch up with staging. Another announcement will be made
when the moratorium is lifted.

Thanks
Wei.

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

Re: [Xen-devel] [OSSTEST PATCH 2/2] cr-daily-branch: Make sg-report-flight ignore bisections

[Ian Campbell]

On Thu, 2015-09-03 at 11:45 +0100, Ian Jackson wrote:
> sg-report-flight when testing X' (with a baseline of X) can justify a
> failure of T(X',Y,Z) with a bisection failure of T(X,Y'',Z).
> 
> If Y'' breaks T then this makes it look to sg-report-flight like T was
> already broken in X; cr-daily-branch could then push X' even though it
> is actually broken.
> 
> This happened rarely, because cr-daily-branch's sg-report-flight would
> only look at flights on the right branch, so only a bisection of T on
> that branch can cause this, but nevertheless this can produce bad
> pushes.
> 
> So: have cr-daily-branch pass a --blessings option to cr-daily-branch,
> so that it only looks at (usually) `real' rather than the default of
> `real' and also `real-bisect'.
> 
> An alternative, more complicated, approach would be for
> sg-report-flight to compare versions of Y, Z, et al, when looking for
> justifications, but I'm not sure this is desirable because it would
> effectively reset the heisenbug compensator each time any other tree
> changed.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - PUSHED

[Ian Campbell]

On Thu, 2015-09-03 at 10:35 -0600, Jim Fehlig wrote:
> On 09/03/2015 05:37 AM, Ian Campbell wrote:
> > On Thu, 2015-09-03 at 11:26 +0100, Ian Campbell wrote:
> > > Notice that it has bound to 127.0.1.1 and not to 10.80.228.77!
> > So while I investigate how to make d-i not create these entries I also
> > removed the line from /etc/hosts such that looking up the FQDN gives 
> > the
> > non-local IP. But:
> > 
> > 
> >  root@moss-bug:/var/log# strace -o /tmp/virsh -fff virsh --debug 0 
> > migrate --live debian.guest.osstest xen+ssh://10.80.228.77
> >  migrate: live(bool): (none)
> >  migrate: domain(optdata): debian.guest.osstest
> >  migrate: desturi(optdata): xen+ssh://10.80.228.77
> >  migrate: found option : debian.guest.osstest
> >  migrate:  trying as domain NAME
> >  migrate: found option : debian.guest.osstest
> >  migrate:  trying as domain NAME
> >  error: internal error: Failed to send migration data to 
> > destination host
> > 
> > The senders libxl-driver.log says:
> > 
> > 2015-09-03 12:29:45 BST libxl-save-helper: debug: starting save: 
> > Success
> > 2015-09-03 12:29:45 BST xc: detail: fd 27, dom 3, max_iters 0, 
> > max_factor 0, flags 1, hvm 0
> > 2015-09-03 12:29:45 BST xc: info: Saving domain 3, type x86 PV
> > 2015-09-03 12:29:45 BST xc: detail: 64 bits, 4 levels
> > 2015-09-03 12:29:45 BST xc: detail: max_pfn 0x1, p2m_frames 256
> > 2015-09-03 12:29:45 BST xc: detail: max_mfn 0x12
> > 2015-09-03 12:29:46 BST xc: error: Failed to write page data to stream 
> > (104 = Connection reset by peer): Internal error
> > 2015-09-03 12:29:46 BST xc: error: Save failed (104 = Connection reset 
> > by peer): Internal error
> > 2015-09-03 12:29:46 BST libxl-save-helper: debug: complete r=-1: 
> > Connection reset by peer
> > 2015-09-03 12:29:46 BST libxl: error: 
> > libxl_stream_write.c:329:libxl__xc_domain_save_done: saving domain: 
> > domain did not respond to suspend request: Connection reset by peer
> > 2015-09-03 12:29:46 BST libxl: debug: 
> > libxl_event.c:1874:libxl__ao_complete: ao 0x7f67b3f63e90: complete, rc=
> > -8
> > 2015-09-03 12:29:46 BST libxl: debug: 
> > libxl_event.c:1843:libxl__ao__destroy: ao 0x7f67b3f63e90: destroy
> > 2015-09-03 12:29:46 BST libxl: debug: libxl.c:526:libxl_domain_resume: 
> > ao 0x7f67b3fa44b0: create: how=(nil) callback=(nil) 
> > poller=0x7f67a0002610
> > 2015-09-03 12:29:46 BST xc: error: Dom 3 not suspended: (shutdown 0, 
> > reason 255): Internal error
> > 2015-09-03 12:29:46 BST libxl: error: 
> > libxl_dom_suspend.c:409:libxl__domain_resume: xc_domain_resume failed 
> > for domain 3: Invalid argument
> > 2015-09-03 12:29:46 BST libxl: debug: 
> > libxl_event.c:1874:libxl__ao_complete: ao 0x7f67b3fa44b0: complete, rc=
> > -3
> > 2015-09-03 12:29:46 BST libxl: debug: libxl.c:529:libxl_domain_resume: 
> > ao 0x7f67b3fa44b0: inprogress: poller=0x7f67a0002610, flags=ic
> > 2015-09-03 12:29:46 BST libxl: debug: 
> > libxl_event.c:1843:libxl__ao__destroy: ao 0x7f67b3fa44b0: destroy
> > 
> > While the receiver has:
> > 
> > 2015-09-03 12:29:45 BST libxl-save-helper: debug: starting restore: 
> > Success
> > 2015-09-03 12:29:45 BST xc: detail: fd 31, dom 4, hvm 0, pae 0, 
> > superpages 0, checkpointed_stream 0
> > 2015-09-03 12:29:45 BST xc: info: Found x86 PV domain from Xen 4.6
> > 2015-09-03 12:29:45 BST xc: info: Restoring domain
> > 2015-09-03 12:29:45 BST xc: detail: 64 bits, 4 levels
> > 2015-09-03 12:29:45 BST xc: detail: max_mfn 0x12
> > 2015-09-03 12:29:45 BST xc: detail: Expanded p2m from 0 to 0x1
> > 2015-09-03 12:29:45 BST xc: error: Failed to read 4202504 bytes of data 
> > for record (0x0001, Page data) (11 = Resource temporarily 
> > unavailabl): Internal error
> > 2015-09-03 12:29:45 BST xc: error: Restore failed (11 = Resource 
> > temporarily unavailabl): Internal error
> > 2015-09-03 12:29:45 BST libxl-save-helper: debug: complete r=-1: 
> > Resource temporarily unavailable
> > 2015-09-03 12:29:45 BST libxl: error: 
> > libxl_stream_read.c:749:libxl__xc_domain_restore_done: restoring 
> > domain: Resource temporarily unavailable
> > 2015-09-03 12:29:45 BST libxl: error: 
> > libxl_create.c:1141:domcreate_rebuild_done: cannot (re-)build domain: 
> > -3
> > 2015-09-03 12:29:46 BST libxl: debug: libxl.c:1708:devices_destroy_cb: 
> > forked pid 18738 for destroy of domain 4
> > 2015-09-03 12:29:46 BST libxl: debug: 
> > libxl_event.c:1874:libxl__ao_complete: ao 0x7fbb7687e900: complete, rc=
> > -3
> > 2015-09-03 12:29:46 BST libxl: debug: 
> > libxl_event.c:1843:libxl__ao__destroy: ao 0x7fbb7687e900: destroy
> > 
> > 
> > "xc: error: Failed to write page data to stream (104 = Connection reset 
> > by
> > peer): Internal error" seems to be the initial failure.
> 
> I wonder if this has anything to do with migration V2?

That would be my first guess.

>  I noticed a migration 
> regression a few days back, but later realized that the sender was 4.5 and 
> receiver was 4.6. I planned 

Re: [Xen-devel] [Xen-users] Changing netback tx interrupts affinity on Dom0

[Jintack Lim]

On Thu, Sep 3, 2015 at 12:06 PM, Jintack Lim 
wrote:

> Hi,
>
> I was trying to set irq affinity by writing a value
> to /proc/irq//smp_affinity,
> but smp_affinity value was not changed at all.
> Ian suggested to take this to the devel list.
> I'm working on Xen4.5, ARMv8.
>

I checked that setting smp_affinity works on Xen4.5, x86.
So, probably this is an ARM specific issue.


>
> Thanks,
> Jintack
>
> On Thu, Sep 3, 2015 at 11:34 AM, Ian Campbell 
> wrote:
>
>> On Thu, 2015-09-03 at 10:59 -0400, Jintack Lim wrote:
>> > Hi,
>> >
>> > While I was running Apache server,
>> > I found that one of Dom0 vcpu is running 100% to handle irqs,
>> > and those irqs are set to be processed only on that specific vcpu.
>> >
>> > Referring to this document,
>> > http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide
>> > I tried to change smp_affinity by writing a value to /proc/irq/> > -no>/smp_affinity,
>> > however the smp_affinity value was not changed.
>> >
>> > I'm working on Xen 4.5 on ARMv8,
>> > and the irq is netback tx interrupt.
>> >
>> > # cat /proc/irq/106/smp_affinity
>> > 1
>> >
>> > # cat /proc/interrupts
>> > ...
>> > 106:  53849  0  0  0   xen-dyn-event
>> > vif1.1-q0-tx
>> > 107:  1  0  0  0   xen-dyn-event
>> > vif1.1-q0-rx
>> > 108:  61460  0  0  0   xen-dyn-event
>> > vif1.1-q1-tx
>> > 109:  1  0  0  0   xen-dyn-event
>> > vif1.1-q1-rx
>> > 110:  67118  0  0  0   xen-dyn-event
>> > vif1.1-q2-tx
>> > 111:  1  0  0  0   xen-dyn-event
>> > vif1.1-q2-rx
>> > 112:  58273  0  0  0   xen-dyn-event
>> > vif1.1-q3-tx
>> > 113:  1  0  0  0   xen-dyn-event
>> > vif1.1-q3-rx
>> > ...
>> >
>> > What would be the way to change smp_affinity?
>>
>> It should be via /proc/irq//smp_affinity as you've tried, I asked
>> Stefano and he things this was already implemented in 4.5 even. That it is
>> not happening would be a bug, I think.
>>
>> I'd suggest you take this to the devel list as a bug.
>>
>> > and where is the affinity set initially for netback tx interrupts?
>>
>> Not, sure, I think it might just be generic IRQ code.
>>
>> Ian.
>>
>>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH V2] libxl: don't overwrite error from virNetSocketNewConnectTCP()

[Jim Fehlig]

Remove redundant error reporting in libxlDomainMigrationPerform().
virNetSocketNewConnectTCP() is perfectly capable of reporting
sensible errors.

Signed-off-by: Jim Fehlig 
---

V2:
Actually try to compile the code and find saved_errno is no
longer used - remove it.

 src/libxl/libxl_migration.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 9609e06..0d23e5f 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -472,7 +472,6 @@ libxlDomainMigrationPerform(libxlDriverPrivatePtr driver,
 virURIPtr uri = NULL;
 virNetSocketPtr sock;
 int sockfd = -1;
-int saved_errno = EINVAL;
 int ret = -1;
 
 /* parse dst host:port from uri */
@@ -487,12 +486,8 @@ libxlDomainMigrationPerform(libxlDriverPrivatePtr driver,
 /* socket connect to dst host:port */
 if (virNetSocketNewConnectTCP(hostname, portstr,
   AF_UNSPEC,
-  ) < 0) {
-virReportSystemError(saved_errno,
- _("unable to connect to '%s:%s'"),
- hostname, portstr);
+  ) < 0)
 goto cleanup;
-}
 
 if (virNetSocketSetBlocking(sock, true) < 0) {
 virObjectUnref(sock);
-- 
2.5.0


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

[Xen-devel] [PATCH v4 1/2] xen: move perform_gunzip to common

[Stefano Stabellini]

The current gunzip code to decompress the Dom0 kernel is implemented in
inflate.c which is included by bzimage.c.

I am looking to doing the same on ARM64 but there is quite a bit of
boilerplate definitions that I would need to import in order for
inflate.c to work correctly.

Instead of copying/pasting the code from x86/bzimage.c, move those
definitions to a new common file, gunzip.c. Export only perform_gunzip
and gzip_check. Leave output_length where it is.

Signed-off-by: Stefano Stabellini 
Acked-by: Jan Beulich 
CC: andrew.coop...@citrix.com

---
Changes in v4:
- move gunzip.init.o to its alphabetically correct place

Changes in v3:
- build gunzip.c as gunzip.init.o
- remove #include 
- remove __init from declarations

Changes in v2:
- the patch has been reworked from scratch
---
 xen/arch/x86/bzimage.c   |  134 +
 xen/common/Makefile  |1 +
 xen/common/gunzip.c  |  137 ++
 xen/include/xen/gunzip.h |7 +++
 4 files changed, 146 insertions(+), 133 deletions(-)
 create mode 100644 xen/common/gunzip.c
 create mode 100644 xen/include/xen/gunzip.h

diff --git a/xen/arch/x86/bzimage.c b/xen/arch/x86/bzimage.c
index c86c39e..50ebb84 100644
--- a/xen/arch/x86/bzimage.c
+++ b/xen/arch/x86/bzimage.c
@@ -4,148 +4,16 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
-#define HEAPORDER 3
-
-static unsigned char *__initdata window;
-#define memptr long
-static memptr __initdata free_mem_ptr;
-static memptr __initdata free_mem_end_ptr;
-
-#define WSIZE   0x8000
-
-static unsigned char *__initdata inbuf;
-static unsigned __initdata insize;
-
-/* Index of next byte to be processed in inbuf: */
-static unsigned __initdata inptr;
-
-/* Bytes in output buffer: */
-static unsigned __initdata outcnt;
-
-#define OF(args)args
-#define STATIC  static
-
-#define memzero(s, n)   memset((s), 0, (n))
-
-typedef unsigned char   uch;
-typedef unsigned short  ush;
-typedef unsigned long   ulg;
-
-#define INIT__init
-#define INITDATA__initdata
-
-#define get_byte()  (inptr < insize ? inbuf[inptr++] : fill_inbuf())
-
-/* Diagnostic functions */
-#ifdef DEBUG
-#  define Assert(cond, msg) do { if (!(cond)) error(msg); } while (0)
-#  define Trace(x)  do { fprintf x; } while (0)
-#  define Tracev(x) do { if (verbose) fprintf x ; } while (0)
-#  define Tracevv(x)do { if (verbose > 1) fprintf x ; } while (0)
-#  define Tracec(c, x)  do { if (verbose && (c)) fprintf x ; } while (0)
-#  define Tracecv(c, x) do { if (verbose > 1 && (c)) fprintf x ; } while (0)
-#else
-#  define Assert(cond, msg)
-#  define Trace(x)
-#  define Tracev(x)
-#  define Tracevv(x)
-#  define Tracec(c, x)
-#  define Tracecv(c, x)
-#endif
-
-static long __initdata bytes_out;
-static void flush_window(void);
-
-static __init void error(char *x)
-{
-panic("%s", x);
-}
-
-static __init int fill_inbuf(void)
-{
-error("ran out of input data");
-return 0;
-}
-
-
-#include "../../common/inflate.c"
-
-static __init void flush_window(void)
-{
-/*
- * The window is equal to the output buffer therefore only need to
- * compute the crc.
- */
-unsigned long c = crc;
-unsigned n;
-unsigned char *in, ch;
-
-in = window;
-for ( n = 0; n < outcnt; n++ )
-{
-ch = *in++;
-c = crc_32_tab[((int)c ^ ch) & 0xff] ^ (c >> 8);
-}
-crc = c;
-
-bytes_out += (unsigned long)outcnt;
-outcnt = 0;
-}
-
 static __init unsigned long output_length(char *image, unsigned long image_len)
 {
 return *(uint32_t *)[image_len - 4];
 }
 
-static __init int gzip_check(char *image, unsigned long image_len)
-{
-unsigned char magic0, magic1;
-
-if ( image_len < 2 )
-return 0;
-
-magic0 = (unsigned char)image[0];
-magic1 = (unsigned char)image[1];
-
-return (magic0 == 0x1f) && ((magic1 == 0x8b) || (magic1 == 0x9e));
-}
-
-static __init int perform_gunzip(char *output, char *image, unsigned long 
image_len)
-{
-int rc;
-
-if ( !gzip_check(image, image_len) )
-return 1;
-
-window = (unsigned char *)output;
-
-free_mem_ptr = (unsigned long)alloc_xenheap_pages(HEAPORDER, 0);
-free_mem_end_ptr = free_mem_ptr + (PAGE_SIZE << HEAPORDER);
-
-inbuf = (unsigned char *)image;
-insize = image_len;
-inptr = 0;
-
-makecrc();
-
-if ( gunzip() < 0 )
-{
-rc = -EINVAL;
-}
-else
-{
-rc = 0;
-}
-
-free_xenheap_pages((void *)free_mem_ptr, HEAPORDER);
-
-return rc;
-}
-
 struct __packed setup_header {
 uint8_t _pad0[0x1f1];   /* skip uninteresting stuff */
 uint8_t setup_sects;
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 3fdf931..e681aaa 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -10,6 +10,7 @@ obj-y += 

Re: [Xen-devel] [PATCH 15/16] xen/vtd: prevent from assign the device with shared rmrr

[Tamas K Lengyel]

So this change in 4.6 prevents me from passing through devices that have
worked previously with VT-d:

(XEN) [VT-D] cannot assign :00:1a.0 with shared RMRR at ae8a9000 for
Dom30.
(XEN) [VT-D] cannot assign :00:1d.0 with shared RMRR at ae8a9000 for
Dom31.

The devices are the USB 2.0 devices on a DQ67SW motherboard:

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04)

Tamas


On Wed, Jul 22, 2015 at 9:44 AM, Ian Jackson 
wrote:

> From: Tiejun Chen 
>
> Currently we're intending to cover this kind of devices
> with shared RMRR simply since the case of shared RMRR is
> a rare case according to our previous experiences. But
> late we can group these devices which shared rmrr, and
> then allow all devices within a group to be assigned to
> same domain.
>
> CC: Yang Zhang 
> CC: Kevin Tian 
> Signed-off-by: Tiejun Chen 
> Acked-by: Kevin Tian 
> ---
>  xen/drivers/passthrough/vtd/iommu.c |   30 +++---
>  1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index 8a8d763..ce5c295 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2293,13 +2293,37 @@ static int intel_iommu_assign_device(
>  if ( list_empty(_drhd_units) )
>  return -ENODEV;
>
> +seg = pdev->seg;
> +bus = pdev->bus;
> +/*
> + * In rare cases one given rmrr is shared by multiple devices but
> + * obviously this would put the security of a system at risk. So
> + * we should prevent from this sort of device assignment.
> + *
> + * TODO: in the future we can introduce group device assignment
> + * interface to make sure devices sharing RMRR are assigned to the
> + * same domain together.
> + */
> +for_each_rmrr_device( rmrr, bdf, i )
> +{
> +if ( rmrr->segment == seg &&
> + PCI_BUS(bdf) == bus &&
> + PCI_DEVFN2(bdf) == devfn &&
> + rmrr->scope.devices_cnt > 1 )
> +{
> +printk(XENLOG_G_ERR VTDPREFIX
> +   " cannot assign %04x:%02x:%02x.%u"
> +   " with shared RMRR at %"PRIx64" for Dom%d.\n",
> +   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> +   rmrr->base_address, d->domain_id);
> +return -EPERM;
> +}
> +}
> +
>  ret = reassign_device_ownership(hardware_domain, d, devfn, pdev);
>  if ( ret )
>  return ret;
>
> -seg = pdev->seg;
> -bus = pdev->bus;
> -
>  /* Setup rmrr identity mapping */
>  for_each_rmrr_device( rmrr, bdf, i )
>  {
> --
> 1.7.10.4
>
>
> ___
> 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] how to boot from multiple xen version?

[big strong]

I've installed xen4.4 on ubuntu1404 with aptitude. Recently, in order to
test the Xen4.6, I manually compiled and installed Xen4.6 without remove
the Xen4.4. Now the machine cannot boot normally. I mean booting stop at a
sceen shows:
>
>
> Loading Xen Xen.
> WARNING: No Console will be available to OS.
> Loading linux 3.13.0-24-generic ...
> Loading initial ramdisk ...


Actually, I'm ok with this. Because I can still connect the dom0 using ssh
before installing Xen 4.6. But after the installing, the network cannot be
connected,

This is the grub.cfg file in /boot/grub/:

#
>
> # DO NOT EDIT THIS FILE
>
> #
>
> # It is automatically generated by grub-mkconfig using templates
> # from /etc/grub.d and settings from /etc/default/grub
> #
> ### BEGIN /etc/grub.d/00_header ###
> if [ -s $prefix/grubenv ]; then
>   set have_grubenv=true
>   load_env
> fi
> if [ "${next_entry}" ] ; then
>set default="${next_entry}"
>set next_entry=
>save_env next_entry
>set boot_once=true
> else
>set default="Ubuntu GNU/Linux, with Xen hypervisor"
> fi
> if [ x"${feature_menuentry_id}" = xy ]; then
>   menuentry_id_option="--id"
> else
>   menuentry_id_option=""
> fi
> export menuentry_id_option
> if [ "${prev_saved_entry}" ]; then
>   set saved_entry="${prev_saved_entry}"
>   save_env saved_entry
>   set prev_saved_entry=
>   save_env prev_saved_entry
>   set boot_once=true
> fi
> function savedefault {
>   if [ -z "${boot_once}" ]; then
> saved_entry="${chosen}"
> save_env saved_entry
>   fi
> }
> function recordfail {
>   set recordfail=1
>   if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then
> save_env recordfail; fi; fi
> }
> function load_video {
>   if [ x$feature_all_video_module = xy ]; then
> insmod all_video
>   else
> insmod efi_gop
> insmod efi_uga
> insmod ieee1275_fb
> insmod vbe
> insmod vga
> insmod video_bochs
> insmod video_cirrus
>   fi
> }
> if [ x$feature_default_font_path = xy ] ; then
>font=unicode
> else
> insmod part_gpt
> insmod lvm
> insmod ext2
> set
> root='lvmid/D6XXXa-yAcw-xbjd-5AXp-wzhu-gzU1-7avET9/kiowbS-lgZx-J4Us-toiX-mc4m-xZgB-2dA2JA'
> if [ x$feature_platform_search_hint = xy ]; then
>   search --no-floppy --fs-uuid --set=root
> --hint='lvmid/D6XXXa-yAcw-xbjd-5AXp-wzhu-gzU1-7avET9/kiowbS-lgZx-J4Us-toiX-mc4m-xZgB-2dA2JA'
>  0f4768d7-64dd-4e80-819d-1f58b4150505
> else
>   search --no-floppy --fs-uuid --set=root
> 0f4768d7-64dd-4e80-819d-1f58b4150505
> fi
> font="/usr/share/grub/unicode.pf2"
> fi
> if loadfont $font ; then
>   set gfxmode=auto
>   load_video
>   insmod gfxterm
>   set locale_dir=$prefix/locale
>   set lang=en_HK
>   insmod gettext
> fi
> terminal_output gfxterm
> if [ "${recordfail}" = 1 ] ; then
>   set timeout=-1
> else
>   if [ x$feature_timeout_style = xy ] ; then
> set timeout_style=menu
> set timeout=2
>   # Fallback normal timeout code in case the timeout_style feature is
>   # unavailable.
>   else
> set timeout=2
>   fi
> fi
> ### END /etc/grub.d/00_header ###
> ### BEGIN /etc/grub.d/05_debian_theme ###
> set menu_color_normal=white/black
> set menu_color_highlight=black/light-gray
> ### END /etc/grub.d/05_debian_theme ###
> ### BEGIN /etc/grub.d/09_linux_xen ###
> menuentry 'Ubuntu GNU/Linux, with Xen hypervisor' --class ubuntu --class
> gnu-linux --class gnu --class os --class xen $menuentry_id_option
> 'xen-gnulinux-simple-0f4768d7-64dd-4e80-819d-1f58b4150505' {
> insmod part_gpt
> insmod ext2
> set root='hd0,gpt2'
> if [ x$feature_platform_search_hint = xy ]; then
>   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
> --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
>  0a900dc0-5839-4ffc-9b16-f5f513ae2d99
> else
>   search --no-floppy --fs-uuid --set=root
> 0a900dc0-5839-4ffc-9b16-f5f513ae2d99
> fi
> echo'Loading Xen xen ...'
> if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
> xen_rm_opts=
> else
> xen_rm_opts="no-real-mode edd=off"
> fi
> multiboot   /xen.gz placeholder  dom0_mem=8192M,max:8192M
> ${xen_rm_opts}
> echo'Loading Linux 3.13.0-24-generic ...'
> module  /vmlinuz-3.13.0-24-generic placeholder
> root=/dev/mapper/storage--vg-root ro
> echo'Loading initial ramdisk ...'
> module  --nounzip   /initrd.img-3.13.0-24-generic
> }
> submenu 'Advanced options for Ubuntu GNU/Linux (with Xen hypervisor)'
> $menuentry_id_option
> 'gnulinux-advanced-0f4768d7-64dd-4e80-819d-1f58b4150505' {
> submenu 'Xen hypervisor, version xen' $menuentry_id_option
> 'xen-hypervisor-xen-0f4768d7-64dd-4e80-819d-1f58b4150505' {
> menuentry 'Ubuntu GNU/Linux, with Xen xen and Linux
> 3.13.0-24-generic' --class ubuntu --class gnu-linux --class gnu --class os
> --class xen $menuentry_id_option
> 'xen-gnulinux-3.13.0-24-generic-advanced-0f4768d7-64dd-4e80-819d-1f58b4150505'
> {

[Xen-devel] [PATCH for 4.6] tools/xen-access: use PRI_xen_pfn

[Wei Liu]

Otherwise when building with 32bit compiler, we get:

xen-access.c: In function 'xenaccess_init':
xen-access.c:263:5: error: format '%llx' expects argument of type 'long long 
unsigned int', but argument 3 has type 'xen_pfn_t' [-Werror=format]
cc1: all warnings being treated as errors

Signed-off-by: Wei Liu 
---
Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 
Cc: Ian Jackson 
Cc: Ian Campbell 
---
 tools/tests/xen-access/xen-access.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index cdb8f4e..a52ca6e 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -260,7 +260,7 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t 
domain_id)
 goto err;
 }
 
-DPRINTF("max_gpfn = %"PRIx64"\n", xenaccess->max_gpfn);
+DPRINTF("max_gpfn = %"PRI_xen_pfn"\n", xenaccess->max_gpfn);
 
 return xenaccess;
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v4 2/2] xen/arm: support gzip compressed kernels

[Julien Grall]

Hi Stefano,

On 03/09/15 18:54, Stefano Stabellini wrote:
> Free the memory used for the compressed kernel and update the relative
> mod->start and mod->size parameters with the uncompressed ones.
> 
> Signed-off-by: Stefano Stabellini 
> CC: julien.gr...@citrix.com
> CC: ian.campb...@citrix.com

With the 2 comments coding style changes, see below:

Reviewed-by: Julien Grall 

[...]

> +static __init int kernel_decompress(struct kernel_info *info,
> + paddr_t *addr, paddr_t *size)
> +{

[...]

> +end = output + (1 << (kernel_order_out + PAGE_SHIFT));
> +/* Need to free pages after output_size here because they won't be
> + * freed by discard_initial_modules */

Multi-line comment on Xen should be:

/*
 * Need ...
 * freed ...
 */

> +output += (output_size + PAGE_SIZE - 1) & PAGE_MASK;
> +for ( ; output < end; output += PAGE_SIZE )
> +free_domheap_page(virt_to_page(output));
> +
> +return 0;
> +}
> +
>  #ifdef CONFIG_ARM_64
>  /*
>   * Check if the image is a 64-bit Image.
> @@ -463,6 +520,20 @@ int kernel_probe(struct kernel_info *info)
>  printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
> info->initrd_bootmodule->start);
>  
> +/* if it is a gzip'ed image, 32bit or 64bit, uncompress it */
> +rc = kernel_decompress(info, , );
> +if (rc < 0 && rc != -EINVAL)
> +return rc;
> +else if (!rc)
> +{
> +/* Free the original kernel, update the pointers to the
> + * decompressed kernel */

Ditto

> +dt_unreserved_regions(mod->start, mod->start + mod->size,
> +  init_domheap_pages, 0);
> +mod->start = start;
> +mod->size = size;
> +}
> +
>  #ifdef CONFIG_ARM_64
>  rc = kernel_zimage64_probe(info, start, size);
>  if (rc < 0)

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [Xen-users] Changing netback tx interrupts affinity on Dom0

[Julien Grall]

On 03/09/15 17:06, Jintack Lim wrote:
> Hi,

Hi Jintack,

> On Thu, Sep 3, 2015 at 11:34 AM, Ian Campbell  > wrote:
> 
> On Thu, 2015-09-03 at 10:59 -0400, Jintack Lim wrote:
> > Hi,
> >
> > While I was running Apache server,
> > I found that one of Dom0 vcpu is running 100% to handle irqs,
> > and those irqs are set to be processed only on that specific vcpu.
> >
> > Referring to this document,
> > http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide
> > I tried to change smp_affinity by writing a value to /proc/irq/ > -no>/smp_affinity,
> > however the smp_affinity value was not changed.
> >
> > I'm working on Xen 4.5 on ARMv8,
> > and the irq is netback tx interrupt.
> >
> > # cat /proc/irq/106/smp_affinity
> > 1
> >
> > # cat /proc/interrupts
> > ...
> > 106:  53849  0  0  0   xen-dyn-event
> > vif1.1-q0-tx
> > 107:  1  0  0  0   xen-dyn-event
> > vif1.1-q0-rx
> > 108:  61460  0  0  0   xen-dyn-event
> > vif1.1-q1-tx
> > 109:  1  0  0  0   xen-dyn-event
> > vif1.1-q1-rx
> > 110:  67118  0  0  0   xen-dyn-event
> > vif1.1-q2-tx
> > 111:  1  0  0  0   xen-dyn-event
> > vif1.1-q2-rx
> > 112:  58273  0  0  0   xen-dyn-event
> > vif1.1-q3-tx
> > 113:  1  0  0  0   xen-dyn-event
> > vif1.1-q3-rx
> > ...
> >
> > What would be the way to change smp_affinity?

All those interrupts are in-fine event channels. This is a bug in Linux
which I sent a fix a month ago and it's queued in xentip for Linux 4.3 [1]

The event channel rebinding was not working because we don't have vector
callback on ARM and therefore the driver was only allowing event channel
to be routed on VCPU0.

commit 4a5b69464e51f4a8dd432e8c2a1468630df1a53c
Author: Julien Grall 
Date:   Tue Jul 28 10:10:42 2015 +0100

xen/events: Support event channel rebind on ARM
Currently, the event channel rebind code is gated with the presence of
the vector callback.

The virtual interrupt controller on ARM has the concept of per-CPU
interrupt (PPI) which allow us to support per-VCPU event
channel.Therefore there is no need of vector callback for ARM.

Xen is already using a free PPI to notify the guest VCPU of an event.
Furthermore, the xen code initialization in Linux (see
arch/arm/xen/enlighten.c) is requesting correctly a per-CPU IRQ.

Introduce new helper xen_support_evtchn_rebind to allow architecture
decide whether rebind an event is support or not. It will always return
true on ARM and keep the same behavior on x86.

This is also allow us to drop the usage of xen_have_vector_callback
entirely in the ARM code.

Signed-off-by: Julien Grall 
Signed-off-by: David Vrabel 

Regards,

[1] https://lkml.org/lkml/2015/7/28/205

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH for 4.6] tools/xen-access: use PRI_xen_pfn

[Tamas K Lengyel]

On Thu, Sep 3, 2015 at 12:27 PM, Wei Liu  wrote:

> Otherwise when building with 32bit compiler, we get:
>
> xen-access.c: In function 'xenaccess_init':
> xen-access.c:263:5: error: format '%llx' expects argument of type 'long
> long unsigned int', but argument 3 has type 'xen_pfn_t' [-Werror=format]
> cc1: all warnings being treated as errors
>
> Signed-off-by: Wei Liu 
>

Acked-by: Tamas K Lengyel 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.18 test] 61292: regressions - FAIL

[osstest service owner]

flight 61292 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61292/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 58581

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 61244
 test-amd64-i386-xl-qemut-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
pass in 61244
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat 
fail pass in 61244
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat 
fail pass in 61244

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 58581
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
baseline untested
 test-armhf-armhf-xl-rtds 11 guest-start fail baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail baseline untested
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 61244 baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 61244 baseline untested
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   like 58581
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 58581
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 58581
 test-armhf-armhf-xl   6 xen-boot fail   like 58581
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 58581
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 58581
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 58581
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 58581

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxe9fd6ddcabf8695329f2462d3ece5a8442f2a8cf
baseline version:
 linuxd048c068d00da7d4cfa5ea7651933b99026958cf

Last test of basis58581  2015-06-15 09:42:22 Z   80 days
Failing since 58976  2015-06-29 19:43:23 Z   65 days   54 attempts
Testing same since60642  2015-08-09 13:18:01 Z   25 days   13 attempts


383 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   

Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - PUSHED

[Ian Campbell]

On Thu, 2015-09-03 at 11:49 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [osstest test] 60719: tolerable 
> FAIL - PUSHED"):
> ...
> > I suspect this is down to:
> > 
> > root@lace-bug:/etc/libvirt# cat /etc/hosts
> > 127.0.0.1   localhost
> > 127.0.1.1   lace-bug.xs.citrite.net
> >  lace-bug
> 
> This is simply wrong.  It means that when programs on the host try to
> find the host's own IP address starting with its host name, they get
> different (and wrong) answers to programs on other hosts.
> 
> I can see why D-I wants to do this but in our setup it is simply
> entirely wrong.  Is there a way to suppress this (from preseed
> maybe) ?

The responsible component in d-i is netcfg and when it has been told (e.g.
via preseed) to use dhcp it will do as above, with no option to do
otherwise (it _might_ be possible to omit FQDN by not giving the domains
name in preseed, I can't quite figure that out without trying).

If instead preseed is changed to use a static address then it will write
the given static address instead.

So we could change osstest to use static addresses at preseed time,
although that would be problematic if the host was actually dynamic. Also
it seems like we explicitly stopped doing this in:
commit 28bc2c8875c30209c2f189ba4d87fc401bb78cf6
Author: Ian Jackson 
Date:   Thu Aug 18 01:23:40 2011 +0100

OsstestDebian: use dhcp for installation again (avoids reference to 
NetNetmask and NetGateway)

We could rewrite /etc/hosts in ts-xen-install (around the time we frob
/etc/network/interfaces) to remove the 127.0.1.1 altogether, meaning that
lookups of a hosts own FQDN would be resolved by DNS instead. THis would be
OK even if we stop switching /e/n/i from DHCP to static too.

Ian.

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

Re: [Xen-devel] [libvirt] [PATCH] libxl: report correct errno from virNetSocketNewConnectTCP on migration

[Jim Fehlig]

On 09/03/2015 06:58 AM, Michal Privoznik wrote:

On 03.09.2015 12:14, Ian Campbell wrote:

saved_errno is never written to in this function after it is
initialised and it is only used to log the failure from
virNetSocketNewConnectTCP masking the real errno from that function.

Drop saved_errno and use errno itself.

Signed-off-by: Ian Campbell 
---
  src/libxl/libxl_migration.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 39e4a65..e291d71 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -480,7 +480,6 @@ libxlDomainMigrationPerform(libxlDriverPrivatePtr driver,
  virURIPtr uri = NULL;
  virNetSocketPtr sock;
  int sockfd = -1;
-int saved_errno = EINVAL;
  int ret = -1;
  
  /* parse dst host:port from uri */

@@ -496,7 +495,7 @@ libxlDomainMigrationPerform(libxlDriverPrivatePtr driver,
  if (virNetSocketNewConnectTCP(hostname, portstr,
AF_UNSPEC,
) < 0) {
-virReportSystemError(saved_errno,
+virReportSystemError(errno,
   _("unable to connect to '%s:%s'"),
   hostname, portstr);
  goto cleanup;


In fact, virNetSocketNewConnectTCP itself returns meaningful message on
error. I think this overwriting should be dropped completely.


Agreed. How about the following patch?

Regards,
Jim

>From a30c493bd9e20c9a7a423789a202c444a5eba344 Mon Sep 17 00:00:00 2001
From: Jim Fehlig 
Date: Thu, 3 Sep 2015 10:14:20 -0600
Subject: [PATCH] libxl: don't overwrite error from virNetSocketNewConnectTCP()

Remove redundant error reporting libxlDomainMigrationPerform().
virNetSocketNewConnectTCP() is perfectly capable of reporting
sensible errors.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_migration.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 9609e06..de2de91 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -487,12 +487,8 @@ libxlDomainMigrationPerform(libxlDriverPrivatePtr driver,
 /* socket connect to dst host:port */
 if (virNetSocketNewConnectTCP(hostname, portstr,
   AF_UNSPEC,
-  ) < 0) {
-virReportSystemError(saved_errno,
- _("unable to connect to '%s:%s'"),
- hostname, portstr);
+  ) < 0)
 goto cleanup;
-}
 
 if (virNetSocketSetBlocking(sock, true) < 0) {
 virObjectUnref(sock);
-- 
2.5.0

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

Re: [Xen-devel] [PATCH v6 06/31] xen/arm: ITS: Port ITS driver to Xen

[Julien Grall]

On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> +struct its_device {
> +/* Physical ITS */
> +struct its_node *its;
> +/* Device ITT address */
> +paddr_t *itt_addr;

Just spotted this, why do you have a pointer to paddr_t?

You store a pointer to the base virtual address and not the physical
address of the ITT. So the name is also wrong.

I would keep what Linux does, i.e:

void   *itt;

> +/* Device ITT size */
> +unsigned long   itt_size;
> +/* LPI and event mapping */
> +struct event_lpi_mapevent_map;
> +/* Physical Device id */
> +u32 device_id;
> +};

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v6 17/31] xen/arm: ITS: Store LPIs allocated and IRQ ID bits per domain

[Julien Grall]

Hi Vijay,

On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Store number of lpis and number of id bits
> in vgic structure
> 
> Signed-off-by: Vijaya Kumar K 
> ---
>  xen/arch/arm/irq.c   |9 +
>  xen/arch/arm/vgic-v3-its.c   |2 ++
>  xen/arch/arm/vgic.c  |   12 
>  xen/include/asm-arm/domain.h |3 +++
>  xen/include/asm-arm/irq.h|3 +++
>  5 files changed, 29 insertions(+)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 24c4f24..93e9411 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -31,6 +31,15 @@
>  static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>  static DEFINE_SPINLOCK(local_irqs_type_lock);
>  
> +/* Number of LPI supported in XEN */
> +/*

Number of LPI supported by Xen.

Also, it's not necessary to have a separate comment for this. It could
be included in the next one. I.e:

/*
 * Number of LPI supported by Xen
 *
 * LPI 

> + * LPI number start from 8192. Minimum number of bits
> + * required to represent 8192 is 13 bits. So to Support LPIs minimum 
> + * 14 bits are required which can represent maximum LPI 16384.
> + * 16384 - 8192 = 8192. Minimum number of LPIs supported is 8192
> + */

The explanation is hard to understand. I would rewrite like:

"The LPI identifier starts from 8192. Given that the hardware is
providing the number of identifier bits, supporting LPIs requires at
least 14 bits. This will represent 16384 interrupt ID of which 8192
LPIs. So the minimum of LPIs supported when the hardware supports LPIs
is 8192 ".

> +unsigned int nr_lpis = 8192;
> +

I still don't think that it makes sense to introduce the number of LPIs
variable in a patch for vITS. As you describe it, it should be part of
an ITS/GICv3 patch.

Although, I think you should use the field nr_irq_ids in the gic
structure (see patch #10) to avoid problem you currently have with this
solution.

For instance, gic_is_lpi is relying on the number of ID bits exposed by
the hardware but you allocate the IRQ desc for LPIs based on nr_lpis.

It's fine to restrict the value in the GIC compare to hardware.

Furthermore this value should be 0 on platform where LPIs is not
supported in order to make confusion and introduce possible problem with
the code later. I could add that, AFAICT, this new variable (nr_lpis) is
not that often within the code.

Lastly, on a previous version (don't remember which one) we said that
the user should be able to change the value on the command line. What's
your plan for that?

>  /* Describe an IRQ assigned to a guest */
>  struct irq_guest
>  {
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index fabbad0..cef6139 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -547,6 +547,8 @@ int vits_domain_init(struct domain *d)
>  
>  ASSERT(is_hardware_domain(d));
>  
> +d->arch.vgic.nr_lpis = nr_lpis;
> +

With  my suggestion, this would turn into gic_nr_irq_ids() - 8192;

>  d->arch.vgic.vits = xzalloc(struct vgic_its);
>  if ( !d->arch.vgic.vits )
>  return -ENOMEM;
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index e28c30d..6b6bbce 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -72,8 +72,10 @@ int domain_vgic_init(struct domain *d, unsigned int 
> nr_spis)
>  {
>  int i;
>  int ret;
> +unsigned int irq_lines;

This will be used as the number of IRQ identifiers which is different as
the number of lines. So please rename into irq_ids.

>  
>  d->arch.vgic.ctlr = 0;
> +d->arch.vgic.nr_lpis = 0;
>  
>  /* Limit the number of virtual SPIs supported to (1020 - 32) = 988  */
>  if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
> @@ -130,6 +132,16 @@ int domain_vgic_init(struct domain *d, unsigned int 
> nr_spis)
>  for ( i = 0; i < NR_GIC_SGI; i++ )
>  set_bit(i, d->arch.vgic.allocated_irqs);
>  
> +irq_lines = d->arch.vgic.nr_spis + 32;
> +/*
> + * If LPIs are supported, then just overwrite nr_spis
> + * in computing id_bits.
> + */
> +if ( d->arch.vgic.nr_lpis != 0 )
> +   irq_lines = d->arch.vgic.nr_lpis + FIRST_GIC_LPI;
> +

This would be more logic to do:

if ( !d->arch.vgic.nr_lpis )
irq_ids = d->arch.vgic.nr_spis + 32;
else
irq_ids = d->arch.vgic.nr_lpis + FIRST_GIC_LPI;

You could also use "min()" if you want to avoid the if/else.

> +d->arch.vgic.id_bits = get_count_order(irq_lines);
> +
>  return 0;
>  }
>  
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 986a4d6..269e4bb 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -93,6 +93,9 @@ struct arch_domain
>  spinlock_t lock;
>  int ctlr;
>  int nr_spis; /* Number of SPIs */
> +int nr_lpis; /* Number of LPIs */
> +/* Number of bits required to represent 

[Xen-devel] [PATCH v4 2/2] xen/arm: support gzip compressed kernels

[Stefano Stabellini]

Free the memory used for the compressed kernel and update the relative
mod->start and mod->size parameters with the uncompressed ones.

Signed-off-by: Stefano Stabellini 
CC: julien.gr...@citrix.com
CC: ian.campb...@citrix.com

---
Changes in v4:
- return uint32_t from output_length
- __init kernel_decompress
- code style
- add comment
- if kernel_decompress fails with error, return

Changes in v3:
- better error checks in kernel_decompress
- free unneeded pages between output_size and kernel_order_out
- alloc pages from domheap

Changes in v2:
- use gzip_check
- avoid useless casts
- free original kernel image and update the mod with the new address and
size
- remove changes to common Makefile
- remove CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
---
 xen/arch/arm/kernel.c   |   71 +++
 xen/arch/arm/setup.c|2 +-
 xen/include/asm-arm/setup.h |2 ++
 3 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index f641b12..1e8c569 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "kernel.h"
 
@@ -257,6 +259,61 @@ static int kernel_uimage_probe(struct kernel_info *info,
 return 0;
 }
 
+static __init uint32_t output_length(char *image, unsigned long image_len)
+{
+return *(uint32_t *)[image_len - 4];
+}
+
+static __init int kernel_decompress(struct kernel_info *info,
+ paddr_t *addr, paddr_t *size)
+{
+char *output, *input, *end;
+char magic[2];
+int rc;
+unsigned kernel_order_out;
+paddr_t output_size;
+struct page_info *pages;
+
+if ( *size < 2 )
+return -EINVAL;
+
+copy_from_paddr(magic, *addr, sizeof(magic));
+
+/* only gzip is supported */
+if ( !gzip_check(magic, *size) )
+return -EINVAL;
+
+input = ioremap_cache(*addr, *size);
+if ( input == NULL )
+return -EFAULT;
+
+output_size = output_length(input, *size);
+kernel_order_out = get_order_from_bytes(output_size);
+pages = alloc_domheap_pages(NULL, kernel_order_out, 0);
+if ( pages == NULL )
+{
+iounmap(input);
+return -ENOMEM;
+}
+output = page_to_virt(pages);
+
+rc = perform_gunzip(output, input, *size);
+clean_dcache_va_range(output, output_size);
+iounmap(input);
+
+*addr = virt_to_maddr(output);
+*size = output_size;
+
+end = output + (1 << (kernel_order_out + PAGE_SHIFT));
+/* Need to free pages after output_size here because they won't be
+ * freed by discard_initial_modules */
+output += (output_size + PAGE_SIZE - 1) & PAGE_MASK;
+for ( ; output < end; output += PAGE_SIZE )
+free_domheap_page(virt_to_page(output));
+
+return 0;
+}
+
 #ifdef CONFIG_ARM_64
 /*
  * Check if the image is a 64-bit Image.
@@ -463,6 +520,20 @@ int kernel_probe(struct kernel_info *info)
 printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
info->initrd_bootmodule->start);
 
+/* if it is a gzip'ed image, 32bit or 64bit, uncompress it */
+rc = kernel_decompress(info, , );
+if (rc < 0 && rc != -EINVAL)
+return rc;
+else if (!rc)
+{
+/* Free the original kernel, update the pointers to the
+ * decompressed kernel */
+dt_unreserved_regions(mod->start, mod->start + mod->size,
+  init_domheap_pages, 0);
+mod->start = start;
+mod->size = size;
+}
+
 #ifdef CONFIG_ARM_64
 rc = kernel_zimage64_probe(info, start, size);
 if (rc < 0)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6626eba..109c71c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -165,7 +165,7 @@ static void __init processor_id(void)
 processor_setup();
 }
 
-static void dt_unreserved_regions(paddr_t s, paddr_t e,
+void dt_unreserved_regions(paddr_t s, paddr_t e,
   void (*cb)(paddr_t, paddr_t), int first)
 {
 int i, nr = fdt_num_mem_rsv(device_tree_flattened);
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 81bb3da..30ac53b 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -54,6 +54,8 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long 
len);
 int construct_dom0(struct domain *d);
 
 void discard_initial_modules(void);
+void dt_unreserved_regions(paddr_t s, paddr_t e,
+   void (*cb)(paddr_t, paddr_t), int first);
 
 size_t __init boot_fdt_info(const void *fdt, paddr_t paddr);
 const char __init *boot_fdt_cmdline(const void *fdt);
-- 
1.7.10.4


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

Re: [Xen-devel] [OSSTEST PATCH 1/2] cr-daily-branch: Break out blessings_arg variable

[Ian Campbell]

On Thu, 2015-09-03 at 11:45 +0100, Ian Jackson wrote:
> And rewrap check_tested.
> 
> No functional change.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

> ---
>  cr-daily-branch |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/cr-daily-branch b/cr-daily-branch
> index 7402d3f..e90919d 100755
> --- a/cr-daily-branch
> +++ b/cr-daily-branch
> @@ -75,14 +75,14 @@ case $branch in
>   treeurl=`./ap-print-url $branch`;;
>  esac
>  
> +blessings_arg=--blessings=${DAILY_BRANCH_TESTED_BLESSING:
> -$OSSTEST_BLESSING}
> +
>  force_baseline=false
>  skipidentical=true
>  wantpush=$OSSTEST_PUSH
>  
>  check_tested () {
> - ./sg-check-tested --debug --branch=$branch \
> -   --blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING} 
> \
> -   "$@"
> + ./sg-check-tested --debug --branch=$branch $blessings_arg "$@"
>  }
>  
>  if [ "x$OLD_REVISION" = x ]; then

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

Re: [Xen-devel] [PATCH v6 19/31] xen/arm: ITS: Export ITS info to Virtual ITS

[Julien Grall]

On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Export physical ITS information to virtual ITS driver
> 
> Signed-off-by: Vijaya Kumar K 
> ---
> v6: - Passed only one physical ITS info
> - Passed all the values as parameters
> - Initialize vITS only if physical ITS is available
> ---
>  xen/arch/arm/gic-v3-its.c |   11 +++
>  xen/arch/arm/vgic-v3-its.c|   28 
>  xen/include/asm-arm/gic-its.h |7 +++
>  3 files changed, 46 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 0865a93..77abbc6 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c

[...]

> @@ -1402,6 +1405,7 @@ int its_cpu_init(void)
>  
>  int __init its_init(struct rdist_prop *rdists)
>  {
> +struct its_node *its;
>  struct dt_device_node *np = NULL;
>  
>  static const struct dt_device_match its_device_ids[] __initconst =
> @@ -1424,6 +1428,13 @@ int __init its_init(struct rdist_prop *rdists)
>  its_alloc_lpi_tables();
>  its_lpi_init(rdists->id_bits);
>  
> +its = list_first_entry(_nodes, struct its_node, entry);
> +if ( !its )
> +return -ENOMEM;

This check is not necessary, you already check is the its_nodes list is
not empty.

> +
> +vits_setup_hw(its_data.dev_bits, its_data.eventid_bits,
> +  its->phys_base, its->phys_size);

It would have been nice to have a comment explaining that we always
expose a single ITS to DOM0.

> +
>  return 0;
>  }
>  
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index cef6139..53f2a27 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -68,6 +68,26 @@ static inline uint16_t vits_get_max_collections(struct 
> domain *d)
>  return (d->max_vcpus + 1);
>  }
>  
> +static struct {
> +bool_t enabled;
> +uint32_t dev_bits;
> +uint32_t eventid_bits;


Please have consistent name. I.e

eventID_bits
devID_bits

Also, those fields can be stored each on uint8_t (both are only 4 bits).

> +/* GITS physical base */
> +paddr_t phys_base;
> +/* GITS physical size */
> +unsigned long phys_size;
> +} vits_hw;
> +
> +void vits_setup_hw(uint32_t dev_bits, uint32_t eventid_bits,
> +   paddr_t phys_base, unsigned long phys_size)
> +{
> +vits_hw.enabled = 1;
> +vits_hw.dev_bits = dev_bits;
> +vits_hw.eventid_bits = eventid_bits;
> +vits_hw.phys_base = phys_base;
> +vits_hw.phys_size = phys_size;
> +}
> +
>  int vits_access_guest_table(struct domain *d, paddr_t entry, void *addr,
>  uint32_t size, bool_t set)
>  {
> @@ -547,6 +567,14 @@ int vits_domain_init(struct domain *d)
>  
>  ASSERT(is_hardware_domain(d));
>  
> +if ( !vits_hw.enabled )

An ASSERT would have been enough given that this should never be called
when LPIs is not supported and ITS not enabled (see caller).

> +{
> +printk(XENLOG_G_ERR
> +   "%"PRIu16": VITS is not supported on this platform.\n",

s/PRIu16/u/ to be consistent with the rest of Xen.

> +   d->domain_id);
> +return -ENODEV;
> +}
> +
>  d->arch.vgic.nr_lpis = nr_lpis;
>  
>  d->arch.vgic.vits = xzalloc(struct vgic_its);
> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
> index 4327ba2..7077477 100644
> --- a/xen/include/asm-arm/gic-its.h
> +++ b/xen/include/asm-arm/gic-its.h
> @@ -320,6 +320,11 @@ struct vitt {
>  uint32_t vlpi;
>  };
>  
> +struct gic_its_info {
> +uint32_t eventid_bits;
> +uint32_t dev_bits;

See my remark on the vits_hw.

> +};
> +

This is only used internally to gic-v3-its.c. So you could have directly
done

static struct
{
uint32_t eventid_bits;
uint32_t dev_bits;
} its_data;

>  void irqdesc_set_lpi_event(struct irq_desc *desc, unsigned id);
>  unsigned int irqdesc_get_lpi_event(struct irq_desc *desc);
>  struct its_device *irqdesc_get_its_device(struct irq_desc *desc);
> @@ -337,6 +342,8 @@ int vits_get_vitt_entry(struct domain *d, uint32_t devid,
>  uint32_t event, struct vitt *entry);
>  int vits_get_vdevice_entry(struct domain *d, uint32_t devid,
> struct vdevice_table *entry);
> +void vits_setup_hw(uint32_t dev_bits, uint32_t eventid_bits,
> +   paddr_t base, unsigned long size);
>  
>  #endif /* __ASM_ARM_GIC_ITS_H__ */
>  /*
> 

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v6 00/31] Add ITS support

[Julien Grall]

Hi Vijay,

On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> This is based on DraftG version
> http://xenbits.xen.org/people/ianc/vits/draftG.pdf
> 
> Following major features are supported
>  - GICv3 ITS support for arm64 platform
>  - Only Dom0 is supported. For DomU pci passthrough feature
>is required.
> 
> Patches shared @ https://github.com/vijaykilari/its_v6.git

Thank you for the repo.

FYI, you could have re-used the git repo you've used for v2 and create a
new branch called its-v6 ;). It's easier than creating a new repo for
every version.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [libvirt] [PATCH] libxl: report correct errno from virNetSocketNewConnectTCP on migration

[Ian Campbell]

On Thu, 2015-09-03 at 10:26 -0600, Jim Fehlig wrote:
> From a30c493bd9e20c9a7a423789a202c444a5eba344 Mon Sep 17 00:00:00 2001
> From: Jim Fehlig 
> Date: Thu, 3 Sep 2015 10:14:20 -0600
> Subject: [PATCH] libxl: don't overwrite error from 
> virNetSocketNewConnectTCP()
> 
> Remove redundant error reporting libxlDomainMigrationPerform().
> virNetSocketNewConnectTCP() is perfectly capable of reporting
> sensible errors.
> 
> Signed-off-by: Jim Fehlig 

FWIW: Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH v6 09/31] xen/arm: ITS: Add APIs to add and assign device

[Julien Grall]

Hi Vijay,

On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Add APIs to add devices to RB-tree, assign and remove
> devices to domain.
> 
> Signed-off-by: Vijaya Kumar K 
> ---
> v6: - Moved this patch #19 to patch #8
> - Used col_map to store collection id
> - Use helper functions to update msi_desc members
> v5: - Removed its_detach_device API
> - Pass nr_ites as parameter to its_add_device
> v4: - Introduced helper to populate its_device struct
> - Fixed freeing of its_device memory
> - its_device struct holds domain id
> ---
>  xen/arch/arm/gic-v3-its.c |  212 
> +
>  xen/include/asm-arm/gic-its.h |6 ++
>  2 files changed, 218 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index e70c21a..f14c0f4 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -145,6 +145,19 @@ static struct its_collection *dev_event_to_col(struct 
> its_device *dev,
>  return its->collections + dev->event_map.col_map[event];
>  }
>  
> +static struct its_node *its_get_phys_node(struct dt_device_node *dt)
> +{
> +struct its_node *its;
> +
> +list_for_each_entry(its, _nodes, entry)
> +{
> +if ( its->dt_node == dt )
> +return its;
> +}
> +
> +return NULL;
> +}
> +
>  /* RB-tree helpers for its_device */
>  static struct its_device *its_find_device(u32 devid)
>  {
> @@ -522,6 +535,205 @@ static void its_lpi_free(struct its_device *dev)
>  xfree(dev->event_map.lpi_map);
>  }
>  
> +static void its_discard_lpis(struct its_device *dev, u32 ids)
> +{
> +int i;
> +

I would have expected a function more complex than that. If you discard
the LPIs, you also need to free the MSI desc and potentially reset the
IRQ desc.

Otherwise you will left the irq_desc in an unknown state for the next one.

> +for ( i = 0; i < ids; i++)
> +   its_send_discard(dev, i);
> +}
> +
> +static inline u32 its_get_plpi(struct its_device *dev, u32 event)
> +{
> +return dev->event_map.lpi_base + event;
> +}
> +
> +static int its_alloc_device_irq(struct its_device *dev, u32 *hwirq)
> +{
> +int idx;
> +
> +idx = find_first_zero_bit(dev->event_map.lpi_map, 
> dev->event_map.nr_lpis);
> +if ( idx == dev->event_map.nr_lpis )
> +return -ENOSPC;
> +
> +*hwirq = its_get_plpi(dev, idx);
> +set_bit(idx, dev->event_map.lpi_map);
> +
> +return 0;
> +}
> +
> +static void its_free_device(struct its_device *dev)
> +{
> +xfree(dev->itt_addr);
> +xfree(dev->event_map.lpi_map);

This should be replaced by its_lpi_free. Otherwise you will never
release the reserved LPI ranges in lpi_bitmap.

> +xfree(dev->event_map.col_map);
> +xfree(dev);
> +}
> +
> +static struct its_device *its_alloc_device(u32 devid, u32 nr_ites,
> +   struct dt_device_node *dt_its)
> +{
> +struct its_device *dev;
> +paddr_t *itt;

Why paddr_t? You only allocate it and pass directly to the hardware.

> +unsigned long *lpi_map;
> +int lpi_base, sz;
> +u16 *col_map = NULL;
> +
> +dev = xzalloc(struct its_device);
> +if ( dev == NULL )
> +return NULL;
> +
> +dev->its = its_get_phys_node(dt_its);
> +if (dev->its == NULL)
> +{
> +dprintk(XENLOG_G_ERR,

Why XENLOG_G_ERR?

Also, dprintk will be turned into a no-op on non-debug build. Is it what
you expect?

> +"ITS: Failed to find ITS node for devid 0x%"PRIx32"\n",
> +devid);
> +goto err;
> +}
> +
> +sz = nr_ites * dev->its->ite_size;
> +sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
> +itt = xzalloc_bytes(sz);
> +if ( !itt )
> +goto err;
> +
> +lpi_map = its_lpi_alloc_chunks(nr_ites, _base);
> +if ( !lpi_map )
> +goto lpi_err;
> +
> +col_map = xzalloc_bytes(sizeof(*col_map) * nr_ites);
> +if ( !col_map )
> +goto col_err;
> +dev->itt_addr = itt;
> +dev->event_map.lpi_map = lpi_map;
> +dev->event_map.lpi_base = lpi_base;
> +dev->event_map.col_map = col_map;
> +dev->event_map.nr_lpis = nr_ites;
> +dev->device_id = devid;
> +
> +return dev;
> +
> +col_err:
> +xfree(lpi_map);

This should be replaced by its_lpi_free. Otherwise you will never
release the reserved LPI ranges in lpi_bitmap.

> +lpi_err:
> +xfree(itt);
> +err:
> +xfree(dev);

By reworking a bit this function, you could directly its_free_device.

For instance if you assign lpi_map directly after allocating,...

> +return NULL;
> +}
> +
> +/* Device assignment */
> +int its_add_device(u32 devid, u32 nr_ites, struct dt_device_node *dt_its)
> +{
> +struct its_device *dev;
> +u32 i, plpi = 0;
> +struct its_collection *col;
> +struct irq_desc *desc;
> +struct msi_desc *msi = NULL;
> +int res = 0;
> +
> +

Re: [Xen-devel] [Xen-users] Changing netback tx interrupts affinity on Dom0

[Jintack Lim]

Hi,

I was trying to set irq affinity by writing a value
to /proc/irq//smp_affinity,
but smp_affinity value was not changed at all.
Ian suggested to take this to the devel list.
I'm working on Xen4.5, ARMv8.

Thanks,
Jintack

On Thu, Sep 3, 2015 at 11:34 AM, Ian Campbell 
wrote:

> On Thu, 2015-09-03 at 10:59 -0400, Jintack Lim wrote:
> > Hi,
> >
> > While I was running Apache server,
> > I found that one of Dom0 vcpu is running 100% to handle irqs,
> > and those irqs are set to be processed only on that specific vcpu.
> >
> > Referring to this document,
> > http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide
> > I tried to change smp_affinity by writing a value to /proc/irq/ > -no>/smp_affinity,
> > however the smp_affinity value was not changed.
> >
> > I'm working on Xen 4.5 on ARMv8,
> > and the irq is netback tx interrupt.
> >
> > # cat /proc/irq/106/smp_affinity
> > 1
> >
> > # cat /proc/interrupts
> > ...
> > 106:  53849  0  0  0   xen-dyn-event
> > vif1.1-q0-tx
> > 107:  1  0  0  0   xen-dyn-event
> > vif1.1-q0-rx
> > 108:  61460  0  0  0   xen-dyn-event
> > vif1.1-q1-tx
> > 109:  1  0  0  0   xen-dyn-event
> > vif1.1-q1-rx
> > 110:  67118  0  0  0   xen-dyn-event
> > vif1.1-q2-tx
> > 111:  1  0  0  0   xen-dyn-event
> > vif1.1-q2-rx
> > 112:  58273  0  0  0   xen-dyn-event
> > vif1.1-q3-tx
> > 113:  1  0  0  0   xen-dyn-event
> > vif1.1-q3-rx
> > ...
> >
> > What would be the way to change smp_affinity?
>
> It should be via /proc/irq//smp_affinity as you've tried, I asked
> Stefano and he things this was already implemented in 4.5 even. That it is
> not happening would be a bug, I think.
>
> I'd suggest you take this to the devel list as a bug.
>
> > and where is the affinity set initially for netback tx interrupts?
>
> Not, sure, I think it might just be generic IRQ code.
>
> Ian.
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - PUSHED

[Jim Fehlig]

On 09/03/2015 05:37 AM, Ian Campbell wrote:

On Thu, 2015-09-03 at 11:26 +0100, Ian Campbell wrote:

Notice that it has bound to 127.0.1.1 and not to 10.80.228.77!

So while I investigate how to make d-i not create these entries I also
removed the line from /etc/hosts such that looking up the FQDN gives the
non-local IP. But:


 root@moss-bug:/var/log# strace -o /tmp/virsh -fff virsh --debug 0 migrate 
--live debian.guest.osstest xen+ssh://10.80.228.77
 migrate: live(bool): (none)
 migrate: domain(optdata): debian.guest.osstest
 migrate: desturi(optdata): xen+ssh://10.80.228.77
 migrate: found option : debian.guest.osstest
 migrate:  trying as domain NAME
 migrate: found option : debian.guest.osstest
 migrate:  trying as domain NAME
 error: internal error: Failed to send migration data to destination host

The senders libxl-driver.log says:

2015-09-03 12:29:45 BST libxl-save-helper: debug: starting save: Success
2015-09-03 12:29:45 BST xc: detail: fd 27, dom 3, max_iters 0, max_factor 0, 
flags 1, hvm 0
2015-09-03 12:29:45 BST xc: info: Saving domain 3, type x86 PV
2015-09-03 12:29:45 BST xc: detail: 64 bits, 4 levels
2015-09-03 12:29:45 BST xc: detail: max_pfn 0x1, p2m_frames 256
2015-09-03 12:29:45 BST xc: detail: max_mfn 0x12
2015-09-03 12:29:46 BST xc: error: Failed to write page data to stream (104 = 
Connection reset by peer): Internal error
2015-09-03 12:29:46 BST xc: error: Save failed (104 = Connection reset by 
peer): Internal error
2015-09-03 12:29:46 BST libxl-save-helper: debug: complete r=-1: Connection 
reset by peer
2015-09-03 12:29:46 BST libxl: error: 
libxl_stream_write.c:329:libxl__xc_domain_save_done: saving domain: domain did 
not respond to suspend request: Connection reset by peer
2015-09-03 12:29:46 BST libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 
0x7f67b3f63e90: complete, rc=-8
2015-09-03 12:29:46 BST libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 
0x7f67b3f63e90: destroy
2015-09-03 12:29:46 BST libxl: debug: libxl.c:526:libxl_domain_resume: ao 
0x7f67b3fa44b0: create: how=(nil) callback=(nil) poller=0x7f67a0002610
2015-09-03 12:29:46 BST xc: error: Dom 3 not suspended: (shutdown 0, reason 
255): Internal error
2015-09-03 12:29:46 BST libxl: error: 
libxl_dom_suspend.c:409:libxl__domain_resume: xc_domain_resume failed for 
domain 3: Invalid argument
2015-09-03 12:29:46 BST libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 
0x7f67b3fa44b0: complete, rc=-3
2015-09-03 12:29:46 BST libxl: debug: libxl.c:529:libxl_domain_resume: ao 
0x7f67b3fa44b0: inprogress: poller=0x7f67a0002610, flags=ic
2015-09-03 12:29:46 BST libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 
0x7f67b3fa44b0: destroy

While the receiver has:

2015-09-03 12:29:45 BST libxl-save-helper: debug: starting restore: Success
2015-09-03 12:29:45 BST xc: detail: fd 31, dom 4, hvm 0, pae 0, superpages 0, 
checkpointed_stream 0
2015-09-03 12:29:45 BST xc: info: Found x86 PV domain from Xen 4.6
2015-09-03 12:29:45 BST xc: info: Restoring domain
2015-09-03 12:29:45 BST xc: detail: 64 bits, 4 levels
2015-09-03 12:29:45 BST xc: detail: max_mfn 0x12
2015-09-03 12:29:45 BST xc: detail: Expanded p2m from 0 to 0x1
2015-09-03 12:29:45 BST xc: error: Failed to read 4202504 bytes of data for 
record (0x0001, Page data) (11 = Resource temporarily unavailabl): Internal 
error
2015-09-03 12:29:45 BST xc: error: Restore failed (11 = Resource temporarily 
unavailabl): Internal error
2015-09-03 12:29:45 BST libxl-save-helper: debug: complete r=-1: Resource 
temporarily unavailable
2015-09-03 12:29:45 BST libxl: error: 
libxl_stream_read.c:749:libxl__xc_domain_restore_done: restoring domain: 
Resource temporarily unavailable
2015-09-03 12:29:45 BST libxl: error: 
libxl_create.c:1141:domcreate_rebuild_done: cannot (re-)build domain: -3
2015-09-03 12:29:46 BST libxl: debug: libxl.c:1708:devices_destroy_cb: forked 
pid 18738 for destroy of domain 4
2015-09-03 12:29:46 BST libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 
0x7fbb7687e900: complete, rc=-3
2015-09-03 12:29:46 BST libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 
0x7fbb7687e900: destroy


"xc: error: Failed to write page data to stream (104 = Connection reset by
peer): Internal error" seems to be the initial failure.


I wonder if this has anything to do with migration V2? I noticed a migration 
regression a few days back, but later realized that the sender was 4.5 and 
receiver was 4.6. I planned to see if migration worked through libvirt between 
two 4.6 hosts, but before doing so I had to re-purpose the machines for another 
task. I think libvirt needs some work to accommodate migration V2...


Regards,
Jim


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

[Xen-devel] [PATCH v4 0/2] support gzipped kernels on arm

[Stefano Stabellini]

Hi all,

this patch series introduces support for gzipped kernels, such as the
standard Image.gz format used by Linux on arm64 by default, in Xen on
arm. Without it, Xen cannot load the default kernel shipped by distros,
such as CentOS 7.


Stefano Stabellini (2):
  xen: move perform_gunzip to common
  xen/arm: support gzip compressed kernels

 xen/arch/arm/kernel.c   |   71 ++
 xen/arch/arm/setup.c|2 +-
 xen/arch/x86/bzimage.c  |  134 +-
 xen/common/Makefile |1 +
 xen/common/gunzip.c |  137 +++
 xen/include/asm-arm/setup.h |2 +
 xen/include/xen/gunzip.h|7 +++
 7 files changed, 220 insertions(+), 134 deletions(-)
 create mode 100644 xen/common/gunzip.c
 create mode 100644 xen/include/xen/gunzip.h

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v6 20/31] xen/arm: ITS: Introduce helper to get number of event IDs

[Julien Grall]

Hi Vijay,

On 31/08/15 12:06, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> gic_nr_event_ids() helper to read number of event IDs that
> ITS hardware supports.

AFAICT, this new helper is only used for an ASSERT which live in
gic-v3-its.c.

If that's right, I would prefer to see directly the use of
its_data.eventid_bits (which lives within the same file) in the function
and drop this patch.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH 15/13] Plan reporting: Provide get-last-plan queuedaemon command

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 15/13] Plan reporting: Provide 
get-last-plan queuedaemon command"):
> On Thu, 2015-09-03 at 12:49 +0100, Ian Jackson wrote:
> > This allows retrieval, by monitoring clients which are not
> > participating in the planning queue, of the finished projection, or
> > the unfinished plan as it was at the time of last restart.
...
> > +   file copy -force data-$w.pl data-$wo-final.pl
> 
> IIRC there was code earlier which did smth like "cp data-plan.pl data
> -projection.pl" during the take over and that if no resources come
> available during a plan walk then no projection walk would happen.

Yes.  After patch 13 we have this:

  proc queuerun-finished/plan {} {
  runneeded-ensure-will 0
  report-plan plan plan
  report-plan plan projection
  }

report-plan X Y generates resource-Y.html from data-Y.pl.

In 15/13 we make it also copy data-Y.pl to data-Y-final.pl.

>  It might be nicer to arrange for data-plan-final.pl to be copied
> to data-projection-final.pl at the same time as data-plan.pl becomes data
> -projection.pl?

So this is already taken care of.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 15/13] Plan reporting: Provide get-last-plan queuedaemon command

[Ian Jackson]

Ian Jackson writes ("Re: [OSSTEST PATCH 15/13] Plan reporting: Provide 
get-last-plan queuedaemon command"):
>   proc queuerun-finished/plan {} {
>   runneeded-ensure-will 0
>   report-plan plan plan
>   report-plan plan projection
>   }
> 
> report-plan X Y generates resource-Y.html from data-Y.pl.
> 
> In 15/13 we make it also copy data-Y.pl to data-Y-final.pl.
^
I mean  data-X.pl

Ian.

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

[Xen-devel] [PATCH RFC v2 4/4] HVM x86 deprivileged mode: Watchdog for DoS prevention

[Ben Catterall]

A watchdog timer is used to prevent the deprivileged mode running for too long,
aimed at handling a bug or attempted DoS. If the watchdog has occurred more than
once whilst we have been in the same deprivileged mode context, then we crash
the domain. This can be adjusted for longer running times in future.

Signed-off-by: Ben Catterall 
---
 xen/arch/x86/hvm/deprivileged.c| 17 +
 xen/arch/x86/nmi.c | 17 +
 xen/include/xen/hvm/deprivileged.h |  1 +
 3 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/deprivileged.c b/xen/arch/x86/hvm/deprivileged.c
index 01efbe1..85701c0 100644
--- a/xen/arch/x86/hvm/deprivileged.c
+++ b/xen/arch/x86/hvm/deprivileged.c
@@ -4,10 +4,11 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -17,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void hvm_deprivileged_init(struct domain *d, l4_pgentry_t *l4t_base)
 {
@@ -219,7 +221,6 @@ int hvm_deprivileged_map_l4(struct domain *d,
  * we preserve the access bits of any supervisor entries that are
  * used in the leaf case.
  */
-
 l3t_base = map_l3t_from_l4e(l4t_base[i]);
 
 hvm_deprivileged_map_l3(d, l3t_base, src_start, dst_start,
@@ -309,7 +310,6 @@ int hvm_deprivileged_map_l3(struct domain *d,
  * we preserve the access bits of any supervisor entries that are
  * used in the leaf case.
  */
-
 l2t_base = map_l2t_from_l3e(l3t_base[i]);
 
 hvm_deprivileged_map_l2(d, l2t_base, src_start, dst_start,
@@ -389,7 +389,6 @@ int hvm_deprivileged_map_l2(struct domain *d,
 {
 panic("HVM: L2 Leaf page is already mapped\n");
 }
-
 /*
  * We can try recursing on this and see if where we want to put our
  * new pages is empty.
@@ -552,6 +551,16 @@ void hvm_deprivileged_user_mode(void)
 
 vcpu->arch.hvm_vcpu.depriv_user_mode = 0;
 vcpu->arch.hvm_vcpu.depriv_rsp = 0;
+vcpu->arch.hvm_vcpu.depriv_watchdog_count = 0;
+
+/*
+ * If we need to crash the domain at this point. We will return up the call
+ * stack, undoing any allocations and then the event testers in the exit
+ * assembly stubs will test for the SOFTIRQ_TIMER event generated by a
+ * domain_crash and will crash the domain for us.
+ */
+if( vcpu->arch.hvm_vcpu.depriv_destroy )
+domain_crash(vcpu->domain);
 }
 
 /*
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 2ab97a0..25817d2 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -463,9 +464,25 @@ int __init watchdog_setup(void)
 /* Returns false if this was not a watchdog NMI, true otherwise */
 bool_t nmi_watchdog_tick(const struct cpu_user_regs *regs)
 {
+struct vcpu *vcpu = current;
 bool_t watchdog_tick = 1;
 unsigned int sum = this_cpu(nmi_timer_ticks);
 
+/*
+ * If the domain has been running in deprivileged mode for two watchdog
+ * ticks, then we kill it to prevent a DoS. We use two ticks as a coarse
+ * measure as this ensures that at least a full watchdog tick duration has
+ * occurred. This means that we do not need to track entry time and do
+ * time calculations.
+ */
+if( is_hvm_deprivileged_vcpu() )
+{
+if( vcpu->arch.hvm_vcpu.depriv_watchdog_count )
+hvm_deprivileged_crash_domain("HVM Deprivileged domain: Domain 
exceeded running time.");
+else
+vcpu->arch.hvm_vcpu.depriv_watchdog_count = 1;
+}
+
 if ( (this_cpu(last_irq_sums) == sum) && watchdog_enabled() )
 {
 /*
diff --git a/xen/include/xen/hvm/deprivileged.h 
b/xen/include/xen/hvm/deprivileged.h
index 9c08adf..9a7f109 100644
--- a/xen/include/xen/hvm/deprivileged.h
+++ b/xen/include/xen/hvm/deprivileged.h
@@ -74,6 +74,7 @@ int hvm_deprivileged_map_l1(struct domain *d,
 unsigned int l1_flags,
 unsigned int op);
 
+
 /* Used to allocate a page for the deprivileged mode */
 struct page_info *hvm_deprivileged_alloc_page(struct domain *d);
 
-- 
2.1.4


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

[Xen-devel] [PATCH RFC v2 1/4] HVM x86 deprivileged mode: Create deprivileged page tables

[Ben Catterall]

The paging structure mappings for the deprivileged mode are added to the monitor
page table for HVM guests for HAP and shadow table paging. The entries are
generated by walking the page tables and mapping in new pages. Access bits are
flipped as needed.

The page entries are generated for deprivileged .text, .data and a stack. The
.text section is only allocated once at HVM domain initialisation and then we
alias it from then onwards. The data section is copied from sections allocated
by the linker. The mappings are setup in an unused portion of the Xen virtual
address space. The pages are mapped in as user mode accessible, with NX bits set
for the data and stack regions and the code region is set to be executable and
read-only.

The needed pages are allocated on the paging heap and are deallocated when
those heap pages are deallocated (on domain destruction).

Signed-off-by: Ben Catterall 

Changes since v1

 * .text section is now aliased when needed
 * Reduced user stack size to two pages
 * Changed allocator used for pages
 * Changed types to using __hvm_$foo[] for linker variables
 * Moved some #define's to page.h
 * Small bug fix: Testing global bit on L3 not relevant
---
 xen/arch/x86/hvm/Makefile  |   1 +
 xen/arch/x86/hvm/deprivileged.c| 514 +
 xen/arch/x86/mm/hap/hap.c  |   8 +
 xen/arch/x86/mm/shadow/multi.c |   8 +
 xen/arch/x86/xen.lds.S |  19 ++
 xen/include/asm-x86/config.h   |  29 ++-
 xen/include/asm-x86/x86_64/page.h  |  15 ++
 xen/include/xen/hvm/deprivileged.h |  90 +++
 xen/include/xen/sched.h|   4 +
 9 files changed, 681 insertions(+), 7 deletions(-)
 create mode 100644 xen/arch/x86/hvm/deprivileged.c
 create mode 100644 xen/include/xen/hvm/deprivileged.h

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 794e793..df5ebb8 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -2,6 +2,7 @@ subdir-y += svm
 subdir-y += vmx
 
 obj-y += asid.o
+obj-y += deprivileged.o
 obj-y += emulate.o
 obj-y += event.o
 obj-y += hpet.o
diff --git a/xen/arch/x86/hvm/deprivileged.c b/xen/arch/x86/hvm/deprivileged.c
new file mode 100644
index 000..f34ed67
--- /dev/null
+++ b/xen/arch/x86/hvm/deprivileged.c
@@ -0,0 +1,514 @@
+/*
+ * HVM deprivileged mode to provide support for running operations in
+ * user mode from Xen
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void hvm_deprivileged_init(struct domain *d, l4_pgentry_t *l4t_base)
+{
+void *p;
+unsigned long size;
+unsigned int l4t_idx_code = l4_table_offset(HVM_DEPRIVILEGED_TEXT_ADDR);
+int ret;
+
+/* If there is already an entry here */
+ASSERT(!l4e_get_intpte(l4t_base[l4t_idx_code]));
+
+/*
+ * We alias the .text segment for deprivileged mode to save memory.
+ * Additionally, to save allocating page tables for each vcpu's 
deprivileged
+ * mode .text segment, we reuse them.
+ *
+ * If we have not already created a mapping (valid_l4e_code is false) then
+ * we create one and generate the page tables. To save doing this for each
+ * vcpu, if we already have a set of valid page tables then we reuse them.
+ * So, if we have the page tables and there is no entry at the desired PML4
+ * slot, then we can just reuse those page tables.
+ *
+ * The mappings are per-domain as we use the domain's page pool memory
+ * allocator for the new page structure and page frame pages.
+ */
+if( !d->hvm_depriv_valid_l4e_code )
+{
+/*
+ * Build the alias mappings for the .text segment for deprivileged code
+ *
+ * NOTE: If there are other pages here, then this method will map 
around
+ * them. Which means that any future alias will use this mapping. If 
the
+ * HVM depriv section no longer has a unique PML4 entry in the Xen
+ * memory map, this will need to be accounted for.
+ */
+size = (unsigned long)__hvm_deprivileged_text_end -
+   (unsigned long)__hvm_deprivileged_text_start;
+
+ret = hvm_deprivileged_map_l4(d, l4t_base,
+   (unsigned 
long)__hvm_deprivileged_text_start,
+   (unsigned long)HVM_DEPRIVILEGED_TEXT_ADDR,
+   size, 0 /* No write */, HVM_DEPRIV_ALIAS);
+
+if( ret )
+{
+printk(XENLOG_ERR "HVM: Error when initialising depriv .text. 
Code: %d",
+   ret);
+
+domain_crash(d);
+return;
+}
+
+d->hvm_depriv_l4e_code = l4t_base[l4t_idx_code];
+d->hvm_depriv_valid_l4e_code = 1;
+}
+else
+{
+/* Just copy the PML4 entry across */
+l4t_base[l4t_idx_code] = d->hvm_depriv_l4e_code;

[Xen-devel] [PATCH RFC v2 2/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode

[Ben Catterall]

The process to switch into and out of deprivileged mode can be likened to
setjmp/longjmp.

Xen is non-preemptive and taking an interrupt/exception, SYSCALL, SYSENTER,
NMI or any IST will currently clobber the Xen privileged stack. We need this
stack to be preserved so that after executing deprivileged mode, we can
return to our previous privileged execution point. This allows us to unwind the
stack, cleaning up memory allocations.

To enter deprivileged mode, we move the interrupt/exception rsp,
SYSENTER rsp and SYSCALL rsp to point to lower down Xen's privileged stack
to prevent them from clobbering it. The IST NMI and DF handlers used to copy
themselves onto the privileged stack. This is no longer the case, they now
leave themselves on their predefined stacks.

This means that we can continue execution from that point. This is similar
behaviour to a context switch.

To exit deprivileged mode, we restore the original interrupt/exception rsp,
SYSENTER rsp and SYSCALL rsp. We can then continue execution from where we left
off, which will unwind the stack and free up resources. This method means that
we do not need to change any other code paths and its invocation will be
transparent to callers. This should allow the feature to be more easily
deployed to different parts of Xen.

The switch to and from deprivileged mode is performed using sysret and syscall
respectively.

Signed-off-by: Ben Catterall 

Changed since v1

 * Added support for AMD SVM
 * Moved to the new stack approach
 * IST handlers no longer copy themselves
 * Updated context switching code to perform a full context-switch.
   This means that depriv mode will execute with host register states not
   (partial) guest register state. This allows for crashing the domain (later
   patch) whilst in depriv mode, alleviates potential security vulnerabilities
   and is necessaryto work around the AMD TR issue.
 * Moved processor-specific code to processor-specific files.
 * Changed call/jmp pair in deprivileged_asm.S to call/ret pair to not confuse
   processor branch predictors.
---
 xen/arch/x86/domain.c   |  12 +++
 xen/arch/x86/hvm/Makefile   |   1 +
 xen/arch/x86/hvm/deprivileged.c | 103 ++
 xen/arch/x86/hvm/deprivileged_asm.S | 167 
 xen/arch/x86/hvm/svm/svm.c  | 130 +++-
 xen/arch/x86/hvm/vmx/vmx.c  | 118 +
 xen/arch/x86/mm/hap/hap.c   |   2 +-
 xen/arch/x86/x86_64/asm-offsets.c   |   5 ++
 xen/arch/x86/x86_64/entry.S |  38 ++--
 xen/arch/x86/x86_64/traps.c |  13 ++-
 xen/include/asm-x86/current.h   |   2 +
 xen/include/asm-x86/hvm/svm/svm.h   |  13 +++
 xen/include/asm-x86/hvm/vcpu.h  |  15 
 xen/include/asm-x86/hvm/vmx/vmx.h   |   2 +
 xen/include/asm-x86/processor.h |   2 +
 xen/include/asm-x86/system.h|   3 +
 xen/include/xen/hvm/deprivileged.h  |  45 ++
 xen/include/xen/sched.h |  18 +++-
 18 files changed, 674 insertions(+), 15 deletions(-)
 create mode 100644 xen/arch/x86/hvm/deprivileged_asm.S

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 045f6ff..a0e5e70 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 DEFINE_PER_CPU(unsigned long, cr4);
@@ -446,6 +447,12 @@ int vcpu_initialise(struct vcpu *v)
 if ( has_hvm_container_domain(d) )
 {
 rc = hvm_vcpu_initialise(v);
+
+/* Initialise HVM deprivileged mode */
+printk("HVM initialising deprivileged mode ...");
+hvm_deprivileged_prepare_vcpu(v);
+printk("Done.\n");
+
 goto done;
 }
 
@@ -523,7 +530,12 @@ void vcpu_destroy(struct vcpu *v)
 vcpu_destroy_fpu(v);
 
 if ( has_hvm_container_vcpu(v) )
+{
+/* Destroy the deprivileged mode on this vcpu */
+hvm_deprivileged_destroy_vcpu(v);
+
 hvm_vcpu_destroy(v);
+}
 else
 xfree(v->arch.pv_vcpu.trap_ctxt);
 }
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index df5ebb8..e16960a 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -3,6 +3,7 @@ subdir-y += vmx
 
 obj-y += asid.o
 obj-y += deprivileged.o
+obj-y += deprivileged_asm.o
 obj-y += emulate.o
 obj-y += event.o
 obj-y += hpet.o
diff --git a/xen/arch/x86/hvm/deprivileged.c b/xen/arch/x86/hvm/deprivileged.c
index f34ed67..994c19e 100644
--- a/xen/arch/x86/hvm/deprivileged.c
+++ b/xen/arch/x86/hvm/deprivileged.c
@@ -512,3 +512,106 @@ struct page_info *hvm_deprivileged_alloc_page(struct 
domain *d)
 
 return pg;
 }
+
+/* Used to prepare each vcpus data for user mode. Call for each HVM vcpu. */
+int hvm_deprivileged_prepare_vcpu(struct vcpu *vcpu)
+{
+vcpu->arch.hvm_vcpu.depriv_rsp = 0;
+vcpu->arch.hvm_vcpu.depriv_user_mode = 0;
+

[Xen-devel] [PATCH RFC v2 0/4] HVM x86 deprivileged mode operations

[Ben Catterall]

Hi all,

I have made requested changes and reworked the patch series based on the
comments recieved. Thank you to all of the contributors to those discussions!
The next step will be to provide an example of usage of this system which
will follow in another patch.

The main changes from v1 are:
 - No longer copying the privileged Xen stack but instead change the
   interrupt/exception, syscall and sysenter pointers to be below the current
   execution point.
 - AMD SVM support
 - Stop IST copying onto the privileged stack
 - Watchdog timer to kill a long running deprivileged domain
 - Support for crashing a domain whilst performing a deprivileged operation
 - .text section is now aliased
 - Assembly updates
 - Updated deprivileged context switching code to fix bugs
 - Moved processor-specific code to processor-specific files
 - Reduction of user stack sizes
 - Updates to interfaces and an is_hvm_deprivileged_mode() style test
 - Small bug fixes
 - Revised performance tests

Many thanks in advance,
Ben

The aim of this work is to create a proof-of-concept to establish if it is
feasible to move certain Xen operations into a deprivileged context to mitigate
the impact of a bug or compromise in such areas. An example would be x86_emulate
or virtual device emulation which is not done in QEMU for performance reasons.

Performance testing
---
Performance testing indicates that the overhead for this deprivileged mode
depend heavily upon the processor. This overhead is the cost of moving into
deprivileged mode and then fully back out of deprivileged mode. The conclusions
are that the overheads are not negligible and that operations using this
mechanism would benefit from being long running or be high risk components. It
will need to be evaluated on a case-by-case basis.

I performed 10 writes to a single I/O port on an Intel 2.2GHz Xeon
E5-2407 0 processor and an AMD Opteron 2376. This was done from a python script
within the HVM guest using time.time() and running Debian Jessie. Each write was
trapped to cause a vmexit and the time for each write was calculated. The port
operation is bypassed so that no portio is actually performed. Thus, the
differences in the measurements below can be taken as the pure overhead. These
experiments were repeated. Note that only the host and this HVM guest were
running (both Debian Jessie) during the experiments.

Intel Intel 2.2GHz Xeon E5-2407 0 processor:

1.55e-06 seconds was the average time for performing the write without the
 deprivileged code running.

5.75e-06 seconds was the average time for performing the write with the
 deprivileged code running.

So approximately 351% overhead

AMD Opteron 2376:
-
1.74e-06 seconds was the average time for performing the write without the
 deprivileged code running.
3.10e-06 seconds was the average time for performing the write with an entry and
 exit from deprvileged mode.

So approximately 178% overhead.

Signed-off-by: Ben Catterall 


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

[Xen-devel] [PATCH RFC v2 3/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode

[Ben Catterall]

Added trap handlers to catch exceptions such as a page fault, general
protection fault, etc. These handlers will crash the domain as such exceptions
would indicate that either there is a bug in deprivileged mode or it has been
compromised by an attacker.

On calling a domain_crash() whilst in deprivileged mode, we need to restore
the host's context so that we do not have guest-defined registers and values
in use after this point due to lazy loading of these values in the SVM and VMX
implementations.

Signed-off-by: Ben Catterall 

Changed since v1

 * Changed to domain_crash(), domain_crash_synchronous was used previously.
 * Updated to perform a HVM context switch on crashing a domain
 * Updated hvm_deprivileged_check_trap() to return a testable error
   code and return based on this.
---
 xen/arch/x86/hvm/deprivileged.c| 54 ++
 xen/arch/x86/traps.c   | 48 +
 xen/arch/x86/x86_64/traps.c|  1 -
 xen/include/xen/hvm/deprivileged.h | 23 
 4 files changed, 125 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/deprivileged.c b/xen/arch/x86/hvm/deprivileged.c
index 994c19e..01efbe1 100644
--- a/xen/arch/x86/hvm/deprivileged.c
+++ b/xen/arch/x86/hvm/deprivileged.c
@@ -615,3 +615,57 @@ void hvm_deprivileged_finish_user_mode(void)
 
 hvm_deprivileged_finish_user_mode_asm();
 }
+
+/* Check if we are in deprivileged mode */
+int is_hvm_deprivileged_vcpu(void)
+{
+struct vcpu *v = get_current();
+
+if( is_hvm_vcpu(v) && (v->arch.hvm_vcpu.depriv_user_mode) )
+return 1;
+
+return 0;
+}
+
+/*
+ * Crash the domain. This should not be called if there are any memory
+ * allocations which will be freed by code following its invocation in the
+ * current execution context (current stack). This is because it causes a
+ * permanent 'context switch' and the current stack will be cloberred so
+ * any allocations made which are not freed by other paths will leak.
+ * This function should only be used after deprivileged mode has been
+ * successfully switched into, otherwise, the normal domain_crash function
+ * should be used.
+ *
+ * The domain which is crashed is that of the current vcpu.
+ *
+ * To crash the domain, we need to return to our privileged stack as we may 
have
+ * memory allocations which need to be cleaned up. Then, after we have returned
+ * to this stack, we can then crash the domain. We set a flag which we check
+ * when returning.
+ */
+void hvm_deprivileged_crash_domain(const char *reason)
+{
+struct vcpu *vcpu = get_current();
+
+vcpu->arch.hvm_vcpu.depriv_destroy = 1;
+
+printk(XENLOG_ERR "HVM Deprivileged Mode: Crashing domain. Reason: %s\n",
+   reason);
+
+/*
+ * Restore the processor's state. We need to do the privileged return
+ * path to undo any allocations that got us to this state
+ */
+hvm_deprivileged_finish_user_mode();
+/* DOES NOT RETURN */
+}
+
+/* Handle a trap event */
+int hvm_deprivileged_check_trap(const char* func_name)
+{
+if( is_hvm_deprivileged_vcpu() )
+hvm_deprivileged_crash_domain(func_name);
+
+return 0;
+}
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 9f5a6c6..df89aa9 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -74,6 +74,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
@@ -500,6 +501,12 @@ static void do_guest_trap(
 struct trap_bounce *tb;
 const struct trap_info *ti;
 
+/* If we take the trap whilst in HVM deprivileged mode
+ * then we should crash the domain.
+ */
+if( hvm_deprivileged_check_trap(__FUNCTION__) )
+return;
+
 trace_pv_trap(trapnr, regs->eip, use_error_code, regs->error_code);
 
 tb = >arch.pv_vcpu.trap_bounce;
@@ -616,6 +623,11 @@ static void do_trap(struct cpu_user_regs *regs, int 
use_error_code)
 unsigned long fixup;
 
 DEBUGGER_trap_entry(trapnr, regs);
+/* If we take the trap whilst in HVM deprivileged mode
+ * then we should crash the domain.
+ */
+if( hvm_deprivileged_check_trap(__FUNCTION__) )
+return;
 
 if ( guest_mode(regs) )
 {
@@ -1070,6 +1082,13 @@ void do_invalid_op(struct cpu_user_regs *regs)
 
 DEBUGGER_trap_entry(TRAP_invalid_op, regs);
 
+/*
+ * If we take the trap whilst in HVM deprivileged mode
+ * then we should crash the domain.
+ */
+if( hvm_deprivileged_check_trap(__func__) )
+return;
+
 if ( likely(guest_mode(regs)) )
 {
 if ( !emulate_invalid_rdtscp(regs) &&
@@ -1159,6 +1178,12 @@ void do_int3(struct cpu_user_regs *regs)
 {
 DEBUGGER_trap_entry(TRAP_int3, regs);
 
+/* If we take the trap whilst in HVM deprivileged mode
+ * then we should crash the domain.
+ */
+if( hvm_deprivileged_check_trap(__func__) )
+return;
+
 if ( !guest_mode(regs) )
 

Re: [Xen-devel] [OSSTEST PATCH 15/13] Plan reporting: Provide get-last-plan queuedaemon command

[Ian Campbell]

On Thu, 2015-09-03 at 16:52 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [OSSTEST PATCH 15/13] Plan reporting: Provide 
> get-last-plan queuedaemon command"):
> >   proc queuerun-finished/plan {} {
> >   runneeded-ensure-will 0
> >   report-plan plan plan
> >   report-plan plan projection
> >   }
> > 
> > report-plan X Y generates resource-Y.html from data-Y.pl.
> > 
> > In 15/13 we make it also copy data-Y.pl to data-Y-final.pl.
> ^
> I mean  data-X.pl

I read it as you meant it.

So great, thanks.



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

Re: [Xen-devel] [libvirt] [PATCH] libxl: report correct errno from virNetSocketNewConnectTCP on migration

[Jim Fehlig]

On 09/03/2015 10:26 AM, Jim Fehlig wrote:


Agreed. How about the following patch?



>From a30c493bd9e20c9a7a423789a202c444a5eba344 Mon Sep 17 00:00:00 2001
From: Jim Fehlig
Date: Thu, 3 Sep 2015 10:14:20 -0600
Subject: [PATCH] libxl: don't overwrite error from virNetSocketNewConnectTCP()

Remove redundant error reporting libxlDomainMigrationPerform().


FYI, I've changed s/reporting/reporting in/ in the commit message.

Regards,
Jim


virNetSocketNewConnectTCP() is perfectly capable of reporting
sensible errors.

Signed-off-by: Jim Fehlig




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

[Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org Technical Call (2015-09-09)

[Ian Campbell]

The next Xen technical call will be at:
Wed  9 Sep 17:00:00 BST 2015
`date -d @1441814400`

See http://lists.xen.org/archives/html/xen-devel/2015-01/msg00414.html
for more information on the call.

Please let me know (CC-ing the list) any topics which you would like to
discuss. It might be useful to include:

  * References to any relevant/recent mailing list threads;
  * Other people who you think should be involved in the discussion (and
CC them);

If you would like to attend then please let me know so I can send you the
dial in details.

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

Re: [Xen-devel] [PATCH] xen/p2m: fix extra memory regions accounting

[Juergen Gross]

On 09/03/2015 05:39 PM, Roger Pau Monné wrote:

El 03/09/15 a les 17.20, Juergen Gross ha escrit:

On 09/03/2015 05:01 PM, David Vrabel wrote:

On 03/09/15 15:55, Juergen Gross wrote:

On 09/03/2015 04:52 PM, David Vrabel wrote:

On 03/09/15 15:45, David Vrabel wrote:

On 03/09/15 15:38, Roger Pau Monné wrote:

El 03/09/15 a les 14.25, Juergen Gross ha escrit:

On 09/03/2015 02:05 PM, Roger Pau Monne wrote:

On systems with memory maps with ranges that don't end at page
boundaries,
like:

[...]
(XEN)  0010 - dfdf9c00 (usable)
(XEN)  dfdf9c00 - dfe4bc00 (ACPI NVS)
[...]

xen_add_extra_mem will create a protected range that ends up at
0xdfdf9c00,
but the function used to check if a memory address is inside of a
protected
range works with pfns, which means that an attempt to map
0xdfdf9c00
will be
refused because the check is performed against 0xdfdf9000
instead of
0xdfdf9c00.

In order to fix this, make sure that the ranges that are added
to the
xen_extra_mem array are aligned to page boundaries.

Signed-off-by: Roger Pau Monné 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Juergen Gross 
Cc: xen-de...@lists.xenproject.org
---
AFAICT this patch needs to be backported to 3.19, 4.0, 4.1 and 4.2.
---
 arch/x86/xen/setup.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 55f388e..dcf5865 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -68,6 +68,9 @@ static void __init xen_add_extra_mem(phys_addr_t
start, phys_addr_t size)
 {
 int i;

+start = PAGE_ALIGN(start);
+size &= PAGE_MASK;


This is not correct. If start wasn't page aligned and size was,
you'll
add one additional page to xen_extra_mem.


I'm not understanding this, let's put an example:

start = 0x8c00
size = 0x1000

After the fixup added above this would become:

start = 0x9000
size = 0x1000

So if anything, I'm adding one page less (because 0x8000 was partly
added, and with the fixup it is not added).


We expand the reserved (i.e., non-RAM) areas down so they're fully
covered with whole pages when we depopulate and 1:1 map them, we
should
add extra memory regions that cover these same areas.


Ignore this.  This was nonsense.

We expand the reserved (i.e., non-RAM) areas so they're fully covered
with whole pages when we depopulate and 1:1 map them, we should add the
extra memory such that it does not overlap with with expanded regions.
i.e., round up the start and round down the end (like Roger's patch
does).


Nearly. Roger's patch rounds up start and rounds down the size. It might
add non-RAM partial pages to xen_extra_mem.


Yes.  You're right.


Hmm, thinking more about it, I'd prefer to change xen_extra_mem to use
pfns instead of physical addresses. This would make things much more
clear.

Roger, do you want to do the patch or should I?


I can certainly take care of it if you are busy, otherwise I leave it to
you since you have more expertise on it :).


Okay, I can do it. Should be ready soon...


Juergen


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

Re: [Xen-devel] [Vote] Re-open staging for contributions at RC3

[Wei Liu]

The tree is in good state as far as I can tell.

I asked Jan on IRC. He doesn't have strong opinion.

And from the feedback I got from this threads, several maintainers
expressed their opinion in favour of reopening the tree.

So I now make the decision we branch at RC3 and reopen xen-unstable for
new contributions.

I will send out an email to announce this.

Wei.

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

Re: [Xen-devel] [libvirt] [PATCH] libxl: report correct errno from virNetSocketNewConnectTCP on migration

[Jim Fehlig]

On 09/03/2015 10:26 AM, Jim Fehlig wrote:


Agreed. How about the following patch?



>From a30c493bd9e20c9a7a423789a202c444a5eba344 Mon Sep 17 00:00:00 2001
From: Jim Fehlig
Date: Thu, 3 Sep 2015 10:14:20 -0600
Subject: [PATCH] libxl: don't overwrite error from virNetSocketNewConnectTCP()

Remove redundant error reporting libxlDomainMigrationPerform().
virNetSocketNewConnectTCP() is perfectly capable of reporting
sensible errors.

Signed-off-by: Jim Fehlig
---
  src/libxl/libxl_migration.c | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 9609e06..de2de91 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -487,12 +487,8 @@ libxlDomainMigrationPerform(libxlDriverPrivatePtr driver,
  /* socket connect to dst host:port */
  if (virNetSocketNewConnectTCP(hostname, portstr,
AF_UNSPEC,
-  ) < 0) {
-virReportSystemError(saved_errno,
- _("unable to connect to '%s:%s'"),
- hostname, portstr);
+  ) < 0)
  goto cleanup;
-}


I should try compiling before sending patches:

libxl/libxl_migration.c:475:9: error: unused variable 'saved_errno' 
[-Werror=unused-variable]

 int saved_errno = EINVAL;

I posted a working V2:

https://www.redhat.com/archives/libvir-list/2015-September/msg00107.html

Regards,
Jim


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

Re: [Xen-devel] [Xen-users] Changing netback tx interrupts affinity on Dom0

[Jintack Lim]

Thanks Julien.

On Thu, Sep 3, 2015 at 2:21 PM, Julien Grall 
wrote:

> On 03/09/15 17:06, Jintack Lim wrote:
> > Hi,
>
> Hi Jintack,
>
> > On Thu, Sep 3, 2015 at 11:34 AM, Ian Campbell  > > wrote:
> >
> > On Thu, 2015-09-03 at 10:59 -0400, Jintack Lim wrote:
> > > Hi,
> > >
> > > While I was running Apache server,
> > > I found that one of Dom0 vcpu is running 100% to handle irqs,
> > > and those irqs are set to be processed only on that specific vcpu.
> > >
> > > Referring to this document,
> > > http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide
> > > I tried to change smp_affinity by writing a value to /proc/irq/ > > -no>/smp_affinity,
> > > however the smp_affinity value was not changed.
> > >
> > > I'm working on Xen 4.5 on ARMv8,
> > > and the irq is netback tx interrupt.
> > >
> > > # cat /proc/irq/106/smp_affinity
> > > 1
> > >
> > > # cat /proc/interrupts
> > > ...
> > > 106:  53849  0  0  0   xen-dyn-event
> > > vif1.1-q0-tx
> > > 107:  1  0  0  0   xen-dyn-event
> > > vif1.1-q0-rx
> > > 108:  61460  0  0  0   xen-dyn-event
> > > vif1.1-q1-tx
> > > 109:  1  0  0  0   xen-dyn-event
> > > vif1.1-q1-rx
> > > 110:  67118  0  0  0   xen-dyn-event
> > > vif1.1-q2-tx
> > > 111:  1  0  0  0   xen-dyn-event
> > > vif1.1-q2-rx
> > > 112:  58273  0  0  0   xen-dyn-event
> > > vif1.1-q3-tx
> > > 113:  1  0  0  0   xen-dyn-event
> > > vif1.1-q3-rx
> > > ...
> > >
> > > What would be the way to change smp_affinity?
>
> All those interrupts are in-fine event channels. This is a bug in Linux
> which I sent a fix a month ago and it's queued in xentip for Linux 4.3 [1]
>
> The event channel rebinding was not working because we don't have vector
> callback on ARM and therefore the driver was only allowing event channel
> to be routed on VCPU0.
>
>
After applying this patch, I was able to set smp_affinity.

In addition, the default value of smp_affinity for netback tx interrupts on
Dom0 becomes "f" (I have four vcpus on Dom0).
What I meant by 'netback tx interrupts' is vif1.1-q-tx
This is slightly different from x86, because netback tx interrupts are
pinned to separate vcpus on x86.
I'm not sure this question is appropriate for devel-list,
but why the policy to set smp_affinity for netback tx interrupts are
different on ARM and x86?


> commit 4a5b69464e51f4a8dd432e8c2a1468630df1a53c
> Author: Julien Grall 
> Date:   Tue Jul 28 10:10:42 2015 +0100
>
> xen/events: Support event channel rebind on ARM
> Currently, the event channel rebind code is gated with the presence of
> the vector callback.
>
> The virtual interrupt controller on ARM has the concept of per-CPU
> interrupt (PPI) which allow us to support per-VCPU event
> channel.Therefore there is no need of vector callback for ARM.
>
> Xen is already using a free PPI to notify the guest VCPU of an event.
> Furthermore, the xen code initialization in Linux (see
> arch/arm/xen/enlighten.c) is requesting correctly a per-CPU IRQ.
>
> Introduce new helper xen_support_evtchn_rebind to allow architecture
> decide whether rebind an event is support or not. It will always return
> true on ARM and keep the same behavior on x86.
>
> This is also allow us to drop the usage of xen_have_vector_callback
> entirely in the ARM code.
>
> Signed-off-by: Julien Grall 
> Signed-off-by: David Vrabel 
>
> Regards,
>
> [1] https://lkml.org/lkml/2015/7/28/205
>
> --
> Julien Grall
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/NUMA: make init_node_heap() respect Xen heap limit

[Julien Grall]

Hi Jan,

On 27/08/2015 09:37, Jan Beulich wrote:
> On NUMA systems, where we try to use node local memory for the basic
> control structures of the buddy allocator, this special case needs to
> take into consideration a possible address width limit placed on the
> Xen heap. In turn this (but also other, more abstract considerations)
> requires that xenheap_max_mfn() not be called more than once (at most
> we might permit it to be called a second time with a larger value than
> was passed the first time), and be called only before calling
> end_boot_allocator().
> 
> While inspecting all the involved code, a couple of off-by-one issues
> were found (and are being corrected here at once):
> - arch_init_memory() cleared one too many page table slots
> - the highmem_start based invocation of xenheap_max_mfn() passed too
>big a value
> - xenheap_max_mfn() calculated the wrong bit count in edge cases
> 
> Signed-off-by: Jan Beulich 

This patch is breaking boot on aarch64 platform (particularly X-gene).

I think this should be considered as a block until I find a way to
fix it.

I've noticed it while rebasing my branch on xengit/staging, although
given that there is no aarch64 hardware on osstest this issue won't
be reported.

I gave a try to boot on arm32 and didn't see any failure.

I will do more debug tonight and tomorrow morning to see what's going
on. Stack trace below:

- UART enabled -
- CPU  booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 0040 - 0043
(XEN)
(XEN) MODULE[0]: 004000ff9000 - 00400100 Device Tree
(XEN) MODULE[1]: 00400200 - 004002a4aa00 Kernel   console=hvc0 
root=/dev/sda2 rw earlycon=uart8250,mmio32,0x1c02 ignore_loglevel
(XEN)  RESVD[0]: 00400300 - 004003004000
(XEN)  RESVD[1]: 0040 - 0041
(XEN)
(XEN) Command line: conswitch=x console=dtuart dtuart=/soc/serial@1c02 
no-bootscrub noreboot dom0_mem=4G
(XEN) Placing Xen at 0x0043ffe0-0x0044
(XEN) Update BOOTMOD_XEN from 00400400-00400410ad81 => 
0043ffe0-0043fff0ad81
(XEN) Xen heap: 38 bits
(XEN) Domain heap initialised
(XEN) create_xen_entries: L2 failed
(XEN) Hypervisor Trap. HSR=0x9646 EC=0x25 IL=1 Syndrome=0x46
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.6.0-rc  arm64  debug=y  Not tainted ]
(XEN) CPU:0
(XEN) PC: 0025a638 clear_page+0x10/0x24
(XEN) LR: 0027eb28
(XEN) SP: 002b7db0
(XEN) CPSR:   83c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)  X0: 4000  X1: 0040  X2: 0004
(XEN)  X3:   X4: 3fff  X5: 002982e8
(XEN)  X6: 0004  X7: 002c4a30  X8: 002c4a28
(XEN)  X9: 000800037e40 X10: 002c1950 X11: 0200
(XEN) X12:  X13:  X14: 
(XEN) X15: 0040 X16: 0028c734 X17: 0006
(XEN) X18: 84d0 X19: 4000 X20: 0001
(XEN) X21: 0027b400 X22: 40001000 X23: 0027b000
(XEN) X24: 0027b000 X25: 0027b000 X26: 6db7
(XEN) X27: fff8 X28: 4000  FP: 002b7db0
(XEN)
(XEN)   VTCR_EL2: 8000
(XEN)  VTTBR_EL2: 
(XEN)
(XEN)  SCTLR_EL2: 30cd183d
(XEN)HCR_EL2: 0030643f
(XEN)  TTBR0_EL2: 0043ffef4000
(XEN)
(XEN)ESR_EL2: 9646
(XEN)  HPFAR_EL2: 
(XEN)FAR_EL2: 4000
(XEN)
(XEN) Xen stack trace from sp=002b7db0:
(XEN)002b7e20 00287d6c 80039000 0440
(XEN)0044 002a  0027b000
(XEN)002a0048 0040 0044 0001
(XEN)  0043efb181f0 0020060c
(XEN)00400400 004003e0 004000ff9000 
(XEN)0040  0001 
(XEN) 0043efb8eff0 004000ff9000 7000
(XEN)0004 0027d5e8  
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN) 

Re: [Xen-devel] [PATCH] x86/NUMA: make init_node_heap() respect Xen heap limit

[Julien Grall]

On 03/09/2015 21:01, Julien Grall wrote:
> Hi Jan,
> 
> On 27/08/2015 09:37, Jan Beulich wrote:
>> On NUMA systems, where we try to use node local memory for the basic
>> control structures of the buddy allocator, this special case needs to
>> take into consideration a possible address width limit placed on the
>> Xen heap. In turn this (but also other, more abstract considerations)
>> requires that xenheap_max_mfn() not be called more than once (at most
>> we might permit it to be called a second time with a larger value than
>> was passed the first time), and be called only before calling
>> end_boot_allocator().
>>
>> While inspecting all the involved code, a couple of off-by-one issues
>> were found (and are being corrected here at once):
>> - arch_init_memory() cleared one too many page table slots
>> - the highmem_start based invocation of xenheap_max_mfn() passed too
>> big a value
>> - xenheap_max_mfn() calculated the wrong bit count in edge cases
>>
>> Signed-off-by: Jan Beulich 
> 
> This patch is breaking boot on aarch64 platform (particularly X-gene).
> 
> I think this should be considered as a block until I find a way to
> fix it.

And found why! The last xenheap_bits changed from 39 to 38.

On x-gene the last max mfn used for the xenheap is 0x440, which the
new computation, it will give 38 bits which doesn't cover the entire
xenheap range.

I have wrote a patch to fix the issue, but I'm not sure that it's
the right things to do (see below).

Regards,

commit d1f2e47326da87c55f3165156407f224d684bccd
Author: Julien Grall 
Date:   Thu Sep 3 21:49:31 2015 +0100

xen: pagealloc: Correctly calculate the number of xenheap bits

The commit 88e3ed61642bb393458acc7a9bd2f96edc337190 "x86/NUMA: make
init_node_heap() respect Xen heap limit" breaks boot on the arm64 board
X-Gene.

This is because the last xen heaf MFN is 0x440. Which the new way to
calculate the number bits, the result would 38 bits which doesn't cover
all the xenheap. Fix it by dropping the -1 in the expression.

Signed-off-by: Julien Grall 

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 74fc1de..24fb09c 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1558,7 +1558,7 @@ void __init xenheap_max_mfn(unsigned long mfn)
 ASSERT(!first_node_initialised);
 ASSERT(!xenheap_bits);
 BUILD_BUG_ON(PADDR_BITS >= BITS_PER_LONG);
-xenheap_bits = min(flsl(mfn + 1) - 1 + PAGE_SHIFT, PADDR_BITS);
+xenheap_bits = min(flsl(mfn + 1) + PAGE_SHIFT, PADDR_BITS);
 printk(XENLOG_INFO "Xen heap: %u bits\n", xenheap_bits);
 }

-- 
Julien Grall

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

Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - PUSHED

[Jim Fehlig]

On 09/01/2015 07:14 AM, Ian Campbell wrote:

On Tue, 2015-09-01 at 13:47 +0100, Ian Jackson wrote:

Jim Fehlig writes ("Re: [osstest test] 60719: tolerable FAIL - PUSHED"):

This sounds a bit like an issue discussed in the Redhat libvirt
troubleshooting FAQ

https://access.redhat.com/documentation/en
-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Admin
istration_Guide/sect-Troubleshooting
-Common_libvirt_errors_and_troubleshooting.html#sect
-Migration_fails_with_Error_unable_to_resolve_address
Right. If it is a DNS issue, error handling in the libvirt libxl
migration code needs improving.

I booked out a test host, and (as I expected) forward DNS works, but
reverse DNS on test box IP addresses does not:

As discussed IRL I was also investigating this using the Cambridge
instance, which does have correct reverse DNS:

 root@moss-bug:~# host moss-bug.xs.citrite.net
 moss-bug.xs.citrite.net has address 10.80.229.144
 root@moss-bug:~# host -i 10.80.229.144
 144.229.80.10.in-addr.arpa domain name pointer moss-bug.xs.citrite.net.
 root@moss-bug:~# domainname -f
 moss-bug.xs.citrite.net
 root@moss-bug:~# cat /etc/hosts
 127.0.0.1  localhost
 127.0.1.1  moss-bug.xs.citrite.net moss-bug

 # The following lines are desirable for IPv6 capable hosts
 ::1 localhost ip6-localhost ip6-loopback
 ff02::1 ip6-allnodes
 ff02::2 ip6-allrouters
 root@moss-bug:~#

(previously these machines had a wrong idea about their own FQDN, that is
now fixed)

I am now seeing the same error as the production instance:

2015-09-01 12:10:00 Z executing ssh ... root@10.80.229.144 virsh --debug 0 
migrate --live debian.guest.osstest xen+ssh://10.80.228.77
migrate: live(bool): (none)
migrate: domain(optdata): debian.guest.osstest
migrate: desturi(optdata): xen+ssh://10.80.228.77
migrate: found option : debian.guest.osstest
migrate:  trying as domain NAME
migrate: found option : debian.guest.osstest
migrate:  trying as domain NAME
error: unable to connect to 'lace-bug.xs.citrite.net:49152': Invalid argument


AFAICT, this error means the source libvirtd cannot open a tcp connection to the 
destination libvirtd during the 'perform' phase of migration. In the preceding 
'prepare' phase, the destination libvirtd opened a socket to listen for the 
incoming migration, and passed the connection details back to the source 
libvirtd. The connection details (hostname:port) are generated on the 
destination libvirtd with


virGetHostname():virPortAllocatorAcquire()

virPortAllocatorAcquire() grabs the next available port in a range of ports. 
virGetHostName() attempts to get the FQDN of the host


http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virutil.c;h=cddc78a700c12a4f786a1f6544b92b8ee19c85f5;hb=HEAD#l632

Seems the source libvirtd cannot connect to the hostname:port created by the 
destination libvirtd.


Regards,
Jim


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

[Xen-devel] [linux-3.10 test] 61268: regressions - FAIL

[osstest service owner]

flight 61268 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61268/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-vhd   9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 60670
 test-amd64-i386-freebsd10-amd64 14 guest-localmigrate fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-i386-qemut-rhel6hvm-intel 10 guest-stopfail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-saverestore fail 
in 60748 REGR. vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate.2 fail in 60748 
REGR. vs. 60670
 test-amd64-i386-qemut-rhel6hvm-amd 10 guest-stop fail in 60790 REGR. vs. 60670
 test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail in 
60790 REGR. vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 13 guest-localmigrate fail in 
60790 REGR. vs. 60670
 test-amd64-i386-freebsd10-i386 14 guest-localmigrate fail in 60865 REGR. vs. 
60670
 test-amd64-i386-xl-qcow2 10 guest-start  fail in 60865 REGR. vs. 60670
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail in 
60950 REGR. vs. 60670
 test-amd64-i386-xl-vhd   10 guest-start  fail in 60950 REGR. vs. 60670
 test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail in 60950 REGR. 
vs. 60670
 test-amd64-i386-qemuu-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 60950 
REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3 12 guest-saverestore fail in 60992 REGR. vs. 
60670

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl6 xen-boot   fail in 60748 pass in 61268
 test-amd64-i386-libvirt  16 guest-stop fail in 60790 pass in 60865
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 guest-saverestore fail in 60790 
pass in 60865
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore  fail in 60790 pass in 61268
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 60790 pass in 61268
 test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail in 60790 pass in 61268
 test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-start.2 fail in 60950 pass in 
60790
 test-amd64-i386-libvirt  14 guest-saverestore  fail in 60950 pass in 61268
 test-amd64-i386-freebsd10-amd64 13 guest-saverestore fail in 60950 pass in 
61268
 test-amd64-i386-qemut-rhel6hvm-intel 9 redhat-install fail in 60950 pass in 
61268
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
60950 pass in 61268
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
60950 pass in 61268
 test-amd64-i386-libvirt-raw   9 debian-di-install  fail in 60950 pass in 61268
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-saverestore fail in 
60992 pass in 60790
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 60748
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
60748
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-installfail pass in 60790
 test-amd64-i386-freebsd10-i386 13 guest-saverestore fail pass in 60865
 test-amd64-i386-libvirt  15 guest-saverestore.2 fail pass in 60865
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
60865
 test-amd64-i386-xl-qcow2  9 debian-di-install   fail pass in 60865
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 
60950
 test-amd64-i386-xl-vhd9 debian-di-install   fail pass in 60950
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install   fail pass in 60950
 

Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for multicast control

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 September 2015 09:57
> To: Paul Durrant
> Cc: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org;
> net...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for
> multicast control
> 
> >>> On 02.09.15 at 18:58,  wrote:
> > @@ -1215,6 +1289,31 @@ static void xenvif_tx_build_gops(struct
> xenvif_queue *queue,
> > break;
> > }
> >
> > +   if (extras[XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1].type) {
> > +   struct xen_netif_extra_info *extra;
> > +
> > +   extra =
> [XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1];
> > +   ret = xenvif_mcast_add(queue->vif, extra-
> >u.mcast.addr);
> 
> What's the reason this call isn't gated on vif->multicast_control?
> 

No particular reason. I guess it eats a small amount of memory for no gain but 
a well behaved frontend wouldn't send such a request and a malicious one can 
only send 64 of them before netback starts to reject them.

  Paul

> Jan


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

Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for multicast control

[Jan Beulich]

>>> On 02.09.15 at 18:58,  wrote:
> @@ -1215,6 +1289,31 @@ static void xenvif_tx_build_gops(struct xenvif_queue 
> *queue,
>   break;
>   }
>  
> + if (extras[XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1].type) {
> + struct xen_netif_extra_info *extra;
> +
> + extra = [XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1];
> + ret = xenvif_mcast_add(queue->vif, extra->u.mcast.addr);

What's the reason this call isn't gated on vif->multicast_control?

Jan


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

Re: [Xen-devel] [PATCH v6 10/31] xen/arm: ITS: Introduce gic_is_lpi helper function

[Vijay Kilari]

On Tue, Sep 1, 2015 at 6:32 PM, Julien Grall  wrote:
> On 01/09/15 12:56, Vijay Kilari wrote:
>>> BTW, I suggested to create a field nr_lpis but you decided to store the
>>> number of bits supported. Why?
>>
>> I have nr_lpis field in vgic structure (patch #17). But it just tells
>> how LPIs are supported
>> for a domain.
>
> Why are you speaking about vgic structure? I'm only suggesting to
> replace you nr_id_bits by nr_lpis in the hw GIC. AFAICT, there is
> nothing to prevent having 2 field using the same name on 2 differents
> structure...
>
>> Where as nr_id_bits shows total number of  lpis that hw supports.
>
> No nr_id_bits shows the total number of interrupt not LPIs. The total
> number of LPIs is (1 << nr_id_bits) - 8092. Although (1 << nr_id_bits)
> gives you the last LPI interrupt ID supported.
>
> Anyway, as I said earlier, re-calculating the last LPI interrupt ID
> everytime based on the shift is time consuming. You should optimize for
> the common case rather than using copy the raw value (i.e ID bits) from
> the HW directly.
>
> Maybe the name "max_lpi_id" would make more sense to you for a name?

Instead of storing max_lpi_id which is ( 1 << nr_id_bits) - 8192, I prefer
to rename nr_id_bits as nr_irq_ids which can be initialized to (1 << nr_id_bits)
for gicv3 and gicv2_info.nr_lines for gicv2.

and gic_is_lpi() as below will work both gicv2 and gicv3.

bool_t gic_is_lpi(unsigned int irq)
{
return (irq >= FIRST_GIC_LPI && irq < gic_hw_ops->info->nr_irq_ids);
}

Regards
Vijay

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

[Xen-devel] [distros-debian-jessie test] 37850: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 9 debian-di-install fail never 
pass

baseline version:
 flight   37844

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub fail
 test-amd64-amd64-i386-jessie-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] [PATCH v2 net-next] xen-netback: add support for multicast control

[Ian Campbell]

On Thu, 2015-09-03 at 10:00 +0100, Paul Durrant wrote:
> > 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 03 September 2015 09:57
> > To: Paul Durrant
> > Cc: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org;
> > net...@vger.kernel.org
> > Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support 
> > for
> > multicast control
> > 
> > > > > On 02.09.15 at 18:58,  wrote:
> > > @@ -1215,6 +1289,31 @@ static void xenvif_tx_build_gops(struct
> > xenvif_queue *queue,
> > >   break;
> > >   }
> > > 
> > > + if (extras[XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1].type) 
> > > {
> > > + struct xen_netif_extra_info *extra;
> > > +
> > > + extra =
> > [XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1];
> > > + ret = xenvif_mcast_add(queue->vif, extra-
> > > u.mcast.addr);
> > 
> > What's the reason this call isn't gated on vif->multicast_control?
> > 
> 
> No particular reason. I guess it eats a small amount of memory for no 
> gain but a well behaved frontend wouldn't send such a request and a 
> malicious one can only send 64 of them before netback starts to reject 
> them.

Perhaps a confused guest might submit them thinking they would work when
actually the feature hasn't been properly negotiated and since it would
succeed it wouldn't generate an error on the guest side?

(A bit of a niche corner case I confess...)

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

Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for multicast control

[Paul Durrant]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 03 September 2015 10:31
> To: Paul Durrant; Jan Beulich
> Cc: Wei Liu; xen-de...@lists.xenproject.org; net...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for
> multicast control
> 
> On Thu, 2015-09-03 at 10:00 +0100, Paul Durrant wrote:
> > >
> > > -Original Message-
> > > From: Jan Beulich [mailto:jbeul...@suse.com]
> > > Sent: 03 September 2015 09:57
> > > To: Paul Durrant
> > > Cc: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org;
> > > net...@vger.kernel.org
> > > Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support
> > > for
> > > multicast control
> > >
> > > > > > On 02.09.15 at 18:58,  wrote:
> > > > @@ -1215,6 +1289,31 @@ static void xenvif_tx_build_gops(struct
> > > xenvif_queue *queue,
> > > > break;
> > > > }
> > > >
> > > > +   if (extras[XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1].type)
> > > > {
> > > > +   struct xen_netif_extra_info *extra;
> > > > +
> > > > +   extra =
> > > [XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1];
> > > > +   ret = xenvif_mcast_add(queue->vif, extra-
> > > > u.mcast.addr);
> > >
> > > What's the reason this call isn't gated on vif->multicast_control?
> > >
> >
> > No particular reason. I guess it eats a small amount of memory for no
> > gain but a well behaved frontend wouldn't send such a request and a
> > malicious one can only send 64 of them before netback starts to reject
> > them.
> 
> Perhaps a confused guest might submit them thinking they would work
> when
> actually the feature hasn't been properly negotiated and since it would
> succeed it wouldn't generate an error on the guest side?

It would, but that's essentially harmless to functionality. If the feature had 
not been negotiated properly then multicast flooding would still be in 
operation so the guest would not lose any multicasts. I can tighten things up 
if you like but as you say below it is a bit of a corner case.

  Paul

> 
> (A bit of a niche corner case I confess...)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Vote] Re-open staging for contributions at RC3

[Ian Campbell]

On Wed, 2015-09-02 at 17:12 +0100, Lars Kurth wrote:
> Hi all,
> 
> I wanted to kick off a vote related to the following threads
> * http://lists.xenproject.org/archives/html/xen-devel/2015
> -08/msg00883.html - [URGENT RFC] Branching and reopening -unstable
> * http://lists.xenproject.org/archives/html/xen-devel/2015
> -08/msg00543.html - [xen 4.6 retrospective] [urgent] rename "freeze" 
> window and make release branch as soon as possible after RC1
> 
> Although there was no consensus in the general case to say we should 
> always branch at RC-x at any given release, there seems to be enough 
> consensus for branching earlier, given a number of conditions are met:
> 
> In particular:
> 1: We should not re-open staging too early (aka we would need to get a 
> sense how much churn to expect)
> 2: Maybe we should not accept major re-factoring and leave it up to the 
> discretion of thy maintainers to do so - aka Ian Jackson's option B. But 
> there seems to be some disagreement around it. 
> 
> 2.1: Some maintainers are concerned that they would have to deal with 
> backporting, if we re-opened early.
> 
> 2.2: A sensible compromise seems to me for the maintainer to evaluate 
> whether a patch is ready to go in after RC3: if there is an amount of 
> back porting that the maintainer can't deal with, it is IMHO OK for the 
> maintainer to let the contributor know and give him/her the option to 
> provide a patch for two trees as it is customary in Linux OR to wait 
> until the ongoing release is out. This is a slight variant of Ian 
> Jackson's option B in http://lists.xenproject.org/archives/html/xen
> -devel/2015-08/msg00883.html ;
> 
> Of course, 1 will minimise the amount of incidents for 2
> 
> = VOTE =  
> With that in mind: please vote on
> A) Do we think 4.6 is in a good enough state to branch at the next RC 
> (which would be RC3)

IMHO this decision should be the Release Managers to make. I'm not sure how
to vote to express that, so I suppose I'll abstain.

Since I'm sure the RM would want input from maintainers to help them make
this decision I'll note that my opinion (not vote) is that the tree is
indeed in a good enough state to branch.

> B) Do we have enough consensus given that there is some disagreement on 
> how to deal with back-porting. In other words, does the proposal 2.2 
> above look sensible. 

It's not clear to me which branch "ready to go in after RC3" refers to, the
reopened staging or the newly branched 4.6 branch?

If the proposal is to ask maintainers to use their discretion when applying
things to staging, i.e. taking the possible need to do backports (of
subsequent patches) to the 4.6 branch and/or asking for help with backports
from the submitters of patches which need it then that gets +1 from me.

Ian.

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

Re: [Xen-devel] Kbuild and Kconfig

[Jan Beulich]

>>> On 03.09.15 at 12:09,  wrote:
> At 10:56 +0100 on 03 Sep (1441277769), Ian Campbell wrote:
>> Is the proposal here then to abandon autoconf for the tools subtree in
>> favour of Kconfig? Or maybe to somehow hybridize autoconf (for e.g. library
>> and feature detection) with Kconfig (for user selection of options)? I'm
>> not sure how I feel about either of those approaches, they certainly both
>> need careful consideration, and the second in particular regarding the
>> interactions...
>> 
>> FWIW it seems to me that the link between things which are optional in Xen
>> and which are optional in the tools is (or should be) pretty loose. i.e.
>> the tools today _always_ support XSM and correctly handle the errors from
>> Xen if it is not enabled there. Personally I think this is the right way to
>> do things. Likewise Xen doesn't care if the tools have particular opinions
>> on the qemu to use or whatever.
> 
> This is as it should be, but I can see the argument for cutting out
> whole features at build time, from both sides.  If I were embedding
> Xen in an appliance, or building my own cloud, I'd be very happy to
> ./configure --disable all sorts of things from the entire build,
> without having to figure out how to disable each feature twice.

I don't see why ./configure shouldn't be able to invoke the
configure mechanism in xen/, passing it appropriate overrides
based on the --disable settings it was handed.

I definitely agree with Ian that using a single mechanism for
both tools and hypervisor is rather not what we want (due to
the different nature of the two).

Jan


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

[Xen-devel] [Patch V1 0/3] usb, xen: add pvUSB backend

[Juergen Gross]

This series adds a Xen pvUSB backend driver to qemu. USB devices
connected to the host can be passed through to a Xen guest. The
devices are specified via Xenstore. Access to the devices is done
via host-libusb.c

I've tested the backend with various USB devices (memory sticks,
keyboard, phono preamp, ...).

Changes since RFC:
- open device via qdev_device_add(), making patch 1 obsolete
- modify patch 2 to use isoc passthrough via libusb instead of one
  job per frame

Juergen Gross (3):
  xen: introduce dummy system device
  xen/usb: add capability for passing through isoc jobs to host devices
  xen: add pvUSB backend

 hw/usb/Makefile.objs |4 +
 hw/usb/core.c|   11 +-
 hw/usb/host-libusb.c |   51 +-
 hw/usb/xen-usb.c | 1120 ++
 hw/xenpv/xen_machine_pv.c|   42 ++
 include/hw/xen/xen_backend.h |   11 +
 6 files changed, 1229 insertions(+), 10 deletions(-)
 create mode 100644 hw/usb/xen-usb.c

-- 
2.1.4


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

Re: [Xen-devel] [OSSTEST PATCH 04/13] Planner: Fix indefinite holdoff

[Ian Campbell]

On Wed, 2015-09-02 at 16:45 +0100, Ian Jackson wrote:
> runneeded-ensure-will would always reset the runneeded_holdoff_after
> timer.  So no new queue run would start until no runneeded-ensure-will
> has occurred for (currently) 30s.
> 
> Instead, only start the timer if it's not already running.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

> ---
>  ms-queuedaemon |   10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/ms-queuedaemon b/ms-queuedaemon
> index d6d59ee..1aa526c 100755
> --- a/ms-queuedaemon
> +++ b/ms-queuedaemon
> @@ -86,10 +86,12 @@ proc runneeded-ensure-will {need} {
>  log-event "runneeded-ensure-will $need (was $need_queue_run)"
>  
>  if {$need > $need_queue_run} { set need_queue_run $need }
> -catch { after cancel $runneeded_holdoff_after }
> -set runneeded_holdoff_after \
> -[after [expr {$c(QueueDaemonHoldoff) * 1000}] \
> - runneeded-perhaps-start]
> +
> +if {![info exists runneeded_holdoff_after]} {
> + set runneeded_holdoff_after \
> + [after [expr {$c(QueueDaemonHoldoff) * 1000}] \
> +  runneeded-perhaps-start]
> +}
>  }
>  
>  proc runneeded-perhaps-start {} {

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

Re: [Xen-devel] [OSSTEST PATCH 06/13] Planner: client side: New `!OK think noalloc' protocol

[Ian Campbell]

On Wed, 2015-09-02 at 16:45 +0100, Ian Jackson wrote:
> Introduce a way for the queue daemon to tell its client that it must
> not allocate anything in this planning iteration.
> 
> In the client:
>  * Advertise the new feature via set-info.
>  * Accept the `noalloc' part of `!OK think noalloc';
>  * Print that in our log message;
>  * Honour it by passing it to $resourcecall.
> 
> And document the new protocol.  However, there is no server-side yet,
> so this does not yet introduce any overall change to the system.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - PUSHED

[Ian Campbell]

On Thu, 2015-09-03 at 11:49 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [osstest test] 60719: tolerable 
> FAIL - PUSHED"):
> ...
> > I suspect this is down to:
> > 
> > root@lace-bug:/etc/libvirt# cat /etc/hosts
> > 127.0.0.1   localhost
> > 127.0.1.1   lace-bug.xs.citrite.net
> >  lace-bug
> 
> This is simply wrong.  It means that when programs on the host try to
> find the host's own IP address starting with its host name, they get
> different (and wrong) answers to programs on other hosts.
> 
> I can see why D-I wants to do this but in our setup it is simply
> entirely wrong.  Is there a way to suppress this (from preseed
> maybe) ?

I'll see if I can find the code which generates this file...

> > Overall I'm not sure what to do here. The Debian config seems a bit 
> > odd,
> > but I'm not sure if it is actually "wrong". OTOH I'm not sure how 
> > libvirt
> > could be changed to work in this scenario.
> 
> It might be possible to work around this in libvirt, but this is by no
> means libvirt's fault.

Right.

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

Re: [Xen-devel] Kbuild and Kconfig

[Tim Deegan]

Hi,

At 12:50 -0500 on 02 Sep (1441198200), Doug Goldstein wrote:
> I just wanted to bring this to a top level post since Jonathan Creekmore
> and myself have talked with a few maintainers in different threads and
> on IRC about potentially using Kconfig and/or Kbuild for Xen.

If we're going to need a configure step before building the
hypervisor, maybe we should consider using the autoconf runes instead.

I'm one of the people who objected to requiring ./configure before
building the hypervisor, but I think it would be better than having
_two_ config systems which are not synced with each other, esp. if
we'll want to enable/disable features with matching tools-side code.

If we do go this way, I think we'd need a ./configure --hypervisor-only,
or similar, that _only_ makes the various CONFIG_ flags, and doesn't
do the tedious library & compiler checks that are needed for the
user-space code.

Cheers,

Tim.

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

Re: [Xen-devel] Kbuild and Kconfig

[Tim Deegan]

At 10:56 +0100 on 03 Sep (1441277769), Ian Campbell wrote:
> On Wed, 2015-09-02 at 19:29 +0100, Andrew Cooper wrote:
> > On 02/09/15 18:50, Doug Goldstein wrote:
> > > I just wanted to bring this to a top level post since Jonathan 
> > > Creekmore
> > > and myself have talked with a few maintainers in different threads and
> > > on IRC about potentially using Kconfig and/or Kbuild for Xen. Basically
> > > I would like to get a rough idea on what the Xen community wants the
> > > system to look like before starting work on it to both save myself time
> > > and save maintainers review cycles. So that being said rough proposal 
> > > as
> > > follows:
> > > 
> > > * target only the xen/ directory tree (i.e. not the toolstack, stubdoms
> > > or docs)
> > > * split top level config bits to not affect xen/ tree (currently only
> > > XSM_ENABLE / FLASK_ENABLE do)
> > > * convert xen/ to Kbuild first and merge this in (since Kconfig relies
> > > on Kbuild-y bits which can be undone but if we're going to go to Kbuild
> > > in the end why undo it and then redo it)
> > > * convert existing xen/ config bits into Kconfig and merge that in
> > > 
> > > Jonathan and I, in a former life, converted a project to Kbuild and
> > > Kconfig successfully. I have looked at starting with
> > > https://github.com/masahir0y/kbuild_skeleton while the tree is fairly
> > > old it does separate out the build bits from the Linux specific bits
> > > pretty nicely while removing module support which arguably is the most
> > > complicated part. Alternatively we could start with Linux 4.2 if that's
> > > more desirable.
> > 
> > Thinking longterm, it would be nice to have xen, tools and stubdoms
> > covered by a system like this
> 
> Is the proposal here then to abandon autoconf for the tools subtree in
> favour of Kconfig? Or maybe to somehow hybridize autoconf (for e.g. library
> and feature detection) with Kconfig (for user selection of options)? I'm
> not sure how I feel about either of those approaches, they certainly both
> need careful consideration, and the second in particular regarding the
> interactions...
> 
> FWIW it seems to me that the link between things which are optional in Xen
> and which are optional in the tools is (or should be) pretty loose. i.e.
> the tools today _always_ support XSM and correctly handle the errors from
> Xen if it is not enabled there. Personally I think this is the right way to
> do things. Likewise Xen doesn't care if the tools have particular opinions
> on the qemu to use or whatever.

This is as it should be, but I can see the argument for cutting out
whole features at build time, from both sides.  If I were embedding
Xen in an appliance, or building my own cloud, I'd be very happy to
./configure --disable all sorts of things from the entire build,
without having to figure out how to disable each feature twice.

Cheers,

Tim.

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

Re: [Xen-devel] [linux-4.1 test] 60785: tolerable FAIL - PUSHED

[Ian Jackson]

Ian Campbell writes ("Re: [linux-4.1 test] 60785: tolerable FAIL - PUSHED"):
> 60030 is the "bad" push which uses "fail like NN-bisect" to justify
> ignoring all three.

For example, you mean the line in 60030's report saying

  test-amd64-i386-xl   13 guest-saverestore   fail like 60094-bisect

Well, 60094's report is contained within

  Date: Tue, 28 Jul 2015 21:44:28 GMT
  Subject: "[linux-4.1 bisection] complete test-amd64-i386-xl

and says

  test-amd64-i386-xl   13 guest-saverestore   fail baseline untested

There was no build job in 60094; for Linux (build-i386-pvops) it used
59826 (ie 5cf9896d) and for Xen (build-i386) 59934 (xen.git#3a9ace01).

> IIRC there was a bug in the osstest machinery (now fixed by Ian) which lead
> to this, but I mention it in case I'm recalling incorrectly.

I think that actually this is another problem: sg-report-flight when
testing X' (with a baseline of X) can justify a failure of T(X',Y,Z)
with a bisection failure of T(X,Y'',Z).

If Y'' breaks T then this makes it look to sg-report-flight like T was
already broken in X.

The simple solution is for sg-report-flight for cr-daily-branch to to
look at bisections.

The more complicated one would be for sg-report-flight to compare
versions of Y when looking for justifications, but I'm not sure this
is desirable because it would reset the justification search each time
any other tree changed.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 01/13] Tcl: Use lshift instead of open-coding with lrange

[Ian Campbell]

On Wed, 2015-09-02 at 16:45 +0100, Ian Jackson wrote:
> In ms-queuedaemon, and JobDB-Executive, once each.  No functional
> change.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

(Caveat: I don't speak a lot of tcl, but seems plausible. Same caveat for
all tcl patches here...)

> ---
>  ms-queuedaemon  |3 +--
>  tcl/JobDB-Executive.tcl |3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/ms-queuedaemon b/ms-queuedaemon
> index e15bc79..d6d59ee 100755
> --- a/ms-queuedaemon
> +++ b/ms-queuedaemon
> @@ -210,8 +210,7 @@ proc queuerun-perhaps-step {} {
>  return
>  }
>  
> -set thinking [lindex $queue_running 0]
> -set queue_running [lrange $queue_running 1 end]
> +set thinking [lshift queue_running]
>  log-event "queuerun-perhaps-step selected"
>  
>  set thinking_after [after [expr {$c(QueueThoughtsTimeout) * 1000}] \
> diff --git a/tcl/JobDB-Executive.tcl b/tcl/JobDB-Executive.tcl
> index 7228712..d61d2a2 100644
> --- a/tcl/JobDB-Executive.tcl
> +++ b/tcl/JobDB-Executive.tcl
> @@ -74,8 +74,7 @@ proc set-flight {} {
>  set argv [lrange $argv 2 end]
>  }
>  
> -set flight [lindex $argv 0]
> -set argv [lrange $argv 1 end]
> +set flight [lshift argv]
>  set env(OSSTEST_FLIGHT) $flight
>  }
>  

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xend  5 xen-buildfail in 61126 REGR. vs. 60727
 build-i3865 xen-buildfail in 61126 REGR. vs. 60727
 build-i386-xend   5 xen-buildfail in 61126 REGR. vs. 60727
 build-i386-pvops  5 kernel-build fail in 61126 REGR. vs. 60727

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-vhd  3 host-install(3)  broken in 61126 pass in 61278
 test-amd64-amd64-i386-pvgrub 10 guest-startfail in 60802 pass in 61278
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 60802 pass in 
61278
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 60802 pass 
in 61278
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail in 60832 pass in 61278
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-localmigrate/x10 fail in 
60832 pass in 61278
 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail in 
60954 pass in 61278
 test-amd64-amd64-libvirt-raw  9 debian-di-install   fail pass in 60802
 test-amd64-i386-libvirt-vhd   9 debian-di-install   fail pass in 60832
 test-amd64-i386-xl-qcow2  9 debian-di-install   fail pass in 60954
 test-armhf-armhf-xl-vhd   6 xen-bootfail pass in 61126
 test-armhf-armhf-xl-arndale   6 xen-bootfail pass in 61126
 test-amd64-amd64-libvirt-vhd  9 debian-di-install   fail pass in 61126

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeatfail  like 60696
 test-amd64-i386-xl-vhd9 debian-di-installfail   like 60727
 test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  like 60727
 test-amd64-amd64-xl-vhd   9 debian-di-installfail   like 60727
 test-amd64-i386-libvirt  11 guest-start  fail   like 60727
 test-amd64-amd64-libvirt 11 guest-start  fail   like 60727
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60727

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-vhd1 build-check(1)blocked in 61126 n/a
 build-i386-libvirt1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked in 61126 n/a
 test-amd64-i386-libvirt   1 build-check(1)blocked in 61126 n/a
 build-i386-rumpuserxen1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)blocked in 61126 n/a
 test-amd64-amd64-pv   1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-pv1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-xl1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 61126 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)  blocked in 61126 n/a
 test-amd64-i386-pair  1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-libvirt-raw   1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-xl-qcow2  1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-libvirt-vhd   1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-xl-raw1 build-check(1)blocked in 61126 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)  blocked in 61126 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 61126 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1) blocked in 61126 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1) blocked in 61126 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1) blocked in 61126 n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1) blocked in 61126 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)  blocked in 61126 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1) blocked in 61126 n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked in 61126 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 61126 n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-raw 11 migrate-support-check fail in 60802 never pass
 test-amd64-i386-libvirt-vhd 

Re: [Xen-devel] [OSSTEST PATCH 02/13] Planner: docs: Minor fixes

[Ian Campbell]

On Wed, 2015-09-02 at 16:45 +0100, Ian Jackson wrote:
>  * Document the ms-queuedaemon banner
>  * Document the argument to the allocation $resourcecall callback fn.
> 
> Signed-off-by: Ian Jackson 
> ---
>  Osstest/Executive.pm |2 +-
>  README.planner   |3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
> index bf968c8..ab015d2 100644
> --- a/Osstest/Executive.pm
> +++ b/Osstest/Executive.pm
> @@ -604,7 +604,7 @@ sub plan_search () {
>  }
>  
>  sub alloc_resources {
> -my ($resourcecall) = pop @_;
> +my ($resourcecall) = pop @_; # $resourcecall->($plan);

Took me a while to work out this means $resourcecall is a function which
should be called as shown, but now I've got that:

Acked-by: Ian Campbell 

Maybe consider adding "Called as" to the front of the comment though? (Ack
either way)

>  my (%xparams) = @_;
>  # $resourcecall should die (abort) or return ($ok, $bookinglist)
>  #
> diff --git a/README.planner b/README.planner
> index ec4dce8..34eae97 100644
> --- a/README.planner
> +++ b/README.planner
> @@ -181,6 +181,9 @@ DETAILED PROTOCOL NOTES
>  
>  ms-queuedaemon commands
>  
> +< OK ms-queuedaemon [INFO...]
> +Banner on connection.  INFO should be ignored.
> +
>   > wait
>   I want to join the plan
>  

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

Re: [Xen-devel] [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2

[Luis Henriques]

On Wed, Sep 02, 2015 at 10:18:32AM +0100, Ian Campbell wrote:
> [resending to correct stable address, sorry folks]
> 
> TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59e
> ("xen/gntdev: convert priv->lock to a mutex", which was added in v4.0)
> needs $something doing to it, either s/mutex/spinlock/ or (more likely)
> backporting of 1401c00e59e too.
> 
> Looking at LTS:
> 
> 3.18.y: Backported both.
> 3.16.y: Has backported neither
> 3.14.y:   * Only backported 30b03d05e074
> 3.12.y: Has backported neither
> 3.10.y:   * Only backported 30b03d05e074
> 3.4.y:  Has backported neither
> 3.2.y:  Has backported neither
> 
> So AFAICT 3.14.y and 3.10.y need fixes, probably following 3.18 and
> backporting 1401c00e59e.
> 
> 3.16/12/4/2 might need to be careful if they subsequently pick up 30b03d05.
>

Thank you Ian.  In fact, I had explicitly dropped 30b03d05e074
("xen/gntdevt: Fix race condition in gntdev_release()") from the 3.16
kernel and notified stable maintainers about this problem (in a reply to a
3.12 review email).

Simply replacing the mutex by the spinlock in this commit seems to cause
problems (sleep in atomic) as pointed out by Jiri in other thread.

Since 1401c00e59ea ("xen/gntdev: convert priv->lock to a mutex") is a
clean cherry-pick for 3.16 (and probably to older kernels as well), I'm
happy to pick both commits if you can confirm they are both good for older
stable kernels (they seem to be!)

Cheers,
--
Luís

> See below for the build log error.
> 
> On Tue, 2015-09-01 at 11:05 +0100, Ian Campbell wrote:
> > On Tue, 2015-09-01 at 10:57 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [linux-3.14 bisection] complete test-amd64
> > > -i386
> > > -xl-qcow2"):
> > > > On Wed, 2015-08-26 at 20:02 +, osstest service owner wrote:
> > > > >   commit 9e6c072a69d87100808d16279d60e9f857291340
> > > > >   Author: Marek Marczykowski-Górecki <
> > > > > marma...@invisiblethingslab.com
> > > > > > 
> > > > >   Date:   Fri Jun 26 03:28:24 2015 +0200
> > > > >   
> > > > >   xen/gntdevt: Fix race condition in gntdev_release()
> > > > 
> > > > I'm not sure what to make of this.
> > > > 
> > > > The qcow2 test is one of the only ones I'd expect to be exercising 
> > > > gntdev
> > > > (most tests use LVM+blkback), which explains why this particular 
> > > > commit 
> > > > is
> > > > apparently seeing issues due to this particular change.
> > > 
> > > (You mean `which explains why this particular _test_ is [failing]',
> > > I think.)
> > 
> > Indeed.
> > 
> > > The host serial log in one of the confirmation tests of 9e6c072a shows
> > > serious trouble:
> > > 
> > >  http://logs.test-lab.xenproject.org/osstest/logs/60893/test-amd64-i386
> > > -xl-qcow2/serial-huxelrebe1.log
> > > 
> > >  Aug 26 19:36:51.841068 [  738.050547] BUG: unable to handle kernel
> > >  NULL pointer dereference at 0014
> > > 
> > >  Aug 26 19:36:56.753068 [  738.050594] IP: []
> > >  __mmu_notifier_invalidate_range_start+0x33/0x70
> > > 
> > > And the immediately preceding confirmation flight, which got a pass on
> > > 9e6c072a~1, seems fine:
> > > 
> > >  http://logs.test-lab.xenproject.org/osstest/logs/60892/test-amd64-i386
> > > -xl-qcow2/serial-huxelrebe1.log
> > > 
> > > But, it's difficult to see how that gntdev fix would be responsible
> > > for the bug.  Perhaps it changes the order in which certain things
> > > happen so as to expose another bug.
> > 
> > Or perhaps there was a fix and/or change in behaviour in the mmunotifier
> > stuff which the patch relied on but which isn't in 3.14?
> 
> Looking at http://logs.test-lab.xenproject.org/osstest/logs/60949/'s build
> jobs:
> http://logs.test-lab.xenproject.org/osstest/logs/60949/build-amd64
> -pvops/5.ts-kernel-build.log contains:
> 
> drivers/xen/gntdev.c: In function ‘gntdev_release’:
> drivers/xen/gntdev.c:532:2: warning: passing argument 1 of ‘mutex_lock’
> from incompatible pointer type [enabled by default]
> In file included from include/linux/notifier.h:13:0,
>  from include/linux/memory_hotplug.h:6,
>  from include/linux/mmzone.h:821,
>  from include/linux/gfp.h:5,
>  from include/linux/kmod.h:22,
>  from include/linux/module.h:13,
>  from drivers/xen/gntdev.c:24:
> include/linux/mutex.h:157:13: note: expected ‘struct mutex *’ but
> argument is of type ‘struct spinlock_t *’
> drivers/xen/gntdev.c:539:2: warning: passing argument 1 of
> ‘mutex_unlock’ from incompatible pointer type [enabled by default]
> In file included from include/linux/notifier.h:13:0,
>  from include/linux/memory_hotplug.h:6,
>  from include/linux/mmzone.h:821,
>  from include/linux/gfp.h:5,
>  from include/linux/kmod.h:22,
>  from include/linux/module.h:13,
>  from drivers/xen/gntdev.c:24:
> 

Re: [Xen-devel] Kbuild and Kconfig

[Ian Campbell]

On Wed, 2015-09-02 at 19:29 +0100, Andrew Cooper wrote:
> On 02/09/15 18:50, Doug Goldstein wrote:
> > I just wanted to bring this to a top level post since Jonathan 
> > Creekmore
> > and myself have talked with a few maintainers in different threads and
> > on IRC about potentially using Kconfig and/or Kbuild for Xen. Basically
> > I would like to get a rough idea on what the Xen community wants the
> > system to look like before starting work on it to both save myself time
> > and save maintainers review cycles. So that being said rough proposal 
> > as
> > follows:
> > 
> > * target only the xen/ directory tree (i.e. not the toolstack, stubdoms
> > or docs)
> > * split top level config bits to not affect xen/ tree (currently only
> > XSM_ENABLE / FLASK_ENABLE do)
> > * convert xen/ to Kbuild first and merge this in (since Kconfig relies
> > on Kbuild-y bits which can be undone but if we're going to go to Kbuild
> > in the end why undo it and then redo it)
> > * convert existing xen/ config bits into Kconfig and merge that in
> > 
> > Jonathan and I, in a former life, converted a project to Kbuild and
> > Kconfig successfully. I have looked at starting with
> > https://github.com/masahir0y/kbuild_skeleton while the tree is fairly
> > old it does separate out the build bits from the Linux specific bits
> > pretty nicely while removing module support which arguably is the most
> > complicated part. Alternatively we could start with Linux 4.2 if that's
> > more desirable.
> 
> Thinking longterm, it would be nice to have xen, tools and stubdoms
> covered by a system like this

Is the proposal here then to abandon autoconf for the tools subtree in
favour of Kconfig? Or maybe to somehow hybridize autoconf (for e.g. library
and feature detection) with Kconfig (for user selection of options)? I'm
not sure how I feel about either of those approaches, they certainly both
need careful consideration, and the second in particular regarding the
interactions...

FWIW it seems to me that the link between things which are optional in Xen
and which are optional in the tools is (or should be) pretty loose. i.e.
the tools today _always_ support XSM and correctly handle the errors from
Xen if it is not enabled there. Personally I think this is the right way to
do things. Likewise Xen doesn't care if the tools have particular opinions
on the qemu to use or whatever.

IOW I'm not sure have xen and tools use a common .config would make sense.

Ian.



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

Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for multicast control

[Ian Campbell]

On Thu, 2015-09-03 at 10:34 +0100, Paul Durrant wrote:
> > 
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: 03 September 2015 10:31
> > To: Paul Durrant; Jan Beulich
> > Cc: Wei Liu; xen-de...@lists.xenproject.org; net...@vger.kernel.org
> > Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support 
> > for
> > multicast control
> > 
> > On Thu, 2015-09-03 at 10:00 +0100, Paul Durrant wrote:
> > > > 
> > > > -Original Message-
> > > > From: Jan Beulich [mailto:jbeul...@suse.com]
> > > > Sent: 03 September 2015 09:57
> > > > To: Paul Durrant
> > > > Cc: Ian Campbell; Wei Liu; xen-de...@lists.xenproject.org;
> > > > net...@vger.kernel.org
> > > > Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add 
> > > > support
> > > > for
> > > > multicast control
> > > > 
> > > > > > > On 02.09.15 at 18:58,  wrote:
> > > > > @@ -1215,6 +1289,31 @@ static void xenvif_tx_build_gops(struct
> > > > xenvif_queue *queue,
> > > > >   break;
> > > > >   }
> > > > > 
> > > > > + if (extras[XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 
> > > > > 1].type)
> > > > > {
> > > > > + struct xen_netif_extra_info *extra;
> > > > > +
> > > > > + extra =
> > > > [XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1];
> > > > > + ret = xenvif_mcast_add(queue->vif, extra
> > > > > -
> > > > > u.mcast.addr);
> > > > 
> > > > What's the reason this call isn't gated on vif->multicast_control?
> > > > 
> > > 
> > > No particular reason. I guess it eats a small amount of memory for no
> > > gain but a well behaved frontend wouldn't send such a request and a
> > > malicious one can only send 64 of them before netback starts to 
> > > reject
> > > them.
> > 
> > Perhaps a confused guest might submit them thinking they would work
> > when
> > actually the feature hasn't been properly negotiated and since it would
> > succeed it wouldn't generate an error on the guest side?
> 
> It would, but that's essentially harmless to functionality. If the 
> feature had not been negotiated properly then multicast flooding would 
> still be in operation so the guest would not lose any multicasts. I can 
> tighten things up if you like but as you say below it is a bit of a 
> corner case.

Ah yes, I had something backwards and thought the guest might miss out on
something it was expecting, but as you say it will just get more than it
wanted.


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

Re: [Xen-devel] [linux-4.1 test] 60785: tolerable FAIL - PUSHED

[Ian Campbell]

On Fri, 2015-08-21 at 17:24 +, osstest service owner wrote:
> flight 60785 linux-4.1 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/60785/
> 
> Failures :-/ but no regressions.
> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat 
> fail in 60746 pass in 60785
>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
> guest-start/debianhvm.repeat fail pass in 60746
>  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
> fail pass in 60746
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-rumpuserxen-amd64 15 
> rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 60654
>  test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
> fail blocked in 60654
>  test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
> fail in 60746 like 60654

>  test-amd64-i386-xl-xsm   14 guest-saverestorefail   like 
> 60654
>  test-amd64-i386-xl   14 guest-saverestorefail   like 
> 60654
>  test-amd64-i386-pair21 guest-migrate/src_host/dst_host fail like 
> 60654

As noted in 
http://lists.xen.org/archives/html/xen-devel/2015-09/msg00306.html these
three are regressions vs. 3.14 which the bisector has fingered with being
3a9ace0147d4 "tools/libxc+libxl+xl: Restore v2
streams".

linux-linux is also failing in what looks like the same manner.

We perhaps ought to consider whether we think "migration broken with newer
kernels" should be a blocker for 4.6.

The bisector was working on the linux-4.1, so ended up fingering the Xen
change which exposed the bug, since it didn't consider older kernels. I'm
going to see if I can engineer some adhoc runs which will cause the
bisector to instead try and find a commit between 3.18 and 4.1 which was
tickled by the Xen change, since I suspect that will be the actual
underlying buggy thing. If any one has any intuition on where to start
looking that might help speed things along...

Also, the fact these are "fail like " is a bit odd since the history[0]
shows this used to pass, hence a bad thing got pushed at some point.

59811 and 59837 correctly has them as "fail REGR. vs. 59393", 

59909 considered one of the three "fail like 59936-bisect" and the others
as "fail REGR. vs. 59393".

Then 59960 has two as "fail like NN-bisect" and one as "fail REGR. vs.
59393".

60030 is the "bad" push which uses "fail like NN-bisect" to justify
ignoring all three.

IIRC there was a bug in the osstest machinery (now fixed by Ian) which lead
to this, but I mention it in case I'm recalling incorrectly.

Ian.

[0] http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64
-i386-pair/linux-4.1.html

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

Re: [Xen-devel] [PATCH v6 10/31] xen/arm: ITS: Introduce gic_is_lpi helper function

[Julien Grall]

Hi,

On 03/09/2015 07:32, Vijay Kilari wrote:

On Tue, Sep 1, 2015 at 6:32 PM, Julien Grall  wrote:

On 01/09/15 12:56, Vijay Kilari wrote:

BTW, I suggested to create a field nr_lpis but you decided to store the
number of bits supported. Why?


I have nr_lpis field in vgic structure (patch #17). But it just tells
how LPIs are supported
for a domain.


Why are you speaking about vgic structure? I'm only suggesting to
replace you nr_id_bits by nr_lpis in the hw GIC. AFAICT, there is
nothing to prevent having 2 field using the same name on 2 differents
structure...


Where as nr_id_bits shows total number of  lpis that hw supports.


No nr_id_bits shows the total number of interrupt not LPIs. The total
number of LPIs is (1 << nr_id_bits) - 8092. Although (1 << nr_id_bits)
gives you the last LPI interrupt ID supported.

Anyway, as I said earlier, re-calculating the last LPI interrupt ID
everytime based on the shift is time consuming. You should optimize for
the common case rather than using copy the raw value (i.e ID bits) from
the HW directly.

Maybe the name "max_lpi_id" would make more sense to you for a name?


Instead of storing max_lpi_id which is ( 1 << nr_id_bits) - 8192, I prefer
to rename nr_id_bits as nr_irq_ids which can be initialized to (1 << nr_id_bits)
for gicv3 and gicv2_info.nr_lines for gicv2.


I'm fine with that.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [linux-4.1 test] 60785: tolerable FAIL - PUSHED

[Jan Beulich]

>>> On 03.09.15 at 11:47,  wrote:
> We perhaps ought to consider whether we think "migration broken with newer
> kernels" should be a blocker for 4.6.

I think we should, at least up until we're certain it's in fact a problem
in a Linux commit that simply got exposed by the tools side change.

Jan


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

Re: [Xen-devel] xhci_hcd intterrupt affinity in Dom0/DomU limited to single interrupt

[Jan Beulich]

(re-adding xen-devel)

>>> On 02.09.15 at 19:17,  wrote:
>   From: Jan Beulich 
>  Sent: Wednesday, September 2, 2015 4:58 AM
 Justin Acker  09/02/15 1:14 AM >>>
>> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
>> Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI])
>>Subsystem: Dell Device 053e
>>Flags: bus master, medium devsel, latency 0, IRQ 78
>>Memory at f7f2 (64-bit, non-prefetchable) [size=64K]
>>Capabilities: [70] Power Management version 2
>>Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
> 
> This shows that the driver could use up to 8 MSI IRQs, but chose to use just 
> one. If
> this is the same under Xen and the native kernel, the driver likely doesn't 
> know any
> better. If under native more interrupts are being used, there might be an 
> issue with
> Xen specific code in the kernel or hypervisor code. We'd need to see details 
> to be
> able to tell.
> 
> Please let me know what details I should provide. 
> 
> Jan

Please, first of all, get you reply style fixed. Just look at the above
and tell me how a reader should figure which parts of the text were
written by whom.

Together with other replies you sent, I first of all wonder whether
you've understood what you've been told: Any interrupt delivered
via the event channel mechanism can't be delivered to more than
one CPU unless it gets moved around them by a tool or manually.
When you set the affinity to more than on (v)CPU, the kernel will
pick one (usually the first) out of the provided set and bind the
event channel to that vCPU.

As to, in the XHCI case, using multi-vector MSI: Please tell use
whether the lspci output still left in context above was with a
kernel running natively or under Xen. In the former case, the
driver may need improving. In the latter case we'd need to see,
for comparison, the same output with a natively running kernel. If
it matches the Xen one, same thing (driver may need improving).
If it doesn't match, maximum verbosity hypervisor and kernel logs
would be what we'd need to start with.

Jan


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

[Xen-devel] [PATCH] libxl: report correct errno from virNetSocketNewConnectTCP on migration

[Ian Campbell]

saved_errno is never written to in this function after it is
initialised and it is only used to log the failure from
virNetSocketNewConnectTCP masking the real errno from that function.

Drop saved_errno and use errno itself.

Signed-off-by: Ian Campbell 
---
 src/libxl/libxl_migration.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 39e4a65..e291d71 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -480,7 +480,6 @@ libxlDomainMigrationPerform(libxlDriverPrivatePtr driver,
 virURIPtr uri = NULL;
 virNetSocketPtr sock;
 int sockfd = -1;
-int saved_errno = EINVAL;
 int ret = -1;
 
 /* parse dst host:port from uri */
@@ -496,7 +495,7 @@ libxlDomainMigrationPerform(libxlDriverPrivatePtr driver,
 if (virNetSocketNewConnectTCP(hostname, portstr,
   AF_UNSPEC,
   ) < 0) {
-virReportSystemError(saved_errno,
+virReportSystemError(errno,
  _("unable to connect to '%s:%s'"),
  hostname, portstr);
 goto cleanup;
-- 
2.1.4


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

Re: [Xen-devel] Kbuild and Kconfig

[Jan Beulich]

>>> On 02.09.15 at 19:50,  wrote:
> * target only the xen/ directory tree (i.e. not the toolstack, stubdoms
> or docs)

As just said in another reply, allowing for ./configure to pass down
options to the configure mechanism in xen/ would seem desirable (as
long as configuring in xen/ alone would still work).

> * split top level config bits to not affect xen/ tree (currently only
> XSM_ENABLE / FLASK_ENABLE do)

As already said by someone else, this shouldn't be necessary. In fact
I would hope there's (other than debug-build-or-not) no top level
setting affecting both tools and hypervisor.

> * convert xen/ to Kbuild first and merge this in (since Kconfig relies
> on Kbuild-y bits which can be undone but if we're going to go to Kbuild
> in the end why undo it and then redo it)

To be honest I'm not convinced we want to pull in Kbuild as a whole.
Achieving the ability to do out-of-tree builds (viewed as desirable
by Andrew, and I've also long been meaning to see whether this
could be made work, as that's also my preferred build setup in other
projects) should be possible without importing everything (and
perhaps even without importing anything).

Jan


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

[Xen-devel] [Patch V1 3/3] xen: add pvUSB backend

[Juergen Gross]

Add a backend for para-virtualized USB devices for xen domains.

The backend is using host-libusb to forward USB requests from a
domain via libusb to the real device(s) passed through.

Signed-off-by: Juergen Gross 
---
 hw/usb/Makefile.objs |4 +
 hw/usb/xen-usb.c | 1120 ++
 hw/xenpv/xen_machine_pv.c|3 +
 include/hw/xen/xen_backend.h |   13 +-
 4 files changed, 1137 insertions(+), 3 deletions(-)
 create mode 100644 hw/usb/xen-usb.c

diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
index 3fe4dff..0253184 100644
--- a/hw/usb/Makefile.objs
+++ b/hw/usb/Makefile.objs
@@ -36,3 +36,7 @@ common-obj-$(CONFIG_USB_REDIR) += redirect.o quirks.o
 
 # usb pass-through
 common-obj-y += $(patsubst %,host-%.o,$(HOST_USB))
+
+ifeq ($(CONFIG_USB_LIBUSB),y)
+common-obj-$(CONFIG_XEN_BACKEND) += xen-usb.o
+endif
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
new file mode 100644
index 000..2570bd7
--- /dev/null
+++ b/hw/usb/xen-usb.c
@@ -0,0 +1,1120 @@
+/*
+ *  xen paravirt usb device backend
+ *
+ *  (c) Juergen Gross 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; under version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ *
+ *  Contributions after 2012-01-13 are licensed under the terms of the
+ *  GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "qemu-common.h"
+#include "qemu/config-file.h"
+#include "hw/sysbus.h"
+#include "hw/usb.h"
+#include "hw/xen/xen_backend.h"
+#include "monitor/qdev.h"
+#include "qapi/qmp/qbool.h"
+#include "qapi/qmp/qint.h"
+#include "qapi/qmp/qstring.h"
+#include "sys/user.h"
+
+#include 
+#include 
+
+#define TR(fmt, args...)\
+{   \
+struct timeval tv;  \
+\
+gettimeofday(, NULL);\
+fprintf(stderr, "%8ld.%06ld xen-usb(%s):" fmt, tv.tv_sec,   \
+tv.tv_usec, __func__, ##args);  \
+}
+#define TR_REQ(fmt, args...) { if (tr_debug & 1) TR(fmt, ##args) }
+#define TR_BUS(fmt, args...) { if (tr_debug & 2) TR(fmt, ##args) }
+
+#define USBBACK_MAXPORTSUSBIF_PIPE_PORT_MASK
+#define USBBACK_DEVNAME_SIZE32
+#define USB_DEV_ADDR_SIZE   128
+
+struct usbif_ctrlrequest {
+uint8_tbRequestType;
+uint8_tbRequest;
+uint16_t   wValue;
+uint16_t   wIndex;
+uint16_t   wLength;
+};
+
+struct usbif_isoc_descriptor {
+uint32_t   offset;
+uint32_t   length;
+uint32_t   actual_length;
+int32_tstatus;
+};
+
+struct usbback_info;
+struct usbback_req;
+
+struct usbback_stub {
+USBDevice  *dev;
+USBPortport;
+unsigned   speed;
+bool   attached;
+QTAILQ_HEAD(submit_q_head, usbback_req) submit_q;
+};
+
+struct usbback_req {
+struct usbback_info  *usbif;
+struct usbback_stub  *stub;
+struct usbif_urb_request req;
+USBPacketpacket;
+
+unsigned int nr_buffer_segs; /* # of transfer_buffer segments 
*/
+unsigned int nr_extra_segs;  /* # of iso_frame_desc segments  
*/
+
+QTAILQ_ENTRY(usbback_req) q;
+
+void *buffer;
+void *isoc_buffer;
+struct libusb_transfer   *xfer;
+};
+
+struct usbback_info {
+struct XenDevice xendev;  /* must be first */
+USBBus   bus;
+void *urb_sring;
+void *conn_sring;
+struct usbif_urb_back_ring urb_ring;
+struct usbif_conn_back_ring conn_ring;
+int  num_ports;
+int  usb_ver;
+bool ring_error;
+QTAILQ_HEAD(req_free_q_head, usbback_req) req_free_q;
+struct usbback_stub  ports[USBBACK_MAXPORTS];
+struct usbback_stub  *addr_table[USB_DEV_ADDR_SIZE];
+QEMUBH   *bh;
+};
+
+static unsigned int tr_debug = 3;
+
+static void usbback_copy_buffer(struct usbback_req *usbback_req,
+struct usbif_isoc_descriptor *iso, bool out,
+unsigned len, unsigned off)
+{
+struct usbif_request_segment *seg;
+unsigned s, offset, copy_len, 

[Xen-devel] [Patch V1 1/3] xen: introduce dummy system device

[Juergen Gross]

Introduce a new dummy system device serving as parent for virtual
buses. This will enable new pv backends to introduce virtual buses
which are removable again opposed to system buses which are meant
to stay once added.

Signed-off-by: Juergen Gross 
---
 hw/xenpv/xen_machine_pv.c| 39 +++
 include/hw/xen/xen_backend.h |  1 +
 2 files changed, 40 insertions(+)

diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 2e545d2..57bc071 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -24,10 +24,15 @@
 
 #include "hw/hw.h"
 #include "hw/boards.h"
+#include "hw/sysbus.h"
 #include "hw/xen/xen_backend.h"
 #include "xen_domainbuild.h"
 #include "sysemu/block-backend.h"
 
+#define TYPE_XENSYSDEV "xensysdev"
+
+DeviceState *xen_sysdev;
+
 static void xen_init_pv(MachineState *machine)
 {
 const char *kernel_filename = machine->kernel_filename;
@@ -59,6 +64,9 @@ static void xen_init_pv(MachineState *machine)
 break;
 }
 
+xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
+qdev_init_nofail(xen_sysdev);
+
 xen_be_register("console", _console_ops);
 xen_be_register("vkbd", _kbdmouse_ops);
 xen_be_register("vfb", _framebuffer_ops);
@@ -93,6 +101,31 @@ static void xen_init_pv(MachineState *machine)
 xen_init_display(xen_domid);
 }
 
+static int xen_sysdev_init(SysBusDevice *dev)
+{
+return 0;
+}
+
+static Property xen_sysdev_properties[] = {
+{/* end of property list */},
+};
+
+static void xen_sysdev_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
+
+k->init = xen_sysdev_init;
+dc->props = xen_sysdev_properties;
+}
+
+static const TypeInfo xensysdev_info = {
+.name  = TYPE_XENSYSDEV,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(SysBusDevice),
+.class_init= xen_sysdev_class_init,
+};
+
 static QEMUMachine xenpv_machine = {
 .name = "xenpv",
 .desc = "Xen Para-virtualized PC",
@@ -101,9 +134,15 @@ static QEMUMachine xenpv_machine = {
 .default_machine_opts = "accel=xen",
 };
 
+static void xenpv_register_types(void)
+{
+type_register_static(_info);
+}
+
 static void xenpv_machine_init(void)
 {
 qemu_register_machine(_machine);
 }
 
+type_init(xenpv_register_types)
 machine_init(xenpv_machine_init);
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 3b4125e..911ba6d 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -59,6 +59,7 @@ struct XenDevice {
 extern XenXC xen_xc;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
+extern DeviceState *xen_sysdev;
 
 /* xenstore helper functions */
 int xenstore_write_str(const char *base, const char *node, const char *val);
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 2/2] cr-daily-branch: Make sg-report-flight ignore bisections

[Ian Jackson]

sg-report-flight when testing X' (with a baseline of X) can justify a
failure of T(X',Y,Z) with a bisection failure of T(X,Y'',Z).

If Y'' breaks T then this makes it look to sg-report-flight like T was
already broken in X; cr-daily-branch could then push X' even though it
is actually broken.

This happened rarely, because cr-daily-branch's sg-report-flight would
only look at flights on the right branch, so only a bisection of T on
that branch can cause this, but nevertheless this can produce bad
pushes.

So: have cr-daily-branch pass a --blessings option to cr-daily-branch,
so that it only looks at (usually) `real' rather than the default of
`real' and also `real-bisect'.

An alternative, more complicated, approach would be for
sg-report-flight to compare versions of Y, Z, et al, when looking for
justifications, but I'm not sure this is desirable because it would
effectively reset the heisenbug compensator each time any other tree
changed.

Signed-off-by: Ian Jackson 
---
 cr-daily-branch |1 +
 1 file changed, 1 insertion(+)

diff --git a/cr-daily-branch b/cr-daily-branch
index e90919d..e4c5532 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -76,6 +76,7 @@ case $branch in
 esac
 
 blessings_arg=--blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING}
+sgr_args+=" $blessings_arg"
 
 force_baseline=false
 skipidentical=true
-- 
1.7.10.4


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

[Xen-devel] [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices

[Juergen Gross]

When Xen is using the qemu usb framework for pure passthrough of I/Os
to host devices the handling of isoc jobs is rather complicated if
multiple isoc frames are transferred with one call.

Instead of calling the framework with each frame individually, using
timers to avoid polling in a loop and sampling all responses to
construct a sum response for the user, just add a capability to
use the libusb isoc framework instead. This capability is selected
via a device specific property.

When the property is selected the host usb driver will use xen specific
callbacks to signal the end of isoc I/Os. For now these callbacks will
just be nops, they'll be filled with sensible actions when the xen
pv-usb backend is being added.

Signed-off-by: Juergen Gross 
---
 hw/usb/core.c| 11 ++
 hw/usb/host-libusb.c | 51 ++--
 include/hw/xen/xen_backend.h |  3 +++
 3 files changed, 55 insertions(+), 10 deletions(-)

diff --git a/hw/usb/core.c b/hw/usb/core.c
index cf34755..ed2255c 100644
--- a/hw/usb/core.c
+++ b/hw/usb/core.c
@@ -427,10 +427,13 @@ void usb_handle_packet(USBDevice *dev, USBPacket *p)
 if (QTAILQ_EMPTY(>ep->queue) || p->ep->pipeline || p->stream) {
 usb_process_one(p);
 if (p->status == USB_RET_ASYNC) {
-/* hcd drivers cannot handle async for isoc */
-assert(p->ep->type != USB_ENDPOINT_XFER_ISOC);
-/* using async for interrupt packets breaks migration */
-assert(p->ep->type != USB_ENDPOINT_XFER_INT ||
+/*
+ * hcd drivers cannot handle async for isoc.
+ * Using async for interrupt packets breaks migration.
+ * Host devices are okay in any case.
+ */
+assert((p->ep->type != USB_ENDPOINT_XFER_ISOC &&
+p->ep->type != USB_ENDPOINT_XFER_INT) ||
(dev->flags & (1 << USB_DEV_FLAG_IS_HOST)));
 usb_packet_set_state(p, USB_PACKET_ASYNC);
 QTAILQ_INSERT_TAIL(>ep->queue, p, queue);
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index a5f9dab..ce644c3 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -42,6 +42,7 @@
 #include "trace.h"
 
 #include "hw/usb.h"
+#include "hw/xen/xen_backend.h"
 
 /*  */
 
@@ -64,6 +65,7 @@ struct USBAutoFilter {
 
 enum USBHostDeviceOptions {
 USB_HOST_OPT_PIPELINE,
+USB_HOST_XEN_ISO_PASSTHROUGH,
 };
 
 struct USBHostDevice {
@@ -152,6 +154,7 @@ static void usb_host_attach_kernel(USBHostDevice *s);
 #define CONTROL_TIMEOUT  1/* 10 sec*/
 #define BULK_TIMEOUT 0/* unlimited */
 #define INTR_TIMEOUT 0/* unlimited */
+#define ISO_TIMEOUT  0/* unlimited */
 
 #if LIBUSBX_API_VERSION >= 0x01000103
 # define HAVE_STREAMS 1
@@ -306,14 +309,14 @@ static bool usb_host_use_combining(USBEndpoint *ep)
 /*  */
 
 static USBHostRequest *usb_host_req_alloc(USBHostDevice *s, USBPacket *p,
-  bool in, size_t bufsize)
+  bool in, size_t bufsize, int packets)
 {
 USBHostRequest *r = g_new0(USBHostRequest, 1);
 
 r->host = s;
 r->p = p;
 r->in = in;
-r->xfer = libusb_alloc_transfer(0);
+r->xfer = libusb_alloc_transfer(packets);
 if (bufsize) {
 r->buffer = g_malloc(bufsize);
 }
@@ -376,6 +379,29 @@ out:
 }
 }
 
+static void usb_host_req_complete_iso_xen(struct libusb_transfer *xfer)
+{
+USBHostRequest *r = xfer->user_data;
+USBHostDevice  *s = r->host;
+bool disconnect = (xfer->status == LIBUSB_TRANSFER_NO_DEVICE);
+
+if (r->p == NULL) {
+goto out; /* request was canceled */
+}
+
+r->p->status = status_map[xfer->status];
+trace_usb_host_req_complete(s->bus_num, s->addr, r->p,
+r->p->status, r->p->actual_length);
+/* copying of buffer is done in complete callback of xen */
+usb_packet_complete(USB_DEVICE(s), r->p);
+
+out:
+usb_host_req_free(r);
+if (disconnect) {
+usb_host_nodev(s);
+}
+}
+
 static void usb_host_req_complete_data(struct libusb_transfer *xfer)
 {
 USBHostRequest *r = xfer->user_data;
@@ -1226,7 +1252,7 @@ static void usb_host_handle_control(USBDevice *udev, 
USBPacket *p,
 }
 }
 
-r = usb_host_req_alloc(s, p, (request >> 8) & USB_DIR_IN, length + 8);
+r = usb_host_req_alloc(s, p, (request >> 8) & USB_DIR_IN, length + 8, 0);
 r->cbuf = data;
 r->clen = length;
 memcpy(r->buffer, udev->setup_buf, 8);
@@ -1264,7 +1290,7 @@ static void usb_host_handle_data(USBDevice *udev, 
USBPacket *p)
 USBHostDevice *s = USB_HOST_DEVICE(udev);
 USBHostRequest *r;
 size_t size;
-int ep, rc;
+int ep, rc, packets;
 
 if 

[Xen-devel] [OSSTEST PATCH 1/2] cr-daily-branch: Break out blessings_arg variable

[Ian Jackson]

And rewrap check_tested.

No functional change.

Signed-off-by: Ian Jackson 
---
 cr-daily-branch |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cr-daily-branch b/cr-daily-branch
index 7402d3f..e90919d 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -75,14 +75,14 @@ case $branch in
treeurl=`./ap-print-url $branch`;;
 esac
 
+blessings_arg=--blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING}
+
 force_baseline=false
 skipidentical=true
 wantpush=$OSSTEST_PUSH
 
 check_tested () {
-   ./sg-check-tested --debug --branch=$branch \
- --blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING} \
- "$@"
+   ./sg-check-tested --debug --branch=$branch $blessings_arg "$@"
 }
 
 if [ "x$OLD_REVISION" = x ]; then
-- 
1.7.10.4


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

Re: [Xen-devel] [OSSTEST PATCH 05/13] Planner: client side: $mayalloc parameter to $resourcecall->()

[Ian Campbell]

On Wed, 2015-09-02 at 16:45 +0100, Ian Jackson wrote:
> Add a new parameter to $resourcecall which allows the alloc_resources
> loop in Osstest::Executive to specify to its clients that on this
> occasion they should not make any actual allocations.
> 
> The callers of alloc_resources are all adjusted to honour this new
> parameter:
>  * ts-hosts-allocate-Executive avoids allocating unless $mayalloc
>  * mg-allocate avoids allocating unless $mayalloc
>  * mg-blockage never allocates anyway.
> 
> Currently we always pass 1, so no functional change.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


> ---
>  Osstest/Executive.pm|4 ++--
>  mg-allocate |4 ++--
>  mg-blockage |2 +-
>  ts-hosts-allocate-Executive |4 ++--
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
> index ab015d2..f9be0a0 100644
> --- a/Osstest/Executive.pm
> +++ b/Osstest/Executive.pm
> @@ -604,7 +604,7 @@ sub plan_search () {
>  }
>  
>  sub alloc_resources {
> -my ($resourcecall) = pop @_; # $resourcecall->($plan);
> +my ($resourcecall) = pop @_; # $resourcecall->($plan, $mayalloc);
>  my (%xparams) = @_;
>  # $resourcecall should die (abort) or return ($ok, $bookinglist)
>  #
> @@ -720,7 +720,7 @@ sub alloc_resources {
>   $plan= from_json($jplan);
>   }, sub {
>   if (!eval {
> - ($ok, $bookinglist) = $resourcecall->($plan);
> + ($ok, $bookinglist) = $resourcecall->($plan, 1);
>   1;
>   }) {
>   warn "resourcecall $@";
> diff --git a/mg-allocate b/mg-allocate
> index fc1b394..6dc7ddd 100755
> --- a/mg-allocate
> +++ b/mg-allocate
> @@ -270,7 +270,7 @@ sub showposs ($) {
>  sub plan () {
>  my @got;
>  alloc_resources(sub {
> -my ($plan) = @_;
> +my ($plan, $mayalloc) = @_;
>  
>   @got = ();
>  my @possmatrix = ([]);
> @@ -310,7 +310,7 @@ sub plan () {
>   die unless $planned;
>  
>  my $allok=0;
> -if (!$planned->{Start}) {
> +if ($mayalloc && !$planned->{Start}) {
>  $allok=1;
>  
>  alloc_prep();
> diff --git a/mg-blockage b/mg-blockage
> index a21f15b..1f66d8e 100755
> --- a/mg-blockage
> +++ b/mg-blockage
> @@ -40,7 +40,7 @@ sub max { (reverse sort @_)[0]; }
>  
>  sub plan () {
>  alloc_resources(sub {
> - my ($plan) = @_;
> + my ($plan, $mayalloc) = @_;
>  
>   my $now = time;
>   if ($now > $end) { return (1, { Bookings => [ ] }); }
> diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
> index 7a9411d..6e1391e 100755
> --- a/ts-hosts-allocate-Executive
> +++ b/ts-hosts-allocate-Executive
> @@ -606,7 +606,7 @@ sub alloc_hosts () {
>  }
>  
>  sub attempt_allocation {
> -($plan) = @_;
> +($plan, $mayalloc) = @_;
>  undef $best;
>  
>  logm("allocating hosts: ".join(' ', map { $_->{Ident} } @hids));
> @@ -632,7 +632,7 @@ sub attempt_allocation {
>  
>  my $retval=0;
>  
> -if (!$best->{Start}) {
> +if ($mayalloc && !$best->{Start}) {
>   $retval= 1;
>   foreach my $hid (@hids) {
>   my $got= actual_allocation($hid);

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

Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - PUSHED

[Ian Campbell]

On Thu, 2015-09-03 at 00:38 -0600, Jim Fehlig wrote:
> AFAICT, this error means the source libvirtd cannot open a tcp connection to 
> the 
> destination libvirtd during the 'perform' phase of migration. In the 
> preceding 
> 'prepare' phase, the destination libvirtd opened a socket to listen for the 
> incoming migration, and passed the connection details back to the source 
> libvirtd. The connection details (hostname:port) are generated on the 
> destination libvirtd with
> 
> virGetHostname():virPortAllocatorAcquire()
> 
> virPortAllocatorAcquire() grabs the next available port in a range of ports. 
> virGetHostName() attempts to get the FQDN of the host
> 
> http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virutil.c;h=cddc78a700c12a4f786a1f6544b92b8ee19c85f5;hb=HEAD#l632
>
> Seems the source libvirtd cannot connect to the hostname:port created by the 
> destination libvirtd.

Indeed. I've now got two boxes setup to do this and in the libvirtd.log of
the source host I see:

2015-09-03 10:03:56.154+: 3440: error : virNetSocketNewConnectTCP:578 : 
unable to connect to server at 'lace-bug.xs.citrite.net:49154': Connection 
refused
2015-09-03 10:03:56.154+: 3440: error : libxlDomainMigrationPerform:501 : 
unable to connect to 'lace-bug.xs.citrite.net:49154': Invalid argument

It seems like libxlDomainMigrationPerform is clobbering the errno from
virNetSocketNewConnectTCP. I sent a patch for that:

http://lists.xen.org/archives/html/xen-devel/2015-09/msg00320.html

Looking further at the test failure on the destination host I see:

2015-09-03 10:03:56.133+: 3463: info : virNetSocketNew:277 : 
RPC_SOCKET_NEW: sock=0x7fbb768807a0 fd=28 errfd=-1 pid=0 
localAddr=127.0.1.1;49154, remoteAddr=

Notice that it has bound to 127.0.1.1 and not to 10.80.228.77!

I suspect this is down to:

root@lace-bug:/etc/libvirt# cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   lace-bug.xs.citrite.net lace-bug

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

And in particular the line associating 127.0.1.1 with lace
-bug.xs.citrite.net.

This seems to be a Debian thing, possibly the installer I'm not sure.

https://lists.debian.org/debian-devel/2013/07/msg00809.html looks relevant.

Overall I'm not sure what to do here. The Debian config seems a bit odd,
but I'm not sure if it is actually "wrong". OTOH I'm not sure how libvirt
could be changed to work in this scenario.

Ian.

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

[Xen-devel] [3.16.y-ckt stable] Patch "x86/ldt: Make modify_ldt synchronous" has been added to staging queue

[Luis Henriques]

This is a note to let you know that I have just added a patch titled

x86/ldt: Make modify_ldt synchronous

to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree 
which can be found at:

http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.16.y-queue

This patch is scheduled to be released in version 3.16.7-ckt17.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.16.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

--

>From b29f804421c40778a4858c428746a899f934d67c Mon Sep 17 00:00:00 2001
From: Andy Lutomirski 
Date: Thu, 30 Jul 2015 14:31:32 -0700
Subject: x86/ldt: Make modify_ldt synchronous

commit 37868fe113ff2ba814b3b4eb12df214df555f8dc upstream.

modify_ldt() has questionable locking and does not synchronize
threads.  Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.

This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.

This fixes some fallout from the CVE-2015-5157 fixes.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Cc: Andrew Cooper 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sasha Levin 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: secur...@kernel.org 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/4c6978476782160600471bd865b318db34c7b628.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
[ luis: backported to 3.16:
  - dropped changes to comments in switch_mm()
  - included asm/mmu_context.h in perf_event.c
  - adjusted context ]
Signed-off-by: Luis Henriques 
---
 arch/x86/include/asm/desc.h|  15 ---
 arch/x86/include/asm/mmu.h |   3 +-
 arch/x86/include/asm/mmu_context.h |  48 ++-
 arch/x86/kernel/cpu/common.c   |   4 +-
 arch/x86/kernel/cpu/perf_event.c   |  13 +-
 arch/x86/kernel/ldt.c  | 262 -
 arch/x86/kernel/process_64.c   |   4 +-
 arch/x86/kernel/step.c |   6 +-
 arch/x86/power/cpu.c   |   3 +-
 9 files changed, 208 insertions(+), 150 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index a94b82e8f156..69126184c609 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
 }

-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
-   set_ldt(pc->ldt, pc->size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
-   preempt_disable();
-   load_LDT_nolock(pc);
-   preempt_enable();
-}
-
 static inline unsigned long get_desc_base(const struct desc_struct *desc)
 {
return (unsigned)(desc->base0 | ((desc->base1) << 16) | ((desc->base2) 
<< 24));
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 876e74e8eec7..b6b7bc3f5d26 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
  * we put the segment information here.
  */
 typedef struct {
-   void *ldt;
-   int size;
+   struct ldt_struct *ldt;

 #ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index be12c534fd59..86fef96f4eca 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -16,6 +16,50 @@ static inline void paravirt_activate_mm(struct mm_struct 
*prev,
 #endif /* !CONFIG_PARAVIRT */

 /*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+   /*
+* Xen requires page-aligned LDTs with special permissions.  This is
+* needed to prevent us from installing evil descriptors such as
+* call gates.  On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+   struct desc_struct *entries;
+   int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+   struct ldt_struct *ldt;
+
+   /* lockless_dereference synchronizes with 

Re: [Xen-devel] [Vote] Re-open staging for contributions at RC3

[Lars Kurth]

> On 3 Sep 2015, at 10:15, Ian Campbell  wrote:
> 
> On Wed, 2015-09-02 at 17:12 +0100, Lars Kurth wrote:
>> Hi all,
>> 
>> I wanted to kick off a vote related to the following threads
>> * http://lists.xenproject.org/archives/html/xen-devel/2015
>> -08/msg00883.html - [URGENT RFC] Branching and reopening -unstable
>> * http://lists.xenproject.org/archives/html/xen-devel/2015
>> -08/msg00543.html - [xen 4.6 retrospective] [urgent] rename "freeze" 
>> window and make release branch as soon as possible after RC1
>> 
>> Although there was no consensus in the general case to say we should 
>> always branch at RC-x at any given release, there seems to be enough 
>> consensus for branching earlier, given a number of conditions are met:
>> 
>> In particular:
>> 1: We should not re-open staging too early (aka we would need to get a 
>> sense how much churn to expect)
>> 2: Maybe we should not accept major re-factoring and leave it up to the 
>> discretion of thy maintainers to do so - aka Ian Jackson's option B. But 
>> there seems to be some disagreement around it. 
>> 
>> 2.1: Some maintainers are concerned that they would have to deal with 
>> backporting, if we re-opened early.
>> 
>> 2.2: A sensible compromise seems to me for the maintainer to evaluate 
>> whether a patch is ready to go in after RC3: if there is an amount of 
>> back porting that the maintainer can't deal with, it is IMHO OK for the 
>> maintainer to let the contributor know and give him/her the option to 
>> provide a patch for two trees as it is customary in Linux OR to wait 
>> until the ongoing release is out. This is a slight variant of Ian 
>> Jackson's option B in http://lists.xenproject.org/archives/html/xen
>> -devel/2015-08/msg00883.html ;
>> 
>> Of course, 1 will minimise the amount of incidents for 2
>> 
>> = VOTE =  
>> With that in mind: please vote on
>> A) Do we think 4.6 is in a good enough state to branch at the next RC 
>> (which would be RC3)
> 
> IMHO this decision should be the Release Managers to make. I'm not sure how
> to vote to express that, so I suppose I'll abstain.
> 
> Since I'm sure the RM would want input from maintainers to help them make
> this decision I'll note that my opinion (not vote) is that the tree is
> indeed in a good enough state to branch.

I am happy with Wei making that decision. But we chatted on IRC yesterday, and 
my interpretation of that conversation was that because of B) which is really a 
policy decision and because A) was raised specifically as an objection to Wei's 
earlier RFC, it would make sense to at least highlight this issue.  

>> B) Do we have enough consensus given that there is some disagreement on 
>> how to deal with back-porting. In other words, does the proposal 2.2 
>> above look sensible. 
> 
> It's not clear to me which branch "ready to go in after RC3" refers to, the
> reopened staging or the newly branched 4.6 branch?
> 
> If the proposal is to ask maintainers to use their discretion when applying
> things to staging, i.e. taking the possible need to do backports (of
> subsequent patches) to the 4.6 branch and/or asking for help with backports
> from the submitters of patches which need it then that gets +1 from me.

That's what I meant

> 
> Ian.


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

Re: [Xen-devel] [OSSTEST PATCH 01/13] Tcl: Use lshift instead of open-coding with lrange

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTEST PATCH 01/13] Tcl: Use lshift instead of 
open-coding with lrange"):
> Acked-by: Ian Campbell 
> 
> (Caveat: I don't speak a lot of tcl, but seems plausible. Same caveat for
> all tcl patches here...)

Thanks...

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 03/13] Planner: docs: Document set-info command

[Ian Campbell]

On Wed, 2015-09-02 at 16:45 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - PUSHED

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - 
PUSHED"):
...
> I suspect this is down to:
> 
> root@lace-bug:/etc/libvirt# cat /etc/hosts
> 127.0.0.1 localhost
> 127.0.1.1 lace-bug.xs.citrite.net lace-bug

This is simply wrong.  It means that when programs on the host try to
find the host's own IP address starting with its host name, they get
different (and wrong) answers to programs on other hosts.

I can see why D-I wants to do this but in our setup it is simply
entirely wrong.  Is there a way to suppress this (from preseed
maybe) ?

> Overall I'm not sure what to do here. The Debian config seems a bit odd,
> but I'm not sure if it is actually "wrong". OTOH I'm not sure how libvirt
> could be changed to work in this scenario.

It might be possible to work around this in libvirt, but this is by no
means libvirt's fault.

Ian.

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

Re: [Xen-devel] [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2

[David Vrabel]

On 03/09/15 12:05, Luis Henriques wrote:
> On Wed, Sep 02, 2015 at 10:18:32AM +0100, Ian Campbell wrote:
>> [resending to correct stable address, sorry folks]
>>
>> TL;DR: Any backport of 30b03d05e074 to earlier than commit 1401c00e59e
>> ("xen/gntdev: convert priv->lock to a mutex", which was added in v4.0)
>> needs $something doing to it, either s/mutex/spinlock/ or (more likely)
>> backporting of 1401c00e59e too.
>>
>> Looking at LTS:
>>
>> 3.18.y:Backported both.
>> 3.16.y:Has backported neither
>> 3.14.y:  * Only backported 30b03d05e074
>> 3.12.y:Has backported neither
>> 3.10.y:  * Only backported 30b03d05e074
>> 3.4.y: Has backported neither
>> 3.2.y: Has backported neither
>>
>> So AFAICT 3.14.y and 3.10.y need fixes, probably following 3.18 and
>> backporting 1401c00e59e.
>>
>> 3.16/12/4/2 might need to be careful if they subsequently pick up 30b03d05.
>>
> 
> Thank you Ian.  In fact, I had explicitly dropped 30b03d05e074
> ("xen/gntdevt: Fix race condition in gntdev_release()") from the 3.16
> kernel and notified stable maintainers about this problem (in a reply to a
> 3.12 review email).
> 
> Simply replacing the mutex by the spinlock in this commit seems to cause
> problems (sleep in atomic) as pointed out by Jiri in other thread.
> 
> Since 1401c00e59ea ("xen/gntdev: convert priv->lock to a mutex") is a
> clean cherry-pick for 3.16 (and probably to older kernels as well), I'm
> happy to pick both commits if you can confirm they are both good for older
> stable kernels (they seem to be!)

You can take both 1401c00e59ea and 30b03d05e074.

David

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

[Xen-devel] [OSSTEST PATCH 14/13] Planning reports: Break out return-plan-to-client

[Ian Jackson]

We are going to want to reuse this.  No functional change.

Signed-off-by: Ian Jackson 
---
 ms-queuedaemon |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/ms-queuedaemon b/ms-queuedaemon
index 425b98f..222b687 100755
--- a/ms-queuedaemon
+++ b/ms-queuedaemon
@@ -354,11 +354,16 @@ proc cmd/thought-done {chan desc} {
 puts-chan $chan "OK thought"
 }
 
+proc return-plan-to-client {chan wf} {
+set tplan [exec -keepnewline ./ms-planner -w$wf get-plan < /dev/null]
+puts-chan-data $chan "OK get-plan" $tplan
+return $tplan
+}
+
 proc cmd/get-plan {chan desc} {
 global plan
 set w [check-we-are-thinking $chan]
-set plan [exec -keepnewline ./ms-planner -w$w get-plan < /dev/null]
-puts-chan-data $chan "OK get-plan" $plan
+set plan [return-plan-to-client $chan $w]
 }
 
 proc cmd/book-resources {chan desc bytes} {
-- 
1.7.10.4


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