Re: [Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

[Borislav Petkov]

On Mon, Dec 05, 2016 at 01:32:43PM -0800, Andy Lutomirski wrote:
> Aside from being excessively slow, CPUID is problematic: Linux runs
> on a handful of CPUs that don't have CPUID.  Use IRET-to-self
> instead.  IRET-to-self works everywhere, so it makes testing easy.
> 
> For reference, On my laptop, IRET-to-self is ~110ns,
> CPUID(eax=1, ecx=0) is ~83ns on native and very very slow under KVM,
> and MOV-to-CR2 is ~42ns.
> 
> While we're at it: sync_core() serves a very specific purpose.
> Document it.
> 
> Cc: "H. Peter Anvin" 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/include/asm/processor.h | 77 
> 
>  1 file changed, 55 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h 
> b/arch/x86/include/asm/processor.h
> index 64fbc937d586..201a956e345f 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -590,33 +590,66 @@ static __always_inline void cpu_relax(void)
>  
>  #define cpu_relax_lowlatency() cpu_relax()
>  
> -/* Stop speculative execution and prefetching of modified code. */
> +/*
> + * This function forces the icache and prefetched instruction stream to
> + * catch up with reality in two very specific cases:
> + *
> + *  a) Text was modified using one virtual address and is about to be 
> executed
> + * from the same physical page at a different virtual address.
> + *
> + *  b) Text was modified on a different CPU, may subsequently be
> + * executed on this CPU, and you want to make sure the new version
> + * gets executed.  This generally means you're calling this in a IPI.
> + *
> + * If you're calling this for a different reason, you're probably doing
> + * it wrong.

"... and think hard before you call this - it is slow."

I'd add that now that it is even slower than CPUID.

> + */
>  static inline void sync_core(void)
>  {
> - int tmp;
> -
> -#ifdef CONFIG_X86_32
>   /*
> -  * Do a CPUID if available, otherwise do a jump.  The jump
> -  * can conveniently enough be the jump around CPUID.
> +  * There are quite a few ways to do this.  IRET-to-self is nice
> +  * because it works on every CPU, at any CPL (so it's compatible
> +  * with paravirtualization), and it never exits to a hypervisor.
> +  * The only down sides are that it's a bit slow (it seems to be
> +  * a bit more than 2x slower than the fastest options) and that
> +  * it unmasks NMIs.

Ewww, I hadn't thought of that angle. Aren't we going to get in all
kinds of hard to debug issues due to that couple of cycles window of
unmasked NMIs?

We sync_core in some NMI handler and then right in the middle of it we
get another NMI. Yeah, we have the nested NMI stuff still but I'd like
to avoid complications if possible.

> The "push %cs" is needed because, in
> +  * paravirtual environments, __KERNEL_CS may not be a valid CS
> +  * value when we do IRET directly.
> +  *
> +  * In case NMI unmasking or performance every becomes a problem,
> +  * the next best option appears to be MOV-to-CR2 and an
> +  * unconditional jump.  That sequence also works on all CPUs,
> +  * but it will fault at CPL3.

Does it really have to be non-priviledged?

If not, there are a couple more serializing insns:

"• Privileged serializing instructions — INVD, INVEPT, INVLPG,
INVVPID, LGDT, LIDT, LLDT, LTR, MOV (to control register, with the
exception of MOV CR83), MOV (to debug register), WBINVD, and WRMSR"

What about INVD? It is expensive too :-)

Can't we use, MOV %dr or so? With previously saving/restoring the reg?

WBINVD could be another candidate, albeit a big hammer.

WRMSR maybe too. If it faults, it's fine too because then you have the
IRET automagically. Hell, we could even make it fault on purpose by
writing into an invalid MSR but then we're back to the unmasking NMIs...
:-\

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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

Re: [Xen-devel] [PATCH 1/2] xen/x86: return partial memory map in case of not enough space

[Juergen Gross]

On 05/12/16 18:17, Jan Beulich wrote:
 On 05.12.16 at 17:34,  wrote:
>> For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
>> caller's buffer can't hold all entries.
>>
>> This is a problem as the caller has normally a static buffer defined
>> and when he is doing the call no dynamic memory allocation is
>> possible as nothing is yet known about the system's memory layout.
>>
>> Instead of just fail deliver as many memory map entries as possible
>> and return with E2BIG indicating the result was incomplete. Then the
>> caller will be capable to use at least some memory reported to exist
>> to allocate a larger buffer for the complete memory map.
> 
> This makes no sense, as what we're talking about here is the
> machine memory map, and the calling Dom0 kernel can't allocate
> from that pool directly. Instead it would need its own memory
> map to know where to place such a larger buffer, and this map
> is usually just one or two entries large.

This is true. In practice, however, things are a little bit more
complicated:

Linux being started as dom0 tries to rearrange memory layout to match
the one of the physical machine. It will only add memory to its
allocator which is known to either not need to be moved or which has
already been moved. And this decision is based on the machine memory
map.

I admit it is a Linux kernel private decision how to handle the boot and
adding of memory to its allocator. OTOH the "all or nothing" approach of
the hypervisor regarding delivery of the machine memory map is a little
bit strange, especially as the BIOS is returning the E820 map one entry
after the other.

> For that reason I'm not convinced we need or want this change.

It would certainly make it easier for the Linux kernel.


Juergen

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

[Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm
testid xen-boot

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  24542192519d21719377d89f14654b3afd993a61
  Bug not present: c6f51aabaf400f357eebe8f8f17e8bb39fc033dc
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/102987/


  commit 24542192519d21719377d89f14654b3afd993a61
  Author: Kashyap Desai 
  Date:   Fri Oct 21 06:33:32 2016 -0700
  
  scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) 
devices
  
  [ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
  
  Commit 02b01e010afe ("megaraid_sas: return sync cache call with
  success") modified the driver to successfully complete SYNCHRONIZE_CACHE
  commands without passing them to the controller. Disk drive caches are
  only explicitly managed by controller firmware when operating in RAID
  mode. So this commit effectively disabled writeback cache flushing for
  any drives used in JBOD mode, leading to data integrity failures.
  
  [mkp: clarified patch description]
  
  Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
  CC: sta...@vger.kernel.org
  Signed-off-by: Kashyap Desai 
  Signed-off-by: Sumit Saxena 
  Reviewed-by: Tomas Henzl 
  Reviewed-by: Hannes Reinecke 
  Reviewed-by: Ewan D. Milne 
  Signed-off-by: Martin K. Petersen 
  Signed-off-by: Sasha Levin 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm.xen-boot
 --summary-out=tmp/102987.bisection-summary --basis-template=101675 
--blessings=real,real-bisect linux-3.18 
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm xen-boot
Searching for failure / basis pass:
 102920 fail [host=nobling1] / 101675 [host=pinot0] 101662 [host=godello0] 
101648 [host=elbling0] 101637 [host=godello1] 101623 [host=merlot1] 101603 
[host=italia0] 101584 [host=nobling0] 101570 [host=nocera0] 101561 
[host=elbling1] 101552 [host=italia1] 101541 ok.
Failure / basis pass flights: 102920 / 101541
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest ff8e021225ce5d2ca962ea433172df42f2d52c78 
c3b131294aa42b7997cc9b9a0bbb2934aa27fd6c 
ac3d826bef907afe35f80ecccbcdd57223df4b88 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
89c4cbe8d234049b0145e4dc5e5d19d626250b57 
4220231eb22235e757d269722b9f6a594fbcb70f 
8e4b2676685f50bc26f03b5f62d8b7aea8e69dbf
Basis pass 538220c3c42cad0adbd818b6a931c69492a572de 
e89b4a7aefce9cb02963920712ba7cdd13641644 
3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
570117996772b762e9654e58e708943a4db68b4f 
05e379bd279768495cdc516f17a120e30dfbcca5
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#538220c3c42cad0adbd818b6a931c69492a572de-ff8e021225ce5d2ca962ea433172df42f2d52c78
 
git://git.sv.gnu.org/gnulib.git#e89b4a7aefce9cb02963920712ba7cdd13641644-c3b131294aa42b7997cc9b9a0bbb2934aa27fd6c
 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430-ac3d826bef907afe35f80ecccbcdd57223df4b88
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-89c4cbe8d234049b0145e4dc5e5d19d626250b57
 

Re: [Xen-devel] Please Welcome Our New Release Manager

[Edgar E. Iglesias]

On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Wei Liu wrote:
> > Dear community members,
> > 
> > I'm pleased to announce that Julien Grall  will be
> > the Release Manager for the next Xen release.
> > 
> > The appointment was voted by the Committers and the vote passed.
> > 
> > Julien has done excellent jobs in many aspects. He has been an active
> > developer for the past few years and contributed a lot of code for Xen
> > on ARM. He has been doing a good job in co-maintaining Xen on ARM with
> > Stefano Stabellini. Particularly in 4.8 release, he showed his ability
> > to make balanced decisions and influence other contributors to move
> > various projects forward. He also expressed desire to work with greater
> > Xen community and make bigger impact.
> > 
> > All in all, we believe Julien will do a good job in managing the next
> > release. Thanks Julien for stepping up.
> 
> Congratulations!

Congrats Julien! :-)

Cheers,
Edgar

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

[Xen-devel] [PATCH] tools/xenstore: avoid unterminated string in xs_directory_part()

[Juergen Gross]

Commit d4016288ab1f ("xenstore: support XS_DIRECTORY_PART in
libxenstore") introduced a theoretical bug: the generation count of
the read node is transferred via strncpy without forcing a NUL byte
at the end. Correct this.

Signed-off-by: Juergen Gross 
---
 tools/xenstore/xs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index e462a20..3ce7157 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -589,7 +589,7 @@ static char **xs_directory_part(struct xs_handle *h, 
xs_transaction_t t,
struct iovec iovec[2];
char *result = NULL, *strings = NULL;
 
-   gen[0] = 0;
+   memset(gen, 0, sizeof(gen));
iovec[0].iov_base = (void *)path;
iovec[0].iov_len = strlen(path) + 1;
 
@@ -616,7 +616,7 @@ static char **xs_directory_part(struct xs_handle *h, 
xs_transaction_t t,
continue;
}
} else
-   strncpy(gen, result, sizeof(gen));
+   strncpy(gen, result, sizeof(gen) - 1);
 
result_len -= strlen(result) + 1;
strings = realloc(strings, off + result_len);
-- 
2.10.2


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

Re: [Xen-devel] [PATCH v4 00/12] xenstore: support reading directory with many children

[Juergen Gross]

On 05/12/16 19:19, Andrew Cooper wrote:
> On 05/12/16 12:05, Wei Liu wrote:
>> On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote:
>> [...]
>>> Juergen Gross (12):
>>>   xenstore: modify add_change_node() parameter types
>>>   xenstore: call add_change_node() directly when writing node
>>>   xenstore: use common tdb record header in xenstore
>>>   xenstore: add per-node generation counter
>>>   xenstore: add support for reading directory with many children
>>>   xenstore: support XS_DIRECTORY_PART in libxenstore
>>>   xenstore: use array for xenstore wire command handling
>>>   xenstore: let command functions return error or success
>>>   xenstore: make functions static
>>>   xenstore: add helper functions for wire argument parsing
>>>   xenstore: add small default data buffer to internal struct
>>>   xenstore: handle memory allocation failures in xenstored
>>>
>> Applied to staging.
> 
> XenServer's Coverity has run, and has a few things to say.  Its not
> obvious (i.e. I can't trivially identify) if these are preexisting bugs
> which your code has brought to light, or introduced by your series.
> 
> Both do_rm() and do_mkdir() suffer from the same problem.
> 
> onearg(in) may return NULL, which results in get_node_canonicalized()
> setting name to NULL and returning NULL.  name is then dereferenced in
> the error path by get_parent()/create_node() respectively.

No. errno will be EINVAL and this will prohibit to enter the said paths
guarded by errno == ENOENT.

> There are two complains of leaking a talloc_array() allocation.  First
> in do_set_perms() via the xs_strings_to_perms() failure path and second

No. The allocation context is "node" which is allocated using "in" as
allocation context. This is freed when the command has been processed.

> in send_directory_part() via the success path.  The use of

No again. Allocation context is "in" to be freed after processing the
command.

> talloc_array() in add_event() would suggest that you are expected to
> call talloc_free() on the result, unless I am missing something subtle.

You do. The free in add_event() is done as the allocation context might
be NULL (e.g. when called from domain_cleanup()). So here the free is
really needed in order to avoid a leak.

> There is another resource leak complaint of bdata in send_reply(),
> although this case clearly hasn't observed the list_add_tail(), so I
> don't think this is a real issue.

Right.

> Finally, xs_directory_part(), on line 619 uses a strncpy() for all bytes
> of gen, but doesn't necesserily NULL terminate it, and is later used by
> strcmp().

This is a real issue. I'll send a patch.


Juergen

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

[Xen-devel] [xen-4.8-testing baseline test] 102940: tolerable FAIL

[osstest service owner]

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail 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 12 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop 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-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   never pass

version targeted for testing:
 xen  a7a578ce6b8634eec30cb8445ea98e18d9b4e9b8
baseline version:
 xen  a7a578ce6b8634eec30cb8445ea98e18d9b4e9b8

Last test of basis   102940  2016-12-05 12:52:01 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17141 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun  

Re: [Xen-devel] [PATCH 5/8] x86/hvm: Don't raise #GP behind the emulators back for MSR accesses

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, December 05, 2016 6:09 PM
> 
> The current hvm_msr_{read,write}_intercept() infrastructure calls
> hvm_inject_hw_exception() directly to latch a fault, and returns
> X86EMUL_EXCEPTION to its caller.
> 
> This behaviour is problematic for the hvmemul_{read,write}_msr() paths, as the
> fault is raised behind the back of the x86 emulator.
> 
> Alter the behaviour so hvm_msr_{read,write}_intercept() simply returns
> X86EMUL_EXCEPTION, leaving the callers to actually inject the #GP fault.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v2 4/4] x86/hvm: Move hvm_hypervisor_cpuid_leaf() handling into cpuid_hypervisor_leaves()

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, December 06, 2016 2:25 AM
> 
> This reduces the net complexity of CPUID handling by having all adjustments in
> at the same place.  Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf()
> infrastructure.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v2 3/4] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, December 06, 2016 2:25 AM
> 
> This reduces the net complexity of CPUID handling by having all adjustments in

remove 'in'

> at the same place.  Remove the now-unused hvm_funcs.cpuid_intercept
> infrastructure.
> 
> The SYSCALL feature hiding is tweaked when moved.  In principle, an
> administrator can choose to explicitly hide the SYSCALL feature from the
> guest, as it has a separate feature bit.  If this is the case, the feature
> shouldn't be set behind the back of the administrators wishes.  (Not that many
> 64bit OSes would function in this scenario.)  In reality, SYSCALL will always
> be set in edx at this point.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH] xen-scsifront: Add a missing call to kfree

[Juergen Gross]

On 05/12/16 21:53, Dan Carpenter wrote:
> On Mon, Nov 21, 2016 at 07:01:36AM +0100, Juergen Gross wrote:
>> On 19/11/16 19:22, Quentin Lambert wrote:
>>> Most error branches following the call to kmalloc contain
>>> a call to kfree. This patch add these calls where they are
>>> missing.
>>>
>>> This issue was found with Hector.
>>>
>>> Signed-off-by: Quentin Lambert 
>>
>> Nice catch. I think this will need some more work, I'll do a
>> follow-on patch.
>>
> 
> The error handling is really weird.  Could you send your follow on to
> this thread?

I did:

https://lkml.org/lkml/2016/12/2/17


Juergen


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

Re: [Xen-devel] mpt3sas bug with Debian jessie kernel only under Xen - "swiotlb buffer is full"

[Andy Smith]

Hi Andrew,

On Sun, Dec 04, 2016 at 03:59:20PM +, Andrew Cooper wrote:
> On 04/12/16 08:32, Andy Smith wrote:
> > Under the Debian jessie amd64 kernel (linux-image-3.16.0-4-amd64
> > 3.16.36-1+deb8u2) running under Xen, I cannot put the system's
> > storage under heavy load without receiving a bunch of "swiotlb
> > buffer is full" kernel error messages and severely degraded
> > performance. Sometimes the system panics and reboots itself.

[…]

> Can you try these two patches from the XenServer Patch queue?
> https://github.com/xenserver/linux-3.x.pg/blob/master/master/series#L613-L614

Looking good.

Using those patches I'm ~20 minutes into this now:

Every 2.0s: cat /proc/mdstat Tue Dec  6 
02:16:40 2016

Personalities : [raid1] [raid10]
md5 : active raid10 sdb[0] sda[1]
  1875243008 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  [==>..]  check = 11.5% (217058176/1875243008) 
finish=133.9min speed=206252K/sec
  bitmap: 0/14 pages [0KB], 65536KB chunk

md4 : active raid10 sdc[0] sdd[1]
  3906886656 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
  [>]  check =  2.6% (102650880/3906886656) 
finish=674.4min speed=94007K/sec
  bitmap: 0/30 pages [0KB], 65536KB chunk

…where previously it would have given kernel errors within 5
seconds, so I think that fixes it. I will have to perform some more
strenuous testing.

Those two patches did not apply cleanly to source of
linux-image-3.16.0-4-amd64 3.16.36-1+deb8u2. The last bit of each
patch was rejected, so I removed them and put them into a separate
patch file (0003-fixup.patch attached).

I have not done this process in a long time so just for the
archives, my process was as per:


https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official

# mkdir -p /data/debian
# chown andy: /data/debian
# apt-get install build-essential fakeroot
# apt-get build-dep linux
$ cd /data/debian
$ apt-get source linux
$ wget 
https://raw.githubusercontent.com/xenserver/linux-3.x.pg/master/master/0001-dma-add-dma_get_required_mask_from_max_pfn.patch
$ wget 
https://raw.githubusercontent.com/xenserver/linux-3.x.pg/master/master/0002-x86-xen-correct-dma_get_required_mask-for-Xen-PV-gue.patch
$ # remove last parts of each patch file, create 0003-fixup.patch that performs 
equivalent changes
$ cd linux-3.16.36
$ # applying these patches is going to change symbols so changing the abiname
$ # is necessary.
$ # See https://kernel-handbook.alioth.debian.org/ch-versions.html#s-abi-name
$ sed -i -e 's/^abiname: 4/abiname: 4bf/' debian/config/defines
$ fakeroot debian/rules debian/control-real
$ bash debian/bin/test-patches -f amd64 
../0001-dma-add-dma_get_required_mask_from_max_pfn.patch 
../0002-x86-xen-correct-dma_get_required_mask-for-Xen-PV-gue.patch 
../0003-fixup.patch
# dpkg -i ../linux-headers-3.16.0-4bf-amd64_3.16.36-1+deb8u2a~test_amd64.deb 
../linux-image-3.16.0-4bf-amd64_3.16.36-1+deb8u2a~test_amd64.deb

boot into new kernel under Xen

$ uname -a
Linux elephant 3.16.0-4bf-amd64 #1 SMP Debian 3.16.36-1+deb8u2a~test 
(2016-12-05) x86_64 GNU/Linux

I think my next steps should be:

1. Do some more strenuous testing

2. Report bug against source package "linux" in Debian jessie with
   pointer to those two patches.

3. Check if those fixes are already applied in Debian backports
   and/or Debian testing linux package.

> > Dec  4 07:06:00 elephant kernel: [22019.373653] mpt3sas :01:00.0: 
> > swiotlb buffer is full (sz: 57344 bytes)
> > Dec  4 07:06:00 elephant kernel: [22019.374707] mpt3sas :01:00.0: 
> > swiotlb buffer is full
> > Dec  4 07:06:00 elephant kernel: [22019.375754] BUG: unable to handle 
> > kernel NULL pointer dereference at 0010
> > Dec  4 07:06:00 elephant kernel: [22019.376430] IP: [] 
> > _base_build_sg_scmd_ieee+0x1f9/0x2d0 [mpt3sas]
> > Dec  4 07:06:00 elephant kernel: [22019.377122] PGD 0
> 
> This alone is a clear error handling bug in the mpt3sas driver.  It
> hasn't checked the DMA mapping call for a successful mapping before
> following the NULL pointer it got given back.  It is collateral damage
> from the swiotlb buffer being full, but a bug none the less.

Does that require reporting as an upstream linux bug in mpt3sas
then?

Thanks for your help.

Cheers,
Andy
diff -u a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
--- a/drivers/xen/swiotlb-xen.c	2016-06-15 20:29:36.0 +
+++ b/drivers/xen/swiotlb-xen.c	2016-12-05 07:05:13.009992832 +
@@ -673,6 +673,13 @@
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_dma_supported);
 
+u64
+xen_swiotlb_get_required_mask(struct device *dev)
+{
+	return DMA_BIT_MASK(64);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_get_required_mask);
+
 int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask)
 {
diff -u a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
--- a/include/linux/dma-mapping.h	2016-06-15 20:29:36.0 +
+++ 

[Xen-devel] [linux-4.1 test] 102929: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-rtds  broken
 test-armhf-armhf-xl-vhd   broken
 test-armhf-armhf-xl-multivcpu  broken
 test-armhf-armhf-libvirt-xsm  broken
 test-armhf-armhf-xl-xsm   broken
 test-armhf-armhf-xl-arndale   broken
 test-armhf-armhf-libvirt  broken
 test-armhf-armhf-xl-cubietruck  broken
 test-armhf-armhf-libvirt-qcow2  broken
 test-armhf-armhf-xl-credit2   broken
 test-armhf-armhf-xl   broken
 test-armhf-armhf-libvirt-raw  broken
 test-amd64-amd64-xl-pvh-intel  6 xen-bootfail REGR. vs. 101737
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot   fail REGR. vs. 101737
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 101737
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101737
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101737
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 101737
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail REGR. vs. 101737
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 101737
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101737
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101737
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail REGR. vs. 101737
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail REGR. vs. 101737
 build-armhf-pvops 5 kernel-build   fail in 102733 REGR. vs. 101737

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 102733 pass in 102886
 test-armhf-armhf-libvirt-xsm 14 guest-stop   fail in 102755 pass in 102886
 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeat fail in 102755 pass in 
102929
 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 102829 pass in 102886
 test-amd64-i386-xl-xsm6 xen-boot fail in 102886 pass in 102929
 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail in 102886 pass in 
102929
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 102886 pass 
in 102929
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 102733
 test-amd64-amd64-libvirt  6 xen-boot   fail pass in 102733
 test-amd64-i386-xl-raw6 xen-boot   fail pass in 102733
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 102755
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 102755
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot   fail pass in 102829
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
102886
 test-amd64-amd64-libvirt-vhd  6 xen-boot   fail pass in 102886

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 102755 like 
101715
 test-armhf-armhf-xl-credit2  11 guest-start fail in 102829 like 101737
 test-armhf-armhf-xl-xsm  11 guest-start fail in 102829 like 101737
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 102886 blocked in 101737
 test-armhf-armhf-xl-rtds 16 guest-start.2 fail in 102886 blocked in 101737
 test-armhf-armhf-libvirt 15 guest-start/debian.repeat fail in 102886 like 
101672
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 102886 like 
101687
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 102886 like 101715
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 102886 
like 101715
 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 102886 like 
101737
 test-armhf-armhf-xl15 guest-start/debian.repeat fail in 102886 like 101737
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail in 102886 like 
101737
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 102886 like 
101737
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install fail in 102886 like 101737
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 102886 like 
101737
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail in 102886 like 101737
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101737
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101737
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101737

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)  blocked in 102733 n/a
 test-armhf-armhf-libvirt  

[Xen-devel] [DOC v2] Xen transport for 9pfs

[Stefano Stabellini]

Changes in v2:
- fix copy/paste error
- rename ring-ref- to ring-ref
- fix memory barriers
- add "verify prod/cons against local copy"
- add a paragraph on high level design
- add a note on the maximum possible max-ring-page-order value
- add mechanisms to avoid unnecessary evtchn notifications

---

# Xen transport for 9pfs version 1 

## Background

9pfs is a network filesystem protocol developed for Plan 9. 9pfs is very
simple and describes a series of commands and responses. It is
completely independent from the communication channels, in fact many
clients and servers support multiple channels, usually called
"transports". For example the Linux client supports tcp and unix
sockets, fds, virtio and rdma.


### 9pfs protocol

This document won't cover the full 9pfs specification. Please refer to
this [paper] and this [website] for a detailed description of it.
However it is useful to know that each 9pfs request and response has the
following header:

struct header {
uint32_t size;
uint8_t id;
uint16_t tag;
} __attribute__((packed));

0 4  57
+-+--++
|  size   |id|tag |
+-+--++

- *size*
The size of the request or response.

- *id*
The 9pfs request or response operation.

- *tag*
Unique id that identifies a specific request/response pair. It is used
to multiplex operations on a single channel.

It is possible to have multiple requests in-flight at any given time.


## Rationale

This document describes a Xen based transport for 9pfs, in the
traditional PV frontend and backend format. The PV frontend is used by
the client to send commands to the server. The PV backend is used by the
9pfs server to receive commands from clients and send back responses.

The transport protocol supports multiple rings up to the maximum
supported by the backend. The size of every ring is also configurable
and can span multiple pages, up to the maximum supported by the backend
(although it cannot be more than 2MB). The design is to exploit
parallelism at the vCPU level and support multiple outstanding requests
simultaneously.

This document does not cover the 9pfs client/server design or
implementation, only the transport for it.


## Xenstore

The frontend and the backend connect via xenstore to exchange
information. The toolstack creates front and back nodes with state
[XenbusStateInitialising]. The protocol node name is **9pfs**.

Multiple rings are supported for each frontend and backend connection.

### Frontend XenBus Nodes

num-rings
 Values: 

 Number of rings. It needs to be lower or equal to max-rings.

port- (port-0, port-1, etc)
 Values: 

 The identifier of the Xen event channel used to signal activity
 in the ring buffer. One for each ring.

ring-ref (ring-ref0, ring-ref1, etc)
 Values: 

 The Xen grant reference granting permission for the backend to
 map a page with information to setup a share ring. One for each
 ring.

### Backend XenBus Nodes

Backend specific properties, written by the backend, read by the
frontend:

version
 Values: 

 Protocol version supported by the backend. Currently the value is
 1.

max-rings
 Values: 

 The maximum supported number of rings.

max-ring-page-order
 Values: 

 The maximum supported size of a memory allocation in units of
 lb(machine pages), e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
 etc.

Backend configuration nodes, written by the toolstack, read by the
backend:

path
 Values: 

 Host filesystem path to share.

tag
 Values: 

 Alphanumeric tag that identifies the 9pfs share. The client needs
 to know the tag to be able to mount it.

security_model
 Values: "none"

 *none*: files are stored using the same credentials as they are
 created on the guest
 Only "none" is supported in this version of the protocol.


### State Machine

Initialization:

*Front*   *Back*
XenbusStateInitialising   XenbusStateInitialising
- Query virtual device- Query backend device
  properties.   identification data.
- Setup OS device instance.   - Publish backend features
- Allocate and initialize the   and transport parameters
  request ring.  |
- Publish transport parameters   |
  that will be in effect during  V
  this connection.XenbusStateInitWait
 |
 |
 V
   XenbusStateInitialised

  - Query 

[Xen-devel] [qemu-upstream-4.8-testing baseline test] 102941: tolerable FAIL

[osstest service owner]

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-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-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-libvirt 15 guest-start/debian.repeatfail   never pass

version targeted for testing:
 qemuu4220231eb22235e757d269722b9f6a594fbcb70f
baseline version:
 qemuu4220231eb22235e757d269722b9f6a594fbcb70f

Last test of basis   102941  2016-12-05 12:51:08 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17141 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-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

[Andrew Cooper]

On 05/12/2016 19:17, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Andrew Cooper wrote:
>> None of these barriers serve any purpose, as they are not synchronising with
>> any anything on remote CPUs.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>>
>> Restricting to just the $ARCH maintainers, as this is a project-wide sweep.
>>
>> Julien/Stefano: I think the ARM smpboot inhereted the erronious barrier usage
>> from x86, but I don't know whether further development has gained a 
>> dependence
>> on them.
> We turned them into smp_wmb already (kudos to IanC).

Right, but the entire point I am trying to argue is that they are not
needed in the first place.

~Andrew

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

Re: [Xen-devel] Please Welcome Our New Release Manager

[Andrew Cooper]

On 05/12/2016 20:41, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote:
>> On Mon, 5 Dec 2016, Wei Liu wrote:
>>> Dear community members,
>>>
>>> I'm pleased to announce that Julien Grall  will be
>>> the Release Manager for the next Xen release.
>>>
>>> The appointment was voted by the Committers and the vote passed.
>>>
>>> Julien has done excellent jobs in many aspects. He has been an active
>>> developer for the past few years and contributed a lot of code for Xen
>>> on ARM. He has been doing a good job in co-maintaining Xen on ARM with
>>> Stefano Stabellini. Particularly in 4.8 release, he showed his ability
>>> to make balanced decisions and influence other contributors to move
>>> various projects forward. He also expressed desire to work with greater
>>> Xen community and make bigger impact.
>>>
>>> All in all, we believe Julien will do a good job in managing the next
>>> release. Thanks Julien for stepping up.
>> Congratulations!
> Indeed! Congratulations and also I would like to thank Wei Liu for doing
> an fantastic job on the the last releases!

Three cheers to Wei.  Good luck to Julien.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101675
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot fail REGR. vs. 101675
 test-amd64-i386-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 101675
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 101675
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-bootfail REGR. vs. 101675
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 101675
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot fail REGR. vs. 101675
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail REGR. vs. 101675
 test-amd64-amd64-libvirt-xsm  6 xen-boot fail REGR. vs. 101675
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 101675
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 101675
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host   fail REGR. vs. 101675
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host   fail REGR. vs. 101675
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail REGR. vs. 101675
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101675
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101675
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101675
 build-i386-pvops  5 kernel-build   fail in 102732 REGR. vs. 101675
 build-armhf-libvirt  4 host-build-prep fail in 102875 REGR. vs. 101675

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair 9 xen-boot/src_host  fail pass in 102732
 test-amd64-amd64-pair10 xen-boot/dst_host  fail pass in 102732
 test-amd64-amd64-xl-xsm   6 xen-boot   fail pass in 102732
 test-amd64-amd64-i386-pvgrub  6 xen-boot   fail pass in 102754
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail pass in 102823
 test-amd64-amd64-libvirt  6 xen-boot   fail pass in 102823
 test-amd64-i386-xl-raw6 xen-boot   fail pass in 102875
 test-amd64-amd64-xl-credit2   6 xen-boot   fail pass in 102875
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat  fail pass in 102875

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101675
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101675
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101675
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101675
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101675
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101675
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101675

Tests which did not succeed, but are not blocking:
 test-amd64-i386-freebsd10-i386  1 build-check(1) blocked in 102732 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
102732 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
102732 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
102732 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 102732 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 102732 n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)  blocked in 102732 n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)  blocked in 102732 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 102732 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 102732 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)blocked in 102732 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 102732 n/a
 test-amd64-i386-xl1 build-check(1)   blocked in 102732 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked in 102732 n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked in 102732 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)blocked in 102732 n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked in 102732 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1) blocked in 102732 n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked in 102732 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)   blocked in 102732 n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked in 102732 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)blocked in 102732 n/a
 test-amd64-i386-pair  1 

[Xen-devel] [PATCH v11 06/13] efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   it in e820 memory map and map it in Xen virtual address space. This
   means that the code referring to Xen command line, loaded modules and
   EFI memory map, mostly in __start_xen(), will be further complicated
   and diverge from legacy BIOS cases. Additionally, both former things
   have to be placed below 4 GiB because their addresses are stored in
   multiboot_info_t structure which has 32-bit relevant members.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase Xen
   binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we use this memory pool for Xen and modules command
   line storage (it would be used when xen.efi is executed as EFI application)
   then we should add, I think, about 1 KiB. In this case, to be on safe
   side, we should assume at least 64 KiB pool for early memory allocations.
   Which is about 4 times of our earlier calculations. However, during
   discussion on Xen-devel Jan Beulich suggested that just in case we should
   use 1 MiB memory pool like it is in original place_string() implementation.
   So, let's use 1 MiB as it was proposed. If we think that we should not
   waste unallocated memory in the pool on running system then we can mark
   this region as __initdata and move all required data to dynamically
   allocated places somewhere in __start_xen().

2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or 
.init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.

Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().

New allocator is quite generic and can be used on ARM platforms too.
Though it is not enabled on ARM yet due to lack of some prereq.
List of them is placed before ebmalloc code.

Signed-off-by: Daniel Kiper 
---
v11 - suggestions/fixes:
- #ifdef only EBMALLOC_SIZE from ebmalloc machinery
  (suggested by Jan Beulich).

v10 - suggestions/fixes:
- remove unneeded ARM free_ebmalloc_unused_mem() stub.

v9 - suggestions/fixes:
   - call free_ebmalloc_unused_mem() from efi_init_memory()
 instead of xen/arch/arm/setup.c:init_done()
 (suggested by Jan Beulich),
   - improve comments.

v8 - suggestions/fixes:
   - disable whole ebmalloc machinery on ARM platforms,
   - add comment saying what should be done before
 enabling ebmalloc on ARM,
 (suggested by Julien Grall),
   - move ebmalloc code before efi-boot.h inclusion and
 remove unneeded forward declaration
 (suggested by Jan Beulich),
   - remove free_ebmalloc_unused_mem() call from
 xen/arch/arm/setup.c:init_done()
 (suggested by Julien Grall),
   - improve commit message.

v7 - suggestions/fixes:
   - enable most of ebmalloc machinery on ARM platforms
 (suggested by Jan Beulich),
   - remove unneeded cast
 (suggested by Jan Beulich),
   - wrap long line
 (suggested by Jan Beulich),
   - improve commit message.

v6 - suggestions/fixes:
   - optimize ebmalloc allocator,
   - move ebmalloc machinery to xen/common/efi/boot.c
 (suggested by Jan Beulich),
   - enforce PAGE_SIZE ebmalloc_mem alignment
 (suggested by Jan Beulich),
   - ebmalloc() must 

[Xen-devel] [PATCH v11 13/13] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v9 - suggestions/fixes:
   - use .L labels instead of numeric ones in multiboot2 data scanning loop
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - do not get Xen image load base address from
 multiboot2 information in x86_64 code
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich),
   - improve comments,
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - rename some types and constants,
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 xen/arch/x86/boot/head.S  |   16 
 xen/arch/x86/x86_64/asm-offsets.c |1 +
 xen/include/xen/multiboot2.h  |   13 +
 3 files changed, 30 insertions(+)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 390f72d..fabfa97 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
 /* Align modules at page boundry. */
 mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
 
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+   sym_offs(start), /* Min load address. */ \
+   0x, /* The end of image max load address (4 GiB - 
1). */ \
+   0x20, /* Load address alignment (2 MiB). */ \
+   MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
 /* Console flags tag. */
 mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -386,6 +393,15 @@ __start:
 cmp %edi,MB2_fixed_total_size(%ebx)
 jbe trampoline_bios_setup
 
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne .Lmb2_mem_lower
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp .Lmb2_next_tag
+
+.Lmb2_mem_lower:
 /* Get mem_lower from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
 cmove   MB2_mem_lower(%ecx),%edx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 5d7a8e5..beac5ca 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -174,6 +174,7 @@ void __dummy__(void)
 OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
 OFFSET(MB2_tag_type, multiboot2_tag_t, type);
 OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, 
load_base_addr);
 OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
 OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index 8dd5800..feb4297 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
 #define MULTIBOOT2_HEADER_TAG_EFI_BS   7
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE  10
 
 /* Header tag flags. */
 #define MULTIBOOT2_HEADER_TAG_REQUIRED 0
 #define MULTIBOOT2_HEADER_TAG_OPTIONAL 1
 
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH2
+
 /* Header console tag console_flags. */
 #define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED  1
 #define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED2
@@ -90,6 +96,7 @@
 #define MULTIBOOT2_TAG_TYPE_EFI_BS 18
 #define MULTIBOOT2_TAG_TYPE_EFI32_IH   19
 #define MULTIBOOT2_TAG_TYPE_EFI64_IH   20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR 21
 
 /* Multiboot 2 tag alignment. */
 #define MULTIBOOT2_TAG_ALIGN   8
@@ -120,6 +127,12 @@ typedef struct {
 typedef struct {
 u32 type;
 u32 size;
+u32 load_base_addr;
+} multiboot2_tag_load_base_addr_t;
+
+typedef struct {
+u32 type;
+u32 size;
 char string[];
 } 

[Xen-devel] [PATCH v11 11/13] x86: make Xen early boot code relocatable

[Daniel Kiper]

Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with that
problem we must make Xen early boot code relocatable and help boot loader to
relocate image in proper way by suggesting, not requesting specific load
addresses as it is right now, allowed address ranges. This patch does former.
It does not add multiboot2 protocol interface which is done in "x86: add
multiboot2 protocol support for relocatable images" patch.

This patch changes following things:
  - %esi and %r15d registers are used as a storage for Xen image load base
address (%r15d shortly because %rsi is used for EFI SystemTable address
in 64-bit code); both registers are (%esi is mostly) unused in early
boot code and preserved during C functions calls (%esi in 32-bit code
and %r15d in 64-bit code),
  - %fs is used as base for Xen data relative addressing in 32-bit code
if it is possible; %esi is used for that thing during error printing
because it is not always possible to properly and efficiently
initialize %fs.

Signed-off-by: Daniel Kiper 
---
v8 - suggestions/fixes:
   - use shld instead of mov and shr in BOOT_FS segment
 descriptor base address initialization
 (suggested by Jan Beulich),
   - simplify code updating frame addresses in page tables
 (suggested by Jan Beulich),
   - print Xen image base addresses using "%#lx" format
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - leave static mapping of first
 16 MiB in l2_identmap as is
 (suggested by Jan Beulich),
   - use xen_phys_start instead of xen_img_load_base_addr
 (suggested by Daniel Kiper and Jan Beulich),
   - simplify BOOT_FS segment descriptor
 base address initialization
 (suggested by Jan Beulich),
   - fix BOOT_FS segment limit
 (suggested by Jan Beulich),
   - do not rename sym_phys in this patch
 (suggested by Jan Beulich),
   - rename esi_offset/fs_offset to
 sym_esi/sym_fs respectively
 (suggested by Jan Beulich),
   - use add instead of lea in assembly
 error printing code
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - do not relocate Xen image if boot loader did work for us
 (suggested by Andrew Cooper and Jan Beulich),
   - initialize xen_img_load_base_addr in EFI boot code too,
   - properly initialize trampoline_xen_phys_start,
   - calculate Xen image load base address in
 x86_64 code ourselves,
 (suggested by Jan Beulich),
   - change how and when Xen image base address is printed,
   - use %fs instead of %esi for relative addressing
 (suggested by Andrew Cooper and Jan Beulich),
   - create esi_offset and fs_offset() macros in assembly,
   - calculate  mkelf32 argument automatically,
   - optimize and cleanup code,
   - improve comments,
   - improve commit message.

v3 - suggestions/fixes:
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - simplify Xen image load base address calculation
 (suggested by Jan Beulich),
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - use %esi instead of %fs for relative addressing;
 this way we get shorter and simpler code,
   - rename some variables and constants
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S  |  160 +
 xen/arch/x86/boot/trampoline.S|5 ++
 xen/arch/x86/boot/x86_64.S|   21 +++--
 xen/arch/x86/setup.c  |   14 ++--
 xen/arch/x86/x86_64/asm-offsets.c |3 +
 xen/include/asm-x86/page.h|2 +-
 6 files changed, 155 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index a7bc467..d992a95 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -13,12 +13,15 @@
 .code32
 
 #define sym_phys(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym)  sym_phys(sym)(%esi)
+#define sym_fs(sym)   %fs:sym_phys(sym)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
 #define BOOT_DS  0x0018
 #define BOOT_PSEUDORM_CS 

[Xen-devel] [PATCH v11 10/13] x86/setup: use XEN_IMG_OFFSET instead of...

[Daniel Kiper]

..calculating its value during runtime.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
 xen/arch/x86/setup.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index fa808ef..5d0830e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -943,7 +943,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 l4_pgentry_t *pl4e;
 l3_pgentry_t *pl3e;
 l2_pgentry_t *pl2e;
-uint64_t load_start;
 int i, j, k;
 
 /* Select relocation address. */
@@ -957,9 +956,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * with a barrier(). After this we must *not* modify static/global
  * data until after we have switched to the relocated pagetables!
  */
-load_start = (unsigned long)_start - XEN_VIRT_START;
 barrier();
-move_memory(e + load_start, load_start, _end - _start, 1);
+move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1);
 
 /* Walk initial pagetables, relocating page directory entries. */
 pl4e = __va(__pa(idle_pg_table));
-- 
1.7.10.4


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

[Xen-devel] [PATCH v11 09/13] x86: change default load address from 1 MiB to 2 MiB

[Daniel Kiper]

Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load address from 1 MiB to 2 MiB. This way page table
code will be nice and easy. Hence, there is a chance that it will be
less error prone too... :-)))

