Re: [Xen-devel] qemu-upstream triggering OOM killer

[Anthony PERARD]

On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote:
> >>> On 09.02.17 at 23:24,  wrote:
> > On Thu, 9 Feb 2017, Jan Beulich wrote:
> >> the recent qemuu update results in the produced binary triggering the
> >> OOM killer on the first system I tried the updated code on. Is there
> >> anything known in this area? Are there any hints as to finding out
> >> what is going wrong?
> > 
> > Do you mean QEMU upstream (from qemu.org) or qemu-xen/staging (that
> > hasn't changed much in the last couple of months)?
> 
> The latter. The diff to my last snapshot (from early January) is 6.6Mb
> though - I wouldn't call this "hasn't changed much". Looks like Anthony
> did update to 2.8.0 in early January (a day or two after I had last
> snapshotted it).

Yes, I did the update.

> > Do you know if it's something Xen specific?
> 
> Not so far. It appears to happen when grub clears the screen
> before displaying its graphical menu, so I'd rather suspect an issue
> with a graphics related change (the one you pointed out isn't).

I tried to reproduce this, by limiting the amount of memory available to
qemu using cgroups, but about 44MB of memory is enough to boot a guest
(tried Ubuntu and Debian).

How much memory did qemu try to use?
What guest did you try to boot?
What the xl configuration?

-- 
Anthony PERARD

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

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

[Julien Grall]

Hi,

On 01/26/2017 09:11 PM, Julien Grall wrote:

Hi,

On 26/01/2017 19:01, Boris Ostrovsky wrote:

On 01/26/2017 12:18 PM, Ian Jackson wrote:

Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684:
regressions - FAIL"):

On 01/26/2017 08:23 AM, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs.
59254

...

I don't see why ARM tests fail. But then I also don't see (in the
serial
log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
but there it nothing coming to the console from it.

Yes.

Unfortunately the osstest bisector is having some trouble with this
because the basis revision combination includes Xen f3a7ca02400d which
is ancient and doesn't build now on armhf, although it built before.
(I think the difference is that the compiler has been updated by
Debian.)

Since there is no output from Xen, I think this must be a problem with
the Xen image, not anything to do with Linux.

The history for this test is here:

http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus


In xen-unstable, there is what looks like a different failure:

http://logs.test-lab.xenproject.org/osstest/logs/104681/test-armhf-armhf-xl/serial-arndale-westfield.log


The machine in 104684 is cubietruck-metzinger which seems fine:

http://logs.test-lab.xenproject.org/osstest/results/host/cubietruck-metzinger.html



I am probably not interpreting  results correctly but 104684 looks like
failed to me:

http://logs.test-lab.xenproject.org/osstest/logs/104684/test-armhf-armhf-xl/info.html


And 104681's failure looks exactly like 104684.


I agree here. I think Ian got confused because the cubietruck is used to
build Xen.



Here are the histories on the linux-linus and xen-unstable branches:

http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus


http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable


I think there may be a host-specific bug in ARM in xen-unstable ?


So the problem with linux-linus is the path in the DeviceTree for the
serial has been changed by commit 5d99cc5 "ARM: dts: exynos: Move
Exynos5250 and Exynos5420 nodes under soc". Before the path was
/serial@12C2, now it is /soc/serial@12C2.

From my understanding, osstest is testing 3.18 and onwards. Correct?

If so, all the device tree we care have the same alias name to the
serial node. I would use it to get avoid specific command line option
depending on the kernel.

Replacing on xen command line "dtuart=/serial@12C2" by
"dtuart=serial0" will allow Xen to be able to use again the console.


I have looked at osstest git [1] and was not able to find where the 
configuration for the Arndale.


Can someone knowing Osstest look at it? This would unblock linux-linus 
test on ARM.




Regarding xen-unstable, I spot in the log a lot of "asix 2-3.2.4:1.0
eth0: link down". So this looks like an ethernet issue. IIRC the network
dongle on the Arndale has always been unreliable. So I would not worry
too much here and wait the next flight.


Cheers,

[1] http://xenbits.xen.org/gitweb/?p=osstest.git;a=summary

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

[George Dunlap]

On 13/02/17 11:00, Andrew Cooper wrote:
> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be
> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
> backpointer.
> 
> However, plenty of hardware has a physical address width less that 44 bits,
> and the code added in shadow_domain_init() is a straight assignment.  This
> causes gfn_bits to be increased beyond the physical address width on most
> Intel consumer hardware (typically a width of 39, which is the number reported
> to the guest via CPUID).
> 
> If the guest intentionally creates a PTE referencing a physical address
> between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
> address.  However, the shadow code accepts the PTE, shadows it, and the
> virtual address works normally.
> 
> Introduce paging_max_paddr_bits() to calculate the largest guest physical
> address supportable by the paging infrastructure, and update
> recalculate_cpuid_policy() to take this into account when clamping the guests
> cpuid_policy to reality.  Remove gfn_bits and rework its users in terms of a
> guests maxphysaddr.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: George Dunlap 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> 
> v2:
>  * Introduce paging_max_paddr_bits() rather than moving paging logic into
>recalculate_cpuid_policy().
>  * Rewrite half of the commit message.
> ---
>  xen/arch/x86/cpuid.c|  7 +++
>  xen/arch/x86/hvm/vmx/vvmx.c |  2 +-
>  xen/arch/x86/mm/guest_walk.c|  3 ++-
>  xen/arch/x86/mm/hap/hap.c   |  2 --
>  xen/arch/x86/mm/p2m.c   |  3 ++-
>  xen/arch/x86/mm/shadow/common.c | 10 --
>  xen/arch/x86/mm/shadow/multi.c  |  3 ++-
>  xen/include/asm-x86/domain.h|  3 ---
>  xen/include/asm-x86/paging.h| 16 
>  9 files changed, 26 insertions(+), 23 deletions(-)
> 
> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index e0a387e..3378f7a 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>  
>  cpuid_featureset_to_policy(fs, p);
>  
> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>  p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
> -d->arch.paging.gfn_bits + PAGE_SHIFT);
> -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
> -(p->basic.pae || p->basic.pse36) ? 36 : 32);
> +paging_max_paddr_bits(d));
> +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
>  
>  p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>  
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 9c61b5b..774a11f 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
>  }
>  
>  if ( (gpa & ~PAGE_MASK) ||
> - (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
> + (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
>  {
>  vmfail_invalid(regs);
>  return X86EMUL_OKAY;
> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
> index a67fd5a..5ad8cf6 100644
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>  /* If this guest has a restricted physical address space then the
>   * target GFN must fit within it. */
>  if ( !(rc & _PAGE_PRESENT)
> - && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
> + && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
> + (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )

This pattern, of taking a gfn and shifting it by
(cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
several times; it seems like for both clarity and avoiding mistakes, it
would be better if it were put into a macro.

Everything else looks good to me.  (No opinion on the other questions
raised so far.)

 -George


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

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

[Daniel Kiper]

..calculating its value during runtime.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
 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 525ce7a..a5ce926 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 v15 09/10] 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 
Reviewed-by: Doug Goldstein 
---
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 4fbf776..ebcc28b 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 Multiboot2 entry point. */
 mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
-   sym_phys(__efi64_mb2_start)
+   sym_offs(__efi64_mb2_start)
 
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -119,7 +119,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 */
 
 vga_text_buffer:
@@ -131,23 +131,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:
@@ -358,7 +358,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
@@ -538,8 +538,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
@@ -612,22 +612,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. */
@@ -653,7 +653,7 @@ trampoline_setup:
 push%eax
 
 /* Copy bootstrap 

[Xen-devel] [PATCH v15 10/10] 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 
Reviewed-by: Doug Goldstein 
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
  (suggested by Doug Goldstein).

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 ebcc28b..b2601a7 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
@@ -390,6 +397,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 87e573a..85639e4 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 a3e3119..5acd225 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
 #define MULTIBOOT2_HEADER_TAG_EFI_BS7
 #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_NONE 0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW  1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH 2
+
 /* Header console tag console_flags. */
 #define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED   1
 #define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
@@ -90,6 +96,7 @@
 #define MULTIBOOT2_TAG_TYPE_EFI_BS  18
 #define MULTIBOOT2_TAG_TYPE_EFI32_IH19
 #define MULTIBOOT2_TAG_TYPE_EFI64_IH20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR  21
 
 /* Multiboot 2 tag alignment. */
 #define MULTIBOOT2_TAG_ALIGN8
@@ -120,6 +127,12 @@ typedef struct {
 typedef struct {
 u32 

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

[Wei Liu]

On Tue, Feb 14, 2017 at 02:57:42PM +, Julien Grall wrote:
> Hi,
> 
> On 01/26/2017 09:11 PM, Julien Grall wrote:
> > Hi,
> > 
> > On 26/01/2017 19:01, Boris Ostrovsky wrote:
> > > On 01/26/2017 12:18 PM, Ian Jackson wrote:
> > > > Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684:
> > > > regressions - FAIL"):
> > > > > On 01/26/2017 08:23 AM, osstest service owner wrote:
> > > > > > flight 104684 linux-linus real [real]
> > > > > > http://logs.test-lab.xenproject.org/osstest/logs/104684/
> > > > > > 
> > > > > > Regressions :-(
> > > > > > 
> > > > > > Tests which did not succeed and are blocking,
> > > > > > including tests which could not be run:
> > > > > >  test-armhf-armhf-xl   6 xen-boot  fail REGR. vs.
> > > > > > 59254
> > > > ...
> > > > > I don't see why ARM tests fail. But then I also don't see (in the
> > > > > serial
> > > > > log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
> > > > > but there it nothing coming to the console from it.
> > > > Yes.
> > > > 
> > > > Unfortunately the osstest bisector is having some trouble with this
> > > > because the basis revision combination includes Xen f3a7ca02400d which
> > > > is ancient and doesn't build now on armhf, although it built before.
> > > > (I think the difference is that the compiler has been updated by
> > > > Debian.)
> > > > 
> > > > Since there is no output from Xen, I think this must be a problem with
> > > > the Xen image, not anything to do with Linux.
> > > > 
> > > > The history for this test is here:
> > > > 
> > > > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus
> > > > 
> > > > 
> > > > In xen-unstable, there is what looks like a different failure:
> > > > 
> > > > http://logs.test-lab.xenproject.org/osstest/logs/104681/test-armhf-armhf-xl/serial-arndale-westfield.log
> > > > 
> > > > 
> > > > The machine in 104684 is cubietruck-metzinger which seems fine:
> > > > 
> > > > http://logs.test-lab.xenproject.org/osstest/results/host/cubietruck-metzinger.html
> > > > 
> > > 
> > > I am probably not interpreting  results correctly but 104684 looks like
> > > failed to me:
> > > 
> > > http://logs.test-lab.xenproject.org/osstest/logs/104684/test-armhf-armhf-xl/info.html
> > > 
> > > 
> > > And 104681's failure looks exactly like 104684.
> > 
> > I agree here. I think Ian got confused because the cubietruck is used to
> > build Xen.
> > 
> > > > 
> > > > Here are the histories on the linux-linus and xen-unstable branches:
> > > > 
> > > > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus
> > > > 
> > > > 
> > > > http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable
> > > > 
> > > > 
> > > > I think there may be a host-specific bug in ARM in xen-unstable ?
> > 
> > So the problem with linux-linus is the path in the DeviceTree for the
> > serial has been changed by commit 5d99cc5 "ARM: dts: exynos: Move
> > Exynos5250 and Exynos5420 nodes under soc". Before the path was
> > /serial@12C2, now it is /soc/serial@12C2.
> > 
> > From my understanding, osstest is testing 3.18 and onwards. Correct?
> > 
> > If so, all the device tree we care have the same alias name to the
> > serial node. I would use it to get avoid specific command line option
> > depending on the kernel.
> > 
> > Replacing on xen command line "dtuart=/serial@12C2" by
> > "dtuart=serial0" will allow Xen to be able to use again the console.
> 
> I have looked at osstest git [1] and was not able to find where the
> configuration for the Arndale.
> 
> Can someone knowing Osstest look at it? This would unblock linux-linus test
> on ARM.
> 

(test-lab)liuw@osstest:~/testing.git$ ./mg-hosts showprops | grep DTUART | grep 
arndale
 arndale-bluewater  XenDTUARTPath  /serial@12C2
 arndale-lakeside   XenDTUARTPath  /serial@12C2
 arndale-metrocentre XenDTUARTPath  /serial@12C2
 arndale-westfield  XenDTUARTPath  /serial@12C2

That's a property of this kind of hosts in osstest. It needs to be
updated by the administrator (Ian).

Wei.

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

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

[Andrew Cooper]

On 14/02/17 17:42, George Dunlap wrote:
> On 13/02/17 11:00, Andrew Cooper wrote:
>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might 
>> be
>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
>> backpointer.
>>
>> However, plenty of hardware has a physical address width less that 44 bits,
>> and the code added in shadow_domain_init() is a straight assignment.  This
>> causes gfn_bits to be increased beyond the physical address width on most
>> Intel consumer hardware (typically a width of 39, which is the number 
>> reported
>> to the guest via CPUID).
>>
>> If the guest intentionally creates a PTE referencing a physical address
>> between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
>> address.  However, the shadow code accepts the PTE, shadows it, and the
>> virtual address works normally.
>>
>> Introduce paging_max_paddr_bits() to calculate the largest guest physical
>> address supportable by the paging infrastructure, and update
>> recalculate_cpuid_policy() to take this into account when clamping the guests
>> cpuid_policy to reality.  Remove gfn_bits and rework its users in terms of a
>> guests maxphysaddr.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Tim Deegan 
>> CC: George Dunlap 
>> CC: Jun Nakajima 
>> CC: Kevin Tian 
>>
>> v2:
>>  * Introduce paging_max_paddr_bits() rather than moving paging logic into
>>recalculate_cpuid_policy().
>>  * Rewrite half of the commit message.
>> ---
>>  xen/arch/x86/cpuid.c|  7 +++
>>  xen/arch/x86/hvm/vmx/vvmx.c |  2 +-
>>  xen/arch/x86/mm/guest_walk.c|  3 ++-
>>  xen/arch/x86/mm/hap/hap.c   |  2 --
>>  xen/arch/x86/mm/p2m.c   |  3 ++-
>>  xen/arch/x86/mm/shadow/common.c | 10 --
>>  xen/arch/x86/mm/shadow/multi.c  |  3 ++-
>>  xen/include/asm-x86/domain.h|  3 ---
>>  xen/include/asm-x86/paging.h| 16 
>>  9 files changed, 26 insertions(+), 23 deletions(-)
>>
>> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
>> index e0a387e..3378f7a 100644
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -6,6 +6,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>>  
>>  cpuid_featureset_to_policy(fs, p);
>>  
>> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>>  p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
>> -d->arch.paging.gfn_bits + PAGE_SHIFT);
>> -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
>> -(p->basic.pae || p->basic.pse36) ? 36 : 32);
>> +paging_max_paddr_bits(d));
>> +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
>>  
>>  p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>  
>> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
>> index 9c61b5b..774a11f 100644
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
>>  }
>>  
>>  if ( (gpa & ~PAGE_MASK) ||
>> - (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
>> + (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
>>  {
>>  vmfail_invalid(regs);
>>  return X86EMUL_OKAY;
>> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
>> index a67fd5a..5ad8cf6 100644
>> --- a/xen/arch/x86/mm/guest_walk.c
>> +++ b/xen/arch/x86/mm/guest_walk.c
>> @@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>>  /* If this guest has a restricted physical address space then the
>>   * target GFN must fit within it. */
>>  if ( !(rc & _PAGE_PRESENT)
>> - && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
>> + && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
>> + (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )
> This pattern, of taking a gfn and shifting it by
> (cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
> several times; it seems like for both clarity and avoiding mistakes, it
> would be better if it were put into a macro.
>
> Everything else looks good to me.  (No opinion on the other questions
> raised so far.)

static inline unsigned int gfn_bits(const struct domain *d)
{
return d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT;
}

?

I do like that idea.  It would certainly make all of the callsites more
readable.

I can happily fold that change in if others agree.

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Stefano Stabellini]

On Tue, 14 Feb 2017, Boris Ostrovsky wrote:
> On 02/13/2017 12:03 PM, Paul Durrant wrote:
> > Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> > for restricting device emulators (such as QEMU) to a limited set of
> > hypervisor operations, and being able to audit those operations in the
> > kernel of the domain in which they run.
> >
> > This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.
> >
> > NOTE: There is no requirement for user-space code to bounce data through
> >   locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
> >   privcmd has enough information to lock the original buffers
> >   directly.
> >
> > [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2
> >
> > Signed-off-by: Paul Durrant 
> 
> 
> Stefano,
> 
> Are you OK with ARM changes?

Yes:

Acked-by: Stefano Stabellini 

Thanks for CC'ing me, I missed the patch.



> 
> 
> > ---
> > Cc: Boris Ostrovsky 
> > Cc: Juergen Gross 
> >
> > v3:
> > - Add module parameters for max number of dm_op buffers and max buffer
> >   size
> > - Fix arm build
> > - Fix commit comment to reflect re-worked patch
> >
> > v2:
> > - Lock the user pages rather than bouncing through kernel memory
> > ---
> >  arch/arm/xen/enlighten.c |   1 +
> >  arch/arm/xen/hypercall.S |   1 +
> >  arch/arm64/xen/hypercall.S   |   1 +
> >  arch/x86/include/asm/xen/hypercall.h |   7 ++
> >  drivers/xen/privcmd.c| 139 
> > +++
> >  include/uapi/xen/privcmd.h   |  13 
> >  include/xen/arm/hypercall.h  |   1 +
> >  include/xen/interface/hvm/dm_op.h|  32 
> >  include/xen/interface/xen.h  |   1 +
> >  9 files changed, 196 insertions(+)
> >  create mode 100644 include/xen/interface/hvm/dm_op.h
> >
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 11d9f28..81e3217 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -457,4 +457,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
> >  EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
> >  EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
> >  EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> > +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> >  EXPORT_SYMBOL_GPL(privcmd_call);
> > diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> > index a648dfc..b0b80c0 100644
> > --- a/arch/arm/xen/hypercall.S
> > +++ b/arch/arm/xen/hypercall.S
> > @@ -92,6 +92,7 @@ HYPERCALL1(tmem_op);
> >  HYPERCALL1(platform_op_raw);
> >  HYPERCALL2(multicall);
> >  HYPERCALL2(vm_assist);
> > +HYPERCALL3(dm_op);
> >  
> >  ENTRY(privcmd_call)
> > stmdb sp!, {r4}
> > diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> > index 947830a..401ceb7 100644
> > --- a/arch/arm64/xen/hypercall.S
> > +++ b/arch/arm64/xen/hypercall.S
> > @@ -84,6 +84,7 @@ HYPERCALL1(tmem_op);
> >  HYPERCALL1(platform_op_raw);
> >  HYPERCALL2(multicall);
> >  HYPERCALL2(vm_assist);
> > +HYPERCALL3(dm_op);
> >  
> >  ENTRY(privcmd_call)
> > mov x16, x0
> > diff --git a/arch/x86/include/asm/xen/hypercall.h 
> > b/arch/x86/include/asm/xen/hypercall.h
> > index a12a047..f6d20f6 100644
> > --- a/arch/x86/include/asm/xen/hypercall.h
> > +++ b/arch/x86/include/asm/xen/hypercall.h
> > @@ -472,6 +472,13 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg)
> > return _hypercall2(int, xenpmu_op, op, arg);
> >  }
> >  
> > +static inline int
> > +HYPERVISOR_dm_op(
> > +   domid_t dom, unsigned int nr_bufs, void *bufs)
> > +{
> > +   return _hypercall3(int, dm_op, dom, nr_bufs, bufs);
> > +}
> > +
> >  static inline void
> >  MULTI_fpu_taskswitch(struct multicall_entry *mcl, int set)
> >  {
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index 5e5c7ae..a33f17e 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -22,6 +22,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -32,6 +33,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -43,6 +45,17 @@ MODULE_LICENSE("GPL");
> >  
> >  #define PRIV_VMA_LOCKED ((void *)1)
> >  
> > +unsigned int privcmd_dm_op_max_num = 16;
> > +module_param_named(dm_op_max_nr_bufs, privcmd_dm_op_max_num, uint, 0644);
> > +MODULE_PARM_DESC(dm_op_max_nr_bufs,
> > +"Maximum number of buffers per dm_op hypercall");
> > +
> > +unsigned int privcmd_dm_op_buf_max_size = XEN_PAGE_SIZE;
> > +module_param_named(dm_op_buf_max_size, privcmd_dm_op_buf_max_size, uint,
> > +  0644);
> > +MODULE_PARM_DESC(dm_op_buf_max_size,
> > +"Maximum size of a dm_op hypercall buffer");
> > +
> >  static int privcmd_vma_range_is_mapped(
> > struct vm_area_struct *vma,
> > unsigned long addr,
> > @@ -548,6 +561,128 @@ 

Re: [Xen-devel] STAO spec in xen.git

[Olaf Hering]

On Tue, Feb 14, Stefano Stabellini wrote:

> Also, I tried to do the same conversion with my copy of Libreoffice and
> the FODT files produced are significantly different from yours, which
> means, even if we use FODT docs, we are probably going to be unable to
> send changes as meaningful text patches.

I guess one would be able to use vi to make further adjustments.

So far I have not tried to apply what git send-email produced, it would
be a dead-end anyway :-)

Olaf


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

Re: [Xen-devel] [DOC v5] Xen transport for 9pfs

[Konrad Rzeszutek Wilk]

On Mon, Feb 13, 2017 at 11:47:26AM -0800, Stefano Stabellini wrote:

Reviewed-by: Konrad Rzeszutek Wilk 

> Changes in v5:
> - add padding after out_prod
> - add "Why ring.h is not needed"
> - specify max-ring-page-order >= 1

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

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

[Julien Grall]

Hi,

On 02/13/2017 10:14 PM, Stefano Stabellini wrote:

On Mon, 13 Feb 2017, Tamas K Lengyel wrote:

On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini
 wrote:

On Mon, 13 Feb 2017, Tamas K Lengyel wrote:

On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini
 wrote:

On Mon, 13 Feb 2017, Tamas K Lengyel wrote:

On Mon, Feb 13, 2017 at 11:06 AM, Julien Grall  wrote:



On 13/02/17 16:59, Tamas K Lengyel wrote:


On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall 
wrote:


Hi Tamas,


On 13/02/17 16:20, Tamas K Lengyel wrote:



On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
 wrote:



Hello,

This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in platform_hvc). I want to discuss more broad topic there.

Obviously, there are growing number of SMC users and current state of
SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
secure way, Xilinx wants to forward some calls directly to Secure
Monitor, while allowing to handle other in userspace, etc.

My proposition is to gather all requirements to SMC (and HVC) handling
in one place (e.g. in this mail thread). After we' will have clear
picture of what we want, we will be able to develop some solution,
that will satisfy us all. At least, I hope so :)

Also I want to remind, that there are ARM document called "SMC Calling
Convention" [3]. According to it, any aarch64 hypervisor "must
implement the Standard Secure and Hypervisor Service calls". At this
moment XEN does not conform to this.

So, lets get started with the requirements:
0. There are no much difference between SMC and HVC handling (at least
according to SMCCC).
1. Hypervisor should at least provide own UUID and version while
called by SMC/HVC
2. Hypervisor should forward some calls from dom0 directly to Secure
Monitor (Xilinx use case)
3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
architecture service calls, etc.
4. Hypervisor should handle TEE calls in a secure way (e.g. no
untrusted handlers in Dom0 userspace).
5. Hypervisor should support multiple TEEs (at least at compilation
time).
6. Hypervisor should do this as fast as possible (DRM playback use
case).
7. All domains (including dom0) should be handled in the same way.
8. Not all domains will have right to issue certain SMCs.
9. Hypervisor will issue own SMCs in some cases.




10. Domains on which the monitor privileged call feature is enabled
(which is by default disabled for all domains) should not be able to
issue SMCs such that it reaches the firmware directly. Xen should not
bounce such calls to the firmware on behalf of the domain. Xen should
not alter the state of the domain automatically (ie. incrementing PC).
These calls should be exclusively transfered to the monitor subscriber
for further processing. HVC calls need not be included in the monitor
forwarding as long as the HVC call can be governed by XSM.




This should not be a strong requirement. Whilst in your use case you want
to
forward all the SMCs to the monitor app, there are use case where Xen
would
need to emulate SMCs on the behalf of the guest. For instance see PSCI
(arch/arm/vpsci.c).



In my usecases it is a strong requirement. What happens when the
monitor system is disabled is beyond my concerns - Xen can emulate or
forward the call as it wishes. But when the monitor application is in
use - in my usecase - it needs to be in exclusive control. If that
breaks an in-guest application, that is acceptable in my usecase. As
soon as there is another usecase that would need to support such an
application while the monitor system is enabled, the monitor system
can be fine-tuned for those needs to allow Xen to emulate. I've said
it many times, I have nothing against doing that, but as I don't need
it I won't be able to spend time implementing it.


Right, as I wrote in the other thread, I think we should be able to find
a way to satisfy Tamas' requirement as well as all the others. Of
course, once you enable the "forward all SMCs to monitor" mode, some of
the other requirements might not be met anymore, but that's acceptable
because they are for different use-cases.



Let me remind you that this discussion is not about what you implemented but
what is a sensible design to fit everyone. I also never ask you to implement
anything.




Another valid use case is Xen handling power management for device
assigned
to the guest and having the monitor app acting as a "Trusted App".

Regarding the HVC call governed by XSM. I think this is the wrong way to
g.
As it was mentioned a couple of time HVC is a valid conduit for Secure
monitor call. You should not deny them on the basis that your monitor app
is
not able to handle it properly. A better way would be to have a list of
Secure Monitor Call (HVC/SMC) that should be forwarded to the monitor

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-buildfail REGR. vs. 105756
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 105756

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 

Re: [Xen-devel] [PATCH v15 01/10] x86: add "w" flag to .init.data section definition

[Andrew Cooper]

On 14/02/17 18:33, Daniel Kiper wrote:
> init.data section is clearly writable, so, add "w" flag to its
> definition in xen/arch/x86/boot/x86_64.S.
>
> Signed-off-by: Daniel Kiper 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

[Andrew Cooper]

On 14/02/17 17:49, George Dunlap wrote:
> On 14/02/17 17:45, Andrew Cooper wrote:
>> On 14/02/17 17:42, George Dunlap wrote:
>>> On 13/02/17 11:00, Andrew Cooper wrote:
 XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which 
 might be
 lower than the real maxphysaddr, to avoid overflowing the superpage shadow
 backpointer.

 However, plenty of hardware has a physical address width less that 44 bits,
 and the code added in shadow_domain_init() is a straight assignment.  This
 causes gfn_bits to be increased beyond the physical address width on most
 Intel consumer hardware (typically a width of 39, which is the number 
 reported
 to the guest via CPUID).

 If the guest intentionally creates a PTE referencing a physical address
 between 39 and 44 bits, the result should be #PF[RSVD] for using the 
 virtual
 address.  However, the shadow code accepts the PTE, shadows it, and the
 virtual address works normally.

 Introduce paging_max_paddr_bits() to calculate the largest guest physical
 address supportable by the paging infrastructure, and update
 recalculate_cpuid_policy() to take this into account when clamping the 
 guests
 cpuid_policy to reality.  Remove gfn_bits and rework its users in terms of 
 a
 guests maxphysaddr.

 Signed-off-by: Andrew Cooper 
 ---
 CC: Jan Beulich 
 CC: Tim Deegan 
 CC: George Dunlap 
 CC: Jun Nakajima 
 CC: Kevin Tian 

 v2:
  * Introduce paging_max_paddr_bits() rather than moving paging logic into
recalculate_cpuid_policy().
  * Rewrite half of the commit message.
 ---
  xen/arch/x86/cpuid.c|  7 +++
  xen/arch/x86/hvm/vmx/vvmx.c |  2 +-
  xen/arch/x86/mm/guest_walk.c|  3 ++-
  xen/arch/x86/mm/hap/hap.c   |  2 --
  xen/arch/x86/mm/p2m.c   |  3 ++-
  xen/arch/x86/mm/shadow/common.c | 10 --
  xen/arch/x86/mm/shadow/multi.c  |  3 ++-
  xen/include/asm-x86/domain.h|  3 ---
  xen/include/asm-x86/paging.h| 16 
  9 files changed, 26 insertions(+), 23 deletions(-)

 diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
 index e0a387e..3378f7a 100644
 --- a/xen/arch/x86/cpuid.c
 +++ b/xen/arch/x86/cpuid.c
 @@ -6,6 +6,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  
 @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
  
  cpuid_featureset_to_policy(fs, p);
  
 -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
  p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
 -d->arch.paging.gfn_bits + PAGE_SHIFT);
 -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
 -(p->basic.pae || p->basic.pse36) ? 36 : 
 32);
 +paging_max_paddr_bits(d));
 +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
  
  p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
  
 diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
 index 9c61b5b..774a11f 100644
 --- a/xen/arch/x86/hvm/vmx/vvmx.c
 +++ b/xen/arch/x86/hvm/vmx/vvmx.c
 @@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
  }
  
  if ( (gpa & ~PAGE_MASK) ||
 - (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
 + (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
  {
  vmfail_invalid(regs);
  return X86EMUL_OKAY;
 diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
 index a67fd5a..5ad8cf6 100644
 --- a/xen/arch/x86/mm/guest_walk.c
 +++ b/xen/arch/x86/mm/guest_walk.c
 @@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain 
 *p2m,
  /* If this guest has a restricted physical address space then the
   * target GFN must fit within it. */
  if ( !(rc & _PAGE_PRESENT)
 - && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
 + && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
 + (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )
>>> This pattern, of taking a gfn and shifting it by
>>> (cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
>>> several times; it seems like for both clarity and avoiding mistakes, it
>>> would be better if it were put into a macro.
>>>
>>> Everything else looks good to me.  (No opinion on the other questions
>>> raised so far.)
>> static inline unsigned int gfn_bits(const struct domain *d)
>> {
>> return d->arch.cpuid->extd.maxphysaddr - 

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Stefano Stabellini]

On Tue, 14 Feb 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 02/13/2017 07:59 PM, Stefano Stabellini wrote:
> > On Mon, 13 Feb 2017, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 10/02/17 01:01, Stefano Stabellini wrote:
> >>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
>  A possible hack could be to allocate a chunk of DDR dedicated for PCI 
>  DMA.
>  PCI DMA devs could be locked in to only be able to access this mem + MSI
>  doorbell.
>  Guests can still screw each other up but at least it becomes harder to
>  read/write directly from each others OS memory.
>  It may not be worth the effort though
> >>>
> >>> Actually, we do have the swiotlb in Dom0, which can be used to bounce
> >>> DMA requests over a buffer that has been previously setup to be DMA safe
> >>> using an hypercall. That is how the swiotlb is used on x86. On ARM it is
> >>> used to issue cache flushes via hypercall, but it could be adapted to do
> >>> both. It would degrade performance, due to the additional memcpy, but it
> >>> would work, I believe.
> >>
> >> A while ago, Globallogic suggested to use direct memory mapping for the 
> >> guest
> >> to allow guest using DMA on platform not supporting SMMU.
> >>
> >> I believe we can use the same trick on platform where SMMUs can not
> >> distinguish PCI devices.
> >
> > Yes, that would work, but only on platforms with a very limited number
> > of guests. However, it might still be a very common use-case on a
> > platform such as the Zynq MPSoC.
> 
> Can you explain why you think this could only work with limited number
> of guests?

Because the memory regions would need to be mapped 1:1, right? And often
devices have less than 4G DMA addresses limitations?

I can see how it could work well with 1-4 guests, but I don't think it
could work in a typical server environment with many more guests. Or am
I missing something?

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

Re: [Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Tue, Feb 14, 2017 at 07:33:24PM +0100, Daniel Kiper wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper 

I am posting diff between v14 and v15 for your convenience.

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 5147204..eb738d4 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -394,10 +394,18 @@ __start:

 /* EFI IA-32 platforms are not supported. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI32,MB2_tag_type(%ecx)
+/*
+ * Here we should zap vga_text_buffer. However, we can disable
+ * VGA updates in simpler and more reliable way later.
+ */
 je  .Lmb2_efi_ia_32

 /* Bootloader shutdown EFI x64 boot services. */
 cmpl$MULTIBOOT2_TAG_TYPE_EFI64,MB2_tag_type(%ecx)
+/*
+ * Here we should zap vga_text_buffer. However, we can disable
+ * VGA updates in simpler and more reliable way later.
+ */
 je  .Lmb2_no_bs

 /* Is it the end of Multiboot2 information? */
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub.c
index 2127cce..17da050 100644
--- a/xen/arch/x86/efi/stub.c
+++ b/xen/arch/x86/efi/stub.c
@@ -34,10 +34,10 @@ void __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle,
  * not be directly supported by C compiler.
  */
 asm volatile(
-"call *%2 \n"
+"call *%3 \n"
 "0:  hlt  \n"
 "jmp  0b  \n"
-   : "+c" (StdErr) : "d" (err), "rm" (StdErr->OutputString)
+   : "+c" (StdErr), "=d" (StdErr) : "1" (err), "rm" (StdErr->OutputString)
: "rax", "r8", "r9", "r10", "r11", "memory");

 unreachable();

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

[Xen-devel] [PATCH v3 3/4] x86: Make the GDT remapping read-only on 64-bit

[Thomas Garnier]

This patch makes the GDT remapped pages read-only to prevent corruption.
This change is done only on 64-bit.

The native_load_tr_desc function was adapted to correctly handle a
read-only GDT. The LTR instruction always writes to the GDT TSS entry.
This generates a page fault if the GDT is read-only. This change checks
if the current GDT is a remap and swap GDTs as needed. This function was
tested by booting multiple machines and checking hibernation works
properly.

KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
per-cpu variable was removed for functions to fetch the original GDT.
Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
expected. For testing, VMs were started and restored on multiple
configurations.

Signed-off-by: Thomas Garnier 
---
Based on next-20170213
---
 arch/x86/include/asm/desc.h  | 51 
 arch/x86/include/asm/processor.h |  1 +
 arch/x86/kernel/cpu/common.c | 28 +-
 arch/x86/kvm/svm.c   |  4 +---
 arch/x86/kvm/vmx.c   | 15 
 5 files changed, 75 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 5d4ba1311737..15b2a86c9267 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -57,6 +57,17 @@ static inline unsigned long get_cpu_gdt_rw_vaddr(unsigned 
int cpu)
return (unsigned long)get_cpu_gdt_rw(cpu);
 }
 
+/* Provide the current original GDT */
+static inline struct desc_struct *get_current_gdt_rw(void)
+{
+   return this_cpu_ptr(_page)->gdt;
+}
+
+static inline unsigned long get_current_gdt_rw_vaddr(void)
+{
+   return (unsigned long)get_current_gdt_rw();
+}
+
 /* Get the fixmap index for a specific processor */
 static inline unsigned int get_cpu_gdt_ro_index(int cpu)
 {
@@ -233,11 +244,6 @@ static inline void native_set_ldt(const void *addr, 
unsigned int entries)
}
 }
 
-static inline void native_load_tr_desc(void)
-{
-   asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
-}
-
 static inline void native_load_gdt(const struct desc_ptr *dtr)
 {
asm volatile("lgdt %0"::"m" (*dtr));
@@ -258,6 +264,41 @@ static inline void native_store_idt(struct desc_ptr *dtr)
asm volatile("sidt %0":"=m" (*dtr));
 }
 
+/*
+ * The LTR instruction marks the TSS GDT entry as busy. On 64-bit, the GDT is
+ * a read-only remapping. To prevent a page fault, the GDT is switched to the
+ * original writeable version when needed.
+ */
+#ifdef CONFIG_X86_64
+static inline void native_load_tr_desc(void)
+{
+   struct desc_ptr gdt;
+   int cpu = raw_smp_processor_id();
+   bool restore = 0;
+   struct desc_struct *fixmap_gdt;
+
+   native_store_gdt();
+   fixmap_gdt = get_cpu_gdt_ro(cpu);
+
+   /*
+* If the current GDT is the read-only fixmap, swap to the original
+* writeable version. Swap back at the end.
+*/
+   if (gdt.address == (unsigned long)fixmap_gdt) {
+   load_direct_gdt(cpu);
+   restore = 1;
+   }
+   asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
+   if (restore)
+   load_fixmap_gdt(cpu);
+}
+#else
+static inline void native_load_tr_desc(void)
+{
+   asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
+}
+#endif
+
 static inline unsigned long native_store_tr(void)
 {
unsigned long tr;
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index c441d1f7e275..6ea9e419a856 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -706,6 +706,7 @@ extern struct desc_ptr  early_gdt_descr;
 
 extern void cpu_set_gdt(int);
 extern void switch_to_new_gdt(int);
+extern void load_direct_gdt(int);
 extern void load_fixmap_gdt(int);
 extern void load_percpu_segment(int);
 extern void cpu_init(void);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 2853a42ded2d..bdf521383900 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -444,13 +444,31 @@ void load_percpu_segment(int cpu)
load_stack_canary_segment();
 }
 
+/* On 64-bit the GDT remapping is read-only */
+#ifdef CONFIG_X86_64
+#define PAGE_FIXMAP_GDT PAGE_KERNEL_RO
+#else
+#define PAGE_FIXMAP_GDT PAGE_KERNEL
+#endif
+
 /* Setup the fixmap mapping only once per-processor */
 static inline void setup_fixmap_gdt(int cpu)
 {
__set_fixmap(get_cpu_gdt_ro_index(cpu),
-__pa(get_cpu_gdt_rw(cpu)), PAGE_KERNEL);
+__pa(get_cpu_gdt_rw(cpu)), PAGE_FIXMAP_GDT);
 }
 
+/* Load the original GDT from the per-cpu structure */
+void load_direct_gdt(int cpu)
+{
+   struct desc_ptr gdt_descr;
+
+   gdt_descr.address = (long)get_cpu_gdt_rw(cpu);
+   gdt_descr.size = GDT_SIZE - 1;
+   load_gdt(_descr);
+}
+EXPORT_SYMBOL_GPL(load_direct_gdt);
+
 /* Load a fixmap remapping of the per-cpu GDT */
 

[Xen-devel] [xen-unstable-smoke test] 105797: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   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  bdbc25b8722cc1e3921858530f8ac484892156d3
baseline version:
 xen  909c219944e944f086ec0a89938a7397e2aa4cb0

Last test of basis   105792  2017-02-14 15:01:05 Z0 days
Testing same since   105797  2017-02-14 17:02:33 Z0 days1 attempts


People who touched revisions under test:
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=bdbc25b8722cc1e3921858530f8ac484892156d3
+ . ./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 
bdbc25b8722cc1e3921858530f8ac484892156d3
+ branch=xen-unstable-smoke
+ revision=bdbc25b8722cc1e3921858530f8ac484892156d3
+ . ./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
+ '[' xbdbc25b8722cc1e3921858530f8ac484892156d3 = 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
++ : 

Re: [Xen-devel] [PATCH v2] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

[George Dunlap]

On 14/02/17 17:45, Andrew Cooper wrote:
> On 14/02/17 17:42, George Dunlap wrote:
>> On 13/02/17 11:00, Andrew Cooper wrote:
>>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might 
>>> be
>>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
>>> backpointer.
>>>
>>> However, plenty of hardware has a physical address width less that 44 bits,
>>> and the code added in shadow_domain_init() is a straight assignment.  This
>>> causes gfn_bits to be increased beyond the physical address width on most
>>> Intel consumer hardware (typically a width of 39, which is the number 
>>> reported
>>> to the guest via CPUID).
>>>
>>> If the guest intentionally creates a PTE referencing a physical address
>>> between 39 and 44 bits, the result should be #PF[RSVD] for using the virtual
>>> address.  However, the shadow code accepts the PTE, shadows it, and the
>>> virtual address works normally.
>>>
>>> Introduce paging_max_paddr_bits() to calculate the largest guest physical
>>> address supportable by the paging infrastructure, and update
>>> recalculate_cpuid_policy() to take this into account when clamping the 
>>> guests
>>> cpuid_policy to reality.  Remove gfn_bits and rework its users in terms of a
>>> guests maxphysaddr.
>>>
>>> Signed-off-by: Andrew Cooper 
>>> ---
>>> CC: Jan Beulich 
>>> CC: Tim Deegan 
>>> CC: George Dunlap 
>>> CC: Jun Nakajima 
>>> CC: Kevin Tian 
>>>
>>> v2:
>>>  * Introduce paging_max_paddr_bits() rather than moving paging logic into
>>>recalculate_cpuid_policy().
>>>  * Rewrite half of the commit message.
>>> ---
>>>  xen/arch/x86/cpuid.c|  7 +++
>>>  xen/arch/x86/hvm/vmx/vvmx.c |  2 +-
>>>  xen/arch/x86/mm/guest_walk.c|  3 ++-
>>>  xen/arch/x86/mm/hap/hap.c   |  2 --
>>>  xen/arch/x86/mm/p2m.c   |  3 ++-
>>>  xen/arch/x86/mm/shadow/common.c | 10 --
>>>  xen/arch/x86/mm/shadow/multi.c  |  3 ++-
>>>  xen/include/asm-x86/domain.h|  3 ---
>>>  xen/include/asm-x86/paging.h| 16 
>>>  9 files changed, 26 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
>>> index e0a387e..3378f7a 100644
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -6,6 +6,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  
>>> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>>>  
>>>  cpuid_featureset_to_policy(fs, p);
>>>  
>>> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>>>  p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
>>> -d->arch.paging.gfn_bits + PAGE_SHIFT);
>>> -p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
>>> -(p->basic.pae || p->basic.pse36) ? 36 : 
>>> 32);
>>> +paging_max_paddr_bits(d));
>>> +p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr, 32);
>>>  
>>>  p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>>  
>>> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
>>> index 9c61b5b..774a11f 100644
>>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>>> @@ -1381,7 +1381,7 @@ int nvmx_handle_vmxon(struct cpu_user_regs *regs)
>>>  }
>>>  
>>>  if ( (gpa & ~PAGE_MASK) ||
>>> - (gpa >> (v->domain->arch.paging.gfn_bits + PAGE_SHIFT)) )
>>> + (gpa >> v->domain->arch.cpuid->extd.maxphysaddr) )
>>>  {
>>>  vmfail_invalid(regs);
>>>  return X86EMUL_OKAY;
>>> diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
>>> index a67fd5a..5ad8cf6 100644
>>> --- a/xen/arch/x86/mm/guest_walk.c
>>> +++ b/xen/arch/x86/mm/guest_walk.c
>>> @@ -435,7 +435,8 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain 
>>> *p2m,
>>>  /* If this guest has a restricted physical address space then the
>>>   * target GFN must fit within it. */
>>>  if ( !(rc & _PAGE_PRESENT)
>>> - && gfn_x(guest_l1e_get_gfn(gw->l1e)) >> d->arch.paging.gfn_bits )
>>> + && gfn_x(guest_l1e_get_gfn(gw->l1e)) >>
>>> + (d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT) )
>> This pattern, of taking a gfn and shifting it by
>> (cpuid->ectd.maxphysaddr-PAGE_SHIFT) to see if it's valid happens
>> several times; it seems like for both clarity and avoiding mistakes, it
>> would be better if it were put into a macro.
>>
>> Everything else looks good to me.  (No opinion on the other questions
>> raised so far.)
> 
> static inline unsigned int gfn_bits(const struct domain *d)
> {
> return d->arch.cpuid->extd.maxphysaddr - PAGE_SHIFT;
> }
> 
> ?
> 
> I do like that idea.  It would certainly make all of the callsites more
> readable.
> 
> I can happily fold that change in if others 

[Xen-devel] [PATCH v3 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

[Thomas Garnier]

This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.

It will allow GDT remapping in the Fixmap section. The current
MODULES_END static address does not provide enough space for the kernel
to support a large number of processors.

Signed-off-by: Thomas Garnier 
---
Based on next-20170213
---
 arch/x86/include/asm/fixmap.h   | 8 
 arch/x86/include/asm/pgtable_64_types.h | 3 ---
 arch/x86/kernel/module.c| 1 +
 arch/x86/mm/dump_pagetables.c   | 1 +
 arch/x86/mm/kasan_init_64.c | 1 +
 5 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 8554f960e21b..20231189e0e3 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -132,6 +132,14 @@ enum fixed_addresses {
 
 extern void reserve_top_address(unsigned long reserve);
 
+/* On 64-bit, the module sections ends with the start of the fixmap */
+#ifdef CONFIG_X86_64
+#define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+#define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
+#define MODULES_LEN   (MODULES_END - MODULES_VADDR)
+#endif /* CONFIG_X86_64 */
+
+
 #define FIXADDR_SIZE   (__end_of_permanent_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START  (FIXADDR_TOP - FIXADDR_SIZE)
 
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 3a264200c62f..de8bace10200 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -66,9 +66,6 @@ typedef struct { pteval_t pte; } pte_t;
 #define VMEMMAP_START  __VMEMMAP_BASE
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 #define VMALLOC_END(VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
-#define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
-#define MODULES_END  _AC(0xff00, UL)
-#define MODULES_LEN   (MODULES_END - MODULES_VADDR)
 #define ESPFIX_PGD_ENTRY _AC(-2, UL)
 #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
 #define EFI_VA_START( -4 * (_AC(1, UL) << 30))
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 477ae806c2fa..fad61caac75e 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if 0
 #define DEBUGP(fmt, ...)   \
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 8aa6bea1cd6c..90170415f08a 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -19,6 +19,7 @@
 #include 
 
 #include 
+#include 
 
 /*
  * The dumper groups pagetable entries of the same type into one, and for
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 0493c17b8a51..34f167cf3316 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 
 extern pgd_t early_level4_pgt[PTRS_PER_PGD];
 extern struct range pfn_mapped[E820_X_MAX];
-- 
2.11.0.483.g087da7b7c-goog


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

[Xen-devel] [PATCH v3 2/4] x86: Remap GDT tables in the Fixmap section

[Thomas Garnier]

Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section (PAGE_OFFSET).

This patch relocates the GDT table for each processor inside the
Fixmap section. The space is reserved based on number of supported
processors.

For consistency, the remapping is done by default on 32 and 64-bit.

Each processor switches to its remapped GDT at the end of
initialization. For hibernation, the main processor returns with the
original GDT and switches back to the remapping at completion.

This patch was tested on both architectures. Hibernation and KVM were
both tested specially for their usage of the GDT.

Signed-off-by: Thomas Garnier 
---
Based on next-20170213
---
 arch/x86/entry/vdso/vma.c |  2 +-
 arch/x86/include/asm/desc.h   | 33 +
 arch/x86/include/asm/fixmap.h |  4 
 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/include/asm/stackprotector.h |  2 +-
 arch/x86/kernel/acpi/sleep.c  |  2 +-
 arch/x86/kernel/apm_32.c  |  6 +++---
 arch/x86/kernel/cpu/common.c  | 26 --
 arch/x86/kernel/setup_percpu.c|  2 +-
 arch/x86/kernel/smpboot.c |  2 +-
 arch/x86/platform/efi/efi_32.c|  4 ++--
 arch/x86/power/cpu.c  |  7 +--
 arch/x86/xen/enlighten.c  |  2 +-
 arch/x86/xen/smp.c|  2 +-
 drivers/lguest/x86/core.c |  6 +++---
 drivers/pnp/pnpbios/bioscalls.c   | 10 +-
 16 files changed, 83 insertions(+), 28 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 572cee3fccff..9c8bd4cfcc6e 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -353,7 +353,7 @@ static void vgetcpu_cpu_init(void *arg)
d.p = 1;/* Present */
d.d = 1;/* 32-bit */
 
-   write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, , 
DESCTYPE_S);
+   write_gdt_entry(get_cpu_gdt_rw(cpu), GDT_ENTRY_PER_CPU, , DESCTYPE_S);
 }
 
 static int vgetcpu_online(unsigned int cpu)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 12080d87da3b..5d4ba1311737 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -45,11 +46,35 @@ struct gdt_page {
 
 DECLARE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page);
 
-static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu)
+/* Provide the original GDT */
+static inline struct desc_struct *get_cpu_gdt_rw(unsigned int cpu)
 {
return per_cpu(gdt_page, cpu).gdt;
 }
 
+static inline unsigned long get_cpu_gdt_rw_vaddr(unsigned int cpu)
+{
+   return (unsigned long)get_cpu_gdt_rw(cpu);
+}
+
+/* Get the fixmap index for a specific processor */
+static inline unsigned int get_cpu_gdt_ro_index(int cpu)
+{
+   return FIX_GDT_REMAP_BEGIN + cpu;
+}
+
+/* Provide the fixmap address of the remapped GDT */
+static inline struct desc_struct *get_cpu_gdt_ro(int cpu)
+{
+   unsigned int idx = get_cpu_gdt_ro_index(cpu);
+   return (struct desc_struct *)__fix_to_virt(idx);
+}
+
+static inline unsigned long get_cpu_gdt_ro_vaddr(int cpu)
+{
+   return (unsigned long)get_cpu_gdt_ro(cpu);
+}
+
 #ifdef CONFIG_X86_64
 
 static inline void pack_gate(gate_desc *gate, unsigned type, unsigned long 
func,
@@ -174,7 +199,7 @@ static inline void set_tssldt_descriptor(void *d, unsigned 
long addr, unsigned t
 
 static inline void __set_tss_desc(unsigned cpu, unsigned int entry, void *addr)
 {
-   struct desc_struct *d = get_cpu_gdt_table(cpu);
+   struct desc_struct *d = get_cpu_gdt_rw(cpu);
tss_desc tss;
 
/*
@@ -202,7 +227,7 @@ static inline void native_set_ldt(const void *addr, 
unsigned int entries)
 
set_tssldt_descriptor(, (unsigned long)addr, DESC_LDT,
  entries * LDT_ENTRY_SIZE - 1);
-   write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_LDT,
+   write_gdt_entry(get_cpu_gdt_rw(cpu), GDT_ENTRY_LDT,
, DESC_LDT);
asm volatile("lldt %w0"::"q" (GDT_ENTRY_LDT*8));
}
@@ -244,7 +269,7 @@ static inline unsigned long native_store_tr(void)
 
 static inline void native_load_tls(struct thread_struct *t, unsigned int cpu)
 {
-   struct desc_struct *gdt = get_cpu_gdt_table(cpu);
+   struct desc_struct *gdt = get_cpu_gdt_rw(cpu);
unsigned int i;
 
for (i = 0; i < GDT_ENTRY_TLS_ENTRIES; i++)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 20231189e0e3..4c11425d856c 100644
--- a/arch/x86/include/asm/fixmap.h
+++ 

[Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base

[Thomas Garnier]

The KVM segment_base function is confusing. This patch replaces integers
with appropriate flags, simplify constructs and add comments.

Signed-off-by: Thomas Garnier 
---
Based on next-20170213
---
 arch/x86/kvm/vmx.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 99167f20bc34..edb8326108dd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2062,25 +2062,35 @@ static unsigned long segment_base(u16 selector)
struct desc_struct *d;
unsigned long table_base;
unsigned long v;
+   u32 high32;
 
-   if (!(selector & ~3))
+   if (!(selector & ~SEGMENT_RPL_MASK))
return 0;
 
-   table_base = get_current_gdt_rw_vaddr();
-
-   if (selector & 4) {   /* from ldt */
+   /* LDT selector */
+   if ((selector & SEGMENT_TI_MASK) == SEGMENT_LDT) {
u16 ldt_selector = kvm_read_ldt();
 
-   if (!(ldt_selector & ~3))
+   if (!(ldt_selector & ~SEGMENT_RPL_MASK))
return 0;
 
table_base = segment_base(ldt_selector);
+   } else {
+   table_base = get_current_gdt_rw_vaddr();
}
-   d = (struct desc_struct *)(table_base + (selector & ~7));
+
+   d = (struct desc_struct *)table_base + (selector >> 3);
v = get_desc_base(d);
 #ifdef CONFIG_X86_64
-   if (d->s == 0 && (d->type == 2 || d->type == 9 || d->type == 11))
-   v |= ((unsigned long)((struct ldttss_desc64 *)d)->base3) << 32;
+   /*
+* Extend the virtual address if we have a system descriptor entry for
+* LDT or TSS (available or busy).
+*/
+   if (d->s == 0 && (d->type == DESC_LDT || d->type == DESC_TSS ||
+ d->type == 11/*Busy TSS */)) {
+   high32 = ((struct ldttss_desc64 *)d)->base3;
+   v |= (u64)high32 << 32;
+   }
 #endif
return v;
 }
-- 
2.11.0.483.g087da7b7c-goog


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

Re: [Xen-devel] [PATCH v3] xen, input: try to read screen resolution for xen-kbdfront

[Oleksandr Andrushchenko]

Ping as I am also interested in modifying kbdfront...

On 02/09/2017 03:45 PM, Juergen Gross wrote:

On 30/01/17 16:10, Juergen Gross wrote:

Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.

Signed-off-by: Juergen Gross 

Ping?


---
V3: add case of late framebuffer registration (Oleksandr Andrushchenko)
V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
---
  drivers/input/misc/xen-kbdfront.c | 46 ---
  1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875..9a20800 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -39,6 +40,9 @@ struct xenkbd_info {

int irq;
struct xenbus_device *xbdev;
char phys[32];
+#ifdef CONFIG_FB_NOTIFY
+   struct notifier_block nb;
+#endif
  };
  
  static int xenkbd_remove(struct xenbus_device *);

@@ -105,10 +109,29 @@ static irqreturn_t input_handler(int rq, void *dev_id)
return IRQ_HANDLED;
  }
  
+#ifdef CONFIG_FB

+#ifdef CONFIG_FB_NOTIFY
+static int xenkbd_fb_event(struct notifier_block *self,
+  unsigned long action, void *data)
+{
+   struct xenkbd_info *info = container_of(self, struct xenkbd_info, nb);
+   struct fb_info *fb = registered_fb[0];
+
+   if (action != FB_EVENT_FB_REGISTERED || !fb)
+   return 0;
+
+   input_set_abs_params(info->ptr, ABS_X, 0, fb->var.xres_virtual, 0, 0);
+   input_set_abs_params(info->ptr, ABS_Y, 0, fb->var.yres_virtual, 0, 0);
+
+   return 0;
+}
+#endif
+#endif
+
  static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
  {
-   int ret, i;
+   int ret, i, width, height;
unsigned int abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
@@ -173,9 +196,22 @@ static int xenkbd_probe(struct xenbus_device *dev,
ptr->id.product = 0xfffe;
  
  	if (abs) {

+   width = XENFB_WIDTH;
+   height = XENFB_HEIGHT;
+#ifdef CONFIG_FB
+   if (registered_fb[0]) {
+   width = registered_fb[0]->var.xres_virtual;
+   height = registered_fb[0]->var.yres_virtual;
+   } else {
+#ifdef CONFIG_FB_NOTIFY
+   info->nb.notifier_call = xenkbd_fb_event;
+   fb_register_client(>nb);
+#endif
+   }
+#endif
__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, width, 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, height, 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);
@@ -222,6 +258,10 @@ static int xenkbd_remove(struct xenbus_device *dev)
struct xenkbd_info *info = dev_get_drvdata(>dev);
  
  	xenkbd_disconnect_backend(info);

+#ifdef CONFIG_FB_NOTIFY
+   if (info->nb.notifier_call)
+   fb_unregister_client(>nb);
+#endif
if (info->kbd)
input_unregister_device(info->kbd);
if (info->ptr)



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



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

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

[Tian, Kevin]

> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper
> Sent: Tuesday, February 14, 2017 3:59 PM
> 
> On 14/02/2017 02:52, Tian, Kevin wrote:
> >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> >> Sent: Monday, February 13, 2017 10:32 PM
> >>
> >> hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
> >> restored when switching into guest context.  It should never have been 
> >> part of
> >> the migration state to start with, and Xen must not make any decisions 
> >> based
> >> on the value seen during restore.
> >>
> >> Identify it as obsolete in the header files, consistently save it as zero 
> >> and
> >> ignore it on restore.
> >>
> >> The MSRs must be considered dirty during VMCS creation to cause the proper
> >> defaults of 0 to be visible to the guest.
> >>
> >> Signed-off-by: Andrew Cooper 
> > Reviewed-by: Kevin Tian , with one small comment.
> >
> > the effect of this patch should be more than not leaking syscall MSR.
> > what about making the subject clearer when check-in?
> 
> What other effects do you think are going on here?  Yes, we now context
> switch the MSRs right from the start of the domain, but that is
> necessary to avoid leaking them.
> 

If just looking at this patch, it's for general MSR save/restore policy,
nothing specific to syscall MSR. 

Thanks
Kevin

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 5b97eb4c35316cbe8235ae526209263da818e1a4
baseline version:
 ovmf 296153c5bf9976a3b5f00566819f109d1c23c135

Last test of basis68554  2017-02-13 10:16:42 Z0 days
Testing same since68555  2017-02-14 06:16:27 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 
  Yonghong Zhu 

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 5b97eb4c35316cbe8235ae526209263da818e1a4
Author: Yonghong Zhu 
Date:   Mon Feb 13 13:10:43 2017 +0800

BaseTools: Enhance BaseTools supports FixedAtBuild usage in VFR file

This patch is to update BaseTools generate Fixed PCD APIs and Value into
$(MODULE_NAME)StrDefs.h for VFR only. If the module has VFR files, and it
directly consumes FixedAtBuild PCD, BaseTool will generate those
FixedAtBuild PCD value into its $(MODULE_NAME)StrDefs.h. FixedPcdGetXX
macro are always generated. Every FixedPcd _PCD_VALUE_PcdName will be
generated without the postfix U or UL or ULL.

Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=348
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit 8b2a15fd5c7235f2998e26906e034204147d07a9
Author: Star Zeng 
Date:   Fri Feb 10 15:31:40 2017 +0800

MdePkg ACPI: Incorrect definition name for ACPI IORT Table signature

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=363

The definition name for ACPI IO Remapping Table signature is incorrect
in Acpi60.h and Acpi61.h as below:
EFI_ACPI_6_0_INTERRUPT_SOURCE_OVERRIDE_SIGNATURE
EFI_ACPI_6_1_INTERRUPT_SOURCE_OVERRIDE_SIGNATURE

The name should be changed to
EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE
EFI_ACPI_6_1_IO_REMAPPING_TABLE_SIGNATURE

The comments
///
/// "IORT" Interrupt Source Override
///
will be also changed to
///
/// "IORT" I/O Remapping Table
///

Cc: Alexei Fedorov 
Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

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

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

[Andrew Cooper]

On 14/02/2017 08:04, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew 
>> Cooper
>> Sent: Tuesday, February 14, 2017 3:59 PM
>>
>> On 14/02/2017 02:52, Tian, Kevin wrote:
 From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
 Sent: Monday, February 13, 2017 10:32 PM

 hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
 restored when switching into guest context.  It should never have been 
 part of
 the migration state to start with, and Xen must not make any decisions 
 based
 on the value seen during restore.

 Identify it as obsolete in the header files, consistently save it as zero 
 and
 ignore it on restore.

 The MSRs must be considered dirty during VMCS creation to cause the proper
 defaults of 0 to be visible to the guest.

 Signed-off-by: Andrew Cooper 
>>> Reviewed-by: Kevin Tian , with one small comment.
>>>
>>> the effect of this patch should be more than not leaking syscall MSR.
>>> what about making the subject clearer when check-in?
>> What other effects do you think are going on here?  Yes, we now context
>> switch the MSRs right from the start of the domain, but that is
>> necessary to avoid leaking them.
>>
> If just looking at this patch, it's for general MSR save/restore policy,
> nothing specific to syscall MSR.

The only three MSRs which use this infrastructure are LSTAR, STAR and
FMASK.  What if I were to clarify that in the first paragraph?

~Andrew

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

Re: [Xen-devel] [PATCH v3 0/2] Enable Wformat for clang

[Roger Pau Monne]

On Tue, Feb 14, 2017 at 08:46:56AM +, Roger Pau Monne wrote:
> Hello,
> 
> These patches fix the remaining issues so that Wformat can be enabled for
> clang.

This has now been superseded by "[PATCH v4 0/4] clang: don't disable any
warnings". Please ignore this series.

Roger.

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

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest

[Kang, Luwei]

> On 14/02/17 02:19, Luwei Kang wrote:
> > vpmu_enable() can not use for check if vpmu is enabled in guest during
> > booting up. Because linux kernel get the status of if supported pmu is
> > earler than xen vpmu initialise. vpmu_enable() will return false even
> > if vpmu has been enabled in guest.
> 
> Sorry for breaking this.  However ...
> 
> > diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index
> > e0a387e..b63c5d8 100644
> > --- a/xen/arch/x86/cpuid.c
> > +++ b/xen/arch/x86/cpuid.c
> > @@ -713,8 +713,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
> > struct cpuid_leaf *res)
> >  }
> >  }
> >
> > -if ( vpmu_enabled(curr) &&
> > - vpmu_is_set(vcpu_vpmu(curr), VPMU_CPU_HAS_DS) )
> > +if ( opt_vpmu_enabled && boot_cpu_has(X86_FEATURE_DS) )
> 
> ... this is overly general.  The visibility of these flags must be per 
> domain, and not globally like this.
> 
> In particular, XENPMU_MODE_ALL needs to expose PMU to dom0, but hide it from 
> all other domains, while even in the
> XENPMU_MODE_SELF case, only domains explicitly configured with PMU should see 
> it (as it generally unsafe to migrate with).
> 
> Longterm (with the inclusion of the CPUID improvements), my plan was to have 
> PMU available in the max policy but hidden in the
> default policy, which requires the toolstack to explicitly opt in for 
> domains.  It would opt in/out by setting the version field in guests
> CPUID policy and the other feature bits.
> 
Get it. Thanks for your explanation.

Thanks,
Luwei Kang

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

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

[George Dunlap]

On Tue, Feb 14, 2017 at 10:29 AM, Wei Liu  wrote:
> On Thu, Feb 09, 2017 at 11:35:16AM +, George Dunlap wrote:
>> No.  This is why I'm bothering to paint this bikeshed: In every context
>> *except* "cpupool create", 0 means cpupool0 -- the one that was created
>> at boot, which always contains dom0, and which cannot be destroyed.
>> (You can only remove all but one of the cpus.)  If you remove a cpupool
>> from poolid 0, you remove it from cpupool0, not "any" pool.  If you
>> create a domain and ask to put it in poolid 0, it will be put in
>> cpupool0, not "any" pool.  The only context in which "0" currently means
>> "any" is when you're creating a cpupool.
>>
>
> OK. This makes sense.
>
[snip]
>> > I want to reserve the possibility to change that into an enum in the
>> > future.
>>
>> Yes, I had thought of that -- but like I said, I thought enums were
>> meant mostly for things for which there was an exhaustive list.  In this
>> case it's a "magic" value for a parameter which normally has a plain
>> numerical meaning.
>>
>> But I can add the #define if you wish.
>>
>
> You don't need to do that.

Is that an Ack? :-)

 -George

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 105756
 build-amd64-xsm   5 xen-build  fail in 105777 REGR. vs. 105756
 build-armhf-libvirt  4 host-build-prep fail in 105777 REGR. vs. 105756

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qcow23 host-install(3) broken in 105777 pass in 105784
 test-armhf-armhf-xl-arndale   4 host-ping-check-native fail pass in 105777

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 105728
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 105756
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 105756
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105756
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105756
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105756
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105756
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 105756
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 105756

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-xsm1 build-check(1)   blocked in 105777 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked in 105777 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 105777 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 105777 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 105777 n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked in 105777 n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked in 105777 n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 105777 n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked in 105777 n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
105777 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 105777 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 105777 never 
pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   

