[Xen-devel] [xen-unstable test] 100751: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt  3 host-install(3) broken in 100748 pass in 100751
 test-armhf-armhf-xl7 host-ping-check-xen fail in 100748 pass in 100751
 test-armhf-armhf-xl-multivcpu  6 xen-boot  fail pass in 100748

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100748
 build-i386-rumpuserxen6 xen-buildfail  like 100748
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100748
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100748
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100748
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100748
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100748

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

version targeted for testing:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100751  2016-09-05 01:59:33 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17049 days0 attempts

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

Re: [Xen-devel] [PATCH 2/5] gcov: collect more sections to constructor list

[Julien Grall]

Hi Wei,

On 02/09/2016 12:47, Wei Liu wrote:

The version of gcc (4.9.2) I use put constructors into .init_array*
section(s). Collect those sections into constructor list as well.

Modify both arm and x86 scripts to keep them in sync.


With Jan's comment handled:

Acked-by: Julien Grall 

Regards,



Signed-off-by: Wei Liu 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/arm/xen.lds.S | 2 ++
 xen/arch/x86/xen.lds.S | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index b24e93b..13a 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -166,6 +166,8 @@ SECTIONS

. = ALIGN(8);
__ctors_start = .;
+   *(.ctors)
+   *(SORT(.init_array.*))
*(.init_array)
__ctors_end = .;
   } :text
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 67cfda1..8957efd 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -205,6 +205,8 @@ SECTIONS
. = ALIGN(8);
__ctors_start = .;
*(.ctors)
+   *(SORT(.init_array.*))
+   *(.init_array)
__ctors_end = .;
   } :text




--
Julien Grall

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

[Xen-devel] [distros-debian-sid test] 67637: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 67603
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 67603
 test-amd64-amd64-i386-sid-netboot-pygrub  9 debian-di-install  fail like 67603
 test-armhf-armhf-armhf-sid-netboot-pygrub  9 debian-di-install fail like 67603
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 67603

baseline version:
 flight   67603

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



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
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 10/38] arm/p2m: Move hostp2m init/teardown to individual functions

[Sergej Proskurin]

Hi Julien,


On 09/02/2016 12:51 PM, Julien Grall wrote:
>
>
> On 02/09/16 10:09, Sergej Proskurin wrote:
>> Hi Julien,
>>
>> On 09/01/2016 07:36 PM, Julien Grall wrote:
>>> Hello Sergej,
>>>
>>> On 16/08/16 23:16, Sergej Proskurin wrote:
 ---
  xen/arch/arm/p2m.c| 71
 +--
  xen/include/asm-arm/p2m.h | 11 
  2 files changed, 73 insertions(+), 9 deletions(-)

 diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
 index e859fca..9ef19d4 100644
 --- a/xen/arch/arm/p2m.c
 +++ b/xen/arch/arm/p2m.c
 @@ -1245,27 +1245,53 @@ static void p2m_free_vmid(struct domain *d)
  spin_unlock(_alloc_lock);
  }

 -void p2m_teardown(struct domain *d)
 +/* Reset this p2m table to be empty. */
 +void p2m_flush_table(struct p2m_domain *p2m)
  {
 -struct p2m_domain *p2m = p2m_get_hostp2m(d);
 -struct page_info *pg;
 +struct page_info *page, *pg;
 +unsigned int i;
 +
 +if ( p2m->root )
 +{
 +page = p2m->root;
 +
 +/* Clear all concatenated first level pages. */
>>>
>>> s/first/root/
>>>
>>
>> Ok.
>>
 +for ( i = 0; i < P2M_ROOT_PAGES; i++ )
 +clear_and_clean_page(page + i);
>>>
>>> Clearing live page table like that is not safe. Each entry (64-bit)
>>> should be written atomically to avoid breaking coherency (e.g if the
>>> MMU
>>> is walking the page table at the same time). However you don't know the
>>> implementation of clear_and_clean_page.
>>
>> The function p2m_flush_table gets called by the altp2m subsystem
>> indrectly through the function p2m_teardown_one when the associated view
>> gets destroyed. In this case we should not worry about crashing the
>> domain, as the altp2m views are not active anyway.
>>
>> The function altp2m_reset calls the function p2m_flush_table directly
>> (with active altp2m views), however, locks the p2m before flushing the
>> table. I did not find any locks on page-granularity, so please provide
>> me with further information about the solution you had in mind.
>
> I never mentioned any locking problem. As said in my previous mail,
> the altp2m may still be in use by another vCPU. So the MMU (i.e the
> hardware) may want do a table walk whilst you modify the entry.
>
> The MMU is reading the entry (64-bit) at once so it also expects the
> entry to be modified atomically. However, you don't know the
> implementation of clean_and_clean_page. The function might write
> 32-bit at the time, which means that the MMU will see bogus entry. At
> best it will lead to a crash, at worst open a security issue.
>

I see your point. Not sure how to fix this, though. I believe that the
described issue would remain if we would use free_domheap_pages.
Instead, maybe we should manually set the value in the translation tables?

Or, what if we flush the TLBs immediately before unmapping the root
pages? This would cause the system to load the mappings from memory and
delay a MMU table walk so that it would potentially resolve the
atomicity issue.

Do you have another suggestion?

>>>
>>> Also, this adds a small overhead when tearing down a p2m because the
>>> clear is not necessary.
>>>
>>
>> The p2m views are cleared very rarely so the overhead is really minimal
>> as it affects clearing the root tables.
>
> You seem to forget the p2m teardown is also called during domain
> destruction.
>
>> Besides the function
>> altp2m_reset calls the function p2m_flush_table and assumes that the
>> root tables are cleared as well. If the root tables would not be cleared
>> at this point, stalled entries in the altp2m views that got wiped out in
>> the hostp2m would make the system unstable.
>
> As I already mentioned in the previous version, this code was not
> present before and based of the description of this commit the patch
> is supposed to only move code around. This is not the case here.
>

I will move the part with the clear_and_clean_page invocation into a
separate patch.

>

  radix_tree_destroy(>mem_access_settings, NULL);
  }

 -int p2m_init(struct domain *d)
 +int p2m_init_one(struct domain *d, struct p2m_domain *p2m)
  {
 -struct p2m_domain *p2m = p2m_get_hostp2m(d);
  int rc = 0;

  rwlock_init(>lock);
 @@ -1278,11 +1304,14 @@ int p2m_init(struct domain *d)
  return rc;

  p2m->max_mapped_gfn = _gfn(0);
 -p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
 +p2m->lowest_mapped_gfn = INVALID_GFN;
>>>
>>> Why this change?
>>>
>>
>> Since we compare the gfn's with INVALID_GFN throughout the code it makes
>> sense to use the macro instead of a hardcoded value.
>
> Please don't do unnecessary change. This patch is complex enough to
> review.

Ok.

Cheers,
~Sergej


___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Ian Jackson]

Wei Liu writes ("Re: [PATCH] libxl: do not assume Dom0 backend while getting 
nic info"):
> On Mon, Sep 05, 2016 at 11:44:46AM +0200, Marek Marczykowski-Górecki wrote:
> > Yes, certainly. If you want I can send a 4.7 version (function is in
> > libxl.c there).

Thanks for the backport.

Wei, can you mail me here (or tell me on irc) when the unstable fix
goes into staging ?

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Juergen Gross]

On 05/09/16 12:32, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH] libxl: add "xl qemu-monitor-command""):
>> Add a new xl command "qemu-monitor-command" to issue arbitrary commands
>> to a domain's device model. Syntax is:
>>
>> xl qemu-monitor-command  
>>
>> The command is issued via qmp human-monitor-command command. Any
>> information returned by the command is printed to stdout.
> ...
>> +=item B I I
>> +
>> +Issue a monitor command to the device model of the domain specified by
>> +I. I can be any valid command qemu understands. This
>> +can be e.g. used to add non-standard devices or devices with non-standard
>> +parameters to a domain. The output of the command is printed to stdout.
> 
> This needs some kind of health warning.  Something like:
> 
>  Warning: This qemu monitor access is provided for convenience when
>  debugging, troubleshooting, and experimenting.  Its use is not
>  supported by the Xen Project.
> 
>  Specifically, not all information printed by the qemu monitor will
>  necessarily be accurate or complete, because in a Xen system qemu
>  does not have a complete view of the guest.
> 
>  Furthermore, modifying the guest's setup via the qemu monitor may
>  conflict with the Xen toolstack's assumptions.  Resulting problems
>  may include, but are not limited to: guest crashes; toolstack error
>  messages; inability to migrate the guest; and security
>  vulnerabilities which are not covered by the Xen Project security
>  response policy.

Thanks for the complete text! I'll add it to the man page.

> The rest of the documentation will need adjusting.  As an example of
> the incompleteness I am talking about I think the example shows only
> some of the USB devices presented to the guest.

Hmm, I think the statement:

+Obtain information of USB devices connected via the device model to a
+domain:

is absolutely correct. Which USB devices connected via the device model
won't be shown?


Juergen

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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[Jan Beulich]

>>> On 05.09.16 at 13:19,  wrote:
> On 2016-09-05 12:25, Jan Beulich wrote:
>> Anyway - with you quite clearly having used HAP before, I can't
>> see how this commit would matter for you at all. In case you want
>> to double check you could try with a hypervisor built without
>> shadow paging code (which we've been allowing for quite a
>> while).
> 
> I just tried that and without shadow paging code the guest boots fine, 
> so that's interesting.

Indeed. Was that try with plain staging/master, or with much of
the reverts in place (from the bisection)? It seems to me that
investigating this odd difference would perhaps be a better
route than trying to guess what's wrong with said commit.

Jan


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

Re: [Xen-devel] [PATCH v5 12/16] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 20.08.16 at 00:43,  wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -103,9 +103,56 @@ static void __init relocate_trampoline(unsigned long 
> phys)
>  *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
>  }
>  
> +#define EBMALLOC_SIZEMB(1)
> +
> +static char __section(".bss.page_aligned") ebmalloc_mem[EBMALLOC_SIZE];

You need to specify the alignment of the object (using the relatively
new __aligned() construct).