Additionally, drop first 2 MiB mapping from Xen image mapping.
It is no longer needed.

Signed-off-by: Daniel Kiper 
Reviewed-by: Jan Beulich 
---
v8 - suggestions/fixes:
   - drop first 2 MiB mapping from Xen image mapping
 (suggested by Jan Beulich),
   - improve commit message.

v7 - suggestions/fixes:
   - minor cleanups
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/Rules.mk  |3 +++
 xen/arch/x86/boot/head.S   |8 
 xen/arch/x86/boot/x86_64.S |5 +++--
 xen/arch/x86/setup.c   |3 ++-
 xen/arch/x86/xen.lds.S |2 +-
 6 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index e74fe62..d5d0651 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -90,7 +90,7 @@ all_symbols =
 endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
-   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
+   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 
$(XEN_IMG_OFFSET) \
   `$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . 
__2M_rwdata_end$$/0x\1/p'`
 
 ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 42be4bc..36e6386 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,12 @@
 
 # x86-specific definitions
 
+XEN_IMG_OFFSET := 0x20
+
 CFLAGS += -I$(BASEDIR)/include
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
 CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst 
$(BASEDIR)/,,$(CURDIR))/$@))'
 
 # Prevent floating-point variables from creeping into Xen.
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 6c97e1f..a7bc467 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -482,14 +482,6 @@ trampoline_setup:
 mov %eax,sym_phys(boot_tsc_stamp)
 mov %edx,sym_phys(boot_tsc_stamp+4)
 
-/*
- * During boot, hook 4kB mappings of first 2MB of memory into L2.
- * This avoids mixing cachability for the legacy VGA region, and is
- * corrected when Xen relocates itself.
- */
-mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
-mov %edi,sym_phys(l2_xenmap)
-
 /* Apply relocations to bootstrap trampoline. */
 mov sym_phys(trampoline_phys),%edx
 mov $sym_phys(__trampoline_rel_start),%edi
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 139b2ca..7890374 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -121,8 +121,9 @@ GLOBAL(l2_identmap)
  * page.
  */
 GLOBAL(l2_xenmap)
-idx = 0
-.rept 8
+.quad 0
+idx = 1
+.rept 7
 .quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + 
(PAGE_HYPERVISOR | _PAGE_PSE)
 idx = idx + 1
 .endr
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 3a7d21e..fa808ef 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -999,7 +999,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * Undo the temporary-hooking of the l1_identmap.  __2M_text_start
  * is contained in this PTE.
  */
-BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+BUG_ON(using_2M_mapping() &&
+   l2_table_offset((unsigned long)_erodata) ==
l2_table_offset((unsigned long)_stext));
 *pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index e0e2529..45251fd 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -55,7 +55,7 @@ SECTIONS
   __2M_text_start = .; /* Start of 2M superpages, mapped RX. */
 #endif
 
-  . = __XEN_VIRT_START + MB(1);
+  . = __XEN_VIRT_START + XEN_IMG_OFFSET;
   _start = .;
   .text : {
 _stext = .;/* Text and read-only data */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v11 12/13] x86/boot: rename sym_phys() to sym_offs()

[Daniel Kiper]

This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.

There is no functional change.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v8 - suggestions/fixes:
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S   |   38 +++---
 xen/arch/x86/boot/trampoline.S |2 +-
 xen/arch/x86/boot/wakeup.S |4 ++--
 xen/arch/x86/boot/x86_64.S |   18 +-
 4 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index d992a95..390f72d 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,9 +12,9 @@
 .text
 .code32
 
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
-#define sym_esi(sym)  sym_phys(sym)(%esi)
-#define sym_fs(sym)   %fs:sym_phys(sym)
+#define sym_offs(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym)  sym_offs(sym)(%esi)
+#define sym_fs(sym)   %fs:sym_offs(sym)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
@@ -97,7 +97,7 @@ multiboot2_header_start:
 
 /* EFI64 entry point. */
 mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
-   sym_phys(__efi64_start)
+   sym_offs(__efi64_start)
 
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -110,7 +110,7 @@ multiboot2_header_start:
 gdt_boot_descr:
 .word   7*8-1
 gdt_boot_base:
-.long   sym_phys(trampoline_gdt)
+.long   sym_offs(trampoline_gdt)
 .long   0 /* Needed for 64-bit lgdt */
 
 .align 4
@@ -130,23 +130,23 @@ efi_platform:
 .section .init.text, "ax", @progbits
 
 bad_cpu:
-add $sym_phys(.Lbad_cpu_msg),%esi   # Error message
+add $sym_offs(.Lbad_cpu_msg),%esi   # Error message
 jmp .Lget_vtb
 not_multiboot:
-add $sym_phys(.Lbad_ldr_msg),%esi   # Error message
+add $sym_offs(.Lbad_ldr_msg),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_st:
-add $sym_phys(.Lbad_ldr_nst),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nst),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_ih:
-add $sym_phys(.Lbad_ldr_nih),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nih),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_bs:
-add $sym_phys(.Lbad_ldr_nbs),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nbs),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
 jmp .Lsend_chr
 .Lmb2_efi_ia_32:
-add $sym_phys(.Lbad_efi_msg),%esi   # Error message
+add $sym_offs(.Lbad_efi_msg),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
 jmp .Lsend_chr
 .Lget_vtb:
@@ -354,7 +354,7 @@ __start:
 cli
 
 /* Load default Xen image load base address. */
-mov $sym_phys(__image_base__),%esi
+mov $sym_offs(__image_base__),%esi
 
 /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
 xor %edx,%edx
@@ -505,8 +505,8 @@ trampoline_setup:
 jnz 1f
 
 /* Initialize BSS (no nasty surprises!). */
-mov $sym_phys(__bss_start),%edi
-mov $sym_phys(__bss_end),%ecx
+mov $sym_offs(__bss_start),%edi
+mov $sym_offs(__bss_end),%ecx
 push%fs
 pop %es
 sub %edi,%ecx
@@ -579,22 +579,22 @@ trampoline_setup:
 
 /* Apply relocations to bootstrap trampoline. */
 mov sym_fs(trampoline_phys),%edx
-mov $sym_phys(__trampoline_rel_start),%edi
+mov $sym_offs(__trampoline_rel_start),%edi
 1:
 mov %fs:(%edi),%eax
 add %edx,%fs:(%edi,%eax)
 add $4,%edi
-cmp $sym_phys(__trampoline_rel_stop),%edi
+cmp $sym_offs(__trampoline_rel_stop),%edi
 jb  1b
 
 /* Patch in the trampoline segment. */
 shr $4,%edx
-mov $sym_phys(__trampoline_seg_start),%edi
+mov $sym_offs(__trampoline_seg_start),%edi
 1:
 mov %fs:(%edi),%eax
 mov %dx,%fs:(%edi,%eax)
 add $4,%edi
-cmp $sym_phys(__trampoline_seg_stop),%edi
+cmp $sym_offs(__trampoline_seg_stop),%edi
 jb  1b
 
 /* Do not parse command line on EFI platform here. */
@@ -620,7 +620,7 @@ trampoline_setup:
 push%eax
 
 /* Copy bootstrap trampoline to low memory, below 1MB. */
-mov 

[Xen-devel] [PATCH v11 08/13] x86/boot: implement early command line parser in C

[Daniel Kiper]

Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without playing
with segment registers) and much easier to maintain.

Additionally, put all common cmdline.c and reloc.c definitions
into defs.h header. This way we do not duplicate needlessly
some stuff.