[Xen-devel] [PATCH v4 1/4] xen/grants: print grant number and handle in hex format

[Roger Pau Monne]

Due to the large number of grants in use it seems more useful to print the
grant references and handlers in hex format rather than decimal.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v2:
 - Remove the () and the final dot of messages.
 - Fix printing the ref in the 'g' debug key, so that 3 chars are used for the
   ref itself.
---
 xen/common/grant_table.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index d3ea805..f780975 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -814,7 +814,7 @@ __gnttab_map_grant_ref(
 
 /* Bounds check on the grant ref */
 if ( unlikely(op->ref >= nr_grant_entries(rgt)))
-PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref (%d).\n", op->ref);
+PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x\n", op->ref);
 
 act = active_entry_acquire(rgt, op->ref);
 shah = shared_entry_header(rgt, op->ref);
@@ -1087,7 +1087,7 @@ __gnttab_unmap_common(
 
 if ( unlikely(op->handle >= lgt->maptrack_limit) )
 {
-gdprintk(XENLOG_INFO, "Bad handle (%d).\n", op->handle);
+gdprintk(XENLOG_INFO, "Bad handle %#x\n", op->handle);
 op->status = GNTST_bad_handle;
 return;
 }
@@ -1099,7 +1099,7 @@ __gnttab_unmap_common(
 if ( unlikely(!read_atomic(>map->flags)) )
 {
 grant_read_unlock(lgt);
-gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle);
+gdprintk(XENLOG_INFO, "Zero flags for handle %#x\n", op->handle);
 op->status = GNTST_bad_handle;
 return;
 }
@@ -1132,7 +1132,7 @@ __gnttab_unmap_common(
 op->flags = read_atomic(>map->flags);
 if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) )
 {
-gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle);
+gdprintk(XENLOG_WARNING, "Unstable handle %#x\n", op->handle);
 rc = GNTST_bad_handle;
 goto unmap_out;
 }
