Re: [Xen-devel] [PATCH RFC v1 57/74] x86/pv-shim: shadow PV console's page for L2 DomU

[Sarah Newman]

On 01/10/2018 08:56 AM, Sergey Dyasli wrote:
> On Tue, 2018-01-09 at 09:28 -0700, Jan Beulich wrote:
> On 09.01.18 at 16:43,  wrote:
>>>
>>> On Tue, 2018-01-09 at 02:13 -0700, Jan Beulich wrote:
>>> On 04.01.18 at 14:06,  wrote:
>
> +size_t consoled_guest_rx(void)
> +{
> +size_t recv = 0, idx = 0;
> +XENCONS_RING_IDX cons, prod;
> +
> +if ( !cons_ring )
> +return 0;
> +
> +spin_lock(_lock);
> +
> +cons = cons_ring->out_cons;
> +prod = ACCESS_ONCE(cons_ring->out_prod);
> +ASSERT((prod - cons) <= sizeof(cons_ring->out));
> +
> +/* Is the ring empty? */
> +if ( cons == prod )
> +goto out;
> +
> +/* Update pointers before accessing the ring */
> +smp_rmb();

 I think this need to move up ahead of the if(). In the comment
 perhaps s/Update/Latch/?
>>>
>>> The read/write memory barriers here are between read/write accesses to
>>> ring->out_prod and ring->out array. So there is no need to move them.
>>> (the same goes for the input ring)
>>
>> And there is no multiple-read issue here?
> 
> As Andrew has kindly explained to me, there is an issue indeed.
> So I moved smp_rmb() to be right after cons and prod read, and updated
> the comment to say:
> 
> "Latch pointers before accessing the ring. Included compiler barrier also
> ensures that pointers are really read only once into local variables."
> 

There is an incompatibility in this (also vixen's) serial output. The NetBSD 
installer includes NUL characters in its output and does not display
properly due to the call to puts. putc demonstrably works, though it would be 
better to add a length oriented function to serial.c.

--Sarah

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

Re: [Xen-devel] [PATCH] xen/sched_rt: Move repl_timer into struct rt_private

[Meng Xu]

On Thu, Jan 11, 2018 at 12:00 PM, Andrew Cooper
 wrote:
>
> struct timer is only 48 bytes and repl_timer has a 1-to-1 correspondance with
> struct rt_private, so having it referenced by pointer is wasteful.
>
> This avoids one memory allocation in rt_init(), and the resulting diffstat is:
>
>   add/remove: 0/0 grow/shrink: 0/7 up/down: 0/-156 (-156)
>   function old new   delta
>   rt_switch_sched  134 133  -1
>   rt_context_saved 278 271  -7
>   rt_vcpu_remove   253 245  -8
>   rt_vcpu_sleep234 218 -16
>   repl_timer_handler   761 744 -17
>   rt_deinit 44  20 -24
>   rt_init  219 136 -83
>
> As an extra bit of cleanup noticed while making this change, there is no need
> to call cpumask_clear() on an zeroed memory allocation.
>
> Signed-off-by: Andrew Cooper 
> ---


Reviewed-by: Meng Xu 

Thanks,

Meng

---
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

[Xen-devel] [linux-next test] 117767: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 117721
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 117721
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 117721
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
117721
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 117721
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 117721
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
117721
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 117721
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 117721
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 117721
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 117721
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 117721
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 117721
 test-amd64-amd64-qemuu-nested-amd  7 xen-bootfail REGR. vs. 117721
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 117721
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 117721
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 117721
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 117721
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 117721
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 117721
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 117721
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 117721
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 117721
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 117721
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 117721
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 117721
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 117721
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 117721
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 117721
 test-armhf-armhf-xl-arndale   7 xen-boot fail REGR. vs. 117721
 test-armhf-armhf-libvirt-xsm 19 leak-check/check fail REGR. vs. 117721
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 117721
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 117721
 test-armhf-armhf-libvirt 10 debian-install   fail REGR. vs. 117721
 test-armhf-armhf-xl-xsm  10 debian-install   

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

[Doug Goldstein]

On 1/11/18 3:16 AM, Lars Kurth wrote:
> And this time with attachment
> 
> 
> 
>> On 11 Jan 2018, at 09:15, Lars Kurth > > wrote:
>>
>> I am wondering whether something like the attached table would make
>> understanding the FAQ easier. Page 1 is clearly what is Xen specific
>> and we definitely should cover.
>> Page 2 in general covers Linux and guests. The first block is
>> relatively straightforward.
>>
>> The 2nd and 3rd block is based on information from Doug: as there are
>> many gaps, I would be uneasy about publishing these somewhere prominent. 
>>
>> Also
>>> As this is really guest specific this information can't be provided by
>>> Xen.
>> which carries a risk that any analysis made by anyone might only apply
>> to the context in which the analysis was done.
>>
>> But the question keeps coming up, so making this clearer is maybe
>> sensible.
>>
>> Best Regards
>> Lars

Thanks for the improvements Lars.

-- 
Doug Goldstein



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

Re: [Xen-devel] Trying out vixen: qemu processes left behind

[Andy Smith]

Hi Anthony,

On Thu, Jan 11, 2018 at 03:47:25PM -0800, Anthony Liguori wrote:
> On Thu, Jan 11, 2018 at 3:00 PM, Andy Smith  wrote:
> > $ sudo xl list
> > NameID   Mem VCPUs  State   
> > Time(s)
> > Domain-0 0  2048 2 r-  
> > 104114.0
> > (null)  17 1 2 --ps-d  
> > 14.2
> > $ ps awux | grep qemu
> > root  3310  1.2  1.2 430648 24676 ?SLl  22:48   0:06 
> > /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 17 -chardev 
> > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-17,server,nowait 
> > -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev 
> > socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-17,server,nowait 
> > -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name 
> > debtest1 -display none -serial pty -boot order=c -smp 2,maxcpus=2 -netdev 
> > type=tap,id=net0,ifname=vif17.0-emu,script=no,downscript=no -machine xenfv 
> > -cdrom /var/lib/xen/pvshim-sidecars/debtest1.iso -m 2552
> >
> > If I kill the qemu process then the domain does away.
> >
> > Is this expected? It doesn't seem workable if so.
> 
> Usually this means there is a dangling backend that wasn't properly
> terminated.  It would be useful to xenstore-ls the domain and see
> which backend is not in a disconnected state.

After halting that:

$ sudo xl list
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  2048 2 r-  104246.6
(null)  19 1 2 --ps-d  86.6
$ sudo xenstore-ls
tool = ""
 xenstored = ""
local = ""
 domain = ""
  0 = ""
   control = ""
feature-poweroff = "1"
feature-reboot = "1"
feature-suspend = "1"
   domid = "0"
   name = "Domain-0"
   device-model = ""
vm = ""
libxl = ""
$ sudo xenstore-ls /local/domain/19
xenstore-ls: xs_directory (/local/domain/19): No such file or directory

Cheers,
Andy

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

[Xen-devel] [libvirt test] 117772: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117737
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117737
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117737
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  335ea94e311fdd3fd590677e11ff2248fd116f2b
baseline version:
 libvirt  e3088bfd8efe0ec4a3875788aad6d69f48509c2d

Last test of basis   117737  2018-01-09 04:20:02 Z2 days
Testing same since   117772  2018-01-10 11:26:35 Z1 days1 attempts


People who touched revisions under test:
  Christian Ehrhardt 
  Intrigeri 
  Jamie Strandboge 
  Michal Privoznik 
  Serge Hallyn 
  Stefan Bader 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 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 pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 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   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

Explanation of these reports, and of osstest in general, is at

[Xen-devel] [PATCH] x86/boot: Fix boot following c/s b6c2c7f48a

[Andrew Cooper]

c/s b6c2c7f48a unfortunately broke booting on affected systems.  Most of the
time, ioemul_handle_quirk() doesn't write a custom stub, and the redundant
call was depending on the seemingly-pointless writing of the default stub.

Alter the ioemul_handle_quirk() API to return a boolean if a custom stub was
written, allowing its caller to know whether it should write a default stub
instead.

Finally, adjust the /* Regular stubs */ comment to make it clearer that the 16
refers to the length of the emul stub opcode.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/ioport_emulate.c  |  6 --
 xen/arch/x86/pv/emul-priv-op.c | 12 
 xen/arch/x86/traps.c   |  2 +-
 xen/include/asm-x86/io.h   |  2 +-
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/ioport_emulate.c b/xen/arch/x86/ioport_emulate.c
index 1f6f794..e80993a 100644
--- a/xen/arch/x86/ioport_emulate.c
+++ b/xen/arch/x86/ioport_emulate.c
@@ -8,14 +8,14 @@
 #include 
 #include 
 
-static void ioemul_handle_proliant_quirk(
+static bool ioemul_handle_proliant_quirk(
 u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs)
 {
 uint16_t port = regs->dx;
 uint8_t value = regs->al;
 
 if ( (opcode != 0xee) || (port != 0xcd4) || !(value & 0x80) )
-return;
+return false;
 
 /*pushf */
 io_emul_stub[0] = 0x9c;
@@ -37,6 +37,8 @@ static void ioemul_handle_proliant_quirk(
 io_emul_stub[9] = 0xc3;
 
 BUILD_BUG_ON(IOEMUL_QUIRK_STUB_BYTES < 10);
+
+return true;
 }
 
 static int __init proliant_quirk(struct dmi_system_id *d)
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 4087cf2..ebd6dc1 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -76,6 +76,8 @@ typedef void io_emul_stub_t(struct cpu_user_regs *);
 static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
   unsigned int port, unsigned int 
bytes)
 {
+bool use_quirk_stub = false;
+
 if ( !ctxt->io_emul_stub )
 ctxt->io_emul_stub = map_domain_page(_mfn(this_cpu(stubs.mfn))) +
  (this_cpu(stubs.addr) &
@@ -90,7 +92,11 @@ static io_emul_stub_t *io_emul_stub_setup(struct 
priv_op_ctxt *ctxt, u8 opcode,
 ctxt->io_emul_stub[10] = 0xff;
 ctxt->io_emul_stub[11] = 0xd1;
 
-if ( likely(!ioemul_handle_quirk) )
+if ( unlikely(ioemul_handle_quirk) )
+use_quirk_stub = ioemul_handle_quirk(opcode, >io_emul_stub[12],
+ ctxt->ctxt.regs);
+
+if ( !use_quirk_stub )
 {
 /* data16 or nop */
 ctxt->io_emul_stub[12] = (bytes != 2) ? 0x90 : 0x66;
@@ -101,10 +107,8 @@ static io_emul_stub_t *io_emul_stub_setup(struct 
priv_op_ctxt *ctxt, u8 opcode,
 /* ret (jumps to guest_to_host_gpr_switch) */
 ctxt->io_emul_stub[15] = 0xc3;
 }
-else
-ioemul_handle_quirk(opcode, >io_emul_stub[12], ctxt->ctxt.regs);
 
-BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(16, /* Regular stubs */
+BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(16, /* Default emul stub */
  12 + IOEMUL_QUIRK_STUB_BYTES));
 
 /* Handy function-typed pointer to the stub. */
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index db16a44..2509ea7 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -107,7 +107,7 @@ idt_entry_t idt_table[IDT_ENTRIES];
 /* Pointer to the IDT of every CPU. */
 idt_entry_t *idt_tables[NR_CPUS] __read_mostly;
 
-void (*ioemul_handle_quirk)(
+bool (*ioemul_handle_quirk)(
 u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);
 
 static int debug_stack_lines = 20;
diff --git a/xen/include/asm-x86/io.h b/xen/include/asm-x86/io.h
index e6bb20c..4d2064e 100644
--- a/xen/include/asm-x86/io.h
+++ b/xen/include/asm-x86/io.h
@@ -52,7 +52,7 @@ extern void (*pv_post_outb_hook)(unsigned int port, u8 value);
 
 /* Function pointer used to handle platform specific I/O port emulation. */
 #define IOEMUL_QUIRK_STUB_BYTES 10
-extern void (*ioemul_handle_quirk)(
+extern bool (*ioemul_handle_quirk)(
 u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);
 
 #endif
-- 
2.1.4


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

[Xen-devel] [seabios test] 117818: regressions - FAIL

[osstest service owner]

flight 117818 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117818/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  844b86464a5cbfffb62b87808632018ca250d867
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   69 days
Failing since115733  2017-11-10 17:19:59 Z   62 days   68 attempts
Testing same since   117014  2017-12-08 19:11:23 Z   34 days   23 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paul Menzel 
  Stefan Berger 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit 844b86464a5cbfffb62b87808632018ca250d867
Author: Paul Menzel 
Date:   Mon Oct 2 08:13:13 2017 +0200

docs/Download: Use more secure HTTPS URLs where possible

Signed-off-by: Paul Menzel 

commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

Re: [Xen-devel] Trying out vixen: qemu processes left behind

[Anthony Liguori]

On Thu, Jan 11, 2018 at 3:00 PM, Andy Smith  wrote:
> Hi,
>
> I'm giving Vixen a try by following the instructions in
> https://xenbits.xen.org/xsa/xsa254/README.vixen
>
> Debian jessie, xen 4.8.1 packages from jessie-backports with XSAs
> applied.
>
> I finally got a guest booted although its networking doesn't work.
> Every time I've started a guest and had it crash it's left behind a
> domain called "(null)" and a matching qemu process so I assume
> that's the device model. I thought that was just because the guest
> was failing to start.
>
> Now that I have one which boots, even when I shut it down cleanly
> there's still a domain left behind:
>
> $ sudo xl list
> NameID   Mem VCPUs  State   
> Time(s)
> Domain-0 0  2048 2 r-  
> 104114.0
> (null)  17 1 2 --ps-d  
> 14.2
> $ ps awux | grep qemu
> root  3310  1.2  1.2 430648 24676 ?SLl  22:48   0:06 
> /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 17 -chardev 
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-17,server,nowait -no-shutdown 
> -mon chardev=libxl-cmd,mode=control -chardev 
> socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-17,server,nowait 
> -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name 
> debtest1 -display none -serial pty -boot order=c -smp 2,maxcpus=2 -netdev 
> type=tap,id=net0,ifname=vif17.0-emu,script=no,downscript=no -machine xenfv 
> -cdrom /var/lib/xen/pvshim-sidecars/debtest1.iso -m 2552
>
> If I kill the qemu process then the domain does away.
>
> Is this expected? It doesn't seem workable if so.

Usually this means there is a dangling backend that wasn't properly
terminated.  It would be useful to xenstore-ls the domain and see
which backend is not in a disconnected state.

Regards,

Anthony Liguori

> Cheers,
> Andy
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Xen-devel] Trying out vixen: vif-route issue

[Andy Smith]

Hi,

On Thu, Jan 11, 2018 at 10:26:36PM +, Andy Smith wrote:
> Parsing config from /etc/xen/debtest1-with-shim.conf
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
> /etc/xen/scripts/vif-route add [31567] exited with error status 1
> libxl: error: libxl_device.c:1225:device_hotplug_child_death_cb: script: 
> /etc/xen/scripts/vif-route failed; error detected.
> libxl: error: libxl_create.c:1461:domcreate_attach_devices: unable to add nic 
> devices
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
> /etc/xen/scripts/vif-route remove [31751] exited with error status 1
> libxl: error: libxl_device.c:1225:device_hotplug_child_death_cb: script: 
> /etc/xen/scripts/vif-route failed; error detected.

I seem to have got it working. The vif-route thing was this:

https://lists.xen.org/archives/html/xen-users/2015-08/msg5.html

i.e. /etc/xen/scripts/vif-route in HVM mode is *still* being called
with both "online" and "add", and fails with the latter, leading to
"unable to add nic devices". I used Martti's suggested workaround
and things seem to work now.

In dom0 I have an extra v-debtest-emu interface that is shutdown.
What is that for? Do I need it? If not, can it be gotten rid of
somehow? It can't be doing too much if it's shutdown with no
addresses on it.

There is something odd going on with my pvgrub2 kernel which was
compiled with a ram disk. The first thing that happens is I get:

error: file `/ramdisk' not found.

Press any key to continue...

Then I can either press a key or else wait about 5 seconds, either
way pvgrub2 continues to boot, presents the menu I put in its ram
disk and the options correctly chain to whatever they are meant to
(only tested grub2 inside guest so far). The /ramdisk message
doesn't appear in PV mode so I don't know what that is about yet.

qemu process still hangs around after guest is shut down.

Cheers,
Andy

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

[Xen-devel] Trying out vixen: qemu processes left behind

[Andy Smith]

Hi,

I'm giving Vixen a try by following the instructions in
https://xenbits.xen.org/xsa/xsa254/README.vixen

Debian jessie, xen 4.8.1 packages from jessie-backports with XSAs
applied.

I finally got a guest booted although its networking doesn't work.
Every time I've started a guest and had it crash it's left behind a
domain called "(null)" and a matching qemu process so I assume
that's the device model. I thought that was just because the guest
was failing to start.

Now that I have one which boots, even when I shut it down cleanly
there's still a domain left behind:

$ sudo xl list
NameID   Mem VCPUs  State   Time(s)
Domain-0 0  2048 2 r-  104114.0
(null)  17 1 2 --ps-d  14.2
$ ps awux | grep qemu
root  3310  1.2  1.2 430648 24676 ?SLl  22:48   0:06 
/usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 17 -chardev 
socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-17,server,nowait -no-shutdown 
-mon chardev=libxl-cmd,mode=control -chardev 
socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-17,server,nowait -mon 
chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name debtest1 
-display none -serial pty -boot order=c -smp 2,maxcpus=2 -netdev 
type=tap,id=net0,ifname=vif17.0-emu,script=no,downscript=no -machine xenfv 
-cdrom /var/lib/xen/pvshim-sidecars/debtest1.iso -m 2552

If I kill the qemu process then the domain does away.

Is this expected? It doesn't seem workable if so.

Cheers,
Andy

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

Re: [Xen-devel] [Xen-users] Trying out vixen: failure to start device model

[Andy Smith]

[Cc'ing xen-devel as this bit seems like a bug in pvshim]

On Thu, Jan 11, 2018 at 09:59:24PM +, Andy Smith wrote:
> libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm: Spawning device-model 
> /var/lib/xen/pvshim-sidecars/debtest1.dm with arguments:
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> /var/lib/xen/pvshim-sidecars/debtest1.dm
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -xen-domid
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   9
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-9,server,nowait
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -no-shutdown
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -mon
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> chardev=libxl-cmd,mode=control
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -chardev
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-9,server,nowait
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -mon
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> chardev=libxenstat-cmd,mode=control
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -nodefaults
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -no-user-config
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -name
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   debtest1
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -vnc
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   127.0.0.1:0,to=99
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -display
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   none
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -kernel
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> /opt/grub/lib/grub-x86_64-xen.bin
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -serial
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   pty
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   cirrus-vga,vgamem_mb=8
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -boot
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   order=c
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -smp
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   2,maxcpus=2
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -device
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> rtl8139,id=nic0,netdev=net0,mac=00:16:5e:00:02:39
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -netdev
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> type=tap,id=net0,ifname=vif9.0-emu,script=no,downscript=no
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -machine
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   xenfv
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -cdrom
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> /var/lib/xen/pvshim-sidecars/debtest1.iso
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -m
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   2552
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -drive
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> file=/dev/ssdvg/domu_debtest1_xvda,if=ide,index=0,media=disk,format=raw,cache=writeback
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -drive
> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> file=/dev/ssdvg/domu_debtest1_xvdb,if=ide,index=1,media=disk,format=raw,cache=writeback
> libxl: debug: libxl_dm.c:2098:libxl__spawn_local_dm: Spawning device-model 
> /var/lib/xen/pvshim-sidecars/debtest1.dm with additional environment:
> libxl: debug: libxl_dm.c:2100:libxl__spawn_local_dm:   
> XEN_QEMU_CONSOLE_LIMIT=1048576
> libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x1b46a58 
> wpath=/local/domain/0/device-model/9/state token=2/2: register slotnum=2
> libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x1b46a58 
> wpath=/local/domain/0/device-model/9/state token=2/2: event 
> epath=/local/domain/0/device-model/9/state
> libxl: debug: libxl_exec.c:398:spawn_watch_event: domain 9 device model: 
> spawn watch p=(null)
> libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch 
> w=0x1b46a58 wpath=/local/domain/0/device-model/9/state token=2/2: deregister 
> slotnum=2
> libxl: error: libxl_dm.c:2189:device_model_spawn_outcome: domain 9 device 
> model: spawn failed (rc=-3)
> libxl: error: libxl_create.c:1504:domcreate_devmodel_started: device model 
> did not start: -3

I looked in the generated /var/lib/xen/pvshim-sidecars/debtest1.dm
and noted:

 63 for path in /usr/local/lib /usr/lib; do
 64 $path/xen/bin/qemu-system-i386 "${newargs[@]}" ||:
 65 done
 66 echo >&2 'could not exec qemu'

My qemu-system-i386 is at 

[Xen-devel] [PATCH v2] vixen: port of shadow PV console's page for L2 DomU

[Sarah Newman]

The current version of vixen handles console output from the guest
but not console input to the guest. This adds guest input as in

0d50a85f x86/pv-shim: shadow PV console's page for L2 DomU,

but with read_smb moved up in guest_tx.

Signed-off-by: Sergey Dyasli 
Signed-off-by: Sarah Newman 
---
 xen/arch/x86/guest/vixen.c| 42 +++
 xen/drivers/char/console.c|  6 +-
 xen/include/asm-x86/guest/vixen.h |  1 +
 3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/guest/vixen.c b/xen/arch/x86/guest/vixen.c
index 08619d1..4491d82 100644
--- a/xen/arch/x86/guest/vixen.c
+++ b/xen/arch/x86/guest/vixen.c
@@ -245,6 +245,48 @@ static void vixen_interrupt(int irq, void *dev_id, struct 
cpu_user_regs *regs)
 vixen_upcall(smp_processor_id());
 }
 
+static void notify_guest(void)
+{
+struct evtchn *chn;
+chn = evtchn_from_port(hardware_domain, vixen_xencons_port);
+evtchn_port_set_pending(hardware_domain, chn->notify_vcpu_id, chn);
+}
+
+size_t vixen_guest_tx(char c)
+{
+size_t sent = 0;
+volatile struct xencons_interface *r = vixen_xencons_iface;
+XENCONS_RING_IDX cons, prod;
+
+if (r == NULL)
+return 0;
+
+cons = ACCESS_ONCE(r->in_cons);
+prod = r->in_prod;
+/* Update pointers before accessing the ring */
+smp_rmb();
+
+ASSERT((prod - cons) <= sizeof(r->in));
+
+/* Is the ring out of space? */
+if ( sizeof(r->in) - (prod - cons) == 0 )
+goto notify;
+
+
+r->in[MASK_XENCONS_IDX(prod++, r->in)] = c;
+sent++;
+
+/* Write to the ring before updating the pointer */
+smp_wmb();
+ACCESS_ONCE(r->in_prod) = prod;
+
+ notify:
+/* Always notify the guest: prevents receive path from getting stuck. */
+notify_guest();
+
+return sent;
+}
+
 bool vixen_ring_process(uint16_t port)
 {
 volatile struct xencons_interface *r = vixen_xencons_iface;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index a83aeb2..be5875e 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -30,6 +30,7 @@
 #include  /* for do_console_io */
 #include 
 #include 
+#include 
 
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] = OPT_CONSOLE_STR;
@@ -406,13 +407,16 @@ static void __serial_rx(char c, struct cpu_user_regs 
*regs)
 serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
 /* Always notify the guest: prevents receive path from getting stuck. */
 send_global_virq(VIRQ_CONSOLE);
+
+if ( is_vixen())
+vixen_guest_tx(c);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
 {
 static int switch_code_count = 0;
 
-if ( switch_code && (c == switch_code) )
+if (!is_vixen() && switch_code && (c == switch_code) )
 {
 /* We eat CTRL- in groups of 3 to switch console input. */
 if ( ++switch_code_count == 3 )
diff --git a/xen/include/asm-x86/guest/vixen.h 
b/xen/include/asm-x86/guest/vixen.h
index eca263a..2e2666e 100644
--- a/xen/include/asm-x86/guest/vixen.h
+++ b/xen/include/asm-x86/guest/vixen.h
@@ -86,5 +86,6 @@ vixen_transform(struct domain *dom0,
 xen_pfn_t *pconsole_mfn, uint32_t *pconsole_evtchn);
 
 bool vixen_ring_process(uint16_t port);
+size_t vixen_guest_tx(char c);
 
 #endif
-- 
1.9.1


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

Re: [Xen-devel] Backport request for Arm

[Stefano Stabellini]

Backports done, I skipped 43208a9cb4c3decce67b653539c1b860121fbb5e

On Mon, 18 Dec 2017, Julien Grall wrote:
> Hi,
> 
> Below a list of potential backport patches for Xen 4.{10,9,8,7}.
> The commit are listed from the newest to the oldest.
> 
> Xen 4.10
> 
> 9630c5ae363b4cbf8eb61366530f40c80680af4d xen/arm: gic-v3: Bail out if 
> gicv3_cpu_init fail
> c05aa4afac64ea687c1a2bf9277ba6552809495b xen/arm: bootfdt: Use proper default 
> for #address-cells and #size-cells
> 
> Xen 4.9
> 
> 9630c5ae363b4cbf8eb61366530f40c80680af4d xen/arm: gic-v3: Bail out if 
> gicv3_cpu_init fail
> c05aa4afac64ea687c1a2bf9277ba6552809495b xen/arm: bootfdt: Use proper default 
> for #address-cells and #size-cells
> 0c8055c2f45f489aff67f4d362f3fdc192cc2d94 arm: configure interrupts to be in 
> non-secure group1
> abd91b2a2bcd05618a71f7e5fe571dd10a5727bc xen/arm: p2m: Check for p2m->domain 
> to be initialized before releasing resources
> b1f1e492cd4231a1e9feedb7a35c62c063f7c510 xen/arm: vgic: Check for vgic 
> handler to be initialized before dereferencing it
> 
> Xen 4.8
> 
> 9630c5ae363b4cbf8eb61366530f40c80680af4d xen/arm: gic-v3: Bail out if 
> gicv3_cpu_init fail
> c05aa4afac64ea687c1a2bf9277ba6552809495b xen/arm: bootfdt: Use proper default 
> for #address-cells and #size-cells
> 0c8055c2f45f489aff67f4d362f3fdc192cc2d94 arm: configure interrupts to be in 
> non-secure group1
> abd91b2a2bcd05618a71f7e5fe571dd10a5727bc xen/arm: p2m: Check for p2m->domain 
> to be initialized before releasing resources
> b1f1e492cd4231a1e9feedb7a35c62c063f7c510 xen/arm: vgic: Check for vgic 
> handler to be initialized before dereferencing it
> 43208a9cb4c3decce67b653539c1b860121fbb5e ARM: vGIC: avoid rank lock when 
> reading priority
>   => Require ACCESS_ONCE that is not globally available in Xen 4.8.
>   I am undecided we want that patch, it is a real bug but it would pull a 
> bit more code.
> 779a0e15ca0d9d5dbcbdee29b1dad9faf73bfc77 xen/arm: fix smpboot barriers
> 
> Xen 4.7
> 
> 9630c5ae363b4cbf8eb61366530f40c80680af4d xen/arm: gic-v3: Bail out if 
> gicv3_cpu_init fail
> c05aa4afac64ea687c1a2bf9277ba6552809495b xen/arm: bootfdt: Use proper default 
> for #address-cells and #size-cells
> 0c8055c2f45f489aff67f4d362f3fdc192cc2d94 arm: configure interrupts to be in 
> non-secure group1
> 43208a9cb4c3decce67b653539c1b860121fbb5e ARM: vGIC: avoid rank lock when 
> reading priority
>   => Require ACCESS_ONCE that is not globally available in Xen 4.7.
>   I am undecided we want that patch, it is a real bug but it would pull a 
> bit more code.
> 779a0e15ca0d9d5dbcbdee29b1dad9faf73bfc77 xen/arm: fix smpboot barriers


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

[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
 version 4

Information leak via side effects of speculative execution

UPDATES IN VERSION 4


Added README for determining which shim to use, as well as
instructions for using "Vixen" (HVM shim) and the required
conversion script

ISSUE DESCRIPTION
=

Processors give the illusion of a sequence of instructions executed
one-by-one.  However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel.  In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be.  If the guess is correct, execution has been sped up.  If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all.  This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back.  These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase.  If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks.  This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor.  Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead.  Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks.  On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.

More information is available here:
  https://meltdownattack.com/
  https://spectreattack.com/
  
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.

When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level.  (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.)  However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.

IMPACT
==

Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers.  For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes.  For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware.  Consult your
operating system provider for more information.

NOTE ON TIMING
==

This vulnerability was originally scheduled to be made public on 9
January.  It was accelerated at the request of the discloser due to
one of the issues being made public.

VULNERABLE SYSTEMS
==

Systems running all versions of Xen are affected.

For SP1 and SP2, both Intel and AMD are vulnerable.  Vulnerability of
ARM processors to SP1 

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

[Hans van Kranenburg]

On 01/11/2018 08:22 PM, Peter wrote:
> On 2018-01-11 22:16, Lars Kurth wrote:
>> And this time with attachment
>>> On 11 Jan 2018, at 09:15, Lars Kurth 
>>> wrote:
>>>
>>> I am wondering whether something like the attached table would make
>>> understanding the FAQ easier. Page 1 is clearly what is Xen specific
>>> and we definitely should cover.
>>> Page 2 in general covers Linux and guests. The first block is
>>> relatively straightforward.
>>>
>>> The 2nd and 3rd block is based on information from Doug: as there
>>> are many gaps, I would be uneasy about publishing these somewhere
>>> prominent.
>>>
>>> Also
>>>
 As this is really guest specific this information can't be
 provided by
 Xen.
>>>
>>> which carries a risk that any analysis made by anyone might only
>>> apply to the context in which the analysis was done.
>>>
>>> But the question keeps coming up, so making this clearer is maybe
>>> sensible.
> 
> In the matrix I see "Is a user space attack on the guest kernel possible
> (when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1]
> Impacts Intel CPUs only.
> 
> Is there any mitigation for this?  i.e. How to protect a guest VM from
> its own userspace processes.

That part is handled by the kernel inside the guest. Xen doesn't see
that happening.

It's for example the KPTI/KAISER patches that got into the linux kernels
now.

>>>
>>> Best Regards
>>> Lars
>>>
>>> On 10 Jan 2018, at 06:03, Juergen Gross  wrote:
>>> On 10/01/18 04:58, Peter wrote:
>>> On 2018-01-09 15:04, Stefano Stabellini wrote:
>>> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 05, 2018 at 07:05:56PM +, Andrew Cooper wrote:
>>> On 05/01/18 18:16, Rich Persaud wrote:
>>> On Jan 5, 2018, at 06:35, Lars Kurth >> > wrote:
>>> Linux’s KPTI series is designed to address SP3 only.  For Xen
>>  guests,
>>
>>> only 64-bit PV guests are affected by SP3. A KPTI-like approach was
>>> explored initially, but required significant ABI changes.
>>
>> Is some partial KPTI-like approach feasible? Like unmapping memory
>> owned
>> by other guests, but keeping Xen areas mapped? This will still allow
>> leaking Xen memory, but there are very few secrets there (vCPUs state,
>> anything else?), so overall impact will be much lower.
>>
>> +1
>>
>> I believe
>> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
>> is clear re VMs attacking/accessing the host/dom0/hypervisor and the
>> mitigations for that.
>>
>> However the page seems ambiguous about whether 64 bit VMs running as
>> PVHv2 with host provided kernels are protected or not (from each VM's
>> own processes).
>>
>> PVHv2 is using exactly the same runtime environment as HVM seen from
>> the
>> hypervisor. So a guest running as PVHv2 needs a PTI like approach like
>> HVM in its kernel.
>>
>>> Can the page be updated to be more explicit and perhaps describe how
>>> the
>>> VM kernel or how the PVHv2 virtualization provides that protection.
>>> And
>>> ideally how that could be checked from the VM itself.  e.g. grep pti
>>> /proc/cpuinfo?
>>
>> As this is really guest specific this information can't be provided by
>> Xen.
>>
>>> e.g. the page says: "Guest kernels running in 64-bit PV mode are not
>>> directly vulnerable to attack using SP3, because 64-bit PV guests
>>> already run in a KPTI-like mode." but it does not mention PVHv2 for
>>> that.  Is it protected under PVHv2?  Does it depend on the kernel?
>>> Is
>>> so what is the patchset/option/mechanism that protects the VM from
>>> its
>>> own processes?
>>
>> This question should have been answered above already.
>>
>> Juergen
>>
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


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

Re: [Xen-devel] [PATCH] vixen: port of shadow PV console's page for L2 DomU

[Wei Liu]

Hi Sarah

On Wed, Jan 10, 2018 at 09:15:52AM -0800, Sarah Newman wrote:
> The current version of vixen handles console output from the guest
> but not console input to the guest. This adds guest input as in
> 
> 0d50a85f x86/pv-shim: shadow PV console's page for L2 DomU,
> 
> but with read_smb moved up in guest_tx.
> 
> Signed-off-by: Sarah Newman 

I was wrong about Ian's script would make the console work for guest
input.

This patch looks OK, but please add back Sergey's SoB on the patch when
you submit it the next time.

Note that this patch has been since updated, but the meat of the
guest_tx should be the same, so you shouldn't worry about that.

> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index a83aeb2..be5875e 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -30,6 +30,7 @@
>  #include  /* for do_console_io */
>  #include 
>  #include 
> +#include 
>  
>  /* console: comma-separated list of console outputs. */
>  static char __initdata opt_console[30] = OPT_CONSOLE_STR;
> @@ -406,13 +407,16 @@ static void __serial_rx(char c, struct cpu_user_regs 
> *regs)
>  serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
>  /* Always notify the guest: prevents receive path from getting stuck. */
>  send_global_virq(VIRQ_CONSOLE);
> +
> +if ( is_vixen())
> +vixen_guest_tx(c);
>  }
>  
>  static void serial_rx(char c, struct cpu_user_regs *regs)
>  {
>  static int switch_code_count = 0;
>  
> -if ( switch_code && (c == switch_code) )
> +if (!is_vixen() && switch_code && (c == switch_code) )

Oh... :-)

Wei.

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

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

[Peter]

On 2018-01-11 22:16, Lars Kurth wrote:

And this time with attachment

On 11 Jan 2018, at 09:15, Lars Kurth 
wrote:

I am wondering whether something like the attached table would make
understanding the FAQ easier. Page 1 is clearly what is Xen specific
and we definitely should cover.
Page 2 in general covers Linux and guests. The first block is
relatively straightforward.

The 2nd and 3rd block is based on information from Doug: as there
are many gaps, I would be uneasy about publishing these somewhere
prominent.

Also


As this is really guest specific this information can't be
provided by
Xen.


which carries a risk that any analysis made by anyone might only
apply to the context in which the analysis was done.

But the question keeps coming up, so making this clearer is maybe
sensible.


In the matrix I see "Is a user space attack on the guest kernel possible 
(when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1] 
Impacts Intel CPUs only.


Is there any mitigation for this?  i.e. How to protect a guest VM from 
its own userspace processes.




Best Regards
Lars

On 10 Jan 2018, at 06:03, Juergen Gross  wrote:
On 10/01/18 04:58, Peter wrote:
On 2018-01-09 15:04, Stefano Stabellini wrote:
On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
On Fri, Jan 05, 2018 at 07:05:56PM +, Andrew Cooper wrote:
On 05/01/18 18:16, Rich Persaud wrote:
On Jan 5, 2018, at 06:35, Lars Kurth > wrote:
Linux’s KPTI series is designed to address SP3 only.  For Xen

 guests,


only 64-bit PV guests are affected by SP3. A KPTI-like approach was
explored initially, but required significant ABI changes.


Is some partial KPTI-like approach feasible? Like unmapping memory
owned
by other guests, but keeping Xen areas mapped? This will still allow
leaking Xen memory, but there are very few secrets there (vCPUs state,
anything else?), so overall impact will be much lower.

+1

I believe
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
is clear re VMs attacking/accessing the host/dom0/hypervisor and the
mitigations for that.

However the page seems ambiguous about whether 64 bit VMs running as
PVHv2 with host provided kernels are protected or not (from each VM's
own processes).

PVHv2 is using exactly the same runtime environment as HVM seen from
the
hypervisor. So a guest running as PVHv2 needs a PTI like approach like
HVM in its kernel.


Can the page be updated to be more explicit and perhaps describe how
the
VM kernel or how the PVHv2 virtualization provides that protection.
And
ideally how that could be checked from the VM itself.  e.g. grep pti
/proc/cpuinfo?


As this is really guest specific this information can't be provided by
Xen.


e.g. the page says: "Guest kernels running in 64-bit PV mode are not
directly vulnerable to attack using SP3, because 64-bit PV guests
already run in a KPTI-like mode." but it does not mention PVHv2 for
that.  Is it protected under PVHv2?  Does it depend on the kernel?
Is
so what is the patchset/option/mechanism that protects the VM from
its
own processes?


This question should have been answered above already.

Juergen



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

Re: [Xen-devel] [PATCH] xen/sched_rt: Move repl_timer into struct rt_private

[Dario Faggioli]

On Thu, 2018-01-11 at 17:00 +, Andrew Cooper wrote:
> struct timer is only 48 bytes and repl_timer has a 1-to-1
> correspondance with
> struct rt_private, so having it referenced by pointer is wasteful.
> 
> This avoids one memory allocation in rt_init(), and the resulting
> diffstat is:
> 
>   add/remove: 0/0 grow/shrink: 0/7 up/down: 0/-156 (-156)
>   function old new   delta
>   rt_switch_sched  134 133  -1
>   rt_context_saved 278 271  -7
>   rt_vcpu_remove   253 245  -8
>   rt_vcpu_sleep234 218 -16
>   repl_timer_handler   761 744 -17
>   rt_deinit 44  20 -24
>   rt_init  219 136 -83
> 
> As an extra bit of cleanup noticed while making this change, there is
> no need
> to call cpumask_clear() on an zeroed memory allocation.
> 
> Signed-off-by: Andrew Cooper 
>
Acked-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

[Xen-devel] [qemu-mainline baseline-only test] 74259: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74259 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74259/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf-xsm  broken
 build-armhf  broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning
 build-armhf-xsm   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  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-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 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-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-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  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-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   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 build-check(1)   blocked  n/a
 test-amd64-i386-pair  

Re: [Xen-devel] [PATCH] xen/credit2: Drop unnecessary bit test

[Dario Faggioli]

On Thu, 2018-01-11 at 16:50 +, George Dunlap wrote:
> On 01/11/2018 04:48 PM, Andrew Cooper wrote:
> > Signed-off-by: Andrew Cooper 
> > ---
> > CC: George Dunlap 
> > CC: Dario Faggioli 
> > 
> > Notices by chance while inspecting the disassembly delta for
> > "x86/bitops:
> > Introduce variable/constant pairs for __{set,clear,change}_bit()"
> > ---
> >  xen/common/sched_credit2.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > index 18f39ca..ee9768e 100644
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -2063,7 +2063,7 @@ csched2_vcpu_sleep(const struct scheduler
> > *ops, struct vcpu *vc)
> >  update_load(ops, svc->rqd, svc, -1, NOW());
> >  runq_remove(svc);
> >  }
> > -else if ( svc->flags & CSFLAG_delayed_runq_add )
> > +else
> >  __clear_bit(__CSFLAG_delayed_runq_add, >flags);
> 
> There was a reason for this at some point, I'm sure.  
>
Adding Juergen, as commit e8abdea48a ("use masking operation instead of
test_bit for CSFLAG bits") is his.

> Did this used to
> be the atomic version (without the __) originally?
> 
At the beginning, yes. In fact, if you look at how the code was before
Juergen's patch:

else if ( test_bit(__CSFLAG_delayed_runq_add, >flags) )
 clear_bit(__CSFLAG_delayed_runq_add, >flags);

Which indeed was overkill. That patch got rid of test_bit(), but did
not touch clear_bit().

I then turned the clear_bit() in __clear_bit() in commit 34f2ad
("xen: credit2: use non-atomic cpumask and bit operations") but kept
the test.

From a code readability perspective, I like this patch (and have
thought about doing this myself many times). From a performance
perspective, the test may make sense. In fact, we do a technically
unnecessary "load", but that may avoid having to pay the price of a
"store".

I guess it's debatable whether that is worth or not, in general.
However, at least in this specific case, I don't think this matters too
 much, and I'd be inclined to take the patch.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH] x86/link: Don't merge .init.text and .init.data

[Konrad Rzeszutek Wilk]

On Thu, Jan 11, 2018 at 03:06:37PM +, Andrew Cooper wrote:
> On 11/01/18 14:58, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 11, 2018 at 02:17:57PM +, Andrew Cooper wrote:
> >> c/s 1308f0170c merged .init.text and .init.data, because EFI might properly
> >> write-protect r/o sections.
> >>
> >> However, this change makes xen-syms unusable for disassembly analysis.  In
> > s/this makes/that made/
> 
> Erm.  I'm not sure how to apply that regex, but I've changed to
> 
> "However, that change makes xen-syms unusable for disassembly analysis."

Perhaps s/makes/made/ ? Just speculating ..

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

[Xen-devel] [PATCH] xen/sched_rt: Move repl_timer into struct rt_private

[Andrew Cooper]

struct timer is only 48 bytes and repl_timer has a 1-to-1 correspondance with
struct rt_private, so having it referenced by pointer is wasteful.

This avoids one memory allocation in rt_init(), and the resulting diffstat is:

  add/remove: 0/0 grow/shrink: 0/7 up/down: 0/-156 (-156)
  function old new   delta
  rt_switch_sched  134 133  -1
  rt_context_saved 278 271  -7
  rt_vcpu_remove   253 245  -8
  rt_vcpu_sleep234 218 -16
  repl_timer_handler   761 744 -17
  rt_deinit 44  20 -24
  rt_init  219 136 -83

As an extra bit of cleanup noticed while making this change, there is no need
to call cpumask_clear() on an zeroed memory allocation.

Signed-off-by: Andrew Cooper 
---
CC: Dario Faggioli 
CC: Meng Xu 

Also noticed by chance while inspecting the disassembly delta for "x86/bitops:
Introduce variable/constant pairs for __{set,clear,change}_bit()"
---
 xen/common/sched_rt.c | 45 +
 1 file changed, 17 insertions(+), 28 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index b770287..a202802 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -186,7 +186,7 @@ struct rt_private {
 struct list_head runq;  /* ordered list of runnable vcpus */
 struct list_head depletedq; /* unordered list of depleted vcpus */
 
-struct timer *repl_timer;   /* replenishment timer */
+struct timer repl_timer;/* replenishment timer */
 struct list_head replq; /* ordered list of vcpus that need 
replenishment */
 
 cpumask_t tickled;  /* cpus been tickled */
@@ -554,10 +554,10 @@ replq_remove(const struct scheduler *ops, struct rt_vcpu 
*svc)
 if ( !list_empty(replq) )
 {
 struct rt_vcpu *svc_next = replq_elem(replq->next);
-set_timer(prv->repl_timer, svc_next->cur_deadline);
+set_timer(>repl_timer, svc_next->cur_deadline);
 }
 else
-stop_timer(prv->repl_timer);
+stop_timer(>repl_timer);
 }
 }
 
@@ -597,7 +597,7 @@ replq_insert(const struct scheduler *ops, struct rt_vcpu 
*svc)
  * at the front of the event list.
  */
 if ( deadline_replq_insert(svc, >replq_elem, replq) )
-set_timer(prv->repl_timer, svc->cur_deadline);
+set_timer(>repl_timer, svc->cur_deadline);
 }
 
 /*
@@ -634,7 +634,7 @@ replq_reinsert(const struct scheduler *ops, struct rt_vcpu 
*svc)
 rearm = deadline_replq_insert(svc, >replq_elem, replq);
 
 if ( rearm )
-set_timer(rt_priv(ops)->repl_timer, rearm_svc->cur_deadline);
+set_timer(_priv(ops)->repl_timer, rearm_svc->cur_deadline);
 }
 
 /*
@@ -676,27 +676,18 @@ rt_init(struct scheduler *ops)
 if ( prv == NULL )
 goto err;
 
-prv->repl_timer = xzalloc(struct timer);
-if ( prv->repl_timer == NULL )
-goto err;
-
 spin_lock_init(>lock);
 INIT_LIST_HEAD(>sdom);
 INIT_LIST_HEAD(>runq);
 INIT_LIST_HEAD(>depletedq);
 INIT_LIST_HEAD(>replq);
 
-cpumask_clear(>tickled);
-
 ops->sched_data = prv;
 rc = 0;
 
  err:
-if ( rc && prv )
-{
-xfree(prv->repl_timer);
+if ( rc )
 xfree(prv);
-}
 
 return rc;
 }
@@ -706,9 +697,8 @@ rt_deinit(struct scheduler *ops)
 {
 struct rt_private *prv = rt_priv(ops);
 
-ASSERT(prv->repl_timer->status == TIMER_STATUS_invalid ||
-   prv->repl_timer->status == TIMER_STATUS_killed);
-xfree(prv->repl_timer);
+ASSERT(prv->repl_timer.status == TIMER_STATUS_invalid ||
+   prv->repl_timer.status == TIMER_STATUS_killed);
 
 ops->sched_data = NULL;
 xfree(prv);
@@ -731,9 +721,9 @@ rt_init_pdata(const struct scheduler *ops, void *pdata, int 
cpu)
  * TIMER_STATUS_invalid means we are the first cpu that sees the timer
  * allocated but not initialized, and so it's up to us to initialize it.
  */
-if ( prv->repl_timer->status == TIMER_STATUS_invalid )
+if ( prv->repl_timer.status == TIMER_STATUS_invalid )
 {
-init_timer(prv->repl_timer, repl_timer_handler, (void*) ops, cpu);
+init_timer(>repl_timer, repl_timer_handler, (void *)ops, cpu);
 dprintk(XENLOG_DEBUG, "RTDS: timer initialized on cpu %u\n", cpu);
 }
 
@@ -769,10 +759,10 @@ rt_switch_sched(struct scheduler *new_ops, unsigned int 
cpu,
  * removed (in which case we'll see TIMER_STATUS_killed), it's our
  * job to (re)initialize the timer.
  */
-if ( prv->repl_timer->status == TIMER_STATUS_invalid ||
- prv->repl_timer->status == TIMER_STATUS_killed )
+if ( prv->repl_timer.status == 

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Konrad Rzeszutek Wilk]

On Thu, Jan 11, 2018 at 03:17:45PM +, George Dunlap wrote:
> On 01/10/2018 01:34 PM, George Dunlap wrote:
> > * Executive summary
> > 
> > - We've agreed on a "convergence" point for PV shim functionality that
> >   covers as many users as possible:
> >  - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
> >event channels, , booted via 'sidecar'
> >  - 'PVH' functionality: boots in PVH mode, booted via toolstack
> >changes
> > 
> > - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
> >   each cover some users and not others; neither one (yet) covers all
> >   users
> 
> Proposed codenames we can use for shorthand:
> 
> "Vixen": Amazon's HVM+sidecar shim solution
> "Comet": Citrix's PVH+toolstack shim solution
> "Rudolph": Long-term solution combining both
> 
> In the Xen mythos then, Rudolph could be the child of Vixen and Comet. :-)



> 
> Cultural references (given that 'Vixen' and 'Comet' were both developed
> in the run up to Christmas):
> 
> * https://www.teachervision.com/twas-night-christmas-full-text
> *
> http://www.metrolyrics.com/rudolph-the-red-nosed-reindeer-lyrics-christmas-carols.html
> 
>  -George

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[George Dunlap]

On 01/11/2018 04:52 PM, Rich Persaud wrote:
> On Jan 11, 2018, at 11:36, Stefano Stabellini  wrote:
>>
>>> On Thu, 11 Jan 2018, George Dunlap wrote:
 On 01/11/2018 04:23 PM, Stefano Stabellini wrote:
 On Thu, 11 Jan 2018, Jan Beulich wrote:
 On 10.01.18 at 18:25,  wrote:
>>> On Wed, 10 Jan 2018, George Dunlap wrote:
>>> * Executive summary
>>>
>>> - We've agreed on a "convergence" point for PV shim functionality that
>>>  covers as many users as possible:
>>> - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
>>>   event channels, , booted via 'sidecar'
>>> - 'PVH' functionality: boots in PVH mode, booted via toolstack
>>>   changes
>>>
>>> - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
>>>  each cover some users and not others; neither one (yet) covers all
>>>  users
>>
>> Sorry for being punctilious, but neither one can cover all users: there
>> are users without VT-x on their platform, and both approaches require
>> VT-x.
>
> For the record, yesterday I've decided to make an attempt to
> create a very simplistic patch to deal with the issue in the
> hypervisor, ignoring (almost) all performance considerations
> (not all, because I didn't want to go the "disable caching" route).
> I've dealt with some of the to-be-expected early bugs, but I'm
> now debugging a host hang (note: not a triple fault apparently,
> as the box doesn't reboot, yet triple faults is what I would have
> expected to occur if anything is wrong here or missing).
>
> I know that's late, and I have to admit that I don't understand
> myself why I didn't consider doing such earlier on, but the
> much increased pressure to get something like the shim out,
> which
> - doesn't address all cases
> - requires changes to how VMs are being created (which likely will
>  be a problem for various customers)
> - later will want those changes undone
> plus the pretty obvious impossibility to backport something like
> Andrew's (not yet complete) series to baselines as old as 3.2
> made it seem to me that some (measurable!) performance
> overhead can't be all that bad in the given situation.

 Thank you for giving it a look! I completely agree with you on these
 points. I think we should approach this problem with the assumption that
 this is going to be the only long term solution to SP3, while Vixen (or
 PVshim) incomplete stopgaps for now.
>>>
>>> Well the pvshim is a feature for people who want to be able to eliminate
>>> all PV interfaces to the hypervisor whatsover for security / maintenance
>>> purposes.  I do agree a "proper" fix for PV would be good, assuming the
>>> overhead is lower than pvshim.
>>
>> Why "assuming the overhead is lower than pvshim"? What if the overhead
>> is higher?  As I said, there are users that *cannot* deploy HVM because
>> it is not available to them.
>>
>> In other words, PVshim is irrelevant to me because I cannot use it.
> 
> Would a “proper” PV fix (does this have a codename?) benefit stubdoms?  These 
> are needed to isolate Qemu, e.g. on an HVM driver domain.  PVshim does not 
> yet support driver domains.

We'd have to see the actual code before we could be sure, but I can't
think of a reason why a "proper" PV fix wouldn't work for driver domains.

 -George

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Stefano Stabellini]

On Thu, 11 Jan 2018, Rich Persaud wrote:
> On Jan 11, 2018, at 11:36, Stefano Stabellini  wrote:
> > 
> >> On Thu, 11 Jan 2018, George Dunlap wrote:
> >>> On 01/11/2018 04:23 PM, Stefano Stabellini wrote:
> >>> On Thu, 11 Jan 2018, Jan Beulich wrote:
> >>> On 10.01.18 at 18:25,  wrote:
> >> On Wed, 10 Jan 2018, George Dunlap wrote:
> >> * Executive summary
> >> 
> >> - We've agreed on a "convergence" point for PV shim functionality that
> >>  covers as many users as possible:
> >> - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
> >>   event channels, , booted via 'sidecar'
> >> - 'PVH' functionality: boots in PVH mode, booted via toolstack
> >>   changes
> >> 
> >> - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
> >>  each cover some users and not others; neither one (yet) covers all
> >>  users
> > 
> > Sorry for being punctilious, but neither one can cover all users: there
> > are users without VT-x on their platform, and both approaches require
> > VT-x.
>  
>  For the record, yesterday I've decided to make an attempt to
>  create a very simplistic patch to deal with the issue in the
>  hypervisor, ignoring (almost) all performance considerations
>  (not all, because I didn't want to go the "disable caching" route).
>  I've dealt with some of the to-be-expected early bugs, but I'm
>  now debugging a host hang (note: not a triple fault apparently,
>  as the box doesn't reboot, yet triple faults is what I would have
>  expected to occur if anything is wrong here or missing).
>  
>  I know that's late, and I have to admit that I don't understand
>  myself why I didn't consider doing such earlier on, but the
>  much increased pressure to get something like the shim out,
>  which
>  - doesn't address all cases
>  - requires changes to how VMs are being created (which likely will
>   be a problem for various customers)
>  - later will want those changes undone
>  plus the pretty obvious impossibility to backport something like
>  Andrew's (not yet complete) series to baselines as old as 3.2
>  made it seem to me that some (measurable!) performance
>  overhead can't be all that bad in the given situation.
> >>> 
> >>> Thank you for giving it a look! I completely agree with you on these
> >>> points. I think we should approach this problem with the assumption that
> >>> this is going to be the only long term solution to SP3, while Vixen (or
> >>> PVshim) incomplete stopgaps for now.
> >> 
> >> Well the pvshim is a feature for people who want to be able to eliminate
> >> all PV interfaces to the hypervisor whatsover for security / maintenance
> >> purposes.  I do agree a "proper" fix for PV would be good, assuming the
> >> overhead is lower than pvshim.
> > 
> > Why "assuming the overhead is lower than pvshim"? What if the overhead
> > is higher?  As I said, there are users that *cannot* deploy HVM because
> > it is not available to them.
> > 
> > In other words, PVshim is irrelevant to me because I cannot use it.
> 
> Would a “proper” PV fix (does this have a codename?) benefit stubdoms?  These 
> are needed to isolate Qemu, e.g. on an HVM driver domain.  PVshim does not 
> yet support driver domains.

Yes, good point. A "proper" fix should support stubdoms too. I think
that Jan's approach above should be able to cover them.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  3cf7ee82e16cacd7c3dd371dead46b90f52fa905
baseline version:
 xen  21bd8b8b0836702284d283e2bbb104ed9e0d5865

Last test of basis   117834  2018-01-11 13:01:32 Z0 days
Testing same since   117843  2018-01-11 15:01:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Juergen Gross 
  Meng Xu 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   21bd8b8b08..3cf7ee82e1  3cf7ee82e16cacd7c3dd371dead46b90f52fa905 -> smoke

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Rich Persaud]

On Jan 11, 2018, at 11:36, Stefano Stabellini  wrote:
> 
>> On Thu, 11 Jan 2018, George Dunlap wrote:
>>> On 01/11/2018 04:23 PM, Stefano Stabellini wrote:
>>> On Thu, 11 Jan 2018, Jan Beulich wrote:
>>> On 10.01.18 at 18:25,  wrote:
>> On Wed, 10 Jan 2018, George Dunlap wrote:
>> * Executive summary
>> 
>> - We've agreed on a "convergence" point for PV shim functionality that
>>  covers as many users as possible:
>> - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
>>   event channels, , booted via 'sidecar'
>> - 'PVH' functionality: boots in PVH mode, booted via toolstack
>>   changes
>> 
>> - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
>>  each cover some users and not others; neither one (yet) covers all
>>  users
> 
> Sorry for being punctilious, but neither one can cover all users: there
> are users without VT-x on their platform, and both approaches require
> VT-x.
 
 For the record, yesterday I've decided to make an attempt to
 create a very simplistic patch to deal with the issue in the
 hypervisor, ignoring (almost) all performance considerations
 (not all, because I didn't want to go the "disable caching" route).
 I've dealt with some of the to-be-expected early bugs, but I'm
 now debugging a host hang (note: not a triple fault apparently,
 as the box doesn't reboot, yet triple faults is what I would have
 expected to occur if anything is wrong here or missing).
 
 I know that's late, and I have to admit that I don't understand
 myself why I didn't consider doing such earlier on, but the
 much increased pressure to get something like the shim out,
 which
 - doesn't address all cases
 - requires changes to how VMs are being created (which likely will
  be a problem for various customers)
 - later will want those changes undone
 plus the pretty obvious impossibility to backport something like
 Andrew's (not yet complete) series to baselines as old as 3.2
 made it seem to me that some (measurable!) performance
 overhead can't be all that bad in the given situation.
>>> 
>>> Thank you for giving it a look! I completely agree with you on these
>>> points. I think we should approach this problem with the assumption that
>>> this is going to be the only long term solution to SP3, while Vixen (or
>>> PVshim) incomplete stopgaps for now.
>> 
>> Well the pvshim is a feature for people who want to be able to eliminate
>> all PV interfaces to the hypervisor whatsover for security / maintenance
>> purposes.  I do agree a "proper" fix for PV would be good, assuming the
>> overhead is lower than pvshim.
> 
> Why "assuming the overhead is lower than pvshim"? What if the overhead
> is higher?  As I said, there are users that *cannot* deploy HVM because
> it is not available to them.
> 
> In other words, PVshim is irrelevant to me because I cannot use it.

Would a “proper” PV fix (does this have a codename?) benefit stubdoms?  These 
are needed to isolate Qemu, e.g. on an HVM driver domain.  PVshim does not yet 
support driver domains.

Rich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/credit2: Drop unnecessary bit test

[George Dunlap]

On 01/11/2018 04:48 PM, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper 
> ---
> CC: George Dunlap 
> CC: Dario Faggioli 
> 
> Notices by chance while inspecting the disassembly delta for "x86/bitops:
> Introduce variable/constant pairs for __{set,clear,change}_bit()"
> ---
>  xen/common/sched_credit2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 18f39ca..ee9768e 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -2063,7 +2063,7 @@ csched2_vcpu_sleep(const struct scheduler *ops, struct 
> vcpu *vc)
>  update_load(ops, svc->rqd, svc, -1, NOW());
>  runq_remove(svc);
>  }
> -else if ( svc->flags & CSFLAG_delayed_runq_add )
> +else
>  __clear_bit(__CSFLAG_delayed_runq_add, >flags);

There was a reason for this at some point, I'm sure.  Did this used to
be the atomic version (without the __) originally?

 -George

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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Stefano Stabellini]

On Thu, 11 Jan 2018, George Dunlap wrote:
> On 01/11/2018 04:23 PM, Stefano Stabellini wrote:
> > On Thu, 11 Jan 2018, Jan Beulich wrote:
> > On 10.01.18 at 18:25,  wrote:
> >>> On Wed, 10 Jan 2018, George Dunlap wrote:
>  * Executive summary
> 
>  - We've agreed on a "convergence" point for PV shim functionality that
>    covers as many users as possible:
>   - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
> event channels, , booted via 'sidecar'
>   - 'PVH' functionality: boots in PVH mode, booted via toolstack
> changes
> 
>  - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
>    each cover some users and not others; neither one (yet) covers all
>    users
> >>>
> >>> Sorry for being punctilious, but neither one can cover all users: there
> >>> are users without VT-x on their platform, and both approaches require
> >>> VT-x.
> >>
> >> For the record, yesterday I've decided to make an attempt to
> >> create a very simplistic patch to deal with the issue in the
> >> hypervisor, ignoring (almost) all performance considerations
> >> (not all, because I didn't want to go the "disable caching" route).
> >> I've dealt with some of the to-be-expected early bugs, but I'm
> >> now debugging a host hang (note: not a triple fault apparently,
> >> as the box doesn't reboot, yet triple faults is what I would have
> >> expected to occur if anything is wrong here or missing).
> >>
> >> I know that's late, and I have to admit that I don't understand
> >> myself why I didn't consider doing such earlier on, but the
> >> much increased pressure to get something like the shim out,
> >> which
> >> - doesn't address all cases
> >> - requires changes to how VMs are being created (which likely will
> >>   be a problem for various customers)
> >> - later will want those changes undone
> >> plus the pretty obvious impossibility to backport something like
> >> Andrew's (not yet complete) series to baselines as old as 3.2
> >> made it seem to me that some (measurable!) performance
> >> overhead can't be all that bad in the given situation.
> > 
> > Thank you for giving it a look! I completely agree with you on these
> > points. I think we should approach this problem with the assumption that
> > this is going to be the only long term solution to SP3, while Vixen (or
> > PVshim) incomplete stopgaps for now.
> 
> Well the pvshim is a feature for people who want to be able to eliminate
> all PV interfaces to the hypervisor whatsover for security / maintenance
> purposes.  I do agree a "proper" fix for PV would be good, assuming the
> overhead is lower than pvshim.

Why "assuming the overhead is lower than pvshim"? What if the overhead
is higher?  As I said, there are users that *cannot* deploy HVM because
it is not available to them.

In other words, PVshim is irrelevant to me because I cannot use it.

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

[Xen-devel] [PATCH] x86/bitops: Introduce variable/constant pairs for __{set, clear, change}_bit()

[Andrew Cooper]

Just as with test_bit, the non-atomic set/clear/change helpers can be better
optimised by the compiler in the case that the nr parameter is constant, and
it often is.

This results in a general replacement of `mov $imm, %reg; bt* %reg, mem` with
the more simple `op $imm, mem`, reducing register pressure.

The net diffstat is:
  add/remove: 0/1 grow/shrink: 5/17 up/down: 90/-301 (-211)

As a piece of minor cleanup, drop unnecessary brackets in the test_bit()
macro, and fix the indentation.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/include/asm-x86/bitops.h | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/xen/include/asm-x86/bitops.h b/xen/include/asm-x86/bitops.h
index 440abb7..cbc7d36 100644
--- a/xen/include/asm-x86/bitops.h
+++ b/xen/include/asm-x86/bitops.h
@@ -51,13 +51,19 @@ static inline void set_bit(int nr, volatile void *addr)
  * If it's called on the same region of memory simultaneously, the effect
  * may be that only one operation succeeds.
  */
-static inline void __set_bit(int nr, void *addr)
+static inline void variable_set_bit(int nr, void *addr)
 {
 asm volatile ( "btsl %1,%0" : "+m" (*(int *)addr) : "Ir" (nr) : "memory" );
 }
+static inline void constant_set_bit(int nr, void *addr)
+{
+((unsigned int *)addr)[nr >> 5] |= (1u << (nr & 31));
+}
 #define __set_bit(nr, addr) ({  \
 if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
-__set_bit(nr, addr);\
+__builtin_constant_p(nr) ?  \
+constant_set_bit(nr, addr) :\
+variable_set_bit(nr, addr); \
 })
 
 /**
@@ -86,13 +92,19 @@ static inline void clear_bit(int nr, volatile void *addr)
  * If it's called on the same region of memory simultaneously, the effect
  * may be that only one operation succeeds.
  */
-static inline void __clear_bit(int nr, void *addr)
+static inline void variable_clear_bit(int nr, void *addr)
 {
 asm volatile ( "btrl %1,%0" : "+m" (*(int *)addr) : "Ir" (nr) : "memory" );
 }
+static inline void constant_clear_bit(int nr, void *addr)
+{
+((unsigned int *)addr)[nr >> 5] &= ~(1u << (nr & 31));
+}
 #define __clear_bit(nr, addr) ({\
 if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
-__clear_bit(nr, addr);  \
+__builtin_constant_p(nr) ?  \
+constant_clear_bit(nr, addr) :  \
+variable_clear_bit(nr, addr);   \
 })
 
 /**
@@ -104,13 +116,19 @@ static inline void __clear_bit(int nr, void *addr)
  * If it's called on the same region of memory simultaneously, the effect
  * may be that only one operation succeeds.
  */
-static inline void __change_bit(int nr, void *addr)
+static inline void variable_change_bit(int nr, void *addr)
 {
 asm volatile ( "btcl %1,%0" : "+m" (*(int *)addr) : "Ir" (nr) : "memory" );
 }
+static inline void constant_change_bit(int nr, void *addr)
+{
+((unsigned int *)addr)[nr >> 5] ^= ~(1u << (nr & 31));
+}
 #define __change_bit(nr, addr) ({   \
 if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
-__change_bit(nr, addr); \
+__builtin_constant_p(nr) ?  \
+constant_change_bit(nr, addr) : \
+variable_change_bit(nr, addr);  \
 })
 
 /**
@@ -291,9 +309,9 @@ static inline int variable_test_bit(int nr, const volatile 
void *addr)
 
 #define test_bit(nr, addr) ({   \
 if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
-(__builtin_constant_p(nr) ? \
- constant_test_bit((nr),(addr)) :   \
- variable_test_bit((nr),(addr)));   \
+__builtin_constant_p(nr) ?  \
+constant_test_bit(nr, addr) :   \
+variable_test_bit(nr, addr);\
 })
 
 extern unsigned int __find_first_bit(
-- 
2.1.4


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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[George Dunlap]

On 01/11/2018 04:23 PM, Stefano Stabellini wrote:
> On Thu, 11 Jan 2018, Jan Beulich wrote:
> On 10.01.18 at 18:25,  wrote:
>>> On Wed, 10 Jan 2018, George Dunlap wrote:
 * Executive summary

 - We've agreed on a "convergence" point for PV shim functionality that
   covers as many users as possible:
  - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
event channels, , booted via 'sidecar'
  - 'PVH' functionality: boots in PVH mode, booted via toolstack
changes

 - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
   each cover some users and not others; neither one (yet) covers all
   users
>>>
>>> Sorry for being punctilious, but neither one can cover all users: there
>>> are users without VT-x on their platform, and both approaches require
>>> VT-x.
>>
>> For the record, yesterday I've decided to make an attempt to
>> create a very simplistic patch to deal with the issue in the
>> hypervisor, ignoring (almost) all performance considerations
>> (not all, because I didn't want to go the "disable caching" route).
>> I've dealt with some of the to-be-expected early bugs, but I'm
>> now debugging a host hang (note: not a triple fault apparently,
>> as the box doesn't reboot, yet triple faults is what I would have
>> expected to occur if anything is wrong here or missing).
>>
>> I know that's late, and I have to admit that I don't understand
>> myself why I didn't consider doing such earlier on, but the
>> much increased pressure to get something like the shim out,
>> which
>> - doesn't address all cases
>> - requires changes to how VMs are being created (which likely will
>>   be a problem for various customers)
>> - later will want those changes undone
>> plus the pretty obvious impossibility to backport something like
>> Andrew's (not yet complete) series to baselines as old as 3.2
>> made it seem to me that some (measurable!) performance
>> overhead can't be all that bad in the given situation.
> 
> Thank you for giving it a look! I completely agree with you on these
> points. I think we should approach this problem with the assumption that
> this is going to be the only long term solution to SP3, while Vixen (or
> PVshim) incomplete stopgaps for now.

Well the pvshim is a feature for people who want to be able to eliminate
all PV interfaces to the hypervisor whatsover for security / maintenance
purposes.  I do agree a "proper" fix for PV would be good, assuming the
overhead is lower than pvshim.

 -George


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

Re: [Xen-devel] [PATCH 2/2] xen-netfront: Fix race between device setup and open

[David Miller]

From: Ross Lagerwall 
Date: Thu, 11 Jan 2018 15:49:07 +

> I've now added CC'd netdev on the other two.

That doesn't work.

If you don't post the originals explicitly to netdev then it won't
get properly queued in patchwork.

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

Re: [Xen-devel] [PATCH 2/2] xen-netfront: Fix race between device setup and open

[Ross Lagerwall]

On 01/11/2018 03:26 PM, David Miller wrote:

From: Ross Lagerwall 
Date: Thu, 11 Jan 2018 09:36:38 +


When a netfront device is set up it registers a netdev fairly early on,
before it has set up the queues and is actually usable. A userspace tool
like NetworkManager will immediately try to open it and access its state
as soon as it appears. The bug can be reproduced by hotplugging VIFs
until the VM runs out of grant refs. It registers the netdev but fails
to set up any queues (since there are no more grant refs). In the
meantime, NetworkManager opens the device and the kernel crashes trying
to access the queues (of which there are none).

Fix this in two ways:
* For initial setup, register the netdev much later, after the queues
are setup. This avoids the race entirely.
* During a suspend/resume cycle, the frontend reconnects to the backend
and the queues are recreated. It is possible (though highly unlikely) to
race with something opening the device and accessing the queues after
they have been destroyed but before they have been recreated. Extend the
region covered by the rtnl semaphore to protect against this race. There
is a possibility that we fail to recreate the queues so check for this
in the open function.

Signed-off-by: Ross Lagerwall 


Where is patch 1/2 and the 0/2 header posting which explains what this
patch series is doing, how it is doing it, and why it is doing it that
way?



I've now added CC'd netdev on the other two.

Cheers,
--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH 0/2] Fix a couple of crashes in netfront

[Ross Lagerwall]

+CC netdev

On 01/11/2018 09:36 AM, Ross Lagerwall wrote:

Here are a couple of patches to fix two crashes in netfront.

Ross Lagerwall (2):
   xen/grant-table: Use put_page instead of free_page
   xen-netfront: Fix race between device setup and open

  drivers/net/xen-netfront.c | 46 --
  drivers/xen/grant-table.c  |  4 ++--
  2 files changed, 26 insertions(+), 24 deletions(-)



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

Re: [Xen-devel] [PATCH 1/2] xen/grant-table: Use put_page instead of free_page

[Ross Lagerwall]

+CC netdev

On 01/11/2018 09:36 AM, Ross Lagerwall wrote:

The page given to gnttab_end_foreign_access() to free could be a
compound page so use put_page() instead of free_page() since it can
handle both compound and single pages correctly.

This bug was discovered when migrating a Xen VM with several VIFs and
CONFIG_DEBUG_VM enabled. It hits a BUG usually after fewer than 10
iterations. All netfront devices disconnect from the backend during a
suspend/resume and this will call gnttab_end_foreign_access() if a
netfront queue has an outstanding skb. The mismatch between calling
get_page() and free_page() on a compound page causes a reference
counting error which is detected when DEBUG_VM is enabled.

Signed-off-by: Ross Lagerwall 
---
  drivers/xen/grant-table.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index f45114f..27be107 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -382,7 +382,7 @@ static void gnttab_handle_deferred(struct timer_list 
*unused)
if (entry->page) {
pr_debug("freeing g.e. %#x (pfn %#lx)\n",
 entry->ref, page_to_pfn(entry->page));
-   __free_page(entry->page);
+   put_page(entry->page);
} else
pr_info("freeing g.e. %#x\n", entry->ref);
kfree(entry);
@@ -438,7 +438,7 @@ void gnttab_end_foreign_access(grant_ref_t ref, int 
readonly,
if (gnttab_end_foreign_access_ref(ref, readonly)) {
put_free_entry(ref);
if (page != 0)
-   free_page(page);
+   put_page(virt_to_page(page));
} else
gnttab_add_deferred(ref, readonly,
page ? virt_to_page(page) : NULL);



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

Re: [Xen-devel] [PATCH RFC v1 00/74] Run PV guest in PVH container

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] [PATCH RFC v1 00/74] Run PV guest in PVH 
container"):
> Xen 4.10
> 
...
>  => code change: the backport should set the default non-NULL
> values only if the pvhshim boolean is true after defaulting

I discover, looking at the code, that this is already true.

> New callers with old libxl on 4.10:
> ---
> 
> If the caller is creating a guest other than a PVH one there is no
> change to the ABI.
> 
> When a caller creates a PVH non-shim guest, it will probably not set
> any of these fields.  Things will work properly.
> 
> If a caller tries to create a shim guest, the attempt to do so will be
> ignored and the guest will be created as PV.  Probably, the guest will
> not boot.  Additionally, if the caller filled in pvshim cmdline or
> path information, it will probably expect *dispose* to free those
> values - and the result will be a memory leak.
> 
> If the caller is examining existing guests, PV and HVM guests will
> work fine.  If the caller is examining existing PVH guests, the
> library will not initialise the new fields.  The result may include an
> uninitialised read by the caller.
> 
> Overall: this is not safe and should be prevented.
> 
>  => code change: the 4.10 backport should use symbol versioning or
> another technique to prevent expecting callers whose source code
> understands *shim* guests from using libxl versions which don't.

This is only _really_ needed to avoid trouble when:
  * New tool has been installed
  * New libxl has not been installed
  * PVH guests (including shim guests) have been created by tool A
  * Tool B has not been updated, and is used to examine guests

We do not have any symbol versioning in libxl in 4.10 and it is hard
to think of another way to make this work without changes to the tool
source code.  I don't want to invent something ad-hoc.

So I propose to skip this.

Wei: My conclusion is that the libxl tools branch (including George's
"libxl: introduce hack" patch, as I I sent you previously, is suitable
for simple rebase to 4.10.

Ian.

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

Re: [Xen-devel] [PATCH 2/2] xen-netfront: Fix race between device setup and open

[David Miller]

From: Ross Lagerwall 
Date: Thu, 11 Jan 2018 09:36:38 +

> When a netfront device is set up it registers a netdev fairly early on,
> before it has set up the queues and is actually usable. A userspace tool
> like NetworkManager will immediately try to open it and access its state
> as soon as it appears. The bug can be reproduced by hotplugging VIFs
> until the VM runs out of grant refs. It registers the netdev but fails
> to set up any queues (since there are no more grant refs). In the
> meantime, NetworkManager opens the device and the kernel crashes trying
> to access the queues (of which there are none).
> 
> Fix this in two ways:
> * For initial setup, register the netdev much later, after the queues
> are setup. This avoids the race entirely.
> * During a suspend/resume cycle, the frontend reconnects to the backend
> and the queues are recreated. It is possible (though highly unlikely) to
> race with something opening the device and accessing the queues after
> they have been destroyed but before they have been recreated. Extend the
> region covered by the rtnl semaphore to protect against this race. There
> is a possibility that we fail to recreate the queues so check for this
> in the open function.
> 
> Signed-off-by: Ross Lagerwall 

Where is patch 1/2 and the 0/2 header posting which explains what this
patch series is doing, how it is doing it, and why it is doing it that
way?

Thanks.

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

Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

[Hans van Kranenburg]

On 01/10/2018 06:50 AM, Juergen Gross wrote:
> On 09/01/18 23:11, Hans van Kranenburg wrote:
>> On 01/09/2018 07:22 PM, Rich Persaud wrote:
>>>
>>
>>> Since the primary audience for security fixes are production
>>> deployments of Xen where customer assets are at risk, is there an
>>> estimate for the percentage/size of Xen deployments where PVH (not
>>> only Xen 4.10) has already been deployed for production customers?
>>> That could give other customers more confidence in deploying PVH in
>>> production.
>> +1
>>
>> I have been hearing mostly-very-positive stories around, except for the
>> missing pvgrub2 support. :)
> 
> https://lists.xen.org/archives/html/xen-devel/2017-11/msg01795.html

Ah thanks. I also found the links to kernel changes and a xen change.

http://lists.gnu.org/archive/html/grub-devel/2017-12/msg2.html

I'm going to play around with it, see if I can get it running. Being
able to use pvgrub2 will mean ending up with an incredibly smooth
migration path to Xen 4.10 and PVHv2...

Hans


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

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[George Dunlap]

On 01/10/2018 01:34 PM, George Dunlap wrote:
> * Executive summary
> 
> - We've agreed on a "convergence" point for PV shim functionality that
>   covers as many users as possible:
>  - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
>event channels, , booted via 'sidecar'
>  - 'PVH' functionality: boots in PVH mode, booted via toolstack
>changes
> 
> - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
>   each cover some users and not others; neither one (yet) covers all
>   users

Proposed codenames we can use for shorthand:

"Vixen": Amazon's HVM+sidecar shim solution
"Comet": Citrix's PVH+toolstack shim solution
"Rudolph": Long-term solution combining both

In the Xen mythos then, Rudolph could be the child of Vixen and Comet. :-)

Cultural references (given that 'Vixen' and 'Comet' were both developed
in the run up to Christmas):

* https://www.teachervision.com/twas-night-christmas-full-text
*
http://www.metrolyrics.com/rudolph-the-red-nosed-reindeer-lyrics-christmas-carols.html

 -George

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

Re: [Xen-devel] [PATCH] x86/link: Don't merge .init.text and .init.data

[Andrew Cooper]

On 11/01/18 14:58, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 11, 2018 at 02:17:57PM +, Andrew Cooper wrote:
>> c/s 1308f0170c merged .init.text and .init.data, because EFI might properly
>> write-protect r/o sections.
>>
>> However, this change makes xen-syms unusable for disassembly analysis.  In
> s/this makes/that made/

Erm.  I'm not sure how to apply that regex, but I've changed to

"However, that change makes xen-syms unusable for disassembly analysis."

~Andrew

>> particular, searching for indirect branches as part of the SP2/Spectre
>> mitigation series.
>>
>> Revert the relevent bits of 1308f0170c and instead modify the EFI relocation
>> code to disable CR0.WP, which is how we deal with relocations in r/o mappings
>> elsewhere.
>>
>> Signed-off-by: Andrew Cooper 
> with that change above:
>
> Reviewed-by: Konrad Rzeszutek Wilk 
>> ---
>> CC: Jan Beulich 
>> ---
>>  xen/arch/x86/efi/efi-boot.h | 12 
>>  xen/arch/x86/efi/mkreloc.c  |  5 -
>>  xen/arch/x86/xen.lds.S  |  7 +++
>>  3 files changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
>> index d30f688..0b5f218 100644
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -47,8 +47,17 @@ extern const struct pe_base_relocs {
>>  
>>  static void __init efi_arch_relocate_image(unsigned long delta)
>>  {
>> +unsigned long cr0;
>>  const struct pe_base_relocs *base_relocs;
>>  
>> +/*
>> + * Conditionally disable CR0.WP in case there are relocations present in
>> + * read-only mappings.
>> + */
>> +cr0 = read_cr0();
>> +if ( cr0 & X86_CR0_WP )
>> +write_cr0(cr0 & ~X86_CR0_WP);
>> +
>>  for ( base_relocs = __base_relocs_start; base_relocs < 
>> __base_relocs_end; )
>>  {
>>  unsigned int i = 0, n;
>> @@ -96,6 +105,9 @@ static void __init efi_arch_relocate_image(unsigned long 
>> delta)
>>  }
>>  base_relocs = (const void *)(base_relocs->entries + i + (i & 1));
>>  }
>> +
>> +if ( cr0 & X86_CR0_WP )
>> +write_cr0(cr0);
>>  }
>>  
>>  extern const s32 __trampoline_rel_start[], __trampoline_rel_stop[];
>> diff --git a/xen/arch/x86/efi/mkreloc.c b/xen/arch/x86/efi/mkreloc.c
>> index 1aca796..509fd83 100644
>> --- a/xen/arch/x86/efi/mkreloc.c
>> +++ b/xen/arch/x86/efi/mkreloc.c
>> @@ -267,11 +267,6 @@ static void diff_sections(const unsigned char *ptr1, 
>> const unsigned char *ptr2,
>>  exit(3);
>>  }
>>  
>> -if ( !(sec->flags & COFF_SECTION_WRITEABLE) )
>> -fprintf(stderr,
>> -"Warning: relocation to r/o section %.8s:%08" 
>> PRIxFAST32 "\n",
>> -sec->name, i);
>> -
>>  printf("\t.word (%u << 12) | 0x%03" PRIxFAST32 "\n",
>> reloc, sec->rva + i - disp - rva);
>>  reloc_size += 2;
>> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
>> index d5e8821..6a7bbb8 100644
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -159,7 +159,7 @@ SECTIONS
>>__2M_init_start = .; /* Start of 2M superpages, mapped RWX (boot 
>> only). */
>>. = ALIGN(PAGE_SIZE); /* Init code and data */
>>__init_begin = .;
>> -  .init : {
>> +  .init.text : {
>> _sinittext = .;
>> *(.init.text)
>> /*
>> @@ -169,9 +169,8 @@ SECTIONS
>>  */
>> *(.altinstr_replacement)
>> _einittext = .;
>> -
>> -   . = ALIGN(SMP_CACHE_BYTES);
>> -
>> +  } :text
>> +  .init.data : {
>> *(.init.rodata)
>> *(.init.rodata.rel)
>> *(.init.rodata.str*)
>> -- 
>> 2.1.4
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xenproject.org
>> https://lists.xenproject.org/mailman/listinfo/xen-devel
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


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

Re: [Xen-devel] [PATCH] x86/link: Don't merge .init.text and .init.data

[Konrad Rzeszutek Wilk]

On Thu, Jan 11, 2018 at 02:17:57PM +, Andrew Cooper wrote:
> c/s 1308f0170c merged .init.text and .init.data, because EFI might properly
> write-protect r/o sections.
> 
> However, this change makes xen-syms unusable for disassembly analysis.  In

s/this makes/that made/
> particular, searching for indirect branches as part of the SP2/Spectre
> mitigation series.
> 
> Revert the relevent bits of 1308f0170c and instead modify the EFI relocation
> code to disable CR0.WP, which is how we deal with relocations in r/o mappings
> elsewhere.
> 
> Signed-off-by: Andrew Cooper 

with that change above:

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> CC: Jan Beulich 
> ---
>  xen/arch/x86/efi/efi-boot.h | 12 
>  xen/arch/x86/efi/mkreloc.c  |  5 -
>  xen/arch/x86/xen.lds.S  |  7 +++
>  3 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index d30f688..0b5f218 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -47,8 +47,17 @@ extern const struct pe_base_relocs {
>  
>  static void __init efi_arch_relocate_image(unsigned long delta)
>  {
> +unsigned long cr0;
>  const struct pe_base_relocs *base_relocs;
>  
> +/*
> + * Conditionally disable CR0.WP in case there are relocations present in
> + * read-only mappings.
> + */
> +cr0 = read_cr0();
> +if ( cr0 & X86_CR0_WP )
> +write_cr0(cr0 & ~X86_CR0_WP);
> +
>  for ( base_relocs = __base_relocs_start; base_relocs < 
> __base_relocs_end; )
>  {
>  unsigned int i = 0, n;
> @@ -96,6 +105,9 @@ static void __init efi_arch_relocate_image(unsigned long 
> delta)
>  }
>  base_relocs = (const void *)(base_relocs->entries + i + (i & 1));
>  }
> +
> +if ( cr0 & X86_CR0_WP )
> +write_cr0(cr0);
>  }
>  
>  extern const s32 __trampoline_rel_start[], __trampoline_rel_stop[];
> diff --git a/xen/arch/x86/efi/mkreloc.c b/xen/arch/x86/efi/mkreloc.c
> index 1aca796..509fd83 100644
> --- a/xen/arch/x86/efi/mkreloc.c
> +++ b/xen/arch/x86/efi/mkreloc.c
> @@ -267,11 +267,6 @@ static void diff_sections(const unsigned char *ptr1, 
> const unsigned char *ptr2,
>  exit(3);
>  }
>  
> -if ( !(sec->flags & COFF_SECTION_WRITEABLE) )
> -fprintf(stderr,
> -"Warning: relocation to r/o section %.8s:%08" PRIxFAST32 
> "\n",
> -sec->name, i);
> -
>  printf("\t.word (%u << 12) | 0x%03" PRIxFAST32 "\n",
> reloc, sec->rva + i - disp - rva);
>  reloc_size += 2;
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index d5e8821..6a7bbb8 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -159,7 +159,7 @@ SECTIONS
>__2M_init_start = .; /* Start of 2M superpages, mapped RWX (boot 
> only). */
>. = ALIGN(PAGE_SIZE); /* Init code and data */
>__init_begin = .;
> -  .init : {
> +  .init.text : {
> _sinittext = .;
> *(.init.text)
> /*
> @@ -169,9 +169,8 @@ SECTIONS
>  */
> *(.altinstr_replacement)
> _einittext = .;
> -
> -   . = ALIGN(SMP_CACHE_BYTES);
> -
> +  } :text
> +  .init.data : {
> *(.init.rodata)
> *(.init.rodata.rel)
> *(.init.rodata.str*)
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  21bd8b8b0836702284d283e2bbb104ed9e0d5865
baseline version:
 xen  b6c2c7f48ab8bd5566759cb404afd80fd0df2dfe

Last test of basis   117771  2018-01-10 11:01:42 Z1 days
Testing same since   117834  2018-01-11 13:01:32 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   b6c2c7f48a..21bd8b8b08  21bd8b8b0836702284d283e2bbb104ed9e0d5865 -> smoke

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

[Xen-devel] [PATCH] x86/link: Don't merge .init.text and .init.data

[Andrew Cooper]

c/s 1308f0170c merged .init.text and .init.data, because EFI might properly
write-protect r/o sections.

However, this change makes xen-syms unusable for disassembly analysis.  In
particular, searching for indirect branches as part of the SP2/Spectre
mitigation series.

Revert the relevent bits of 1308f0170c and instead modify the EFI relocation
code to disable CR0.WP, which is how we deal with relocations in r/o mappings
elsewhere.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/efi/efi-boot.h | 12 
 xen/arch/x86/efi/mkreloc.c  |  5 -
 xen/arch/x86/xen.lds.S  |  7 +++
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index d30f688..0b5f218 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -47,8 +47,17 @@ extern const struct pe_base_relocs {
 
 static void __init efi_arch_relocate_image(unsigned long delta)
 {
+unsigned long cr0;
 const struct pe_base_relocs *base_relocs;
 
+/*
+ * Conditionally disable CR0.WP in case there are relocations present in
+ * read-only mappings.
+ */
+cr0 = read_cr0();
+if ( cr0 & X86_CR0_WP )
+write_cr0(cr0 & ~X86_CR0_WP);
+
 for ( base_relocs = __base_relocs_start; base_relocs < __base_relocs_end; )
 {
 unsigned int i = 0, n;
@@ -96,6 +105,9 @@ static void __init efi_arch_relocate_image(unsigned long 
delta)
 }
 base_relocs = (const void *)(base_relocs->entries + i + (i & 1));
 }
+
+if ( cr0 & X86_CR0_WP )
+write_cr0(cr0);
 }
 
 extern const s32 __trampoline_rel_start[], __trampoline_rel_stop[];
diff --git a/xen/arch/x86/efi/mkreloc.c b/xen/arch/x86/efi/mkreloc.c
index 1aca796..509fd83 100644
--- a/xen/arch/x86/efi/mkreloc.c
+++ b/xen/arch/x86/efi/mkreloc.c
@@ -267,11 +267,6 @@ static void diff_sections(const unsigned char *ptr1, const 
unsigned char *ptr2,
 exit(3);
 }
 
-if ( !(sec->flags & COFF_SECTION_WRITEABLE) )
-fprintf(stderr,
-"Warning: relocation to r/o section %.8s:%08" PRIxFAST32 
"\n",
-sec->name, i);
-
 printf("\t.word (%u << 12) | 0x%03" PRIxFAST32 "\n",
reloc, sec->rva + i - disp - rva);
 reloc_size += 2;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d5e8821..6a7bbb8 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -159,7 +159,7 @@ SECTIONS
   __2M_init_start = .; /* Start of 2M superpages, mapped RWX (boot 
only). */
   . = ALIGN(PAGE_SIZE); /* Init code and data */
   __init_begin = .;
-  .init : {
+  .init.text : {
_sinittext = .;
*(.init.text)
/*
@@ -169,9 +169,8 @@ SECTIONS
 */
*(.altinstr_replacement)
_einittext = .;
-
-   . = ALIGN(SMP_CACHE_BYTES);
-
+  } :text
+  .init.data : {
*(.init.rodata)
*(.init.rodata.rel)
*(.init.rodata.str*)
-- 
2.1.4


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

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

[Hans van Kranenburg]

On 01/11/2018 10:15 AM, Lars Kurth wrote:
> I am wondering whether something like the attached table would make
> understanding the FAQ easier. Page 1 is clearly what is Xen specific and
> we definitely should cover.
> Page 2 in general covers Linux and guests. The first block is relatively
> straightforward.
> 
> The 2nd and 3rd block is based on information from Doug: as there are
> many gaps, I would be uneasy about publishing these somewhere prominent. 
> 
> Also
>> As this is really guest specific this information can't be provided by
>> Xen.
> which carries a risk that any analysis made by anyone might only apply
> to the context in which the analysis was done.
> 
> But the question keeps coming up, so making this clearer is maybe sensible.

Yes! This is a really good thing do do, since it's much more powerful
than trying to express the "multi-dimensional combinations" in  sentences.

When having this, the amount of text in the faq should just clearly
describe the categories, and cut out all the "X can but not if Y, but
also Y but not if Z" type sentences and then refer to the tables for the
end verdict for a specific users own situation.

  -- >8 --

The one thing I would want to point out again, which keeps to be a
non-obvious thing for users, is that in the short term with the pvshim
solution, a 64 bit PV guest in pvshim mode can still not be protected
against itself.

At  "Is a user space attack on the guest kernel possible (when running
in a Xen VM)"  there could be a [3] at 64 bit PV no, with the
explanation that while technically correct, this can again be
circumvented by exploiting the attack via Xen (see 'on other guest'
table) back to itself.

Or maybe adding an extra table "Is a user space attack via Xen back to
the guest itself possible (when running in a Xen VM)?" will help instead.

And to make it more complicated, a user would want to see how the tables
change when injecting the pvshim approach... For that, it might be
sufficient to add an extra row to all tables with "64 bit PV in pvhsim"
just below "64 bit PV".


Thanks,
Hans


[0] I also haven't see this info in any PR from AWS about PV guests?
Like, "hey, we protected ourselves and other customers against you, but
we can't do anything about your own business. Please stop using 64bit PV
instances for now if there's anything untrusted running inside."

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

Re: [Xen-devel] [RFC v2] xen/arm: Suspend to RAM Support in Xen for ARM

[Julien Grall]

Hi Mirela,

Thank you for the sending the design document. The general design looks 
good to me. I have some comments below, but they are more related to the 
implementation of CPU on/off in Xen.


On 22/12/17 17:41, Mirela Simonovic wrote:

[...]


+---
+Resuming Guests
+---
+
+Resume of the privileged guest (Dom0) is always following the Xen resume.
+
+An unprivileged guest shall resume once a device it owns triggers a wake-up
+interrupt, regardless of whether Xen was suspended when the wake-up interrupt
+was triggered. If Xen was suspended, it is assumed that Dom0 will be running
+before the DomU guest starts to resume. The synchronization mechanism to
+enforce the assumed condition is TBD.


Given that all but the non-boot CPU will be offlined. Does the wake-up 
interrupt always need to target the non-boot CPU?



+
+If the ARM's GIC was powered down after the ARM subsystem suspended, it is
+assumed that Xen needs to restore the GIC interface for a VM prior to handing
+over control to the guest. However, the guest should restore its own context
+upon entering the resume point, just like it would when running without Xen.
+
+===
+Implementation
+===


[...]


+CPU_OFF (physical CPUs)
+---
+The CPU_OFF function shall be implemented in
+* call_psci_cpu_off() in arch/arm/psci.c
+
+The implementation shall consist just of making the SMC call to EL3.
+
+This function needs to be called when Xen generic code disables a non-boot CPU.
+When a CPU is disabled it will loop forever in while loop (stop_cpu() function
+which is already implemented in xen/arch/arm/smpboot.c). Call to
+call_psci_cpu_off() shall be made before the CPU enters infinite loop.


While the code is present, we never offline physical CPU at the moment 
except when shutting down the place. So I am not fully convinced that 
stop_cpu() is properly implemented.


For instance, you likely need to migrate interrupts that was assigned to 
the physical CPU (either guest one or Xen one). Though Xen ones might be 
less a concern because I think they are always assigned to CPU0 at the 
moment.


Furthermore, PPI handlers are not removed. Same for any memory allocated 
(you may loose reference to it because percpu area for that CPU will get 
freed). I believe get into trouble when the CPU is back online?


I may have miss other bits, so I would highly recommend to go through 
the boot code and see what could go wrong.


[..]


+Resume Flow
+
+The resume entry point shall be implemented in
+* hyp_resume() in arch/arm/arm64/entry.S
+The very beginning of the resume procedure has to be implemented in assembly.
+It shall contain the following:
+* Enable the MMU so that the structure containing CPU context which was saved 
on
+suspend can be accessed
+* Restore CPU context (to match the values saved on suspend) and return into C
+* Set the system_state variable to SYS_STATE_resume
+* Restore GIC context
+* Resume timer
+* Enable interrupts
+* Enable non-boot CPUs by calling enable_nonboot_cpus()


You would have to be careful on re-enabling the non-CPU. start_secondary 
is implemented based on the assumption that it will only be called 
during Xen boot. Some of the code may be part of __init (see 
cpu_up_send_sgi) or should not be called as it is after boot (e.g 
check_local_cpu_errata).


Another I have in mind is the way VTCR_EL2 is set today (see 
setup_virt_paging). It is done at boot time, so if you online a CPU 
afterwards, VTCR_EL2 will not be set correctly.


I probably have missed other bits. I am happy to provide more insights here.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6.5 11/26] x86: Support indirect thunks from assembly code

[David Woodhouse]

On Thu, 2018-01-11 at 13:41 +, Andrew Cooper wrote:
> On 11/01/18 13:03, David Woodhouse wrote:
> > 
> > On Thu, 2018-01-04 at 00:15 +, Andrew Cooper wrote:
> > > 
> > > + * We've got no usable stack so can't use a RETPOLINE thunk, and 
> > > are
> > > + * further than +- 2G from the high mappings so couldn't use 
> > > JUMP_THUNK
> > > + * even if was a non-RETPOLINE thunk.  Futhermore, an LFENCE 
> > > isn't
> > > + * necesserily safe to use at this point.
>
> > I count three typos, pedantry about ± and GiB aside.
> > Late night? :)
> Just one of many...
> 
> I've found furthermore and necessarily.  Where is the 3rd?

* even if IT was a … 


> > > -asm volatile ( "call *%[stb]\n"
> > > +asm volatile ( "CALL_THUNK %[stb]\n"
> > If you make that %V[stb] then...
> > ... you don't need this.
> That's fine in principle, except it isn't compatible with most of the
> compilers we support.  To use, the %V has to be hidden behind a
> conditional macro, and I can't think of any remotely-clean way to do
> that.

In at least one incarnation I ended up with something like

#ifndef CONFIG_RETPOLINE
#define CALL_THUNK(reg) "call *%[" #reg "]"
#else
#define CALL_THUNK(reg) "CALL_THUNK %V[" #reg "]"
#endif

Or maybe I just insisted that it was called %[thunk_target] and my
CALL_THUNK C macro doesn't even take an argument. I forget. Late night…


smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6.5 11/26] x86: Support indirect thunks from assembly code

[Andrew Cooper]

On 11/01/18 13:03, David Woodhouse wrote:
> On Thu, 2018-01-04 at 00:15 +, Andrew Cooper wrote:
>> + * We've got no usable stack so can't use a RETPOLINE thunk, and are
>> + * further than +- 2G from the high mappings so couldn't use 
>> JUMP_THUNK
>> + * even if was a non-RETPOLINE thunk.  Futhermore, an LFENCE isn't
>> + * necesserily safe to use at this point.
> I count three typos, pedantry about ± and GiB aside.
> Late night? :)

Just one of many...

I've found furthermore and necessarily.  Where is the 3rd?

>
>> --- a/xen/arch/x86/extable.c
>> +++ b/xen/arch/x86/extable.c
>> @@ -158,7 +158,7 @@ static int __init stub_selftest(void)
>>  memcpy(ptr, tests[i].opc, ARRAY_SIZE(tests[i].opc));
>>  unmap_domain_page(ptr);
>>  
>> -asm volatile ( "call *%[stb]\n"
>> +asm volatile ( "CALL_THUNK %[stb]\n"
> If you make that %V[stb] then...
>
>> +.if CONFIG_INDIRECT_THUNK == 1
>> +
>> +$done = 0
>> +.irp reg, rax, rbx, rcx, rdx, rsi, rdi, rbp, r8, r9, r10, r11, r12, 
>> r13, r14, r15
>> +.ifeqs "\arg", "%\reg"
>> +\insn __x86.indirect_thunk.\reg
>> +$done = 1
>> +   .exitm
>> +.endif
>> +.endr
>> +.if $done != 1
>> +.error "Bad register arg \arg"
>> +.endif
>> +
> ... you don't need this.

That's fine in principle, except it isn't compatible with most of the
compilers we support.  To use, the %V has to be hidden behind a
conditional macro, and I can't think of any remotely-clean way to do that.

~Andrew

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

Re: [Xen-devel] [PATCH v6.5 11/26] x86: Support indirect thunks from assembly code

[David Woodhouse]

On Thu, 2018-01-04 at 00:15 +, Andrew Cooper wrote:
> + * We've got no usable stack so can't use a RETPOLINE thunk, and are
> + * further than +- 2G from the high mappings so couldn't use 
> JUMP_THUNK
> + * even if was a non-RETPOLINE thunk.  Futhermore, an LFENCE isn't
> + * necesserily safe to use at this point.

I count three typos, pedantry about ± and GiB aside.
Late night? :)

> --- a/xen/arch/x86/extable.c
> +++ b/xen/arch/x86/extable.c
> @@ -158,7 +158,7 @@ static int __init stub_selftest(void)
>  memcpy(ptr, tests[i].opc, ARRAY_SIZE(tests[i].opc));
>  unmap_domain_page(ptr);
>  
> -asm volatile ( "call *%[stb]\n"
> +asm volatile ( "CALL_THUNK %[stb]\n"

If you make that %V[stb] then...

> +.if CONFIG_INDIRECT_THUNK == 1
> +
> +$done = 0
> +.irp reg, rax, rbx, rcx, rdx, rsi, rdi, rbp, r8, r9, r10, r11, r12, 
> r13, r14, r15
> +.ifeqs "\arg", "%\reg"
> +\insn __x86.indirect_thunk.\reg
> +$done = 1
> +   .exitm
> +.endif
> +.endr
> +.if $done != 1
> +.error "Bad register arg \arg"
> +.endif
> +

... you don't need this.


smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117732
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117732
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117732
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117732
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 117732
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117732
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu3cee4db661ab9c0fce7937b3bbfa188a1845f31f
baseline version:
 qemuu4124ea4f5bd367ca6412fb2dfe7ac4d80e1504d9

Last test of basis   117732  2018-01-08 18:52:04 Z2 days
Testing same since   117764  2018-01-10 04:15:47 Z1 days1 attempts


People who touched revisions under test:
  Aneesh Kumar K.V 
  Eric Blake 
  Greg Kurz 
  Laurent Vivier 
  Marc-André Lureau 
  Murilo Opsfelder Araujo 
  Peter Maydell 
  Philippe Mathieu-Daudé 

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

Re: [Xen-devel] [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

[Ard Biesheuvel]

On 9 January 2018 at 14:22, Daniel Kiper  wrote:
> Hi,
>
> Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
> may not even know that it runs on secure boot enabled platform.
>

Hi Daniel,

I must say, I am not too thrilled with the approach you have chosen
here. #including .c files in other .c files, and using #defines to
override C functions or other stub functionality is rather fragile. In
particular, it means we have to start caring about not breaking
Xen/x86 code when making modifications to the EFI stub, and that code
is already difficult enough to maintain, given that it is shared
between ARM, arm64 and x86, and runs either from the decompressor or
the kernel proper (arm64) but in the context of the UEFI firmware.
None of the stub code currently runs in ordinary kernel context.

So please, could you try to find another way to do this?

Thanks,
Ard.


>
>  arch/x86/xen/Makefile  |4 +++-
>  arch/x86/xen/efi.c |   14 +
>  drivers/firmware/efi/libstub/secureboot-core.c |   77 
> +
>  drivers/firmware/efi/libstub/secureboot.c  |   66 
> +--
>  4 files changed, 99 insertions(+), 62 deletions(-)
>
> Daniel Kiper (4):
>   efi/stub: Extract efi_get_secureboot() to separate file
>   x86/xen/efi: Initialize boot_params.secure_boot in xen_efi_init()
>   efi: Tweak efi_get_secureboot() and its data section assignment
>   efi: Rename efi_get_secureboot() to __efi_get_secureboot() and make it 
> static
>

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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[George Dunlap]

On 01/11/2018 12:01 PM, Roger Pau Monné wrote:
> On Thu, Jan 11, 2018 at 11:03:05AM +, George Dunlap wrote:
>> On 01/11/2018 10:58 AM, Roger Pau Monné wrote:
>>> On Tue, Jan 09, 2018 at 05:08:15PM +, George Dunlap wrote:
 Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
 the PVH mode from 4.10 to 4.9 and 4.8.  This will first allow people
 able to run PVH kernels to switch their PV guests directly to PVH
 guests; and second, eventually enable the backport of patches which
 will enable transparent changing of PV guests into PVH guests.

 All of the hypervisor support seems to have existed already in 4.8, so
 the only backports involve toolstack patches.
>>>
>>> Thanks for looking into this.
>>>
>>> My general opinion given those are toolstack only patches is that if
>>> it works it's fine.
>>>
 I've put up two trees for a first-cut backport of the PVH
 functionality, to 4.9 and 4.8 here:

 git://xenbits.xen.org/people/gdunlap/xen.git

 Branches out/pvh-backport/4.8/v1 and out/pvh-backport/4.9/v1

 Below are the patches backported from 4.10 to 4.9 (23 patches total):

 Roger Pau Monnelibxl: add is_default checkers for string and timer_mode
 types
 Roger Pau Monnelibxl: introduce a way to mark fields as deprecated in
 the idl
>>>
>>> This or one of the related patches is going to add fields in
>>> domain_build_info, which will break the ABI. Is this expected/OK?
>>
>> Oh right -- this needs to be ported to add the fields at the end.
>>
>> Going back to the 4.10 series, it looks like there are also some "shim
>> host" patches having to do with enabling CPUID faulting in the guest.
>> Do we need to backport those to 4.9 and 4.8 as well?  ISTR they may rely
>> on some hypervisor infrastructure which would then also need to be
>> backported.
> 
> IIRC those are for AMD hardware?
> 
> Adding Andy who worked on those patches.

From what I recall there were two parts:
1. Allow AMD to even enable CPUID faulting if available
2. Enable CPUID faulting for shim guests (both Intel and AMD)

The point of #1 was to enable #2 on AMD hardware.

 -George

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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[Roger Pau Monné]

On Thu, Jan 11, 2018 at 11:03:05AM +, George Dunlap wrote:
> On 01/11/2018 10:58 AM, Roger Pau Monné wrote:
> > On Tue, Jan 09, 2018 at 05:08:15PM +, George Dunlap wrote:
> >> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
> >> the PVH mode from 4.10 to 4.9 and 4.8.  This will first allow people
> >> able to run PVH kernels to switch their PV guests directly to PVH
> >> guests; and second, eventually enable the backport of patches which
> >> will enable transparent changing of PV guests into PVH guests.
> >>
> >> All of the hypervisor support seems to have existed already in 4.8, so
> >> the only backports involve toolstack patches.
> > 
> > Thanks for looking into this.
> > 
> > My general opinion given those are toolstack only patches is that if
> > it works it's fine.
> > 
> >> I've put up two trees for a first-cut backport of the PVH
> >> functionality, to 4.9 and 4.8 here:
> >>
> >> git://xenbits.xen.org/people/gdunlap/xen.git
> >>
> >> Branches out/pvh-backport/4.8/v1 and out/pvh-backport/4.9/v1
> >>
> >> Below are the patches backported from 4.10 to 4.9 (23 patches total):
> >>
> >> Roger Pau Monnelibxl: add is_default checkers for string and timer_mode
> >> types
> >> Roger Pau Monnelibxl: introduce a way to mark fields as deprecated in
> >> the idl
> > 
> > This or one of the related patches is going to add fields in
> > domain_build_info, which will break the ABI. Is this expected/OK?
> 
> Oh right -- this needs to be ported to add the fields at the end.
> 
> Going back to the 4.10 series, it looks like there are also some "shim
> host" patches having to do with enabling CPUID faulting in the guest.
> Do we need to backport those to 4.9 and 4.8 as well?  ISTR they may rely
> on some hypervisor infrastructure which would then also need to be
> backported.

IIRC those are for AMD hardware?

Adding Andy who worked on those patches.

Roger.

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

Re: [Xen-devel] Consensus in Parallel Universe Responses to Spectre/Meltdown

[George Dunlap]

On 01/11/2018 03:38 AM, Rich Persaud wrote:
> Across the computer industry, it is clear that a small subset of specialists 
> have known about this issue for some time:  developers who worked on 
> candidate fixes ahead of the public announcement, experts who warned about 
> microarchitecture risks years ago, and any adversaries who acted on their 
> warnings.  Some people had advance information & time to consider candidate 
> solutions, most [1] of the world did not.
> 
> As a customer of $HW_vendor / Xen / $OS_vendor / $APP_vendor, the last thing 
> I want to hear is that world-class specialists who have had weeks/months to 
> evaluate candidate fixes have been unable to reach agreement and propose to 
> delegate the decision TO CUSTOMERS (?!)  That would be customers with only 
> days of exposure to the CVE details, who still have to keep their regular 
> business running, while trying to understand a complex security issue that 
> eluded experts for decades.

I hope I'm not saying too much to say this: Those who knew about this
were not working according to the normal XenProject Security Team rules;
in fact the XenProject Security Team as such was only officially told on
3 January (the same day the issue went public).  Those who knew were
working under NDA and sharing of information was severely restricted,
*even on people in the same team at the same organization*.

In the week that we've been able to openly discuss it, we've already
come up with a large number of much better ideas than the people "in the
know" were able to come up with crippled by a lack of ability to
communicate.

I'm sure I speak for a number of people when I say that we're just as
unhappy with that situation as you are.

 -George

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

[Xen-devel] [distros-debian-wheezy test] 74248: trouble: blocked/broken

[Platform Team regression test user]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-wheezy-netboot-pvgrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 build-armhf   4 host-install(4)  broken like 73880
 build-armhf-pvops 4 host-install(4)  broken like 73880
 build-armhf   5 capture-logs broken like 73880
 build-armhf-pvops 5 capture-logs broken like 73880
 build-i3864 host-install(4)  broken like 73880
 build-i386-pvops  4 host-install(4)  broken like 73880
 build-amd64-pvops 4 host-install(4)  broken like 73880
 build-amd64   4 host-install(4)  broken like 73880

baseline version:
 flight   73880

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked 
 test-amd64-i386-i386-wheezy-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-wheezy-netboot-pygrub  blocked 
 test-amd64-amd64-i386-wheezy-netboot-pygrub  blocked 



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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[George Dunlap]

On 01/11/2018 10:58 AM, Roger Pau Monné wrote:
> On Tue, Jan 09, 2018 at 05:08:15PM +, George Dunlap wrote:
>> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
>> the PVH mode from 4.10 to 4.9 and 4.8.  This will first allow people
>> able to run PVH kernels to switch their PV guests directly to PVH
>> guests; and second, eventually enable the backport of patches which
>> will enable transparent changing of PV guests into PVH guests.
>>
>> All of the hypervisor support seems to have existed already in 4.8, so
>> the only backports involve toolstack patches.
> 
> Thanks for looking into this.
> 
> My general opinion given those are toolstack only patches is that if
> it works it's fine.
> 
>> I've put up two trees for a first-cut backport of the PVH
>> functionality, to 4.9 and 4.8 here:
>>
>> git://xenbits.xen.org/people/gdunlap/xen.git
>>
>> Branches out/pvh-backport/4.8/v1 and out/pvh-backport/4.9/v1
>>
>> Below are the patches backported from 4.10 to 4.9 (23 patches total):
>>
>> Roger Pau Monne  libxl: add is_default checkers for string and timer_mode
>> types
>> Roger Pau Monne  libxl: introduce a way to mark fields as deprecated in
>> the idl
> 
> This or one of the related patches is going to add fields in
> domain_build_info, which will break the ABI. Is this expected/OK?

Oh right -- this needs to be ported to add the fields at the end.

Going back to the 4.10 series, it looks like there are also some "shim
host" patches having to do with enabling CPUID faulting in the guest.
Do we need to backport those to 4.9 and 4.8 as well?  ISTR they may rely
on some hypervisor infrastructure which would then also need to be
backported.

But PVH shim guests seemed to boot fine under 4.9 / 4.8 without those
patches, so I'm not sure how critical they are.

 -George

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

Re: [Xen-devel] PVH backports to 4.9 and 4.8

[Roger Pau Monné]

On Tue, Jan 09, 2018 at 05:08:15PM +, George Dunlap wrote:
> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
> the PVH mode from 4.10 to 4.9 and 4.8.  This will first allow people
> able to run PVH kernels to switch their PV guests directly to PVH
> guests; and second, eventually enable the backport of patches which
> will enable transparent changing of PV guests into PVH guests.
> 
> All of the hypervisor support seems to have existed already in 4.8, so
> the only backports involve toolstack patches.

Thanks for looking into this.

My general opinion given those are toolstack only patches is that if
it works it's fine.

> I've put up two trees for a first-cut backport of the PVH
> functionality, to 4.9 and 4.8 here:
> 
> git://xenbits.xen.org/people/gdunlap/xen.git
> 
> Branches out/pvh-backport/4.8/v1 and out/pvh-backport/4.9/v1
> 
> Below are the patches backported from 4.10 to 4.9 (23 patches total):
> 
> Roger Pau Monne   libxl: add is_default checkers for string and timer_mode
> types
> Roger Pau Monne   libxl: introduce a way to mark fields as deprecated in
> the idl

This or one of the related patches is going to add fields in
domain_build_info, which will break the ABI. Is this expected/OK?

Roger.

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

Re: [Xen-devel] [PATCH] MAINTAINERS: update my entries to new email address.

[George Dunlap]

On 01/10/2018 06:20 PM, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

Good to have you back!

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

Re: [Xen-devel] sidecar (hvm shim) creation script

[George Dunlap]

On 01/10/2018 11:08 PM, Doug Goldstein wrote:
> On 1/10/18 9:39 AM, Ian Jackson wrote:
>> Ian Jackson writes ("Re: sidecar (hvm shim) creation script"):
>>> Here is the converter script where I just got my guest to boot with
>>> the Vixen shim, as built and provided by Wei.
>>
>> And here is one which handles the guest console correctly.  Vixen
>> sends the L2 guest console to the emulated serial, along with the
>> shim's own output.
>>
>>
> 
> So, not that I don't like executing another language interpreter from
> another language interpreter (insert yodawg meme here), but how would
> you feel about a Python version? The system I'm currently dealing with
> needs to import this code as a Python module so I figured I'd slap a
> main() and some argparse on it and it should be good.

From what I understand, Ian's decision tree looked like this:

1. For parsing xl.cfg, the options are "use python" or "write a brand
new parser for the python-like xl.cfg syntax".  That's pretty much a
no-brainer.

2. Given that the aim of the shim is to hand to people running systems
as old as Xen 3.4, the script needs to run identically, without issue,
on a wide range of systems.  In his estimation, his ability to write
such "lowest-common-denominator" perl was much higher than his ability
to write "lowest-common-denominator" python.

If anyone stepped to write and maintain a version of the script that can
run as well under Python 2.2 as under 2.7, he'd probably be happy to
avoid using three different languages.

 -George

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

Re: [Xen-devel] [PATCH] vixen: port of shadow PV console's page for L2 DomU

[Wei Liu]

On Wed, Jan 10, 2018 at 09:15:52AM -0800, Sarah Newman wrote:
> The current version of vixen handles console output from the guest
> but not console input to the guest. This adds guest input as in
> 
> 0d50a85f x86/pv-shim: shadow PV console's page for L2 DomU,
> 
> but with read_smb moved up in guest_tx.
> 
> Signed-off-by: Sarah Newman 

Ian Jackson wrote a sidecar loading script to redirect console to QEMU
serial. Have you checked that out?

Wei.

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

Re: [Xen-devel] [PATCH RFC v1 23/74] x86/entry: Probe for Xen early during boot

[Wei Liu]

On Thu, Jan 11, 2018 at 12:55:48AM -0700, Jan Beulich wrote:
> >>> On 10.01.18 at 18:45,  wrote:
> > On Fri, Jan 05, 2018 at 06:40:29AM -0700, Jan Beulich wrote:
> >> >>> On 04.01.18 at 14:05,  wrote:
> >> > --- a/xen/include/asm-x86/guest.h
> >> > +++ b/xen/include/asm-x86/guest.h
> >> > @@ -20,6 +20,7 @@
> >> >  #define __X86_GUEST_H__
> >> >  
> >> >  #include 
> >> > +#include 
> >> >  
> >> >  #endif /* __X86_GUEST_H__ */
> >> 
> >> I'm increasingly curious to understand what this header's purpose
> >> is meant to be. It looks as if you mean source files to only ever
> >> include this one, but why? Rather than exposing everything at
> > 
> > Yes there will be file that only includes this header -- the PV in HVM
> > work doesn't need the PVH bits.
> 
> Either I'm not understanding your reply or you didn't understand
> mine: I was trying to understand the purpose of guest.h if it
> consists of only #include-s. In such a case, why can't the sources
> needing certain bits simply include the headers they need, instead
> of this container one?

I see. Yes this header can go away. This is going to be a nice-to-have
in my book, i.e. I will do it later.

Wei.

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

[Xen-devel] [PATCH 0/2] Fix a couple of crashes in netfront

[Ross Lagerwall]

Here are a couple of patches to fix two crashes in netfront.

Ross Lagerwall (2):
  xen/grant-table: Use put_page instead of free_page
  xen-netfront: Fix race between device setup and open

 drivers/net/xen-netfront.c | 46 --
 drivers/xen/grant-table.c  |  4 ++--
 2 files changed, 26 insertions(+), 24 deletions(-)

-- 
2.9.5


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

[Xen-devel] [PATCH 1/2] xen/grant-table: Use put_page instead of free_page

[Ross Lagerwall]

The page given to gnttab_end_foreign_access() to free could be a
compound page so use put_page() instead of free_page() since it can
handle both compound and single pages correctly.

This bug was discovered when migrating a Xen VM with several VIFs and
CONFIG_DEBUG_VM enabled. It hits a BUG usually after fewer than 10
iterations. All netfront devices disconnect from the backend during a
suspend/resume and this will call gnttab_end_foreign_access() if a
netfront queue has an outstanding skb. The mismatch between calling
get_page() and free_page() on a compound page causes a reference
counting error which is detected when DEBUG_VM is enabled.

Signed-off-by: Ross Lagerwall 
---
 drivers/xen/grant-table.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index f45114f..27be107 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -382,7 +382,7 @@ static void gnttab_handle_deferred(struct timer_list 
*unused)
if (entry->page) {
pr_debug("freeing g.e. %#x (pfn %#lx)\n",
 entry->ref, page_to_pfn(entry->page));
-   __free_page(entry->page);
+   put_page(entry->page);
} else
pr_info("freeing g.e. %#x\n", entry->ref);
kfree(entry);
@@ -438,7 +438,7 @@ void gnttab_end_foreign_access(grant_ref_t ref, int 
readonly,
if (gnttab_end_foreign_access_ref(ref, readonly)) {
put_free_entry(ref);
if (page != 0)
-   free_page(page);
+   put_page(virt_to_page(page));
} else
gnttab_add_deferred(ref, readonly,
page ? virt_to_page(page) : NULL);
-- 
2.9.5


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

[Xen-devel] [PATCH 2/2] xen-netfront: Fix race between device setup and open

[Ross Lagerwall]

When a netfront device is set up it registers a netdev fairly early on,
before it has set up the queues and is actually usable. A userspace tool
like NetworkManager will immediately try to open it and access its state
as soon as it appears. The bug can be reproduced by hotplugging VIFs
until the VM runs out of grant refs. It registers the netdev but fails
to set up any queues (since there are no more grant refs). In the
meantime, NetworkManager opens the device and the kernel crashes trying
to access the queues (of which there are none).

Fix this in two ways:
* For initial setup, register the netdev much later, after the queues
are setup. This avoids the race entirely.
* During a suspend/resume cycle, the frontend reconnects to the backend
and the queues are recreated. It is possible (though highly unlikely) to
race with something opening the device and accessing the queues after
they have been destroyed but before they have been recreated. Extend the
region covered by the rtnl semaphore to protect against this race. There
is a possibility that we fail to recreate the queues so check for this
in the open function.

Signed-off-by: Ross Lagerwall 
---
 drivers/net/xen-netfront.c | 46 --
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 9bd7dde..8328d39 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -351,6 +351,9 @@ static int xennet_open(struct net_device *dev)
unsigned int i = 0;
struct netfront_queue *queue = NULL;
 
+   if (!np->queues)
+   return -ENODEV;
+
for (i = 0; i < num_queues; ++i) {
queue = >queues[i];
napi_enable(>napi);
@@ -1358,18 +1361,8 @@ static int netfront_probe(struct xenbus_device *dev,
 #ifdef CONFIG_SYSFS
info->netdev->sysfs_groups[0] = _dev_group;
 #endif
-   err = register_netdev(info->netdev);
-   if (err) {
-   pr_warn("%s: register_netdev err=%d\n", __func__, err);
-   goto fail;
-   }
 
return 0;
-
- fail:
-   xennet_free_netdev(netdev);
-   dev_set_drvdata(>dev, NULL);
-   return err;
 }
 
 static void xennet_end_access(int ref, void *page)
@@ -1737,8 +1730,6 @@ static void xennet_destroy_queues(struct netfront_info 
*info)
 {
unsigned int i;
 
-   rtnl_lock();
-
for (i = 0; i < info->netdev->real_num_tx_queues; i++) {
struct netfront_queue *queue = >queues[i];
 
@@ -1747,8 +1738,6 @@ static void xennet_destroy_queues(struct netfront_info 
*info)
netif_napi_del(>napi);
}
 
-   rtnl_unlock();
-
kfree(info->queues);
info->queues = NULL;
 }
@@ -1764,8 +1753,6 @@ static int xennet_create_queues(struct netfront_info 
*info,
if (!info->queues)
return -ENOMEM;
 
-   rtnl_lock();
-
for (i = 0; i < *num_queues; i++) {
struct netfront_queue *queue = >queues[i];
 
@@ -1774,7 +1761,7 @@ static int xennet_create_queues(struct netfront_info 
*info,
 
ret = xennet_init_queue(queue);
if (ret < 0) {
-   dev_warn(>netdev->dev,
+   dev_warn(>xbdev->dev,
 "only created %d queues\n", i);
*num_queues = i;
break;
@@ -1788,10 +1775,8 @@ static int xennet_create_queues(struct netfront_info 
*info,
 
netif_set_real_num_tx_queues(info->netdev, *num_queues);
 
-   rtnl_unlock();
-
if (*num_queues == 0) {
-   dev_err(>netdev->dev, "no queues\n");
+   dev_err(>xbdev->dev, "no queues\n");
return -EINVAL;
}
return 0;
@@ -1828,6 +1813,7 @@ static int talk_to_netback(struct xenbus_device *dev,
goto out;
}
 
+   rtnl_lock();
if (info->queues)
xennet_destroy_queues(info);
 
@@ -1838,6 +1824,7 @@ static int talk_to_netback(struct xenbus_device *dev,
info->queues = NULL;
goto out;
}
+   rtnl_unlock();
 
/* Create shared ring, alloc event channel -- for each queue */
for (i = 0; i < num_queues; ++i) {
@@ -1934,8 +1921,10 @@ static int talk_to_netback(struct xenbus_device *dev,
xenbus_transaction_end(xbt, 1);
  destroy_ring:
xennet_disconnect_backend(info);
+   rtnl_lock();
xennet_destroy_queues(info);
  out:
+   rtnl_unlock();
device_unregister(>dev);
return err;
 }
@@ -1965,6 +1954,15 @@ static int xennet_connect(struct net_device *dev)
netdev_update_features(dev);
rtnl_unlock();
 
+   if (dev->reg_state == NETREG_UNINITIALIZED) {
+   err = register_netdev(dev);
+   if (err) {
+   pr_warn("%s: register_netdev err=%d\n", __func__, 

[Xen-devel] [seabios test] 117784: regressions - FAIL

[osstest service owner]

flight 117784 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117784/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  844b86464a5cbfffb62b87808632018ca250d867
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   68 days
Failing since115733  2017-11-10 17:19:59 Z   61 days   67 attempts
Testing same since   117014  2017-12-08 19:11:23 Z   33 days   22 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Paul Menzel 
  Stefan Berger 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit 844b86464a5cbfffb62b87808632018ca250d867
Author: Paul Menzel 
Date:   Mon Oct 2 08:13:13 2017 +0200

docs/Download: Use more secure HTTPS URLs where possible

Signed-off-by: Paul Menzel 

commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

I am wondering whether something like the attached table would make 
understanding the FAQ easier. Page 1 is clearly what is Xen specific and we 
definitely should cover.
Page 2 in general covers Linux and guests. The first block is relatively 
straightforward.

The 2nd and 3rd block is based on information from Doug: as there are many 
gaps, I would be uneasy about publishing these somewhere prominent. 

Also
> As this is really guest specific this information can't be provided by
> Xen.
which carries a risk that any analysis made by anyone might only apply to the 
context in which the analysis was done.

But the question keeps coming up, so making this clearer is maybe sensible.

Best Regards
Lars

> On 10 Jan 2018, at 06:03, Juergen Gross  wrote:
> 
> On 10/01/18 04:58, Peter wrote:
>> On 2018-01-09 15:04, Stefano Stabellini wrote:
>>> On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:
 On Fri, Jan 05, 2018 at 07:05:56PM +, Andrew Cooper wrote:
> On 05/01/18 18:16, Rich Persaud wrote:
>>> On Jan 5, 2018, at 06:35, Lars Kurth >> > wrote:
>>> Linux’s KPTI series is designed to address SP3 only.  For Xen
 guests,
>>> only 64-bit PV guests are affected by SP3. A KPTI-like approach was
>>> explored initially, but required significant ABI changes.  
 
 Is some partial KPTI-like approach feasible? Like unmapping memory owned
 by other guests, but keeping Xen areas mapped? This will still allow
 leaking Xen memory, but there are very few secrets there (vCPUs state,
 anything else?), so overall impact will be much lower.
>>> 
>>> +1
>>> 
>> 
>> I believe
>> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
>> is clear re VMs attacking/accessing the host/dom0/hypervisor and the
>> mitigations for that.
>> 
>> However the page seems ambiguous about whether 64 bit VMs running as
>> PVHv2 with host provided kernels are protected or not (from each VM's
>> own processes).
> 
> PVHv2 is using exactly the same runtime environment as HVM seen from the
> hypervisor. So a guest running as PVHv2 needs a PTI like approach like
> HVM in its kernel.
> 
>> Can the page be updated to be more explicit and perhaps describe how the
>> VM kernel or how the PVHv2 virtualization provides that protection.  And
>> ideally how that could be checked from the VM itself.  e.g. grep pti
>> /proc/cpuinfo?
> 
> As this is really guest specific this information can't be provided by
> Xen.
> 
>> e.g. the page says: "Guest kernels running in 64-bit PV mode are not
>> directly vulnerable to attack using SP3, because 64-bit PV guests
>> already run in a KPTI-like mode." but it does not mention PVHv2 for
>> that.  Is it protected under PVHv2?  Does it depend on the kernel?  Is
>> so what is the patchset/option/mechanism that protects the VM from its
>> own processes?
> 
> This question should have been answered above already.
> 
> 
> Juergen
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org 
> https://lists.xenproject.org/mailman/listinfo/xen-devel 
> 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

[Lars Kurth]

And this time with attachment

Matrix.pdf
Description: Adobe PDF document
On 11 Jan 2018, at 09:15, Lars Kurth  wrote:I am wondering whether something like the attached table would make understanding the FAQ easier. Page 1 is clearly what is Xen specific and we definitely should cover.Page 2 in general covers Linux and guests. The first block is relatively straightforward.The 2nd and 3rd block is based on information from Doug: as there are many gaps, I would be uneasy about publishing these somewhere prominent. AlsoAs this is really guest specific this information can't be provided byXen.which carries a risk that any analysis made by anyone might only apply to the context in which the analysis was done.But the question keeps coming up, so making this clearer is maybe sensible.Best RegardsLarsOn 10 Jan 2018, at 06:03, Juergen Gross  wrote:On 10/01/18 04:58, Peter wrote:On 2018-01-09 15:04, Stefano Stabellini wrote:On Sun, 7 Jan 2018, Marek Marczykowski-Górecki wrote:On Fri, Jan 05, 2018 at 07:05:56PM +, Andrew Cooper wrote:On 05/01/18 18:16, Rich Persaud wrote:On Jan 5, 2018, at 06:35, Lars Kurth > wrote:Linux’s KPTI series is designed to address SP3 only.  For Xenguests,only 64-bit PV guests are affected by SP3. A KPTI-like approach wasexplored initially, but required significant ABI changes.  Is some partial KPTI-like approach feasible? Like unmapping memory ownedby other guests, but keeping Xen areas mapped? This will still allowleaking Xen memory, but there are very few secrets there (vCPUs state,anything else?), so overall impact will be much lower.+1I believehttps://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/is clear re VMs attacking/accessing the host/dom0/hypervisor and themitigations for that.However the page seems ambiguous about whether 64 bit VMs running asPVHv2 with host provided kernels are protected or not (from each VM'sown processes).PVHv2 is using exactly the same runtime environment as HVM seen from thehypervisor. So a guest running as PVHv2 needs a PTI like approach likeHVM in its kernel.Can the page be updated to be more explicit and perhaps describe how theVM kernel or how the PVHv2 virtualization provides that protection.  Andideally how that could be checked from the VM itself.  e.g. grep pti/proc/cpuinfo?As this is really guest specific this information can't be provided byXen.e.g. the page says: "Guest kernels running in 64-bit PV mode are notdirectly vulnerable to attack using SP3, because 64-bit PV guestsalready run in a KPTI-like mode." but it does not mention PVHv2 forthat.  Is it protected under PVHv2?  Does it depend on the kernel?  Isso what is the patchset/option/mechanism that protects the VM from itsown processes?This question should have been answered above already.Juergen___Xen-devel mailing listXen-devel@lists.xenproject.orghttps://lists.xenproject.org/mailman/listinfo/xen-devel___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [qemu-upstream-unstable test] 117763: FAIL

[osstest service owner]

flight 117763 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117763/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  broken  in 117731
 test-amd64-amd64-amd64-pvgrub broken in 117731

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt  4 host-install(4) broken in 117731 pass in 117763
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 117731

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-amd64-pvgrub  4 host-install(4)  broken in 117731 like 115739
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116133
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116133
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116133
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116133
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116133
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu2b033e396f4fa0981bae1213cdacd15775655a97
baseline version:
 qemuub79708a8ed1b3d18bee67baeaf33b3fa529493e2

Last test of basis   116133  2017-11-13 06:47:58 Z   59 days
Testing same since   117731  2018-01-08 18:12:06 Z2 days2 attempts


People who touched revisions under test:
  "Daniel P. Berrange" 
  Aaron Lindsay 
  Alberto Garcia 
  Aleksandr Bezzubikov 

Re: [Xen-devel] Radical proposal v2: Publish Amazon's verison now, Citrix's version soon

[Jan Beulich]

>>> On 10.01.18 at 18:25,  wrote:
> On Wed, 10 Jan 2018, George Dunlap wrote:
>> * Executive summary
>> 
>> - We've agreed on a "convergence" point for PV shim functionality that
>>   covers as many users as possible:
>>  - 'HVM' functionality: boots in HVM mode, has support for Xen 3.4
>>event channels, , booted via 'sidecar'
>>  - 'PVH' functionality: boots in PVH mode, booted via toolstack
>>changes
>> 
>> - "Vixen" (the Amazon shim) and PVH shim (mostly developed by Citrix)
>>   each cover some users and not others; neither one (yet) covers all
>>   users
> 
> Sorry for being punctilious, but neither one can cover all users: there
> are users without VT-x on their platform, and both approaches require
> VT-x.

For the record, yesterday I've decided to make an attempt to
create a very simplistic patch to deal with the issue in the
hypervisor, ignoring (almost) all performance considerations
(not all, because I didn't want to go the "disable caching" route).
I've dealt with some of the to-be-expected early bugs, but I'm
now debugging a host hang (note: not a triple fault apparently,
as the box doesn't reboot, yet triple faults is what I would have
expected to occur if anything is wrong here or missing).

I know that's late, and I have to admit that I don't understand
myself why I didn't consider doing such earlier on, but the
much increased pressure to get something like the shim out,
which
- doesn't address all cases
- requires changes to how VMs are being created (which likely will
  be a problem for various customers)
- later will want those changes undone
plus the pretty obvious impossibility to backport something like
Andrew's (not yet complete) series to baselines as old as 3.2
made it seem to me that some (measurable!) performance
overhead can't be all that bad in the given situation.

Jan


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