And finally remove unused xen/include/asm-x86/config.h
header from reloc.c dependencies.

Suggested-by: Andrew Cooper 
Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v7 - suggestions/fixes:
   - add min() macro
 (suggested by Jan Beulich),
   - add padding to early_boot_opts_t
 in more standard way
 (suggested by Jan Beulich),
   - simplify defs.h dependencies
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - put common cmdline.c and reloc.c
 definitions into defs.h header
 (suggested by Jan Beulich),
   - use xen/include/xen/stdbool.h
 and bool type from it instead
 of own defined bool_t
 (suggested by Jan Beulich),
   - define delim_chars as constant
 (suggested by Jan Beulich),
   - properly align trampoline.S:early_boot_opts struct
 (suggested by Jan Beulich),
   - fix overflow check in strtoui()
 (suggested by Jan Beulich),
   - remove unused xen/include/asm-x86/config.h
 header from reloc.c dependencies,
   - improve commit message.

v4 - suggestions/fixes:
   - move to stdcall calling convention
 (suggested by Jan Beulich),
   - define bool_t and use it properly
 (suggested by Jan Beulich),
   - put list of delimiter chars into
 static const char[]
 (suggested by Jan Beulich),
   - use strlen() instead of strlen_opt()
 (suggested by Jan Beulich),
   - change strtoi() to strtoui() and
 optimize it a bit
 (suggested by Jan Beulich),
   - define strchr() and use it in strtoui()
 (suggested by Jan Beulich),
   - optimize vga_parse()
 (suggested by Jan Beulich),
   - move !cmdline check from assembly to C
 (suggested by Jan Beulich),
   - remove my name from copyright (Oracle requirement)
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - optimize some code
 (suggested by Jan Beulich),
   - put VESA data into early_boot_opts_t members
 (suggested by Jan Beulich),
   - rename some functions and variables
 (suggested by Jan Beulich),
   - move around video.h include in xen/arch/x86/boot/trampoline.S
 (suggested by Jan Beulich),
   - fix coding style
 (suggested by Jan Beulich),
   - fix build with older GCC
 (suggested by Konrad Rzeszutek Wilk),
   - remove redundant comments
 (suggested by Jan Beulich),
   - add some comments
   - improve commit message
 (suggested by Jan Beulich).
---
 .gitignore |5 +-
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/boot/Makefile |   11 +-
 xen/arch/x86/boot/build32.mk   |2 +
 xen/arch/x86/boot/cmdline.S|  367 
 xen/arch/x86/boot/cmdline.c|  340 +
 xen/arch/x86/boot/defs.h   |   58 +++
 xen/arch/x86/boot/edd.S|3 -
 xen/arch/x86/boot/head.S   |8 +
 xen/arch/x86/boot/reloc.c  |   13 +-
 xen/arch/x86/boot/trampoline.S |   15 ++
 xen/arch/x86/boot/video.S  |7 -
 12 files changed, 437 insertions(+), 394 deletions(-)
 delete mode 100644 xen/arch/x86/boot/cmdline.S
 create mode 100644 xen/arch/x86/boot/cmdline.c
 create mode 100644 xen/arch/x86/boot/defs.h

diff --git a/.gitignore b/.gitignore
index a2f34a1..d2967d8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -250,9 +250,10 @@ xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
+xen/arch/x86/boot/cmdline.S
 xen/arch/x86/boot/reloc.S
-xen/arch/x86/boot/reloc.bin
-xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/boot/*.bin
+xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 2a0781a..e74fe62 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -220,5 +220,5 @@ clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
-   rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+   rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 06893d8..c6246c8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,9 +1,16 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = $(BASEDIR)/include/asm-x86/config.h 

[Xen-devel] [PATCH v11 03/13] x86: allow EFI reboot method neither on EFI platforms...

[Daniel Kiper]

..nor EFI platforms with runtime services enabled.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v6 - suggestions/fixes:
   - move this commit behind "efi: create efi_enabled()" commit
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - fix build error
 (suggested by Jan Beulich),
   - improve commit message.
---
 xen/arch/x86/shutdown.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 7a1a73a..55f6840 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -80,6 +80,9 @@ static void __init set_reboot_type(char *str)
 break;
 str++;
 }
+
+if ( reboot_type == BOOT_EFI && !efi_enabled(EFI_RS) )
+reboot_type = BOOT_INVALID;
 }
 custom_param("reboot", set_reboot_type);
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v11 01/13] x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper 
Reviewed-by: Jan Beulich 
---
v9 - suggestions/fixes:
   - use .L label instead of numeric one in multiboot2 data scanning loop;
 I hope that this change does not invalidate Jan's Reviewed-by
 (suggested by Jan Beulich).

v8 - suggestions/fixes:
   - use sizeof(/) instead of sizeof()
 if it is possible
 (suggested by Jan Beulich).

v7 - suggestions/fixes:
   - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively
 (suggested by Jan Beulich),
   - initialize mbi_out->flags using "|=" instead of "="
 (suggested by Jan Beulich),
   - use sizeof(*mmap_dst) instead of sizeof(memory_map_t)
 if it makes sense
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - do not index mbi_out_mods[] beyond its end
 (suggested by Andrew Cooper),
   - reduce number of casts
 (suggested by Andrew Cooper and Jan Beulich),
   - add braces to increase code readability
 (suggested by Andrew Cooper).

v5 - suggestions/fixes:
   - check multiboot2_tag_mmap_t.entry_size before
 multiboot2_tag_mmap_t.entries[] use
 (suggested by Jan Beulich),
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - use "type name[]" instad of "type name[0]"
 in xen/include/xen/multiboot2.h
 (suggested by Jan Beulich),
   - remove unneeded comment
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - avoid assembly usage in xen/arch/x86/boot/reloc.c,
   - fix boundary check issue and optimize
 for() loops in mbi2_mbi(),
   - move to stdcall calling convention,
   - remove unneeded typeof() from ALIGN_UP() macro
 (suggested by Jan Beulich),
   - add and use NULL definition in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - add :req to some .macro arguments
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - add .L to multiboot2_header_end label
 (suggested by Jan Beulich),
   - add .L to multiboot2_proto label
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  107 ++-
 xen/arch/x86/boot/reloc.c |  148 ++--
 xen/arch/x86/x86_64/asm-offsets.c |9 ++
 xen/include/xen/multiboot2.h  |  169 +
 5 files changed, 426 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..06893d8 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,6 +1,7 @@
 

[Xen-devel] [PATCH v11 07/13] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.

Signed-off-by: Daniel Kiper 
---
v10 - suggestions/fixes:
- replace ljmpl with lretq
  (suggested by Andrew Cooper),
- introduce efi_platform to increase code readability
  (suggested by Andrew Cooper).

v9 - suggestions/fixes:
   - use .L labels instead of numeric ones in multiboot2 data scanning loops
 (suggested by Jan Beulich).

v8 - suggestions/fixes:
   - use __bss_start(%rip)/__bss_end(%rip) instead of
 of .startof.(.bss)(%rip)/$.sizeof.(.bss) because
 latter is not tested extensively in different
 built environments yet
 (suggested by Andrew Cooper),
   - fix multiboot2 data scanning loop in x86_32 code
 (suggested by Jan Beulich),
   - add check for extra mem for mbi data if Xen is loaded
 via multiboot2 protocol on EFI platform
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v7 - suggestions/fixes:
   - do not allocate twice memory for trampoline if we were
 loaded via multiboot2 protocol on EFI platform,
   - wrap long line
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - improve label names in assembly
 error printing code
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - remove redundant BSS alignment,
   - update BSS alignment check,
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - call efi_arch_cpu() from efi_multiboot2()
 even if the same work is done later in
 other place right now
 (suggested by Jan Beulich),
   - xen/arch/x86/efi/stub.c:efi_multiboot2()
 fail properly on EFI platforms,
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - use 32-bit registers in x86_64 code if possible
 (suggested by Jan Beulich),
   - multiboot2 information address is 64-bit
 in x86_64 code, so, treat it is as is
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - leave only one space between rep and stosq
 (suggested by Jan Beulich),
   - improve error handling,
   - improve early error messages,
 (suggested by Jan Beulich),
   - improve early error messages printing code,
   - improve label names
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups.

v3 - suggestions/fixes:
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - switch CPU to x86_32 mode before
 jumping to 32-bit code
 (suggested by Andrew Cooper),
   - reduce code changes to increase patch readability
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform
 and find on my own multiboot2.mem_lower value,
   - stop execution if EFI platform is detected
 in legacy BIOS path.
---
 xen/arch/x86/boot/head.S  |  263 ++---
 xen/arch/x86/efi/efi-boot.h   |   54 +++-
 xen/arch/x86/efi/stub.c   |   38 ++
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/arch/x86/xen.lds.S|4 +-
 xen/common/efi/boot.c |   11 ++
 6 files changed, 349 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index d423fd8..ac93df0 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -89,6 +89,13 @@ multiboot2_header_start:
0, /* Number of the lines - no preference. */ \
0  /* Number of bits per pixel - no preference. */
 
+/* Inhibit bootloader from calling ExitBootServices(). */
+mb2ht_init MB2_HT(EFI_BS), MB2_HT(OPTIONAL)
+
+/* EFI64 entry point. */
+mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
+   sym_phys(__efi64_start)
+
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
 .Lmultiboot2_header_end:
@@ -100,20 +107,48 @@ multiboot2_header_start:
 gdt_boot_descr:
 .word   6*8-1
 .long   sym_phys(trampoline_gdt)
+.long   0 /* Needed for 64-bit lgdt */
+
+.align 4
+vga_text_buffer:
+.long   0xb8000
+
+efi_platform:
+.byte   0
 
 .Lbad_cpu_msg: .asciz "ERR: Not a 64-bit CPU!"
 

[Xen-devel] [PATCH v11 02/13] efi: create efi_enabled()

[Daniel Kiper]

First of all we need to differentiate between legacy BIOS
and EFI platforms during runtime, not during build, because
one image will have legacy and EFI code and can be executed
on both platforms. Additionally, we need more fine grained
knowledge about EFI environment and check for EFI platform
and EFI loader separately to properly support multiboot2
protocol. In general Xen loaded by this protocol uses memory
mappings and loaded modules in similar way to Xen loaded by
multiboot (v1) protocol. Hence, create efi_enabled() which
checks available features in efi_flags. This patch defines
EFI_BOOT, EFI_LOADER and EFI_RS features. EFI_BOOT is equal
to old efi_enabled == 1. EFI_RS ease control on runtime
services usage. EFI_LOADER tells that Xen was loaded
directly from EFI as PE executable.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
Reviewed-by: Jan Beulich 
---
v7 - suggestions/fixes:
   - remove efi_enabled(EFI_RS) check from mapcache_current_vcpu()
 (suggested by Daniel Kiper and Jan Beulich),
   - remove BUG() from xen/arch/x86/efi/stub.c:efi_rs_using_pgtables()
 (suggested by Daniel Kiper and Jan Beulich).

v6 - suggestions/fixes:
   - define efi_enabled() as "bool efi_enabled(unsigned int feature)"
 instead of "bool_t efi_enabled(int feature)"
 (suggested by Jan Beulich),
   - define efi_flags as unsigned int
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - squash three patches into one
 (suggested by Jan Beulich),
   - introduce all features at once
 (suggested by Jan Beulich),
   - efi_enabled() returns bool_t
 instead of unsigned int
 (suggested by Jan Beulich),
   - update commit message.

v4 - suggestions/fixes:
   - rename EFI_PLATFORM to EFI_BOOT
 (suggested by Jan Beulich),
   - move EFI_BOOT definition to efi struct definition
 (suggested by Jan Beulich),
   - remove unneeded efi.flags initialization
 (suggested by Jan Beulich),
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - do efi_enabled() cleanup
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message.

v3 - suggestions/fixes:
   - define efi struct in xen/arch/x86/efi/stub.c
 in earlier patch
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/dmi_scan.c|4 ++--
 xen/arch/x86/domain_page.c |2 +-
 xen/arch/x86/efi/stub.c|8 
 xen/arch/x86/mpparse.c |4 ++--
 xen/arch/x86/setup.c   |   12 +++-
 xen/arch/x86/shutdown.c|2 +-
 xen/arch/x86/time.c|2 +-
 xen/common/efi/boot.c  |   19 +++
 xen/common/efi/runtime.c   |   14 --
 xen/common/version.c   |2 +-
 xen/drivers/acpi/osl.c |2 +-
 xen/include/xen/efi.h  |8 ++--
 12 files changed, 49 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/dmi_scan.c b/xen/arch/x86/dmi_scan.c
index b049e31..8dcb640 100644
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -238,7 +238,7 @@ const char *__init dmi_get_table(paddr_t *base, u32 *len)
 {
static unsigned int __initdata instance;
 
-   if (efi_enabled) {
+   if (efi_enabled(EFI_BOOT)) {
if (efi_smbios3_size && !(instance & 1)) {
*base = efi_smbios3_address;
*len = efi_smbios3_size;
@@ -696,7 +696,7 @@ static void __init dmi_decode(struct dmi_header *dm)
 
 void __init dmi_scan_machine(void)
 {
-   if ((!efi_enabled ? dmi_iterate(dmi_decode) :
+   if ((!efi_enabled(EFI_BOOT) ? dmi_iterate(dmi_decode) :
dmi_efi_iterate(dmi_decode)) == 0)
dmi_check_system(dmi_blacklist);
else
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index d86f8fe..a58ef8e 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
  * domain's page tables but current may point at another domain's VCPU.
  * Return NULL as though current is not properly set up yet.
  */
-if ( efi_enabled && efi_rs_using_pgtables() )
+if ( efi_rs_using_pgtables() )
 return NULL;
 
 /*
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 07c2bd0..4158124 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -4,9 +4,10 @@
 #include 
 #include 
 
-#ifndef efi_enabled
-const bool_t efi_enabled = 0;
-#endif
+bool efi_enabled(unsigned int feature)
+{
+return false;
+}
 
 void __init efi_init_memory(void) { }
 
@@ -14,7 +15,6 @@ void efi_update_l4_pgtable(unsigned int l4idx, l4_pgentry_t 
l4e) { }
 
 bool_t efi_rs_using_pgtables(void)
 {
-

[Xen-devel] [PATCH v11 04/13] x86: properly calculate xen ELF end of image address

[Daniel Kiper]

This patch is prereq for "efi: build xen.gz with EFI code" patch which adds,
among others, xen/arch/x86/efi/relocs-dummy.S to xen.gz output. Below there
is a description why it is needed.

Currently xen ELF end of image address is calculated using first line from
"nm -nr xen/xen-syms" output. However, potentially it may contain symbol
address not related to the end of image in any way. It can happen if a symbol
is introduced with address larger than _end symbol address. Such situation
encountered when I linked xen ELF binary with xen/arch/x86/efi/relocs-dummy.S.
Then first line from "nm -nr xen/xen-syms" contained "82d0c000 A 
ALT_START"
and xen ELF image memory size was silently set to 1023 MiB. This issue happened
because there is no check which symbol address is used to calculate end of
image address. So, let's fix it and take ELF end of image address by reading
__2M_rwdata_end symbol address from nm output. This way xen ELF image build
process is not prone to changes in order of nm output.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v9 - suggestions/fixes:
   - use __2M_rwdata_end symbol instead of _end symbol
 (suggested by Jan Beulich),
   - really fix indention
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v8 - suggestions/fixes:
   - use spaces instead of tab in indentation
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v7 - suggestions/fixes:
   - use sed instead of awk
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 931917d..e40897f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -91,7 +91,7 @@ endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
-   `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+  `$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . 
__2M_rwdata_end$$/0x\1/p'`
 
 ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending eleventh version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known issues.

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
xen.efi will be extracted from xen(-syms)
file using objcopy or special custom tool,
  - xen.efi build will not so strongly depend
on a given GCC and binutils version.

Here is short list of changes since v10:
  - changed patches: 06 (small change suggested by Jan).

This is Xen 4.9 material.

If you are not interested in this patch series at all please
drop me a line and I will remove you from distribution list.

Daniel

 .gitignore|5 +-
 xen/arch/x86/Makefile |8 +-
 xen/arch/x86/Rules.mk |3 +
 xen/arch/x86/boot/Makefile|   12 +-
 xen/arch/x86/boot/build32.mk  |2 +
 xen/arch/x86/boot/cmdline.S   |  367 

 xen/arch/x86/boot/cmdline.c   |  340 

 xen/arch/x86/boot/defs.h  |   58 +
 xen/arch/x86/boot/edd.S   |3 -
 xen/arch/x86/boot/head.S  |  540 
++
 xen/arch/x86/boot/reloc.c |  151 +--
 xen/arch/x86/boot/trampoline.S|   22 +++-
 xen/arch/x86/boot/video.S |7 --
 xen/arch/x86/boot/wakeup.S|4 +-
 xen/arch/x86/boot/x86_64.S|   44 +++
 xen/arch/x86/dmi_scan.c   |4 +-
 xen/arch/x86/domain_page.c|2 +-
 xen/arch/x86/efi/Makefile |   12 +-
 xen/arch/x86/efi/efi-boot.h   |   65 +++---
 xen/arch/x86/efi/stub.c   |   46 ++-
 xen/arch/x86/mpparse.c|4 +-
 xen/arch/x86/setup.c  |   34 +++---
 xen/arch/x86/shutdown.c   |5 +-
 xen/arch/x86/time.c   |2 +-
 xen/arch/x86/x86_64/asm-offsets.c |   15 +++
 xen/arch/x86/xen.lds.S|   10 +-
 xen/common/efi/boot.c |   83 -
 xen/common/efi/runtime.c  |   23 +++-
 xen/common/version.c  |2 +-
 xen/drivers/acpi/osl.c|2 +-
 xen/include/asm-x86/page.h|2 +-
 xen/include/xen/efi.h |8 +-
 xen/include/xen/multiboot2.h  |  182 
 33 files changed, 1528 insertions(+), 539 deletions(-)

Daniel Kiper (13):
  x86: add multiboot2 protocol support
  efi: create efi_enabled()
  x86: allow EFI reboot method neither on EFI platforms...
  x86: properly calculate xen ELF end of image address
  efi: build xen.gz with EFI code
  efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms
  x86/boot: implement early command line parser in C
  x86: change default load address from 1 MiB to 2 MiB
  x86/setup: use XEN_IMG_OFFSET instead of...
  x86: make Xen early boot code relocatable
  x86/boot: rename sym_phys() to sym_offs()
  x86: add multiboot2 protocol support for relocatable images


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

[Xen-devel] [PATCH v11 05/13] efi: build xen.gz with EFI code

[Daniel Kiper]

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
---
v6 - suggestions/fixes:
   - improve efi_enabled() checks in efi_runtime_call()
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - properly calculate efi symbol address in
 xen/arch/x86/xen.lds.S (I hope that this
 change does not invalidate Jan's ACK).

v4 - suggestions/fixes:
   - functions should return -ENOSYS instead
 of -EOPNOTSUPP if EFI runtime services
 are not available
 (suggested by Jan Beulich),
   - remove stale bits from xen/arch/x86/Makefile
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 xen/arch/x86/efi/Makefile |   12 
 xen/arch/x86/xen.lds.S|4 ++--
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |9 +
 5 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index e40897f..2a0781a 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -219,6 +219,6 @@ efi/mkreloc: efi/mkreloc.c
 clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
+   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..442f3fc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,14 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
 
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
 nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7676de9..b0b1c9b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,10 +270,10 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
+  efi = DEFINED(efi) ? efi : .;
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 56544dc..1ef5d0b 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1251,6 +1251,9 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+if ( !efi_enabled(EFI_BOOT) )
+return;
+
 printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
 for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c
index 8c44835..25323de 100644
--- 

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

[osstest service owner]

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

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  503148ae5a6d22ba9e63517bade5f0f680a8f47b
baseline version:
 xen  cc50fa3051947e1b72f87f22767886a7904761fe

Last test of basis   102948  2016-12-05 15:01:20 Z0 days
Testing same since   102959  2016-12-05 18:01:55 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Tim Deegan 

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=503148ae5a6d22ba9e63517bade5f0f680a8f47b
+ . ./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 
503148ae5a6d22ba9e63517bade5f0f680a8f47b
+ branch=xen-unstable-smoke
+ revision=503148ae5a6d22ba9e63517bade5f0f680a8f47b
+ . ./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.8-testing
+ '[' x503148ae5a6d22ba9e63517bade5f0f680a8f47b = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ 

[Xen-devel] [PATCH v3 1/4] x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

[Andy Lutomirski]

We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong.  For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.

Reported-by: One Thousand Gnomes 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/processor.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 984a7bf17f6a..64fbc937d586 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -595,7 +595,7 @@ static inline void sync_core(void)
 {
int tmp;
 
-#ifdef CONFIG_M486
+#ifdef CONFIG_X86_32
/*
 * Do a CPUID if available, otherwise do a jump.  The jump
 * can conveniently enough be the jump around CPUID.
-- 
2.9.3


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

[Xen-devel] [PATCH v3 0/4] CPUID-less CPU/sync_core fixes and improvements

[Andy Lutomirski]

*** PATCHES 1 and 2 MAY BE 4.9 MATERIAL ***

Alan Cox pointed out that the 486 isn't the only supported CPU that
doesn't have CPUID.  Let's clean up the mess and make everything
faster while we're at it.

Patch 1 is intended to be an easy fix: it makes sync_core() work
without CPUID on all 32-bit kernels.  It should be quite safe.  This
will have a negligible performance cost during boot on kernels built
for newer CPUs.  With this in place, patch 2 reverts the buggy 486
check I added.

Patches 3-4 are meant to improve the situation.  Patch 3 cleans up
the Intel microcode loader and the patch 4 (which depends on patch 3
to work correctly) stops using CPUID in sync_core() altogether.

Changes from v2:
 - Switch to IRET-to-self and get rid of all the paravirt code.
 - Further immprove the sync_core() comment.

Changes from v1:
 - Fix Xen
 - Add timing info to the changelog (hint: 2x speedup)
 - Document patch 1 a bit better.

Andy Lutomirski (4):
  x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit
kernels
  Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"
  x86/microcode/intel: Replace sync_core() with native_cpuid()
  x86/asm: Rewrite sync_core() to use IRET-to-self

 arch/x86/boot/cpu.c   |  6 ---
 arch/x86/include/asm/processor.h  | 77 +--
 arch/x86/kernel/cpu/microcode/intel.c | 26 ++--
 3 files changed, 78 insertions(+), 31 deletions(-)

-- 
2.9.3


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

[Xen-devel] [PATCH v3 3/4] x86/microcode/intel: Replace sync_core() with native_cpuid()

[Andy Lutomirski]

The Intel microcode driver is using sync_core() to mean "do CPUID
with EAX=1".  I want to rework sync_core(), but first the Intel
microcode driver needs to stop depending on its current behavior.

Reported-by: Henrique de Moraes Holschuh 
Acked-by: Borislav Petkov 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/cpu/microcode/intel.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/intel.c 
b/arch/x86/kernel/cpu/microcode/intel.c
index cdc0deab00c9..e0981bb2a351 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -356,6 +356,26 @@ get_matching_model_microcode(unsigned long start, void 
*data, size_t size,
return state;
 }
 
+static void cpuid_1(void)
+{
+   /*
+* According to the Intel SDM, Volume 3, 9.11.7:
+*
+*   CPUID returns a value in a model specific register in
+*   addition to its usual register return values. The
+*   semantics of CPUID cause it to deposit an update ID value
+*   in the 64-bit model-specific register at address 08BH
+*   (IA32_BIOS_SIGN_ID). If no update is present in the
+*   processor, the value in the MSR remains unmodified.
+*
+* Use native_cpuid -- this code runs very early and we don't
+* want to mess with paravirt.
+*/
+   unsigned int eax = 1, ebx, ecx = 0, edx;
+
+   native_cpuid(, , , );
+}
+
 static int collect_cpu_info_early(struct ucode_cpu_info *uci)
 {
unsigned int val[2];
@@ -385,7 +405,7 @@ static int collect_cpu_info_early(struct ucode_cpu_info 
*uci)
native_wrmsrl(MSR_IA32_UCODE_REV, 0);
 
/* As documented in the SDM: Do a CPUID 1 here */
-   sync_core();
+   cpuid_1();
 
/* get the current revision from MSR 0x8B */
native_rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
@@ -627,7 +647,7 @@ static int apply_microcode_early(struct ucode_cpu_info 
*uci, bool early)
native_wrmsrl(MSR_IA32_UCODE_REV, 0);
 
/* As documented in the SDM: Do a CPUID 1 here */
-   sync_core();
+   cpuid_1();
 
/* get the current revision from MSR 0x8B */
native_rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
@@ -927,7 +947,7 @@ static int apply_microcode_intel(int cpu)
wrmsrl(MSR_IA32_UCODE_REV, 0);
 
/* As documented in the SDM: Do a CPUID 1 here */
-   sync_core();
+   cpuid_1();
 
/* get the current revision from MSR 0x8B */
rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
-- 
2.9.3


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

[Xen-devel] [PATCH v3 4/4] x86/asm: Rewrite sync_core() to use IRET-to-self

[Andy Lutomirski]

Aside from being excessively slow, CPUID is problematic: Linux runs
on a handful of CPUs that don't have CPUID.  Use IRET-to-self
instead.  IRET-to-self works everywhere, so it makes testing easy.

For reference, On my laptop, IRET-to-self is ~110ns,
CPUID(eax=1, ecx=0) is ~83ns on native and very very slow under KVM,
and MOV-to-CR2 is ~42ns.

While we're at it: sync_core() serves a very specific purpose.
Document it.

Cc: "H. Peter Anvin" 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/processor.h | 77 
 1 file changed, 55 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 64fbc937d586..201a956e345f 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -590,33 +590,66 @@ static __always_inline void cpu_relax(void)
 
 #define cpu_relax_lowlatency() cpu_relax()
 
-/* Stop speculative execution and prefetching of modified code. */
+/*
+ * This function forces the icache and prefetched instruction stream to
+ * catch up with reality in two very specific cases:
+ *
+ *  a) Text was modified using one virtual address and is about to be executed
+ * from the same physical page at a different virtual address.
+ *
+ *  b) Text was modified on a different CPU, may subsequently be
+ * executed on this CPU, and you want to make sure the new version
+ * gets executed.  This generally means you're calling this in a IPI.
+ *
+ * If you're calling this for a different reason, you're probably doing
+ * it wrong.
+ */
 static inline void sync_core(void)
 {
-   int tmp;
-
-#ifdef CONFIG_X86_32
/*
-* Do a CPUID if available, otherwise do a jump.  The jump
-* can conveniently enough be the jump around CPUID.
+* There are quite a few ways to do this.  IRET-to-self is nice
+* because it works on every CPU, at any CPL (so it's compatible
+* with paravirtualization), and it never exits to a hypervisor.
+* The only down sides are that it's a bit slow (it seems to be
+* a bit more than 2x slower than the fastest options) and that
+* it unmasks NMIs.  The "push %cs" is needed because, in
+* paravirtual environments, __KERNEL_CS may not be a valid CS
+* value when we do IRET directly.
+*
+* In case NMI unmasking or performance every becomes a problem,
+* the next best option appears to be MOV-to-CR2 and an
+* unconditional jump.  That sequence also works on all CPUs,
+* but it will fault at CPL3.
+*
+* CPUID is the conventional way, but it's nasty: it doesn't
+* exist on some 486-like CPUs, and it usually exits to a
+* hypervisor.
 */
-   asm volatile("cmpl %2,%1\n\t"
-"jl 1f\n\t"
-"cpuid\n"
-"1:"
-: "=a" (tmp)
-: "rm" (boot_cpu_data.cpuid_level), "ri" (0), "0" (1)
-: "ebx", "ecx", "edx", "memory");
+   register void *__sp asm(_ASM_SP);
+
+#ifdef CONFIG_X86_32
+   asm volatile (
+   "pushfl\n\t"
+   "pushl %%cs\n\t"
+   "pushl $1f\n\t"
+   "iret\n\t"
+   "1:"
+   : "+r" (__sp) : : "cc", "memory");
 #else
-   /*
-* CPUID is a barrier to speculative execution.
-* Prefetched instructions are automatically
-* invalidated when modified.
-*/
-   asm volatile("cpuid"
-: "=a" (tmp)
-: "0" (1)
-: "ebx", "ecx", "edx", "memory");
+   unsigned long tmp;
+
+   asm volatile (
+   "movq %%ss, %0\n\t"
+   "pushq %0\n\t"
+   "pushq %%rsp\n\t"
+   "addq $8, (%%rsp)\n\t"
+   "pushfq\n\t"
+   "movq %%cs, %0\n\t"
+   "pushq %0\n\t"
+   "pushq $1f\n\t"
+   "iretq\n\t"
+   "1:"
+   : "=r" (tmp), "+r" (__sp) : : "cc", "memory");
 #endif
 }
 
-- 
2.9.3


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

[Xen-devel] [PATCH v3 2/4] Revert "x86/boot: Fail the boot if !M486 and CPUID is missing"

[Andy Lutomirski]

This reverts commit ed68d7e9b9cfb64f3045ffbcb108df03c09a0f98.

The patch wasn't quite correct -- there are non-Intel (and hence
non-486) CPUs that we support that don't have CPUID.  Since we no
longer require CPUID for sync_core(), just revert the patch.

I think the relevant CPUs are Geode and Elan, but I'm not sure.

In principle, we should try to do better at identifying CPUID-less
CPUs in early boot, but that's more complicated.

Reported-by: One Thousand Gnomes 
Cc: Matthew Whitehead 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Andy Lutomirski 
---
 arch/x86/boot/cpu.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
index 4224ede43b4e..26240dde081e 100644
--- a/arch/x86/boot/cpu.c
+++ b/arch/x86/boot/cpu.c
@@ -87,12 +87,6 @@ int validate_cpu(void)
return -1;
}
 
-   if (CONFIG_X86_MINIMUM_CPU_FAMILY <= 4 && !IS_ENABLED(CONFIG_M486) &&
-   !has_eflag(X86_EFLAGS_ID)) {
-   printf("This kernel requires a CPU with the CPUID instruction.  
Build with CONFIG_M486=y to run on this CPU.\n");
-   return -1;
-   }
-
if (err_flags) {
puts("This kernel requires the following features "
 "not present on the CPU:\n");
-- 
2.9.3


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

Re: [Xen-devel] [PATCH v2 3/4] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

[Boris Ostrovsky]

On 12/05/2016 01:24 PM, Andrew Cooper wrote:
> This reduces the net complexity of CPUID handling by having all adjustments in
> at the same place.  Remove the now-unused hvm_funcs.cpuid_intercept
> infrastructure.
>
> The SYSCALL feature hiding is tweaked when moved.  In principle, an
> administrator can choose to explicitly hide the SYSCALL feature from the
> guest, as it has a separate feature bit.  If this is the case, the feature
> shouldn't be set behind the back of the administrators wishes.  (Not that many
> 64bit OSes would function in this scenario.)  In reality, SYSCALL will always
> be set in edx at this point.
>
> Signed-off-by: Andrew Cooper 
>


Reviewed-by:  Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH v2 2/4] x86/vpmu: Remove core2_no_vpmu_ops

[Boris Ostrovsky]

On 12/05/2016 01:24 PM, Andrew Cooper wrote:
> core2_no_vpmu_ops exists solely to work around the default-leaking of 
> CPUID/MSR
> values in Xen.
>
> With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
> remaining hook.  Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu
> intel: Add cpuid handling when vpmu disabled", a lot of work has been done and
> the nop path in vpmu_do_msr() now suffices.
>
> vpmu_do_msr() also falls into the nop path for un-configured or unprivileged
> domains, which enables the removal the duplicate logic in priv_op_read_msr().
>
> Finally, make all arch_vpmu_ops structures const as they are never modified,
> and make them static as they are not referred to externally.
>
> Signed-off-by: Andrew Cooper 
> Acked-by: Kevin Tian 

Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH v2 1/4] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

[Boris Ostrovsky]

On 12/05/2016 01:24 PM, Andrew Cooper wrote:
> @@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
> unsigned int *ebx,
>  if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
>  *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
>  }
> +
> +if ( vpmu_enabled(v) &&
> + vpmu_is_set(vcpu_vpmu(v), VPMU_CPU_HAS_DS) )
> +{
> +*edx |= cpufeat_mask(X86_FEATURE_DS);
> +if ( cpu_has(_cpu_data, X86_FEATURE_DTES64) )
> +*ecx |= cpufeat_mask(X86_FEATURE_DTES64);
> +if ( cpu_has(_cpu_data, X86_FEATURE_DSCPL) )
> +*ecx |= cpufeat_mask(X86_FEATURE_DSCPL);
> +}
> +
>  break;
>  
>  case 0x7:
> @@ -3646,6 +3657,18 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
> unsigned int *ebx,
>  }
>  break;
>  
> +case 0x000a: /* Architectural Performance Monitor Features (Intel) */
> +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || 
> !vpmu_enabled(v) )
> +{
> +*eax = *ebx = *ecx = *edx = 0;
> +break;
> +}
> +
> +/* Report at most version 3 since that's all we currently emulate */
> +if ( (*eax & 0xff) > 3 )
> +*eax = (*eax & ~0xff) | 3;
> +break;


Both this and Debug Store checks are the same for both HVM and PV. Can
they be factored out? (and then perhaps version update can gain back
PMU_VERSION_MASK macro)

-boris


> @@ -1192,6 +1192,16 @@ void pv_cpuid(struct cpu_user_regs *regs)
>  }
>  }
>  
> +if ( vpmu_enabled(curr) &&
> + vpmu_is_set(vcpu_vpmu(curr), VPMU_CPU_HAS_DS) )
> +{
> +d |= cpufeat_mask(X86_FEATURE_DS);
> +if ( cpu_has(_cpu_data, X86_FEATURE_DTES64) )
> +c |= cpufeat_mask(X86_FEATURE_DTES64);
> +if ( cpu_has(_cpu_data, X86_FEATURE_DSCPL) )
> +c |= cpufeat_mask(X86_FEATURE_DSCPL);
> +}
> +
>  c |= cpufeat_mask(X86_FEATURE_HYPERVISOR);
>  break;
>  
> @@ -1224,6 +1234,16 @@ void pv_cpuid(struct cpu_user_regs *regs)
>  a = 0;
>  break;
>  
> +case 0x000a: /* Architectural Performance Monitor Features (Intel) */
> +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
> + !vpmu_enabled(curr) )
> +goto unsupported;
> +
> +/* Report at most version 3 since that's all we currently emulate. */
> +if ( (a & 0xff) > 3 )
> +a = (a & ~0xff) | 3;
> +break;
> +
>



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