@@ -1706,7 +1706,7 @@ gnttab_prepare_for_transfer(
 if ( unlikely(ref >= nr_grant_entries(rgt)) )
 {
 gdprintk(XENLOG_INFO,
-"Bad grant reference (%d) for transfer to domain(%d).\n",
+"Bad grant reference %#x for transfer to d%d\n",
 ref, rd->domain_id);
 goto fail;
 }
@@ -2672,7 +2672,7 @@ 
gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
 break;
 default:
 gdprintk(XENLOG_INFO,
- "bad flags %#x in grant %u when switching version\n",
+ "bad flags %#x in grant %#x when switching version\n",
  flags, i);
 /* fall through */
 case GTF_invalid:
@@ -2836,9 +2836,9 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t 
ref_b)
 
 /* Bounds check on the grant refs */
 if ( unlikely(ref_a >= nr_grant_entries(d->grant_table)))
-PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-a (%d).\n", ref_a);
+PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-a %#x\n", ref_a);
 if ( unlikely(ref_b >= nr_grant_entries(d->grant_table)))
-PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b (%d).\n", ref_b);
+PIN_FAIL(out, GNTST_bad_gntref, "Bad ref-b %#x\n", ref_b);
 
 /* Swapping the same ref is a no-op. */
 if ( ref_a == ref_b )
@@ -2846,11 +2846,11 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t 
ref_b)
 
 act_a = active_entry_acquire(gt, ref_a);
 if ( act_a->pin )
-PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
+PIN_FAIL(out, GNTST_eagain, "ref a %#x busy\n", ref_a);
 
 act_b = active_entry_acquire(gt, ref_b);
 if ( act_b->pin )
-PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
+PIN_FAIL(out, GNTST_eagain, "ref b %#x busy\n", ref_b);
 
 if ( gt->gt_version == 1 )
 {
@@ -3284,9 +3284,8 @@ gnttab_release_mappings(
 
 ref = map->ref;
 
-gdprintk(XENLOG_INFO, "Grant release (%hu) ref:(%hu) "
-"flags:(%x) dom:(%hu)\n",
-handle, ref, map->flags, map->domid);
+gdprintk(XENLOG_INFO, "Grant release %#x ref %#x flags %#x dom %u\n",
+ handle, ref, map->flags, map->domid);
 
 rd = rcu_lock_domain_by_id(map->domid);
 if ( rd == NULL )
@@ -3530,8 +3529,8 @@ static void gnttab_usage_print(struct domain *rd)
 first = 0;
 }
 
-/*  [ddd]d 0xXX 0x  d 

[Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

[Roger Pau Monne]

And fix the following errors reported:

traps.c:2014:25: error: equality comparison with extraneous parentheses
  [-Werror,-Wparentheses-equality]
else if ( (port == RTC_PORT(0)) )
   ~^~
traps.c:2014:25: note: remove extraneous parentheses around the comparison to 
silence this warning
else if ( (port == RTC_PORT(0)) )
  ~ ^ ~
traps.c:2014:25: note: use '=' to turn this equality comparison into an 
assignment
else if ( (port == RTC_PORT(0)) )
^~
=
traps.c:2083:25: error: equality comparison with extraneous parentheses
  [-Werror,-Wparentheses-equality]
else if ( (port == RTC_PORT(0)) )
   ~^~

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk| 3 ---
 xen/arch/x86/traps.c | 4 ++--
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/Config.mk b/Config.mk
index bff4dc5..9a28d15 100644
--- a/Config.mk
+++ b/Config.mk
@@ -212,9 +212,6 @@ CFLAGS += -std=gnu99
 
 CFLAGS += -Wall -Wstrict-prototypes
 
-# Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
-CFLAGS-$(clang) += -Wno-parentheses
-
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 691c9a2..eb634d9 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2011,7 +2011,7 @@ uint32_t guest_io_read(unsigned int port, unsigned int 
bytes,
 {
 sub_data = pv_pit_handler(port, 0, 0);
 }
-else if ( (port == RTC_PORT(0)) )
+else if ( port == RTC_PORT(0) )
 {
 sub_data = currd->arch.cmos_idx;
 }
@@ -2080,7 +2080,7 @@ void guest_io_write(unsigned int port, unsigned int 
bytes, uint32_t data,
 {
 pv_pit_handler(port, (uint8_t)data, 1);
 }
-else if ( (port == RTC_PORT(0)) )
+else if ( port == RTC_PORT(0) )
 {
 currd->arch.cmos_idx = data;
 }
-- 
2.10.1 (Apple Git-78)


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

[Xen-devel] [PATCH v4 0/4] clang: don't disable any warnings

[Roger Pau Monne]

Hello,

The following series removes the disable of certain clang warnings, after this
all clang warnings are enabled. This supersedes "[PATCH v3 0/2] Enable Wformat
for clang".

It has been tested in FreeBSD with clang 3.8, and by travis, all OK:

https://travis-ci.org/royger/xen/builds/201482055

Thanks, Roger.


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

[Xen-devel] [PATCH v4 2/4] build/printf: fix incorrect format specifiers

[Roger Pau Monne]

The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:

mce.c:601:18: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
 smp_processor_id());
 ^

xenpm.c:102:23: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
what, argv[argc > 1]);
  ^

libxl_internal.c:25:69: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^
libxl_internal.c:26:21: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
fprintf(stderr, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^

This patch contains the fixes for them and enables -Wformat for clang.

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
---
NB: FWIW, there's a way to disable extra arguments checks
(-Wno-format-extra-args), that would prevent us from having to apply some of
the changes here. However, given that there are not that many occurrences, I
would rather leave the full checks of Wformat enabled.

NB2: this has only been tested with a FreeBSD clang build (3.8.0), and only
against the components that build on FreeBSD (ie: no qemu-trad, and certainly
no blktap).
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Christoph Egger 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v2:
 - Remove the printf related comment near the -Wno-format.

Changes since v1:
 - Change the format string for MCE to avoid duplicating CPU%i.
 - Remove the grant-ref format specifier change, it's already taken care in
   patch #1.
---
 Config.mk |  3 +--
 tools/libxl/libxl_internal.c  | 21 -
 tools/misc/xenpm.c| 13 -
 xen/arch/x86/cpu/mcheck/mce.c |  5 ++---
 4 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/Config.mk b/Config.mk
index 3a1d960..7d08d16 100644
--- a/Config.mk
+++ b/Config.mk
@@ -213,9 +213,8 @@ CFLAGS += -std=gnu99
 CFLAGS += -Wall -Wstrict-prototypes
 
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
-# and is over-zealous with the printf format lint
 # and is a bit too fierce about unused return values
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
+CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d288215..f492dae 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -20,14 +20,25 @@
 void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
  size_t nmemb, size_t size) {
 #define M "libxl: FATAL ERROR: memory allocation failure"
-#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
-  func, (unsigned long)nmemb, (unsigned long)size
-libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
-fprintf(stderr, L);
+#define M_SIZE M " (%s, %lu x %lu)\n"
+#define M_NSIZE M " (%s)\n"
+if (size) {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_SIZE, func, (unsigned long)nmemb, (unsigned long)size);
+   fprintf(stderr, M_SIZE, func, (unsigned long)nmemb,
+   (unsigned long)size);
+} else {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_NSIZE, func);
+   fprintf(stderr, M_NSIZE, func);
+
+}
+
 fflush(stderr);
 _exit(-1);
+#undef M_NSIZE
+#undef M_SIZE
 #undef M
-#undef L
 }
 
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index a2edee5..ded40b9 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -93,13 +93,16 @@ static void parse_cpuid(const char *arg, int *cpuid)
 static void parse_cpuid_and_int(int argc, char *argv[],
 int *cpuid, int *val, const char *what)
 {
-if ( argc > 1 )
-parse_cpuid(argv[0], cpuid);
+if ( argc == 0 )
+{
+ fprintf(stderr, "Missing %s\n", what);
+ exit(EINVAL);
+}
 
-if ( argc == 0 || sscanf(argv[argc > 1], "%d", val) != 1 )
+parse_cpuid(argv[0], cpuid);
+if ( sscanf(argv[1], "%d", val) != 1 )
 {
-fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
- 

[Xen-devel] [PATCH v4 3/4] build: enable unused value checks for clang

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Config.mk b/Config.mk
index 7d08d16..bff4dc5 100644
--- a/Config.mk
+++ b/Config.mk
@@ -213,8 +213,7 @@ CFLAGS += -std=gnu99
 CFLAGS += -Wall -Wstrict-prototypes
 
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
-# and is a bit too fierce about unused return values
-CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
+CFLAGS-$(clang) += -Wno-parentheses
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
-- 
2.10.1 (Apple Git-78)


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

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest

[Jan Beulich]

>>> On 14.02.17 at 03:19,  wrote:
> vpmu_enable() can not use for check if vpmu is enabled in guest during
> booting up. Because linux kernel get the status of if supported pmu
> is earler than xen vpmu initialise. vpmu_enable() will return false
> even if vpmu has been enabled in guest.
> 
> Signed-off-by: Luwei Kang 

You've probably seen Boris' patch with the same overall goal. While
his looks to leave things a little too strict, yours looks to be widening
things a little too much. Do both of you think we could find a middle
ground, or do we need to accept the effect of possibly misleading
the guest by surfacing the CPUID data independent of vPMU mode,
as is done here?

Jan


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

Re: [Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

[Roger Pau Monne]

On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
> >>> On 10.02.17 at 13:33,  wrote:
> > ---
> > Changes since v5:
> >  - Adjust the logic to set need_paging.
> >  - Remove the usage of the _AC macro.
> >  - Subtract memory from the end of regions instead of the start.
> >  - Create the VM86_TSS before the identity page table, so that the page 
> > table
> >is aligned to a page boundary.
> >  - Use MB1_PAGES in modify_identity_mmio.
> >  - Move and simply the ASSERT in pvh_setup_p2m.
> >  - Move the creation of the PSE page tables to a separate function, and use 
> > it
> >in shadow_enable also.
> >  - Make the map modify_identiy_mmio parameter a constant.
> >  - Add a comment to HVM_VM86_TSS_SIZE, although it seems this might need
> >further fixing.
> 
> Indeed, I think this wants to be re-based on top of the patch I've
> just sent (with you Cc-ed).

Sure. Just done that.

> > +static int __init pvh_steal_ram(struct domain *d, unsigned long size,
> > +unsigned long align, paddr_t limit,
> > +paddr_t *addr)
> > +{
> > +unsigned int i = d->arch.nr_e820;
> > +
> > +/*
> > + * Alignment 0 should be set to 1, so it doesn't wrap around in the
> > + * calculations below.
> > + */
> > +align = align ? : 1;
> > +while ( i-- )
> > +{
> > +struct e820entry *entry = >arch.e820[i];
> > +
> > +if ( entry->type != E820_RAM || entry->addr + entry->size > limit 
> > ||
> > + entry->addr < MB(1) )
> > +continue;
> > +
> > +*addr = (entry->addr + entry->size - size) & ~(align - 1);
> 
> Without taking the present callers into account (who don't request
> huge alignment) this (theoretically) risks running into the low 1Mb.
> I see two options - either add a comment clarifying that an entry
> will never cross the 1Mb boundary (and hence the issue can't
> occur), or limit the alignment (by way of ASSERT()) to PAGE_SIZE
> (in which case no significant harm would result from crossing the
> boundary).

I don't mind adding the ASSERT, but I don't see how this can risk running into
the low 1MB. If entry->addr < MB(1) the entry is skipped. If an entry crosses
the 1Mb boundary it will certainly have entry->addr < 1Mb.

> > +static int __init pvh_setup_vmx_realmode_helpers(struct domain *d)
> > +{
> > +p2m_type_t p2mt;
> > +uint32_t rc, *ident_pt;
> > +uint8_t *tss;
> > +mfn_t mfn;
> > +paddr_t gaddr;
> > +
> > +/*
> > + * Steal some space from the last RAM region below 4GB and use it to
> > + * store the real-mode TSS.
> > + */
> > +if ( !pvh_steal_ram(d, HVM_VM86_TSS_SIZE, 0, GB(4), ) &&
> 
> Please request at least 128-byte alignment here, to avoid the
> base TSS structure crossing a page boundary.

Right, this TSS is loaded while using the identity PT, so with paging enabled.

> > + (tss = map_domain_gfn(p2m_get_hostp2m(d), _gfn(PFN_DOWN(gaddr)),
> > +   , , 0, )) )
> > +{
> > +memset(tss, 0, HVM_VM86_TSS_SIZE);
> 
> What makes you assume that you've mapped all the space you've
> allocated?

Hm, right, I've just realized we don't really need to map anything here, a
hvm_copy_to_guest_phys with NULL should be enough, and then I don't need to
worry about boundaries.

> > --- a/xen/include/asm-x86/page.h
> > +++ b/xen/include/asm-x86/page.h
> > @@ -374,6 +374,18 @@ perms_strictly_increased(uint32_t old_flags, uint32_t 
> > new_flags)
> >  return ((of | (of ^ nf)) == nf);
> >  }
> >  
> > +/* Build a 32bit PSE page table using 4MB pages. */
> > +static inline void
> > +write_32bit_pse_identmap(uint32_t *l2)
> 
> Why does this need to be an inline function?

Given it's size and the low number of callers I though it would be better to
make it inline, but since this is not in any performance critical path I'm
going to remove the inlining, although I think the compiler is probably going
to do it anyway.

Roger.

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

Re: [Xen-devel] [PATCH] configure: disable bash check for FreeBSD

[Wei Liu]

On Mon, Feb 13, 2017 at 04:05:19PM +, Roger Pau Monne wrote:
> On Mon, Feb 13, 2017 at 03:59:15PM +, Wei Liu wrote:
> > On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> > > Sorry, I've forgot to re-generate the patch after adding the 
> > > maintainers...
> > > 
> > > On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
> > > > Bash it's not used on FreeBSD.
> > > > 
> > > > Signed-off-by: Roger Pau Monné 
> > > > ---
> > > > Please re-run autoconf after applying
> > > > ---
> > > >  tools/configure.ac | 6 +-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/tools/configure.ac b/tools/configure.ac
> > > > index 873e18d..28a539c 100644
> > > > --- a/tools/configure.ac
> > > > +++ b/tools/configure.ac
> > > > @@ -320,7 +320,11 @@ AS_IF([test "x$xsmpolicy" = "xy"], [
> > > >  xsmpolicy="n"
> > > >  ])
> > > >  ])
> > > > -AX_PATH_PROG_OR_FAIL([BASH], [bash])
> > > > +dnl FreeBSD doesn't require bash (hotplug scripts are in plain sh)
> > 
> > I am not sure I follow this comment.  It implies hotplug scripts are the
> > only shell scripts that we ship or care and this check here is
> > specifically for that purpose.
> > 
> > If this comment is correct, isn't it better to just  remove this check?
> > AFAICT sh is standard.  If this comment is not correct, should we check
> > for the desired shell in FreeBSD?
> 
> Hotplug scripts are specific to each OS, and the FreeBSD ones use /bin/sh as
> the parser, which is present in base (ie: there's no reason to explicitly 
> check
> for it, also because it's the same that's used in configure). Linux OTOH uses
> bash as the hotplug script parser, hence this check is needed there.
> 
> Hope this makes sense, Roger.

Yes, it does.

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

[Jan Beulich]

>>> On 14.02.17 at 11:19,  wrote:
> On Tue, Feb 14, 2017 at 10:10:16AM +, Roger Pau Monne wrote:
>> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
>> > >>> On 10.02.17 at 13:33,  wrote:
>> > > --- a/xen/include/asm-x86/page.h
>> > > +++ b/xen/include/asm-x86/page.h
>> > > @@ -374,6 +374,18 @@ perms_strictly_increased(uint32_t old_flags, 
>> > > uint32_t new_flags)
>> > >  return ((of | (of ^ nf)) == nf);
>> > >  }
>> > >  
>> > > +/* Build a 32bit PSE page table using 4MB pages. */
>> > > +static inline void
>> > > +write_32bit_pse_identmap(uint32_t *l2)
>> > 
>> > Why does this need to be an inline function?
>> 
>> Given it's size and the low number of callers I though it would be better to
>> make it inline, but since this is not in any performance critical path I'm
>> going to remove the inlining, although I think the compiler is probably going
>> to do it anyway.
> 
> Right, now I remember why it needs to be inline:
> 
> xen/include/asm/page.h:379:1: error: unused function 
> 'write_32bit_pse_identmap'
>   [-Werror,-Wunused-function]
> write_32bit_pse_identmap(uint32_t *l2)

Funny - when sending the other reply a second ago I did think about
whether this needs clarification, and I decide it's obvious enough.
But it looks like I was wrong: Not inlining the function of course means
moving its definition to a C file, keeping just the declaration here.

Jan


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

[Xen-devel] [PATCH 0/2] x86: context switch handling adjustments

[Jan Beulich]

1: VMX: fix VMCS race on context-switch paths
2: x86: package up context switch hook pointers

Signed-off-by: Jan Beulich 


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

[Xen-devel] [PATCH 2/2] x86: package up context switch hook pointers

[Jan Beulich]

They're all solely dependent on guest type, so we don't need to repeat
all the same four pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.

Since touching it anyway, take the opportunity and move schedule_tail()
into the only C file needing it.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -426,16 +426,8 @@ int vcpu_initialise(struct vcpu *v)
 /* PV guests by default have a 100Hz ticker. */
 v->periodic_period = MILLISECS(10);
 }
-
-v->arch.schedule_tail = continue_nonidle_domain;
-v->arch.ctxt_switch_from = paravirt_ctxt_switch_from;
-v->arch.ctxt_switch_to   = paravirt_ctxt_switch_to;
-
-if ( is_idle_domain(d) )
-{
-v->arch.schedule_tail = continue_idle_domain;
-v->arch.cr3   = __pa(idle_pg_table);
-}
+else
+v->arch.cr3 = __pa(idle_pg_table);
 
 v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
 
@@ -642,8 +634,23 @@ int arch_domain_create(struct domain *d,
 goto fail;
 }
 else
+{
+static const struct arch_csw pv_csw = {
+.from = paravirt_ctxt_switch_from,
+.to   = paravirt_ctxt_switch_to,
+.tail = continue_nonidle_domain,
+};
+static const struct arch_csw idle_csw = {
+.from = paravirt_ctxt_switch_from,
+.to   = paravirt_ctxt_switch_to,
+.tail = continue_idle_domain,
+};
+
+d->arch.ctxt_switch = is_idle_domain(d) ? _csw : _csw;
+
 /* 64-bit PV guest by default. */
 d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
+}
 
 /* initialize default tsc behavior in case tools don't */
 tsc_set_info(d, TSC_MODE_DEFAULT, 0UL, 0, 0);