> +static char __initdata *ebmalloc_free = NULL;
> +
> +/* EFI boot allocator. */
> +static void __init *ebmalloc(size_t size)
> +{
> +void *ptr;
> +
> +/*
> + * Init ebmalloc_free on runtime. Static initialization
> + * will not work because it puts virtual address there.
> + */

I don't understand this static allocation comment: We have this issue
elsewhere (and use bootsym() as needed), and we do not have this
issue at all in xen.efi (which this code also gets built for). So I think at
the very least the comment needs improvement. And then, if static
initialization indeed can't be used, then a static symbol's initializer of
NULL is pointless and hence should be omitted.

> +if ( ebmalloc_free == NULL )
> +ebmalloc_free = ebmalloc_mem;
> +
> +ptr = ebmalloc_free;
> +
> +ebmalloc_free += size;

No minimal (at least pointer size) alignment getting enforced
somewhere here?

> +void __init free_ebmalloc_unused_mem(void)
> +{
> +unsigned long start, end;
> +
> +if ( ebmalloc_free )
> +{
> +start = (unsigned long)ebmalloc_free - xen_phys_start;
> +start = PAGE_ALIGN(start + XEN_VIRT_START);
> +}
> +else
> +start = (unsigned long)ebmalloc_mem;
> +
> +end = (unsigned long)ebmalloc_mem + sizeof(ebmalloc_mem);
> +
> +destroy_xen_mappings(start, end);
> +init_xenheap_pages(__pa(start), __pa(end));
> +
> +printk("Freed %lukB unused BSS memory\n", (end - start) >> 10);

XENLOG_INFO

And then - wouldn't this better go into xen/common/efi/boot.c,
even if ARM64 does not have a use for it right away? The code
certainly isn't really x86-specific.

Jan


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

[Xen-devel] [xen-unstable-smoke test] 100755: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386  6 xen-boot fail REGR. vs. 100736
 test-amd64-amd64-libvirt  6 xen-boot fail REGR. vs. 100736

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  7539772a65b044f326ebf9528bd40e7c6a78c540
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100736  2016-09-02 16:03:32 Z2 days
Testing same since   100755  2016-09-05 11:01:49 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  He Chen 
  Ian Jackson 
  Jan Beulich 
  Luwei Kang 
  Marek Marczykowski-Górecki 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 7539772a65b044f326ebf9528bd40e7c6a78c540
Author: Marek Marczykowski-Górecki 
Date:   Mon Sep 5 11:26:04 2016 +0200

libxl: do not assume Dom0 backend while getting nic info

Fill backend_domid field based on backend path.

Cc: Ian Jackson 
Cc: Wei Liu 
Signed-off-by: Marek Marczykowski-Górecki 
Acked-by: Wei Liu 

commit b2f2ced591060588a45cdc7881a7335ba42b9cc5
Author: Wei Liu 
Date:   Mon Sep 5 11:36:45 2016 +0100

tools/firmware: Rename bios.bin to seabios.bin

bios.bin as a name is far too generic.  Rename it to seabios.bin.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
[ wei: fix up conflict, rerun autogen.sh ]
Signed-off-by: Wei Liu 

commit eb502cb30cc5af309ed824da024014afca1d0fcf
Author: Wei Liu 
Date:   Mon Sep 5 10:21:28 2016 +0100

libxl: update flex output files for DSA 3653-2

We updated flex output files in 4b314c89 ("libxl: update flex output
files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
discovered the fix to flex was incomplete and issued DSA 3653-2. We need
to update our flex output files accordingly.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 5fdea6577098eda065c794c79e1ae23f33f103af
Author: He Chen 
Date:   Mon Sep 5 12:49:43 2016 +0200

x86: allow disabling sm{e,a}p for Xen itself

SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.

SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest which will suffer unknown SMEP/SMAP page fault when guest
kernel attempt to access user address although SMEP/SMAP is close for
PV guests.

This patch introduces a new boot option value "hvm" for "sm{e,a}p", it
is going to diable SMEP/SMAP for Xen hypervisor while enable them for
HVM. In this way, 32-bit PV guest will not suffer SMEP/SMAP security
issue. Users can choose whether open SMEP/SMAP for Xen itself,
especially when they are going to run 32-bit PV guests.

Signed-off-by: He 

[Xen-devel] [PATCH] libxl: update flex output files for DSA 3653-2

[Wei Liu]

We updated flex output files in 4b314c89 ("libxl: update flex output
files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
discovered the fix to flex was incomplete and issued DSA 3653-2. We need
to update our flex output files accordingly.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libxl/libxlu_cfg_l.c  | 4 ++--
 tools/libxl/libxlu_disk_l.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxlu_cfg_l.c b/tools/libxl/libxlu_cfg_l.c
index 7fedd41..099aa8e 100644
--- a/tools/libxl/libxlu_cfg_l.c
+++ b/tools/libxl/libxlu_cfg_l.c
@@ -685,7 +685,7 @@ static int input (yyscan_t yyscanner );
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
-   size_t n; \
+   int n; \
for ( n = 0; n < max_size && \
 (c = getc( yyin )) != EOF && c != '\n'; ++n ) \
buf[n] = (char) c; \
@@ -698,7 +698,7 @@ static int input (yyscan_t yyscanner );
else \
{ \
errno=0; \
-   while ( (result = fread(buf, 1, max_size, yyin))==0 && 
ferror(yyin)) \
+   while ( (result = fread(buf, 1, (yy_size_t) max_size, yyin)) == 
0 && ferror(yyin)) \
{ \
if( errno != EINTR) \
{ \
diff --git a/tools/libxl/libxlu_disk_l.c b/tools/libxl/libxlu_disk_l.c
index 06f839e..54160ca 100644
--- a/tools/libxl/libxlu_disk_l.c
+++ b/tools/libxl/libxlu_disk_l.c
@@ -1158,7 +1158,7 @@ static int input (yyscan_t yyscanner );
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
-   size_t n; \
+   int n; \
for ( n = 0; n < max_size && \
 (c = getc( yyin )) != EOF && c != '\n'; ++n ) \
buf[n] = (char) c; \
@@ -1171,7 +1171,7 @@ static int input (yyscan_t yyscanner );
else \
{ \
errno=0; \
-   while ( (result = fread(buf, 1, max_size, yyin))==0 && 
ferror(yyin)) \
+   while ( (result = fread(buf, 1, (yy_size_t) max_size, yyin)) == 
0 && ferror(yyin)) \
{ \
if( errno != EINTR) \
{ \
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

[Jan Beulich]

>>> On 02.09.16 at 19:56,  wrote:
> From: Jan Beulich [mailto:jbeul...@suse.com] 
> Sent: Friday, September 2, 2016 6:31 AM
 On 19.08.16 at 19:22,  wrote:
>> +/* Init alternate p2m data. */
>> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
>> +{
>> +rc = -ENOMEM;
>> +goto out;
>> +}
> 
> When the epilogue (after the target label) is just a return statement, 
> please avoid using goto.
> 
> [PAUL] I don't see this code in an epilogue (after the target label).  

I don't understand: The function ends like this

 out:
return rc;
}

What is it that you don't see here? Again, all I'm asking for is that
in a case like this you simply use "return" instead of the rc
assignment and "goto".

Jan


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

[Xen-devel] [PATCH RFC 2/6] xen/arm: hwdom GIC: inherit interrupt parent from host device tree

[Kyle Temkin]

From: "Kyle J. Temkin" 

Currently, we don't copy in the interrupt parent from the host device
tree; and instead let Xen automatically figure it out when generating
the device tree for the hardware domain.

In cases where a non-GIC interrupt controller is present, this can lead
to incorrect assignment of interrupt parents, and throughly confuse the
hwdom. Instead of letting this fall to chance, pass through the
phandles.

Signed-off-by: Kyle Temkin 
---
 xen/arch/arm/domain_build.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..52c9a01 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -764,8 +764,8 @@ static int make_gic_node(const struct domain *d, void *fdt,
 {
 const struct dt_device_node *gic = dt_interrupt_controller;
 int res = 0;
-const void *addrcells, *sizecells;
-u32 addrcells_len, sizecells_len;
+const void *addrcells, *sizecells, *iparent;
+u32 addrcells_len, sizecells_len, iparent_len;
 
 /*
  * Xen currently supports only a single GIC. Discard any secondary
@@ -795,6 +795,14 @@ static int make_gic_node(const struct domain *d, void *fdt,
 return res;
 }
 
+iparent = dt_get_property(gic, "interrupt-parent", _len);
+if ( iparent )
+{
+res = fdt_property(fdt, "interrupt-parent", iparent, iparent_len);
+if ( res )
+  return res;
+}
+
 addrcells = dt_get_property(gic, "#address-cells", _len);
 if ( addrcells )
 {
-- 
2.9.2


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

[Xen-devel] [PATCH RFC 1/6] xen/arm: platforms: Add earlyprintk and serial support for Tegra boards.

[Kyle Temkin]

From: "Kyle J. Temkin" 

Tegra boards feature a NS16550-compatible serial mapped into the MMIO
space. Add support for its use both as a full-featured serial port and
as an earlyprintk driver.

Adds a new "needs_rtoie" (requires Rx Timeout Interrupt) quirk, as some
platforms-- including Tegra-- require the NS16550 Rx timeout interrupt
to be enabled for receive to function properly. The same quirk is
applied in the eqvuialent Linux driver [1].

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4539c24fe4f92c09ee668ef959d3e8180df619b9

Signed-off-by: Kyle Temkin 
---
 xen/arch/arm/Rules.mk   |  1 +
 xen/drivers/char/ns16550.c  | 16 +++-
 xen/include/xen/8250-uart.h |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 93304be..2a1473a 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -44,6 +44,7 @@ EARLY_PRINTK_vexpress   := pl011,0x1c09
 EARLY_PRINTK_xgene-mcdivitt := 8250,0x1c021000,2
 EARLY_PRINTK_xgene-storm:= 8250,0x1c02,2
 EARLY_PRINTK_zynqmp := cadence,0xff00
+EARLY_PRINTK_tegra  := 8250,0x70006000,2
 
 ifneq ($(EARLY_PRINTK_$(CONFIG_EARLY_PRINTK)),)
 EARLY_PRINTK_CFG := $(subst $(comma), ,$(EARLY_PRINTK_$(CONFIG_EARLY_PRINTK)))
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 1da103a..bffdb35 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -64,6 +64,7 @@ static struct ns16550 {
 unsigned int timeout_ms;
 bool_t intr_works;
 bool_t dw_usr_bsy;
+bool_t needs_rtoie;
 #ifdef CONFIG_HAS_PCI
 /* PCI card parameters. */
 bool_t pb_bdf_enable;   /* if =1, pb-bdf effective, port behind bridge */
@@ -652,12 +653,23 @@ static void ns16550_setup_postirq(struct ns16550 *uart)
 {
 if ( uart->irq > 0 )
 {
+u8 ier_value = 0;
+
 /* Master interrupt enable; also keep DTR/RTS asserted. */
 ns_write_reg(uart,
  UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS);
 
 /* Enable receive interrupts. */
-ns_write_reg(uart, UART_IER, UART_IER_ERDAI);
+ier_value = UART_IER_ERDAI;
+
+/*
+ * If we're on a platform that needs Rx timeouts enabled, also
+ * set Rx TimeOut Interrupt Enable (RTOIE).
+ */
+if ( uart->needs_rtoie )
+  ier_value |= UART_IER_RTOIE;
+
+ns_write_reg(uart, UART_IER, ier_value);
 }
 
 if ( uart->irq >= 0 )
@@ -1273,6 +1285,7 @@ static int __init ns16550_uart_dt_init(struct 
dt_device_node *dev,
 uart->irq = res;
 
 uart->dw_usr_bsy = dt_device_is_compatible(dev, "snps,dw-apb-uart");
+uart->needs_rtoie = dt_device_is_compatible(dev, "nvidia,tegra20-uart");
 
 uart->vuart.base_addr = uart->io_base;
 uart->vuart.size = uart->io_size;
@@ -1293,6 +1306,7 @@ static const struct dt_device_match ns16550_dt_match[] 
__initconst =
 DT_MATCH_COMPATIBLE("ns16550"),
 DT_MATCH_COMPATIBLE("ns16550a"),
 DT_MATCH_COMPATIBLE("snps,dw-apb-uart"),
+DT_MATCH_COMPATIBLE("nvidia,tegra20-uart"),
 { /* sentinel */ },
 };
 
diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
index c6b62c8..2ad0ee6 100644
--- a/xen/include/xen/8250-uart.h
+++ b/xen/include/xen/8250-uart.h
@@ -41,6 +41,7 @@
 #define UART_IER_ETHREI   0x02/* tx reg. empty*/
 #define UART_IER_ELSI 0x04/* rx line status   */
 #define UART_IER_EMSI 0x08/* MODEM status */
+#define UART_IER_RTOIE0x10/* rx timeout   */
 
 /* Interrupt Identificatiegister */
 #define UART_IIR_NOINT0x01/* no interrupt pending */
-- 
2.9.2


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

[Xen-devel] [PATCH RFC 0/6] ARM: Add support for Tegra SoCs (incl. Jetson TK1, Jetson TX1)

[Kyle Temkin]

The attached patch-set adds support for 32-bit and 64-bit Tegra SoCs; including
support for the Jetson TK1 and Jetson TX1 boards, as well as the Pixel C tablet.
It has been tested on the TK1, TX1, and Pixel C.

Many thanks to Ian Campbell, whose original Jetson TK1 patchset contained a lot
of pointers in the right direction, and helped us to get started on this one!

This patch set includes:
  - Some minor serial quirks to get the NS16550 on the Tegra fully working,
which extend Chris Patterson's previous serial fixes with a very minor 
Tegra-specific quirk.
  - Support for the Tegra Legacy Interrupt Controller, which is necessary to get
interrupt routing working correctly on Tegra devices. In this version of the
patchset, the interrupt controller is supported via platform quirks.
  - A few additional minor features and logic fixes to support the Tegra. An
example would be the Tegra-specific reset logic.

This patch set does NOT include:
  - Support for the Tegra-specific IOMMU. This means this platform doesn't yet
support device passthrough. I do expect to write a driver for the IOMMU at
some point in the future, but don't think it's necessary for this initial 
patchset.

Thoughts and concerns:
  - This patchset includes what is essentially a simple driver for the Tegra
Legacy Interrupt Controller inside the platform code. Ideally, I'd rather
see this as a dedicated irqchip driver (perhaps under drivers/irqchip?)
instead of a chunk of platform code, but this currently isn't easily
accomplished, as Xen only supports a simple single-GIC topology.
  - This patchset introduces four new platform hooks that enable a platform to
override the IRQ routing logic: 'route_irq_to_guest', 'route_irq_to_xen',
'irq_is_routable', and 'irq_for_device'. I don't really like adding more
platform hooks -- especially as these seem like natural methods of an
irqchip driver -- but again am limited by the current single-GIC topology.

I'm looking forward to feedback on this patch set-- and am definitely open to
changes!


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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[Jan Beulich]

>>> On 05.09.16 at 12:02,  wrote:
> On 2016-09-05 11:46, Jan Beulich wrote:
> On 05.09.16 at 11:20,  wrote:
>>> Hmm it seems my thread was kind of hijacked and i was dropped from the
>>> CC.
>>> 
>>> I had some time and bisected the issue and it resulted in:
>>> 
>>> 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f is the first bad commit
>>> commit 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f
>>> Author: Jan Beulich 
>>> Date:   Wed Oct 21 10:56:31 2015 +0200
>>> 
>>>  x86/shadow: drop stray name tags from 
>>> sh_{guest_get,map}_eff_l1e()
>> 
>> Hmm, as Wei already indicated - that's rather odd. The commit isn't
>> really supposed to have any effect on functionality (and going
>> through it again I also can't spot any now). And are you indeed
>> using shadow mode, and if so does your problem not occur when
>> you use HAP instead?
>> 
>> In any event, if there was some hidden (and unintended) change
>> in functionality here, then the most likely result would seem to be
>> a crash, yet from the log fragment you posted it doesn't look like
>> there's _any_ relevant hypervisor output.
> 
> Hmm i was already afraid of that.
> Attached is the output of xl dmesg, HAP is supported and should be 
> enabled by default (and i didn't disable it explicitly in my guest.cfg).
> 
> I just tried the opposite and specified hap=0 in my guest.cfg and this 
> case leads to 2 lines of additional output:
> 
> XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings(): can't 
> find all mappings of mfn 471b69: c=8003 t=7401
> (XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings(): 
> can't find all mappings of mfn 471b68: c=8003 
> t=7401

And these two messages are relevant here? I.e. do they go away
when you use a commit ahead of the one your bisect spotted?

Anyway - with you quite clearly having used HAP before, I can't
see how this commit would matter for you at all. In case you want
to double check you could try with a hypervisor built without
shadow paging code (which we've been allowing for quite a
while).

Is it possible that the reproduction of the issue isn't 100% reliable?
I.e. did you verify with a couple of runs each that it really is this
commit, and not just some spurious effect? If it is, then from all I
know so far I'd suspect an effect from code / data arrangement
rather than the commit itself to be the actual culprit. Which reminds
me of another possible way of double checking: If said commit
reverts reasonably cleanly at the tip of staging or master, maybe
you could try with just this change reverted, instead of with
everything subsequent to it reverted too?

Jan


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

Re: [Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH] libxl: add "xl qemu-monitor-command""):
> On 05/09/16 12:32, Ian Jackson wrote:
> > The rest of the documentation will need adjusting.  As an example of
> > the incompleteness I am talking about I think the example shows only
> > some of the USB devices presented to the guest.
> 
> Hmm, I think the statement:
> 
> +Obtain information of USB devices connected via the device model to a
> +domain:
> 
> is absolutely correct. Which USB devices connected via the device model
> won't be shown?

Well, technically the statement is true.  But it's a bear trap for the
incautious (or hurried) reader.  Perhaps add `(only!)' after `device
model' ?

Ian.

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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[Wei Liu]

On Mon, Sep 05, 2016 at 11:20:30AM +0200, li...@eikelenboom.it wrote:
> On 2016-08-25 23:18, li...@eikelenboom.it wrote:
> >On 2016-08-25 22:34, Doug Goldstein wrote:
> >>On 8/25/16 4:21 PM, li...@eikelenboom.it wrote:
> >>>Today i tried to switch some of my HVM guests (qemu-xen) from booting
> >>>of
> >>>a kernel *inside* the guest, to a dom0 supplied kernel, which is
> >>>described as "Direct Kernel Boot" here:
> >>>https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html :
> >>>
> >>>Direct Kernel Boot
> >>>
> >>>Direct kernel boot allows booting directly from a kernel and
> >>>initrd
> >>>stored in the host physical
> >>>machine OS, allowing command line arguments to be passed directly.
> >>>PV guest direct kernel boot
> >>>is supported. HVM guest direct kernel boot is supported with
> >>>limitation (it's supported when
> >>>using qemu-xen and default BIOS 'seabios'; not supported in case
> >>>of
> >>>stubdom-dm and old rombios.)
> >>>
> >>>kernel="PATHNAME"Load the specified file as the kernel image.
> >>>ramdisk="PATHNAME"   Load the specified file as the ramdisk.
> >>>
> >>>But qemu fails to start, output appended below.
> >>>
> >>>I tested with:
> >>>- current Xen-unstable, which fails.
> >>>- xen-stable-4.7.0 release, which fails.
> >>>- xen-stable-4.6.0 release, works fine.
> >>
> >>Can you include the logs from xl dmesg around that time frame as well?
> >
> >Ah i thought there wasn't any, but didn't check thoroughly or wasn't there
> >since the release builds are non-debug by default.
> >
> >However, back on xen-unstable:
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: CPU
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: PIC
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: IOAPIC
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: LAPIC
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: LAPIC_REGS
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: PCI_IRQ
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: ISA_IRQ
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: PCI_LINK
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: PIT
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: RTC
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: HPET
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: PMTIMER
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: MTRR
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: VIRIDIAN_DOMAIN
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: CPU_XSAVE
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: VIRIDIAN_VCPU
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: VMCE_VCPU
> >(XEN) [2016-08-25 21:09:15.172] HVM19 save: TSC_ADJUST
> >(XEN) [2016-08-25 21:09:15.172] HVM19 restore: CPU 0
> >(XEN) [2016-08-25 21:09:16.126] d0v1 Over-allocation for domain 19:
> >262401 > 262400
> >(XEN) [2016-08-25 21:09:16.126] memory.c:213:d0v1 Could not allocate
> >order=0 extent: id=19 memflags=0 (192 of 512)
> >
> >Hmm some off by one issue ?
> >
> >
> >>Just wondering how much RAM you're domain is defined with as well?
> >
> >1024 Mb, there is more than enough unallocated memory for xen to start
> >the guest (and dom0 is fixed with dom0_mem=1536M,max:1536M and
> >ballooning is off)
> 
> 
> Hmm it seems my thread was kind of hijacked and i was dropped from the CC.
> 

Oops, I thought you were CC'ed. Sorry.

> I had some time and bisected the issue and it resulted in:
> 
> 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f is the first bad commit
> commit 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f
> Author: Jan Beulich 
> Date:   Wed Oct 21 10:56:31 2015 +0200
> 
> x86/shadow: drop stray name tags from sh_{guest_get,map}_eff_l1e()
> 
> They (as a now being removed comment validly says) depend only on Xen's
> number of page table levels, and hence their tags didn't serve any
> useful purpose (there could only ever be one instance in a single
> binary, even back in the x86-32 days).
> 
> Further conditionalize the inclusion of PV-specific hook pointers, at
> once making sure that PV guests can't ever get other than 4-level mode
> enabled for them.
> 
> For consistency reasons shadow_{write,cmpxchg}_guest_entry() also get
> moved next to the other PV-only actors, allowing them to become static
> just like the $subject ones do.
> 
> Signed-off-by: Jan Beulich 
> Acked-by: Tim Deegan 
> 
> :04 04 0c2e3475f81547f934a5960d9f1ac4849707d4ed
> f17f5ff17ca50d6ab908afe9a2d8555d954d3d0a M  xen
> 

Unfortunately I can't see immediately why this would affect QEMU direct
boot. It also suggests that it only affects shadow code -- what kind of
hardware are you using?

Wei.

> 
> --
> Sander
> 
> 
> >
> >--
> >Sander

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

[Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Marek Marczykowski-Górecki]

Fill backend_domid field based on backend path.


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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[linux]

On 2016-09-05 11:46, Jan Beulich wrote:

On 05.09.16 at 11:20,  wrote:

Hmm it seems my thread was kind of hijacked and i was dropped from the
CC.

I had some time and bisected the issue and it resulted in:

5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f is the first bad commit
commit 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f
Author: Jan Beulich 
Date:   Wed Oct 21 10:56:31 2015 +0200

 x86/shadow: drop stray name tags from 
sh_{guest_get,map}_eff_l1e()


Hmm, as Wei already indicated - that's rather odd. The commit isn't
really supposed to have any effect on functionality (and going
through it again I also can't spot any now). And are you indeed
using shadow mode, and if so does your problem not occur when
you use HAP instead?

In any event, if there was some hidden (and unintended) change
in functionality here, then the most likely result would seem to be
a crash, yet from the log fragment you posted it doesn't look like
there's _any_ relevant hypervisor output.

Jan


Hmm i was already afraid of that.
Attached is the output of xl dmesg, HAP is supported and should be 
enabled by default (and i didn't disable it explicitly in my guest.cfg).


I just tried the opposite and specified hap=0 in my guest.cfg and this 
case leads to 2 lines of additional output:


XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings(): can't 
find all mappings of mfn 471b69: c=8003 t=7401
(XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings(): 
can't find all mappings of mfn 471b68: c=8003 
t=7401
(XEN) [2016-09-05 09:58:22.334] d0v5 Over-allocation for domain 3: 
262401 > 262400
(XEN) [2016-09-05 09:58:22.334] memory.c:163:d0v5 Could not allocate 
order=0 extent: id=3 memflags=0 (192 of 512)


--
Sander
 __  ___  _   _  __ _  
 \ \/ /___ _ __   | || | |___  | _   _ _ __  ___| |_ __ _| |__ | | ___ 
  \  // _ \ '_ \  | || |_   / /_| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
  /  \  __/ | | | |__   _| / /__| |_| | | | \__ \ || (_| | |_) | |  __/
 /_/\_\___|_| |_||_|(_)_/\__,_|_| |_|___/\__\__,_|_.__/|_|\___|
   
(XEN) Xen version 4.7-unstable (r...@dyndns.org) (gcc-4.9.real (Debian 
4.9.2-10) 4.9.2) debug=y Mon Sep  5 11:03:14 CEST 2016
(XEN) Latest ChangeSet: Wed Oct 21 10:56:31 2015 +0200 git:5a3ce8f
(XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
(XEN) Command line: dom0_mem=1536M,max:1536M loglvl=all loglvl_guest=all 
console_timestamps=datems vga=gfx-1280x1024x32 no-cpuidle cpufreq=xen 
com1=38400,8n1 console=vga,com1 ivrs_ioapic[6]=00:14.0 
iommu=on,verbose,debug,amd-iommu-debug conring_size=128k sched=credit2 ucode=-1
(XEN) Video information:
(XEN)  VGA is graphics mode 1280x1024, 32 bpp
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because of reasons unknown
(XEN) Disc information:
(XEN)  Found 2 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 00099400 (usable)
(XEN)  00099400 - 000a (reserved)
(XEN)  000e4000 - 0010 (reserved)
(XEN)  0010 - 9ff9 (usable)
(XEN)  9ff9 - 9ff9e000 (ACPI data)
(XEN)  9ff9e000 - 9ffe (ACPI NVS)
(XEN)  9ffe - a000 (reserved)
(XEN)  ffe0 - 0001 (reserved)
(XEN)  0001 - 00056000 (usable)
(XEN) ACPI: RSDP 000FB100, 0014 (r0 ACPIAM)
(XEN) ACPI: RSDT 9FF9, 0048 (r1 MSIOEMSLIC  20100913 MSFT   97)
(XEN) ACPI: FACP 9FF90200, 0084 (r1 7640MS A7640100 20100913 MSFT   97)
(XEN) ACPI: DSDT 9FF905E0, 9427 (r1  A7640 A7640100  100 INTL 20051117)
(XEN) ACPI: FACS 9FF9E000, 0040
(XEN) ACPI: APIC 9FF90390, 0088 (r1 7640MS A7640100 20100913 MSFT   97)
(XEN) ACPI: MCFG 9FF90420, 003C (r1 7640MS OEMMCFG  20100913 MSFT   97)
(XEN) ACPI: SLIC 9FF90460, 0176 (r1 MSIOEMSLIC  20100913 MSFT   97)
(XEN) ACPI: OEMB 9FF9E040, 0072 (r1 7640MS A7640100 20100913 MSFT   97)
(XEN) ACPI: SRAT 9FF9A5E0, 0108 (r3 AMDFAM_F_102 AMD 1)
(XEN) ACPI: HPET 9FF9A6F0, 0038 (r1 7640MS OEMHPET  20100913 MSFT   97)
(XEN) ACPI: IVRS 9FF9A730, 0110 (r1  AMD RD890S   202031 AMD 0)
(XEN) ACPI: SSDT 9FF9A840, 0DA4 (r1 A M I  POWERNOW1 AMD 1)
(XEN) System RAM: 20479MB (20970660kB)
(XEN) SRAT: PXM 0 -> APIC 00 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 01 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 02 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 03 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 04 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 05 -> Node 0
(XEN) SRAT: Node 0 PXM 0 0-a
(XEN) SRAT: Node 0 PXM 0 10-a000
(XEN) SRAT: Node 0 PXM 0 1-56000
(XEN) NUMA: Allocated memnodemap from 55c797000 - 55c79d000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised

[Xen-devel] [PATCH for-4.7, 4.6] libxl: do not assume Dom0 backend while getting nic info

[Marek Marczykowski-Górecki]

Fill backend_domid field based on backend path.

Cc: Ian Jackson 
Cc: Wei Liu 
Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e1ab6ec..9a888a1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3601,6 +3601,18 @@ static int libxl__device_nic_from_xenstore(libxl__gc *gc,
 else
 nic->devid = 0;
 
+rc = libxl__xs_read_checked(gc, XBT_NULL,
+GCSPRINTF("%s/backend", libxl_path), );
+if (rc) goto out;
+
+if (!tmp) {
+LOG(ERROR, "nic %s does not exist (no backend path)", libxl_path);
+rc = ERROR_FAIL;
+goto out;
+}
+rc = libxl__backendpath_parse_domid(gc, tmp, >backend_domid);
+if (rc) goto out;
+
 /* nic->mtu = */
 
 tmp = READ_LIBXLDEV(gc, "mac");
-- 
2.5.5


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RFC 6/6] xen/arm: platforms/tegra: ensure the hwdom can only affect its own interrupts

[Kyle Temkin]

From: "Kyle J. Temkin" 

Several Tegra hardware devices-- and the Tegra device tree--  expect
the presence of a Tegra Legacy Interrupt Controller (LIC) in the hardware
domain. Accordingly, we'll need to expose (most of) the LIC's registers
to the hardware domain.

As the Tegra LIC provides the ability to modify interrupt delivery (e.g.
by masking interrupts, forcing asserting/clearing them, or adjusting
their prority), it's important that the hardware domain's access be
mediated. This commit adds read/write handlers that prohibit
modification of register sections corresponding to interrupts not owned
by the hardware domain.

Note that this is written to be domain agnostic; this allows the
potential to e.g. map the ictlr into multiple domains if this is desired
for passthrough in the future.

Signed-off-by: Kyle Temkin 
---
 xen/arch/arm/platforms/tegra.c | 227 +++--
 1 file changed, 216 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c
index e75242c..a119c01 100644
--- a/xen/arch/arm/platforms/tegra.c
+++ b/xen/arch/arm/platforms/tegra.c
@@ -21,11 +21,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 
 /* Permanent mapping to the Tegra legacy interrupt controller. */
@@ -258,6 +260,218 @@ static void tegra_route_irq_to_xen(struct irq_desc *desc, 
unsigned int priority)
 }
 
 /**
+ * Parses a LIC MMIO read or write, and extracts the information needed to
+ * complete the request.
+ *
+ * @param info Information describing the MMIO read/write being performed.
+ * @param register_number The register number in the ictlr; e.g.
+ *TEGRA_ICTLR_CPU_IER_SET.
+ * @param register_offset The offset into tegra_icltr_base at which the target
+ *register exists.
+ * @param The number of the first IRQ represented by the given ictlr register.
+ */
+static void tegra_ictlr_parse_mmio_request(mmio_info_t *info,
+int *register_number, int *register_offset, int *irq_base)
+{
+/* Determine the offset of the access into the ICTLR region. */
+uint32_t offset = info->gpa - TEGRA_ICTLR_BASE;
+
+if(register_number)
+*register_number = offset % TEGRA_ICTLR_SIZE;
+
+if(register_offset)
+*register_offset = offset;
+
+if(irq_base) {
+int ictlr_number = offset / TEGRA_ICTLR_SIZE;
+*irq_base = (ictlr_number * TEGRA_IRQS_PER_ICTLR) + NR_LOCAL_IRQS;
+}
+}
+
+/**
+ * Returns true iff the given IRQ is currently routed to the given domain.
+ *
+ * @param irq The IRQ number for the IRQ in question.
+ * @param d The domain in question.
+ * @return True iff the given domain is the current IRQ target.
+ */
+static bool irq_owned_by_domain(int irq, struct domain *d)
+{
+struct irq_desc *desc = irq_to_desc(irq);
+domid_t domid;
+unsigned long flags;
+
+BUG_ON(!desc);
+
+spin_lock_irqsave(>lock, flags);
+domid = irq_get_domain_id(desc);
+spin_unlock_irqrestore(>lock, flags);
+
+return (d->domain_id == domid);
+}
+
+
+/**
+ * Mediates an MMIO-read to the Tegra legacy interrupt controller.
+ * Ensures that each domain only is passed interrupt state for its
+ * own interupts.
+ */
+static int tegra_ictlr_domain_read(struct vcpu *v, mmio_info_t *info,
+register_t *target_register, void *priv)
+{
+register_t raw_value;
+
+int register_number;
+int register_offset;
+int irq_base;
+int i;
+
+tegra_ictlr_parse_mmio_request(info, _number, _offset,
+   _base);
+
+/* Sanity check the read. */
+if ( register_offset & 0x3 ) {
+printk(XENLOG_G_ERR "d%u: Tegra LIC: Attempt to read unaligned ictlr 
addr"
+"(%" PRIpaddr ")!", current->domain->domain_id, 
info->gpa);
+domain_crash_synchronous();
+}
+if ( info->dabt.size != DABT_WORD ) {
+printk(XENLOG_G_ERR "d%u: Tegra LIC: Non-word read from ictlr addr"
+"%" PRIpaddr "!", current->domain->domain_id, 
info->gpa);
+domain_crash_synchronous();
+}
+
+/* Ensure that we've only been handed an offset within our region. */
+BUG_ON(register_offset > TEGRA_ICTLR_SIZE * TEGRA_ICTLR_COUNT);
+
+/* Perform the core ictlr read. */
+raw_value = readl(tegra_ictlr_base + register_offset);
+
+/*
+ * We don't want to leak information about interrupts not controlled
+ * by the active domain. Thus, we'll zero out any ictlr slots for
+ * IRQs not owned by the given domain.
+ */
+for (i = 0; i < TEGRA_IRQS_PER_ICTLR; ++i) {
+int irq = irq_base + i;
+int mask = BIT(irq % 32);
+
+if(!irq_owned_by_domain(irq, current->domain))
+raw_value &= ~mask;
+}
+
+/* Finally, set the target register to our read value */
+*target_register = raw_value;
+return 1;
+}
+
+
+/**
+ * Mediates an 

[Xen-devel] [PATCH RFC 4/6] xen/arm: platforms: Add Tegra platform to support basic IRQ routing.

[Kyle Temkin]

From: "Kyle J. Temkin" 

Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat this devices attached to this controller as
connected to the primary GIC, as it will be handling their interrupts.

This commit adds support for exposing the ictlr to the hardware domain;
but a future commit will extend this to support exposing a virtualized
version of the ictlr to the hardware domain, and to ensure that
interrupts are unmasked properly when routed to a Xen, or to a domain
other than the hardware domain.

Signed-off-by: Kyle Temkin 
---
 xen/arch/arm/platforms/Makefile   |   2 +
 xen/arch/arm/platforms/tegra.c| 339 ++
 xen/include/asm-arm/platforms/tegra.h |  50 +
 3 files changed, 391 insertions(+)
 create mode 100644 xen/arch/arm/platforms/tegra.c
 create mode 100644 xen/include/asm-arm/platforms/tegra.h

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 49fa683..0c3a7f4 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -4,7 +4,9 @@ obj-$(CONFIG_ARM_32) += exynos5.o
 obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
 obj-$(CONFIG_ARM_32) += rcar2.o
+obj-$(CONFIG_ARM_32) += tegra.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
 obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_ARM_64) += tegra.o
diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c
new file mode 100644
index 000..e75242c
--- /dev/null
+++ b/xen/arch/arm/platforms/tegra.c
@@ -0,0 +1,339 @@
+/*
+ * NVIDIA Tegra specific settings
+ *
+ * Ian Campbell; Copyright (c) 2014 Citrix Systems
+ * Kyle Temkin; Copyright (c) 2016 Assured Information Security, Inc.
+ * Chris Patterson; Copyright (c) 2016 Assured Information Security, Inc.
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+
+/* Permanent mapping to the Tegra legacy interrupt controller. */
+static void __iomem *tegra_ictlr_base = NULL;
+
+/*
+ * List of legacy interrupt controllers that can be used to route
+ * Tegra interrupts.
+ */
+static const char * const tegra_interrupt_compat[] __initconst =
+{
+"nvidia,tegra120-ictlr",  /* Tegra K1 controllers */
+"nvidia,tegra210-ictlr"   /* Tegra X1 controllers */
+};
+
+
+/**
+ * Returns true if the given IRQ belongs to a supported tegra interrupt
+ * controller.
+ *
+ * @param rirq The raw IRQ to be identified.
+ * @return True iff the given IRQ belongs to a Tegra ictlr.
+ */
+static bool_t tegra_irq_belongs_to_ictlr(struct dt_raw_irq * rirq)  {
+int i;
+
+for (i = 0; i < ARRAY_SIZE(tegra_interrupt_compat); i++)
+{
+if ( dt_device_is_compatible(rirq->controller, 
tegra_interrupt_compat[i]) )
+return true;
+}
+
+return false;
+}
+
+
+/**
+ * Returns true iff the given IRQ is routable -- that is, if it is descended
+ * from the platform's primary GIC.
+ *
+ * @param rirq The raw IRQ in question.
+ * @return True iff the given IRQ routes to a platform GIC.
+ */
+static bool_t tegra_irq_is_routable(struct dt_raw_irq * rirq)
+{
+/* If the IRQ connects directly to our GIC, it's trivially routable. */
+if ( rirq->controller == dt_interrupt_controller )
+return true;
+
+/*
+ * If the IRQ belongs to a legacy interrupt controller, then it's
+ * effectively owned by the GIC, and is routable.
+ */
+if ( tegra_irq_belongs_to_ictlr(rirq) )
+return true;
+
+return false;
+}
+
+/**
+ * Returns the IRQ number for a given device. Tegra IRQs transalate using the
+ * same algorithm as normal GIC IRQs, but aren't parented by the system GIC.
+ *
+ * As a result, translation fails an assertion in the normal translation path.
+ * The normal version is essentially dt_irq_xlate wrapped with an assert, so
+ * we'll just call dt_irq_xlate directly.
+ *
+ * @param device The DT node describing the device.
+ * @param index The index of the interrupt within the device node.
+ * @return The translated number of the IRQ, or a negative error code.
+ */
+static int tegra_irq_for_device(const struct dt_device_node *device, int index)
+{
+struct dt_raw_irq raw;
+struct dt_irq dt_irq;
+int res;
+
+res = dt_device_get_raw_irq(device, 

[Xen-devel] [PATCH RFC 3/6] xen/arm: Allow platforms to hook IRQ routing.

[Kyle Temkin]

From: "Kyle J. Temkin" 

Some common platforms (e.g. Tegra) have non-traditional IRQ controllers
that must be programmed in addition to their primary GICs-- and which
can come in unusual topologies. Device trees for targets that feature
these controllers often deviate from the conventions that Xen expects.

This commit provides a foundation for support of these platforms, by:
- Allowing the platform to decide which IRQs can be routed by Xen,
  rather than assuming that only GIC-connected IRQs can be routed.
- Allowing the platform to extend/replace existing IRQ routing logic,
  rather than asssuming that the GIC will always be programmed to route
  IRQs.
- Allows the platform to override IRQ translation, rather than assuming
  GIC translation will always be followed. This is useful in cases where
  device tree IRQ numbers don't correspond to GIC IRQ numbers.

Signed-off-by: Kyle Temkin 
---
 xen/arch/arm/domain_build.c| 14 +-
 xen/arch/arm/irq.c |  5 +++--
 xen/arch/arm/platform.c| 39 ++
 xen/arch/arm/time.c|  2 +-
 xen/drivers/char/cadence-uart.c|  3 ++-
 xen/drivers/char/exynos4210-uart.c |  3 ++-
 xen/drivers/char/ns16550.c |  3 ++-
 xen/drivers/char/omap-uart.c   |  3 ++-
 xen/drivers/char/pl011.c   |  3 ++-
 xen/drivers/char/scif-uart.c   |  3 ++-
 xen/drivers/passthrough/arm/smmu.c |  4 ++--
 xen/include/asm-arm/platform.h | 14 ++
 12 files changed, 80 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 52c9a01..402c766 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1094,16 +1094,20 @@ static int handle_device(struct domain *d, struct 
dt_device_node *dev)
 
 /*
  * Don't map IRQ that have no physical meaning
- * ie: IRQ whose controller is not the GIC
+ * ie: IRQ that does not wind up being controlled by the GIC
+ * (Note that we can't just check to see if an IRQ is owned by the GIC,
+ *  as some platforms have a controller between the device irq and the 
GIC,
+ *  such as the Tegra legacy interrupt controller.)
  */
-if ( rirq.controller != dt_interrupt_controller )
+if ( !platform_irq_is_routable() )
 {
-dt_dprintk("irq %u not connected to primary controller. Connected 
to %s\n",
-  i, dt_node_full_name(rirq.controller));
+dt_dprintk("irq %u not (directly or indirectly) connected to 
primary"
+"controller. Connected to %s\n", i,
+dt_node_full_name(rirq.controller));
 continue;
 }
 
-res = platform_get_irq(dev, i);
+res = platform_irq_for_device(dev, i);
 if ( res < 0 )
 {
 printk(XENLOG_ERR "Unable to get irq %u for %s\n",
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 06d4843..dc42817 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -27,6 +27,7 @@
 
 #include 
 #include 
+#include 
 
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
@@ -370,7 +371,7 @@ int setup_irq(unsigned int irq, unsigned int irqflags, 
struct irqaction *new)
 /* First time the IRQ is setup */
 if ( disabled )
 {
-gic_route_irq_to_xen(desc, GIC_PRI_IRQ);
+platform_route_irq_to_xen(desc, GIC_PRI_IRQ);
 /* It's fine to use smp_processor_id() because:
  * For PPI: irq_desc is banked
  * For SPI: we don't care for now which CPU will receive the
@@ -504,7 +505,7 @@ int route_irq_to_guest(struct domain *d, unsigned int virq,
 if ( retval )
 goto out;
 
-retval = gic_route_irq_to_guest(d, virq, desc, GIC_PRI_IRQ);
+retval = platform_route_irq_to_guest(d, virq, desc, GIC_PRI_IRQ);
 
 spin_unlock_irqrestore(>lock, flags);
 
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index b0bfaa9..74abdc6 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -137,6 +137,45 @@ bool_t platform_device_is_blacklisted(const struct 
dt_device_node *node)
 return (dt_match_node(blacklist, node) != NULL);
 }
 
+int platform_route_irq_to_guest(struct domain *d, unsigned int virq,
+struct irq_desc *desc, unsigned int priority)
+{
+if ( platform && platform->route_irq_to_guest )
+return platform->route_irq_to_guest(d, virq, desc, priority);
+else
+return gic_route_irq_to_guest(d, virq, desc, priority);
+}
+
+void platform_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
+{
+if ( platform && platform->route_irq_to_xen )
+platform->route_irq_to_xen(desc, priority);
+else
+gic_route_irq_to_xen(desc, priority);
+}
+
+bool_t platform_irq_is_routable(struct dt_raw_irq * rirq)
+{

Re: [Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Ian Jackson]

Juergen Gross writes ("[PATCH] libxl: add "xl qemu-monitor-command""):
> Add a new xl command "qemu-monitor-command" to issue arbitrary commands
> to a domain's device model. Syntax is:
> 
> xl qemu-monitor-command  
> 
> The command is issued via qmp human-monitor-command command. Any
> information returned by the command is printed to stdout.
...
> +=item B I I
> +
> +Issue a monitor command to the device model of the domain specified by
> +I. I can be any valid command qemu understands. This
> +can be e.g. used to add non-standard devices or devices with non-standard
> +parameters to a domain. The output of the command is printed to stdout.

This needs some kind of health warning.  Something like:

 Warning: This qemu monitor access is provided for convenience when
 debugging, troubleshooting, and experimenting.  Its use is not
 supported by the Xen Project.

 Specifically, not all information printed by the qemu monitor will
 necessarily be accurate or complete, because in a Xen system qemu
 does not have a complete view of the guest.

 Furthermore, modifying the guest's setup via the qemu monitor may
 conflict with the Xen toolstack's assumptions.  Resulting problems
 may include, but are not limited to: guest crashes; toolstack error
 messages; inability to migrate the guest; and security
 vulnerabilities which are not covered by the Xen Project security
 response policy.

The rest of the documentation will need adjusting.  As an example of
the incompleteness I am talking about I think the example shows only
some of the USB devices presented to the guest.

Ian.

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

Re: [Xen-devel] [PATCH v5] x86/cpuid: AVX-512 Feature Detection

[Andrew Cooper]

On 23/08/16 02:54, Luwei Kang wrote:
> AVX512 is an extention of AVX2. Its spec can be found at:
> https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
> This patch detects AVX512 features by CPUID.
>
> Signed-off-by: Luwei Kang 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[linux]

On 2016-09-05 13:43, Jan Beulich wrote:

On 05.09.16 at 13:19,  wrote:

On 2016-09-05 12:25, Jan Beulich wrote:

Anyway - with you quite clearly having used HAP before, I can't
see how this commit would matter for you at all. In case you want
to double check you could try with a hypervisor built without
shadow paging code (which we've been allowing for quite a
while).


I just tried that and without shadow paging code the guest boots fine,
so that's interesting.


Indeed. Was that try with plain staging/master, or with much of
the reverts in place (from the bisection)? It seems to me that
investigating this odd difference would perhaps be a better
route than trying to guess what's wrong with said commit.

Jan


It was a try with a tree at the culprit commit and editted 
xen/arch/x86/Rules.mk to disable the shadow paging code from being 
build.


Now just tried with unstable and using Kconfig, but with that build the 
guest doesn't boot.

So
or the KConfig option doesn't work
or the reliability isn't 100% afterall (but i should have noticed that 
earlier on i would say)

or there is something else (semantics around the disabling changed ?)

*sigh*, seems it's not going to be an easy one :-\

My /boot/xen-4.8-unstable.config gives:
#
# Architecture Features
#
CONFIG_NR_CPUS=256
# CONFIG_SHADOW_PAGING is not set
# CONFIG_BIGMEM is not set
CONFIG_HVM_FEP=y
CONFIG_TBOOT=y

So it should be off i guess.

--
Sander

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

[Xen-devel] [PATCH] x86emul: simplify prefix handling for VMFUNC

[Jan Beulich]

LOCK prefixes get dealt with elsewhere and 66, F2, and F3 can all be
checked for in one go by looking at vex.pfx.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3942,8 +3942,8 @@ x86_emulate(
 goto rdtsc;
 }
 case 0xd4: /* vmfunc */
-generate_exception_if(lock_prefix | rep_prefix() | (vex.pfx == 
vex_66),
-  EXC_UD, -1);
+if ( vex.pfx )
+break;
 fail_if(ops->vmfunc == NULL);
 if ( (rc = ops->vmfunc(ctxt) != X86EMUL_OKAY) )
 goto done;



x86emul: simplify prefix handling for VMFUNC

LOCK prefixes get dealt with elsewhere and 66, F2, and F3 can all be
checked for in one go by looking at vex.pfx.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3942,8 +3942,8 @@ x86_emulate(
 goto rdtsc;
 }
 case 0xd4: /* vmfunc */
-generate_exception_if(lock_prefix | rep_prefix() | (vex.pfx == 
vex_66),
-  EXC_UD, -1);
+if ( vex.pfx )
+break;
 fail_if(ops->vmfunc == NULL);
 if ( (rc = ops->vmfunc(ctxt) != X86EMUL_OKAY) )
 goto done;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools/firmware: Rename bios.bin to seabios.bin

[Wei Liu]

On Mon, Sep 05, 2016 at 10:28:25AM +0100, Andrew Cooper wrote:
> On 05/09/16 09:09, Anthony PERARD wrote:
> > On Mon, Aug 22, 2016 at 11:24:05AM +0100, Wei Liu wrote:
> >> On Fri, Aug 19, 2016 at 03:26:23PM +0100, Andrew Cooper wrote:
> >>> bios.bin as a name is far too generic.  Rename it to seabios.bin.
> >>>
> >>> Signed-off-by: Andrew Cooper 
> >> Hmm... I remember the first few versions of that series had it named
> >> seabios.bin and I acked that.
> >>
> >> Anyway, I think I will give Anthony a chance to clarify why he changed
> >> the name.
> > I've changed it because someone ask for it:
> > https://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02371.html
> 
> It was admittedly lacking a question mark, but that was a question not a
> statement.
> 
> The answer is "because there are a load of other bios binaries stored in
> the same directory".
> 
> > It was to match how seabios is installed by default.
> 
> This is not relevant.  The version of seabios built by Xen should fit
> into the Xen expectations.  If this means renaming it to make it clear
> which bios it it, then so be it.

I think renaming it to seabios.bin is better.

Acked-by: Wei Liu 

Wei.

> 
> ~Andrew

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

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[Vitaly Kuznetsov]

Julien Grall  writes:

> Hi Vitaly,
>
> On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>> particular, when we crash on a secondary vCPU we may want to do kdump
>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
>> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
>> we have a number of hypercalls where we pass vCPU id as a parameter. These
>> hypercalls either fail or do something unexpected. To solve the issue
>> introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping
>> for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
>> CPUs it is a bit more trickier. Currently, we initialize IPI vectors
>> before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
>> instead.
>>
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>> Changes since v2:
>> - Use uint32_t for xen_vcpu_id mapping [Julien Grall]
>>
>> Changes since v1:
>> - Introduce xen_vcpu_nr() helper [David Vrabel]
>> - Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
>> ---
>>  arch/arm/xen/enlighten.c | 10 ++
>>  arch/x86/xen/enlighten.c | 23 ++-
>>  include/xen/xen-ops.h|  6 ++
>>  3 files changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index 75cd734..fe32267 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
>> *)_dummy_shared_info;
>>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>>  static struct vcpu_info __percpu *xen_vcpu_info;
>>
>> +/* Linux <-> Xen vCPU id mapping */
>> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
>> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
>> +
>>  /* These are unused until we support booting "pre-ballooned" */
>>  unsigned long xen_released_pages;
>>  struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] 
>> __initdata;
>> @@ -179,6 +183,9 @@ static void xen_percpu_init(void)
>>  pr_info("Xen: initializing cpu%d\n", cpu);
>>  vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>>
>> +/* Direct vCPU id mapping for ARM guests. */
>> +per_cpu(xen_vcpu_id, cpu) = cpu;
>> +
>
> We did some internal testing on ARM64 with the latest Linux kernel
> (4.8-rc4) and noticed that this patch is breaking SMP support. Sorry
> for noticing the issue that late.

Sorry for the breakage :-(

>
> This function is called on the running CPU whilst some code (e.g
> init_control_block in drivers/xen/events/events_fifo.c) is executed
> whilst preparing the CPU on the boot CPU.
>
> So xen_vcpu_nr(cpu) will always return 0 in this case and
> init_control_block will fail to execute.
>

I see,

CPU_UP_PREPARE event happens before xen_starting_cpu() is called.


> I am not sure how to fix. I guess we could setup per_cpu(xen_vcpu_id,
> *) in xen_guest_init. Any opinions?

As we're not doing kexec on ARM we can fix the immediate issue. I don't
know much about ARM and unfortunatelly I don't have a setup to test but
it seems there is no early_per_cpu* infrastructure for ARM so we may fix
it with the following:

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 3d2cef6..f193414 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -170,9 +170,6 @@ static int xen_starting_cpu(unsigned int cpu)
pr_info("Xen: initializing cpu%d\n", cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
 
-   /* Direct vCPU id mapping for ARM guests. */
-   per_cpu(xen_vcpu_id, cpu) = cpu;
-
info.mfn = virt_to_gfn(vcpup);
info.offset = xen_offset_in_page(vcpup);
 
@@ -330,6 +327,7 @@ static int __init xen_guest_init(void)
 {
struct xen_add_to_physmap xatp;
struct shared_info *shared_info_page = NULL;
+   int cpu;
 
if (!xen_domain())
return 0;
@@ -380,7 +378,8 @@ static int __init xen_guest_init(void)
return -ENOMEM;
 
/* Direct vCPU id mapping for ARM guests. */
-   per_cpu(xen_vcpu_id, 0) = 0;
+   for_each_possible_cpu(cpu)
+   per_cpu(xen_vcpu_id, cpu) = cpu;
 
xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,

(not tested, if we can't use for_each_possible_cpu() that early we'll
have to check against NR_CPUS instead).

But unfortunatelly we'll have to get back to this in future. Turns out
we need to know Xen's idea of vCPU id _before_ this vCPU starts
executing code. On x86 we used ACPI_ID from MADT. Is there anything like
it on ARM?

>
> [...]
>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 0f87db2..c833912 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1795,6 +1806,12 @@ static void __init init_hvm_pv_info(void)
>>
>>  

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[linux]

On 2016-09-05 12:25, Jan Beulich wrote:

On 05.09.16 at 12:02,  wrote:

On 2016-09-05 11:46, Jan Beulich wrote:

On 05.09.16 at 11:20,  wrote:
Hmm it seems my thread was kind of hijacked and i was dropped from 
the

CC.

I had some time and bisected the issue and it resulted in:

5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f is the first bad commit
commit 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f
Author: Jan Beulich 
Date:   Wed Oct 21 10:56:31 2015 +0200

 x86/shadow: drop stray name tags from
sh_{guest_get,map}_eff_l1e()


Hmm, as Wei already indicated - that's rather odd. The commit isn't
really supposed to have any effect on functionality (and going
through it again I also can't spot any now). And are you indeed
using shadow mode, and if so does your problem not occur when
you use HAP instead?

In any event, if there was some hidden (and unintended) change
in functionality here, then the most likely result would seem to be
a crash, yet from the log fragment you posted it doesn't look like
there's _any_ relevant hypervisor output.


Hmm i was already afraid of that.
Attached is the output of xl dmesg, HAP is supported and should be
enabled by default (and i didn't disable it explicitly in my 
guest.cfg).


I just tried the opposite and specified hap=0 in my guest.cfg and this
case leads to 2 lines of additional output:

XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings(): 
can't

find all mappings of mfn 471b69: c=8003 t=7401
(XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings():
can't find all mappings of mfn 471b68: c=8003
t=7401


And these two messages are relevant here? I.e. do they go away
when you use a commit ahead of the one your bisect spotted?


Just double checked with a build one commit ahead of the culprit the 
bisection reported and hap=0,

and those messages are there as well and the guest boots fine now.
So they don't seem to be relevant.


Anyway - with you quite clearly having used HAP before, I can't
see how this commit would matter for you at all. In case you want
to double check you could try with a hypervisor built without
shadow paging code (which we've been allowing for quite a
while).


I just tried that and without shadow paging code the guest boots fine, 
so that's

interesting.


Is it possible that the reproduction of the issue isn't 100% reliable?


Nope it seems 100% reliable.


I.e. did you verify with a couple of runs each that it really is this
commit, and not just some spurious effect? If it is, then from all I
know so far I'd suspect an effect from code / data arrangement
rather than the commit itself to be the actual culprit.


Well at least there is one other independent user running into the same 
issue,

so it doesn't seem specifically related to my machine or my builds.

It also happens when running all my guests (and this is the last to 
start) and with only this guest.



Which reminds
me of another possible way of double checking: If said commit
reverts reasonably cleanly at the tip of staging or master, maybe
you could try with just this change reverted, instead of with
everything subsequent to it reverted too?


Nope it tried that already and it didn't revert cleanly (and i didn't 
see how to correctly fix it up).


--
Sander


Jan


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

Re: [Xen-devel] [PATCH 0/3] mini-os: test and document config variations

[Wei Liu]

On Fri, Sep 02, 2016 at 10:56:44AM +0200, Juergen Gross wrote:
> Add a "testbuild" target to Makefile which builds various configurations.
> Repair some minor issues uncovered by those test builds.
> Document the config framework.
> 
> Juergen Gross (3):
>   mini-os: fix builds with uncommon config settings
>   mini-os: add testbuild target to Makefile
>   mini-os: update README to reflect recent changes
> 

Series pushed. Thank you both.

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

[Xen-devel] [PATCH] mini-os: add comments in Config.mk regarding new config options

[Juergen Gross]

Add some comment in Config.mk what to do in case of adding new config
options.

Signed-off-by: Juergen Gross 
---
 Config.mk | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Config.mk b/Config.mk
index 0e405bf..0baedd1 100644
--- a/Config.mk
+++ b/Config.mk
@@ -152,6 +152,11 @@ CFLAGS += -flto
 LDFLAGS-$(clang) += -plugin LLVMgold.so
 endif
 
+# When adding a new CONFIG_ option please make sure the test configurations
+# under arch/*/testbuild/ are updated accordingly. Especially
+# arch/*/testbuild/*-yes and arch/*/testbuild/*-no should set ALL possible
+# CONFIG_ variables.
+
 # Configuration defaults
 ifeq ($(TARGET_ARCH_FAM),x86)
 CONFIG_PARAVIRT ?= y
-- 
2.6.6


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

Re: [Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Wei Liu]

On Mon, Sep 05, 2016 at 11:26:04AM +0200, Marek Marczykowski-Górecki wrote:
> Fill backend_domid field based on backend path.
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Signed-off-by: Marek Marczykowski-Górecki 

Acked-by: Wei Liu 

I think this is a backport candidate?

> ---
>  tools/libxl/libxl_nic.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
> index c34b7ba..d1caa90 100644
> --- a/tools/libxl/libxl_nic.c
> +++ b/tools/libxl/libxl_nic.c
> @@ -309,6 +309,18 @@ static int libxl__device_nic_from_xenstore(libxl__gc *gc,
>  else
>  nic->devid = 0;
>  
> +rc = libxl__xs_read_checked(gc, XBT_NULL,
> +GCSPRINTF("%s/backend", libxl_path), );
> +if (rc) goto out;
> +
> +if (!tmp) {
> +LOG(ERROR, "nic %s does not exist (no backend path)", libxl_path);
> +rc = ERROR_FAIL;
> +goto out;
> +}
> +rc = libxl__backendpath_parse_domid(gc, tmp, >backend_domid);
> +if (rc) goto out;
> +
>  /* nic->mtu = */
>  
>  rc = libxl__xs_read_checked(gc, XBT_NULL,
> -- 
> 2.5.5
> 

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

Re: [Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Juergen Gross]

On 05/09/16 14:18, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH] libxl: add "xl qemu-monitor-command""):
>> On 05/09/16 12:32, Ian Jackson wrote:
>>> The rest of the documentation will need adjusting.  As an example of
>>> the incompleteness I am talking about I think the example shows only
>>> some of the USB devices presented to the guest.
>>
>> Hmm, I think the statement:
>>
>> +Obtain information of USB devices connected via the device model to a
>> +domain:
>>
>> is absolutely correct. Which USB devices connected via the device model
>> won't be shown?
> 
> Well, technically the statement is true.  But it's a bear trap for the
> incautious (or hurried) reader.  Perhaps add `(only!)' after `device
> model' ?

Sure, I can do that. And perhaps I should say:

Obtain information of USB devices connected as such via the device
model (only!) to a domain.

Just in case somebody connects e.g. a USB stick as a disk...


Juergen

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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[Jan Beulich]

>>> On 05.09.16 at 11:20,  wrote:
> Hmm it seems my thread was kind of hijacked and i was dropped from the 
> CC.
> 
> I had some time and bisected the issue and it resulted in:
> 
> 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f is the first bad commit
> commit 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f
> Author: Jan Beulich 
> Date:   Wed Oct 21 10:56:31 2015 +0200
> 
>  x86/shadow: drop stray name tags from sh_{guest_get,map}_eff_l1e()

Hmm, as Wei already indicated - that's rather odd. The commit isn't
really supposed to have any effect on functionality (and going
through it again I also can't spot any now). And are you indeed
using shadow mode, and if so does your problem not occur when
you use HAP instead?

In any event, if there was some hidden (and unintended) change
in functionality here, then the most likely result would seem to be
a crash, yet from the log fragment you posted it doesn't look like
there's _any_ relevant hypervisor output.

Jan


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

Re: [Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Marek Marczykowski-Górecki]

On Mon, Sep 05, 2016 at 10:39:16AM +0100, Wei Liu wrote:
> On Mon, Sep 05, 2016 at 11:26:04AM +0200, Marek Marczykowski-Górecki wrote:
> > Fill backend_domid field based on backend path.
> > 
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > Signed-off-by: Marek Marczykowski-Górecki 
> 
> Acked-by: Wei Liu 
> 
> I think this is a backport candidate?

Yes, certainly. If you want I can send a 4.7 version (function is in
libxl.c there).

In general, should I somehow somehow request a backport in the patch
itself? How?

> > ---
> >  tools/libxl/libxl_nic.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
> > index c34b7ba..d1caa90 100644
> > --- a/tools/libxl/libxl_nic.c
> > +++ b/tools/libxl/libxl_nic.c
> > @@ -309,6 +309,18 @@ static int libxl__device_nic_from_xenstore(libxl__gc 
> > *gc,
> >  else
> >  nic->devid = 0;
> >  
> > +rc = libxl__xs_read_checked(gc, XBT_NULL,
> > +GCSPRINTF("%s/backend", libxl_path), );
> > +if (rc) goto out;
> > +
> > +if (!tmp) {
> > +LOG(ERROR, "nic %s does not exist (no backend path)", libxl_path);
> > +rc = ERROR_FAIL;
> > +goto out;
> > +}
> > +rc = libxl__backendpath_parse_domid(gc, tmp, >backend_domid);
> > +if (rc) goto out;
> > +
> >  /* nic->mtu = */
> >  
> >  rc = libxl__xs_read_checked(gc, XBT_NULL,
> > -- 
> > 2.5.5
> > 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[linux]

On 2016-08-25 23:18, li...@eikelenboom.it wrote:

On 2016-08-25 22:34, Doug Goldstein wrote:

On 8/25/16 4:21 PM, li...@eikelenboom.it wrote:
Today i tried to switch some of my HVM guests (qemu-xen) from booting 
of

a kernel *inside* the guest, to a dom0 supplied kernel, which is
described as "Direct Kernel Boot" here:
https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html :

Direct Kernel Boot

Direct kernel boot allows booting directly from a kernel and 
initrd

stored in the host physical
machine OS, allowing command line arguments to be passed 
directly.

PV guest direct kernel boot
is supported. HVM guest direct kernel boot is supported with
limitation (it's supported when
using qemu-xen and default BIOS 'seabios'; not supported in case 
of

stubdom-dm and old rombios.)

kernel="PATHNAME"Load the specified file as the kernel image.
ramdisk="PATHNAME"   Load the specified file as the ramdisk.

But qemu fails to start, output appended below.

I tested with:
- current Xen-unstable, which fails.
- xen-stable-4.7.0 release, which fails.
- xen-stable-4.6.0 release, works fine.


Can you include the logs from xl dmesg around that time frame as well?


Ah i thought there wasn't any, but didn't check thoroughly or wasn't 
there

since the release builds are non-debug by default.

However, back on xen-unstable:
(XEN) [2016-08-25 21:09:15.172] HVM19 save: CPU
(XEN) [2016-08-25 21:09:15.172] HVM19 save: PIC
(XEN) [2016-08-25 21:09:15.172] HVM19 save: IOAPIC
(XEN) [2016-08-25 21:09:15.172] HVM19 save: LAPIC
(XEN) [2016-08-25 21:09:15.172] HVM19 save: LAPIC_REGS
(XEN) [2016-08-25 21:09:15.172] HVM19 save: PCI_IRQ
(XEN) [2016-08-25 21:09:15.172] HVM19 save: ISA_IRQ
(XEN) [2016-08-25 21:09:15.172] HVM19 save: PCI_LINK
(XEN) [2016-08-25 21:09:15.172] HVM19 save: PIT
(XEN) [2016-08-25 21:09:15.172] HVM19 save: RTC
(XEN) [2016-08-25 21:09:15.172] HVM19 save: HPET
(XEN) [2016-08-25 21:09:15.172] HVM19 save: PMTIMER
(XEN) [2016-08-25 21:09:15.172] HVM19 save: MTRR
(XEN) [2016-08-25 21:09:15.172] HVM19 save: VIRIDIAN_DOMAIN
(XEN) [2016-08-25 21:09:15.172] HVM19 save: CPU_XSAVE
(XEN) [2016-08-25 21:09:15.172] HVM19 save: VIRIDIAN_VCPU
(XEN) [2016-08-25 21:09:15.172] HVM19 save: VMCE_VCPU
(XEN) [2016-08-25 21:09:15.172] HVM19 save: TSC_ADJUST
(XEN) [2016-08-25 21:09:15.172] HVM19 restore: CPU 0
(XEN) [2016-08-25 21:09:16.126] d0v1 Over-allocation for domain 19:
262401 > 262400
(XEN) [2016-08-25 21:09:16.126] memory.c:213:d0v1 Could not allocate
order=0 extent: id=19 memflags=0 (192 of 512)

Hmm some off by one issue ?



Just wondering how much RAM you're domain is defined with as well?


1024 Mb, there is more than enough unallocated memory for xen to start
the guest (and dom0 is fixed with dom0_mem=1536M,max:1536M and
ballooning is off)



Hmm it seems my thread was kind of hijacked and i was dropped from the 
CC.


I had some time and bisected the issue and it resulted in:

5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f is the first bad commit
commit 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f
Author: Jan Beulich 
Date:   Wed Oct 21 10:56:31 2015 +0200

x86/shadow: drop stray name tags from sh_{guest_get,map}_eff_l1e()

They (as a now being removed comment validly says) depend only on 
Xen's

number of page table levels, and hence their tags didn't serve any
useful purpose (there could only ever be one instance in a single
binary, even back in the x86-32 days).

Further conditionalize the inclusion of PV-specific hook pointers, 
at
once making sure that PV guests can't ever get other than 4-level 
mode

enabled for them.

For consistency reasons shadow_{write,cmpxchg}_guest_entry() also 
get
moved next to the other PV-only actors, allowing them to become 
static

just like the $subject ones do.

Signed-off-by: Jan Beulich 
Acked-by: Tim Deegan 

:04 04 0c2e3475f81547f934a5960d9f1ac4849707d4ed 
f17f5ff17ca50d6ab908afe9a2d8555d954d3d0a M  xen



--
Sander




--
Sander


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

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

[Jan Beulich]

>>> On 02.09.16 at 19:53,  wrote:
> [PAUL] in line

Please configure your mail client to use proper quoting.

> From: Jan Beulich [mailto:jbeul...@suse.com] 
> Sent: Friday, September 2, 2016 6:47 AM
 On 19.08.16 at 19:22,  wrote:
>> Ravi Sahita's dynamically allocated altp2m structs
> 
> I think I've asked before: With this and ...
> 
>> Signed-off-by: Paul Lai 
>> Reviewed-by: Ravi Sahita 
> 
> ... this - who's the actual author?
> 
> [PAUL] Ravi is the actual author.  I thought the commit message would have 
> been clear :(

The commit message by itself is clear, but it contradicts the absence
of a From: tag, may also contradict the S-o-b one (albeit it's not
impossible for someone to sign off on someone else's work), and it's
certainly bogus for him to give a R-b for his own patch.

Jan


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

[Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Juergen Gross]

Add a new xl command "qemu-monitor-command" to issue arbitrary commands
to a domain's device model. Syntax is:

xl qemu-monitor-command  

The command is issued via qmp human-monitor-command command. Any
information returned by the command is printed to stdout.

Signed-off-by: Juergen Gross 
---
 docs/man/xl.pod.1.in   | 21 +
 tools/libxl/libxl.h| 14 ++
 tools/libxl/libxl_colo_qdisk.c |  2 +-
 tools/libxl/libxl_internal.h   |  3 ++-
 tools/libxl/libxl_qmp.c| 38 --
 tools/libxl/xl.h   |  1 +
 tools/libxl/xl_cmdimpl.c   | 27 +++
 tools/libxl/xl_cmdtable.c  |  5 +
 8 files changed, 107 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 1adf322..f1bf9b2 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1516,6 +1516,27 @@ List pass-through usb devices for a domain.
 
 =back
 
+=head1 DEVICE-MODEL CONTROL
+
+=over 4
+
+=item B I I
+
+Issue a monitor command to the device model of the domain specified by
+I. I can be any valid command qemu understands. This
+can be e.g. used to add non-standard devices or devices with non-standard
+parameters to a domain. The output of the command is printed to stdout.
+
+B
+
+Obtain information of USB devices connected via the device model to a
+domain:
+
+ xl qemu-monitor-command vm1 'info usb'
+  Device 0.2, Port 5, Speed 480 Mb/s, Product Mass Storage
+
+=back
+
 =head1 TMEM
 
 =over 4
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e4c25c4..7cfa540 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -275,6 +275,12 @@
 #define LIBXL_HAVE_BUILD_ID 1
 
 /*
+ * LIBXL_HAVE_QEMU_MONITOR_COMMAND indiactes the availability of the
+ * libxl_qemu_monitor_command() function.
+ */
+#define LIBXL_HAVE_QEMU_MONITOR_COMMAND 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
@@ -2152,6 +2158,14 @@ void libxl_psr_cat_info_list_free(libxl_psr_cat_info 
*list, int nr);
 int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
 int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
 
+/*
+ * Issue a qmp monitor command to the device model of the specified domain.
+ * The function returns the output of the command in a new allocated buffer
+ * via output.
+ */
+int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
+   const char *command_line, char **output);
+
 #include 
 
 #endif /* LIBXL_H */
diff --git a/tools/libxl/libxl_colo_qdisk.c b/tools/libxl/libxl_colo_qdisk.c
index c23b81b..d271d1f 100644
--- a/tools/libxl/libxl_colo_qdisk.c
+++ b/tools/libxl/libxl_colo_qdisk.c
@@ -173,7 +173,7 @@ static void colo_qdisk_save_preresume(libxl__egc *egc,
 "file.driver=nbd,file.host=%s,file.port=%d,"
 "file.export=%s,node-name=%s,if=none",
 host, port, export_name, node);
-ret = libxl__qmp_hmp(gc, domid, cmd);
+ret = libxl__qmp_hmp(gc, domid, cmd, NULL);
 if (ret)
 rc = ERROR_FAIL;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ce8e17a..9f534c4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1818,7 +1818,8 @@ _hidden int libxl__qmp_x_blockdev_change(libxl__gc *gc, 
int domid,
  const char *parant,
  const char *child, const char *node);
 /* run a hmp command in qmp mode */
-_hidden int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line);
+_hidden int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line,
+   char **out);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 63c49c5..33883b8 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1103,14 +1103,48 @@ int libxl__qmp_x_blockdev_change(libxl__gc *gc, int 
domid, const char *parent,
 return qmp_run_command(gc, domid, "x-blockdev-change", args, NULL, NULL);
 }
 
-int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line)
+static int hmp_callback(libxl__qmp_handler *qmp,
+const libxl__json_object *response,
+void *opaque)
+{
+char **output = opaque;
+GC_INIT(qmp->ctx);
+int rc = 0;
+
+if (!output)
+goto out;
+
+*output = NULL;
+
+if (libxl__json_object_is_string(response)) {
+*output = libxl__strdup(gc, libxl__json_object_get_string(response));
+goto out;
+}
+
+LOG(ERROR, "Response has unexpected format");
+rc = ERROR_FAIL;
+
+out:
+return rc;
+}
+
+int libxl__qmp_hmp(libxl__gc *gc, int domid, const char 

Re: [Xen-devel] [PATCH] libxc: zero-initialize structures in macros

[Wei Liu]

On Fri, Sep 02, 2016 at 11:22:04AM -0600, Tamas K Lengyel wrote:
> On Fri, Sep 2, 2016 at 11:18 AM, Andrew Cooper
>  wrote:
> > On 02/09/16 17:39, Tamas K Lengyel wrote:
> >> While debugging applications built on top of libxc with Valgrind we get a 
> >> lot
> >> of complaining about relying on uninitialized values allocated in libxc.
> >> While these warnings are safe to ignore, zero-initializing the structures
> >> reduces Valgrind clutter a lot and aids in spotting real bugs.
> >>
> >> Signed-off-by: Tamas K Lengyel 
> >> ---
> >> Cc: Ian Jackson 
> >> Cc: Wei Liu 
> >> ---
> >>  tools/libxc/xc_private.h | 10 +-
> >>  1 file changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
> >> index 75b761c..4e9073b 100644
> >> --- a/tools/libxc/xc_private.h
> >> +++ b/tools/libxc/xc_private.h
> >> @@ -59,11 +59,11 @@ struct iovec {
> >>  #include 
> >>  #endif
> >>
> >> -#define DECLARE_DOMCTL struct xen_domctl domctl
> >> -#define DECLARE_SYSCTL struct xen_sysctl sysctl
> >> -#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
> >> -#define DECLARE_FLASK_OP struct xen_flask_op op
> >> -#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op
> >> +#define DECLARE_DOMCTL struct xen_domctl domctl = {0}
> >> +#define DECLARE_SYSCTL struct xen_sysctl sysctl = {0}
> >> +#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = {0}
> >> +#define DECLARE_FLASK_OP struct xen_flask_op op = {0}
> >> +#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op = {0}
> >
> > I specifically took those out in the past, because it hides real
> > problems from Valgrind.
> >
> > Instead, I would recommend removing these wrappers entirely.  They serve
> > no useful purpose.
> >
> > Taking a random example of xc_get_pfn_type_batch(), it would be rather
> > more efficient to write
> >
> > ...
> > DECLARE_HYPERCALL_BOUNCE(arr, sizeof(*arr) * num,
> > XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> > struct xen_domctl domctl = {
> > .cmd = XEN_DOMCTL_getpageframeinfo3,
> > .domain = dom,
> > .u.getpageframeinfo3.num = num,
> > };
> > ...
> >
> > as it permits the compiler more freedom in how xen_domctl gets
> > constructed, as well as being able to plainly see exactly what is done
> > to the memory.
> >
> 
> Yea I don't really see much point using these macros as they are
> either and the one you propose certainly would make more sense.
> 

One reason I can think of why we would want those macros is that we
don't want to change all locations when the code fragment changes. But I
don't see how code segment is going to change for the macros under
discussion.

All in all, I don't object to eliminating those macros. Ian?

Wei.

> Tamas

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

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Andrew Cooper]

On 05/09/16 10:51, Jan Beulich wrote:
 On 05.09.16 at 11:43,  wrote:
>> On 05/09/16 07:32, Jan Beulich wrote:
>> On 02.09.16 at 17:14,  wrote:
 On 01/09/16 16:27, Jan Beulich wrote:
>>> +{
>>> +if ( d->arch.x86_vendor == X86_VENDOR_AMD )
>>> +{
>>> +*eax = 0;
>>> +*ebx = 0;
>>> +*ecx = 0;
>>> +*edx = 0;
>>> +return;
>>> +}
>>> +if ( input >> 16 )
>>> +hvm_cpuid(0, , NULL, NULL, NULL);
>> Is this really the right way round?  The AMD method of "reserved always
>> as zero" is the more sane default to take.
> If anything I'd then say let's _always_ follow the AMD model.
 It would certainly be better to default to AMD, and special case others
 on an as-needed basis.

 Strictly speaking, following the AMD model is compatible with the
 "Reserved" nature specified for Intel.

 Lets just go with this.
>>> Done. But before sending v2, just to be clear: The group check
>>> which you also didn't like won't go away. That's because if we didn't
>>> do it, we'd hide all CPUID info outside the basic and extended group,
>>> in particular (in case we run virtualized ourselves) and leaves coming
>>> from the lower level hypervisor (most notably our own ones, if it's
>>> another Xen underneath).
>> Architecturally speaking, it is not ok for any of our guests to be able
>> to see our hypervisors leaves.
> I'm not convinced, and even less so by the generalization to groups
> like the Cyrix/VIA or Transmeta ones. Yes, some of the leaves there
> would likely need white listing to be applied just like what we do for
> some of the base and extended leaves. But even for those (base
> and extended) we don't hide everything (in particular we don't hide
> the respective lowest numbered subleaf), and hence I don't see why
> we should do so with all of the other groups.

Xen's handling is still broken (albeit it less than it used to be).  A
guest running under Xen should not be able to find any information not
explicitly controlled by Xen, because information leakage like this
causes problems on migrate, etc.

If at some point in the future we choose to extend the whitelist to
include new groups, that is fine.  However, groups which aren't already
explicitly handled by Xen should be excluded from guest view.

~Andrew

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

Re: [Xen-devel] [PATCH v6] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

[Jan Beulich]

>>> On 05.09.16 at 07:17,  wrote:
> SMEP/SMAP is a security feature to prevent kernel executing/accessing
> user address involuntarily, any such behavior will lead to a page fault.
> 
> SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
> SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
> PV guest which will suffer unknown SMEP/SMAP page fault when guest
> kernel attempt to access user address although SMEP/SMAP is close for
> PV guests.
> 
> This patch introduces a new boot option value "hvm" for "sm{e,a}p", it
> is going to diable SMEP/SMAP for Xen hypervisor while enable them for
> HVM. In this way, 32-bit PV guest will not suffer SMEP/SMAP security
> issue. Users can choose whether open SMEP/SMAP for Xen itself,
> especially when they are going to run 32-bit PV guests.
> 
> Signed-off-by: He Chen 

Reviewed-by: Jan Beulich 

albeit one style issue still wasn't taken care of (I'll try to remember
to clean this up when committing):

> @@ -111,6 +103,62 @@ struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 
> 0, 0, -1 };
>  
>  unsigned long __read_mostly mmu_cr4_features = XEN_MINIMAL_CR4;
>  
> +/* smep: Enable/disable Supervisor Mode Execution Protection (default on). */
> +#define SMEP_HVM_ONLY (-1)
> +static s8 __initdata opt_smep = 1;
> +static void __init parse_smep_param(char *s)
> +{
> +if ( !*s )
> +{
> +opt_smep = 1;
> +return;
> +}
> +
> +switch ( parse_bool(s) )
> +{
> +case 0:
> +opt_smep = 0;
> +return;
> +case 1:
> +opt_smep = 1;
> +return;
> +}
> +
> +if ( !strcmp(s, "hvm") )
> +{
> +opt_smep = SMEP_HVM_ONLY;
> +}

You still left unnecessary braces here.

Jan


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

Re: [Xen-devel] [PATCH] mini-os: add comments in Config.mk regarding new config options

[Samuel Thibault]

Juergen Gross, on Mon 05 Sep 2016 13:43:30 +0200, wrote:
> Add some comment in Config.mk what to do in case of adding new config
> options.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

> ---
>  Config.mk | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Config.mk b/Config.mk
> index 0e405bf..0baedd1 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -152,6 +152,11 @@ CFLAGS += -flto
>  LDFLAGS-$(clang) += -plugin LLVMgold.so
>  endif
>  
> +# When adding a new CONFIG_ option please make sure the test configurations
> +# under arch/*/testbuild/ are updated accordingly. Especially
> +# arch/*/testbuild/*-yes and arch/*/testbuild/*-no should set ALL possible
> +# CONFIG_ variables.
> +
>  # Configuration defaults
>  ifeq ($(TARGET_ARCH_FAM),x86)
>  CONFIG_PARAVIRT ?= y
> -- 
> 2.6.6
> 

-- 
Samuel
+#if defined(__alpha__) && defined(CONFIG_PCI)
+   /*
+* The meaning of life, the universe, and everything. Plus
+* this makes the year come out right.
+*/
+   year -= 42;
+#endif
(From the patch for 1.3.2: (kernel/time.c), submitted by Marcus Meissner)

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

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Jan Beulich]

>>> On 05.09.16 at 11:43,  wrote:
> On 05/09/16 07:32, Jan Beulich wrote:
> On 02.09.16 at 17:14,  wrote:
>>> On 01/09/16 16:27, Jan Beulich wrote:
>> +{
>> +if ( d->arch.x86_vendor == X86_VENDOR_AMD )
>> +{
>> +*eax = 0;
>> +*ebx = 0;
>> +*ecx = 0;
>> +*edx = 0;
>> +return;
>> +}
>> +if ( input >> 16 )
>> +hvm_cpuid(0, , NULL, NULL, NULL);
> Is this really the right way round?  The AMD method of "reserved always
> as zero" is the more sane default to take.
 If anything I'd then say let's _always_ follow the AMD model.
>>> It would certainly be better to default to AMD, and special case others
>>> on an as-needed basis.
>>>
>>> Strictly speaking, following the AMD model is compatible with the
>>> "Reserved" nature specified for Intel.
>>>
>>> Lets just go with this.
>> Done. But before sending v2, just to be clear: The group check
>> which you also didn't like won't go away. That's because if we didn't
>> do it, we'd hide all CPUID info outside the basic and extended group,
>> in particular (in case we run virtualized ourselves) and leaves coming
>> from the lower level hypervisor (most notably our own ones, if it's
>> another Xen underneath).
> 
> Architecturally speaking, it is not ok for any of our guests to be able
> to see our hypervisors leaves.

I'm not convinced, and even less so by the generalization to groups
like the Cyrix/VIA or Transmeta ones. Yes, some of the leaves there
would likely need white listing to be applied just like what we do for
some of the base and extended leaves. But even for those (base
and extended) we don't hide everything (in particular we don't hide
the respective lowest numbered subleaf), and hence I don't see why
we should do so with all of the other groups.

Jan

> The current call to cpuid_hypervisor_leaves() will clobber information
> from the outer hypervisor anyway (although I observe that dom0 running
> under Xen under Xen can observe the outer Xen leaves if L1 is configured
> with both Xen+Viridian).
> 
> I will be fixing this information leakage.  As for these bounds checks,
> I would put the checks after the cpuid_hypervisor_leaves() call, and
> exclude everything other than the base and extended groups.
> 
> ~Andrew




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

Re: [Xen-devel] [PATCH] x86emul: simplify prefix handling for VMFUNC

[Andrew Cooper]

On 05/09/16 10:13, Jan Beulich wrote:
> LOCK prefixes get dealt with elsewhere and 66, F2, and F3 can all be
> checked for in one go by looking at vex.pfx.
>
> Signed-off-by: Jan Beulich 

As far as subsuming the checks goes, this is fine.  However, is the code
actually correct?  The manual makes no indication that the use of these
prefixes is prohibited.

~Andrew

>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -3942,8 +3942,8 @@ x86_emulate(
>  goto rdtsc;
>  }
>  case 0xd4: /* vmfunc */
> -generate_exception_if(lock_prefix | rep_prefix() | (vex.pfx == 
> vex_66),
> -  EXC_UD, -1);
> +if ( vex.pfx )
> +break;
>  fail_if(ops->vmfunc == NULL);
>  if ( (rc = ops->vmfunc(ctxt) != X86EMUL_OKAY) )
>  goto done;
>
>
>


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

Re: [Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Wei Liu]

On Mon, Sep 05, 2016 at 11:44:46AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 05, 2016 at 10:39:16AM +0100, Wei Liu wrote:
> > On Mon, Sep 05, 2016 at 11:26:04AM +0200, Marek Marczykowski-Górecki wrote:
> > > Fill backend_domid field based on backend path.
> > > 
> > > Cc: Ian Jackson 
> > > Cc: Wei Liu 
> > > Signed-off-by: Marek Marczykowski-Górecki 
> > > 
> > 
> > Acked-by: Wei Liu 
> > 
> > I think this is a backport candidate?
> 
> Yes, certainly. If you want I can send a 4.7 version (function is in
> libxl.c there).
> 

That would be helpful. Please use PATCH for-4.7 tag and use the
technique I describe below to add postscript that you don't wish to be
in commit message.

> In general, should I somehow somehow request a backport in the patch
> itself? How?

State between the three dashes anything you wish to say --- the content
would be automatically stripped out when committing. I normally do like
this in commit message


libxl: fix foo

Foo is broken because of X, fix it by doing Y.

Signed-off-by: Wei Liu 
---
Please backport to version Z of Xen.


> 
> > > ---
> > >  tools/libxl/libxl_nic.c | 12 
> > >  1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
> > > index c34b7ba..d1caa90 100644
> > > --- a/tools/libxl/libxl_nic.c
> > > +++ b/tools/libxl/libxl_nic.c
> > > @@ -309,6 +309,18 @@ static int libxl__device_nic_from_xenstore(libxl__gc 
> > > *gc,
> > >  else
> > >  nic->devid = 0;
> > >  
> > > +rc = libxl__xs_read_checked(gc, XBT_NULL,
> > > +GCSPRINTF("%s/backend", libxl_path), 
> > > );
> > > +if (rc) goto out;
> > > +
> > > +if (!tmp) {
> > > +LOG(ERROR, "nic %s does not exist (no backend path)", 
> > > libxl_path);
> > > +rc = ERROR_FAIL;
> > > +goto out;
> > > +}
> > > +rc = libxl__backendpath_parse_domid(gc, tmp, >backend_domid);
> > > +if (rc) goto out;
> > > +
> > >  /* nic->mtu = */
> > >  
> > >  rc = libxl__xs_read_checked(gc, XBT_NULL,
> > > -- 
> > > 2.5.5
> > > 
> 
> -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?



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

Re: [Xen-devel] [PATCH] x86emul: simplify prefix handling for VMFUNC

[Jan Beulich]

>>> On 05.09.16 at 11:52,  wrote:
> On 05/09/16 10:13, Jan Beulich wrote:
>> LOCK prefixes get dealt with elsewhere and 66, F2, and F3 can all be
>> checked for in one go by looking at vex.pfx.
>>
>> Signed-off-by: Jan Beulich 
> 
> As far as subsuming the checks goes, this is fine.  However, is the code
> actually correct?  The manual makes no indication that the use of these
> prefixes is prohibited.

Hmm, indeed (and I probably should have checked). Looking at e.g.
XEND and XTEST (which is how I came here) I wonder though
whether the manual is wrong. Let's see if we can get this figured
out. Ravi, Paul: Said checks originate from commit a1b1572833
("VMX: add VMFUNC leaf 0 (EPTP switching) to emulator"). Can you
please clarify whether they got added in error, or whether you
have knowledge the SDM doesn't expose?

Thanks, Jan


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

Re: [Xen-devel] [PATCH] libxl: update flex output files for DSA 3653-2

[Ian Jackson]

Wei Liu writes ("[PATCH] libxl: update flex output files for DSA 3653-2"):
> We updated flex output files in 4b314c89 ("libxl: update flex output
> files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
> discovered the fix to flex was incomplete and issued DSA 3653-2. We need
> to update our flex output files accordingly.

*sigh*

Acked-by: Ian Jackson 

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

[Xen-devel] Test Meetup at Developer Summit

[Lars Kurth]

== Attendees ==
Lars Kurth
George Dunlap
Doug Goldstein
Andrew Cooper
Paul Durrant

There were a few others, which I may have missed

I tried to transcribe from a recording we had at lunch, but due to background 
noise I didn't get everything. Please add/correct, if I got something wrong. 
There was a bit of discussion, but I tried to capture the key points only (e.g. 
I omitted clarifying questions)

== Discussion: Travis Improvements ==

Doug, wanted to discuss changes to the project's Travis set-up
* Reconfiguring Travis set-up such that it launches docker containers to do 
very basic smoke testing of individual commits on a number of different build 
configurations
* Right now this would require running a script running inside a script
* The key question is what matrix to support: e.g. which compiler versions, 
whether it should cover deb builds, ...
* It is basically just a build test, with a very basic run-test within an 
emulated qemu environment to check whether we boot. Aka booting a small image 
that is cross-compiled against various environments that produces "Hello World" 
on the first available serial-port
* If "Hello World" was produced, then Travis would decide the build was 
successful

George: over OSSTEST what value would this add? 
Doug: feedback about 7-8 minutes after a push with some confidence that a build 
was not broken, faster than OSSTEST does now. Obviously this would not replace 
OSSTEST, but should reduce the number of build-related issues in OSSTEST
Andrew: This should help quite a lot with avoiding spotting build related 
issues earlier
Doug: Would help avoid unnecessary manual build testing
George: Should help committers also 
Lars: Are there any extra requirements for people to use?
Andrew: Needs an account and set-up on GitHub

In summary: such a set-up would not compete with OSSTEST, but should decrease 
the number of build related OSSTEST failures, wasting fewer people's time if 
there are build related failures and increases OSSTEST throughput

Andrew, is not 100% sure how much extra confidence the "Hello World" test part 
will actually provide. However, Andrew also states that he does boot-testing 
before committing a major series. 

Random boot-tests on random config's (e.g. KConfigs) may also be valuable. But 
the challenge is what to test against, in OSSTEST, and how to know which test 
would succeed for which config. 

Paul: couldn't we build in something into XTF? ... there was a bit of 
discussion around this, but the audio was very hard to understand ... there was 
a discussion around skipping tests, but not quite knowing which ones should 
legitimately fail in a given configuration, or whether a skip was wrongly 
configured, or a git time-out. We would need to have more information about the 
"intent" of an OSSTEST to better help with random config tests. Andrew: thinks 
that for random build config tests, Travis CI may be more suitable than OSSTEST 
and require fewer plumbing changes, due to the faster turn-around and less 
complexity and scope for infrastructure related time-outs, etc. That is not to 
say that we shouldn't look are OSSTEST for functional config tests.

Andy: suggested a "presence test" in XTF for testing whether a specific config 
exists in a given binary, which could be used as a building block in OSSTEST 
for functional config tests. 

ASIDE: I would say that Doug and other participants, fill out this section, as 
I lost a lot of it, and may have misrepresented. 

Summary: In summary, we discussed
- Improvements to the Travis setup in particular for various build configs
- Possible improvements to OSSTEST / XTF for (random) config tests 
- There was no major objection

== Discussion: GitHub vs. GitLab for Travis ==
The second set of topics was to move from GitHub to GitLab for Build-testing 
due to the code availability issues with GitHub. Doug uses GitLab internally 
and is also more functional that GitHub. 

GitLab can be used hosted (for free projects) or host it locally on a VM

Doug: would probably require taking the github yaml and rewrite as gitlab yam. 
There are a number of advantages on OS support and docker integration, which 
makes set-up a lot easier compared to github.

Andy: if we were going to do this, the project should probably get a support 
license

Summary:
- Gather community input on GitHub vs. GitLab
- GitLab code is public, and thus should address 

There was also a bit of discussion about the review work-flow functionality in 
GitLab: just to clarify, we were not discussing any changes in this area. 
Merely to use GitLab as framework for Travis / Build testing and addressing 
some of the past issues that were raised around GitHub code availability.

== Supported / Unsupported / Preview / Experimental / ... ==

We should have some minimum tests and requirements for testing and 
configuration.

Andy: example - Intel MPX support is currently broken, because it was added 
when there was no available support. Because 

Re: [Xen-devel] [PATCH 23/24] xen: credit2: optimize runq_tickle() a little bit

[Dario Faggioli]

On Fri, 2016-09-02 at 13:38 +0100, anshul makkar wrote:
> On 17/08/16 18:20, Dario Faggioli wrote:
> > 
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > 
> > @@ -1102,13 +1110,26 @@ runq_tickle(const struct scheduler *ops, 
> >   for_each_cpu(i, )
> >   {
> > -/* Already looked at this one above */
> > -if ( i == cpu )
> > +/*
> > + * Already looked at these ones above, either because
> > it's the
> > + * cpu where new was running before, or because we are
> > at the
> > + * hard-affinity step, and we checked this during the
> > + * soft-affinity one
> > + */
> Sorry for my naiveness here,
>
NP.

>  but can we be sure that situation has not 
> changed since we checked during soft-affinity step. ?
>
Yes we can, since we're holding the runqueue lock.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Marek Marczykowski-Górecki]

Fill backend_domid field based on backend path.

Cc: Ian Jackson 
Cc: Wei Liu 
Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl_nic.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
index c34b7ba..d1caa90 100644
--- a/tools/libxl/libxl_nic.c
+++ b/tools/libxl/libxl_nic.c
@@ -309,6 +309,18 @@ static int libxl__device_nic_from_xenstore(libxl__gc *gc,
 else
 nic->devid = 0;
 
+rc = libxl__xs_read_checked(gc, XBT_NULL,
+GCSPRINTF("%s/backend", libxl_path), );
+if (rc) goto out;
+
+if (!tmp) {
+LOG(ERROR, "nic %s does not exist (no backend path)", libxl_path);
+rc = ERROR_FAIL;
+goto out;
+}
+rc = libxl__backendpath_parse_domid(gc, tmp, >backend_domid);
+if (rc) goto out;
+
 /* nic->mtu = */
 
 rc = libxl__xs_read_checked(gc, XBT_NULL,
-- 
2.5.5


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

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Jan Beulich]

>>> On 05.09.16 at 05:11,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 2, 2016 9:55 PM
>> To: Wu, Feng 
>> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> de...@lists.xen.org 
>> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
>> PI hooks
>> 
>> >>> On 02.09.16 at 15:15,  wrote:
>> 
>> >
>> >> -Original Message-
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Friday, September 2, 2016 6:46 PM
>> >> To: Wu, Feng 
>> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> >> de...@lists.xen.org 
>> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> assigning
>> >> PI hooks
>> >>
>> >> >>> On 02.09.16 at 12:30,  wrote:
>> >>
>> >> >
>> >> >> -Original Message-
>> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> Sent: Friday, September 2, 2016 5:26 PM
>> >> >> To: Wu, Feng 
>> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> >> >> de...@lists.xen.org 
>> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> >> assigning
>> >> >> PI hooks
>> >> >>
>> >> >> >>> On 02.09.16 at 10:40,  wrote:
>> >> >>
>> >> >> >
>> >> >> >> -Original Message-
>> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> >> Sent: Friday, September 2, 2016 4:16 PM
>> >> >> >> To: Wu, Feng 
>> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
>> xen-
>> >> >> >> de...@lists.xen.org 
>> >> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> >> >> assigning
>> >> >> >> PI hooks
>> >> >> >>
>> >> >> >> >>> On 02.09.16 at 09:31,  wrote:
>> >> >> >>
>> >> >> >> >
>> >> >> >> >> -Original Message-
>> >> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> >> >> Sent: Friday, September 2, 2016 3:04 PM
>> >> >> >> >> To: Wu, Feng 
>> >> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
>> >> xen-
>> >> >> >> >> de...@lists.xen.org 
>> >> >> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain
>> before/after
>> >> >> >> assigning
>> >> >> >> >> PI hooks
>> >> >> >> >>
>> >> >> >> >> >>> On 02.09.16 at 03:46,  wrote:
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> >> -Original Message-
>> >> >> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> >> >> >> Sent: Thursday, September 1, 2016 4:30 PM
>> >> >> >> >> >> To: Wu, Feng 
>> >> >> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin
>> ;
>> >> >> xen-
>> >> >> >> >> >> de...@lists.xen.org 
>> >> >> >> >> >> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain
>> >> before/after
>> >> >> >> >> assigning
>> >> >> >> >> >> PI hooks
>> >> >> >> >> >>
>> >> >> >> >> >> >>> On 31.08.16 at 05:56,  wrote:
>> >> >> >> >> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> >> >> >> >> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> >> >> >> >> >> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct
>> domain
>> >> *d)
>> >> >> >> >> >> >
>> >> >> >> >> >> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
>> >> >> >> >> >> >
>> >> >> >> >> >> > +/*
>> >> >> >> >> >> > + * Pausing the domain can make sure the vCPU is not
>> >> >> >> >> >> > + * running and hence calling the hooks simultaneously
>> >> >> >> >> >> > + * when deassigning the PI hooks. This makes sure that
>> >> >> >> >> >> > + * all the appropriate state of PI descriptor is 
>> >> >> >> >> >> > actually
>> >> >> >> >> >> > + * set up for all vCPus before leaving this function.
>> >> >> >> >> >> > + */
>> >> >> >> >> >> > +domain_pause(d);
>> >> >> >> >> >> > +
>> >> >> >> >> >> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
>> >> >> >> >> >> >  d->arch.hvm_domain.vmx.pi_do_resume =
>> vmx_pi_do_resume;
>> >> >> >> >> >> > +
>> >> >> >> >> >> > +domain_unpause(d);
>> >> >> >> >> >> >  }
>> >> >> >> >> >>
>> >> >> >> >> >> First of all I'm missing a word on whether the race mentioned 
>> >> >> >> >> >> in
>> >> >> >> >> >> the description and comment can actually happen. Device
>> >> >> >> >> >> (de)assignment should already be pretty much serialized (via
>> >> >> >> >> >> the domctl lock, and maybe also via the pcidevs one).
>> >> >> >> >> >
>> >> >> >> >> > 

Re: [Xen-devel] [PATCH] tools/firmware: Rename bios.bin to seabios.bin

[Andrew Cooper]

On 05/09/16 09:09, Anthony PERARD wrote:
> On Mon, Aug 22, 2016 at 11:24:05AM +0100, Wei Liu wrote:
>> On Fri, Aug 19, 2016 at 03:26:23PM +0100, Andrew Cooper wrote:
>>> bios.bin as a name is far too generic.  Rename it to seabios.bin.
>>>
>>> Signed-off-by: Andrew Cooper 
>> Hmm... I remember the first few versions of that series had it named
>> seabios.bin and I acked that.
>>
>> Anyway, I think I will give Anthony a chance to clarify why he changed
>> the name.
> I've changed it because someone ask for it:
> https://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02371.html

It was admittedly lacking a question mark, but that was a question not a
statement.

The answer is "because there are a load of other bios binaries stored in
the same directory".

> It was to match how seabios is installed by default.

This is not relevant.  The version of seabios built by Xen should fit
into the Xen expectations.  If this means renaming it to make it clear
which bios it it, then so be it.

~Andrew

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

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Andrew Cooper]

On 05/09/16 07:32, Jan Beulich wrote:
 On 02.09.16 at 17:14,  wrote:
>> On 01/09/16 16:27, Jan Beulich wrote:
> +{
> +if ( d->arch.x86_vendor == X86_VENDOR_AMD )
> +{
> +*eax = 0;
> +*ebx = 0;
> +*ecx = 0;
> +*edx = 0;
> +return;
> +}
> +if ( input >> 16 )
> +hvm_cpuid(0, , NULL, NULL, NULL);
 Is this really the right way round?  The AMD method of "reserved always
 as zero" is the more sane default to take.
>>> If anything I'd then say let's _always_ follow the AMD model.
>> It would certainly be better to default to AMD, and special case others
>> on an as-needed basis.
>>
>> Strictly speaking, following the AMD model is compatible with the
>> "Reserved" nature specified for Intel.
>>
>> Lets just go with this.
> Done. But before sending v2, just to be clear: The group check
> which you also didn't like won't go away. That's because if we didn't
> do it, we'd hide all CPUID info outside the basic and extended group,
> in particular (in case we run virtualized ourselves) and leaves coming
> from the lower level hypervisor (most notably our own ones, if it's
> another Xen underneath).

Architecturally speaking, it is not ok for any of our guests to be able
to see our hypervisors leaves.

The current call to cpuid_hypervisor_leaves() will clobber information
from the outer hypervisor anyway (although I observe that dom0 running
under Xen under Xen can observe the outer Xen leaves if L1 is configured
with both Xen+Viridian).

I will be fixing this information leakage.  As for these bounds checks,
I would put the checks after the cpuid_hypervisor_leaves() call, and
exclude everything other than the base and extended groups.

~Andrew

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

Re: [Xen-devel] [PATCH] libxl: update flex output files for DSA 3653-2

[Wei Liu]

On Mon, Sep 05, 2016 at 11:24:45AM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxl: update flex output files for DSA 3653-2"):
> > We updated flex output files in 4b314c89 ("libxl: update flex output
> > files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
> > discovered the fix to flex was incomplete and issued DSA 3653-2. We need
> > to update our flex output files accordingly.
> 
> *sigh*
> 
> Acked-by: Ian Jackson 

Pushed. Thanks.

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

Re: [Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Wei Liu]

On Mon, Sep 05, 2016 at 11:39:22AM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] libxl: do not assume Dom0 backend while getting 
> nic info"):
> > On Mon, Sep 05, 2016 at 11:44:46AM +0200, Marek Marczykowski-Górecki wrote:
> > > Yes, certainly. If you want I can send a 4.7 version (function is in
> > > libxl.c there).
> 
> Thanks for the backport.
> 
> Wei, can you mail me here (or tell me on irc) when the unstable fix
> goes into staging ?
> 

This patch is now in staging.

Wei.

> Thanks,
> Ian.

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

Re: [Xen-devel] [PATCH] tools/firmware: Rename bios.bin to seabios.bin

[Wei Liu]

On Mon, Sep 05, 2016 at 10:31:21AM +0100, Wei Liu wrote:
> On Mon, Sep 05, 2016 at 10:28:25AM +0100, Andrew Cooper wrote:
> > On 05/09/16 09:09, Anthony PERARD wrote:
> > > On Mon, Aug 22, 2016 at 11:24:05AM +0100, Wei Liu wrote:
> > >> On Fri, Aug 19, 2016 at 03:26:23PM +0100, Andrew Cooper wrote:
> > >>> bios.bin as a name is far too generic.  Rename it to seabios.bin.
> > >>>
> > >>> Signed-off-by: Andrew Cooper 
> > >> Hmm... I remember the first few versions of that series had it named
> > >> seabios.bin and I acked that.
> > >>
> > >> Anyway, I think I will give Anthony a chance to clarify why he changed
> > >> the name.
> > > I've changed it because someone ask for it:
> > > https://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02371.html
> > 
> > It was admittedly lacking a question mark, but that was a question not a
> > statement.
> > 
> > The answer is "because there are a load of other bios binaries stored in
> > the same directory".
> > 
> > > It was to match how seabios is installed by default.
> > 
> > This is not relevant.  The version of seabios built by Xen should fit
> > into the Xen expectations.  If this means renaming it to make it clear
> > which bios it it, then so be it.
> 
> I think renaming it to seabios.bin is better.
> 
> Acked-by: Wei Liu 
> 

Fixed up conflict and pushed.

Wei.

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

[Xen-devel] Two new x86 boxes in Mass colo (nobling[01])

[Ian Jackson]

FYI

Dell and us have now finished the exchange of the two problematic test
machines oseleta* with two new machines nobling0 and nobling1.

I have finished running commissioning tests and they are mostly
looking good.  However, I am going to hold off putting them into
service, because they expose a bug in current released versions of the
Debian installer kernel.

I see a crash in identify_boot_cpu / identify_cpu, from d-i inside a
PV guest.  It's reproducible, but affects only 32-bit PV guests.

Andrew Cooper helpfully looked at my stack trace and observed that the
bug was very likely lack of 581b7f158fe0383b492acd1ce3fb4e99d4e57808
in Debian's kernel.  The Debian kernel in question has version
3.16.7-ckt20-1+deb8u2 and the fix is in 3.16.7-ckt22.

Debian intend to do a stable point release on the 17th of September,
and I observe that jessie-proposed-updates contains linux
3.16.7-ckt25-2+deb8u2.  So I think the Debian point release will fix
it.

Ian.

This mail is partly a note to myself :-).

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

Re: [Xen-devel] [PATCH 19/24] xen: credit2: soft-affinity awareness in load balancing

[Dario Faggioli]

On Fri, 2016-09-02 at 12:46 +0100, anshul makkar wrote:

Hey, Anshul,

Thanks for having a look at the patch!

> On 17/08/16 18:19, Dario Faggioli wrote:
> > 
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > 
> > + * Basically, if a soft-affinity is defined, the work done by a
> > vcpu on a
> > + * runq to which it has higher degree of soft-affinity, is
> > considered
> > + * 'lighter' than the same work done by the same vcpu on a runq to
> > which it
> > + * has smaller degree of soft-affinity (degree of soft affinity is
> > <= 1). In
> > + * fact, if soft-affinity is used to achieve NUMA-aware
> > scheduling, the higher
> > + * the degree of soft-affinity of the vcpu to a runq, the greater
> > the probability
> > + * of accessing local memory, when running on such runq. And that
> > is certainly\
> > + * 'lighter' than having to fetch memory from remote NUMA nodes.
> Do we ensure that while defining soft-affinity for a vcpu, NUMA 
> architecture is considered. If not, then this whole calculation can
> go 
> wrong and have negative impact on performance.
> 
Defining soft-affinity after topology is what we do by default, just
not here in Xen: we do it in toolstack (in libxl, to be precise).

NUMA aware scheduling is indeed the most obvious use case for all this
--and, in fact that's why we configure things in such a way in higher
layers-- but the mechanism is, at the Xen level, flexible enough to be
used for any purpose that the user may find interesting.

> Degree of affinity to runq will give good result if the affinity to 
> pcpus has been chosen after due consideration ..
>
At this level, 'good result' means 'making sure that a vcpu runs for as
much time as possible on a pcpu to which it has soft-affinity'. Whether
that is good or not for performance (or for any other aspect or
metric), it's not this algorithm's job to determine.

Note that things are exactly the same for hard-affinity/pinning, or for
weights. In fact, Xen won't stop one to, say, pin 128 vcpu all to pcpu
3. This will deeply suck, but it's the higher layers' will (fault?) and
Xen should just comply to that.

> > + * If there is no soft-affinity, load_balance() (actually,
> > consider()) acts
> > + * as follows:
> > + *
> > + *  - D = abs(Li - Lj)
> If we are consider absolute of Li -Lj, how will we know which runq
> has 
> less workload which, I think, is an essential parameter for load 
> balancing. Am I missing something here ?
>
What we are aiming for is making the queues more balanced, which means
we want the difference between their load to be smaller than how it is
when the balancing start. As far as that happens, we don't care which
loads goes down and which one goes up, as far as the final result is a
smaller load delta.

> > + *  - consider pushing v from I to J:
> > + * - D' = abs(Li - lv - (Lj + lv))   (from now, abs(x) == |x|)
> > + * - if (D' < D) { push }
> > + *  - consider pulling k from J to I:
> > + * - D' = |Li + lk - (Lj - lk)|
> > + * - if (D' < D) { pull }
> For both push and pull we are checking (D` < D) ?
>
Indeed. And that's because of the abs(). :-)


Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

[Jan Beulich]

>>> On 05.09.16 at 07:17,  wrote:
> @@ -1403,12 +1451,16 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  if ( !opt_smep )
>  setup_clear_cpu_cap(X86_FEATURE_SMEP);
> -if ( cpu_has_smep )
> +else if ( opt_smep == 1 )
> +__set_bit(X86_FEATURE_XEN_SMEP, boot_cpu_data.x86_capability);
> +if ( boot_cpu_has(X86_FEATURE_XEN_SMEP) )
>  set_in_cr4(X86_CR4_SMEP);
>  
>  if ( !opt_smap )
>  setup_clear_cpu_cap(X86_FEATURE_SMAP);
> -if ( cpu_has_smap )
> +else if ( opt_smap == 1 )
> +__set_bit(X86_FEATURE_XEN_SMAP, boot_cpu_data.x86_capability);
> +if ( boot_cpu_has(X86_FEATURE_XEN_SMAP) )
>  set_in_cr4(X86_CR4_SMAP);

This is still wrong, as spotted by osstest's smoke test: It in particular
doesn't work on a system which doesn't have SMEP and/or SMAP.
Please fix this while incorporating the other adjustments I did while
committing; I've reverted the patch until then.

Jan


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

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

[George Dunlap]

On Tue, Aug 9, 2016 at 11:40 AM, Jan Beulich  wrote:
> This doesn't cover all of them, just the ones that I think would most
> obviously better be -EINVAL or -EOPNOTSUPP.
>
> Signed-off-by: Jan Beulich 

FWIW:

Reviewed-by: George Dunlap 

>
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -440,7 +440,7 @@ int unmmap_broken_page(struct domain *d,
>  return -EINVAL;
>
>  if ( !has_hvm_container_domain(d) || !paging_mode_hap(d) )
> -return -ENOSYS;
> +return -EOPNOTSUPP;
>
>  rc = -1;
>  r_mfn = get_gfn_query(d, gfn, );
> --- a/xen/arch/x86/cpu/mtrr/main.c
> +++ b/xen/arch/x86/cpu/mtrr/main.c
> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
> printk(KERN_WARNING
>"mtrr: your processor doesn't support 
> write-combining\n");
> -   return -ENOSYS;
> +   return -EOPNOTSUPP;
> }
>
> if (!size) {
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5592,7 +5592,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
>  break;
>
>  case HVMOP_flush_tlbs:
> -rc = guest_handle_is_null(arg) ? hvmop_flush_tlb_all() : -ENOSYS;
> +rc = guest_handle_is_null(arg) ? hvmop_flush_tlb_all() : -EINVAL;
>  break;
>
>  case HVMOP_track_dirty_vram:
> @@ -5832,7 +5832,7 @@ int hvm_debug_op(struct vcpu *v, int32_t
>  {
>  case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON:
>  case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF:
> -rc = -ENOSYS;
> +rc = -EOPNOTSUPP;
>  if ( !cpu_has_monitor_trap_flag )
>  break;
>  rc = 0;
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3565,7 +3565,7 @@ long do_mmuext_op(
>  if ( !opt_allow_superpage )
>  {
>  MEM_LOG("Superpages disallowed");
> -rc = -ENOSYS;
> +rc = -EOPNOTSUPP;
>  }
>  else if ( unlikely(d != pg_owner) )
>  rc = -EPERM;
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -353,7 +353,7 @@ int compat_memory_op(unsigned int cmd, X
>  struct get_reserved_device_memory grdm;
>
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  if ( copy_from_guest(, compat, 1) ||
>   !compat_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
> --- a/xen/common/event_fifo.c
> +++ b/xen/common/event_fifo.c
> @@ -621,7 +621,7 @@ int evtchn_fifo_expand_array(const struc
>  int rc;
>
>  if ( !d->evtchn_fifo )
> -return -ENOSYS;
> +return -EOPNOTSUPP;
>
>  spin_lock(>event_lock);
>  rc = add_page_to_event_array(d, expand_array->array_gfn);
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3025,7 +3025,7 @@ do_grant_table_op(
>  return -EINVAL;
>
>  if ( (cmd &= GNTTABOP_CMD_MASK) != GNTTABOP_cache_flush && opaque_in )
> -return -ENOSYS;
> +return -EINVAL;
>
>  rc = -EFAULT;
>  switch ( cmd )
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -937,14 +937,14 @@ long do_memory_op(unsigned long cmd, XEN
>
>  case XENMEM_exchange:
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  rc = memory_exchange(guest_handle_cast(arg, xen_memory_exchange_t));
>  break;
>
>  case XENMEM_maximum_ram_page:
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  rc = max_page;
>  break;
> @@ -953,7 +953,7 @@ long do_memory_op(unsigned long cmd, XEN
>  case XENMEM_maximum_reservation:
>  case XENMEM_maximum_gpfn:
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  if ( copy_from_guest(, arg, 1) )
>  return -EFAULT;
> @@ -1077,7 +1077,7 @@ long do_memory_op(unsigned long cmd, XEN
>  struct page_info *page;
>
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  if ( copy_from_guest(, arg, 1) )
>  return -EFAULT;
> @@ -1114,7 +1114,7 @@ long do_memory_op(unsigned long cmd, XEN
>
>  case XENMEM_claim_pages:
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  if ( copy_from_guest(, arg, 1) )
>  return -EFAULT;
> @@ -1148,7 +1148,7 @@ long do_memory_op(unsigned long cmd, XEN
>  struct vnuma_info tmp;
>
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  /*
>   * Guest passes nr_vnodes, number of regions and nr_vcpus thus
> @@ 

Re: [Xen-devel] [MINIOS PATCH] Add travis.yml and travis-build script

[Samuel Thibault]

Wei Liu, on Mon 05 Sep 2016 15:43:21 +0100, wrote:
> Signed-off-by: Wei Liu 

Acked-by: Samuel Thibault 

> ---
> See:
> https://travis-ci.org/liuw/mini-os/builds/157653746
> 
> Cc: Samuel Thibault 
> Cc: Juergen Gross 
> Cc: Doug Goldstein 
> 
> IRC notification is not yet set up.
> 
> Doug, can we mirror mini-os.git to github/xen-project as well? I think
> it would also be a good idea to post notification to #xentest.
> ---
>  .travis.yml  | 25 +
>  scripts/travis-build |  5 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 .travis.yml
>  create mode 100755 scripts/travis-build
> 
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 000..9aa69a5
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,25 @@
> +language: c
> +dist: trusty
> +sudo: required
> +# don't test stable branches
> +branches:
> +except:
> +- /^stable-.*/
> +matrix:
> +include:
> +- compiler: gcc
> +addons:
> +apt:
> +sources:
> +- ubuntu-toolchain-r-test
> +packages:
> +- libc6-dev-i386
> +- gcc-5
> +- g++-5
> +# we must set CXX manually instead of using 'language: cpp' due to
> +# travis-ci/travis-ci#3871
> +before_script:
> +- export CXX=${CC/cc/++}
> +- export CXX=${CXX/clang/clang++}
> +script:
> +- ./scripts/travis-build
> diff --git a/scripts/travis-build b/scripts/travis-build
> new file mode 100755
> index 000..9480a9d
> --- /dev/null
> +++ b/scripts/travis-build
> @@ -0,0 +1,5 @@
> +#!/bin/bash -ex
> +
> +$CC --version
> +
> +make testbuild
> -- 
> 2.1.4
> 

-- 
Samuel
 ben oui ce serait idiot, mais osb
  -+- m'en fous de faire un truc débile ! -+-

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

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[Stefano Stabellini]

On Mon, 5 Sep 2016, Vitaly Kuznetsov wrote:
> Julien Grall  writes:
> 
> > Hi Vitaly,
> >
> > On 26/07/16 13:30, Vitaly Kuznetsov wrote:
> >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> >> particular, when we crash on a secondary vCPU we may want to do kdump
> >> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> >> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
> >> we have a number of hypercalls where we pass vCPU id as a parameter. These
> >> hypercalls either fail or do something unexpected. To solve the issue
> >> introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping
> >> for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
> >> CPUs it is a bit more trickier. Currently, we initialize IPI vectors
> >> before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
> >> instead.
> >>
> >> Signed-off-by: Vitaly Kuznetsov 
> >> ---
> >> Changes since v2:
> >> - Use uint32_t for xen_vcpu_id mapping [Julien Grall]
> >>
> >> Changes since v1:
> >> - Introduce xen_vcpu_nr() helper [David Vrabel]
> >> - Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
> >> ---
> >>  arch/arm/xen/enlighten.c | 10 ++
> >>  arch/x86/xen/enlighten.c | 23 ++-
> >>  include/xen/xen-ops.h|  6 ++
> >>  3 files changed, 38 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> index 75cd734..fe32267 100644
> >> --- a/arch/arm/xen/enlighten.c
> >> +++ b/arch/arm/xen/enlighten.c
> >> @@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
> >> *)_dummy_shared_info;
> >>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
> >>  static struct vcpu_info __percpu *xen_vcpu_info;
> >>
> >> +/* Linux <-> Xen vCPU id mapping */
> >> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
> >> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
> >> +
> >>  /* These are unused until we support booting "pre-ballooned" */
> >>  unsigned long xen_released_pages;
> >>  struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] 
> >> __initdata;
> >> @@ -179,6 +183,9 @@ static void xen_percpu_init(void)
> >>pr_info("Xen: initializing cpu%d\n", cpu);
> >>vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
> >>
> >> +  /* Direct vCPU id mapping for ARM guests. */
> >> +  per_cpu(xen_vcpu_id, cpu) = cpu;
> >> +
> >
> > We did some internal testing on ARM64 with the latest Linux kernel
> > (4.8-rc4) and noticed that this patch is breaking SMP support. Sorry
> > for noticing the issue that late.
> 
> Sorry for the breakage :-(
> 
> >
> > This function is called on the running CPU whilst some code (e.g
> > init_control_block in drivers/xen/events/events_fifo.c) is executed
> > whilst preparing the CPU on the boot CPU.
> >
> > So xen_vcpu_nr(cpu) will always return 0 in this case and
> > init_control_block will fail to execute.
> >
> 
> I see,
> 
> CPU_UP_PREPARE event happens before xen_starting_cpu() is called.
> 
> 
> > I am not sure how to fix. I guess we could setup per_cpu(xen_vcpu_id,
> > *) in xen_guest_init. Any opinions?
> 
> As we're not doing kexec on ARM we can fix the immediate issue. I don't
> know much about ARM and unfortunatelly I don't have a setup to test but
> it seems there is no early_per_cpu* infrastructure for ARM so we may fix
> it with the following:
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 3d2cef6..f193414 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -170,9 +170,6 @@ static int xen_starting_cpu(unsigned int cpu)
> pr_info("Xen: initializing cpu%d\n", cpu);
> vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>  
> -   /* Direct vCPU id mapping for ARM guests. */
> -   per_cpu(xen_vcpu_id, cpu) = cpu;
> -
> info.mfn = virt_to_gfn(vcpup);
> info.offset = xen_offset_in_page(vcpup);
>  
> @@ -330,6 +327,7 @@ static int __init xen_guest_init(void)
>  {
> struct xen_add_to_physmap xatp;
> struct shared_info *shared_info_page = NULL;
> +   int cpu;
>  
> if (!xen_domain())
> return 0;
> @@ -380,7 +378,8 @@ static int __init xen_guest_init(void)
> return -ENOMEM;
>  
> /* Direct vCPU id mapping for ARM guests. */
> -   per_cpu(xen_vcpu_id, 0) = 0;
> +   for_each_possible_cpu(cpu)
> +   per_cpu(xen_vcpu_id, cpu) = cpu;
>  
> xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
> if (xen_xlate_map_ballooned_pages(_auto_xlat_grant_frames.pfn,
> 
> (not tested, if we can't use for_each_possible_cpu() that early we'll
> have to check against NR_CPUS instead).

Kind of defeat the purpose of xen_vcpu_id, but I guess it should work.


> But unfortunatelly we'll have to get back to this in future. Turns out
> we need to know Xen's idea of vCPU id _before_ this vCPU starts
> 

[Xen-devel] [OSSTEST PATCH 04/26] rumprun: Rename all `rumpuserxen' to `rumprun'

[Ian Jackson]

The names have changed upstream.

Since upstream is no longer compatible and these tests have been
failing since then, we are going to treat this as an entirely new test
series.

In this patch we rename everything mechanically.  More interesting
changes will come later.

git-mv -f ts-rumpuserxen-build ts-rumprun-build
git-mv -f ts-rumpuserxen-demo-setup ts-rumprun-demo-setup
git-mv -f ts-rumpuserxen-demo-xenstorels ts-rumprun-demo-xenstorels

git-ls-files | xargs perl -i~ -pe 's/rumpuserxen/rumprun/g'
git-ls-files | xargs perl -i~ -pe 's/(_|\b)rumpuserxen(_|\b)/$1rumprun$2/g'

Signed-off-by: Ian Jackson 
---
 allow.all  |   4 +-
 allow.rumpuserxen  |   2 +-
 ap-common  |  16 +++---
 ap-fetch-version   |   6 +-
 ap-fetch-version-old   |   8 +--
 ap-print-url   |   4 +-
 ap-push|   8 +--
 cr-daily-branch|  12 ++--
 cri-common |   2 +-
 crontab|   4 +-
 make-flight|  14 ++---
 mfi-common |  16 +++---
 sg-run-job |  18 +++---
 ts-rumprun-build   | 126 +
 ts-rumprun-demo-setup  |  92 ++
 ts-rumprun-demo-xenstorels | 124 
 ts-rumpuserxen-build   | 126 -
 ts-rumpuserxen-demo-setup  |  92 --
 ts-rumpuserxen-demo-xenstorels | 124 
 19 files changed, 399 insertions(+), 399 deletions(-)
 create mode 100755 ts-rumprun-build
 create mode 100755 ts-rumprun-demo-setup
 create mode 100755 ts-rumprun-demo-xenstorels
 delete mode 100755 ts-rumpuserxen-build
 delete mode 100755 ts-rumpuserxen-demo-setup
 delete mode 100755 ts-rumpuserxen-demo-xenstorels

diff --git a/allow.all b/allow.all
index 785d0b2..c4a2854 100644
--- a/allow.all
+++ b/allow.all
@@ -2,6 +2,6 @@ test-@@-rtds@@
 build-@@logs-capture@@
 test-@@-pcipt@@
 test-@@-qemuu-@@   guest-localmigrate
-test-@@-rumpuserxen@@  rumpuserxen-demo-xenstorels/xenstorels
+test-@@-rumprun@@  rumprun-demo-xenstorels/xenstorels
 test-@@-win7-@@guest-stop
-test-@@-rumpuserxen-@@ rumpuserxen-demo-xenstorels/xenstorels.repeat
+test-@@-rumprun-@@ rumprun-demo-xenstorels/xenstorels.repeat
diff --git a/allow.rumpuserxen b/allow.rumpuserxen
index d9034a2..436417b 100644
--- a/allow.rumpuserxen
+++ b/allow.rumpuserxen
@@ -1 +1 @@
-!test-@@-rumpuserxen-@@
rumpuserxen-demo-xenstorels/xenstorels.repeat
+!test-@@-rumprun-@@rumprun-demo-xenstorels/xenstorels.repeat
diff --git a/ap-common b/ap-common
index 19c7580..6fe3b78 100644
--- a/ap-common
+++ b/ap-common
@@ -37,15 +37,15 @@
 : ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
 : ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
 
-: ${TREE_RUMPUSERXEN:=https://github.com/rumpkernel/rumprun-xen}
-: ${TREEVCS_RUMPUSERXEN:=git}
-: ${BASE_TREE_RUMPUSERXEN:=git://xenbits.xen.org/rumpuser-xen.git}
-: ${PUSH_TREE_RUMPUSERXEN:=$XENBITS:/home/xen/git/rumpuser-xen.git}
+: ${TREE_RUMPRUN:=https://github.com/rumpkernel/rumprun-xen}
+: ${TREEVCS_RUMPRUN:=git}
+: ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/rumpuser-xen.git}
+: ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/rumpuser-xen.git}
 
-: ${TREE_RUMPUSERXEN_RUMPSRC:=$(besteffort_repo 
https://github.com/rumpkernel/rumpkernel-netbsd-src)}
-: ${TREEVCS_RUMPUSERXEN_RUMPSRC:=git}
+: ${TREE_RUMPRUN_RUMPSRC:=$(besteffort_repo 
https://github.com/rumpkernel/rumpkernel-netbsd-src)}
+: ${TREEVCS_RUMPRUN_RUMPSRC:=git}
 # rumpsrc-related runvars needed only for old rumpuser-xen
-# (ie ones which need $bodges=1 in ts-rumpuserxen-build)
+# (ie ones which need $bodges=1 in ts-rumprun-build)
 
 : ${TREE_SEABIOS_UPSTREAM:=git://git.seabios.org/seabios.git}
 : ${PUSH_TREE_SEABIOS:=$XENBITS:/home/xen/git/osstest/seabios.git}
@@ -79,7 +79,7 @@ fi
 : ${LOCALREV_XEN:=daily-cron.$branch}
 : ${LOCALREV_LINUX:=daily-cron.$branch}
 : ${LOCALREV_LIBVIRT:=daily-cron.$branch}
-: ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
+: ${LOCALREV_RUMPRUN:=daily-cron.$branch}
 : ${LOCALREV_SEABIOS:=daily-cron.$branch}
 : ${LOCALREV_OVMF:=daily-cron.$branch}
 
diff --git a/ap-fetch-version b/ap-fetch-version
index f26d60a..8562159 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -90,9 +90,9 @@ libvirt)
repo_tree_rev_fetch_git libvirt \
$TREE_LIBVIRT master $LOCALREV_LIBVIRT
;;
-rumpuserxen)
-   repo_tree_rev_fetch_git rumpuserxen \
-   $TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
+rumprun)
+   repo_tree_rev_fetch_git rumprun \
+   $TREE_RUMPRUN master $LOCALREV_RUMPRUN
;;
 seabios)
repo_tree_rev_fetch_git 

Re: [Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[George Dunlap]

On 05/09/16 14:31, Jan Beulich wrote:
 On 02.09.16 at 12:47,  wrote:
>> @@ -178,8 +179,27 @@ static int hvmemul_do_io(
>>  break;
>>  case X86EMUL_UNHANDLEABLE:
>>  {
>> -struct hvm_ioreq_server *s =
>> -hvm_select_ioreq_server(curr->domain, );
>> +struct hvm_ioreq_server *s = NULL;
>> +p2m_type_t p2mt = p2m_invalid;
>> +
>> +if ( is_mmio )
>> +{
>> +unsigned long gmfn = paddr_to_pfn(addr);
>> +
>> +(void) get_gfn_query_unlocked(currd, gmfn, );
>> +
>> +if ( p2mt == p2m_ioreq_server && dir == IOREQ_WRITE )
>> +{
>> +unsigned int flags;
>> +
>> +s = p2m_get_ioreq_server(currd, );
>> +if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
>> +s = NULL;
>> +}
>> +}
>> +
>> +if ( !s && p2mt != p2m_ioreq_server )
>> +s = hvm_select_ioreq_server(currd, );
> 
> What I recall is that we had agreed on p2m_ioreq_server pages
> to be treated as ordinary RAM ones as long as no server can be
> found. The type check here contradicts that. Is there a reason?

I think it must be a confusion as to what "treated like ordinary RAM
ones" means.  p2m_ram_rw types that gets here will go through
hvm_select_ioreq_server(), and (therefore) potentially be treated as
MMIO accesses, which is not how "ordinary RAM" would behave.  If what
you meant was that you want p2m_ioreq_server to behave like p2m_ram_rw
(and be treated as MMIO if it matches an iorange) then yes.  If what you
want is for p2m_ioreq_server to actually act like RAM, then probably
something more needs to happen here.

 -George

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

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Stefano Stabellini]

On Fri, 2 Sep 2016, Julien Grall wrote:
> On 02/09/2016 18:45, Andrew Cooper wrote:
> > On 02/09/16 18:37, Tamas K Lengyel wrote:
> > > On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
> > >  wrote:
> > > > On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
> > > > > Add support for getting/setting registers through vm_event on ARM.
> > > > > Only
> > > > > TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is
> > > > > set
> > > > > as part of a response. The set of registers can be expanded in the
> > > > > future to
> > > > > include other registers as well if necessary.
> > > > > 
> > > > > Signed-off-by: Tamas K Lengyel 
> > > > > Reviewed-by: Andrew Cooper 
> > > > Acked-by: Razvan Cojocaru 
> > > Patch ping.
> > 
> > Requires an ARM ack.
> 
> I don't think it requires an ack from Stefano and I, it touches only the
> vm_event subsystem.
> 
> If you still want an ARM ack, then I will defer to Stefano.

Acked-by: Stefano Stabellini 

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

Re: [Xen-devel] [OSSTEST PATCH 0/7] Apropos of XTF: Improve failed step selection

[Wei Liu]

On 
> On Thu, Aug 11, 2016 at 05:17:56PM +0100, Ian Jackson wrote:
> > Running XTF in osstest is likely to produce failures where multiple
> > steps fail interestingly.  We would like to prefer to report, and
> > bisect, earlier steps.
> > 
> > This series does that.
> > 
> > Wei, NB, this has a conflict with the XTF pre series that you have
> > taken over.  The conflict is not trivial, but easy.  The conflicting
> > patch is:
> >   Executive: Previous duration estimator: use overall time, not sum of steps
> > 
> 
> The rebased patch is as followed, please check.
> 
> ---8<---
> From bbdc727965b4d4280bac670823f013d078a54b93 Mon Sep 17 00:00:00 2001
> From: Ian Jackson 
> Date: Fri, 8 Jul 2016 19:30:58 +0100
> Subject: [OSSTEST PATCH] Executive: Previous duration estimator: use overall
>  time, not sum of steps
> Cc: ian.jack...@eu.citrix.com
> 
> Some jobs runs steps in parallel.  Do not add up all the insividual
> step durations.  Instead, calculate the duration as the time between
> first step start and last step finish.
> 
> Signed-off-by: Ian Jackson 
> [ wei: rebase and fix conflict ]
> Signed-off-by: Wei Liu 
> ---
>  Osstest/Executive.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
> index 7e31b35..2187a73 100644
> --- a/Osstest/Executive.pm
> +++ b/Osstest/Executive.pm
> @@ -1068,7 +1068,7 @@ END
>FROM steps
>   WHERE flight=? AND job=?
>  )
> -SELECT sum(finished-started)
> +SELECT sum(max(finished)-min(started))
>  AS duration
>FROM tsteps
>   WHERE step != 'ts-hosts-allocate'
> -- 
> 2.1.4
> 


Hmm... there seems to be a problem with this patch.

http://osstest.xs.citrite.net/~osstest/testlogs/logs/67641/build-amd64-xtf/2.ts-hosts-allocate.log

2016-09-05 17:51:48 Z allocating hosts: host 
DBD::Pg::st execute failed: ERROR:  aggregate function calls cannot be nested
LINE 7: SELECT sum(max(finished)-min(started))
   ^ [for Statement "WITH tsteps AS 
(
SELECT *
  FROM steps
 WHERE flight=? AND job=?
)
SELECT sum(max(finished)-min(started))
AS duration
  FROM tsteps
 WHERE step != 'ts-hosts-allocate'
" with ParamValues: 1='67640', 2='build-amd64-xtf'] at Osstest/Executive.pm 
line 1127,  line 10.
resourcecall DBD::Pg::st execute failed: ERROR:  aggregate function calls 
cannot be nested
LINE 7: SELECT sum(max(finished)-min(started))
   ^ [for Statement "WITH tsteps AS 
(
SELECT *
  FROM steps
 WHERE flight=? AND job=?
)
SELECT sum(max(finished)-min(started))
AS duration
  FROM tsteps
 WHERE step != 'ts-hosts-allocate'
" with ParamValues: 1='67640', 2='build-amd64-xtf'] at Osstest/Executive.pm 
line 1127,  line 10.
Died at Osstest/Executive.pm line 903,  line 10.
+ rc=255
+ date -u +%Y-%m-%d %H:%M:%S Z exit status 255
2016-09-05 17:51:49 Z exit status 255
+ exit 255

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

[Xen-devel] [PULL 1/1] xen: use native disk xenbus protocol if possible

[Stefano Stabellini]

From: Juergen Gross 

The qdisk implementation is using the native xenbus protocol only in
case of no protocol specified at all. As using the explicit 32- or
64-bit protocol is slower than the native one due to copying requests
not by memcpy but element for element, this is not optimal.

Correct this by using the native protocol in case word sizes of
frontend and backend match.

Signed-off-by: Juergen Gross 
Reviewed-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 3b8ad33..3428689 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -976,14 +976,16 @@ static int blk_connect(struct XenDevice *xendev)
 blkdev->feature_persistent = !!pers;
 }
 
-blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
-if (blkdev->xendev.protocol) {
-if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
-blkdev->protocol = BLKIF_PROTOCOL_X86_32;
-}
-if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
-blkdev->protocol = BLKIF_PROTOCOL_X86_64;
-}
+if (!blkdev->xendev.protocol) {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_NATIVE) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_X86_32;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_X86_64;
+} else {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
 }
 
 blkdev->sring = xengnttab_map_grant_ref(blkdev->xendev.gnttabdev,
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[George Dunlap]

On 02/09/16 11:47, Yu Zhang wrote:
> A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
> let one ioreq server claim/disclaim its responsibility for the
> handling of guest pages with p2m type p2m_ioreq_server. Users
> of this HVMOP can specify which kind of operation is supposed
> to be emulated in a parameter named flags. Currently, this HVMOP
> only support the emulation of write operations. And it can be
> further extended to support the emulation of read ones if an
> ioreq server has such requirement in the future.
> 
> For now, we only support one ioreq server for this p2m type, so
> once an ioreq server has claimed its ownership, subsequent calls
> of the HVMOP_map_mem_type_to_ioreq_server will fail. Users can also
> disclaim the ownership of guest ram pages with p2m_ioreq_server, by
> triggering this new HVMOP, with ioreq server id set to the current
> owner's and flags parameter set to 0.
> 
> Note both HVMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
> are only supported for HVMs with HAP enabled.
> 
> Also note that only after one ioreq server claims its ownership
> of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server
> be allowed.
> 
> Signed-off-by: Paul Durrant 
> Signed-off-by: Yu Zhang 
> Acked-by: Tim Deegan 
> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: Tim Deegan 
> 
> changes in v6: 
>   - Clarify logic in hvmemul_do_io().
>   - Use recursive lock for ioreq server lock.
>   - Remove debug print when mapping ioreq server.
>   - Clarify code in ept_p2m_type_to_flags() for consistency.
>   - Remove definition of P2M_IOREQ_HANDLE_WRITE_ACCESS.
>   - Add comments for HVMMEM_ioreq_server to note only changes
> to/from HVMMEM_ram_rw are permitted.
>   - Add domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server()
> to avoid the race condition when a vm exit happens on a write-
> protected page, just to find the ioreq server has been unmapped
> already.

Why do we need to do this?  Won't the default case just DTRT if it finds
that the ioreq server has been unmapped?

 -George

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

Re: [Xen-devel] [PATCH v3] mem_access: sanitize code around sending vm_event request

[Stefano Stabellini]

On Wed, 3 Aug 2016, Tamas K Lengyel wrote:
> The two functions monitor_traps and mem_access_send_req duplicate some of the
> same functionality. The mem_access_send_req however leaves a lot of the
> standard vm_event fields to be filled by other functions.
> 
> Remove mem_access_send_req() completely, making use of monitor_traps() to put
> requests into the monitor ring.  This in turn causes some cleanup around the
> old callsites of mem_access_send_req(). We also update monitor_traps to now
> include setting the common vcpu_id field so that all other call-sites can 
> ommit
> this step.
> 
> Finally, this change identifies that errors from mem_access_send_req() were
> never checked.  As errors constitute a problem with the monitor ring,
> crashing the domain is the most appropriate action to take.
> 
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Andrew Cooper 
> Acked-by: Razvan Cojocaru 

The ARM bits:

Acked-by: Stefano Stabellini 


> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: George Dunlap 
> 
> v3: reduce the code movement and sanitization performed to a minimum
> ---
>  xen/arch/arm/p2m.c   | 15 ---
>  xen/arch/x86/hvm/hvm.c   | 18 --
>  xen/arch/x86/hvm/monitor.c   |  5 -
>  xen/arch/x86/mm/p2m.c| 26 +-
>  xen/common/mem_access.c  | 11 ---
>  xen/common/monitor.c |  2 ++
>  xen/include/asm-x86/p2m.h| 13 -
>  xen/include/xen/mem_access.h |  7 ---
>  8 files changed, 31 insertions(+), 66 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 40a0b80..a3f05b4 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -5,7 +5,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1740,10 +1740,6 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  {
>  req->reason = VM_EVENT_REASON_MEM_ACCESS;
>  
> -/* Pause the current VCPU */
> -if ( xma != XENMEM_access_n2rwx )
> -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
> -
>  /* Send request to mem access subscriber */
>  req->u.mem_access.gfn = gpa >> PAGE_SHIFT;
>  req->u.mem_access.offset =  gpa & ((1 << PAGE_SHIFT) - 1);
> @@ -1760,16 +1756,13 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 0;
>  req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 0;
>  req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
> -req->vcpu_id = v->vcpu_id;
>  
> -mem_access_send_req(v->domain, req);
> +if ( monitor_traps(v, (xma != XENMEM_access_n2rwx), req) < 0 )
> +domain_crash(v->domain);
> +
>  xfree(req);
>  }
>  
> -/* Pause the current VCPU */
> -if ( xma != XENMEM_access_n2rwx )
> -vm_event_vcpu_pause(v);
> -
>  return false;
>  }
>  
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index daaee1d..42f163e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  int rc, fall_through = 0, paged = 0;
>  int sharing_enomem = 0;
>  vm_event_request_t *req_ptr = NULL;
> -bool_t ap2m_active;
> +bool_t ap2m_active, sync = 0;
>  
>  /* On Nested Virtualization, walk the guest page table.
>   * If this succeeds, all is fine.
> @@ -1846,11 +1846,15 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  }
>  }
>  
> -if ( p2m_mem_access_check(gpa, gla, npfec, _ptr) )
> -{
> +sync = p2m_mem_access_check(gpa, gla, npfec, _ptr);
> +
> +if ( !sync )
>  fall_through = 1;
> -} else {
> -/* Rights not promoted, vcpu paused, work here is done */
> +else
> +{
> +/*
> + * Rights not promoted (aka. sync event), work here is done
> + */
>  rc = 1;
>  goto out_put_gfn;
>  }
> @@ -1956,7 +1960,9 @@ out:
>  }
>  if ( req_ptr )
>  {
> -mem_access_send_req(currd, req_ptr);
> +if ( monitor_traps(curr, sync, req_ptr) < 0 )
> +rc = 0;
> +
>  xfree(req_ptr);
>  }
>  return rc;
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index 7277c12..0f6ef96 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -44,7 +44,6 @@ bool_t hvm_monitor_cr(unsigned int index, 

Re: [Xen-devel] [PATCH v6 2/4] x86/ioreq server: Release the p2m lock after mmio is handled.

[Jan Beulich]

>>> On 02.09.16 at 12:47,  wrote:
> Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
> select the ioreq server. For example, operations on gfns with
> p2m_ioreq_server type will be delivered to a corresponding ioreq
> server, and this requires that the p2m type not be switched back
> to p2m_ram_rw during the emulation process. To avoid this race
> condition, we delay the release of p2m lock in hvm_hap_nested_page_fault()
> until mmio is handled.
> 
> Note: previously in hvm_hap_nested_page_fault(), put_gfn() was moved
> before the handling of mmio, due to a deadlock risk between the p2m
> lock and the event lock(in commit 77b8dfe). Later, a per-event channel
> lock was introduced in commit de6acb7, to send events. So we do not
> need to worry about the deadlock issue.
> 
> Signed-off-by: Yu Zhang 

Reviewed-by: Jan Beulich 

However, shouldn't this go _before_ what is now patch 1?

Jan


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

Re: [Xen-devel] [PATCH v6 3/4] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.

[Jan Beulich]

>>> On 02.09.16 at 12:47,  wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -95,6 +95,41 @@ static const struct hvm_io_handler null_handler = {
>  .ops = _ops
>  };
>  
> +static int mem_read(const struct hvm_io_handler *io_handler,
> +uint64_t addr,
> +uint32_t size,
> +uint64_t *data)
> +{
> +struct domain *currd = current->domain;
> +unsigned long gmfn = paddr_to_pfn(addr);
> +unsigned long offset = addr & ~PAGE_MASK;
> +struct page_info *page = get_page_from_gfn(currd, gmfn, NULL, 
> P2M_UNSHARE);
> +uint8_t *p;

const (and preferably also void)

> +ASSERT(offset + size < PAGE_SIZE);

Surely <= ?

> +if ( !page )
> +return X86EMUL_UNHANDLEABLE;
> +
> +p = __map_domain_page(page);
> +p += offset;
> +memcpy(data, p, size);
> +
> +unmap_domain_page(p);
> +put_page(page);

But anyway - I think rather than all this open coding you would
better call hvm_copy_from_guest_phys().

> +static const struct hvm_io_ops mem_ops = {
> +.read = mem_read,
> +.write = null_write
> +};
> +
> +static const struct hvm_io_handler mem_handler = {
> +.ops = _ops
> +};

I think the mem_ prefix for both objects is a bad one, considering
that this isn't suitable for general memory handling.

> @@ -204,7 +239,15 @@ static int hvmemul_do_io(
>  /* If there is no suitable backing DM, just ignore accesses */
>  if ( !s )
>  {
> -rc = hvm_process_io_intercept(_handler, );
> +/*
> + * For p2m_ioreq_server pages accessed with read-modify-write
> + * instructions, we provide a read handler to copy the data to
> + * the buffer.
> + */
> +if ( p2mt == p2m_ioreq_server )

Please add unlikely() here, or aid the compiler in avoiding any
branch by ...

> +rc = hvm_process_io_intercept(_handler, );
> +else
> +rc = hvm_process_io_intercept(_handler, );

... using a conditional expression for the first function argument.

And the comment ahead of the if() now also needs adjustment
(perhaps you want to merge the one you add into that one).

Jan


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

Re: [Xen-devel] [PATCH v2] x86: correct CPUID output for out of bounds input

[Andrew Cooper]

On 05/09/16 16:26, Jan Beulich wrote:
> Another place where we should try to behave sufficiently close to how
> real hardware does; see the code comments.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 100754: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3d20524af09243e3b2e3e832d1c62975e84a5dcd
baseline version:
 ovmf 11eaa7affb8b325b3e00bbe9e4357705ce3b2b08

Last test of basis   100749  2016-09-04 05:45:45 Z1 days
Testing same since   100754  2016-09-05 10:46:12 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Star Zeng 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH 2/2] x86/HVM: adjust feature checking in MSR intercept handling

[Andrew Cooper]

On 02/09/16 11:21, Jan Beulich wrote:
> Consistently consult hvm_cpuid(). With that, BNDCFGS gets better
> handled outside of VMX specific code, just like XSS. Don't needlessly
> check for MTRR support when the MSR being accessed clearly is not an
> MTRR one.
>
> Signed-off-by: Jan Beulich 

:( Yet more overhead from extra hvm_cpuid() calls.  I really need to get
on with fixing it.

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 18/24] xen: credit2: soft-affinity awareness fallback_cpu() and cpu_pick()

[Dario Faggioli]

On Thu, 2016-09-01 at 12:08 +0100, anshul makkar wrote:
> On 17/08/16 18:19, Dario Faggioli wrote:
> > 
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > 
> > @@ -506,34 +506,68 @@ void smt_idle_mask_clear(unsigned int cpu,
> > cpumask_t *mask)
> >   }
> > 
> >   /*
> > - * When a hard affinity change occurs, we may not be able to check
> > some
> > - * (any!) of the other runqueues, when looking for the best new
> > processor
> > - * for svc (as trylock-s in csched2_cpu_pick() can fail). If that
> > happens, we
> > - * pick, in order of decreasing preference:
> > - *  - svc's current pcpu;
> > - *  - another pcpu from svc's current runq;
> > - *  - any cpu.
> > + * In csched2_cpu_pick(), it may not be possible to actually look
> > at remote
> > + * runqueues (the trylock-s on their spinlocks can fail!). If that
> > happens,
> With remote runqueues , do you mean runqs on remote socket ? 
>
I mean runqueues different from the runq the vcpu is currently assigned
to (as per runq_assign()/runq_deassing()).

If you have runqueues configured to be per-socket, yes, it will try to
lock runqueues in which there are pcpus that are on a different socket
wrt svc->vcpu->processor.

> Can't we 
> just read their workload or we can change the locktype to allow
> reading ?
>
Reading without taking the lock would race against the load value being
updated. And updating the load is done by __update_runq_load(), which,
with all it's shifts and maths, by no means is an atomic operation.

So it's not just a matter of risking to read a slightly outdated value,
which, I agree, may not be that bad, it's that we risk reading
something inconsistent. :-/

About "changing the locktype", I guess you mean that we can turn also
the runqueue lock into an rw-lock? If yes, that's indeed interesting,
and I've also thought about it, but, for now, always deferred trying to
actually do that.

It's technically non trivial, as it would involve changing
schedule_data->schedule_lock and all the {v,p}cpu_schedule_lock*()
functions. Also, it's a lock that will almost all the times be taken
for writing, which usually means what you want is a proper spinlock.

So, IMO, before embarking in doing something like that, it'd be good to
figure out how frequently we actually fail to take the remote runqueue
lock, and what's the real impact of having to deal the consequence of
that.

I'm not saying it's not worth a try, but I'm saying that's it's
something at high risk of being a lot of work for a very small gain,
and that there are more important things to focus on.

> > + * we pick, in order of decreasing preference:
> > + *  1) svc's current pcpu, if it is part of svc's soft affinity;
> > + *  2) a pcpu in svc's current runqueue that is also in svc's soft
> > affinity;
> svc's current runqueue. Do you mean the runq in which svc is
> currently 
> queued ?
>
I mean the runqueue to which svc is currently assigned (again, as per
runq_assign()/runq_deassing()), which in turns mean that, if svc is
queued in a runqueue, it's queues there (so, I guess the short answer
to your question is "yes" :-D).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] mini-os: add comments in Config.mk regarding new config options

[Wei Liu]

On Mon, Sep 05, 2016 at 03:23:10PM +0200, Samuel Thibault wrote:
> Juergen Gross, on Mon 05 Sep 2016 13:43:30 +0200, wrote:
> > Add some comment in Config.mk what to do in case of adding new config
> > options.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Samuel Thibault 
> 

Pushed.

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

Re: [Xen-devel] [PATCH 05/24] xen: credit2: make tickling more deterministic

[Dario Faggioli]

On Wed, 2016-08-31 at 18:10 +0100, anshul makkar wrote:
> On 17/08/16 18:18, Dario Faggioli wrote:
> > 
> > Right now, the following scenario can occurr:
> >   - upon vcpu v wakeup, v itself is put in the runqueue,
> > and pcpu X is tickled;
> >   - pcpu Y schedules (for whatever reason), sees v in
> > the runqueue and picks it up.
> > 
> > This may seem ok (or even a good thing), but it's not.
> > In fact, if runq_tickle() decided X is where v should
> > run, it did it for a reason (load distribution, SMT
> > support, cache hotness, affinity, etc), and we really
> > should try as hard as possible to stick to that.
> > 
> > Of course, we can't be too strict, or we risk leaving
> > vcpus in the runqueue while there is available CPU
> > capacity. So, we only leave v in runqueue --for X to
> > pick it up-- if we see that X has been tickled and
> > has not scheduled yet, i.e., it will have a real chance
> > of actually select and schedule v.
> > 
> > If that is not the case, we schedule it on Y (or, at
> > least, we consider that), as running somewhere non-ideal
> > is better than not running at all.
> > 
> > The commit also adds performance counters for each of
> > the possible situations.
> > 
> > Signed-off-by: Dario Faggioli 
> > ---
> > Cc: George Dunlap 
> > Cc: Anshul Makkar 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> >   xen/common/sched_credit2.c   |   65
> > +++---
> >   xen/include/xen/perfc_defn.h |3 ++
> >   2 files changed, 64 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > index 12dfd20..a3d7beb 100644
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -54,6 +54,7 @@
> >   #define TRC_CSCHED2_LOAD_CHECK   TRC_SCHED_CLASS_EVT(CSCHED2,
> > 16)
> >   #define TRC_CSCHED2_LOAD_BALANCE TRC_SCHED_CLASS_EVT(CSCHED2,
> > 17)
> >   #define TRC_CSCHED2_PICKED_CPU   TRC_SCHED_CLASS_EVT(CSCHED2,
> > 19)
> > +#define TRC_CSCHED2_RUNQ_CANDIDATE   TRC_SCHED_CLASS_EVT(CSCHED2,
> > 20)
> > 
> >   /*
> >    * WARNING: This is still in an experimental phase.  Status and
> > work can be found at the
> > @@ -398,6 +399,7 @@ struct csched2_vcpu {
> >   int credit;
> >   s_time_t start_time; /* When we were scheduled (used for
> > credit) */
> >   unsigned flags;  /* 16 bits doesn't seem to play well
> > with clear_bit() */
> > +int tickled_cpu; /* cpu tickled for picking us up (-1 if
> > none) */
> > 
> >   /* Individual contribution to load */
> >   s_time_t load_last_update;  /* Last time average was updated
> > */
> > @@ -1049,6 +1051,10 @@ runq_tickle(const struct scheduler *ops,
> > struct csched2_vcpu *new, s_time_t now)
> >   __cpumask_set_cpu(ipid, >tickled);
> >   smt_idle_mask_clear(ipid, >smt_idle);
> >   cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
> > +
> > +if ( unlikely(new->tickled_cpu != -1) )
> > +SCHED_STAT_CRANK(tickled_cpu_overwritten);
> > +new->tickled_cpu = ipid;
> >   }
> > 
> >   /*
> > @@ -1266,6 +1272,7 @@ csched2_alloc_vdata(const struct scheduler
> > *ops, struct vcpu *vc, void *dd)
> >   ASSERT(svc->sdom != NULL);
> >   svc->credit = CSCHED2_CREDIT_INIT;
> >   svc->weight = svc->sdom->weight;
> > +svc->tickled_cpu = -1;
> >   /* Starting load of 50% */
> >   svc->avgload = 1ULL << (CSCHED2_PRIV(ops)-
> > >load_precision_shift - 1);
> >   svc->load_last_update = NOW() >>
> > LOADAVG_GRANULARITY_SHIFT;
> > @@ -1273,6 +1280,7 @@ csched2_alloc_vdata(const struct scheduler
> > *ops, struct vcpu *vc, void *dd)
> >   else
> >   {
> >   ASSERT(svc->sdom == NULL);
> > +svc->tickled_cpu = svc->vcpu->vcpu_id;
> If I understood correctly, tickled_cpu refers to pcpu and not a
> vcpu. 
> Saving vcpu_id in tickled_cpu looks wrong.
> 
Yes, and in fact, as you can see in the previous hunk, for pretty much
all vcpus, tickled_cpu is initialized to -1.

Here, we are dealing with the vcpus of the idle domain. And for vcpus
of the idle domain, their vcpu id is the same as the id of the pcpu
they're associated to.

I agree it looks a little bit weird, but it's both correct, and the
easiest and cleanest way for initializing this.

I guess I can add a comment...

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [MINIOS PATCH] Add travis.yml and travis-build script

[Wei Liu]

Signed-off-by: Wei Liu 
---
See:
https://travis-ci.org/liuw/mini-os/builds/157653746

Cc: Samuel Thibault 
Cc: Juergen Gross 
Cc: Doug Goldstein 

IRC notification is not yet set up.

Doug, can we mirror mini-os.git to github/xen-project as well? I think
it would also be a good idea to post notification to #xentest.
---
 .travis.yml  | 25 +
 scripts/travis-build |  5 +
 2 files changed, 30 insertions(+)
 create mode 100644 .travis.yml
 create mode 100755 scripts/travis-build

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..9aa69a5
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,25 @@
+language: c
+dist: trusty
+sudo: required
+# don't test stable branches
+branches:
+except:
+- /^stable-.*/
+matrix:
+include:
+- compiler: gcc
+addons:
+apt:
+sources:
+- ubuntu-toolchain-r-test
+packages:
+- libc6-dev-i386
+- gcc-5
+- g++-5
+# we must set CXX manually instead of using 'language: cpp' due to
+# travis-ci/travis-ci#3871
+before_script:
+- export CXX=${CC/cc/++}
+- export CXX=${CXX/clang/clang++}
+script:
+- ./scripts/travis-build
diff --git a/scripts/travis-build b/scripts/travis-build
new file mode 100755
index 000..9480a9d
--- /dev/null
+++ b/scripts/travis-build
@@ -0,0 +1,5 @@
+#!/bin/bash -ex
+
+$CC --version
+
+make testbuild
-- 
2.1.4


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

Re: [Xen-devel] Xen 4.8 Development Update

[Dario Faggioli]

On Wed, 2016-08-31 at 10:21 -0400, Konrad Rzeszutek Wilk wrote:
> > 
> > *  Per-cpu tasklet
> >   -  Konrad Rzeszutek Wilk
> Waiting for review and hopefully test results from Intel.
>
I've just seen it (came back today from vacations)... Interesting bit
of work.

I'll try to have a deep look at the patches ASAP (I'm no maintainer, of
course, but I've played with tasklets a bit, and I at last hope to be
able to be of some help :-P)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 100759: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386  6 xen-boot fail REGR. vs. 100736
 test-amd64-amd64-libvirt  6 xen-boot fail REGR. vs. 100736

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  7539772a65b044f326ebf9528bd40e7c6a78c540
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100736  2016-09-02 16:03:32 Z2 days
Testing same since   100755  2016-09-05 11:01:49 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  He Chen 
  Ian Jackson 
  Jan Beulich 
  Luwei Kang 
  Marek Marczykowski-Górecki 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 7539772a65b044f326ebf9528bd40e7c6a78c540
Author: Marek Marczykowski-Górecki 
Date:   Mon Sep 5 11:26:04 2016 +0200

libxl: do not assume Dom0 backend while getting nic info

Fill backend_domid field based on backend path.

Cc: Ian Jackson 
Cc: Wei Liu 
Signed-off-by: Marek Marczykowski-Górecki 
Acked-by: Wei Liu 

commit b2f2ced591060588a45cdc7881a7335ba42b9cc5
Author: Wei Liu 
Date:   Mon Sep 5 11:36:45 2016 +0100

tools/firmware: Rename bios.bin to seabios.bin

bios.bin as a name is far too generic.  Rename it to seabios.bin.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
[ wei: fix up conflict, rerun autogen.sh ]
Signed-off-by: Wei Liu 

commit eb502cb30cc5af309ed824da024014afca1d0fcf
Author: Wei Liu 
Date:   Mon Sep 5 10:21:28 2016 +0100

libxl: update flex output files for DSA 3653-2

We updated flex output files in 4b314c89 ("libxl: update flex output
files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
discovered the fix to flex was incomplete and issued DSA 3653-2. We need
to update our flex output files accordingly.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 5fdea6577098eda065c794c79e1ae23f33f103af
Author: He Chen 
Date:   Mon Sep 5 12:49:43 2016 +0200

x86: allow disabling sm{e,a}p for Xen itself

SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.

SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest which will suffer unknown SMEP/SMAP page fault when guest
kernel attempt to access user address although SMEP/SMAP is close for
PV guests.

This patch introduces a new boot option value "hvm" for "sm{e,a}p", it
is going to diable SMEP/SMAP for Xen hypervisor while enable them for
HVM. In this way, 32-bit PV guest will not suffer SMEP/SMAP security
issue. Users can choose whether open SMEP/SMAP for Xen itself,
especially when they are going to run 32-bit PV guests.

Signed-off-by: He 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl  15 guest-start/debian.repeatfail  like 100587
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 100587
 build-amd64-rumpuserxen   6 xen-buildfail  like 100594
 build-i386-rumpuserxen6 xen-buildfail  like 100594
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeatfail  like 100594
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat   fail like 100594
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100594
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100594
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100594
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100594
 test-armhf-armhf-xl-vhd   9 debian-di-installfail  like 100594
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100594

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux3b60b86aec06fbae1142ccc4e55b39b529ae2a25
baseline version:
 linux99f614a3bb23603a947be2e95b78507112c484e5

Last test of basis   100594  2016-08-23 05:03:57 Z   13 days
Testing same since   100753  2016-09-05 06:44:50 Z0 days1 attempts


People who touched revisions under test:
  Agrawal, Nitesh-kumar 
  Alan Stern 
  Alex Deucher 
  Alexey Klimov 
  Andrej Krutak 
  Andrew Donnellan 
  Andrew Morton 
  Andrey Ryabinin 
  Artem Bityutskiy 
  Bart Van Assche 
  Benjamin Coddington 
  Bjorn Helgaas 
  Bruno Wolff III 
  Chen-Yu Tsai 
  Christian König 
  Christoph Huber 
  Daniel Lezcano 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  343f84be135e6f9e681960a9e235296eae159fc8
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100736  2016-09-02 16:03:32 Z3 days
Failing since100755  2016-09-05 11:01:49 Z0 days3 attempts
Testing same since   100763  2016-09-05 15:02:12 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  He Chen 
  Ian Jackson 
  Jan Beulich 
  Luwei Kang 
  Marek Marczykowski-Górecki 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Jan Beulich]

>>> On 02.09.16 at 12:47,  wrote:
> @@ -178,8 +179,27 @@ static int hvmemul_do_io(
>  break;
>  case X86EMUL_UNHANDLEABLE:
>  {
> -struct hvm_ioreq_server *s =
> -hvm_select_ioreq_server(curr->domain, );
> +struct hvm_ioreq_server *s = NULL;
> +p2m_type_t p2mt = p2m_invalid;
> +
> +if ( is_mmio )
> +{
> +unsigned long gmfn = paddr_to_pfn(addr);
> +
> +(void) get_gfn_query_unlocked(currd, gmfn, );
> +
> +if ( p2mt == p2m_ioreq_server && dir == IOREQ_WRITE )
> +{
> +unsigned int flags;
> +
> +s = p2m_get_ioreq_server(currd, );
> +if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
> +s = NULL;
> +}
> +}
> +
> +if ( !s && p2mt != p2m_ioreq_server )
> +s = hvm_select_ioreq_server(currd, );

What I recall is that we had agreed on p2m_ioreq_server pages
to be treated as ordinary RAM ones as long as no server can be
found. The type check here contradicts that. Is there a reason?

> +static int hvmop_map_mem_type_to_ioreq_server(
> +XEN_GUEST_HANDLE_PARAM(xen_hvm_map_mem_type_to_ioreq_server_t) uop)
> +{
> +xen_hvm_map_mem_type_to_ioreq_server_t op;
> +struct domain *d;
> +int rc;
> +
> +if ( copy_from_guest(, uop, 1) )
> +return -EFAULT;
> +
> +rc = rcu_lock_remote_domain_by_id(op.domid, );
> +if ( rc != 0 )
> +return rc;
> +
> +rc = -EINVAL;
> +if ( !is_hvm_domain(d) )
> +goto out;
> +
> +if ( op.pad != 0 )
> +goto out;

This, I think, should be done first thing after having copied in the
structure. No need to lookup domain or anything if this is not zero.

> +int hvm_map_mem_type_to_ioreq_server(struct domain *d, ioservid_t id,
> + uint32_t type, uint32_t flags)
> +{
> +struct hvm_ioreq_server *s;
> +int rc;
> +
> +/* For now, only HVMMEM_ioreq_server is supported. */
> +if ( type != HVMMEM_ioreq_server )
> +return -EINVAL;
> +
> +/* For now, only write emulation is supported. */
> +if ( flags & ~(XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
> +return -EINVAL;
> +
> +domain_pause(d);
> +spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
> +
> +rc = -ENOENT;
> +list_for_each_entry ( s,
> +  >arch.hvm_domain.ioreq_server.list,
> +  list_entry )
> +{
> +if ( s == d->arch.hvm_domain.default_ioreq_server )
> +continue;
> +
> +if ( s->id == id )
> +{
> +rc = p2m_set_ioreq_server(d, flags, s);
> +break;
> +}
> +}
> +
> +spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
> +domain_unpause(d);
> +return rc;
> +}

Blank line before final return statement of a function please.

> +int p2m_set_ioreq_server(struct domain *d,
> + unsigned int flags,
> + struct hvm_ioreq_server *s)
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +int rc;
> +
> +/*
> + * Use lock to prevent concurrent setting requirements
> + * from multiple ioreq serers.
> + */

"Concurrent setting requirements"? DYM "attempts"?

Jan


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

[Xen-devel] [PATCH v2] libxl: add "xl qemu-monitor-command"

[Juergen Gross]

Add a new xl command "qemu-monitor-command" to issue arbitrary commands
to a domain's device model. Syntax is:

xl qemu-monitor-command  

The command is issued via qmp human-monitor-command command. Any
information returned by the command is printed to stdout.

Signed-off-by: Juergen Gross 
---
 docs/man/xl.pod.1.in   | 36 
 tools/libxl/libxl.h| 14 ++
 tools/libxl/libxl_colo_qdisk.c |  2 +-
 tools/libxl/libxl_internal.h   |  3 ++-
 tools/libxl/libxl_qmp.c| 38 --
 tools/libxl/xl.h   |  1 +
 tools/libxl/xl_cmdimpl.c   | 27 +++
 tools/libxl/xl_cmdtable.c  |  5 +
 8 files changed, 122 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 1adf322..a2be541 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1516,6 +1516,42 @@ List pass-through usb devices for a domain.
 
 =back
 
+=head1 DEVICE-MODEL CONTROL
+
+=over 4
+
+=item B I I
+
+Issue a monitor command to the device model of the domain specified by
+I. I can be any valid command qemu understands. This
+can be e.g. used to add non-standard devices or devices with non-standard
+parameters to a domain. The output of the command is printed to stdout.
+
+B This qemu monitor access is provided for convenience when
+debugging, troubleshooting, and experimenting.  Its use is not
+supported by the Xen Project.
+
+Specifically, not all information printed by the qemu monitor will
+necessarily be accurate or complete, because in a Xen system qemu
+does not have a complete view of the guest.
+
+Furthermore, modifying the guest's setup via the qemu monitor may
+conflict with the Xen toolstack's assumptions.  Resulting problems
+may include, but are not limited to: guest crashes; toolstack error
+messages; inability to migrate the guest; and security
+vulnerabilities which are not covered by the Xen Project security
+response policy.
+
+B
+
+Obtain information of USB devices connected as such via the device model
+(only!) to a domain:
+
+ xl qemu-monitor-command vm1 'info usb'
+  Device 0.2, Port 5, Speed 480 Mb/s, Product Mass Storage
+
+=back
+
 =head1 TMEM
 
 =over 4
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e4c25c4..7cfa540 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -275,6 +275,12 @@
 #define LIBXL_HAVE_BUILD_ID 1
 
 /*
+ * LIBXL_HAVE_QEMU_MONITOR_COMMAND indiactes the availability of the
+ * libxl_qemu_monitor_command() function.
+ */
+#define LIBXL_HAVE_QEMU_MONITOR_COMMAND 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
@@ -2152,6 +2158,14 @@ void libxl_psr_cat_info_list_free(libxl_psr_cat_info 
*list, int nr);
 int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
 int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
 
+/*
+ * Issue a qmp monitor command to the device model of the specified domain.
+ * The function returns the output of the command in a new allocated buffer
+ * via output.
+ */
+int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
+   const char *command_line, char **output);
+
 #include 
 
 #endif /* LIBXL_H */
diff --git a/tools/libxl/libxl_colo_qdisk.c b/tools/libxl/libxl_colo_qdisk.c
index c23b81b..d271d1f 100644
--- a/tools/libxl/libxl_colo_qdisk.c
+++ b/tools/libxl/libxl_colo_qdisk.c
@@ -173,7 +173,7 @@ static void colo_qdisk_save_preresume(libxl__egc *egc,
 "file.driver=nbd,file.host=%s,file.port=%d,"
 "file.export=%s,node-name=%s,if=none",
 host, port, export_name, node);
-ret = libxl__qmp_hmp(gc, domid, cmd);
+ret = libxl__qmp_hmp(gc, domid, cmd, NULL);
 if (ret)
 rc = ERROR_FAIL;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ce8e17a..9f534c4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1818,7 +1818,8 @@ _hidden int libxl__qmp_x_blockdev_change(libxl__gc *gc, 
int domid,
  const char *parant,
  const char *child, const char *node);
 /* run a hmp command in qmp mode */
-_hidden int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line);
+_hidden int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line,
+   char **out);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 63c49c5..33883b8 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1103,14 +1103,48 @@ int libxl__qmp_x_blockdev_change(libxl__gc *gc, int 
domid, const char *parent,
 return qmp_run_command(gc, domid, 

Re: [Xen-devel] [PATCH 17/24] xen: credit2: soft-affinity awareness in runq_tickle()

[Dario Faggioli]

On Thu, 2016-09-01 at 11:52 +0100, anshul makkar wrote:
> On 17/08/16 18:19, Dario Faggioli wrote:
> > 
> > +/*
> > + * We're doing soft-affinity, and we know that the current
> > vcpu on cpu
> > + * has a soft affinity. We now want to know whether cpu itself
> > is in
> Please can you explain the above statment. If the vcpu has soft
> affinity 
> and its currently executing, doesn;t it always means that its running
> on 
> one of the pcpu which is there in its soft affinity or hard affinity?
>
A vcpu will always run on a pcpu from its own hard-affinity (that's the
definition of hard-affinity).

On the other hand, a vcpu will, most of the time, run on a cpu from its
own soft affinity, but can run on a cpu that is in its hard-affinity,
but *IS NOT* in its soft-affinity.

That's the definition of soft-affinity: the scheduler will try to run
it there, but it that can't happen, it will run it will run it outside
of it (but still within its hard-affinity, of course).

So, yes, we know already that it's running in a cpu at least from its
hard affinity, what is it exactly that you are not understanding?

> > + * such affinity. In fact, since we now that new (in
> > runq_tickle()) is
> Typo:   * such affinity. In fact, since now we know that new (in 
> runq_tickle()) is
>
Thanks. :-)

> > + *  - if cpu is not in cur's soft-affinity, we should indeed
> > check to
> > + *see whether new should preempt cur. If that will be the
> > case, that
> > + *would be an improvement wrt respecting soft affinity;
> > + *  - if cpu is in cur's soft-affinity, we leave it alone and
> > (in
> > + *runq_tickle()) move on to another cpu. In fact, we don't
> > want to
> > + *be too harsh with someone which is running within its
> > soft-affinity.
> > + *This is safe because later, if we don't fine anyone else
> > during the
> > + *soft-affinity step, we will check cpu for preemption
> > anyway, when
> > + *doing hard-affinity.
> > + */
>
Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] x86: correct CPUID output for out of bounds input

[Jan Beulich]

Another place where we should try to behave sufficiently close to how
real hardware does; see the code comments.

Signed-off-by: Jan Beulich 
---
v2: Uniformly return zero for out of range leaves. Only consider basic
and extended groups as valid. Avoid recursion in hvm_cpuid().

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3364,6 +3364,27 @@ void hvm_cpuid(unsigned int input, unsig
 if ( cpuid_hypervisor_leaves(input, count, eax, ebx, ecx, edx) )
 return;
 
+if ( input & 0x7fff )
+{
+/*
+ * Requests outside the supported leaf ranges return zero on AMD
+ * and the highest basic leaf output on Intel. Uniformly follow
+ * the AMD model as the more sane one.
+ */
+unsigned int limit;
+
+domain_cpuid(d, (input >> 16) != 0x8000 ? 0 : 0x8000, 0,
+ , , , );
+if ( input > limit )
+{
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+return;
+}
+}
+
 domain_cpuid(d, input, count, eax, ebx, ecx, edx);
 
 switch ( input )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -952,6 +952,29 @@ void pv_cpuid(struct cpu_user_regs *regs
 if ( cpuid_hypervisor_leaves(leaf, subleaf, , , , ) )
 goto out;
 
+if ( leaf & 0x7fff )
+{
+/*
+ * Requests outside the supported leaf ranges return zero on AMD
+ * and the highest basic leaf output on Intel. Uniformly follow
+ * the AMD model as the more sane one.
+ */
+unsigned int limit = (leaf >> 16) != 0x8000 ? 0 : 0x8000, dummy;
+
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, limit, 0, , , , );
+else
+limit = cpuid_eax(limit);
+if ( leaf > limit )
+{
+regs->eax = 0;
+regs->ebx = 0;
+regs->ecx = 0;
+regs->edx = 0;
+return;
+}
+}
+
 if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
 domain_cpuid(currd, leaf, subleaf, , , , );
 else



x86: correct CPUID output for out of bounds input

Another place where we should try to behave sufficiently close to how
real hardware does; see the code comments.

Signed-off-by: Jan Beulich 
---
v2: Uniformly return zero for out of range leaves. Only consider basic
and extended groups as valid. Avoid recursion in hvm_cpuid().

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3364,6 +3364,27 @@ void hvm_cpuid(unsigned int input, unsig
 if ( cpuid_hypervisor_leaves(input, count, eax, ebx, ecx, edx) )
 return;
 
+if ( input & 0x7fff )
+{
+/*
+ * Requests outside the supported leaf ranges return zero on AMD
+ * and the highest basic leaf output on Intel. Uniformly follow
+ * the AMD model as the more sane one.
+ */
+unsigned int limit;
+
+domain_cpuid(d, (input >> 16) != 0x8000 ? 0 : 0x8000, 0,
+ , , , );
+if ( input > limit )
+{
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+return;
+}
+}
+
 domain_cpuid(d, input, count, eax, ebx, ecx, edx);
 
 switch ( input )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -952,6 +952,29 @@ void pv_cpuid(struct cpu_user_regs *regs
 if ( cpuid_hypervisor_leaves(leaf, subleaf, , , , ) )
 goto out;
 
+if ( leaf & 0x7fff )
+{
+/*
+ * Requests outside the supported leaf ranges return zero on AMD
+ * and the highest basic leaf output on Intel. Uniformly follow
+ * the AMD model as the more sane one.
+ */
+unsigned int limit = (leaf >> 16) != 0x8000 ? 0 : 0x8000, dummy;
+
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, limit, 0, , , , );
+else
+limit = cpuid_eax(limit);
+if ( leaf > limit )
+{
+regs->eax = 0;
+regs->ebx = 0;
+regs->ecx = 0;
+regs->edx = 0;
+return;
+}
+}
+
 if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
 domain_cpuid(currd, leaf, subleaf, , , , );
 else
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH 02/26] Executive: Allow out-of-order manipulations of flights intended play

[Ian Jackson]

Flights being operated on by a developer hacking about with the code,
which were created with intended blessing `play', are usually blessed
`running' or `broken' or something.  So the safety catch bypass needs
to look at the intended blessing too.

Signed-off-by: Ian Jackson 
---
 Osstest/JobDB/Executive.pm | 6 +++---
 README.dev | 3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 51c1ebb..c21eba7 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -102,14 +102,14 @@ sub dbfl_check ($$) { #method
 }
 die unless ref($flok) eq 'ARRAY';
 
-my ($bless) = $dbh_tests->selectrow_array(<selectrow_array(<

[Xen-devel] [OSSTEST PATCH 25/26] rumprun: xenstorels: New regexps for finding output

[Ian Jackson]

The framing output in rumprun upstream has changed.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-demo-xenstorels | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ts-rumprun-demo-xenstorels b/ts-rumprun-demo-xenstorels
index a40110a..831c58a 100755
--- a/ts-rumprun-demo-xenstorels
+++ b/ts-rumprun-demo-xenstorels
@@ -77,10 +77,11 @@ END
 sub their_xenstorels () {
 some_xenstorels('theirs', sub {
$output{theirs} =~ s{\r\n}{\n}g;
-   while ($output{theirs} =~ m{\n=== calling main\(\) ===\n\n}) {
+   while ($output{theirs} =~ m{\n=== calling ".*" main\(\) ===\n\n}) {
$output{theirs} = $'; #';
}
-   $output{theirs} =~ m{\n=== main\(\) returned (\d+) ===\n} or die;
+   $output{theirs} =~ m{\n=== main\(\) returned (\d+) ===\n} or
+   $output{theirs} =~ m{\n=== ERROR: _exit\((\d+)\) called ===\n} or die;
$output{theirs} = $`;
die "$1 ?" if $1 ne '0';
$output{theirs} =~ s{^STUB \`\`\w+'' called\n}{}mg;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 24/26] rumprun: xenstorels: Do not attempt to edit the config file

[Ian Jackson]

There is no config file any more, so this function now crashes due to
passing undef to target_editfile_root.

We do not need to edit it to set on_poweroff to preserve because this
is the default for rumprun.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-demo-xenstorels | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/ts-rumprun-demo-xenstorels b/ts-rumprun-demo-xenstorels
index 47aa289..a40110a 100755
--- a/ts-rumprun-demo-xenstorels
+++ b/ts-rumprun-demo-xenstorels
@@ -30,20 +30,6 @@ our $domid;
 
 our $gn = $gho->{Guest};
 
-sub arrangepreserve () {
-target_editfile_root($ho,$r{"$gho->{Guest}_cfgpath"}, sub {
-   while () {
-   if (m/^\s*on_poweroff\s*=/) {
-   target_editfile_cancel("already configured to preserve")
-   if m/\bpreserve\b/;
-   next;
-   }
-   print EO or die $!;
-   }
-   print EO "\n","on_poweroff='preserve'\n" or die $!;
-});
-}
-
 sub start () {
 rumprun_guest_create($gho);
 
@@ -118,7 +104,6 @@ sub check_output () {
 }
 }
 
-arrangepreserve();
 start();
 await_end();
 check_output();
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 18/26] rumprun: ts-rumprun-build: set up ccache

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 24e54e1..26f2f2c 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -54,6 +54,7 @@ END
 
 my $bindir;
 my $gnutriplet;
+my $ccachedir;
 
 sub findtools() {
 my $gcc = target_cmd_output($ho, "echo $rux/rumprun/bin/*-gcc");
@@ -63,8 +64,19 @@ sub findtools() {
 $gnutriplet = $2;
 }
 
+sub setupccache() {
+$ccachedir = "$bindir.ccache";
+target_cmd_build($ho, 600, $rux, <

[Xen-devel] [OSSTEST PATCH 26/26] rumprun: xenstorels: Improve an error message slightly

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 ts-rumprun-demo-xenstorels | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-rumprun-demo-xenstorels b/ts-rumprun-demo-xenstorels
index 831c58a..3d29c46 100755
--- a/ts-rumprun-demo-xenstorels
+++ b/ts-rumprun-demo-xenstorels
@@ -83,7 +83,7 @@ sub their_xenstorels () {
$output{theirs} =~ m{\n=== main\(\) returned (\d+) ===\n} or
$output{theirs} =~ m{\n=== ERROR: _exit\((\d+)\) called ===\n} or die;
$output{theirs} = $`;
-   die "$1 ?" if $1 ne '0';
+   die "EXIT STATUS $1 ?" if $1 ne '0';
$output{theirs} =~ s{^STUB \`\`\w+'' called\n}{}mg;
 }, <

[Xen-devel] [OSSTEST PATCH 00/26] rump kernels: Fix build

[Ian Jackson]

This series fixes the rump kernel build, and the test plumbing.  The
tests still fail because they xenbus driver in rump kernel upstream
has rotted.  I'm working on that...

Ian.

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

[Xen-devel] [OSSTEST PATCH 20/26] Xen built versions: ts-xen-build: check versions of Xen subtrees, only

[Ian Jackson]

ts-xen-build has a check that the actually-built versions of the
various subtrees are right.  This allows it to spot if the machinery
for specifying the subtree revision hasn't worked.

However, this machinery is troublesome: it assumes that the value
specified in the revision_TREE runvar is a commit id, just like the
value specified in built_revision_TREE.  This is, currently, true in
flights created by cr-daily-branch and cs-try-bisect.

But it is not necessarily true for flights created other ways.  In
principle it would be possible to look into each checked out subtree,
and use git-rev-parse (and its equivalent for nother VCSs) to check
whether the specified revision is right (by comparing it to
origin/, not , I guess).  This is quite
fiddly.

The reason this is causing trouble now is that some of the ad-hoc rump
kernel flights I'm currently making contain non-git-revison-id values
for the revision_TREE for parts of the rumprun build.

So for now, limiting this check to TREEs which are actually Xen
subtrees will fix the problem for me (and this will be necessary for
the fuller fix, which I describe above).  So do that.

Specifically:
 * Add a new WHERE clause to the query statement, so that it selects
   only the row for one specific tree
 * Run the query once for each tree in %xensubtrees

This leaves the query overly-complicated, but this doesn't matter,
because if and when we make a fuller fix we'll throw this entire query
away.  So it is easier to put off rewriting it in the hope that this
will never been needed.

Signed-off-by: Ian Jackson 
---
 ts-xen-build | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ts-xen-build b/ts-xen-build
index f5cff8b..cc171ef 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -217,10 +217,13 @@ sub checkversions () {
  WHERE reqd.flight=? and reqd.job=?
AND built.flight=? and built.job=?
AND built.name = 'built_' || reqd.name
+   AND reqd.name = ?
 END
-$chk->execute($flight,$job,$flight,$job);
 my $mismatches= 0;
-while (my $row= $chk->fetchrow_arrayref()) {
+foreach my $subtree (sort keys %xensubtrees) {
+   $chk->execute($flight,$job,$flight,$job,$subtree);
+   my $row= $chk->fetchrow_arrayref();
+   next unless $row;
 my ($tree, $reqd, $built) = @$row;
 next unless defined $reqd && defined $built;
 $reqd =~ s/^.*://;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 23/26] rumprun: `rumpbake' our executables and run them with `rumprun'

[Ian Jackson]

(Well, our one executable: xenstore-ls)

Modern rumprun requires the output of the linker to be `baked' (second
link phase, where the complete unikernel is assembled).

This has to be done as part of the build, because it needs all the
rumpkernel libraries.  It generates a single image file - there is no
longer any disk image or config file produced by the rump ecosystem.

The baked file needs to be provided in a dist.  We have
ts-rumprun-bake take command line argument specifying which things to
bake.  It reads the runvars for the source executables and creates a
single dist output containing the images.  There are now `executables'
and `images'.

Furthermore modern rumprun requires the image to be run with
`rumprun'.  One underlying reason is that it wants to pass the command
line and some other config parameters to the guest via xenstore, in
/local/domain/GUEST/rumprun/cfg.  To do this outside xl requires the
domain to be created paused.  Another is to abstract away details of
the actual execution environment (compared to other unikernel
execution models).

rumprun has a mode (-D -T) in which it would be possible to fish the
configuration and the desired json object (for the cfg) out of the
tempfile it creates.  It might also be possible for osstest to
construct these out of whole cloth.

However, this would be undesirable because it would break if rumprun
changed (in particular, if the interface to the domain creation
changed).

And because of the cfg wrinkle it still wouldn't let us construct a
domain config file which could be passed to
toolstack($ho)->guest_create.

So instead we invent Osstest::Rumprun::rumprun_guest_create, which
invokes rumprun.  rumprun implicitly invokes xl.

The config editing which was previously done by ts-rumprun-demo-setup
is now done by passing appropriate options to rumprun.

Signed-off-by: Ian Jackson 
---
 Osstest/RumpRun.pm | 67 ++
 make-flight|  2 +-
 sg-run-job |  2 ++
 ts-rumprun-bake| 89 ++
 ts-rumprun-demo-setup  | 52 ---
 ts-rumprun-demo-xenstorels |  3 +-
 6 files changed, 167 insertions(+), 48 deletions(-)
 create mode 100644 Osstest/RumpRun.pm
 create mode 100755 ts-rumprun-bake

diff --git a/Osstest/RumpRun.pm b/Osstest/RumpRun.pm
new file mode 100644
index 000..0582bd2
--- /dev/null
+++ b/Osstest/RumpRun.pm
@@ -0,0 +1,67 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# 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 Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+
+package Osstest::RumpRun;
+
+use strict;
+use warnings;
+
+use Osstest::TestSupport;
+
+BEGIN {
+use Exporter ();
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+$VERSION = 1.00;
+@ISA = qw(Exporter);
+@EXPORT  = qw(
+ rumprun_guest_create
+   );
+%EXPORT_TAGS = ( );
+
+@EXPORT_OK   = qw();
+}
+
+sub rumprun_guest_create ($) {
+my ($gho) = @_;
+my $ho = $gho->{Host};
+my $gn = $gho->{Guest};
+guest_prepare_disk($gho);
+
+my $rumprun = target_var($gho, 'rumprun_path');
+if (!$rumprun) {
+   logm("finding rumprun to use for $gho->{Name} on $ho->{Name}");
+   my $buildjob = $r{guests_rumprunbuildjob} // # todo: eliminate this
+   target_var($gho, 'rumprunbuildjob');
+   my $rumprundist = target_extract_jobdistpath_subdir
+   ($ho, "rumprun-rumprun-g-$gho->{Name}", "rumprun", $buildjob);
+   $rumprun = "$rumprundist/rumprun";
+   store_runvar("${gn}_rumprun_path", $rumprun);
+}
+
+my $imagepath = $r{"${gn}_imagepath"};
+my $cmdline = guest_var($gho, 'cmdline', undef);
+
+my $cmd = "$rumprun xen";
+$cmd .= " -N $gn";
+$cmd .= " -IIFTAG,IFBASENAME,mac=$gho->{Ether}";
+$cmd .= " $imagepath";
+$cmd .= " $cmdline";
+
+target_cmd_root($ho, $cmd, 100);
+}
+
+1;
diff --git a/make-flight b/make-flight
index 906bf2b..c94dfa4 100755
--- a/make-flight
+++ b/make-flight
@@ -203,7 +203,7 @@ do_rumpkernel_tests () {
 guests_rumprunbuildjob=build-$rumparch-rumprun   \
  rump_builtimage=rumprun:/usr/local/lib/xen/rump-kernel/rump-kernel \
 rump_cmdline=3   

[Xen-devel] [OSSTEST PATCH 05/26] rumprun: Fetch source from new upstream

[Ian Jackson]

Also, update for the current set of submodules.

Signed-off-by: Ian Jackson 
---
 ap-common| 2 +-
 ts-rumprun-build | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/ap-common b/ap-common
index 6fe3b78..14cc25a 100644
--- a/ap-common
+++ b/ap-common
@@ -37,7 +37,7 @@
 : ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
 : ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
 
-: ${TREE_RUMPRUN:=https://github.com/rumpkernel/rumprun-xen}
+: ${TREE_RUMPRUN:=http://repo.rumpkernel.org/rumprun}
 : ${TREEVCS_RUMPRUN:=git}
 : ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/rumpuser-xen.git}
 : ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/rumpuser-xen.git}
diff --git a/ts-rumprun-build b/ts-rumprun-build
index 574781f..abc1f7d 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -25,9 +25,8 @@ tsreadconfig();
 selectbuildhost(\@ARGV);
 builddirsprops();
 
-our %submodmap = qw(nblibs nblibs
-buildrump.sh buildrumpsh
-rumpsrc netbsdsrc);
+our %submodmap = qw(buildrump.sh buildrumpsh
+src-netbsd netbsdsrc);
 
 our ($rux, $bodges);
 
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 06/26] rumprun: Move xenbits tree to osstest subdir

[Ian Jackson]

Move our tested tree to /home/xen/git/osstest, where these kind of
things live nowadays.

Signed-off-by: Ian Jackson 
---
 ap-common | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ap-common b/ap-common
index 14cc25a..212da18 100644
--- a/ap-common
+++ b/ap-common
@@ -39,8 +39,8 @@
 
 : ${TREE_RUMPRUN:=http://repo.rumpkernel.org/rumprun}
 : ${TREEVCS_RUMPRUN:=git}
-: ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/rumpuser-xen.git}
-: ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/rumpuser-xen.git}
+: ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/osstest/rumprun.git}
+: ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/osstest/rumprun.git}
 
 : ${TREE_RUMPRUN_RUMPSRC:=$(besteffort_repo 
https://github.com/rumpkernel/rumpkernel-netbsd-src)}
 : ${TREEVCS_RUMPRUN_RUMPSRC:=git}
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 03/26] TestSupport: Produce stack trace for undef tfileex

[Ian Jackson]

Use `confess' to see where an undef $rfile came from.  I think there
will probably be lots more of this pattern.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index d0d6ef3..a6ab18f 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -31,6 +31,7 @@ use Osstest::Logtailer;
 use File::Copy;
 use File::Basename;
 use IO::Handle;
+use Carp;
 
 BEGIN {
 use Exporter ();
@@ -523,6 +524,8 @@ sub teditfileex {
 my $code= pop @_;
 my ($ho,$rfile,$lleaf,$rdest) = @_;
 
+confess unless defined $rfile;
+
 if (!defined $rdest) {
 $rdest= $rfile;
 }
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 15/26] rumprun: Drop old rumpuserxen demo

[Ian Jackson]

The WOPR demo is gone from rumpkernel upstream.

Sadly this leaves us without a test that the rump environment's
networking is functional.

Signed-off-by: Ian Jackson 
---
 sg-run-job | 4 
 1 file changed, 4 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index 31a5589..0c7835e 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -443,10 +443,6 @@ proc test-guest-nomigr {g} {
 
 proc need-hosts/test-rumprun {} { return host }
 proc run-job/test-rumprun {} {
-set g rump
-run-ts . =   ts-rumprun-demo-setup + host $g
-run-ts . =   ts-guest-start+ host $g
-run-ts . =   ts-guest-destroy  + host $g
 set g xenstorels
 run-ts . =   ts-rumprun-demo-setup  + host + $g
 run-ts . =   ts-rumprun-demo-xenstorels + host + $g
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 08/26] rumprun: ts-rumprun-build: Build new rumprun properly, ship the output

[Ian Jackson]

The command is `build-rr.sh' nowadays.  The output longer includes
test domain image and configuration.  The output is in `rumprun'.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 55420f0..93c34d1 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -46,7 +46,7 @@ sub massage() {
 sub build() {
 target_cmd_build($ho, 7200, $rux, <