Re: [Xen-devel] [PATCH] xen-scsifront: Add a missing call to kfree

[Dan Carpenter]

On Mon, Nov 21, 2016 at 07:01:36AM +0100, Juergen Gross wrote:
> On 19/11/16 19:22, Quentin Lambert wrote:
> > Most error branches following the call to kmalloc contain
> > a call to kfree. This patch add these calls where they are
> > missing.
> > 
> > This issue was found with Hector.
> > 
> > Signed-off-by: Quentin Lambert 
> 
> Nice catch. I think this will need some more work, I'll do a
> follow-on patch.
> 

The error handling is really weird.  Could you send your follow on to
this thread?

regards,
dan carpenter


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

[Xen-devel] Test Xen 4.8 RC8 stable 05.12.16

[Juergen Schinker]

* Hardware:
 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz
 Sandisk SSD 1T
 32G Ram

Linux xen 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux


* Software:

Debian Stretch/testing is dom0
 
* Guest operating systems:

Guests Ubuntu 14.04 LTS Debian Stretch/Sid 

Ubuntu 16.10 yakity yak with latest 4.8 kernel works 
 
* Functionality tested:
xl 
creating booting 
pygrub
credit2

* Comments:

 host   : xen
release: 4.8.0-1-amd64
version: #1 SMP Debian 4.8.7-1 (2016-11-13)
machine: x86_64
nr_cpus: 4
max_cpu_id : 3
nr_nodes   : 1
cores_per_socket   : 2
threads_per_core   : 2
cpu_mhz: 2312
hw_caps: 
b7ebfbff:77bae3ff:28100800:0001:0001:0281::0100
virt_caps  : hvm hvm_directio
total_memory   : 32711
free_memory: 4031
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 8
xen_extra  : .0-rc
xen_version: 4.8.0-rc
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler  : credit2
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Tue Nov 29 18:05:48 2016 + git:a7a578c-dirty
xen_commandline: placeholder sched=credit2 iommu=1 loglvl=all 
guest_loglvl=all com1=115200,8n1,0x3e8,5 console=com1,vga
cc_compiler: gcc (Debian 6.2.0-13) 6.2.0 20161109
cc_compile_by  : root
cc_compile_domain  : 
cc_compile_date: Fri Dec  2 12:22:34 GMT 2016
build_id   : ba3cdea27d859c8a8826680d161a42f4f9fed456
xend_config_format : 4

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

Re: [Xen-devel] Please Welcome Our New Release Manager

[Konrad Rzeszutek Wilk]

On Mon, Dec 05, 2016 at 12:36:46PM -0800, Stefano Stabellini wrote:
> On Mon, 5 Dec 2016, Wei Liu wrote:
> > Dear community members,
> > 
> > I'm pleased to announce that Julien Grall  will be
> > the Release Manager for the next Xen release.
> > 
> > The appointment was voted by the Committers and the vote passed.
> > 
> > Julien has done excellent jobs in many aspects. He has been an active
> > developer for the past few years and contributed a lot of code for Xen
> > on ARM. He has been doing a good job in co-maintaining Xen on ARM with
> > Stefano Stabellini. Particularly in 4.8 release, he showed his ability
> > to make balanced decisions and influence other contributors to move
> > various projects forward. He also expressed desire to work with greater
> > Xen community and make bigger impact.
> > 
> > All in all, we believe Julien will do a good job in managing the next
> > release. Thanks Julien for stepping up.
> 
> Congratulations!

Indeed! Congratulations and also I would like to thank Wei Liu for doing
an fantastic job on the the last releases!

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

Re: [Xen-devel] Please Welcome Our New Release Manager

[Stefano Stabellini]

On Mon, 5 Dec 2016, Wei Liu wrote:
> Dear community members,
> 
> I'm pleased to announce that Julien Grall  will be
> the Release Manager for the next Xen release.
> 
> The appointment was voted by the Committers and the vote passed.
> 
> Julien has done excellent jobs in many aspects. He has been an active
> developer for the past few years and contributed a lot of code for Xen
> on ARM. He has been doing a good job in co-maintaining Xen on ARM with
> Stefano Stabellini. Particularly in 4.8 release, he showed his ability
> to make balanced decisions and influence other contributors to move
> various projects forward. He also expressed desire to work with greater
> Xen community and make bigger impact.
> 
> All in all, we believe Julien will do a good job in managing the next
> release. Thanks Julien for stepping up.

Congratulations!

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

Re: [Xen-devel] [PATCH] xen/arm: traps: Emulate ICC_SRE_EL1 as RAZ/WI

[Stefano Stabellini]

On Mon, 5 Dec 2016, Julien Grall wrote:
> Recent Linux kernel (4.4 and onwards [1]) is checking whether it is possible
> to enable sysreg access (ICC_SRE_EL1.SRE) when the ID register
> (ID_AA64PRF0_EL1.GIC) is reporting the presence of the sysreg interface.
> 
> When the guest has been configured to use GICv2, the hypervisor will
> disable sysreg access for this vm (via ICC_SRE_EL2.Enable) and therefore
> access to system register such as ICC_SRE_EL1 are trapped in EL2.
> 
> However, ICC_SRE_EL1 is not emulated by the hypervisor. This means that
> Linux will crash as soon as it is trying to access ICC_SRE_EL1.
> 
> To solve this problem, Xen can implement ICC_SRE_EL1 as read-as-zero
> write-ignore. The emulation will only be used when sysreg are disabled
> for EL1.
> 
> [1]  963fcd409 "arm64: cpufeatures: Check ICC_EL1_SRE.SRE before
> enabling ARM64_HAS_SYSREG_GIC_CPUIF"
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

And applied


> ---
> I think this patch would need to be backported as recent Linux (4.4
> and onwards) are trying to access ICC_EL1_SRE during boot time.
> 
> The first support of GICv2 on GICv3 was in Xen 4.6.
> ---
>  xen/arch/arm/traps.c  | 14 ++
>  xen/include/asm-arm/sysregs.h |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 8ff73fe..ae921d7 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2280,6 +2280,20 @@ static void do_sysreg(struct cpu_user_regs *regs,
>  return inject_undef64_exception(regs, hsr.len);
>  
>  /*
> + *  ICC_SRE_EL2.Enable = 0
> + *
> + *  GIC Architecture Specification (IHI 0069C): Section 8.1.9
> + */
> +case HSR_SYSREG_ICC_SRE_EL1:
> +/*
> + * Trapped when the guest is using GICv2 whilst the platform
> + * interrupt controller is GICv3. In this case, the register
> + * should be emulate as RAZ/WI to tell the guest to use the GIC
> + * memory mapped interface (i.e GICv2 compatibility).
> + */
> +return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> +
> +/*
>   * HCR_EL2.TIDCP
>   *
>   * ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
> diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/sysregs.h
> index 570f43e..887368e 100644
> --- a/xen/include/asm-arm/sysregs.h
> +++ b/xen/include/asm-arm/sysregs.h
> @@ -90,6 +90,7 @@
>  #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
>  #define HSR_SYSREG_ICC_ASGI1R_EL1 HSR_SYSREG(3,1,c12,c11,6)
>  #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
> +#define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
>  #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
>  
>  #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] Xen ARM small task (WAS: Re: [Xen Question])

[Stefano Stabellini]

On Mon, 5 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 01/12/16 21:33, Stefano Stabellini wrote:
> > On Thu, 1 Dec 2016, Julien Grall wrote:
> > > On 01/12/16 02:07, Stefano Stabellini wrote:
> > > > On Fri, 25 Nov 2016, Julien Grall wrote:
> > > > > Hi Stefano,
> > > 
> > > Hi,
> > > 
> > > > > On 23/11/16 19:55, Stefano Stabellini wrote:
> > > > > > Actually I am thinking that the default values should be in the
> > > > > > emulators themselves. After all they are the part of the code that
> > > > > > knows
> > > > > > more about vuarts.
> > > > > 
> > > > > Can you expand what you mean by emulator? I was never expecting to
> > > > > have a
> > > > > fully emulated UART exposed to the guest (i.e read/write character
> > > > > support)
> > > > > except for a PL011.
> > > > 
> > > > Once we start having emulators, it is possible that we'll end up with
> > > > more than one. For example, we introduce the PL011 now, then in a couple
> > > > of years somebody wants to add ns16550 because it is the only one that
> > > > Windows 2019 supports. I am assuming that one way or another they'll run
> > > > in a low privilege mode (see other recent threads).
> > > 
> > > Well, if this Windows is meant to run on SBSA complaint server, it will
> > > have
> > > to support either PL011 or SBSA (a subset of PL011).
> > 
> > I am not thinking about SBSA compliant OSes, that is the easy case :-)
> > > If we are going to allow more kind of UART? Why don't we have a disk
> > > emulator
> > > in Xen? How about a network emulator? Overall Windows 2019 may not have PV
> > > drivers for the network and disk.
> > > 
> > > I really think we have to draw a line of what we are supporting. The PL011
> > > is
> > > mandatory by a specification. If the guest is not compliant then it will
> > > have
> > > to use either PV drivers or having a device assigned.
> > > 
> > > The addition of a new emulator in upstream would need to be justified. I
> > > don't
> > > want to end up bringing QEMU in Xen.
> > 
> > Nobody wants to bring QEMU into Xen. To be pedantic we would be
> > bringing QEMU into xen.git, not into "Xen", but we don't want that
> > either.
> > 
> > Of course, any addition would need to be well justified, but at the same
> > time, I don't think we can rule out any emulator a priori.  We'll have
> > to evaluate the issue on a case by case basis. As usual, it is going to
> > be a trade-off between complexity, maintainability and use cases that it
> > enables. Everybody dislike QEMU on Xen on x86, but it enabled Windows XP
> > virtual machines back in the day. I might disagree with the way it was
> > done, but I wonder what would be of the Xen Project today if those
> > emullators hadn't been added in 2005.
> > 
> > Of course the fewer emulators, the better. I wouldn't accept an IDE
> > emulator in Xen on ARM today for example. However sometimes they are
> > unavoidable, that's why it is important to provide a safe execution
> > environment for them (meaning: not in Xen at EL2).
> > 
> > Today it is pretty much the same thing to add an emulator in the
> > hypervisor or in QEMU on x86. Somebody has to maintain the code no
> > matter where it lives and provide security support for it. Every QEMU
> > vulnerability ends up becoming a Xen vulnerability. In all honesty, it
> > is better to introduce them in QEMU so that at least the few people that
> > use stubdoms are less affected. In the future it is going to be similar
> > to introduce new emulators in xen.git at EL0/1 or in QEMU running
> > unprivileged in Dom0. This is to say that having emulators out of Xen
> > (or out of xen.git) is not necessarily an improvement if they are still
> > able to do exactly the same things, such as mapping any random page in
> > memory.
> 
> We have to factor in our decision that QEMU is been used by many people, which
> mean the code should be more exercised. In the case of Xen, some emulator may
> be used by very few people (think about TEE or a specific UART).

That's true, although not all parts of QEMUs are used as much as others.
For example I am pretty sure there is no security support for ARM
platforms and devices in QEMU today.


> I would require more unit tests (maybe in XTF) when a new emulator is added.
> Allowing us to check if the emulator is still functional.

Definitely true. It would be nice to have fuzzy testing too.


> > > > > The current vuart (see xen/arch/arm/vuart.c) is very simple but
> > > > > require
> > > > > someone to configure it. For DOM0, this is configured by the serial
> > > > > driver.
> > > > > For guest we need someone doing the same.
> > > > 
> > > > I understand. For clarity, I'll call "PL011 emulator" the one that will
> > > > end up being used for DomUs, which might be based on, or different from,
> > > > xen/arch/arm/vuart.c. It doesn't exist yet.
> > > > 
> > > > The PL011 emulator should have default values for everything. Some of
> > > > these values could be configured by libxl, but none should 

[Xen-devel] [ovmf baseline-only test] 68162: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68162 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68162/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb
baseline version:
 ovmf 7bbe0b3eff9e7876808ce1b96b9a71360984cf91

Last test of basis68154  2016-12-04 02:17:11 Z1 days
Testing same since68162  2016-12-05 17:21:10 Z0 days1 attempts


People who touched revisions under test:
  Chen A Chen 

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.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.


commit 0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb
Author: Chen A Chen 
Date:   Tue Nov 22 16:16:02 2016 +0800

ShellPkg/MV: Fix MV to deny moving parent of current directory

When user types "mv -r fs0:\A\ fs1:\" under directory
"fs0:\A\B\", MV command should deny such movement.

The patch fixes the above issue.
It also denies moving current directory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen 
Reviewed-by: Jaben Carsey 
Reviewed-by: Ruiyu Ni 

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

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Stefano Stabellini]

On Mon, 5 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 03/12/16 00:46, Stefano Stabellini wrote:
> > On Fri, 2 Dec 2016, Andre Przywara wrote:
> > > > When we receive the maintenance interrupt and we clear the LR of the
> > > > vLPI, Xen should re-enable the pLPI.
> > > > Given that the state of the LRs is sync'ed before calling gic_interrupt,
> > > > we can be sure to know exactly in what state the vLPI is at any given
> > > > time. But for this to work correctly, it is important to configure the
> > > > pLPI to be delivered to the same pCPU running the vCPU which handles
> > > > the vLPI (as it is already the case today for SPIs).
> > > 
> > > Why would that be necessary?
> > 
> > Because the state of the LRs of other pCPUs won't be up to date: we
> > wouldn't know for sure whether the guest EOI'ed the vLPI or not.
> 
> Well, there is still a small window when the interrupt may be received on the
> previous pCPU. So we have to take into account this case.

That's right. We already have a mechanism to deal with that, based on
the GIC_IRQ_GUEST_MIGRATING flag. It should work with LPIs too.


> This window may be bigger with LPIs, because a single vCPU may have thousand
> interrupts routed. This would take a long time to move all of them when the
> vCPU is migrating. So we may want to take a lazy approach and moving them when
> they are received on the "wrong" pCPU.

That's possible. The only downside is that modifying the irq migration
workflow is difficult and we might want to avoid it if possible.

Another approach is to let the scheduler know that migration is slower.
In fact this is not a new problem: it can be slow to migrate interrupts,
even few non-LPIs interrupts, even on x86. I wonder if the Xen scheduler
has any knowledge of that (CC'ing George and Dario). I guess that's the
reason why most people run with dom0_vcpus_pin.

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

[Xen-devel] [PATCH v2] AMD IOMMU: Support IOAPIC IDs larger than 128

[Suravee Suthikulpanit]

Currently, the driver uses the APIC ID to index into the ioapic_sbdf array.
The current MAX_IO_APICS is 128, which causes the driver initialization
to fail on the system with IOAPIC ID >= 128.

Instead, this patch adds APIC ID in the struct ioapic_sbdf,
which is used to match the entry when searching through the array.

Also, this patch removes the use of ioapic_cmdline bit-map, which is
used to track the ivrs_ioapic options via command line.
Instead, it introduces the cmdline flag in the struct ioapic_sbdf,
to identify if the entry is created during ivrs_ioapic command-line parsing.

Signed-off-by: Suravee Suthikulpanit 
Cc: Jan Beulich 
Cc: Boris Ostrovsky 
---
Changes in V2:
* Fix logic error pointed out by Jan in parse_ivrs_ioapic(),
  parse_ivhd_device_special(), parse_ivrs_table(), parse_ivrs_table().
* Use unsigned int for array index variable.
* Minor clean ups.

 xen/drivers/passthrough/amd/iommu_acpi.c  | 102 +++---
 xen/drivers/passthrough/amd/iommu_intr.c  |  64 +---
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |   6 ++
 3 files changed, 118 insertions(+), 54 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c 
b/xen/drivers/passthrough/amd/iommu_acpi.c
index b92c8ad..ac902ac 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -633,26 +633,37 @@ static u16 __init parse_ivhd_device_extended_range(
 return dev_length;
 }
 
-static DECLARE_BITMAP(ioapic_cmdline, ARRAY_SIZE(ioapic_sbdf)) __initdata;
-
 static void __init parse_ivrs_ioapic(char *str)
 {
 const char *s = str;
 unsigned long id;
 unsigned int seg, bus, dev, func;
+unsigned int idx;
 
 ASSERT(*s == '[');
 id = simple_strtoul(s + 1, , 0);
-if ( id >= ARRAY_SIZE(ioapic_sbdf) || *s != ']' || *++s != '=' )
+if ( *s != ']' || *++s != '=' )
 return;
 
 s = parse_pci(s + 1, , , , );
 if ( !s || *s )
 return;
 
-ioapic_sbdf[id].bdf = PCI_BDF(bus, dev, func);
-ioapic_sbdf[id].seg = seg;
-__set_bit(id, ioapic_cmdline);
+idx = ioapic_id_to_index(id);
+if ( idx == MAX_IO_APICS )
+{
+idx = get_next_ioapic_sbdf_index();
+if ( idx == MAX_IO_APICS )
+{
+printk(XENLOG_ERR "Error: %s: Too many IO APICs.\n", __func__);
+return;
+}
+}
+
+ioapic_sbdf[idx].bdf = PCI_BDF(bus, dev, func);
+ioapic_sbdf[idx].seg = seg;
+ioapic_sbdf[idx].id = id;
+ioapic_sbdf[idx].cmdline = true;
 }
 custom_param("ivrs_ioapic[", parse_ivrs_ioapic);
 
@@ -683,7 +694,7 @@ static u16 __init parse_ivhd_device_special(
 u16 header_length, u16 block_length, struct amd_iommu *iommu)
 {
 u16 dev_length, bdf;
-int apic;
+unsigned int apic, idx;
 
 dev_length = sizeof(*special);
 if ( header_length < (block_length + dev_length) )
@@ -714,21 +725,19 @@ static u16 __init parse_ivhd_device_special(
  * consistency here --- whether entry's IOAPIC ID is valid and
  * whether there are conflicting/duplicated entries.
  */
-apic = find_first_bit(ioapic_cmdline, ARRAY_SIZE(ioapic_sbdf));
-while ( apic < ARRAY_SIZE(ioapic_sbdf) )
+for ( idx = 0; idx < nr_ioapic_sbdf; idx++ )
 {
-if ( ioapic_sbdf[apic].bdf == bdf &&
- ioapic_sbdf[apic].seg == seg )
+if ( ioapic_sbdf[idx].bdf == bdf &&
+ ioapic_sbdf[idx].seg == seg &&
+ ioapic_sbdf[idx].cmdline )
 break;
-apic = find_next_bit(ioapic_cmdline, ARRAY_SIZE(ioapic_sbdf),
- apic + 1);
 }
-if ( apic < ARRAY_SIZE(ioapic_sbdf) )
+if ( idx < nr_ioapic_sbdf )
 {
 AMD_IOMMU_DEBUG("IVHD: Command line override present for IO-APIC 
%#x"
 "(IVRS: %#x devID %04x:%02x:%02x.%u)\n",
-apic, special->handle, seg, PCI_BUS(bdf),
-PCI_SLOT(bdf), PCI_FUNC(bdf));
+ioapic_sbdf[idx].id, special->handle, seg,
+PCI_BUS(bdf), PCI_SLOT(bdf), PCI_FUNC(bdf));
 break;
 }
 