@@ -1997,7 +2004,7 @@ static void __context_switch(void)
 {
 memcpy(>arch.user_regs, stack_regs, CTXT_SWITCH_STACK_BYTES);
 vcpu_save_fpu(p);
-p->arch.ctxt_switch_from(p);
+pd->arch.ctxt_switch->from(p);
 }
 
 /*
@@ -2023,7 +2030,7 @@ static void __context_switch(void)
 set_msr_xss(n->arch.hvm_vcpu.msr_xss);
 }
 vcpu_restore_fpu_eager(n);
-n->arch.ctxt_switch_to(n);
+nd->arch.ctxt_switch->to(n);
 }
 
 psr_ctxt_switch_to(nd);
@@ -2066,6 +2073,15 @@ static void __context_switch(void)
 per_cpu(curr_vcpu, cpu) = n;
 }
 
+/*
+ * Schedule tail *should* be a terminal function pointer, but leave a bugframe
+ * around just incase it returns, to save going back into the context
+ * switching code and leaving a far more subtle crash to diagnose.
+ */
+#define schedule_tail(vcpu) do {  \
+(((vcpu)->domain->arch.ctxt_switch->tail)(vcpu)); \
+BUG();\
+} while (0)
 
 void context_switch(struct vcpu *prev, struct vcpu *next)
 {
@@ -2100,8 +2116,8 @@ void context_switch(struct vcpu *prev, s
 
 if ( (per_cpu(curr_vcpu, cpu) == next) )
 {
-if ( next->arch.ctxt_switch_same )
-next->arch.ctxt_switch_same(next);
+if ( nextd->arch.ctxt_switch->same )
+nextd->arch.ctxt_switch->same(next);
 local_irq_enable();
 }
 else if ( is_idle_domain(nextd) && cpu_online(cpu) )
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1144,6 +1144,14 @@ void svm_host_osvw_init()
 
 static int svm_domain_initialise(struct domain *d)
 {
+static const struct arch_csw csw = {
+.from = svm_ctxt_switch_from,
+.to   = svm_ctxt_switch_to,
+.tail = svm_do_resume,
+};
+
+d->arch.ctxt_switch = 
+
 return 0;
 }
 
@@ -1155,10 +1163,6 @@ static int svm_vcpu_initialise(struct vc
 {
 int rc;
 
-v->arch.schedule_tail= svm_do_resume;
-v->arch.ctxt_switch_from = svm_ctxt_switch_from;
-v->arch.ctxt_switch_to   = svm_ctxt_switch_to;
-
 v->arch.hvm_svm.launch_core = -1;
 
 if ( (rc = svm_create_vmcb(v)) != 0 )
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -268,8 +268,16 @@ void vmx_pi_hooks_deassign(struct domain
 
 static int vmx_domain_initialise(struct domain *d)
 {
+static const struct arch_csw csw = {
+.from = vmx_ctxt_switch_from,
+.to   = vmx_ctxt_switch_to,
+.same = vmx_vmcs_reload,
+.tail = vmx_do_resume,
+};
 int rc;
 
+d->arch.ctxt_switch = 
+
 if ( !has_vlapic(d) )
 return 0;
 
@@ -295,11 +303,6 @@ static int vmx_vcpu_initialise(struct vc
 
 INIT_LIST_HEAD(>arch.hvm_vmx.pi_blocking.list);
 
-v->arch.schedule_tail= vmx_do_resume;
-v->arch.ctxt_switch_from = vmx_ctxt_switch_from;
-v->arch.ctxt_switch_to   = vmx_ctxt_switch_to;
-v->arch.ctxt_switch_same = vmx_vmcs_reload;
-
 if ( (rc = vmx_create_vmcs(v)) != 0 )
 {
 dprintk(XENLOG_WARNING,
--- 

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

[Wei Liu]

On Thu, Feb 09, 2017 at 11:35:16AM +, George Dunlap wrote:
> On 09/02/17 11:24, Wei Liu wrote:
> > On Thu, Feb 09, 2017 at 11:17:46AM +, George Dunlap wrote:
> >> On 09/02/17 10:35, Wei Liu wrote:
> >>> On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
>  On 08/02/17 16:11, Dario Faggioli wrote:
> > On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
> >> Callers to libxl_cpupool_create() can either request a specific pool
> >> id, or request that Xen do it for them.  But at the moment, the
> >> "automatic" selection is indicated by using a magic value, 0.  This
> >> is
> >> undesirable both because it doesn't obviously have meaning, but also
> >> because '0' is a valid cpupool (albeit one which at the moment can't
> >> be changed).
> >>
> >> Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
> >> instead.  Still accept '0' as meaning "ANY" for backwards
> >> compatibility.
> >>
> >> Signed-off-by: George Dunlap 
> >>
> > Reviewed-by: Dario Faggioli 
> >
> > With one remark.
> >
> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> >> --- a/tools/libxl/libxl.h
> >> +++ b/tools/libxl/libxl.h
> >> @@ -2086,6 +2086,12 @@ int libxl_tmem_shared_auth(libxl_ctx *ctx,
> >> uint32_t domid, char* uuid,
> >>  int libxl_tmem_freeable(libxl_ctx *ctx);
> >>  
> >>  int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
> >> +
> >> +/* 
> >> + * Set poolid to LIBXL_CPUOOL_POOLID_ANY to have Xen choose a
> >> + * free poolid for you.
> >> + */
> >> +#define LIBXL_CPUPOOL_POOLID_ANY 0x
> >>
> > Do we want this to be here, or in libxl_types.idl.
> >
> > Asking because, AFAICT, it's the only one LIBXL_FOO_BAR defined like
> > this. I appreciate that there's few point in making this an enum, as it
> > is only one value, and will most likely remain so, but still, I thought
> > I'd at least bring this up.
> >
> > FWIW, my Reviewed-by stands both if it is kept as is, and if it is
> > moved to IDL.
> 
>  Well there's things like:
> 
>  #define LIBXL_PCI_FUNC_ALL (~0U)
> 
>  #define LIBXL_TIMER_MODE_DEFAULT -1
>  #define LIBXL_MEMKB_DEFAULT ~0ULL
> 
>  #define LIBXL_RDM_MEM_BOUNDARY_MEMKB_DEFAULT (2048 * 1024)
> 
>  #define LIBXL_MS_VM_GENID_LEN 16
> 
>  #define LIBXL_SUSPEND_DEBUG 1
>  #define LIBXL_SUSPEND_LIVE 2
> 
>  Many of which seem similar in some ways.  Enums I think are meant to be
>  exhaustive (as in, contain all possible options), not be special cases.
> 
>  But I'm happy to defer to the tools maintainers.
> 
> >>>
> >>> I don't really care if it is an enum or a macro.
> >>>
> >>> There is an issue that is  more subtle than where it lives or what form
> >>> it is in.
> >>>
> >>> You need to modify all the poolid fields in various structure to make it
> >>> as default.  Otherwise the whole json infrastructure would still use 0
> >>> as the default value.
> >>
> >> Hmm, at the moment there are only two structs that include poolid:
> >> cpupoolinfo, which is OUT-only (so the field should always be
> >> initialized) and domain_create_info, for which 0 is a much better
> >> default logically than "ANY".
> >>
> > 
> > I don't follow here. Isn't 0 already "ANY"?
> 
> No.  This is why I'm bothering to paint this bikeshed: In every context
> *except* "cpupool create", 0 means cpupool0 -- the one that was created
> at boot, which always contains dom0, and which cannot be destroyed.
> (You can only remove all but one of the cpus.)  If you remove a cpupool
> from poolid 0, you remove it from cpupool0, not "any" pool.  If you
> create a domain and ask to put it in poolid 0, it will be put in
> cpupool0, not "any" pool.  The only context in which "0" currently means
> "any" is when you're creating a cpupool.
> 

OK. This makes sense.

> >>> And maybe a LIBXL_HAVE macro is needed, too.
> >>
> >> I thought about that, but figured people could just do #ifdef
> >> LIBXL_CPUPOOL_POOLID_ANY.  It seemed a bit strange to define a whole new
> >> macro just to see if another macro existed.
> >>
> > 
> > I want to reserve the possibility to change that into an enum in the
> > future.
> 
> Yes, I had thought of that -- but like I said, I thought enums were
> meant mostly for things for which there was an exhaustive list.  In this
> case it's a "magic" value for a parameter which normally has a plain
> numerical meaning.
> 
> But I can add the #define if you wish.
> 

You don't need to do that.

Wei.

>  -George

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

Re: [Xen-devel] [PATCH v4 0/3] x86/vvmx: correctly emulate VMREAD and VMWRITE

[Andrew Cooper]

On 13/02/17 14:21, Sergey Dyasli wrote:
> Sergey Dyasli (3):
>   x86/vmx: introduce VMX_INSN_SUCCEED
>   x86/vvmx: correctly emulate VMWRITE
>   x86/vvmx: correctly emulate VMREAD

Committed, thanks.

~Andrew

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

[Xen-devel] [PATCH 1/2] VMX: fix VMCS race on context-switch paths

[Jan Beulich]

When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At the same time the "owning" CPU will re-enable
interrupts eventually (the lastest when entering the idle loop) and
hence becomes subject to IPIs from other CPUs requesting access to the
VMCS. As a result, when __context_switch() finally gets run, the CPU
may no longer have the VMCS loaded, and hence any accesses to it would
fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().

Similarly, when __context_switch() is being bypassed also on the second
(switch-in) path, VMCS ownership may have been lost and hence needs
re-establishing. Since there's no existing hook to put this in, add a
new one.

Reported-by: Kevin Mayer 
Reported-by: Anshul Makkar 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2098,11 +2098,14 @@ void context_switch(struct vcpu *prev, s
 
 set_current(next);
 
-if ( (per_cpu(curr_vcpu, cpu) == next) ||
- (is_idle_domain(nextd) && cpu_online(cpu)) )
+if ( (per_cpu(curr_vcpu, cpu) == next) )
 {
+if ( next->arch.ctxt_switch_same )
+next->arch.ctxt_switch_same(next);
 local_irq_enable();
 }
+else if ( is_idle_domain(nextd) && cpu_online(cpu) )
+local_irq_enable();
 else
 {
 __context_switch();
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -552,6 +552,27 @@ static void vmx_load_vmcs(struct vcpu *v
 local_irq_restore(flags);
 }
 
+void vmx_vmcs_reload(struct vcpu *v)
+{
+/*
+ * As we're running with interrupts disabled, we can't acquire
+ * v->arch.hvm_vmx.vmcs_lock here. However, with interrupts disabled
+ * the VMCS can't be taken away from us anymore if we still own it.
+ */
+ASSERT(!local_irq_is_enabled());
+if ( v->arch.hvm_vmx.vmcs_pa == this_cpu(current_vmcs) )
+return;
+ASSERT(!this_cpu(current_vmcs));
+
+/*
+ * Wait for the remote side to be done with the VMCS before loading
+ * it here.
+ */
+while ( v->arch.hvm_vmx.active_cpu != -1 )
+cpu_relax();
+vmx_load_vmcs(v);
+}
+
 int vmx_cpu_up_prepare(unsigned int cpu)
 {
 /*
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -298,6 +298,7 @@ static int vmx_vcpu_initialise(struct vc
 v->arch.schedule_tail= vmx_do_resume;
 v->arch.ctxt_switch_from = vmx_ctxt_switch_from;
 v->arch.ctxt_switch_to   = vmx_ctxt_switch_to;
+v->arch.ctxt_switch_same = vmx_vmcs_reload;
 
 if ( (rc = vmx_create_vmcs(v)) != 0 )
 {
@@ -936,6 +937,18 @@ static void vmx_ctxt_switch_from(struct
 if ( unlikely(!this_cpu(vmxon)) )
 return;
 
+if ( !v->is_running )
+{
+/*
+ * When this vCPU isn't marked as running anymore, a remote pCPU's
+ * attempt to pause us (from vmx_vmcs_enter()) won't have a reason
+ * to spin in vcpu_sleep_sync(), and hence that pCPU might have taken
+ * away the VMCS from us. As we're running with interrupts disabled,
+ * we also can't call vmx_vmcs_enter().
+ */
+vmx_vmcs_reload(v);
+}
+
 vmx_fpu_leave(v);
 vmx_save_guest_msrs(v);
 vmx_restore_host_msrs();
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -514,6 +514,7 @@ struct arch_vcpu
 
 void (*ctxt_switch_from) (struct vcpu *);
 void (*ctxt_switch_to) (struct vcpu *);
+void (*ctxt_switch_same) (struct vcpu *);
 
 struct vpmu_struct vpmu;
 
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -174,6 +174,7 @@ void vmx_destroy_vmcs(struct vcpu *v);
 void vmx_vmcs_enter(struct vcpu *v);
 bool_t __must_check vmx_vmcs_try_enter(struct vcpu *v);
 void vmx_vmcs_exit(struct vcpu *v);
+void vmx_vmcs_reload(struct vcpu *v);
 
 #define CPU_BASED_VIRTUAL_INTR_PENDING0x0004
 #define CPU_BASED_USE_TSC_OFFSETING   0x0008


VMX: fix VMCS race on context-switch paths

When __context_switch() is being bypassed during original context
switch handling, the vCPU "owning" the VMCS partially loses control of
it: It will appear non-running to remote CPUs, and hence their attempt
to pause the owning vCPU will have no effect on it (as it already
looks to be paused). At the same time the "owning" CPU will re-enable
interrupts eventually (the lastest when entering the idle loop) and
hence becomes subject to IPIs from other CPUs requesting access to the
VMCS. As a result, when __context_switch() finally gets run, the CPU
may no longer have the VMCS loaded, and hence any accesses to it would
fail. Hence we may need to re-load the VMCS in vmx_ctxt_switch_from().

Similarly, when 

Re: [Xen-devel] [PATCH 2/5] x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c

[Andrew Cooper]

On 14/02/17 10:33, Jan Beulich wrote:
 On 13.02.17 at 14:03,  wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -0,0 +1,332 @@
>> +/**
>> + * arch/hvm/hypercall.c
>> + *
>> + * HVM hypercall dispatching routines
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; If not, see .
>> + *
>> + * Copyright (c) 2017 Citrix Systems Ltd.
>> + */
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +static int grant_table_op_is_allowed(unsigned int cmd)
>> +{
>> +switch (cmd) {
> Pure code motion or not, I think it would be nice to fix coding style
> (here and elsewhere, albeit the only other issue I can spot are a
> few missing blanks lines between non-fall-through case statements).
>
> With that
> Acked-by: Jan Beulich 

I believe all of those issues are addressed in the following patches. 
If not, I can certainly fix them up here.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/vmx: fix compilation after 997382

[Jan Beulich]

>>> On 14.02.17 at 11:37,  wrote:
> 997382 introduced the following errors:
> 
> intr.c:342:46: error: address of array 'vlapic->regs->data' will always 
> evaluate to 'true'
>   [-Werror,-Wpointer-bool-conversion]
> if ( vlapic && vlapic->regs->data )
> ~~ ~~^~~~
> intr.c:352:42: error: address of array 'pi_desc->pir' will always evaluate to 
> 'true'
>   [-Werror,-Wpointer-bool-conversion]
> if ( pi_desc && pi_desc->pir )
>  ~~ ~^~~
> Both of those checks are done against static arrays, which doesn't seem to 
> make
> much sense, so just remove them.

Darn, I had meant to check while massaging the patch, but then
forgot.

> Signed-off-by: Roger Pau Monné 
> ---
> NB: maybe the first check should be against vlapic->regs?

Yes, please. Or I can do this while committing. The subject, btw,
should probably include "clang", as neither I nor osstest have an
issue with gcc?

Jan

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

Re: [Xen-devel] [PATCH v2 01/11] x86emul: catch exceptions occurring in stubs

[Andrew Cooper]

On 13/02/17 16:20, Jan Beulich wrote:
 On 13.02.17 at 14:58,  wrote:
>> On 13/02/17 11:40, Jan Beulich wrote:
>> On 10.02.17 at 17:38,  wrote:
 On 01/02/17 11:12, Jan Beulich wrote:
> Before adding more use of stubs cloned from decoded guest insns, guard
> ourselves against mistakes there: Should an exception (with the
> noteworthy exception of #PF) occur inside the stub, forward it to the
> guest.
 Why exclude #PF ? Nothing in a stub should be hitting a pagefault in the
 first place.
>>> To be honest, I've been considering to limit this to just #UD. We
>>> clearly shouldn't hide memory addressing issues, as them going
>>> by silently means information leaks. Nevertheless including #PF
>>> here would be a trivial change to the patch.
>> When I considered this first, my plan was to catch the fault and crash
>> the domain, rather than allow it to continue (FPU exceptions being the
>> exception).
>>
>> One way or another, by the time we encounter a fault in the stubs,
>> something has gone wrong, and crashing the domain is better than
>> crashing the host.  (In fact, I am looking to extend this principle
>> further, e.g. with vmread/vmwrite failures.)
>>
>> I don't see #PF being meaningfully different to #GP or #SS here.  If we
>> get a fault, an action was stopped, but we can never catch the issues
>> which don't fault in the first place.
>>
>> #UD is a little more tricky.  It either means that we created a
>> malformed stub, or we didn't have sufficient feature checking, both of
>> which are emulation bugs.  This could be passed back to the domain, but
>> I'd err on the side of making it more obvious by crashing the domain. 
> Generally yes, but I think here we really should forward at least
> #UD. I can agree with other faults being terminal to the domain,
> which will the also allow #PF to be handled uniformly (as there
> won't be a need to propagate some CR2 value).
>
>> (Perhaps changing behaviour based on debug?)
> Not here, I would say - this logic should be tested the way it is
> meant to be run in production.

Ok.  Could we at least get a printk() in the case of handing a fault
like this back to the guest, so we stand a chance of noticing the
emulation bug and fixing it?

>
> ---
> There's one possible caveat here: A stub invocation immediately
> followed by another instruction having fault revovery attached to it
> would not work properly, as the table lookup can only ever find one of
> the two entries. Such CALL instructions would then need to be followed
> by a NOP for disambiguation (even if only a slim chance exists for the
> compiler to emit things that way).
 Why key on return address at all?  %rip being in the stubs should be
 good enough.
>>> Well, we need unique (key-address, recovery-address) tuples,
>>> and key-address can't possibly be an address inside the stub
>>> (for both the address varying between CPUs and said uniqueness
>>> requirement).
>> We don't necessarily need to use the extable infrastructure, and you
>> don't appear to be using a unique key at all.
> How am I not? How would both the self test and the emulator
> uses work without unique addresses to key off of?

I'd not followed how you were hooking the information up.  Sorry for the
noise.

> @@ -85,15 +86,88 @@ search_one_extable(const struct exceptio
>  }
>  
>  unsigned long
> -search_exception_table(unsigned long addr)
> +search_exception_table(const struct cpu_user_regs *regs, bool check_stub)
>  {
> -const struct virtual_region *region = find_text_region(addr);
> +const struct virtual_region *region = find_text_region(regs->rip);
> +unsigned long stub = this_cpu(stubs.addr);
>  
>  if ( region && region->ex )
> -return search_one_extable(region->ex, region->ex_end - 1, addr);
> +return search_one_extable(region->ex, region->ex_end - 1, 
> regs->rip);
> +
> +if ( check_stub &&
> + regs->rip >= stub + STUB_BUF_SIZE / 2 &&
> + regs->rip < stub + STUB_BUF_SIZE &&
> + regs->rsp > (unsigned long)_stub &&
> + regs->rsp < (unsigned long)get_cpu_info() )
 How much do we care about accidentally clobbering %rsp in a stub?
>>> I think we can't guard against everything, but we should do the
>>> best we reasonably can. I.e. in the case here, rather than
>>> reading the return (key) address from somewhere outside the
>>> stack (easing a possible attacker's job), don't handle the fault
>>> at all, and instead accept the crash.
>> As before, it would be better overall to result in a domain_crash() than
>> a host crash.
> Yes (see above), but in no case should we do the crashing here
> (or else, even if it may seem marginal, the self test won't work
> anymore). To provide best functionality to current and possible
> future uses, we should leave the 

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest

[Kang, Luwei]

> >>> On 14.02.17 at 03:19,  wrote:
> > vpmu_enable() can not use for check if vpmu is enabled in guest during
> > booting up. Because linux kernel get the status of if supported pmu is
> > earler than xen vpmu initialise. vpmu_enable() will return false even
> > if vpmu has been enabled in guest.
> >
> > Signed-off-by: Luwei Kang 
> 
> You've probably seen Boris' patch with the same overall goal. While his looks 
> to leave things a little too strict, yours looks to be widening
> things a little too much. Do both of you think we could find a middle ground, 
> or do we need to accept the effect of possibly misleading
> the guest by surfacing the CPUID data independent of vPMU mode, as is done 
> here?
> 
Sorry, I didn't check the mail list on time and don't know somebody is working 
on this.  I think Boris' patch is better than me.

Thanks,
Luwei Kang

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

[Xen-devel] [libvirt test] 105785: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  723fef99c0e29d1a327aaea4cef477609f6ccbc2
baseline version:
 libvirt  5620c609596cdfb3b809afab1b37b7f00fe831a1

Last test of basis   105720  2017-02-11 04:21:00 Z3 days
Failing since105759  2017-02-13 04:20:10 Z1 days2 attempts
Testing same since   105785  2017-02-14 04:20:10 Z0 days1 attempts


People who touched revisions under test:
  Ján Tomko 
  Marc Hartmayer 
  Roman Bogorodskiy 

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

Re: [Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

[Jan Beulich]

>>> On 14.02.17 at 11:10,  wrote:
> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
>> >>> On 10.02.17 at 13:33,  wrote:
>> > +static int __init pvh_steal_ram(struct domain *d, unsigned long size,
>> > +unsigned long align, paddr_t limit,
>> > +paddr_t *addr)
>> > +{
>> > +unsigned int i = d->arch.nr_e820;
>> > +
>> > +/*
>> > + * Alignment 0 should be set to 1, so it doesn't wrap around in the
>> > + * calculations below.
>> > + */
>> > +align = align ? : 1;
>> > +while ( i-- )
>> > +{
>> > +struct e820entry *entry = >arch.e820[i];
>> > +
>> > +if ( entry->type != E820_RAM || entry->addr + entry->size > limit 
>> > ||
>> > + entry->addr < MB(1) )
>> > +continue;
>> > +
>> > +*addr = (entry->addr + entry->size - size) & ~(align - 1);
>> 
>> Without taking the present callers into account (who don't request
>> huge alignment) this (theoretically) risks running into the low 1Mb.
>> I see two options - either add a comment clarifying that an entry
>> will never cross the 1Mb boundary (and hence the issue can't
>> occur), or limit the alignment (by way of ASSERT()) to PAGE_SIZE
>> (in which case no significant harm would result from crossing the
>> boundary).
> 
> I don't mind adding the ASSERT, but I don't see how this can risk running into
> the low 1MB. If entry->addr < MB(1) the entry is skipped. If an entry crosses
> the 1Mb boundary it will certainly have entry->addr < 1Mb.

Oh, of course. I'm sorry for the noise (and the code here is fine
then as is).

>> > --- a/xen/include/asm-x86/page.h
>> > +++ b/xen/include/asm-x86/page.h
>> > @@ -374,6 +374,18 @@ perms_strictly_increased(uint32_t old_flags, uint32_t 
>> > new_flags)
>> >  return ((of | (of ^ nf)) == nf);
>> >  }
>> >  
>> > +/* Build a 32bit PSE page table using 4MB pages. */
>> > +static inline void
>> > +write_32bit_pse_identmap(uint32_t *l2)
>> 
>> Why does this need to be an inline function?
> 
> Given it's size and the low number of callers I though it would be better to
> make it inline, but since this is not in any performance critical path I'm
> going to remove the inlining, although I think the compiler is probably going
> to do it anyway.

I don't think so, unless you use LTO, as the function body can be
visible in at most one of the two CUs containing a call to it.

Jan


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

Re: [Xen-devel] [PATCH] x86/vpmu: fix vpmu can't enabled in guest

[Andrew Cooper]

On 14/02/17 02:19, Luwei Kang wrote:
> vpmu_enable() can not use for check if vpmu is enabled in guest during
> booting up. Because linux kernel get the status of if supported pmu
> is earler than xen vpmu initialise. vpmu_enable() will return false
> even if vpmu has been enabled in guest.

Sorry for breaking this.  However ...

> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index e0a387e..b63c5d8 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -713,8 +713,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
> struct cpuid_leaf *res)
>  }
>  }
>  
> -if ( vpmu_enabled(curr) &&
> - vpmu_is_set(vcpu_vpmu(curr), VPMU_CPU_HAS_DS) )
> +if ( opt_vpmu_enabled && boot_cpu_has(X86_FEATURE_DS) )

... this is overly general.  The visibility of these flags must be per
domain, and not globally like this.

In particular, XENPMU_MODE_ALL needs to expose PMU to dom0, but hide it
from all other domains, while even in the XENPMU_MODE_SELF case, only
domains explicitly configured with PMU should see it (as it generally
unsafe to migrate with).

Longterm (with the inclusion of the CPUID improvements), my plan was to
have PMU available in the max policy but hidden in the default policy,
which requires the toolstack to explicitly opt in for domains.  It would
opt in/out by setting the version field in guests CPUID policy and the
other feature bits.

~Andrew

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

Re: [Xen-devel] [PATCH 2/5] x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c

[Jan Beulich]

>>> On 13.02.17 at 14:03,  wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -0,0 +1,332 @@
> +/**
> + * arch/hvm/hypercall.c
> + *
> + * HVM hypercall dispatching routines
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + *
> + * Copyright (c) 2017 Citrix Systems Ltd.
> + */
> +#include 
> +#include 
> +
> +#include 
> +
> +static int grant_table_op_is_allowed(unsigned int cmd)
> +{
> +switch (cmd) {

Pure code motion or not, I think it would be nice to fix coding style
(here and elsewhere, albeit the only other issue I can spot are a
few missing blanks lines between non-fall-through case statements).

With that
Acked-by: Jan Beulich 

Jan


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

[Xen-devel] [PATCH] x86/vmx: fix compilation after 997382

[Roger Pau Monne]

997382 introduced the following errors:

intr.c:342:46: error: address of array 'vlapic->regs->data' will always 
evaluate to 'true'
  [-Werror,-Wpointer-bool-conversion]
if ( vlapic && vlapic->regs->data )
~~ ~~^~~~
intr.c:352:42: error: address of array 'pi_desc->pir' will always evaluate to 
'true'
  [-Werror,-Wpointer-bool-conversion]
if ( pi_desc && pi_desc->pir )
 ~~ ~^~~
Both of those checks are done against static arrays, which doesn't seem to make
much sense, so just remove them.

Signed-off-by: Roger Pau Monné 
---
NB: maybe the first check should be against vlapic->regs?
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Chao Gao 
---
 xen/arch/x86/hvm/vmx/intr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 1e17c4e..b9a02d1 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -339,7 +339,7 @@ void vmx_intr_assist(void)
current, intack.source, intack.vector, pt_vector);
 
 vlapic = vcpu_vlapic(v);
-if ( vlapic && vlapic->regs->data )
+if ( vlapic )
 {
 word = (const void *)>regs->data[APIC_IRR];
 printk(XENLOG_ERR "vIRR:");
@@ -349,7 +349,7 @@ void vmx_intr_assist(void)
 }
 
 pi_desc = >arch.hvm_vmx.pi_desc;
-if ( pi_desc && pi_desc->pir )
+if ( pi_desc )
 {
 word = (const void *)_desc->pir;
 printk(XENLOG_ERR " PIR:");
-- 
2.10.1 (Apple Git-78)


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

Re: [Xen-devel] [PATCH 5/5] x86/hvm: Improve physdev_op hypercall dispatching

[Jan Beulich]

>>> On 13.02.17 at 14:03,  wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -73,10 +73,12 @@ static long hvm_grant_table_op(
>  
>  static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
> +struct vcpu *curr = current;

With this constified
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Paul Durrant]

My previous reply got bounced because my tablet insisted on using HTML...

> -Original Message-
> 
> These need to be static. (I can fix it when committing.)

Ok, thanks.

> 
> And I am still not sure about using XEN_PAGE_SIZE. There is no
> dependency in the hypervisor on buffers being page-sized, is there? If
> not, XEN_PAGE_SIZE is here just because it happens to be 4K, which is a
> reasonable value.
> 
> How about just setting it to 4096?
> 

I chose XEN_PAGE_SIZE because the hypercall will eventually copy in the buffer 
so it seemed like a reasonable value to use. If you want to just use 4096 then 
I am ok with that.

  Paul

PS: If you want to change from XEN_PAGE_SIZE to 4096 then I assume you are 
happy to do this at commit and don't need me to send a v4?

> 
> -boris

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

Re: [Xen-devel] [PATCH] X86/vmx: Dump PIR and vIRR before ASSERT()

[Jan Beulich]

>>> On 07.02.17 at 00:32,  wrote:
> Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
> added a assertion that intack.vector is the highest priority vector. But
> according to the osstest, the assertion failed sometimes. More discussion can
> be found in the thread
> (https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.html).
> 
> The assertion failure is hard to reproduce. In order to root cause issue, this
> patch is to add logs to dump PIR and vIRR when failure takes place. It should
> be reverted once the root cause is found.

Julien, could you add a note on the 4.9 tracking list for us to not
forget to revert this (or at least add NDEBUG conditionals) the
latest in the RC phase?

Thanks, Jan


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

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

[Tian, Kevin]

> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew Cooper
> Sent: Tuesday, February 14, 2017 4:19 PM
> 
> On 14/02/2017 08:04, Tian, Kevin wrote:
> >> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
> Cooper
> >> Sent: Tuesday, February 14, 2017 3:59 PM
> >>
> >> On 14/02/2017 02:52, Tian, Kevin wrote:
>  From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>  Sent: Monday, February 13, 2017 10:32 PM
> 
>  hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to 
>  be
>  restored when switching into guest context.  It should never have been 
>  part of
>  the migration state to start with, and Xen must not make any decisions 
>  based
>  on the value seen during restore.
> 
>  Identify it as obsolete in the header files, consistently save it as 
>  zero and
>  ignore it on restore.
> 
>  The MSRs must be considered dirty during VMCS creation to cause the 
>  proper
>  defaults of 0 to be visible to the guest.
> 
>  Signed-off-by: Andrew Cooper 
> >>> Reviewed-by: Kevin Tian , with one small comment.
> >>>
> >>> the effect of this patch should be more than not leaking syscall MSR.
> >>> what about making the subject clearer when check-in?
> >> What other effects do you think are going on here?  Yes, we now context
> >> switch the MSRs right from the start of the domain, but that is
> >> necessary to avoid leaking them.
> >>
> > If just looking at this patch, it's for general MSR save/restore policy,
> > nothing specific to syscall MSR.
> 
> The only three MSRs which use this infrastructure are LSTAR, STAR and
> FMASK.  What if I were to clarify that in the first paragraph?
> 
> ~Andrew

I meant the subject line (talk about syscall MSR leakage) mismatches the 
commit message (for general MSR load)

Thanks
Kevin

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

Re: [Xen-devel] [PATCH] x86/vmx: fix compilation after 997382

[Roger Pau Monne]

On Tue, Feb 14, 2017 at 03:46:37AM -0700, Jan Beulich wrote:
> >>> On 14.02.17 at 11:37,  wrote:
> > 997382 introduced the following errors:
> > 
> > intr.c:342:46: error: address of array 'vlapic->regs->data' will always 
> > evaluate to 'true'
> >   [-Werror,-Wpointer-bool-conversion]
> > if ( vlapic && vlapic->regs->data )
> > ~~ ~~^~~~
> > intr.c:352:42: error: address of array 'pi_desc->pir' will always evaluate 
> > to 
> > 'true'
> >   [-Werror,-Wpointer-bool-conversion]
> > if ( pi_desc && pi_desc->pir )
> >  ~~ ~^~~
> > Both of those checks are done against static arrays, which doesn't seem to 
> > make
> > much sense, so just remove them.
> 
> Darn, I had meant to check while massaging the patch, but then
> forgot.
> 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > NB: maybe the first check should be against vlapic->regs?
> 
> Yes, please. Or I can do this while committing. The subject, btw,
> should probably include "clang", as neither I nor osstest have an
> issue with gcc?

If you don't mind please change the check while committing, so that it's
against vlapic->regs. Regarding the subject, what about:

x86/vmx: fix compilation with clang after 997382

FWIW, neither the versions of clang in travis seem to pick this up:

https://travis-ci.org/xen-project/xen/builds/201180775

Thanks, Roger.

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

[Xen-devel] [PATCH v3 2/2] build/printf: fix incorrect format specifiers

[Roger Pau Monne]

The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:

mce.c:601:18: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
 smp_processor_id());
 ^

xenpm.c:102:23: error: data argument not used by format string 
[-Werror,-Wformat-extra-args]
what, argv[argc > 1]);
  ^

libxl_internal.c:25:69: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^
libxl_internal.c:26:21: error: data argument not used by format string
  [-Werror,-Wformat-extra-args]
fprintf(stderr, L);
^
libxl_internal.c:24:17: note: expanded from macro 'L'
  func, (unsigned long)nmemb, (unsigned long)size
^

This patch contains the fixes for them and enables -Wformat for clang.

Signed-off-by: Roger Pau Monné 
Acked-by: Andrew Cooper 
---
NB: FWIW, there's a way to disable extra arguments checks
(-Wno-format-extra-args), that would prevent us from having to apply some of
the changes here. However, given that there are not that many occurrences, I
would rather leave the full checks of Wformat enabled.

NB2: this has only been tested with a FreeBSD clang build (3.8.0), and only
against the components that build on FreeBSD (ie: no qemu-trad, and certainly
no blktap).
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Christoph Egger 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Change the format string for MCE to avoid duplicating CPU%i.
 - Remove the grant-ref format specifier change, it's already taken care in
   patch #1.
---
 Config.mk |  2 +-
 tools/libxl/libxl_internal.c  | 21 -
 tools/misc/xenpm.c| 13 -
 xen/arch/x86/cpu/mcheck/mce.c |  5 ++---
 4 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/Config.mk b/Config.mk
index 3a1d960..4739f36 100644
--- a/Config.mk
+++ b/Config.mk
@@ -215,7 +215,7 @@ CFLAGS += -Wall -Wstrict-prototypes
 # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
 # and is over-zealous with the printf format lint
 # and is a bit too fierce about unused return values
-CFLAGS-$(clang) += -Wno-parentheses -Wno-format -Wno-unused-value
+CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d288215..f492dae 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -20,14 +20,25 @@
 void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
  size_t nmemb, size_t size) {
 #define M "libxl: FATAL ERROR: memory allocation failure"
-#define L (size ? M " (%s, %lu x %lu)\n" : M " (%s)\n"), \
-  func, (unsigned long)nmemb, (unsigned long)size
-libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
-fprintf(stderr, L);
+#define M_SIZE M " (%s, %lu x %lu)\n"
+#define M_NSIZE M " (%s)\n"
+if (size) {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_SIZE, func, (unsigned long)nmemb, (unsigned long)size);
+   fprintf(stderr, M_SIZE, func, (unsigned long)nmemb,
+   (unsigned long)size);
+} else {
+   libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0, 0, func, INVALID_DOMID,
+  M_NSIZE, func);
+   fprintf(stderr, M_NSIZE, func);
+
+}
+
 fflush(stderr);
 _exit(-1);
+#undef M_NSIZE
+#undef M_SIZE
 #undef M
-#undef L
 }
 
 void libxl__ptr_add(libxl__gc *gc, void *ptr)
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index a2edee5..ded40b9 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -93,13 +93,16 @@ static void parse_cpuid(const char *arg, int *cpuid)
 static void parse_cpuid_and_int(int argc, char *argv[],
 int *cpuid, int *val, const char *what)
 {
-if ( argc > 1 )
-parse_cpuid(argv[0], cpuid);
+if ( argc == 0 )
+{
+ fprintf(stderr, "Missing %s\n", what);
+ exit(EINVAL);
+}
 
-if ( argc == 0 || sscanf(argv[argc > 1], "%d", val) != 1 )
+parse_cpuid(argv[0], cpuid);
+if ( sscanf(argv[1], "%d", val) != 1 )
 {
-fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
-what, argv[argc > 1]);
+fprintf(stderr, "Invalid %s '%s'\n", what, argv[1]);
   

[Xen-devel] [PATCH v3 0/2] Enable Wformat for clang

[Roger Pau Monne]

Hello,

These patches fix the remaining issues so that Wformat can be enabled for
clang.

This patches have been tested on FreeBSD with clang 3.8, and travis:

https://travis-ci.org/royger/xen/builds/201165863

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

[Jan Beulich]

>>> On 13.02.17 at 19:26,  wrote:
> On 13/02/17 13:19, Jan Beulich wrote:
>> ---
>> TBD: Do we really want to re-init the TSS every time we are about to
>>  use it? This can happen quite often during boot, especially while
>>  grub is running.
> 
> The only case we need worry about is if the guest manually writes to the
> area covered by the vm86 tss.  I think, looking at the logic, that we
> properly restore the old %tr when re-entering protected mode, so we
> aren't at risk of having the vm86 tss on the leaving-side of a hardware
> task switch.

Yes. But that's the whole point of the question: The guest could
equally well write to the TSS manually right after we've initialized
it. And it only harms itself by doing so, hence we could as well
init the TSS on a less frequently executed path.

> We have lasted thus far without, but given the issues recently
> identified, the only safe conclusion to be drawn is that this
> functionality hasn't been used in anger.
> 
> For sensible performance, we need to keep the IO bitmap clear to avoid
> taking the #GP emulation path.
> 
> For correct behaviour, we need the entire software bitmap to be 0.

This one is just for reasonable performance too, afaict. If faulting,
just like with port accesses, we'd emulate the INT $nn.

>> +void hvm_prepare_vm86_tss(struct vcpu *v, uint32_t base, uint32_t limit)
>> +{
>> +/*
>> + * If the provided area is large enough to cover at least the ISA port
>> + * range, keep the bitmaps outside the base structure. For rather small
>> + * areas (namely relevant for guests having been migrated from older
>> + * Xen versions), maximize interrupt vector and port coverage by 
>> pointing
>> + * the I/O bitmap at 0x20 (which puts the interrupt redirection bitmap
>> + * right at zero), accepting accesses to port 0x235 (represented by bit 
>> 5
>> + * of byte 0x46) to trigger #GP (which will simply result in the access
>> + * being handled by the emulator via a slightly different path than it
>> + * would be anyway). Be sure to include one extra byte at the end of the
>> + * I/O bitmap (hence the missing "- 1" in the comparison is not an
>> + * off-by-one mistake), which we deliberately don't fill with all ones.
>> + */
>> +uint16_t iomap = (limit >= sizeof(struct tss32) + (0x100 / 8) + (0x400 
>> / 8)
>> +  ? sizeof(struct tss32) : 0) + (0x100 / 8);
>> +
>> +ASSERT(limit >= sizeof(struct tss32) - 1);
>> +hvm_copy_to_guest_phys(base, NULL, limit + 1, v);
>> +hvm_copy_to_guest_phys(base + offsetof(struct tss32, iomap),
>> +   , sizeof(iomap), v);
> 
> This should be linear rather than phys.

Strictly speaking yes, but since we're running with an ident map,
it doesn't matter. And I'd prefer not to have to introduce a vcpu
parameter to the linear copy function, as that would mean quite
a few changes elsewhere. Would you be okay with me just
attaching a respective comment here?

> In practice it will only make a difference if the guest manages to
> corrupt its IDENT_PT (which is why I suggested that we move the IDENT_PT
> entirely outside of the guest control), but in such a case, we will
> re-enter the guest with the vm86 tss pointing to something other than
> what we have just initialised.

Right, but again the guest would only harm itself.

>> @@ -4484,6 +4511,31 @@ static int hvmop_set_param(
>>  }
>>  d->arch.x87_fip_width = a.value;
>>  break;
>> +
>> +case HVM_PARAM_VM86_TSS:
>> +/* Hardware would silently truncate high bits. */
> 
> Does it?  I'd have thought it would be a vmentry failure.

I'm pretty sure I've tried it out, as I didn't have it that way initially.
I think a VM entry failure would result only if the address was
non-canonical.

Jan


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

[Xen-devel] [qemu-mainline test] 105781: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu305e6c8a2ff7a6e3f4942b50e853230f18eeb5a9
baseline version:
 qemuu6fe791b5e3aca8a6de8a322e85e76d2f13338a7e

Last test of basis   105279  2017-02-02 10:18:27 Z   11 days
Failing since105294  2017-02-02 16:42:47 Z   11 days   79 attempts
Testing same since   105775  2017-02-13 19:18:39 Z0 days2 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alex Williamson 
  Alexander Graf 
  Alexander Indenbaum 
  Andrea Bolognani 
  Anthony PERARD 
  Avinesh Kumar 
  Bharata B Rao 
  Cao jin 
  Christian Borntraeger 
  Cédric Le Goater 
  Daniel 

Re: [Xen-devel] [PATCH 1/4] x86/vmx: Don't leak host syscall MSR state into HVM guests

[Jan Beulich]

>>> On 14.02.17 at 09:40,  wrote:
>>  From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew 
>> Cooper
>> Sent: Tuesday, February 14, 2017 4:19 PM
>> 
>> On 14/02/2017 08:04, Tian, Kevin wrote:
>> >> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of Andrew
>> Cooper
>> >> Sent: Tuesday, February 14, 2017 3:59 PM
>> >>
>> >> On 14/02/2017 02:52, Tian, Kevin wrote:
>>  From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>>  Sent: Monday, February 13, 2017 10:32 PM
>> 
>>  hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing 
>>  to be
>>  restored when switching into guest context.  It should never have been 
>>  part of
>>  the migration state to start with, and Xen must not make any decisions 
>>  based
>>  on the value seen during restore.
>> 
>>  Identify it as obsolete in the header files, consistently save it as 
>>  zero and
>>  ignore it on restore.
>> 
>>  The MSRs must be considered dirty during VMCS creation to cause the 
>>  proper
>>  defaults of 0 to be visible to the guest.
>> 
>>  Signed-off-by: Andrew Cooper 
>> >>> Reviewed-by: Kevin Tian , with one small comment.
>> >>>
>> >>> the effect of this patch should be more than not leaking syscall MSR.
>> >>> what about making the subject clearer when check-in?
>> >> What other effects do you think are going on here?  Yes, we now context
>> >> switch the MSRs right from the start of the domain, but that is
>> >> necessary to avoid leaking them.
>> >>
>> > If just looking at this patch, it's for general MSR save/restore policy,
>> > nothing specific to syscall MSR.
>> 
>> The only three MSRs which use this infrastructure are LSTAR, STAR and
>> FMASK.  What if I were to clarify that in the first paragraph?
> 
> I meant the subject line (talk about syscall MSR leakage) mismatches the 
> commit message (for general MSR load)

I'm with Andrew here: The title seems perfectly fine to me, considering
that the generic mechanism is only used for the syscall MSRs. Hence I
would think his offer to clarify the change in the first paragraph of the
commit message ought to suffice. Otherwise, may I ask that you make
a concrete suggestion as to what you'd like to see?

Jan


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

Re: [Xen-devel] [PATCH v6 3/7] xen/x86: populate PVHv2 Dom0 physical memory map

[Roger Pau Monne]

On Tue, Feb 14, 2017 at 10:10:16AM +, Roger Pau Monne wrote:
> On Mon, Feb 13, 2017 at 06:53:49AM -0700, Jan Beulich wrote:
> > >>> On 10.02.17 at 13:33,  wrote:
> > > --- a/xen/include/asm-x86/page.h
> > > +++ b/xen/include/asm-x86/page.h
> > > @@ -374,6 +374,18 @@ perms_strictly_increased(uint32_t old_flags, 
> > > uint32_t new_flags)
> > >  return ((of | (of ^ nf)) == nf);
> > >  }
> > >  
> > > +/* Build a 32bit PSE page table using 4MB pages. */
> > > +static inline void
> > > +write_32bit_pse_identmap(uint32_t *l2)
> > 
> > Why does this need to be an inline function?
> 
> Given it's size and the low number of callers I though it would be better to
> make it inline, but since this is not in any performance critical path I'm
> going to remove the inlining, although I think the compiler is probably going
> to do it anyway.

Right, now I remember why it needs to be inline:

xen/include/asm/page.h:379:1: error: unused function 'write_32bit_pse_identmap'
  [-Werror,-Wunused-function]
write_32bit_pse_identmap(uint32_t *l2)

Roger.

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

Re: [Xen-devel] [PATCH 4/5] x86/hvm: Improve grant_table_op hypercall dispatching

[Jan Beulich]

>>> On 13.02.17 at 14:03,  wrote:
> hvm_grant_table_op() and hvm_grant_table_op_compat32() are almost identical,
> but there is no need to have two functions instantiated at the end of
> different function pointers.
> 
> Combine the two into a single hvm_grant_table_op() (folding
> grant_table_op_is_allowed() into is now-single caller) and dispatch to
> {do,compat}_grant_table_op() based on the hcall_64bit setting.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 3/5] x86/hvm: Improve memory_op hypercall dispatching

[Jan Beulich]

>>> On 13.02.17 at 14:03,  wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -23,6 +23,29 @@
>  
>  #include 
>  
> +static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
> +{
> +struct vcpu *curr = current;

const? (yes, you modify *curr->domain below, but *curr isn't being
altered)

Other than that
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 2/5] x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c

[Jan Beulich]

>>> On 14.02.17 at 11:33,  wrote:
> On 14/02/17 10:33, Jan Beulich wrote:
> On 13.02.17 at 14:03,  wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -0,0 +1,332 @@
>>> 
> +/***
> ***
>>> + * arch/hvm/hypercall.c
>>> + *
>>> + * HVM hypercall dispatching routines
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program; If not, see .
>>> + *
>>> + * Copyright (c) 2017 Citrix Systems Ltd.
>>> + */
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +static int grant_table_op_is_allowed(unsigned int cmd)
>>> +{
>>> +switch (cmd) {
>> Pure code motion or not, I think it would be nice to fix coding style
>> (here and elsewhere, albeit the only other issue I can spot are a
>> few missing blanks lines between non-fall-through case statements).
>>
>> With that
>> Acked-by: Jan Beulich 
> 
> I believe all of those issues are addressed in the following patches. 
> If not, I can certainly fix them up here.

Right, I've just seen that while going through the later ones.
Either way is fine with me.

Jan


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

[Xen-devel] [distros-debian-snapshot test] 68556: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-i386-daily-netboot-pygrub 10 guest-start fail REGR. vs. 68530
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail REGR. vs. 
68530
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 
68530

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
68530
 test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start   fail like 68530
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 68530
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 68530
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 68530
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 68530

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   68530

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-arm64-arm64-armhf-daily-netboot-pygrub  blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

[Xen-devel] [xen-unstable-smoke test] 105788: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   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  62c7b99a10793738db1007f6750cf79057625f2c
baseline version:
 xen  28722e98f7ff1ef0da1bef885f98e232f89a8ca7

Last test of basis   105771  2017-02-13 15:01:46 Z0 days
Testing same since   105788  2017-02-14 11:01:40 Z0 days1 attempts


People who touched revisions under test:
  Kevin Tian 
  Sergey Dyasli 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=62c7b99a10793738db1007f6750cf79057625f2c
+ . ./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 
62c7b99a10793738db1007f6750cf79057625f2c
+ branch=xen-unstable-smoke
+ revision=62c7b99a10793738db1007f6750cf79057625f2c
+ . ./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
+ '[' x62c7b99a10793738db1007f6750cf79057625f2c = 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
++ : 

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

[Roger Pau Monné]

On Tue, Feb 14, 2017 at 12:31:00PM +, osstest service owner wrote:
> flight 105784 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105784/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
> REGR. vs. 105756

Seems like an issue with the debian mirror:

http://logs.test-lab.xenproject.org/osstest/logs/105784/test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm/elbling1---var-log-xen-osstest-serial-debianhvm.guest.osstest.log

>  build-amd64-xsm   5 xen-build  fail in 105777 REGR. vs. 
> 105756
>  build-armhf-libvirt  4 host-build-prep fail in 105777 REGR. vs. 
> 105756

And I cannot see those last two as failing in the html report...

Roger.

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

Re: [Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

[Jan Beulich]

>>> On 14.02.17 at 13:30,  wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -212,9 +212,6 @@ CFLAGS += -std=gnu99
>  
>  CFLAGS += -Wall -Wstrict-prototypes
>  
> -# Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
> -CFLAGS-$(clang) += -Wno-parentheses

Taking the comment being removed here together with 

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2011,7 +2011,7 @@ uint32_t guest_io_read(unsigned int port, unsigned int 
> bytes,
>  {
>  sub_data = pv_pit_handler(port, 0, 0);
>  }
> -else if ( (port == RTC_PORT(0)) )
> +else if ( port == RTC_PORT(0) )
>  {
>  sub_data = currd->arch.cmos_idx;
>  }
> @@ -2080,7 +2080,7 @@ void guest_io_write(unsigned int port, unsigned int 
> bytes, uint32_t data,
>  {
>  pv_pit_handler(port, (uint8_t)data, 1);
>  }
> -else if ( (port == RTC_PORT(0)) )
> +else if ( port == RTC_PORT(0) )
>  {
>  currd->arch.cmos_idx = data;
>  }

... the code adjustments all being to other than macros I wonder
whether in the version you use the issue is no longer being
reported in macro expansions, but older clang still chokes on such.
Or did you go check that we have no such uses left (which seems
unlikely to me)?

Jan


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

Re: [Xen-devel] [PATCH v4 4/4] build: enable no-parentheses in clang

[Andrew Cooper]

On 14/02/17 12:30, Roger Pau Monne wrote:
> And fix the following errors reported:
>
> traps.c:2014:25: error: equality comparison with extraneous parentheses
>   [-Werror,-Wparentheses-equality]
> else if ( (port == RTC_PORT(0)) )
>~^~
> traps.c:2014:25: note: remove extraneous parentheses around the comparison to 
> silence this warning
> else if ( (port == RTC_PORT(0)) )
>   ~ ^ ~
> traps.c:2014:25: note: use '=' to turn this equality comparison into an 
> assignment
> else if ( (port == RTC_PORT(0)) )
> ^~
> =
> traps.c:2083:25: error: equality comparison with extraneous parentheses
>   [-Werror,-Wparentheses-equality]
> else if ( (port == RTC_PORT(0)) )
>~^~
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v4 3/4] build: enable unused value checks for clang

[Jan Beulich]

>>> On 14.02.17 at 13:30,  wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -213,8 +213,7 @@ CFLAGS += -std=gnu99
>  CFLAGS += -Wall -Wstrict-prototypes
>  
>  # Clang complains about macros that expand to 'if ( ( foo == bar ) ) ...'
> -# and is a bit too fierce about unused return values
> -CFLAGS-$(clang) += -Wno-parentheses -Wno-unused-value
> +CFLAGS-$(clang) += -Wno-parentheses

Same question here - does removing the warning suppression work
with all clang versions, or just new enough ones?

Jan


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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

[Konrad Rzeszutek Wilk]

On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 10 February 2017 21:52
> > To: Paul Durrant ; xen-de...@lists.xenproject.org
> > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > 
> > Hey!
> > 
> > This patch lets me compile this emulator under Xen 4.7.
> > 
> > It probably can be done better (#ifdef magic?) but for right
> > now this gets me past the compile errors.
> > 
> > BTW, are there any other outstanding patches against this tree?
> > 
> 
> This is still my private project, although if it's generally useful then 
> maybe it can be adopted as part of the Xen project?

It is a nice project!

By 'adopted' you mean being built as part of xen.git (like minios.git?) - and
all of those requirements?

> 
> For the benefit of the list, there are two branches in 
> http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git
> 
> - The 'master' branch is a very basic standalone device emulator. It serves 
> as boilerplate for emulation of a single PCI device.
> 
> - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using 
> libVNCServer which can potentially be used with an HVM guest with PV network 
> and storage drivers, thus removing the need to use QEMU. demu is a small and 
> constrained piece of code and thus presents a much smaller attack surface. 
> The original intention was also to run it in a 'console service domain' to 
> further contain damage it was successfully attacked.
> 
> It's likely that I will patch the code further once my current work on 
> libxendevicemodel is done (following acceptance of my recent privcmd patches).


> 
>   Cheers,
> 
> Paul
> 
> > 
> >  demu.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > Konrad Rzeszutek Wilk (1):
> >   Make it compiler under Xen 4.7.
> 

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

[Xen-devel] [linux-linus test] 105786: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
105778
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail in 105778 
pass in 105786

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254

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

version targeted for testing:
 linux7089db84e356562f8ba737c29e472cc42d530dbc
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  586 days
Failing since 59348  2015-07-10 04:24:05 Z  585 days  273 attempts
Testing same since   105757  2017-02-13 03:57:45 Z1 days4 attempts


7580 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvops   

Re: [Xen-devel] [PATCH v7 01/24] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

[Konrad Rzeszutek Wilk]

On Mon, Feb 13, 2017 at 02:32:13PM +0800, Yi Sun wrote:
> This patch creates CAT and CDP feature document in doc/features/. It describes
> key points to implement L3 CAT/CDP and L2 CAT which is described in details in
> Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION 
> FEATURES".
> 
> Signed-off-by: Yi Sun 
> ---
> v7:
> - correct typo.
> - replace application/VM to domain.
> - amend description of `feat_mask` to make it clearer.
> - update revision.
> - other minor fixes.

You forgot to include in the 'Areas of improvement' the issues I described.


> ---
>  docs/features/intel_psr_cat_cdp.pandoc | 454 
> +
>  1 file changed, 454 insertions(+)
>  create mode 100644 docs/features/intel_psr_cat_cdp.pandoc
> 
> diff --git a/docs/features/intel_psr_cat_cdp.pandoc 
> b/docs/features/intel_psr_cat_cdp.pandoc
> new file mode 100644
> index 000..65736cc
> --- /dev/null
> +++ b/docs/features/intel_psr_cat_cdp.pandoc
> @@ -0,0 +1,454 @@
> +% Intel Cache Allocation Technology and Code and Data Prioritization Features
> +% Revision 1.0

?? 1.6 surely

.. snip..

> +# Areas for improvement
> +
> +N/A

Here.
> +
> +# Known issues
> +
> +N/A
> +
> +# References
> +
> +"INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION FEATURES" 
> [Intel® 64 and IA-32 Architectures Software Developer Manuals, 
> vol3](http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html)
> +
> +# History
> +
> +
> +Date   Revision Version  Notes
> +--   ---
> +2016-08-12 1.0  Xen 4.9  Design document written
> +2017-02-13 1.6  Xen 4.9  Design document written

It was not written at 1.6. It was changed. And you enumerate
what was changed.

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

Re: [Xen-devel] [PATCH 2/2] x86: package up context switch hook pointers

[Andrew Cooper]

On 14/02/17 10:29, Jan Beulich wrote:
> They're all solely dependent on guest type, so we don't need to repeat
> all the same four pointers in every vCPU control structure. Instead use
> static const structures, and store pointers to them in the domain
> control structure.
>
> Since touching it anyway, take the opportunity and move schedule_tail()
> into the only C file needing it.
>
> Signed-off-by: Jan Beulich 

+1.  This has been a niggle on my todo list for ages.

> @@ -2066,6 +2073,15 @@ static void __context_switch(void)
>  per_cpu(curr_vcpu, cpu) = n;
>  }
>  
> +/*
> + * Schedule tail *should* be a terminal function pointer, but leave a 
> bugframe
> + * around just incase it returns, to save going back into the context
> + * switching code and leaving a far more subtle crash to diagnose.
> + */
> +#define schedule_tail(vcpu) do {  \
> +(((vcpu)->domain->arch.ctxt_switch->tail)(vcpu)); \
> +BUG();\
> +} while (0)

schedule_tail() is used only twice.  I'd suggest dropping it entirely
and calling the ->tail() function pointer normally, rather than hiding
it this.

Upon reviewing, this patch, don't we also need a ->same() call in the
continue_same() path in the previous patch?

~Andrew

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

[Paul Durrant]

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 14 February 2017 15:16
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> 
> On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: 10 February 2017 21:52
> > > To: Paul Durrant ; xen-
> de...@lists.xenproject.org
> > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > >
> > > Hey!
> > >
> > > This patch lets me compile this emulator under Xen 4.7.
> > >
> > > It probably can be done better (#ifdef magic?) but for right
> > > now this gets me past the compile errors.
> > >
> > > BTW, are there any other outstanding patches against this tree?
> > >
> >
> > This is still my private project, although if it's generally useful then 
> > maybe it
> can be adopted as part of the Xen project?
> 
> It is a nice project!
> 

Glad you find it useful :-)

> By 'adopted' you mean being built as part of xen.git (like minios.git?) - and
> all of those requirements?
> 

Something like that, then it can be incorporated as an option into the xen 
build and we can make sure any dependency issues like this are caught in future.

I guess I'd probably make the 'console' branch master in a more official 
repo... I could even look at adding the necessary tooling into libxl to kick it 
off too :-)

  Paul

> >
> > For the benefit of the list, there are two branches in
> http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git
> >
> > - The 'master' branch is a very basic standalone device emulator. It serves
> as boilerplate for emulation of a single PCI device.
> >
> > - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using
> libVNCServer which can potentially be used with an HVM guest with PV
> network and storage drivers, thus removing the need to use QEMU. demu is
> a small and constrained piece of code and thus presents a much smaller
> attack surface. The original intention was also to run it in a 'console 
> service
> domain' to further contain damage it was successfully attacked.
> >
> > It's likely that I will patch the code further once my current work on
> libxendevicemodel is done (following acceptance of my recent privcmd
> patches).
> 
> 
> >
> >   Cheers,
> >
> > Paul
> >
> > >
> > >  demu.c | 7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > Konrad Rzeszutek Wilk (1):
> > >   Make it compiler under Xen 4.7.
> >

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

Re: [Xen-devel] [PATCH] x86/mm: Alter is_xen_fixed_mfn() to use mfn_t

[Julien Grall]

Hi Andrew,

On 02/07/2017 06:57 PM, Andrew Cooper wrote:

The predicate is common between x86 and ARM, and is unlikley to be different/


NIT: s/unlikley/unlikely/


on other architectures.  Drop the arch declarations and introduce a common
static inline in xen/mm.h instead.

Signed-off-by: Andrew Cooper 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt

[Julien Grall]

Hi,

Ping? As Ian mentioned earlier, without this series it is not possible 
to build Xen tools for ARM64 in osstest.


Cheers,

On 02/08/2017 07:50 PM, Julien Grall wrote:

Hi,

On 24/01/17 22:19, David Scott wrote:



On 24 Jan 2017, at 11:35, Ian Jackson  wrote:

Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no 
ocamlopt"):

Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
package lacks ocamlopt.

...

This does not actually fix the real problem.  I'm unsure how to fix it
properly, for the following reasons:


Can I have some input from ocaml folks ?

The first ARM64 boxes in the Xen Project test lab are in principle now
online, but this bug is stopping osstest actually getting as far as
trying to boot Xen.


ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
`ocamlc'.  However our ocaml Makefiles seem to explicitly call
$(OCAMLOPT) in some places and and $(OCAMLC) in others.


I’m terrible at reading m4 and am really bad with autoconf so I may have
got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`? Where

`ocamlc`: outputs bytecode, and is a bytecode executable itself
`ocamlc.opt`: outputs bytecode, and is a native code executable itself
`ocamlopt`: outputs native code, and is a bytecode executable itself
`ocamlopt.opt`: outputs native code, and is a native code executable itself

Both `ocamlc` and `ocamlc.opt` should be interchangeable: same command-line
arguments, exactly the same output. Same for `ocamlopt` and `ocamlopt.opt`.

I _think_ the m4 is looking for `ocamlc.opt` because it’s an optimised native
(therefore faster) version of `ocamlc`. It should be fine to set `OCAMLC`
to either.

The tools/ocaml/Makefile.rules does contain rules for both bytecode outputs
(e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe *.cmi
can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).

I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it refers
directly to *.cmxa files which are native-code only— I don’t see how that
could work for bytecode outputs.

Do you have a link to the build failure?


Here a link for the build failure:

http://logs.test-lab.xenproject.org/osstest/logs/105644/build-arm64/5.ts-xen-build.log

Cheers,



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 2/4] build/printf: fix incorrect format specifiers

[Wei Liu]

On Tue, Feb 14, 2017 at 12:30:55PM +, Roger Pau Monne wrote:
> The following incorrect format specifiers and incorrect number of parameters
> passed to printf like functions are reported by clang:
> 
> mce.c:601:18: error: data argument not used by format string 
> [-Werror,-Wformat-extra-args]
>  smp_processor_id());
>  ^
> 
> xenpm.c:102:23: error: data argument not used by format string 
> [-Werror,-Wformat-extra-args]
> what, argv[argc > 1]);
>   ^
> 
> libxl_internal.c:25:69: error: data argument not used by format string
>   [-Werror,-Wformat-extra-args]
> libxl__log(ctx, XTL_CRITICAL, ENOMEM, 0,0, func, INVALID_DOMID, L);
> ^
> libxl_internal.c:24:17: note: expanded from macro 'L'
>   func, (unsigned long)nmemb, (unsigned long)size
> ^
> libxl_internal.c:26:21: error: data argument not used by format string
>   [-Werror,-Wformat-extra-args]
> fprintf(stderr, L);
> ^
> libxl_internal.c:24:17: note: expanded from macro 'L'
>   func, (unsigned long)nmemb, (unsigned long)size
> ^
> 
> This patch contains the fixes for them and enables -Wformat for clang.
> 
> Signed-off-by: Roger Pau Monné 
> Acked-by: Andrew Cooper 
> ---
> NB: FWIW, there's a way to disable extra arguments checks
> (-Wno-format-extra-args), that would prevent us from having to apply some of
> the changes here. However, given that there are not that many occurrences, I
> would rather leave the full checks of Wformat enabled.
> 
> NB2: this has only been tested with a FreeBSD clang build (3.8.0), and only
> against the components that build on FreeBSD (ie: no qemu-trad, and certainly
> no blktap).
> ---

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Boris Ostrovsky]

On 02/13/2017 12:03 PM, Paul Durrant wrote:
> Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> for restricting device emulators (such as QEMU) to a limited set of
> hypervisor operations, and being able to audit those operations in the
> kernel of the domain in which they run.
>
> This patch adds IOCTL_PRIVCMD_DM_OP as gateway for __HYPERVISOR_dm_op.
>
> NOTE: There is no requirement for user-space code to bounce data through
>   locked memory buffers (as with IOCTL_PRIVCMD_HYPERCALL) since
>   privcmd has enough information to lock the original buffers
>   directly.
>
> [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=524a98c2
>
> Signed-off-by: Paul Durrant 


Stefano,

Are you OK with ARM changes?

-boris



> ---
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
>
> v3:
> - Add module parameters for max number of dm_op buffers and max buffer
>   size
> - Fix arm build
> - Fix commit comment to reflect re-worked patch
>
> v2:
> - Lock the user pages rather than bouncing through kernel memory
> ---
>  arch/arm/xen/enlighten.c |   1 +
>  arch/arm/xen/hypercall.S |   1 +
>  arch/arm64/xen/hypercall.S   |   1 +
>  arch/x86/include/asm/xen/hypercall.h |   7 ++
>  drivers/xen/privcmd.c| 139 
> +++
>  include/uapi/xen/privcmd.h   |  13 
>  include/xen/arm/hypercall.h  |   1 +
>  include/xen/interface/hvm/dm_op.h|  32 
>  include/xen/interface/xen.h  |   1 +
>  9 files changed, 196 insertions(+)
>  create mode 100644 include/xen/interface/hvm/dm_op.h
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 11d9f28..81e3217 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -457,4 +457,5 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
> +EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
>  EXPORT_SYMBOL_GPL(privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index a648dfc..b0b80c0 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -92,6 +92,7 @@ HYPERCALL1(tmem_op);
>  HYPERCALL1(platform_op_raw);
>  HYPERCALL2(multicall);
>  HYPERCALL2(vm_assist);
> +HYPERCALL3(dm_op);
>  
>  ENTRY(privcmd_call)
>   stmdb sp!, {r4}
> diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> index 947830a..401ceb7 100644
> --- a/arch/arm64/xen/hypercall.S
> +++ b/arch/arm64/xen/hypercall.S
> @@ -84,6 +84,7 @@ HYPERCALL1(tmem_op);
>  HYPERCALL1(platform_op_raw);
>  HYPERCALL2(multicall);
>  HYPERCALL2(vm_assist);
> +HYPERCALL3(dm_op);
>  
>  ENTRY(privcmd_call)
>   mov x16, x0
> diff --git a/arch/x86/include/asm/xen/hypercall.h 
> b/arch/x86/include/asm/xen/hypercall.h
> index a12a047..f6d20f6 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -472,6 +472,13 @@ HYPERVISOR_xenpmu_op(unsigned int op, void *arg)
>   return _hypercall2(int, xenpmu_op, op, arg);
>  }
>  
> +static inline int
> +HYPERVISOR_dm_op(
> + domid_t dom, unsigned int nr_bufs, void *bufs)
> +{
> + return _hypercall3(int, dm_op, dom, nr_bufs, bufs);
> +}
> +
>  static inline void
>  MULTI_fpu_taskswitch(struct multicall_entry *mcl, int set)
>  {
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 5e5c7ae..a33f17e 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -32,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -43,6 +45,17 @@ MODULE_LICENSE("GPL");
>  
>  #define PRIV_VMA_LOCKED ((void *)1)
>  
> +unsigned int privcmd_dm_op_max_num = 16;
> +module_param_named(dm_op_max_nr_bufs, privcmd_dm_op_max_num, uint, 0644);
> +MODULE_PARM_DESC(dm_op_max_nr_bufs,
> +  "Maximum number of buffers per dm_op hypercall");
> +
> +unsigned int privcmd_dm_op_buf_max_size = XEN_PAGE_SIZE;
> +module_param_named(dm_op_buf_max_size, privcmd_dm_op_buf_max_size, uint,
> +0644);
> +MODULE_PARM_DESC(dm_op_buf_max_size,
> +  "Maximum size of a dm_op hypercall buffer");
> +
>  static int privcmd_vma_range_is_mapped(
> struct vm_area_struct *vma,
> unsigned long addr,
> @@ -548,6 +561,128 @@ static long privcmd_ioctl_mmap_batch(void __user 
> *udata, int version)
>   goto out;
>  }
>  
> +static int lock_pages(
> + struct privcmd_dm_op_buf kbufs[], unsigned int num,
> + struct page *pages[], unsigned int nr_pages)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < num; i++) {
> + unsigned int requested;
> + int pinned;
> +
> + requested = 

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

[Julien Grall]

Hi Tamas,

On 13/02/17 16:20, Tamas K Lengyel wrote:

On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
 wrote:

Hello,

This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in platform_hvc). I want to discuss more broad topic there.

Obviously, there are growing number of SMC users and current state of
SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
secure way, Xilinx wants to forward some calls directly to Secure
Monitor, while allowing to handle other in userspace, etc.

My proposition is to gather all requirements to SMC (and HVC) handling
in one place (e.g. in this mail thread). After we' will have clear
picture of what we want, we will be able to develop some solution,
that will satisfy us all. At least, I hope so :)

Also I want to remind, that there are ARM document called "SMC Calling
Convention" [3]. According to it, any aarch64 hypervisor "must
implement the Standard Secure and Hypervisor Service calls". At this
moment XEN does not conform to this.

So, lets get started with the requirements:
0. There are no much difference between SMC and HVC handling (at least
according to SMCCC).
1. Hypervisor should at least provide own UUID and version while
called by SMC/HVC
2. Hypervisor should forward some calls from dom0 directly to Secure
Monitor (Xilinx use case)
3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
architecture service calls, etc.
4. Hypervisor should handle TEE calls in a secure way (e.g. no
untrusted handlers in Dom0 userspace).
5. Hypervisor should support multiple TEEs (at least at compilation time).
6. Hypervisor should do this as fast as possible (DRM playback use case).
7. All domains (including dom0) should be handled in the same way.
8. Not all domains will have right to issue certain SMCs.
9. Hypervisor will issue own SMCs in some cases.


10. Domains on which the monitor privileged call feature is enabled
(which is by default disabled for all domains) should not be able to
issue SMCs such that it reaches the firmware directly. Xen should not
bounce such calls to the firmware on behalf of the domain. Xen should
not alter the state of the domain automatically (ie. incrementing PC).
These calls should be exclusively transfered to the monitor subscriber
for further processing. HVC calls need not be included in the monitor
forwarding as long as the HVC call can be governed by XSM.


This should not be a strong requirement. Whilst in your use case you 
want to forward all the SMCs to the monitor app, there are use case 
where Xen would need to emulate SMCs on the behalf of the guest. For 
instance see PSCI (arch/arm/vpsci.c).


Another valid use case is Xen handling power management for device 
assigned to the guest and having the monitor app acting as a "Trusted App".


Regarding the HVC call governed by XSM. I think this is the wrong way to 
g. As it was mentioned a couple of time HVC is a valid conduit for 
Secure monitor call. You should not deny them on the basis that your 
monitor app is not able to handle it properly. A better way would be to 
have a list of Secure Monitor Call (HVC/SMC) that should be forwarded to 
the monitor app.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

[Peter Zijlstra]

On Tue, Feb 14, 2017 at 09:46:17AM -0500, Waiman Long wrote:
> On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
> > On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
> >> It is the address of _time that will exceed the 32-bit limit.
> > That seems extremely unlikely. That would mean we have more than 4G
> > worth of per-cpu variables declared in the kernel.
> 
> I have some doubt about if the compiler is able to properly use
> RIP-relative addressing for this.

Its not RIP relative, _time lives in the .data..percpu section and
is absolute in that.

> Anyway, it seems like constraints
> aren't allowed for asm() when not in the function context, at least for
> the the compiler that I am using (4.8.5). So it is a moot point.

Well kvm_steal_time is (host/guest) ABI anyway, so the offset is fixed
and hard-coding it isn't a problem.

$ readelf -s defconfig-build/vmlinux | grep steal_time
100843: 00017ac064 OBJECT  WEAK   DEFAULT   35 steal_time

$ objdump -dr defconfig-build/vmlinux | awk '/[<][^>]*[>]:/ { o=0 } 
/[<]__raw_callee_save___kvm_vcpu_is_preempted[>]:/ {o=1} { if (o) print $0 }'
810b4480 <__raw_callee_save___kvm_vcpu_is_preempted>:
810b4480:   55  push   %rbp
810b4481:   48 89 e5mov%rsp,%rbp
810b4484:   48 8b 04 fd 00 94 46mov-0x7db96c00(,%rdi,8),%rax
810b448b:   82 
810b4488: R_X86_64_32S  __per_cpu_offset
810b448c:   80 b8 d0 7a 01 00 00cmpb   $0x0,0x17ad0(%rax)
810b448e: R_X86_64_32S  steal_time+0x10
810b4493:   0f 95 c0setne  %al
810b4496:   5d  pop%rbp
810b4497:   c3  retq   


And as you'll note, the displacement is correct and 'small'.

The below relies on the 'extra' cast in PVOP_CALL_ARG1() to extend the
argument to 64bit on the call side of things.

---
 arch/x86/kernel/kvm.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 099fcba..2c854b8 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -589,6 +589,7 @@ static void kvm_wait(u8 *ptr, u8 val)
local_irq_restore(flags);
 }
 
+#ifdef CONFIG_X86_32
 __visible bool __kvm_vcpu_is_preempted(int cpu)
 {
struct kvm_steal_time *src = _cpu(steal_time, cpu);
@@ -597,6 +598,26 @@ __visible bool __kvm_vcpu_is_preempted(int cpu)
 }
 PV_CALLEE_SAVE_REGS_THUNK(__kvm_vcpu_is_preempted);
 
+#else
+
+extern bool __raw_callee_save___kvm_vcpu_is_preempted(int cpu);
+
+asm(
+".pushsection .text;"
+".global __raw_callee_save___kvm_vcpu_is_preempted;"
+".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
+"__raw_callee_save___kvm_vcpu_is_preempted:"
+FRAME_BEGIN
+"movq __per_cpu_offset(,%rdi,8), %rax;"
+"cmpb $0, 16+steal_time(%rax);"
+"setne %al;"
+FRAME_END
+"ret;"
+".popsection"
+);
+
+#endif
+
 /*
  * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
  */

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

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

[Tim Deegan]

Hi,

At 06:19 -0700 on 13 Feb (1486966797), Jan Beulich wrote:
> The present way of setting this up is flawed: Leaving the I/O bitmap
> pointer at zero means that the interrupt redirection bitmap lives
> outside (ahead of) the allocated space of the TSS. Similarly setting a
> TSS limit of 255 when only 128 bytes get allocated means that 128 extra
> bytes may be accessed by the CPU during I/O port access processing.
> 
> Introduce a new HVM param to set the allocated size of the TSS, and
> have the hypervisor actually take care of setting namely the I/O bitmap
> pointer. Both this and the segment limit now take the allocated size
> into account.
> 
> Signed-off-by: Jan Beulich 

This looks pretty good to me.  Once the question below is resolved,
Reviewed-by: Tim Deegan 

> ---
> TBD: Do we really want to re-init the TSS every time we are about to
>  use it?

No - I think we should init it when the guest writes the param(s) and
leave it at that.  Hvmloader marks it as reserved so the guest should
know better than to write to it, and we can't protect it against all
the possible ways the guest could break itself.

If you do want to re-init it more often, then I think it would still
be better to legacy guests' (lack of a) size limit once, when the guest
writes the base param.

Cheers,

Tim.

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

Re: [Xen-devel] [PATCH] Make it compiler under Xen 4.7.

[Konrad Rzeszutek Wilk]

On Mon, Feb 13, 2017 at 08:46:29AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 10 February 2017 21:52
> > To: Paul Durrant ; xen-de...@lists.xenproject.org
> > Cc: Konrad Rzeszutek Wilk 
> > Subject: [PATCH] Make it compiler under Xen 4.7.
> > 
> > With b7f76a699dcfadc0a52ab45b33cc72dbf3a69e7b
> > Author: Ian Campbell 
> > Date:   Mon Jun 1 16:20:09 2015 +0100
> > 
> > tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
> > 
> > commit 32486916793fd78a41fc25e53d2b53a5aa0b1bd5
> > Author: Ian Campbell 
> > Date:   Thu Jun 18 16:30:19 2015 +0100
> > 
> > tools: Refactor foreign memory mapping into libxenforeignmemory
> > 
> > We need to use the compat layer.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> 
> Thanks for taking the time to send this. I'll incorporate this a.s.a.p.

Thank you. Keep in mind that it will likely break against
older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h

[Oh wait, Xen 4.4 didn't have ioreq either, so perhaps Xen 4.5?]

But I wasn't sure how you wanted to deal with this being compiled
against say Xen 4.6?

Or maybe the README file should just say what version of Xen
is required? (I can send an patch for that too if you would like).

> 
> Acked-by: Paul Durrant 
> 
> > 
> > ---
> > CC: paul.durr...@citrix.com
> > 
> > v1: First version
> > ---
> >  demu.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/demu.c b/demu.c
> > index 2933efb..7d73a69 100644
> > --- a/demu.c
> > +++ b/demu.c
> > @@ -56,7 +56,12 @@
> > 
> >  #include 
> > 
> > +#define XC_WANT_COMPAT_MAP_FOREIGN_API 1
> > +#define XC_WANT_COMPAT_EVTCHN_API 1
> > +
> >  #include 
> > +#include 
> > +
> >  #include 
> > 
> >  #include "debug.h"
> > @@ -126,7 +131,7 @@ typedef enum {
> >  typedef struct demu_state {
> >  demu_seq_t  seq;
> >  xc_interface*xch;
> > -xc_interface*xceh;
> > +xc_evtchn  *xceh;
> >  domid_t domid;
> >  unsigned intvcpus;
> >  ioservid_t  ioservid;
> > --
> > 2.9.3
> 

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

[Paul Durrant]

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 14 February 2017 15:32
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> 
> On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: 14 February 2017 15:16
> > > To: Paul Durrant 
> > > Cc: xen-de...@lists.xenproject.org
> > > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and
> later)
> > >
> > > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > > > > -Original Message-
> > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > > > Sent: 10 February 2017 21:52
> > > > > To: Paul Durrant ; xen-
> > > de...@lists.xenproject.org
> > > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and
> later)
> > > > >
> > > > > Hey!
> > > > >
> > > > > This patch lets me compile this emulator under Xen 4.7.
> > > > >
> > > > > It probably can be done better (#ifdef magic?) but for right
> > > > > now this gets me past the compile errors.
> > > > >
> > > > > BTW, are there any other outstanding patches against this tree?
> > > > >
> > > >
> > > > This is still my private project, although if it's generally useful then
> maybe it
> > > can be adopted as part of the Xen project?
> > >
> > > It is a nice project!
> > >
> >
> > Glad you find it useful :-)
> >
> > > By 'adopted' you mean being built as part of xen.git (like minios.git?) -
> and
> > > all of those requirements?
> > >
> >
> > Something like that, then it can be incorporated as an option into the xen
> build and we can make sure any dependency issues like this are caught in
> future.
> >
> > I guess I'd probably make the 'console' branch master in a more official
> repo... I could even look at adding the necessary tooling into libxl to kick 
> it off
> too :-)
> 
> Oooh, and what kind of bribe^H^H^H^H incentive should I send your way?
> 

A time machine? :-)

  Paul

> >
> >   Paul
> >
> > > >
> > > > For the benefit of the list, there are two branches in
> > > http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git
> > > >
> > > > - The 'master' branch is a very basic standalone device emulator. It
> serves
> > > as boilerplate for emulation of a single PCI device.
> > > >
> > > > - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using
> > > libVNCServer which can potentially be used with an HVM guest with PV
> > > network and storage drivers, thus removing the need to use QEMU.
> demu is
> > > a small and constrained piece of code and thus presents a much smaller
> > > attack surface. The original intention was also to run it in a 'console
> service
> > > domain' to further contain damage it was successfully attacked.
> > > >
> > > > It's likely that I will patch the code further once my current work on
> > > libxendevicemodel is done (following acceptance of my recent privcmd
> > > patches).
> > >
> > > 
> > > >
> > > >   Cheers,
> > > >
> > > > Paul
> > > >
> > > > >
> > > > >  demu.c | 7 ++-
> > > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > > >
> > > > > Konrad Rzeszutek Wilk (1):
> > > > >   Make it compiler under Xen 4.7.
> > > >

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

Re: [Xen-devel] [PATCH v7 04/24] x86: refactor psr: implement CPU init and free flow.

[Konrad Rzeszutek Wilk]

On Mon, Feb 13, 2017 at 02:32:16PM +0800, Yi Sun wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
> 
> Signed-off-by: Yi Sun 
> ---
> v7:
> - initialize 'l3_cat'.
> - fix typo.
> - correct criteria to call 'free_feature' in cpu_fini_work. Only when
>   CPU_STARTING has been done and all CPUs are offline, 'free_feature'
>   can be called.
> - remove 'free_feature in 'psr_free' because 'psr_free' should only free
>   resources allocated in 'psr_cpu_prepare'. But resources allocated in
>   'psr_cpu_prepare' will not be freed to simplify things.
> ---
>  xen/arch/x86/cpuid.c|   6 --
>  xen/arch/x86/psr.c  | 170 
> +++-
>  xen/include/asm-x86/processor.h |   7 ++
>  3 files changed, 175 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
> index e0a387e..e3e92dd 100644
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -34,12 +34,6 @@ static void cpuid_leaf(uint32_t leaf, struct cpuid_leaf 
> *data)
>  cpuid(leaf, >a, >b, >c, >d);
>  }
>  
> -static void cpuid_count_leaf(uint32_t leaf, uint32_t subleaf,
> - struct cpuid_leaf *data)
> -{
> -cpuid_count(leaf, subleaf, >a, >b, >c, >d);
> -}
> -
>  static void sanitise_featureset(uint32_t *fs)
>  {
>  /* for_each_set_bit() uses unsigned longs.  Extend with zeroes. */
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index 5acd9ca..9a2b717 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Terminology:
> @@ -35,6 +36,9 @@
>  #define PSR_CAT(1<<1)
>  #define PSR_CDP(1<<2)
>  
> +#define CAT_CBM_LEN_MASK 0x1f
> +#define CAT_COS_MAX_MASK 0x
> +
>  /*
>   * Per SDM chapter 'Cache Allocation Technology: Cache Mask Configuration',
>   * the MSRs ranging from 0C90H through 0D0FH (inclusive), enables support for
> @@ -136,11 +140,84 @@ struct psr_assoc {
>  
>  struct psr_cmt *__read_mostly psr_cmt;
>  
> +static struct psr_socket_info *__read_mostly socket_info;
> +
>  static unsigned int opt_psr;
>  static unsigned int __initdata opt_rmid_max = 255;
> +static unsigned int __read_mostly opt_cos_max = MAX_COS_REG_CNT;
>  static uint64_t rmid_mask;
>  static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
>  
> +/*
> + * Declare global feature list entry for every feature to facilitate the
> + * feature list creation. It will be allocated in psr_cpu_prepare() and
> + * inserted into feature list in cpu_init_work(). It is protected by
> + * cpu_add_remove_lock spinlock.
> + */
> +static struct feat_node *feat_l3_cat;
> +
> +/* Common functions. */
> +static void free_feature(struct psr_socket_info *info)
> +{
> +struct feat_node *feat, *next;
> +
> +if ( !info )
> +return;
> +
> +/*
> + * Free resources of features. But we do not free global feature list
> + * entry, like feat_l3_cat. Although it may cause a few memory leak,
> + * it is OK simplify things.
> + */
> +list_for_each_entry_safe(feat, next, >feat_list, list)
> +{
> +__clear_bit(feat->feature, >feat_mask);
> +list_del(>list);
> +xfree(feat);
> +}
> +}
> +
> +/* L3 CAT functions implementation. */
> +static void l3_cat_init_feature(struct cpuid_leaf regs,
> +struct feat_node *feat,
> +struct psr_socket_info *info)
> +{
> +struct psr_cat_hw_info l3_cat = { };
> +unsigned int socket;
> +
> +/* No valid value so do not enable feature. */
> +if ( !regs.a || !regs.d )
> +return;
> +
> +l3_cat.cbm_len = (regs.a & CAT_CBM_LEN_MASK) + 1;
> +l3_cat.cos_max = min(opt_cos_max, regs.d & CAT_COS_MAX_MASK);
> +
> +/* cos=0 is reserved as default cbm(all bits within cbm_len are 1). */
> +feat->cos_reg_val[0] = (1ull << l3_cat.cbm_len) - 1;
> +
> +feat->feature = PSR_SOCKET_L3_CAT;
> +ASSERT(!test_bit(PSR_SOCKET_L3_CAT, >feat_mask));
> +__set_bit(PSR_SOCKET_L3_CAT, >feat_mask);
> +
> +feat->info.l3_cat_info = l3_cat;
> +
> +info->nr_feat++;
> +
> +/* Add this feature into list. */
> +list_add_tail(>list, >feat_list);
> +
> +socket = cpu_to_socket(smp_processor_id());
> +if ( !opt_cpu_info )
> +return;
> +
> +printk(XENLOG_INFO "L3 CAT: enabled on socket %u, cos_max:%u, 
> cbm_len:%u\n",
> +   socket, feat->info.l3_cat_info.cos_max,
> +   feat->info.l3_cat_info.cbm_len);
> +}
> +
> +static const struct feat_ops l3_cat_ops = {
> +};
> +
>  static void __init parse_psr_bool(char *s, char *value, char *feature,
>unsigned int mask)
>  {
> @@ -180,6 +257,9 @@ static void __init parse_psr_param(char *s)
>  if ( val_str && !strcmp(s, "rmid_max") )
>  

Re: [Xen-devel] [PATCH] Make it compiler under Xen 4.7.

[Paul Durrant]

> -Original Message-
[snip]
> > Thank you. Keep in mind that it will likely break against
> > older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h
> 
> I'm not sure you actually need to include that directly. I was going to try 
> just
> adding the 'want compat' defines and seeing if I could make it work. I think 
> it
> *should* work since all we do for upstream QEMU is add those defines into
> the configure cmd line IIRC.

I pushed modified patches into the master and console branches. Hopefully it 
should now build ok for you.

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

[Xen-devel] [PATCH 2/4] docs: convert XENV from odt to fodt

[Olaf Hering]

Fixes c33b5f013d ("Add XENV to docs/misc")

Signed-off-by: Olaf Hering 
---
 docs/misc/xen-env-table-spec.fodt | 852 ++
 1 file changed, 852 insertions(+)

diff --git a/docs/misc/xen-env-table-spec.fodt 
b/docs/misc/xen-env-table-spec.fodt
new file mode 100644
index 00..ccde7a6981
--- /dev/null
+++ b/docs/misc/xen-env-table-spec.fodt
@@ -0,0 +1,852 @@
+
+
+http://www.w3.org/1999/xlink; 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:config="urn:oas
 is:names:tc:opendocument:xmlns:config:1.0" 
xmlns:ooo="http://openoffice.org/2004/office; 
xmlns:ooow="http://openoffice.org/2004/writer; 
xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; 
xmlns:officeooo="http://openoffice.org/2009/office; 
xmlns:tableooo="http://openoffice.org/2009/table; 
xmlns:drawooo="http://openoffice.org/2010/draw; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:formx="urn:openoffice:names:
 experimental:ooxml-odf-interop:xmlns:form:1.0" 
xmlns:css3t="http://www.w3.org/TR/css3-text/; office:version="1.2" 
office:mimetype="application/vnd.oasis.opendocument.text">
+ LibreOffice/5.2.3.3$Linux_X86_64 
LibreOffice_project/20m0$Build-3
+ 
+  
+   0
+   2342
+   17861
+   7788
+   true
+   false
+   
+
+ view2
+ 3041
+ 3464
+ 2342
+ 0
+ 20202
+ 7786
+ 1
+ 1
+ false
+ 228
+ false
+
+   
+  
+  
+   false
+   true
+   true
+   true
+   0
+   true
+   true
+   
+   false
+   false
+   true
+   false
+   true
+   false
+   true
+   true
+   true
+   true
+   true
+   false
+   true
+   true
+   false
+   false
+   true
+   false
+   true
+   true
+   false
+   
+   false
+   false
+   true
+   false
+   true
+   
+   true
+   false
+   true
+   false
+   false
+   1430233
+   false
+   false
+   true
+   false
+   true
+   true
+   false
+   false
+   0
+   false
+   true
+   high-resolution
+   false
+   false
+   false
+   false
+   true
+   true
+   
+   true
+   false
+   false
+   false
+   true
+   false
+   false
+   false
+   
+   true
+   true
+   1362860
+   true
+   1
+   true
+   false
+   false
+   0
+   false
+   false
+   
+   
+   false
+  
+ 
+ 
+  
+   http://openoffice.org/2004/office; 
xmlns:xlink="http://www.w3.org/1999/xlink"/>
+  
+ 
+ 
+  
+  
+  
+  
+  
+  
+  
+  
+ 
+ 
+  
+   
+   
+
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+  
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+  
+  
+  
+  
+  
+   
+  
+ 
+ 
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+   
+
+   
+   
+
+   
+  
+ 
+ 
+  
+   
+   

[Xen-devel] [PATCH 1/4] docs: convert STAO from odt to fodt

[Olaf Hering]

Fixes 140b31a8de ("Add STAO spec to docs/misc")

Signed-off-by: Olaf Hering 
---
 docs/misc/status-override-table-spec.fodt | 707 ++
 1 file changed, 707 insertions(+)

diff --git a/docs/misc/status-override-table-spec.fodt 
b/docs/misc/status-override-table-spec.fodt
new file mode 100644
index 00..a831b7323b
--- /dev/null
+++ b/docs/misc/status-override-table-spec.fodt
@@ -0,0 +1,707 @@
+
+
+http://www.w3.org/1999/xlink; 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:config="urn:oas
 is:names:tc:opendocument:xmlns:config:1.0" 
xmlns:ooo="http://openoffice.org/2004/office; 
xmlns:ooow="http://openoffice.org/2004/writer; 
xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; 
xmlns:officeooo="http://openoffice.org/2009/office; 
xmlns:tableooo="http://openoffice.org/2009/table; 
xmlns:drawooo="http://openoffice.org/2010/draw; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:formx="urn:openoffice:names:
 experimental:ooxml-odf-interop:xmlns:form:1.0" 
xmlns:css3t="http://www.w3.org/TR/css3-text/; office:version="1.2" 
office:mimetype="application/vnd.oasis.opendocument.text">
+ LibreOffice/5.2.3.3$Linux_X86_64 
LibreOffice_project/20m0$Build-3
+ 
+  
+   0
+   2342
+   17861
+   7788
+   true
+   false
+   
+
+ view2
+ 3041
+ 3464
+ 2342
+ 0
+ 20202
+ 7786
+ 1
+ 1
+ false
+ 228
+ false
+
+   
+  
+  
+   false
+   true
+   true
+   true
+   0
+   true
+   true
+   
+   false
+   false
+   true
+   false
+   true
+   false
+   true
+   true
+   true
+   true
+   true
+   false
+   true
+   true
+   false
+   false
+   true
+   false
+   true
+   true
+   false
+   
+   false
+   false
+   true
+   false
+   true
+   
+   true
+   false
+   true
+   false
+   false
+   803236
+   false
+   false
+   true
+   false
+   true
+   true
+   false
+   false
+   0
+   false
+   true
+   high-resolution
+   false
+   false
+   false
+   false
+   true
+   true
+   
+   true
+   false
+   false
+   false
+   true
+   false
+   false
+   false
+   
+   true
+   true
+   720138
+   true
+   1
+   true
+   false
+   false
+   0
+   false
+   false
+   
+   
+   false
+  
+ 
+ 
+  
+   http://openoffice.org/2004/office; 
xmlns:xlink="http://www.w3.org/1999/xlink"/>
+  
+ 
+ 
+  
+  
+  
+  
+  
+  
+  
+  
+ 
+ 
+  
+   
+   
+
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+  
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+   
+
+ 
+
+   
+  
+  
+  
+  
+  
+   
+  
+ 
+ 
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+  
+  
+   
+  
+  
+   
+
+ 
+
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+  
+  
+   
+
+   
+   
+
+   
+   
+
+   
+  
+ 
+ 
+  
+   
+
+   
+   
+
+   
+  
+ 
+ 
+  
+   
+
+
+
+
+   
+   ACPI Specification for Status Override 
Table
+   
+   Specification: LINARO-0002
+   Authors: Al 
Stone mailto:al.st...@linaro.org; 

[Xen-devel] [PATCH 4/4] docs: remove odt variant of XENV

[Olaf Hering]

Signed-off-by: Olaf Hering 
---
 docs/misc/xen-env-table-spec.odt | Bin 19204 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/docs/misc/xen-env-table-spec.odt b/docs/misc/xen-env-table-spec.odt
deleted file mode 100644
index 
c8de7ca7d8e7d00dabe9d7bebef1e8117e47f95e..
GIT binary patch
literal 0
HcmV?d1

literal 19204
zcmeFZbBu36(=Ix;ZQHhI_Sm*QTZ)u>b_
z-C5POo~L>#%7B8Q0Rce)0bys-OY4uaz)=DL0sTk*bphE~*_pX|I+__dI@(&97`a+G
z*fajNH)U`za+&8Ox*pir~Np0{V|&{WGR&>1Jna
zZ)9cb!sz6fPjIZK>yYDg5RBifIxv1WmSJs
zP*8Aka`N)>ii(QL%F3#$s_N+In3$N@*x0zZxOjVegO~vzECDdq0AxD=x+4JB6+q+;
zAol{$_yQOL04zZO?l1s5|SMpYdLHvuAA0Wlqbgu0W&`jfP#v#i$h+>Z0)9za3|38e_1_r

Re: [Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY

[Wei Liu]

These two patches don't apply anymore. Please rebase.

Wei.

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

[Konrad Rzeszutek Wilk]

On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 14 February 2017 15:16
> > To: Paul Durrant 
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > 
> > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > > Sent: 10 February 2017 21:52
> > > > To: Paul Durrant ; xen-
> > de...@lists.xenproject.org
> > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > > >
> > > > Hey!
> > > >
> > > > This patch lets me compile this emulator under Xen 4.7.
> > > >
> > > > It probably can be done better (#ifdef magic?) but for right
> > > > now this gets me past the compile errors.
> > > >
> > > > BTW, are there any other outstanding patches against this tree?
> > > >
> > >
> > > This is still my private project, although if it's generally useful then 
> > > maybe it
> > can be adopted as part of the Xen project?
> > 
> > It is a nice project!
> > 
> 
> Glad you find it useful :-)
> 
> > By 'adopted' you mean being built as part of xen.git (like minios.git?) - 
> > and
> > all of those requirements?
> > 
> 
> Something like that, then it can be incorporated as an option into the xen 
> build and we can make sure any dependency issues like this are caught in 
> future.
> 
> I guess I'd probably make the 'console' branch master in a more official 
> repo... I could even look at adding the necessary tooling into libxl to kick 
> it off too :-)

Oooh, and what kind of bribe^H^H^H^H incentive should I send your way?

> 
>   Paul
> 
> > >
> > > For the benefit of the list, there are two branches in
> > http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git
> > >
> > > - The 'master' branch is a very basic standalone device emulator. It 
> > > serves
> > as boilerplate for emulation of a single PCI device.
> > >
> > > - The 'console' branch is a (PS/2) Keyboard-VGA-Mouse emulator using
> > libVNCServer which can potentially be used with an HVM guest with PV
> > network and storage drivers, thus removing the need to use QEMU. demu is
> > a small and constrained piece of code and thus presents a much smaller
> > attack surface. The original intention was also to run it in a 'console 
> > service
> > domain' to further contain damage it was successfully attacked.
> > >
> > > It's likely that I will patch the code further once my current work on
> > libxendevicemodel is done (following acceptance of my recent privcmd
> > patches).
> > 
> > 
> > >
> > >   Cheers,
> > >
> > > Paul
> > >
> > > >
> > > >  demu.c | 7 ++-
> > > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > Konrad Rzeszutek Wilk (1):
> > > >   Make it compiler under Xen 4.7.
> > >

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

Re: [Xen-devel] [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)

[Konrad Rzeszutek Wilk]

On Tue, Feb 14, 2017 at 03:39:00PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 14 February 2017 15:32
> > To: Paul Durrant 
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
> > 
> > On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > > Sent: 14 February 2017 15:16
> > > > To: Paul Durrant 
> > > > Cc: xen-de...@lists.xenproject.org
> > > > Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and
> > later)
> > > >
> > > > On Mon, Feb 13, 2017 at 08:58:42AM +, Paul Durrant wrote:
> > > > > > -Original Message-
> > > > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > > > > Sent: 10 February 2017 21:52
> > > > > > To: Paul Durrant ; xen-
> > > > de...@lists.xenproject.org
> > > > > > Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and
> > later)
> > > > > >
> > > > > > Hey!
> > > > > >
> > > > > > This patch lets me compile this emulator under Xen 4.7.
> > > > > >
> > > > > > It probably can be done better (#ifdef magic?) but for right
> > > > > > now this gets me past the compile errors.
> > > > > >
> > > > > > BTW, are there any other outstanding patches against this tree?
> > > > > >
> > > > >
> > > > > This is still my private project, although if it's generally useful 
> > > > > then
> > maybe it
> > > > can be adopted as part of the Xen project?
> > > >
> > > > It is a nice project!
> > > >
> > >
> > > Glad you find it useful :-)
> > >
> > > > By 'adopted' you mean being built as part of xen.git (like minios.git?) 
> > > > -
> > and
> > > > all of those requirements?
> > > >
> > >
> > > Something like that, then it can be incorporated as an option into the xen
> > build and we can make sure any dependency issues like this are caught in
> > future.
> > >
> > > I guess I'd probably make the 'console' branch master in a more official
> > repo... I could even look at adding the necessary tooling into libxl to 
> > kick it off
> > too :-)
> > 
> > Oooh, and what kind of bribe^H^H^H^H incentive should I send your way?
> > 
> 
> A time machine? :-)

Analog or digital? Amazon.co.uk does have a nice list of 'Timex' ones :-)

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

[Xen-devel] [PATCH 3/4] docs: remove odt variant of STAO

[Olaf Hering]

Signed-off-by: Olaf Hering 
---
 docs/misc/status-override-table-spec.odt | Bin 20206 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/docs/misc/status-override-table-spec.odt 
b/docs/misc/status-override-table-spec.odt
deleted file mode 100644
index 
4ea576b2c248a70445a6a5be751055bc03205092..
GIT binary patch
literal 0
HcmV?d1

literal 20206
zcmeFYQ;;uA3@|t+eXm4+AVQlDZVQ0(e
zYHPw^XXs?%#9(J{YHMO=>|$eT>&)P6>h7%Ye=>#;MD6%a1O)USWBoIxV(wyNWNT<)
z?ZoK(zeEOmTeAoSIdOOx9GHJ9@RAZDO8@3jARu5MDA0e>UeLQE5D+Mkf{cnNGcz*}
z508k5h_tk{ii(Q1wzjdcv6YpTlarH|mlv=J0MZ-)V*x<11)$plaGe2U9sn92fRyh#
zgFk>Z5Wp1*;EMpLhHPp@YzapLB;o)vi2$WkfLc00CktR0yKS1VW0kUNm%eA8v1gbI
zaLU?u|L09cm*dH$=@j5c*o_4V}^c3-CT12P8y
zeS>4A{Z~~(e+xzdCF6jqDM0<`b@Rkc$MkLe9H4XNu6Y5_JAc=?4Cq@23=Iv9P0UP9
zO)V`gZEbB0F5M4p0;V<|Cw2kzJ5MwFfR%@yq%dVE6oW`vP!ubaZ`veQ^GK
z`1kw#=Kb^zaP{!>`1ttn^7Hcc{qytl&(DDWfBb*m1L!5r^FToO&5|O5D(;)tKJQ*=
z9IH3}Rn44W>LG!uE1td%KSKGpBivpWsZ%@48~BPp(E^((NS{f&0@Ab2Ke)Thfi6e_Kl??R0VE
zeDd)*ALtC${$%9q?#S#w?`;
z4dB(eg5Bw4!7UBKzUcRRc@hQ12WIDW#IE>`JO(C@_R)8Syz-}1XEX2GyR+GcrKN0f
z3v5ut#lXn(N*rRHT*)%7-`#hJ?^)B61LfY=a~z`!BBQfc+Gn2p>sZ@jjr`Kd?C?rW
z8}N}@6?^YmFXuSZpM4Aj!>13{BQMk%XG5FArjZeGOf}_A?7?;y(>vtxMMtkgDNCP>
zRYo}e9LcmZHAVy?*U$!Ui+XozpRb+zRs64$!y?!nHrB@r6+dsvf$xvv$NkHZ=cX{`
zbcu_l3;g!=*A6AYk#VNp?JHd%tk0v*oH@wPize4gL5uB4rp2A;;s@b3T*Xc1sRM~mS1+t+Bmi+zVz$x`S1kG03w>PSyqsu$)O@My|O9|Ai@
z`t`_^HsQ5hOr5XqmA&`XUD9*awHxHh8UkYfC4O;SS{ftp
z>pEfHkE0RP(W7(pZag?

[Xen-devel] [PATCH 0/4] docs: convert from binary to ASCII

[Olaf Hering]

The odt files should have been saved as Flat XML via 'Save as ...'.

git send-email warns about lines longer than 998 chars. Hopefully all
involved mail services have no silly limits.

Olaf

Olaf Hering (4):
  docs: convert STAO from odt to fodt
  docs: convert XENV from odt to fodt
  docs: remove odt variant of STAO
  docs: remove odt variant of XENV

 docs/misc/status-override-table-spec.fodt | 707 +
 docs/misc/status-override-table-spec.odt  | Bin 20206 -> 0 bytes
 docs/misc/xen-env-table-spec.fodt | 852 ++
 docs/misc/xen-env-table-spec.odt  | Bin 19204 -> 0 bytes
 4 files changed, 1559 insertions(+)
 create mode 100644 docs/misc/status-override-table-spec.fodt
 delete mode 100644 docs/misc/status-override-table-spec.odt
 create mode 100644 docs/misc/xen-env-table-spec.fodt
 delete mode 100644 docs/misc/xen-env-table-spec.odt


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

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

[Julien Grall]

On 13/02/17 16:59, Tamas K Lengyel wrote:

On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall  wrote:

Hi Tamas,


On 13/02/17 16:20, Tamas K Lengyel wrote:


On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
 wrote:


Hello,

This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in platform_hvc). I want to discuss more broad topic there.

Obviously, there are growing number of SMC users and current state of
SMC handling in Xen satisfies nobody. My team wants to handle SMCs in
secure way, Xilinx wants to forward some calls directly to Secure
Monitor, while allowing to handle other in userspace, etc.

My proposition is to gather all requirements to SMC (and HVC) handling
in one place (e.g. in this mail thread). After we' will have clear
picture of what we want, we will be able to develop some solution,
that will satisfy us all. At least, I hope so :)

Also I want to remind, that there are ARM document called "SMC Calling
Convention" [3]. According to it, any aarch64 hypervisor "must
implement the Standard Secure and Hypervisor Service calls". At this
moment XEN does not conform to this.

So, lets get started with the requirements:
0. There are no much difference between SMC and HVC handling (at least
according to SMCCC).
1. Hypervisor should at least provide own UUID and version while
called by SMC/HVC
2. Hypervisor should forward some calls from dom0 directly to Secure
Monitor (Xilinx use case)
3. Hypervisor should virtualize PSCI calls, CPU service calls, ARM
architecture service calls, etc.
4. Hypervisor should handle TEE calls in a secure way (e.g. no
untrusted handlers in Dom0 userspace).
5. Hypervisor should support multiple TEEs (at least at compilation
time).
6. Hypervisor should do this as fast as possible (DRM playback use case).
7. All domains (including dom0) should be handled in the same way.
8. Not all domains will have right to issue certain SMCs.
9. Hypervisor will issue own SMCs in some cases.



10. Domains on which the monitor privileged call feature is enabled
(which is by default disabled for all domains) should not be able to
issue SMCs such that it reaches the firmware directly. Xen should not
bounce such calls to the firmware on behalf of the domain. Xen should
not alter the state of the domain automatically (ie. incrementing PC).
These calls should be exclusively transfered to the monitor subscriber
for further processing. HVC calls need not be included in the monitor
forwarding as long as the HVC call can be governed by XSM.



This should not be a strong requirement. Whilst in your use case you want to
forward all the SMCs to the monitor app, there are use case where Xen would
need to emulate SMCs on the behalf of the guest. For instance see PSCI
(arch/arm/vpsci.c).


In my usecases it is a strong requirement. What happens when the
monitor system is disabled is beyond my concerns - Xen can emulate or
forward the call as it wishes. But when the monitor application is in
use - in my usecase - it needs to be in exclusive control. If that
breaks an in-guest application, that is acceptable in my usecase. As
soon as there is another usecase that would need to support such an
application while the monitor system is enabled, the monitor system
can be fine-tuned for those needs to allow Xen to emulate. I've said
it many times, I have nothing against doing that, but as I don't need
it I won't be able to spend time implementing it.


Let me remind you that this discussion is not about what you implemented 
but what is a sensible design to fit everyone. I also never ask you to 
implement anything.






Another valid use case is Xen handling power management for device assigned
to the guest and having the monitor app acting as a "Trusted App".

Regarding the HVC call governed by XSM. I think this is the wrong way to g.
As it was mentioned a couple of time HVC is a valid conduit for Secure
monitor call. You should not deny them on the basis that your monitor app is
not able to handle it properly. A better way would be to have a list of
Secure Monitor Call (HVC/SMC) that should be forwarded to the monitor app.


I disagree. XSM needs to be in complete control of all hypercalls.
Whether denying some of them will break an application or not is not
Xen's concern. That is up to me as a user of Xen and XSM. If Xen
overrides a XSM policy because we hard-coded HVCs that pass-through,
that is a huge security policy violation. So even if we make a list of
HVCs that should also fall under the monitor privileged call umbrella,
it should still not override XSM. So since I would not be looking to
emulate anything that gets forwarded as a result of an HVC call, XSM
works for me just fine as the only thing I would do anyway is deny
them. So why would that list help when I might as well just make my
list more efficiently using XSM?


Again, why do you want to handle SMC and 

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Julien Grall]

Hi Stefano,

On 02/13/2017 07:59 PM, Stefano Stabellini wrote:
> On Mon, 13 Feb 2017, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 10/02/17 01:01, Stefano Stabellini wrote:
>>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
 A possible hack could be to allocate a chunk of DDR dedicated for PCI DMA.
 PCI DMA devs could be locked in to only be able to access this mem + MSI
 doorbell.
 Guests can still screw each other up but at least it becomes harder to
 read/write directly from each others OS memory.
 It may not be worth the effort though
>>>
>>> Actually, we do have the swiotlb in Dom0, which can be used to bounce
>>> DMA requests over a buffer that has been previously setup to be DMA safe
>>> using an hypercall. That is how the swiotlb is used on x86. On ARM it is
>>> used to issue cache flushes via hypercall, but it could be adapted to do
>>> both. It would degrade performance, due to the additional memcpy, but it
>>> would work, I believe.
>>
>> A while ago, Globallogic suggested to use direct memory mapping for the guest
>> to allow guest using DMA on platform not supporting SMMU.
>>
>> I believe we can use the same trick on platform where SMMUs can not
>> distinguish PCI devices.
>
> Yes, that would work, but only on platforms with a very limited number
> of guests. However, it might still be a very common use-case on a
> platform such as the Zynq MPSoC.

Can you explain why you think this could only work with limited number
of guests?

Cheers,

-- 
Julien Grall

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