@@ -737,20 +746,14 @@ static u16 __init parse_ivhd_device_special(
 if ( IO_APIC_ID(apic) != special->handle )
 continue;
 
-if ( special->handle >= ARRAY_SIZE(ioapic_sbdf) )
-{
-printk(XENLOG_ERR "IVHD Error: IO-APIC %#x entry beyond 
bounds\n",
-   special->handle);
-return 0;
-}
-
-if ( test_bit(special->handle, ioapic_cmdline) )
+idx = ioapic_id_to_index(special->handle);
+if ( idx != MAX_IO_APICS && ioapic_sbdf[idx].cmdline )
 AMD_IOMMU_DEBUG("IVHD: Command line override present 

[Xen-devel] [xen-unstable-smoke test] 102959: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 broken
 test-amd64-amd64-libvirt  broken
 build-amd64-libvirt   broken

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  503148ae5a6d22ba9e63517bade5f0f680a8f47b
baseline version:
 xen  cc50fa3051947e1b72f87f22767886a7904761fe

Last test of basis   102948  2016-12-05 15:01:20 Z0 days
Testing same since   102959  2016-12-05 18:01:55 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Tim Deegan 

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



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

broken-job test-amd64-amd64-xl-qemuu-debianhvm-i386 broken
broken-job test-amd64-amd64-libvirt broken
broken-job build-amd64-libvirt broken

Not pushing.


commit 503148ae5a6d22ba9e63517bade5f0f680a8f47b
Author: Andrew Cooper 
Date:   Wed Nov 2 15:50:23 2016 +

x86/emul: Drop the last remaining uses of bool_t

And drop the compatibility typedef from the userspace harness

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit a6c406c1f4a17ef30009090a45470f20f75addde
Author: Andrew Cooper 
Date:   Fri Dec 2 13:18:38 2016 +

x86/hvm: Assert some expectations in hvm_inject_event()

Check that event->error_code is appropriate for the type/vector combination.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit c31f3be9b40d5d4703674b35081cfcbabd4ad8bb
Author: Andrew Cooper 
Date:   Tue Oct 25 19:41:01 2016 +0100

x86/emul: Debugging improvements to the test harness

Disable stdout buffering, so logging gets out even if the harness crashes.
Add a verbose option (compile time disabled) which dumps all read/write 
calls
the harness makes

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 

commit 750c5f714b80bf467ccd2af86b7f6ff8d6e578b9
Author: Andrew Cooper 
Date:   Fri Dec 2 18:23:02 2016 +

x86/shadow: Drop stale adjustment in the PAE second-half search

This shouldn't have been present in c/s 29a57c992 "x86/emul: Rework emulator
event injection".  It was a leftover from a previous version of the series.

This conditional has no effect on the behaviour following it, as both
X86EMUL_EXCEPTION and X86EMUL_UNHANDLEABLE fall into the same "return back 
to
guest" path.

Signed-off-by: Andrew Cooper 
Acked-by: Tim Deegan 

commit fb06017f807d45f43b86be33311694c6665ac182
Author: Andrew Cooper 
Date:   Tue May 24 11:56:58 2016 +0100

x86/pagewalk: Improve print_gw()

print_gw() has no callers, meaning that it only gets used as part of manual
debugging.  As such, the FILE/LINE references are of no practical use, and
voluminous in the log.  Additionally, the function becoming empty in a
non-debug build is unhelpful.  Switch from gdprintk() to gprintk().

Print the entry and mfn for a specific level on the same line.  This halves
the number of lines printed overall.  There needs to be a small adjustment 
to
the #ifdef'ary to maintain the proper l3e behaviour for 3-level paging, 
where

Re: [Xen-devel] Possible improvement to Xen Security Response Process

[Stefano Stabellini]

On Mon, 5 Dec 2016, Jan Beulich wrote:
> >>> On 05.12.16 at 15:17,  wrote:
> > From a security purist point of view, any delay in publication could 
> > increase the possibility of vulnerabilities being exploited in the
> > wild.  However, given the significant frequency of publication of XSAs,
> > I’d suggest that users failing to keep up with the publication rate
> > is presently a much greater security risk.
> > 
> > If XSAs were to be batched, we should also consider if batch updates 
> > should be encouraged to be on pre-defined dates.  The present
> > unpredictability makes it unnecessarily more difficult for users of
> > Xen to plan their lives.  For example, our present process causes 
> > organisations with few administrators to choose between cancelling
> > holidays or not patching.
> > 
> > Obviously, some issues are discussed in public before the security 
> > impact is realised (such as XSA-201); equally, the right to set 
> > a disclosure date (if any) rests with the discoverer.  However,
> > my experience of other software (which may not be typical) has been
> > that discoverers are usually happy to go along with any reasonable
> > proposed date given in the same way that discoverers of XSAs are
> > usually happy to conform to our present policy.
> > 
> > If this seems a good idea, then I’ll post a concrete proposal but 
> > I’d like to get general feedback first.
> 
> I think very much here depends on the concrete aspects of the
> proposal (timing, room for exceptions, etc). From just a general
> pov, I can see advantages and disadvantages to both, just like
> you've indicated yourself already. Also it shouldn't be left out of
> consideration that for less severe vulnerabilities consuming
> parties could decide for themselves whether to delay patching
> (and hence leverage batching); I'm not convinced it would be a
> good idea to require the XenProject Security Team to take this
> decision in all cases.

Given that the disclosure date is always chosen by the discoverer, the
only thing the security team can do is to suggest. It could make sense
to have a policy to pick the date the team should propose to the
discoverer, but at the end of the day, it is always, entirely, up to
her.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] Travis-ci: specify KCONFIG_ALLCONFIG for randconfig

[Doug Goldstein]

On 12/5/16 10:45 AM, Wei Liu wrote:
> The file provided contains symbols that must be set to certain values.
> This then prevents random build breakage in travis due to
> known-incompatible symbol selections.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Doug Goldstein 
> ---
>  scripts/travis-build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/travis-build b/scripts/travis-build
> index 584d008..0cb15a8 100755
> --- a/scripts/travis-build
> +++ b/scripts/travis-build
> @@ -4,7 +4,7 @@ $CC --version
>  
>  # random config or default config
>  if [[ "${RANDCONFIG}" == "y" ]]; then
> -make -C xen randconfig
> +make -C xen KCONFIG_ALLCONFIG=tools/kconfig/allrandom.config randconfig
>  else
>  make -C xen defconfig
>  fi
> 

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

[Stefano Stabellini]

On Mon, 5 Dec 2016, Jan Beulich wrote:
> >>> On 05.12.16 at 14:59,  wrote:
> > On 05/12/16 13:50, Jan Beulich wrote:
> > On 05.12.16 at 14:43,  wrote:
> >>> On 05/12/16 12:28, Jan Beulich wrote:
> >>> On 05.12.16 at 12:25,  wrote:
> > On 05/12/16 11:18, Jan Beulich wrote:
> > On 05.12.16 at 11:05,  wrote:
> >>> --- a/xen/arch/x86/smpboot.c
> >>> +++ b/xen/arch/x86/smpboot.c
> >>> @@ -346,7 +346,6 @@ void start_secondary(void *unused)
> >>>  spin_debug_enable();
> >>>  set_cpu_sibling_map(cpu);
> >>>  notify_cpu_starting(cpu);
> >>> -wmb();
> >>>  
> >>>  /*
> >>>   * We need to hold vector_lock so there the set of online cpus
> >> Hmm, this one is indeed redundant with the lock_vector_lock()
> >> following right below, but if that lock wasn't there, I think it
> >> would be needed to order set_cpu_sibling_map() and the
> >> setting of the bit in the online map. So I think it would better
> >> stay (but be relaxed to smb_wmb()).
> > Why?  It doesn't relate to an smp_rmb() on any other CPU, and is
> > therefore wrong to use.
>  I think it does, just not with one that's spelled out as smp_rmb().
>  Instead __cpu_up() spins on !cpu_online(), using cpu_relax() as
>  a de-facto equivalent of smp_rmb().
> >>> __cpu_up() is ordered with the cpumask_set_cpu(cpu, _online_map)
> >>> between the two context hunks.
> >> Exactly - so here we need the write side to that
> > 
> > No, we don't.
> > 
> > cpumask_set_cpu(cpu, _online_map) is a write operation, so orders
> > properly on x86.  C's ordering properties ensure that the adjacent
> > function calls happen in program order.
> 
> Well, that then again falls into the category of barriers which
> would be needed in arch-independent code, but can be omitted
> in x86-specific sources. I think we should separate both classes
> when relaxing/eliminating them.

Yes. It would be nice to keep a barrier, one that #define to nothing if
it's unneeded, so that if somebody else on a different arch (*cough*
*cough*) ends up copying the code, it will know what to do.

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

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

[Stefano Stabellini]

On Mon, 5 Dec 2016, Andrew Cooper wrote:
> None of these barriers serve any purpose, as they are not synchronising with
> any anything on remote CPUs.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> 
> Restricting to just the $ARCH maintainers, as this is a project-wide sweep.
> 
> Julien/Stefano: I think the ARM smpboot inhereted the erronious barrier usage
> from x86, but I don't know whether further development has gained a dependence
> on them.

We turned them into smp_wmb already (kudos to IanC).


>  xen/arch/x86/acpi/cpu_idle.c  | 2 --
>  xen/arch/x86/cpu/mcheck/mce.c | 1 -
>  xen/arch/x86/crash.c  | 3 ---
>  xen/arch/x86/smpboot.c| 2 --
>  4 files changed, 8 deletions(-)
> 
> diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
> index f36b184..09c8848 100644
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -1331,8 +1331,6 @@ void cpuidle_disable_deep_cstate(void)
>  max_cstate = 1;
>  }
>  
> -mb();
> -
>  hpet_disable_legacy_broadcast();
>  }
>  
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> index 2695b0c..460e336 100644
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -86,7 +86,6 @@ static x86_mce_vector_t _machine_check_vector = 
> unexpected_machine_check;
>  void x86_mce_vector_register(x86_mce_vector_t hdlr)
>  {
>  _machine_check_vector = hdlr;
> -wmb();
>  }
>  
>  /* Call the installed machine check handler for this CPU setup. */
> diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c
> index f28f527..4cadb5e 100644
> --- a/xen/arch/x86/crash.c
> +++ b/xen/arch/x86/crash.c
> @@ -146,9 +146,6 @@ static void nmi_shootdown_cpus(void)
>  write_atomic((unsigned long *)__va(__pa(_table[TRAP_nmi])),
>   (unsigned long)_nmi_crash);
>  
> -/* Ensure the new callback function is set before sending out the NMI. */
> -wmb();
> -
>  smp_send_nmi_allbutself();
>  
>  msecs = 1000; /* Wait at most a second for the other cpus to stop */
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 3a9dd3e..0aa377a 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -346,7 +346,6 @@ void start_secondary(void *unused)
>  spin_debug_enable();
>  set_cpu_sibling_map(cpu);
>  notify_cpu_starting(cpu);
> -wmb();
>  
>  /*
>   * We need to hold vector_lock so there the set of online cpus
> @@ -364,7 +363,6 @@ void start_secondary(void *unused)
>  
>  microcode_resume_cpu(cpu);
>  
> -wmb();
>  startup_cpu_idle_loop();
>  }
>  
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH 1/4] xen/common: Replace incorrect mandatory barriers with SMP barriers

[Stefano Stabellini]

On Mon, 5 Dec 2016, Andrew Cooper wrote:
> Mandatory barriers are only for use with reduced-cacheability MMIO mappings.
> 
> All of these uses are just to deal with shared memory between multiple
> processors, so use the smp_*() which are the correct barriers for the purpose.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Stefano Stabellini 


> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> 
> Restricting to just the $ARCH maintainers, as this is a project-wide sweep
> ---
>  xen/common/grant_table.c | 2 +-
>  xen/common/time.c| 4 ++--
>  xen/common/vm_event.c| 6 +++---
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index e2c4097..a425a9e 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -993,7 +993,7 @@ __gnttab_map_grant_ref(
>  mt = _entry(lgt, handle);
>  mt->domid = op->dom;
>  mt->ref   = op->ref;
> -wmb();
> +smp_wmb();
>  write_atomic(>flags, op->flags);
>  
>  if ( need_iommu )
> diff --git a/xen/common/time.c b/xen/common/time.c
> index 721ada8..a7caea9 100644
> --- a/xen/common/time.c
> +++ b/xen/common/time.c
> @@ -103,7 +103,7 @@ void update_domain_wallclock_time(struct domain *d)
>  
>  wc_version = _info(d, wc_version);
>  *wc_version = version_update_begin(*wc_version);
> -wmb();
> +smp_wmb();
>  
>  sec = wc_sec + d->time_offset_seconds;
>  shared_info(d, wc_sec)= sec;
> @@ -117,7 +117,7 @@ void update_domain_wallclock_time(struct domain *d)
>  shared_info(d, wc_sec_hi) = sec >> 32;
>  #endif
>  
> -wmb();
> +smp_wmb();
>  *wc_version = version_update_end(*wc_version);
>  
>  spin_unlock(_lock);
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 907ab40..c6f7d32 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -31,9 +31,9 @@
>  #include 
>  
>  /* for public/io/ring.h macros */
> -#define xen_mb()   mb()
> -#define xen_rmb()  rmb()
> -#define xen_wmb()  wmb()
> +#define xen_mb()   smp_mb()
> +#define xen_rmb()  smp_rmb()
> +#define xen_wmb()  smp_wmb()
>  
>  #define vm_event_ring_lock_init(_ved)  spin_lock_init(&(_ved)->ring_lock)
>  #define vm_event_ring_lock(_ved)   spin_lock(&(_ved)->ring_lock)
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH v1] arm/irq: Reorder check when the IRQ is already used by someone

[Stefano Stabellini]

On Mon, 5 Dec 2016, Julien Grall wrote:
> Hi Oleksandr,
> 
> On 02/12/16 16:38, Oleksandr Tyshchenko wrote:
> > Call irq_get_domain for the IRQ we are interested in
> > only after making sure that it is the guest IRQ to avoid
> > ASSERT(test_bit(_IRQ_GUEST, >status)) triggering.
> > 
> > Signed-off-by: Oleksandr Tyshchenko 
> 
> I forgot to mention that your Signed-off-by does not match the From.
> In the future, please make sure that the author e-mail (the From) is listed in
> the signed-off.

CC'ing Lars.

Actually I don't think this is required: Signed-off-by is about
copyright ownership, that is where using the company email is important.
But I don't think it is necessary for the authorship, that is what From:
is about. Authorship is just to give credit to the author, it could be a
pseudonym, I think. I am pretty sure that I have seen other instances
of this on the LKML.

For example:

Alice works for Bob
Alice writes a patch, Bob has copyright ownership
Chris takes Alice's patch and sends it to xen-devel

Chris should use its own email address in the email From: field; he uses
Alice's email address (doesn't matter which) in the From: field within
the patch; he should use Bob's email as Signed-off-by:

From: Chris
Subject: [PATCH] fix something

From: Alice
This patch fixes something

Signed-off-by: Bob

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

[Xen-devel] [xen-4.4-testing test] 102914: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt3 host-install(3) broken in 102751 REGR. vs. 102521

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
102751 pass in 102914
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 102751 pass 
in 102914
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 102751 pass 
in 102914
 test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail pass in 102751
 test-xtf-amd64-amd64-3  31 xtf/test-hvm32pae-invlpg~shadow fail pass in 102751
 test-xtf-amd64-amd64-3 42 xtf/test-hvm64-invlpg~shadow fail pass in 102751
 test-xtf-amd64-amd64-3   52 leak-check/check   fail pass in 102751
 test-xtf-amd64-amd64-2   52 leak-check/check   fail pass in 102751
 test-xtf-amd64-amd64-1   52 leak-check/check   fail pass in 102751
 test-xtf-amd64-amd64-4   52 leak-check/check   fail pass in 102751
 test-xtf-amd64-amd64-5   52 leak-check/check   fail pass in 102751
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install fail pass in 102751

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-5 16 xtf/test-pv32pae-selftest fail in 102751 like 102521
 test-xtf-amd64-amd64-3 16 xtf/test-pv32pae-selftest fail in 102751 like 102521
 test-xtf-amd64-amd64-4   16 xtf/test-pv32pae-selftestfail  like 102521
 test-xtf-amd64-amd64-2   16 xtf/test-pv32pae-selftestfail  like 102521
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102521
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102521
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102521
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102521

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked in 102751 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 102751 n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1) blocked in 102751 n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-5 18 xtf/test-hvm32-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 18 xtf/test-hvm32-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-5 27 xtf/test-hvm32pae-cpuid-faulting fail in 102751 
never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pse-cpuid-faulting fail in 102751 
never pass
 test-xtf-amd64-amd64-3 27 xtf/test-hvm32pae-cpuid-faulting fail in 102751 
never pass
 test-xtf-amd64-amd64-5 37 xtf/test-hvm64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pse-cpuid-faulting fail in 102751 
never pass
 test-xtf-amd64-amd64-3 37 xtf/test-hvm64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-2 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-2 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-2 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-4 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-5 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-1 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-4 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-4 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-1 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-1 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-5 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-5 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/check fail in 102751 never 
pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   18 

[Xen-devel] [PATCH v2 1/4] x86/vpmu: Move vpmu_do_cpuid() handling into {pv, hvm}_cpuid()

[Andrew Cooper]

This reduces the net complexity of CPUID handling by having all adjustments in
at the same place.  Remove the now-unused vpmu_do_cpuid() infrastructure.

This involves introducing a vpmu_enabled() predicate, and making the Intel
specific VPMU_CPU_HAS_* constants public.

Signed-off-by: Andrew Cooper 
Acked-by: Kevin Tian 
Reviewed-by: Jan Beulich 
---
CC: Boris Ostrovsky 
---
 xen/arch/x86/cpu/vpmu.c   | 10 -
 xen/arch/x86/cpu/vpmu_intel.c | 52 ---
 xen/arch/x86/hvm/hvm.c| 23 +++
 xen/arch/x86/hvm/vmx/vmx.c|  2 --
 xen/arch/x86/traps.c  | 26 +-
 xen/include/asm-x86/vpmu.h| 10 -
 6 files changed, 48 insertions(+), 75 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 2f9ddf6..a542f4d 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -347,16 +347,6 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 }
 }
 
-void vpmu_do_cpuid(unsigned int input,
-   unsigned int *eax, unsigned int *ebx,
-   unsigned int *ecx, unsigned int *edx)
-{
-struct vpmu_struct *vpmu = vcpu_vpmu(current);
-
-if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_cpuid )
-vpmu->arch_vpmu_ops->do_cpuid(input, eax, ebx, ecx, edx);
-}
-
 static void vpmu_save_force(void *arg)
 {
 struct vcpu *v = (struct vcpu *)arg;
diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index e8049ed..e3f25c8 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -68,10 +68,6 @@
 #define MSR_PMC_ALIAS_MASK   (~(MSR_IA32_PERFCTR0 ^ MSR_IA32_A_PERFCTR0))
 static bool_t __read_mostly full_width_write;
 
-/* Intel-specific VPMU features */
-#define VPMU_CPU_HAS_DS 0x100 /* Has Debug Store */
-#define VPMU_CPU_HAS_BTS0x200 /* Has Branch Trace Store */
-
 /*
  * MSR_CORE_PERF_FIXED_CTR_CTRL contains the configuration of all fixed
  * counters. 4 bits for every counter.
@@ -782,33 +778,6 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 return 0;
 }
 
-static void core2_vpmu_do_cpuid(unsigned int input,
-unsigned int *eax, unsigned int *ebx,
-unsigned int *ecx, unsigned int *edx)
-{
-switch ( input )
-{
-case 0x1:
-
-if ( vpmu_is_set(vcpu_vpmu(current), VPMU_CPU_HAS_DS) )
-{
-/* Switch on the 'Debug Store' feature in CPUID.EAX[1]:EDX[21] */
-*edx |= cpufeat_mask(X86_FEATURE_DS);
-if ( cpu_has(_cpu_data, X86_FEATURE_DTES64) )
-*ecx |= cpufeat_mask(X86_FEATURE_DTES64);
-if ( cpu_has(_cpu_data, X86_FEATURE_DSCPL) )
-*ecx |= cpufeat_mask(X86_FEATURE_DSCPL);
-}
-break;
-
-case 0xa:
-/* Report at most version 3 since that's all we currently emulate */
-if ( MASK_EXTR(*eax, PMU_VERSION_MASK) > 3 )
-*eax = (*eax & ~PMU_VERSION_MASK) | MASK_INSR(3, PMU_VERSION_MASK);
-break;
-}
-}
-
 /* Dump vpmu info on console, called in the context of keyhandler 'q'. */
 static void core2_vpmu_dump(const struct vcpu *v)
 {
@@ -900,32 +869,12 @@ struct arch_vpmu_ops core2_vpmu_ops = {
 .do_wrmsr = core2_vpmu_do_wrmsr,
 .do_rdmsr = core2_vpmu_do_rdmsr,
 .do_interrupt = core2_vpmu_do_interrupt,
-.do_cpuid = core2_vpmu_do_cpuid,
 .arch_vpmu_destroy = core2_vpmu_destroy,
 .arch_vpmu_save = core2_vpmu_save,
 .arch_vpmu_load = core2_vpmu_load,
 .arch_vpmu_dump = core2_vpmu_dump
 };
 
-static void core2_no_vpmu_do_cpuid(unsigned int input,
-unsigned int *eax, unsigned int *ebx,
-unsigned int *ecx, unsigned int *edx)
-{
-/*
- * As in this case the vpmu is not enabled reset some bits in the
- * architectural performance monitoring related part.
- */
-if ( input == 0xa )
-{
-*eax &= ~PMU_VERSION_MASK;
-*eax &= ~PMU_GENERAL_NR_MASK;
-*eax &= ~PMU_GENERAL_WIDTH_MASK;
-
-*edx &= ~PMU_FIXED_NR_MASK;
-*edx &= ~PMU_FIXED_WIDTH_MASK;
-}
-}
-
 /*
  * If its a vpmu msr set it to 0.
  */
@@ -943,7 +892,6 @@ static int core2_no_vpmu_do_rdmsr(unsigned int msr, 
uint64_t *msr_content)
  */
 struct arch_vpmu_ops core2_no_vpmu_ops = {
 .do_rdmsr = core2_no_vpmu_do_rdmsr,
-.do_cpuid = core2_no_vpmu_do_cpuid,
 };
 
 int vmx_vpmu_initialise(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7763798..1c35dde 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3516,6 +3516,17 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
  

[Xen-devel] [PATCH v2 2/4] x86/vpmu: Remove core2_no_vpmu_ops

[Andrew Cooper]

core2_no_vpmu_ops exists solely to work around the default-leaking of CPUID/MSR
values in Xen.

With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
remaining hook.  Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu
intel: Add cpuid handling when vpmu disabled", a lot of work has been done and
the nop path in vpmu_do_msr() now suffices.

vpmu_do_msr() also falls into the nop path for un-configured or unprivileged
domains, which enables the removal the duplicate logic in priv_op_read_msr().

Finally, make all arch_vpmu_ops structures const as they are never modified,
and make them static as they are not referred to externally.

Signed-off-by: Andrew Cooper 
Acked-by: Kevin Tian 
---
CC: Jan Beulich 
CC: Boris Ostrovsky 

v2:
 * s/const static/static const/
 * Tweak comment
---
 xen/arch/x86/cpu/vpmu.c   |  6 +-
 xen/arch/x86/cpu/vpmu_amd.c   |  2 +-
 xen/arch/x86/cpu/vpmu_intel.c | 22 +-
 xen/arch/x86/traps.c  |  6 +-
 xen/include/asm-x86/vpmu.h|  2 +-
 5 files changed, 9 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index a542f4d..4c713be 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -136,9 +136,13 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
 const struct arch_vpmu_ops *ops;
 int ret = 0;
 
+/*
+ * Hide the PMU MSRs if vpmu is not configured, or the hardware domain is
+ * profiling the whole system.
+ */
 if ( likely(vpmu_mode == XENPMU_MODE_OFF) ||
  ((vpmu_mode & XENPMU_MODE_ALL) &&
-  !is_hardware_domain(current->domain)) )
+  !is_hardware_domain(curr->domain)) )
  goto nop;
 
 vpmu = vcpu_vpmu(curr);
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 55d03b3..43ade13 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -488,7 +488,7 @@ static void amd_vpmu_dump(const struct vcpu *v)
 }
 }
 
-struct arch_vpmu_ops amd_vpmu_ops = {
+static const struct arch_vpmu_ops amd_vpmu_ops = {
 .do_wrmsr = amd_vpmu_do_wrmsr,
 .do_rdmsr = amd_vpmu_do_rdmsr,
 .do_interrupt = amd_vpmu_do_interrupt,
diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index e3f25c8..e51bc4e 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -865,7 +865,7 @@ static void core2_vpmu_destroy(struct vcpu *v)
 vpmu_clear(vpmu);
 }
 
-struct arch_vpmu_ops core2_vpmu_ops = {
+static const struct arch_vpmu_ops core2_vpmu_ops = {
 .do_wrmsr = core2_vpmu_do_wrmsr,
 .do_rdmsr = core2_vpmu_do_rdmsr,
 .do_interrupt = core2_vpmu_do_interrupt,
@@ -875,32 +875,12 @@ struct arch_vpmu_ops core2_vpmu_ops = {
 .arch_vpmu_dump = core2_vpmu_dump
 };
 
-/*
- * If its a vpmu msr set it to 0.
- */
-static int core2_no_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-int type = -1, index = -1;
-if ( !is_core2_vpmu_msr(msr, , ) )
-return -EINVAL;
-*msr_content = 0;
-return 0;
-}
-
-/*
- * These functions are used in case vpmu is not enabled.
- */
-struct arch_vpmu_ops core2_no_vpmu_ops = {
-.do_rdmsr = core2_no_vpmu_do_rdmsr,
-};
-
 int vmx_vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 u64 msr_content;
 static bool_t ds_warned;
 
-vpmu->arch_vpmu_ops = _no_vpmu_ops;
 if ( vpmu_mode == XENPMU_MODE_OFF )
 return 0;
 
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 48ac519..638d8ff 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2566,11 +2566,7 @@ static int priv_op_read_msr(unsigned int reg, uint64_t 
*val,
 case MSR_K7_EVNTSEL0...MSR_K7_PERFCTR3:
 if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
 {
-/* Don't leak PMU MSRs to unprivileged domains. */
-if ( (vpmu_mode & XENPMU_MODE_ALL) &&
- !is_hardware_domain(currd) )
-*val = 0;
-else if ( vpmu_do_rdmsr(reg, val) )
+if ( vpmu_do_rdmsr(reg, val) )
 break;
 return X86EMUL_OKAY;
 }
diff --git a/xen/include/asm-x86/vpmu.h b/xen/include/asm-x86/vpmu.h
index d1dda4b..e50618f 100644
--- a/xen/include/asm-x86/vpmu.h
+++ b/xen/include/asm-x86/vpmu.h
@@ -60,7 +60,7 @@ struct vpmu_struct {
 u32 hw_lapic_lvtpc;
 void *context;  /* May be shared with PV guest */
 void *priv_context; /* hypervisor-only */
-struct arch_vpmu_ops *arch_vpmu_ops;
+const struct arch_vpmu_ops *arch_vpmu_ops;
 struct xen_pmu_data *xenpmu_data;
 spinlock_t vpmu_lock;
 };
-- 
2.1.4


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

[Xen-devel] [PATCH v2 3/4] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

[Andrew Cooper]

This reduces the net complexity of CPUID handling by having all adjustments in
at the same place.  Remove the now-unused hvm_funcs.cpuid_intercept
infrastructure.

The SYSCALL feature hiding is tweaked when moved.  In principle, an
administrator can choose to explicitly hide the SYSCALL feature from the
guest, as it has a separate feature bit.  If this is the case, the feature
shouldn't be set behind the back of the administrators wishes.  (Not that many
64bit OSes would function in this scenario.)  In reality, SYSCALL will always
be set in edx at this point.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 

v2:
 * Update commit message to explain the difference with SYCALL handling.
 * Entirely exclude leaf 0x801c outside of AMD hardware.
---
 xen/arch/x86/hvm/emulate.c|  2 +-
 xen/arch/x86/hvm/hvm.c| 27 +--
 xen/arch/x86/hvm/svm/svm.c| 39 ++-
 xen/arch/x86/hvm/vmx/vmx.c| 31 ++-
 xen/include/asm-x86/hvm/hvm.h |  3 ---
 5 files changed, 26 insertions(+), 76 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index d0a043b..efae4df 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1565,7 +1565,7 @@ int hvmemul_cpuid(
  hvm_check_cpuid_faulting(current) )
 return X86EMUL_EXCEPTION;
 
-hvm_funcs.cpuid_intercept(eax, ebx, ecx, edx);
+hvm_cpuid(*eax, eax, ebx, ecx, edx);
 return X86EMUL_OKAY;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 1c35dde..652a496 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -906,12 +906,7 @@ const char *hvm_efer_valid(const struct vcpu *v, uint64_t 
value,
 ASSERT(v->domain == current->domain);
 hvm_cpuid(0x8000, , NULL, NULL, NULL);
 if ( (level >> 16) == 0x8000 && level > 0x8000 )
-{
-unsigned int dummy;
-
-level = 0x8001;
-hvm_funcs.cpuid_intercept(, , _ecx, _edx);
-}
+hvm_cpuid(0x8001, NULL, NULL, _ecx, _edx);
 }
 else
 {
@@ -3702,6 +3697,12 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
 *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
 }
+
+/* SYSCALL is hidden outside of long mode on Intel. */
+if ( d->arch.x86_vendor == X86_VENDOR_INTEL &&
+ !hvm_long_mode_enabled(v))
+*edx &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
+
 break;
 
 case 0x8007:
@@ -3726,6 +3727,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 
 *ebx &= hvm_featureset[FEATURESET_e8b];
 break;
+
+case 0x801c:
+if ( !cpu_has_svm )
+{
+*eax = *ebx = *ecx = *edx = 0;
+break;
+}
+
+if ( cpu_has_lwp && (v->arch.xcr0 & XSTATE_LWP) )
+/* Turn on available bit and other features specified in lwp_cfg. 
*/
+*eax = (*edx & v->arch.hvm_svm.guest_lwp_cfg) | 1;
+else
+*eax = 0;
+break;
 }
 }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 1588b2f..df087d9 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1565,41 +1565,6 @@ static void svm_fpu_dirty_intercept(void)
 vmcb_set_cr0(vmcb, vmcb_get_cr0(vmcb) & ~X86_CR0_TS);
 }
 
-static void svm_cpuid_intercept(
-unsigned int *eax, unsigned int *ebx,
-unsigned int *ecx, unsigned int *edx)
-{
-unsigned int input = *eax;
-struct vcpu *v = current;
-
-hvm_cpuid(input, eax, ebx, ecx, edx);
-
-switch (input) {
-case 0x801c: 
-{
-/* LWP capability CPUID */
-uint64_t lwp_cfg = v->arch.hvm_svm.guest_lwp_cfg;
-
-if ( cpu_has_lwp )
-{
-if ( !(v->arch.xcr0 & XSTATE_LWP) )
-   {
-*eax = 0x0;
-break;
-}
-
-/* turn on available bit and other features specified in lwp_cfg */
-*eax = (*edx & lwp_cfg) | 0x0001;
-}
-break;
-}
-default:
-break;
-}
-
-HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
-}
-
 static void svm_vmexit_do_cpuid(struct cpu_user_regs *regs)
 {
 unsigned int eax, ebx, ecx, edx, inst_len;
@@ -1612,7 +1577,8 @@ static void svm_vmexit_do_cpuid(struct cpu_user_regs 
*regs)
 ecx = regs->ecx;
 edx = regs->edx;
 
-svm_cpuid_intercept(, , , );
+hvm_cpuid(regs->_eax, , , , );
+HVMTRACE_5D(CPUID, regs->_eax, eax, ebx, ecx, edx);
 
 regs->eax = eax;
 regs->ebx = ebx;
@@ -2244,7 

[Xen-devel] [PATCH v2 0/4] Introductory cleanup for CPUID phase 2 work

[Andrew Cooper]

This is some cleanup intended to ease the development of further development
work.  There is no practical change from a guests point of view.

Andrew Cooper (4):
  x86/vpmu: Move vpmu_do_cpuid() handling into {pv,hvm}_cpuid()
  x86/vpmu: Remove core2_no_vpmu_ops
  x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()
  x86/hvm: Move hvm_hypervisor_cpuid_leaf() handling into 
cpuid_hypervisor_leaves()

 xen/arch/x86/cpu/vpmu.c   | 16 +++---
 xen/arch/x86/cpu/vpmu_amd.c   |  2 +-
 xen/arch/x86/cpu/vpmu_intel.c | 74 +--
 xen/arch/x86/hvm/emulate.c|  2 +-
 xen/arch/x86/hvm/hvm.c| 72 +
 xen/arch/x86/hvm/svm/svm.c| 39 ++-
 xen/arch/x86/hvm/vmx/vmx.c| 52 ++
 xen/arch/x86/traps.c  | 69 +---
 xen/include/asm-x86/hvm/hvm.h | 10 --
 xen/include/asm-x86/vpmu.h| 12 +++
 10 files changed, 113 insertions(+), 235 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/4] x86/hvm: Move hvm_hypervisor_cpuid_leaf() handling into cpuid_hypervisor_leaves()

[Andrew Cooper]

This reduces the net complexity of CPUID handling by having all adjustments in
at the same place.  Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf()
infrastructure.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 

v2:
 * Reorder the position of the blanket zero
---
 xen/arch/x86/hvm/hvm.c| 22 --
 xen/arch/x86/hvm/vmx/vmx.c| 19 ---
 xen/arch/x86/traps.c  | 37 ++---
 xen/include/asm-x86/hvm/hvm.h |  7 ---
 4 files changed, 30 insertions(+), 55 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 652a496..c5dfd6e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3401,28 +3401,6 @@ unsigned long copy_from_user_hvm(void *to, const void 
*from, unsigned len)
 return rc ? len : 0; /* fake a copy_from_user() return code */
 }
 
-void hvm_hypervisor_cpuid_leaf(uint32_t sub_idx,
-   uint32_t *eax, uint32_t *ebx,
-   uint32_t *ecx, uint32_t *edx)
-{
-*eax = *ebx = *ecx = *edx = 0;
-if ( hvm_funcs.hypervisor_cpuid_leaf )
-hvm_funcs.hypervisor_cpuid_leaf(sub_idx, eax, ebx, ecx, edx);
-
-if ( sub_idx == 0 )
-{
-/*
- * Indicate that memory mapped from other domains (either grants or
- * foreign pages) has valid IOMMU entries.
- */
-*eax |= XEN_HVM_CPUID_IOMMU_MAPPINGS;
-
-/* Indicate presence of vcpu id and set it in ebx */
-*eax |= XEN_HVM_CPUID_VCPU_ID_PRESENT;
-*ebx = current->vcpu_id;
-}
-}
-
 void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx)
 {
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 499b300..350b945 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1908,24 +1908,6 @@ static void vmx_handle_eoi(u8 vector)
 __vmwrite(GUEST_INTR_STATUS, status);
 }
 
-void vmx_hypervisor_cpuid_leaf(uint32_t sub_idx,
-   uint32_t *eax, uint32_t *ebx,
-   uint32_t *ecx, uint32_t *edx)
-{
-if ( sub_idx != 0 )
-return;
-if ( cpu_has_vmx_apic_reg_virt )
-*eax |= XEN_HVM_CPUID_APIC_ACCESS_VIRT;
-/*
- * We want to claim that x2APIC is virtualized if APIC MSR accesses are
- * not intercepted. When all three of these are true both rdmsr and wrmsr
- * in the guest will run without VMEXITs (see vmx_vlapic_msr_changed()).
- */
-if ( cpu_has_vmx_virtualize_x2apic_mode && cpu_has_vmx_apic_reg_virt &&
- cpu_has_vmx_virtual_intr_delivery )
-*eax |= XEN_HVM_CPUID_X2APIC_VIRT;
-}
-
 static void vmx_enable_msr_interception(struct domain *d, uint32_t msr)
 {
 struct vcpu *v;
@@ -2126,7 +2108,6 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .sync_pir_to_irr  = vmx_sync_pir_to_irr,
 .handle_eoi   = vmx_handle_eoi,
 .nhvm_hap_walk_L1_p2m = nvmx_hap_walk_L1_p2m,
-.hypervisor_cpuid_leaf = vmx_hypervisor_cpuid_leaf,
 .enable_msr_interception = vmx_enable_msr_interception,
 .is_singlestep_supported = vmx_is_singlestep_supported,
 .set_mode = vmx_set_mode,
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 638d8ff..5ddc408 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -907,7 +907,8 @@ int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val)
 int cpuid_hypervisor_leaves( uint32_t idx, uint32_t sub_idx,
uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx)
 {
-struct domain *currd = current->domain;
+struct vcpu *curr = current;
+struct domain *currd = curr->domain;
 /* Optionally shift out of the way of Viridian architectural leaves. */
 uint32_t base = is_viridian_domain(currd) ? 0x4100 : 0x4000;
 uint32_t limit, dummy;
@@ -999,13 +1000,35 @@ int cpuid_hypervisor_leaves( uint32_t idx, uint32_t 
sub_idx,
 }
 break;
 
-case 4:
-if ( !has_hvm_container_domain(currd) )
-{
-*eax = *ebx = *ecx = *edx = 0;
+case 4: /* HVM hypervisor leaf. */
+*eax = *ebx = *ecx = *edx = 0;
+
+if ( !has_hvm_container_domain(currd) || sub_idx != 0 )
 break;
-}
-hvm_hypervisor_cpuid_leaf(sub_idx, eax, ebx, ecx, edx);
+
+if ( cpu_has_vmx_apic_reg_virt )
+*eax |= XEN_HVM_CPUID_APIC_ACCESS_VIRT;
+
+/*
+ * We want to claim that x2APIC is virtualized if APIC MSR accesses
+ * are not intercepted. When all three of these are true both rdmsr
+ * and wrmsr in the guest will run without VMEXITs (see
+ * vmx_vlapic_msr_changed()).
+ */
+if ( cpu_has_vmx_virtualize_x2apic_mode &&
+   

Re: [Xen-devel] [PATCH v4 00/12] xenstore: support reading directory with many children

[Andrew Cooper]

On 05/12/16 12:05, Wei Liu wrote:
> On Mon, Dec 05, 2016 at 08:48:41AM +0100, Juergen Gross wrote:
> [...]
>> Juergen Gross (12):
>>   xenstore: modify add_change_node() parameter types
>>   xenstore: call add_change_node() directly when writing node
>>   xenstore: use common tdb record header in xenstore
>>   xenstore: add per-node generation counter
>>   xenstore: add support for reading directory with many children
>>   xenstore: support XS_DIRECTORY_PART in libxenstore
>>   xenstore: use array for xenstore wire command handling
>>   xenstore: let command functions return error or success
>>   xenstore: make functions static
>>   xenstore: add helper functions for wire argument parsing
>>   xenstore: add small default data buffer to internal struct
>>   xenstore: handle memory allocation failures in xenstored
>>
> Applied to staging.

XenServer's Coverity has run, and has a few things to say.  Its not
obvious (i.e. I can't trivially identify) if these are preexisting bugs
which your code has brought to light, or introduced by your series.

Both do_rm() and do_mkdir() suffer from the same problem.

onearg(in) may return NULL, which results in get_node_canonicalized()
setting name to NULL and returning NULL.  name is then dereferenced in
the error path by get_parent()/create_node() respectively.

There are two complains of leaking a talloc_array() allocation.  First
in do_set_perms() via the xs_strings_to_perms() failure path and second
in send_directory_part() via the success path.  The use of
talloc_array() in add_event() would suggest that you are expected to
call talloc_free() on the result, unless I am missing something subtle.

There is another resource leak complaint of bdata in send_reply(),
although this case clearly hasn't observed the list_add_tail(), so I
don't think this is a real issue.

Finally, xs_directory_part(), on line 619 uses a strncpy() for all bytes
of gen, but doesn't necesserily NULL terminate it, and is later used by
strcmp().

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 102830

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102830
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102830
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102830
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102830

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  20f9a22c2743d1ef558ea481e109486b3aa0787f
baseline version:
 libvirt  ff8e021225ce5d2ca962ea433172df42f2d52c78

Last test of basis   102830  2016-12-03 04:24:31 Z2 days
Testing same since   102921  2016-12-05 04:21:47 Z0 days1 attempts


People who touched revisions under test:
  Daniel Veillard 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   fail
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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


Not pushing.


commit 20f9a22c2743d1ef558ea481e109486b3aa0787f
Author: Daniel Veillard 
Date:   Sun Dec 4 22:07:38 2016 +0100

Release of libvirt-2.5.0

* po/*.po*

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

Re: [Xen-devel] [PATCH 1/2] Kconfig: introduce allrandom.config

[Doug Goldstein]

On 12/5/16 10:45 AM, Wei Liu wrote:
> This would be used to force selection of certain items in randconfig.
> 
> We need this to force gcov format to be autodetected in randconfig
> target, which would avoid generating known-incompatible combinations.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Doug Goldstein 
> ---
>  xen/tools/kconfig/allrandom.config | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 xen/tools/kconfig/allrandom.config
> 
> diff --git a/xen/tools/kconfig/allrandom.config 
> b/xen/tools/kconfig/allrandom.config
> new file mode 100644
> index 000..e49e7d6
> --- /dev/null
> +++ b/xen/tools/kconfig/allrandom.config
> @@ -0,0 +1 @@
> +CONFIG_GCOV_FORMAT_AUTODETECT=y
> 

Thank you for doing this Wei. I do agree with Andrew about the explicit
comment.

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



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

[Xen-devel] [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

[Alex Thorlton]

It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
case.  This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
E820_X_MAX is always at least slightly larger than E820MAX.

The real motivation behind this is actually to prevent some issues in
the Xen kernel, where the XENMEM_machine_memory_map hypercall can
produce an e820 map larger than 128 entries, even on systems where the
original e820 table was quite a bit smaller than that, depending on how
many IOAPICs are installed on the system.

Signed-off-by: Alex Thorlton 
Suggested-by: Ingo Molnar 
Cc: Russ Anderson 
Cc: David Vrabel 
Cc: Ingo Molnar 
Cc: Juergen Gross 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Denys Vlasenko 
Cc: Boris Ostrovsky 
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/include/asm/e820.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/e820.h b/arch/x86/include/asm/e820.h
index 476b574..ec23d8e 100644
--- a/arch/x86/include/asm/e820.h
+++ b/arch/x86/include/asm/e820.h
@@ -1,13 +1,17 @@
 #ifndef _ASM_X86_E820_H
 #define _ASM_X86_E820_H
 
-#ifdef CONFIG_EFI
+/*
+ * E820_X_MAX is the maximum size of the extended E820 table.  The extended
+ * table may contain up to 3 extra E820 entries per possible NUMA node, so we
+ * make room for 3 * MAX_NUMNODES possible entries, beyond the standard 128.
+ * Also note that E820_X_MAX *must* be defined before we include 
uapi/asm/e820.h.
+ */
 #include 
 #define E820_X_MAX (E820MAX + 3 * MAX_NUMNODES)
-#else  /* ! CONFIG_EFI */
-#define E820_X_MAX E820MAX
-#endif
+
 #include 
+
 #ifndef __ASSEMBLY__
 /* see comment in arch/x86/kernel/e820.c */
 extern struct e820map *e820;
-- 
1.8.5.6


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

[Xen-devel] [RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

[Alex Thorlton]

This is the third pass at my patchset to fix up our problems with
XENMEM_machine_memory_map on large systems.  The only changes on this
pass were to flesh out the comment above the E820_X_MAX definition, and
to add Juergen's Reviewed-by to the second patch.

Let me know if anyone has any questions/comments!

Alex Thorlton (2):
  x86: Make E820_X_MAX unconditionally larger than E820MAX
  xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

 arch/x86/include/asm/e820.h | 12 
 arch/x86/xen/setup.c|  6 +++---
 2 files changed, 11 insertions(+), 7 deletions(-)

-- 
1.8.5.6


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

[Xen-devel] [PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

[Alex Thorlton]

On systems with sufficiently large e820 tables, and several IOAPICs, it
is possible for the XENMEM_machine_memory_map callback (and its
counterpart, XENMEM_memory_map) to attempt to return an e820 table with
more than 128 entries.  This callback adds entries to the BIOS-provided
e820 table to account for IOAPIC registers, which, on sufficiently large
systems, can result in an e820 table that is too large to copy back into
xen_e820_map.

This change simply increases the size of xen_e820_map to E820_X_MAX to
ensure that there is enough room to store the entire e820 map returned
from this callback.

Signed-off-by: Alex Thorlton 
Suggested-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Cc: Russ Anderson 
Cc: David Vrabel 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Denys Vlasenko 
Cc: Boris Ostrovsky 
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/xen/setup.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index f8960fc..8c394e3 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -41,7 +41,7 @@
 unsigned long xen_released_pages;
 
 /* E820 map used during setting up memory. */
-static struct e820entry xen_e820_map[E820MAX] __initdata;
+static struct e820entry xen_e820_map[E820_X_MAX] __initdata;
 static u32 xen_e820_map_entries __initdata;
 
 /*
@@ -750,7 +750,7 @@ char * __init xen_memory_setup(void)
max_pfn = min(max_pfn, xen_start_info->nr_pages);
mem_end = PFN_PHYS(max_pfn);
 
-   memmap.nr_entries = E820MAX;
+   memmap.nr_entries = ARRAY_SIZE(xen_e820_map);
set_xen_guest_handle(memmap.buffer, xen_e820_map);
 
op = xen_initial_domain() ?
@@ -923,7 +923,7 @@ char * __init xen_auto_xlated_memory_setup(void)
int i;
int rc;
 
-   memmap.nr_entries = E820MAX;
+   memmap.nr_entries = ARRAY_SIZE(xen_e820_map);
set_xen_guest_handle(memmap.buffer, xen_e820_map);
 
rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
-- 
1.8.5.6


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

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

[osstest service owner]

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

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  cc50fa3051947e1b72f87f22767886a7904761fe
baseline version:
 xen  8e4b2676685f50bc26f03b5f62d8b7aea8e69dbf

Last test of basis   102812  2016-12-02 19:19:24 Z2 days
Failing since102944  2016-12-05 13:01:14 Z0 days2 attempts
Testing same since   102948  2016-12-05 15:01:20 Z0 days1 attempts


People who touched revisions under test:
  Cedric Bosdonnat 
  Cédric Bosdonnat 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Samuel Thibault 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=cc50fa3051947e1b72f87f22767886a7904761fe
+ . ./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 
cc50fa3051947e1b72f87f22767886a7904761fe
+ branch=xen-unstable-smoke
+ revision=cc50fa3051947e1b72f87f22767886a7904761fe
+ . ./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.8-testing
+ '[' xcc50fa3051947e1b72f87f22767886a7904761fe = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : 

[Xen-devel] [PATCH] xen/arm: traps: Emulate ICC_SRE_EL1 as RAZ/WI

[Julien Grall]

Recent Linux kernel (4.4 and onwards [1]) is checking whether it is possible
to enable sysreg access (ICC_SRE_EL1.SRE) when the ID register
(ID_AA64PRF0_EL1.GIC) is reporting the presence of the sysreg interface.

When the guest has been configured to use GICv2, the hypervisor will
disable sysreg access for this vm (via ICC_SRE_EL2.Enable) and therefore
access to system register such as ICC_SRE_EL1 are trapped in EL2.

However, ICC_SRE_EL1 is not emulated by the hypervisor. This means that
Linux will crash as soon as it is trying to access ICC_SRE_EL1.

To solve this problem, Xen can implement ICC_SRE_EL1 as read-as-zero
write-ignore. The emulation will only be used when sysreg are disabled
for EL1.

[1]  963fcd409 "arm64: cpufeatures: Check ICC_EL1_SRE.SRE before
enabling ARM64_HAS_SYSREG_GIC_CPUIF"

Signed-off-by: Julien Grall 

---
I think this patch would need to be backported as recent Linux (4.4
and onwards) are trying to access ICC_EL1_SRE during boot time.

The first support of GICv2 on GICv3 was in Xen 4.6.
---
 xen/arch/arm/traps.c  | 14 ++
 xen/include/asm-arm/sysregs.h |  1 +
 2 files changed, 15 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 8ff73fe..ae921d7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2280,6 +2280,20 @@ static void do_sysreg(struct cpu_user_regs *regs,
 return inject_undef64_exception(regs, hsr.len);
 
 /*
+ *  ICC_SRE_EL2.Enable = 0
+ *
+ *  GIC Architecture Specification (IHI 0069C): Section 8.1.9
+ */
+case HSR_SYSREG_ICC_SRE_EL1:
+/*
+ * Trapped when the guest is using GICv2 whilst the platform
+ * interrupt controller is GICv3. In this case, the register
+ * should be emulate as RAZ/WI to tell the guest to use the GIC
+ * memory mapped interface (i.e GICv2 compatibility).
+ */
+return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+
+/*
  * HCR_EL2.TIDCP
  *
  * ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/sysregs.h
index 570f43e..887368e 100644
--- a/xen/include/asm-arm/sysregs.h
+++ b/xen/include/asm-arm/sysregs.h
@@ -90,6 +90,7 @@
 #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
 #define HSR_SYSREG_ICC_ASGI1R_EL1 HSR_SYSREG(3,1,c12,c11,6)
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
+#define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
1.9.1


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

Re: [Xen-devel] [PATCH 1/2] xen/x86: return partial memory map in case of not enough space

[Jan Beulich]

>>> On 05.12.16 at 17:34,  wrote:
> For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
> caller's buffer can't hold all entries.
> 
> This is a problem as the caller has normally a static buffer defined
> and when he is doing the call no dynamic memory allocation is
> possible as nothing is yet known about the system's memory layout.
> 
> Instead of just fail deliver as many memory map entries as possible
> and return with E2BIG indicating the result was incomplete. Then the
> caller will be capable to use at least some memory reported to exist
> to allocate a larger buffer for the complete memory map.

This makes no sense, as what we're talking about here is the
machine memory map, and the calling Dom0 kernel can't allocate
from that pool directly. Instead it would need its own memory
map to know where to place such a larger buffer, and this map
is usually just one or two entries large.

For that reason I'm not convinced we need or want this change.

Jan


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

Re: [Xen-devel] [PATCH 5/8] x86/hvm: Don't raise #GP behind the emulators back for MSR accesses

[Jan Beulich]

>>> On 05.12.16 at 17:29,  wrote:
> On 05/12/16 12:10, Jan Beulich wrote:
> On 05.12.16 at 11:09,  wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -509,7 +509,11 @@ void hvm_do_resume(struct vcpu *v)
>>>  
>>>  if ( w->do_write.msr )
>>>  {
>>> -hvm_msr_write_intercept(w->msr, w->value, 0);
>>> +int rc = hvm_msr_write_intercept(w->msr, w->value, 0);
>>> +
>>> +if ( rc == X86EMUL_EXCEPTION )
>>> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
>> The use of a local variable looks kind of pointless here.
> 
> The first version had
> 
> if ( hvm_msr_write_intercept(w->msr, w->value, 0) ==
>  X86EMUL_EXCEPTION )
> 
> but this looked rather ugly to read.  I prefer the version as submitted,
> but am not too fussed if you insist for the latter?

I won't insist, it was just a suggestion to make the code look better
to my eyes. If you like it better as is, keep it.

Jan


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

Re: [Xen-devel] [PATCH 0/2] xen: modify dom0 interface for obtaining memory map

[Andrew Cooper]

On 05/12/16 16:43, Juergen Gross wrote:
> On 05/12/16 17:39, Andrew Cooper wrote:
>> On 05/12/16 16:34, Juergen Gross wrote:
>>> Today's interface to get the machine memory map in dom0 requires to
>>> know in advance how large the final map will be. There is however no
>>> way to either get only a part of the memory map or to ask the
>>> hypervisor about its size.
>>>
>>> This patch set enhances the XENMEM_machine_memory_map hypercall to
>>> solve both issues by returning only a partial memory map in case the
>>> supplied buffer was too small and to return the needed number of
>>> entries if no buffer is being supplied.
>> These changes appear to be a good improvement in behaviour.
>>
>> However, there is a way to know the exact size of the memory map.  Use
>> XENMEM_maximum_ram_page to find the maximum mfn, and use that to
>> calculate the size of the mapping.
>>
>> See tools/libxc/xc_sr_common_x86_pv.c: x86_pv_map_m2p()
> How does this help for the size of the E820 map of the physical machine
> "enhanced" by the hypervisor to reflect holes for IOAPICs and IOMMU?
>
> The problem is related to the *machine* memory map!

I clearly haven't had enough coffee yet.  I was confusing my various
machine memory maps.  Sorry for the noise.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] Travis-ci: specify KCONFIG_ALLCONFIG for randconfig

[Andrew Cooper]

On 05/12/16 16:45, Wei Liu wrote:
> The file provided contains symbols that must be set to certain values.
> This then prevents random build breakage in travis due to
> known-incompatible symbol selections.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 1/2] Kconfig: introduce allrandom.config

[Andrew Cooper]

On 05/12/16 16:45, Wei Liu wrote:
> This would be used to force selection of certain items in randconfig.
>
> We need this to force gcov format to be autodetected in randconfig
> target, which would avoid generating known-incompatible combinations.
>
> Signed-off-by: Wei Liu 
> ---
> Cc: Doug Goldstein 
> ---
>  xen/tools/kconfig/allrandom.config | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 xen/tools/kconfig/allrandom.config
>
> diff --git a/xen/tools/kconfig/allrandom.config 
> b/xen/tools/kconfig/allrandom.config
> new file mode 100644
> index 000..e49e7d6
> --- /dev/null
> +++ b/xen/tools/kconfig/allrandom.config
> @@ -0,0 +1 @@

I'd put a comment here saying

# Explicit option choices not subject to regular RANDCONFIG

Otherwise, Reviewed-by: Andrew Cooper 

> +CONFIG_GCOV_FORMAT_AUTODETECT=y


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb
baseline version:
 ovmf 7bbe0b3eff9e7876808ce1b96b9a71360984cf91

Last test of basis   102827  2016-12-03 02:45:34 Z2 days
Testing same since   102915  2016-12-05 01:46:17 Z0 days1 attempts


People who touched revisions under test:
  Chen A Chen 

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=0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb
+ . ./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 
0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb
+ branch=ovmf
+ revision=0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb
+ . ./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.8-testing
+ '[' x0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [PATCH 0/2] Fix randconfig build in travis-ci

[Wei Liu]

Wei Liu (2):
  Kconfig: introduce allrandom.config
  Travis-ci: specify KCONFIG_ALLCONFIG for randconfig

 scripts/travis-build   | 2 +-
 xen/tools/kconfig/allrandom.config | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 xen/tools/kconfig/allrandom.config

-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] Kconfig: introduce allrandom.config

[Wei Liu]

This would be used to force selection of certain items in randconfig.

We need this to force gcov format to be autodetected in randconfig
target, which would avoid generating known-incompatible combinations.

Signed-off-by: Wei Liu 
---
Cc: Doug Goldstein 
---
 xen/tools/kconfig/allrandom.config | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 xen/tools/kconfig/allrandom.config

diff --git a/xen/tools/kconfig/allrandom.config 
b/xen/tools/kconfig/allrandom.config
new file mode 100644
index 000..e49e7d6
--- /dev/null
+++ b/xen/tools/kconfig/allrandom.config
@@ -0,0 +1 @@
+CONFIG_GCOV_FORMAT_AUTODETECT=y
-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] Travis-ci: specify KCONFIG_ALLCONFIG for randconfig

[Wei Liu]

The file provided contains symbols that must be set to certain values.
This then prevents random build breakage in travis due to
known-incompatible symbol selections.

Signed-off-by: Wei Liu 
---
Cc: Doug Goldstein 
---
 scripts/travis-build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/travis-build b/scripts/travis-build
index 584d008..0cb15a8 100755
--- a/scripts/travis-build
+++ b/scripts/travis-build
@@ -4,7 +4,7 @@ $CC --version
 
 # random config or default config
 if [[ "${RANDCONFIG}" == "y" ]]; then
-make -C xen randconfig
+make -C xen KCONFIG_ALLCONFIG=tools/kconfig/allrandom.config randconfig
 else
 make -C xen defconfig
 fi
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 0/2] xen: modify dom0 interface for obtaining memory map

[Juergen Gross]

On 05/12/16 17:39, Andrew Cooper wrote:
> On 05/12/16 16:34, Juergen Gross wrote:
>> Today's interface to get the machine memory map in dom0 requires to
>> know in advance how large the final map will be. There is however no
>> way to either get only a part of the memory map or to ask the
>> hypervisor about its size.
>>
>> This patch set enhances the XENMEM_machine_memory_map hypercall to
>> solve both issues by returning only a partial memory map in case the
>> supplied buffer was too small and to return the needed number of
>> entries if no buffer is being supplied.
> 
> These changes appear to be a good improvement in behaviour.
> 
> However, there is a way to know the exact size of the memory map.  Use
> XENMEM_maximum_ram_page to find the maximum mfn, and use that to
> calculate the size of the mapping.
> 
> See tools/libxc/xc_sr_common_x86_pv.c: x86_pv_map_m2p()

How does this help for the size of the E820 map of the physical machine
"enhanced" by the hypervisor to reflect holes for IOAPICs and IOMMU?

The problem is related to the *machine* memory map!


Juergen


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

Re: [Xen-devel] [PATCH 0/2] xen: modify dom0 interface for obtaining memory map

[Andrew Cooper]

On 05/12/16 16:34, Juergen Gross wrote:
> Today's interface to get the machine memory map in dom0 requires to
> know in advance how large the final map will be. There is however no
> way to either get only a part of the memory map or to ask the
> hypervisor about its size.
>
> This patch set enhances the XENMEM_machine_memory_map hypercall to
> solve both issues by returning only a partial memory map in case the
> supplied buffer was too small and to return the needed number of
> entries if no buffer is being supplied.

These changes appear to be a good improvement in behaviour.

However, there is a way to know the exact size of the memory map.  Use
XENMEM_maximum_ram_page to find the maximum mfn, and use that to
calculate the size of the mapping.

See tools/libxc/xc_sr_common_x86_pv.c: x86_pv_map_m2p()

(Not that I think this interface is very nice either...)

~Andrew

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

Re: [Xen-devel] [PATCH] stubdom: correct dependency for ioemu linkfarm

[Juergen Gross]

On 08/11/16 07:29, Juergen Gross wrote:
> The dependency for setting up the links for ioemu is wrong: it is
> depending on tools/qemu-xen-traditional-dir which is being modified by
> each "make tools" call. This leads to rebuilds of several stubdom
> libraries for each call of "make stubdom" as those depend on the ioemu
> linkfarm stamp file.
> 
> Modify the dependency to the qemu Makefile instead which is a better
> indicator whether we need to create the qemu directory before setting
> up the links.
> 
> Signed-off-by: Juergen Gross 

Ping?


Juergen

> ---
>  stubdom/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 2921f30..0b33e23 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -281,10 +281,10 @@ IOEMU_LINKFARM_TARGET := ioemu/linkfarm.stamp
>  endif
>  
>  ifeq ($(QEMU_ROOT),.)
> -$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
> +$(XEN_ROOT)/tools/qemu-xen-traditional-dir/Makefile:
>   $(MAKE) DESTDIR= -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
>  
> -ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir
> +ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir/Makefile
>   mkdir -p ioemu
>   set -e; 
> \
>   $(buildmakevars2shellvars); 
> \
> 


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

[Xen-devel] [PATCH 2/2] xen/x86: add a way to obtain the needed number of memory map entries

[Juergen Gross]

Today there is no way for a domain to obtain the number of entries of
the machine memory map returned by XENMEM_machine_memory_map hypercall.

Modify the interface to return just the needed number of map entries
in case the buffer was specified as NULL.

Signed-off-by: Juergen Gross 
---
 xen/arch/x86/mm.c   | 38 +++---
 xen/include/public/memory.h |  2 ++
 2 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f8e679d..d384022 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4736,15 +4736,18 @@ static int _handle_iomem_range(unsigned long s, 
unsigned long e,
 XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
 XEN_GUEST_HANDLE(e820entry_t) buffer;
 
-if ( ctxt->n + 1 >= ctxt->map.nr_entries )
-return -E2BIG;
-ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT;
-ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT;
-ent.type = E820_RESERVED;
-buffer_param = guest_handle_cast(ctxt->map.buffer, e820entry_t);
-buffer = guest_handle_from_param(buffer_param, e820entry_t);
-if ( __copy_to_guest_offset(buffer, ctxt->n, , 1) )
-return -EFAULT;
+if ( !guest_handle_is_null(ctxt->map.buffer) )
+{
+if ( ctxt->n + 1 >= ctxt->map.nr_entries )
+return -E2BIG;
+ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT;
+ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT;
+ent.type = E820_RESERVED;
+buffer_param = guest_handle_cast(ctxt->map.buffer, e820entry_t);
+buffer = guest_handle_from_param(buffer_param, e820entry_t);
+if ( __copy_to_guest_offset(buffer, ctxt->n, , 1) )
+return -EFAULT;
+}
 ctxt->n++;
 }
 ctxt->s = e + 1;
@@ -4978,6 +4981,7 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 XEN_GUEST_HANDLE(e820entry_t) buffer;
 XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;
 unsigned int i;
+bool store;
 
 rc = xsm_machine_memory_map(XSM_PRIV);
 if ( rc )
@@ -4986,9 +4990,10 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( copy_from_guest(, arg, 1) )
 return -EFAULT;
 
+store = !guest_handle_is_null(ctxt.map.buffer);
 buffer_param = guest_handle_cast(ctxt.map.buffer, e820entry_t);
 buffer = guest_handle_from_param(buffer_param, e820entry_t);
-if ( !guest_handle_okay(buffer, ctxt.map.nr_entries) )
+if ( store && !guest_handle_okay(buffer, ctxt.map.nr_entries) )
 return -EFAULT;
 
 for ( i = 0, ctxt.n = 0, ctxt.s = 0; i < e820.nr_map; ++i, ++ctxt.n )
@@ -5005,13 +5010,16 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( rc )
 break;
 }
-if ( ctxt.map.nr_entries <= ctxt.n + 1 )
+if ( store )
 {
-rc = -E2BIG;
-break;
+if ( ctxt.map.nr_entries <= ctxt.n + 1 )
+{
+rc = -E2BIG;
+break;
+}
+if ( __copy_to_guest_offset(buffer, ctxt.n, e820.map + i, 1) )
+return -EFAULT;
 }
-if ( __copy_to_guest_offset(buffer, ctxt.n, e820.map + i, 1) )
-return -EFAULT;
 ctxt.s = PFN_UP(e820.map[i].addr + e820.map[i].size);
 }
 
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 20df769..2a61e11 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -341,6 +341,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_memory_map_t);
  * XENMEM_memory_map.
  * In case of a buffer not capable to hold all entries of the physical
  * memory map -E2BIG is returned and the buffer is filled completely.
+ * Specifying buffer as NULL will return the number of entries required
+ * to store the complete memory map.
  * arg == addr of xen_memory_map_t.
  */
 #define XENMEM_machine_memory_map   10
-- 
2.10.2


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

[Xen-devel] [PATCH 0/2] xen: modify dom0 interface for obtaining memory map

[Juergen Gross]

Today's interface to get the machine memory map in dom0 requires to
know in advance how large the final map will be. There is however no
way to either get only a part of the memory map or to ask the
hypervisor about its size.

This patch set enhances the XENMEM_machine_memory_map hypercall to
solve both issues by returning only a partial memory map in case the
supplied buffer was too small and to return the needed number of
entries if no buffer is being supplied.

Juergen Gross (2):
  xen/x86: return partial memory map in case of not enough space
  xen/x86: add a way to obtain the needed number of memory map entries

 xen/arch/x86/mm.c   | 52 +++--
 xen/include/public/memory.h |  4 
 2 files changed, 35 insertions(+), 21 deletions(-)

-- 
2.10.2


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

[Xen-devel] [PATCH 1/2] xen/x86: return partial memory map in case of not enough space

[Juergen Gross]

For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
caller's buffer can't hold all entries.

This is a problem as the caller has normally a static buffer defined
and when he is doing the call no dynamic memory allocation is
possible as nothing is yet known about the system's memory layout.

Instead of just fail deliver as many memory map entries as possible
and return with E2BIG indicating the result was incomplete. Then the
caller will be capable to use at least some memory reported to exist
to allocate a larger buffer for the complete memory map.

As E2BIG wasn't returned before a caller not prepared for this case
will still see just a failure as before, while someone prepared for
this error code running on an old hypervisor won't run into problems
other than without this change.

Signed-off-by: Juergen Gross 
---
 xen/arch/x86/mm.c   | 22 --
 xen/include/public/memory.h |  2 ++
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 14552a1..f8e679d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4737,7 +4737,7 @@ static int _handle_iomem_range(unsigned long s, unsigned 
long e,
 XEN_GUEST_HANDLE(e820entry_t) buffer;
 
 if ( ctxt->n + 1 >= ctxt->map.nr_entries )
-return -EINVAL;
+return -E2BIG;
 ent.addr = (uint64_t)ctxt->s << PAGE_SHIFT;
 ent.size = (uint64_t)(s - ctxt->s) << PAGE_SHIFT;
 ent.type = E820_RESERVED;
@@ -4985,8 +4985,6 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 if ( copy_from_guest(, arg, 1) )
 return -EFAULT;
-if ( ctxt.map.nr_entries < e820.nr_map + 1 )
-return -EINVAL;
 
 buffer_param = guest_handle_cast(ctxt.map.buffer, e820entry_t);
 buffer = guest_handle_from_param(buffer_param, e820entry_t);
@@ -5005,31 +5003,35 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( !rc )
 rc = handle_iomem_range(s, s, );
 if ( rc )
-return rc;
+break;
+}
+if ( ctxt.map.nr_entries <= ctxt.n + 1 )
+{
+rc = -E2BIG;
+break;
 }
-if ( ctxt.map.nr_entries <= ctxt.n + (e820.nr_map - i) )
-return -EINVAL;
 if ( __copy_to_guest_offset(buffer, ctxt.n, e820.map + i, 1) )
 return -EFAULT;
 ctxt.s = PFN_UP(e820.map[i].addr + e820.map[i].size);
 }
 
-if ( ctxt.s )
+if ( !rc && ctxt.s )
 {
 rc = rangeset_report_ranges(current->domain->iomem_caps, ctxt.s,
 ~0UL, handle_iomem_range, );
 if ( !rc && ctxt.s )
 rc = handle_iomem_range(~0UL, ~0UL, );
-if ( rc )
-return rc;
 }
 
+if ( rc && rc != -E2BIG )
+return rc;
+
 ctxt.map.nr_entries = ctxt.n;
 
 if ( __copy_to_guest(arg, , 1) )
 return -EFAULT;
 
-return 0;
+return rc;
 }
 
 case XENMEM_machphys_mapping:
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 5bf840f..20df769 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -339,6 +339,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_memory_map_t);
 /*
  * Returns the real physical memory map. Passes the same structure as
  * XENMEM_memory_map.
+ * In case of a buffer not capable to hold all entries of the physical
+ * memory map -E2BIG is returned and the buffer is filled completely.
  * arg == addr of xen_memory_map_t.
  */
 #define XENMEM_machine_memory_map   10
-- 
2.10.2


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

Re: [Xen-devel] [PATCH 5/8] x86/hvm: Don't raise #GP behind the emulators back for MSR accesses

[Andrew Cooper]

On 05/12/16 12:10, Jan Beulich wrote:
 On 05.12.16 at 11:09,  wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -509,7 +509,11 @@ void hvm_do_resume(struct vcpu *v)
>>  
>>  if ( w->do_write.msr )
>>  {
>> -hvm_msr_write_intercept(w->msr, w->value, 0);
>> +int rc = hvm_msr_write_intercept(w->msr, w->value, 0);
>> +
>> +if ( rc == X86EMUL_EXCEPTION )
>> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> The use of a local variable looks kind of pointless here.

The first version had

if ( hvm_msr_write_intercept(w->msr, w->value, 0) ==
 X86EMUL_EXCEPTION )

but this looked rather ugly to read.  I prefer the version as submitted,
but am not too fussed if you insist for the latter?

>
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1788,7 +1788,6 @@ static int svm_msr_read_intercept(unsigned int msr, 
>> uint64_t *msr_content)
>>  return X86EMUL_OKAY;
>>  
>>   gpf:
>> -hvm_inject_hw_exception(TRAP_gp_fault, 0);
>>  return X86EMUL_EXCEPTION;
>>  }
>>  
>> @@ -1945,7 +1944,6 @@ static int svm_msr_write_intercept(unsigned int msr, 
>> uint64_t msr_content)
>>  return result;
>>  
>>   gpf:
>> -hvm_inject_hw_exception(TRAP_gp_fault, 0);
>>  return X86EMUL_EXCEPTION;
>>  }
> In cases like these it would certainly be nice to get rid of the now
> rather pointless goto-s, but of course we can equally well do this
> in a later patch.

I will do a cleanup patch and add it to v2.

~Andrew

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

[Xen-devel] [xen-4.5-testing test] 102905: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-4   52 leak-check/check fail REGR. vs. 102721
 test-xtf-amd64-amd64-1   52 leak-check/check fail REGR. vs. 102721
 test-xtf-amd64-amd64-5   52 leak-check/check fail REGR. vs. 102721
 test-xtf-amd64-amd64-2   52 leak-check/check fail REGR. vs. 102721
 test-xtf-amd64-amd64-3   52 leak-check/check fail REGR. vs. 102721

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail in 102855 pass in 102905
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 102855 
pass in 102905
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
pass in 102855
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-localmigrate   fail pass in 102855
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install   fail pass in 102855

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 102721
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 102721
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 102855 
blocked in 102721
 test-armhf-armhf-xl-rtds 11 guest-start fail in 102855 like 102721
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
102855 like 102721
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 102721
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102721
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102721
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102721
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102721

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-2   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 

Re: [Xen-devel] [PATCH] xen: convert lto to Kconfig option

[Wei Liu]

On Mon, Dec 05, 2016 at 08:58:20AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 16:27,  wrote:
> > On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote:
> >> On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote:
> >> > >>> On 05.12.16 at 15:39,  wrote:
> >> > > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
> >> > > converted to Kconfig, delete the preceding comment in Rules.mk as well.
> >> > > 
> >> > > Make it depend on BROKEN because it doesn't work at the moment.
> >> > 
> >> > Looks fine except for this one aspect: Is that brokenness with gcc,
> >> > clang, or both? I wouldn't be surprised if it was broken with gcc (in
> >> 
> >> It's going to be both.
> >> 
> >> Its build rune is broken.
> >> 
> >> I got:
> >> 
> >>   head.S:212:0: fatal error: opening dependency file /..d: Permission 
> >> denied
> >> 
> >> That is, this rule
> >> 
> >>   CFLAGS-y += -MMD -MF $(@D)/.$(@F).d  
> >>  
> >   
> >> 
> >> is evaluated too early outside of prerequisite list, which results in
> >> empty string.
> >> 
> > 
> > Sorry, "evaluated too early outside ..." is non-sense. I will just copy
> > the manpage for automatic variables from Make:
> > 
> > "In particular, you cannot use them anywhere within the target list of a
> > rule; they have no value there and will expand to the empty string.
> > Also, they cannot be accessed directly within the prerequisite list of a
> > rule. A common mistake is attempting to use $@ within the prerequisites
> > list; this will not work."
> > 
> > The "empty string" part in my description is accurate though.
> 
> And iirc we've run into the issue (in a less destructive way) before
> (even more than once), and do some filtering of CFLAGS in a few
> places. Apparently we've missed one (or more) ...
> 
> Anyway - feel free to put in the patch with my ack, as it certainly
> doesn't really alter the status quo here.
> 

Thanks!

> Jan
> 

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

Re: [Xen-devel] [PATCH] xen: convert lto to Kconfig option

[Jan Beulich]

>>> On 05.12.16 at 16:27,  wrote:
> On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote:
>> On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote:
>> > >>> On 05.12.16 at 15:39,  wrote:
>> > > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
>> > > converted to Kconfig, delete the preceding comment in Rules.mk as well.
>> > > 
>> > > Make it depend on BROKEN because it doesn't work at the moment.
>> > 
>> > Looks fine except for this one aspect: Is that brokenness with gcc,
>> > clang, or both? I wouldn't be surprised if it was broken with gcc (in
>> 
>> It's going to be both.
>> 
>> Its build rune is broken.
>> 
>> I got:
>> 
>>   head.S:212:0: fatal error: opening dependency file /..d: Permission denied
>> 
>> That is, this rule
>> 
>>   CFLAGS-y += -MMD -MF $(@D)/.$(@F).d
>>
>   
>> 
>> is evaluated too early outside of prerequisite list, which results in
>> empty string.
>> 
> 
> Sorry, "evaluated too early outside ..." is non-sense. I will just copy
> the manpage for automatic variables from Make:
> 
> "In particular, you cannot use them anywhere within the target list of a
> rule; they have no value there and will expand to the empty string.
> Also, they cannot be accessed directly within the prerequisite list of a
> rule. A common mistake is attempting to use $@ within the prerequisites
> list; this will not work."
> 
> The "empty string" part in my description is accurate though.

And iirc we've run into the issue (in a less destructive way) before
(even more than once), and do some filtering of CFLAGS in a few
places. Apparently we've missed one (or more) ...

Anyway - feel free to put in the patch with my ack, as it certainly
doesn't really alter the status quo here.

Jan


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

Re: [Xen-devel] [PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready

[Juergen Gross]

On 05/12/16 16:32, Boris Ostrovsky wrote:
> On 12/02/2016 01:15 AM, Juergen Gross wrote:
>>  
>> -static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info 
>> *info)
>> +static int scsifront_do_request(struct vscsifrnt_info *info,
>> +struct vscsifrnt_shadow *shadow)
>>  {
>>  struct vscsiif_front_ring *ring = &(info->ring);
>>  struct vscsiif_request *ring_req;
>> +struct scsi_cmnd *sc = shadow->sc;
>>  uint32_t id;
>> +int i, notify;
>> +
>> +if (RING_FULL(>ring))
>> +return -EBUSY;
>>  
>>  id = scsifront_get_rqid(info);  /* use id in response */
>>  if (id >= VSCSIIF_MAX_REQS)
>> -return NULL;
>> +return -EBUSY;
>> +
>> +info->shadow[id] = shadow;
>> +shadow->rqid = id;
>>  
>>  ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
>> -
>>  ring->req_prod_pvt++;
>>  
>> -ring_req->rqid = (uint16_t)id;
>> +ring_req->rqid= id;
>> +ring_req->act = shadow->act;
>> +ring_req->ref_rqid= shadow->ref_rqid;
>> +ring_req->nr_segments = shadow->nr_segments;
> 
> Shouldn't req_prod_pvt be incremented after you've copied everything? (I
> realize that there is not error until everything has been copied but still.)

That doesn't really matter as it is private.

>> @@ -473,44 +496,14 @@ static int map_data_for_request(struct vscsifrnt_info 
>> *info,
>>  }
>>  
>>  if (seg_grants)
>> -ring_req->nr_segments = VSCSIIF_SG_GRANT | seg_grants;
>> +shadow->nr_segments = VSCSIIF_SG_GRANT | seg_grants;
> 
> Are we guaranteed that seg_grants is not going to have VSCSIIF_SG_GRANT
> bit set?

Absolutely, yes. Can't be larger than VSCSIIF_SG_TABLESIZE which is 26.


Juergen

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

Re: [Xen-devel] [PATCH v3 1/5] tools/libacpi: add _FADT_ to the FADT boot flags definitions

[Wei Liu]

On Mon, Dec 05, 2016 at 03:04:53PM +, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné 
> ---

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready

[Boris Ostrovsky]

On 12/02/2016 01:15 AM, Juergen Gross wrote:
>  
> -static struct vscsiif_request *scsifront_pre_req(struct vscsifrnt_info *info)
> +static int scsifront_do_request(struct vscsifrnt_info *info,
> + struct vscsifrnt_shadow *shadow)
>  {
>   struct vscsiif_front_ring *ring = &(info->ring);
>   struct vscsiif_request *ring_req;
> + struct scsi_cmnd *sc = shadow->sc;
>   uint32_t id;
> + int i, notify;
> +
> + if (RING_FULL(>ring))
> + return -EBUSY;
>  
>   id = scsifront_get_rqid(info);  /* use id in response */
>   if (id >= VSCSIIF_MAX_REQS)
> - return NULL;
> + return -EBUSY;
> +
> + info->shadow[id] = shadow;
> + shadow->rqid = id;
>  
>   ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
> -
>   ring->req_prod_pvt++;
>  
> - ring_req->rqid = (uint16_t)id;
> + ring_req->rqid= id;
> + ring_req->act = shadow->act;
> + ring_req->ref_rqid= shadow->ref_rqid;
> + ring_req->nr_segments = shadow->nr_segments;

Shouldn't req_prod_pvt be incremented after you've copied everything? (I
realize that there is not error until everything has been copied but still.)



> @@ -473,44 +496,14 @@ static int map_data_for_request(struct vscsifrnt_info 
> *info,
>   }
>  
>   if (seg_grants)
> - ring_req->nr_segments = VSCSIIF_SG_GRANT | seg_grants;
> + shadow->nr_segments = VSCSIIF_SG_GRANT | seg_grants;

Are we guaranteed that seg_grants is not going to have VSCSIIF_SG_GRANT
bit set?

-boris




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

Re: [Xen-devel] [PATCH] xen: convert lto to Kconfig option

[Wei Liu]

On Mon, Dec 05, 2016 at 03:22:30PM +, Wei Liu wrote:
> On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote:
> > >>> On 05.12.16 at 15:39,  wrote:
> > > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
> > > converted to Kconfig, delete the preceding comment in Rules.mk as well.
> > > 
> > > Make it depend on BROKEN because it doesn't work at the moment.
> > 
> > Looks fine except for this one aspect: Is that brokenness with gcc,
> > clang, or both? I wouldn't be surprised if it was broken with gcc (in
> 
> It's going to be both.
> 
> Its build rune is broken.
> 
> I got:
> 
>   head.S:212:0: fatal error: opening dependency file /..d: Permission denied
> 
> That is, this rule
> 
>   CFLAGS-y += -MMD -MF $(@D)/.$(@F).d 
> 
> 
> is evaluated too early outside of prerequisite list, which results in
> empty string.
> 

Sorry, "evaluated too early outside ..." is non-sense. I will just copy
the manpage for automatic variables from Make:

"In particular, you cannot use them anywhere within the target list of a
rule; they have no value there and will expand to the empty string.
Also, they cannot be accessed directly within the prerequisite list of a
rule. A common mistake is attempting to use $@ within the prerequisites
list; this will not work."

The "empty string" part in my description is accurate though.

> Also I'm sure gcc can't deal with lto because at one point I tried to
> fix lto but gcc  toolchain can't cope with that.
> 
> > fact I would be surprised it has ever worked), but I would have
> > hoped that the clang variant (which iirc this was introduced for)
> > would work (also e.g. in 4.8).
> > 
> 
> I haven't tried clang, because the brokenness is somewhere else.
> 
> Wei.
> 
> > Jan
> > 

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

Re: [Xen-devel] [PATCH] xen: convert lto to Kconfig option

[Wei Liu]

On Mon, Dec 05, 2016 at 08:05:35AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 15:39,  wrote:
> > Introduce CONFIG_LTO in Kconfig. Since this is the last option to be
> > converted to Kconfig, delete the preceding comment in Rules.mk as well.
> > 
> > Make it depend on BROKEN because it doesn't work at the moment.
> 
> Looks fine except for this one aspect: Is that brokenness with gcc,
> clang, or both? I wouldn't be surprised if it was broken with gcc (in

It's going to be both.

Its build rune is broken.

I got:

  head.S:212:0: fatal error: opening dependency file /..d: Permission denied

That is, this rule

  CFLAGS-y += -MMD -MF $(@D)/.$(@F).d   
  

is evaluated too early outside of prerequisite list, which results in
empty string.

Also I'm sure gcc can't deal with lto because at one point I tried to
fix lto but gcc  toolchain can't cope with that.

> fact I would be surprised it has ever worked), but I would have
> hoped that the clang variant (which iirc this was introduced for)
> would work (also e.g. in 4.8).
> 

I haven't tried clang, because the brokenness is somewhere else.

Wei.

> Jan
> 

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

[Xen-devel] [PATCH v3 3/5] tools/libacpi: don't announce a 8042 controller in the FADT for PVHv2 guests

[Roger Pau Monne]

There's no such controler available for PVHv2 guests.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
 tools/firmware/hvmloader/util.c | 2 +-
 tools/libacpi/build.c   | 2 ++
 tools/libacpi/libacpi.h | 1 +
 tools/libacpi/static_tables.c   | 1 -
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 3e192bf..3f86c88 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -949,7 +949,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
 config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET |
-ACPI_HAS_VGA);
+ACPI_HAS_VGA | ACPI_HAS_8042);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 8799e2c..844dea1 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -581,6 +581,8 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 fadt->x_firmware_ctrl = ctxt->mem_ops.v2p(ctxt, facs);
 if ( !(config->table_flags & ACPI_HAS_VGA) )
 fadt->iapc_boot_arch |= ACPI_FADT_NO_VGA;
+if ( config->table_flags & ACPI_HAS_8042 )
+fadt->iapc_boot_arch |= ACPI_FADT_8042;
 set_checksum(fadt,
  offsetof(struct acpi_header, checksum),
  sizeof(struct acpi_20_fadt));
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index d7ea6e1..e0f1537 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -31,6 +31,7 @@
 #define ACPI_HAS_IOAPIC  (1<<8)
 #define ACPI_HAS_WAET(1<<9)
 #define ACPI_HAS_VGA (1<<10)
+#define ACPI_HAS_8042(1<<11)
 
 struct xen_vmemrange;
 struct acpi_numa {
diff --git a/tools/libacpi/static_tables.c b/tools/libacpi/static_tables.c
index 2659153..1f6247d 100644
--- a/tools/libacpi/static_tables.c
+++ b/tools/libacpi/static_tables.c
@@ -63,7 +63,6 @@ struct acpi_20_fadt Fadt = {
 
 .p_lvl2_lat = 0x0fff, /* >100,  means we do not support C2 state */
 .p_lvl3_lat = 0x0fff, /* >1000, means we do not support C3 state */
-.iapc_boot_arch = ACPI_FADT_8042,
 .flags = (ACPI_PROC_C1 |
   ACPI_WBINVD |
   ACPI_FIX_RTC | ACPI_TMR_VAL_EXT |
-- 
2.9.3 (Apple Git-75)


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

[Xen-devel] [PATCH v3 2/5] tools/libacpi: set FADT boot flag to notify lack of VGA for PVHv2 guests

[Roger Pau Monne]

PVHv2 guests don't have any VGA card, and as so it must be notified in the FADT.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
 tools/firmware/hvmloader/util.c | 3 ++-
 tools/libacpi/acpi2_0.h | 1 +
 tools/libacpi/build.c   | 2 ++
 tools/libacpi/libacpi.h | 1 +
 4 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 6e0cfe7..3e192bf 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -948,7 +948,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET |
+ACPI_HAS_VGA);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
index 03c5dcb..500f95e 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -229,6 +229,7 @@ struct acpi_20_fadt {
  */
 #define ACPI_FADT_LEGACY_DEVICES(1 << 0)
 #define ACPI_FADT_8042  (1 << 1)
+#define ACPI_FADT_NO_VGA(1 << 2)
 
 /*
  * FADT Fixed Feature Flags.
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 47dae01..8799e2c 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -579,6 +579,8 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
 fadt->firmware_ctrl   = ctxt->mem_ops.v2p(ctxt, facs);
 fadt->x_firmware_ctrl = ctxt->mem_ops.v2p(ctxt, facs);
+if ( !(config->table_flags & ACPI_HAS_VGA) )
+fadt->iapc_boot_arch |= ACPI_FADT_NO_VGA;
 set_checksum(fadt,
  offsetof(struct acpi_header, checksum),
  sizeof(struct acpi_20_fadt));
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 1d388f9..d7ea6e1 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -30,6 +30,7 @@
 #define ACPI_HAS_TCPA(1<<7)
 #define ACPI_HAS_IOAPIC  (1<<8)
 #define ACPI_HAS_WAET(1<<9)
+#define ACPI_HAS_VGA (1<<10)
 
 struct xen_vmemrange;
 struct acpi_numa {
-- 
2.9.3 (Apple Git-75)


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

[Xen-devel] [PATCH v3 1/5] tools/libacpi: add _FADT_ to the FADT boot flags definitions

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
Changes since v2:
 - Fix usage of ACPI_8042 in the static boot tables.
---
 tools/libacpi/acpi2_0.h   | 4 ++--
 tools/libacpi/static_tables.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
index 775eb7a..03c5dcb 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -227,8 +227,8 @@ struct acpi_20_fadt {
 /*
  * FADT Boot Architecture Flags.
  */
-#define ACPI_LEGACY_DEVICES (1 << 0)
-#define ACPI_8042   (1 << 1)
+#define ACPI_FADT_LEGACY_DEVICES(1 << 0)
+#define ACPI_FADT_8042  (1 << 1)
 
 /*
  * FADT Fixed Feature Flags.
diff --git a/tools/libacpi/static_tables.c b/tools/libacpi/static_tables.c
index 617bf68..2659153 100644
--- a/tools/libacpi/static_tables.c
+++ b/tools/libacpi/static_tables.c
@@ -63,7 +63,7 @@ struct acpi_20_fadt Fadt = {
 
 .p_lvl2_lat = 0x0fff, /* >100,  means we do not support C2 state */
 .p_lvl3_lat = 0x0fff, /* >1000, means we do not support C3 state */
-.iapc_boot_arch = ACPI_8042,
+.iapc_boot_arch = ACPI_FADT_8042,
 .flags = (ACPI_PROC_C1 |
   ACPI_WBINVD |
   ACPI_FIX_RTC | ACPI_TMR_VAL_EXT |
-- 
2.9.3 (Apple Git-75)


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

Re: [Xen-devel] [PATCH v3 1/5] tools/libacpi: add _FADT_ to the FADT boot flags definitions

[Andrew Cooper]

On 05/12/16 15:04, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v3 4/5] tools/libacpi: update FADT layout to support version 5

[Roger Pau Monne]

Update the structure of the FADT table to version 5, and use that version for
PVHv2 guests. Note that HVM guests will continue to use FADT 4.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: boris.ostrov...@oracle.com
Cc: konrad.w...@oracle.com
---
 tools/firmware/hvmloader/util.c |  2 +-
 tools/libacpi/acpi2_0.h |  9 ++---
 tools/libacpi/build.c   | 24 ++--
 tools/libacpi/libacpi.h |  1 +
 tools/libacpi/static_tables.c   |  8 
 5 files changed, 30 insertions(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 3f86c88..5dbb448 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -949,7 +949,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
 config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET |
-ACPI_HAS_VGA | ACPI_HAS_8042);
+ACPI_HAS_VGA | ACPI_HAS_8042 | ACPI_FADT_4);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
index 500f95e..b8ef777 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -169,7 +169,7 @@ struct acpi_10_fadt {
 /*
  * Fixed ACPI Description Table Structure (FADT).
  */
-struct acpi_20_fadt {
+struct acpi_50_fadt {
 struct acpi_header header;
 uint32_t firmware_ctrl;
 uint32_t dsdt;
@@ -222,6 +222,8 @@ struct acpi_20_fadt {
 struct acpi_20_generic_address x_pm_tmr_blk;
 struct acpi_20_generic_address x_gpe0_blk;
 struct acpi_20_generic_address x_gpe1_blk;
+struct acpi_20_generic_address sleep_control;
+struct acpi_20_generic_address sleep_status;
 };
 
 /*
@@ -422,7 +424,7 @@ struct acpi_20_slit {
  */
 #define ACPI_2_0_RSDP_SIGNATURE ASCII64('R','S','D',' ','P','T','R',' ')
 #define ACPI_2_0_FACS_SIGNATURE ASCII32('F','A','C','S')
-#define ACPI_2_0_FADT_SIGNATURE ASCII32('F','A','C','P')
+#define ACPI_FADT_SIGNATURE ASCII32('F','A','C','P')
 #define ACPI_2_0_MADT_SIGNATURE ASCII32('A','P','I','C')
 #define ACPI_2_0_RSDT_SIGNATURE ASCII32('R','S','D','T')
 #define ACPI_2_0_XSDT_SIGNATURE ASCII32('X','S','D','T')
@@ -436,7 +438,8 @@ struct acpi_20_slit {
  * Table revision numbers.
  */
 #define ACPI_2_0_RSDP_REVISION 0x02
-#define ACPI_2_0_FADT_REVISION 0x04
+#define ACPI_4_0_FADT_REVISION 0x04
+#define ACPI_5_0_FADT_REVISION 0x05
 #define ACPI_2_0_MADT_REVISION 0x02
 #define ACPI_2_0_RSDT_REVISION 0x01
 #define ACPI_2_0_XSDT_REVISION 0x01
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 844dea1..eb40989 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -503,12 +503,13 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 struct acpi_20_rsdp *rsdp;
 struct acpi_20_rsdt *rsdt;
 struct acpi_20_xsdt *xsdt;
-struct acpi_20_fadt *fadt;
+struct acpi_50_fadt *fadt;
 struct acpi_10_fadt *fadt_10;
 struct acpi_20_facs *facs;
 unsigned char   *dsdt;
 unsigned longsecondary_tables[ACPI_MAX_SECONDARY_TABLES];
 int  nr_secondaries, i;
+unsigned longfadt_size;
 
 acpi_info = (struct acpi_info *)config->infop;
 memset(acpi_info, 0, sizeof(*acpi_info));
@@ -572,9 +573,16 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
  offsetof(struct acpi_header, checksum),
  sizeof(struct acpi_10_fadt));
 
-fadt = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_fadt), 16);
+/*
+ * NB: we can use offsetof because there's no padding between
+ * x_gpe1_blk and sleep_control.
+ */
+fadt_size = config->table_flags & ACPI_FADT_4 ?
+offsetof(struct acpi_50_fadt, sleep_control) :
+sizeof(struct acpi_50_fadt);
+fadt = ctxt->mem_ops.alloc(ctxt, fadt_size, 16);
 if (!fadt) goto oom;
-memcpy(fadt, , sizeof(struct acpi_20_fadt));
+memcpy(fadt, , fadt_size);
 fadt->dsdt   = ctxt->mem_ops.v2p(ctxt, dsdt);
 fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
 fadt->firmware_ctrl   = ctxt->mem_ops.v2p(ctxt, facs);
@@ -583,9 +591,13 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 fadt->iapc_boot_arch |= ACPI_FADT_NO_VGA;
 if ( config->table_flags & ACPI_HAS_8042 )
 fadt->iapc_boot_arch |= ACPI_FADT_8042;
-set_checksum(fadt,
- offsetof(struct acpi_header, checksum),
- sizeof(struct acpi_20_fadt));
+
+if ( config->table_flags & ACPI_FADT_4 )
+{
+fadt->header.revision = ACPI_4_0_FADT_REVISION;
+fadt->header.length = fadt_size;
+}
+set_checksum(fadt,