[Xen-devel] [qemu-mainline test] 94618: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  16 guest-start.2 fail REGR. vs. 94612

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94612
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94612

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu65603e2fc18b48e6e55a3dd693669413141694ec
baseline version:
 qemuu22b31af26ff31ef97a9d482fb5e336d699ae33f3

Last test of basis94612  2016-05-20 13:16:10 Z0 days
Testing same since94618  2016-05-20 20:52:51 Z0 days1 attempts


People who touched revisions under test:
  Paolo Bonzini 
  Peter Maydell 

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

[Xen-devel] [PATCH] xen/events: don't migrate disabled IRQs

[Munehisa Kamata]

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") introduced
a crash below. This can be triggered after being resumed from suspend
 (e.g. live migration) if there are disabled IRQs with
IRQD_SETAFFINITY_PENDING set.

kernel BUG at kernel/irq/migration.c:31!
...
CPU: 0 PID: 9 Comm: migration/0 Tainted: GE   4.4.8 #1
Hardware name: Xen HVM domU, BIOS 4.2.amazon 04/04/2016
task: 88020620 ti: 880206208000 task.ti: 880206208000
RIP: 0010:[]  [] 
irq_move_masked_irq+0xd9/0xf0
RSP: 0018:88020620bc88  EFLAGS: 00010046
...
Call Trace:
 [] eoi_pirq+0xa7/0xd0
 [] __startup_pirq+0xd7/0x140
 [] xen_irq_resume+0x2c7/0x330
 [] xen_suspend+0x86/0x140
 [] multi_cpu_stop+0xb3/0xe0
 [] ? cpu_stop_queue_work+0x80/0x80
 [] cpu_stopper_thread+0x7a/0x110
 [] ? finish_task_switch+0x72/0x1d0
 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [] smpboot_thread_fn+0x10f/0x170
 [] ? sort_range+0x30/0x30
 [] kthread+0xc9/0xe0
 [] ? kthread_park+0x60/0x60
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_park+0x60/0x60

The pending state may last until being suspended, because some IRQs may
show no activities after their affinity settings have been changed.

This change don't let ACK and EOI handlers of xen-pirq and xen-dyn chips
try to migrate disabled IRQs to avoid the BUG in that situation.

Fixes: ff1e22e7a638 ("xen/events: Mask a moving irq")
Reported-and-tested-by: Guilherme Wuensch Manika 
To: Boris Ostrovsky 
To: David Vrabel 
Cc: xen-de...@lists.xenproject.org
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: Matt Wilson 
Signed-off-by: Munehisa Kamata 
---
 drivers/xen/events/events_base.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index cb7138c..be8410f 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -487,7 +487,8 @@ static void eoi_pirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
 
-   if (unlikely(irqd_is_setaffinity_pending(data))) {
+   if (unlikely(irqd_is_setaffinity_pending(data) &&
+   !irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
 
clear_evtchn(evtchn);
@@ -1370,7 +1371,8 @@ static void ack_dynirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
 
-   if (unlikely(irqd_is_setaffinity_pending(data))) {
+   if (unlikely(irqd_is_setaffinity_pending(data) &&
+   !irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
 
clear_evtchn(evtchn);
-- 
2.7.4


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

[Xen-devel] [qemu-upstream-4.3-testing test] 94621: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  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-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  104 days
Testing same since93977  2016-05-10 11:09:16 Z   10 days   32 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] e820_host default value and libxl (not xl)

[Marek Marczykowski-Górecki]

Hi,

According to xl.cfg(5) " This option defaults to true (1) if any PCI
passthrough devices are configured and false (0) otherwise."
And indeed this behaviour is implemented in xl. But not in libxl, which
means other libxl based toolstacks (libvirt) will not take advantage of
this directly.

What would be the best approach here? Duplicate that behaviour in
libvirt (currently libvirt knows nothing about this option), or move
that default handling to libxl? I think the later makes more sense, but
maybe there is some reason against it?

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


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

[Xen-devel] [qemu-upstream-4.3-testing test] 94619: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  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-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  104 days
Testing same since93977  2016-05-10 11:09:16 Z   10 days   31 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] PAT-related crash booting Linux 4.4 + Xen 4.5 on VMware ESXi

[Ed Swierk]

I've encountered two problems booting a Linux 4.4 dom0 on recent
stable xen 4.5 on VMware ESXi 5.5.0.

One has the same "ata_piix: probe of :00:07.1 failed with error
-22" symptom discussed some time ago, and prevents the kernel from
seeing any of the virtual IDE drives exposed by VMware.  This problem
is fixed by applying Stefano's patch
(https://lkml.org/lkml/2016/4/20/345).

Another problem occurs very early during boot:

(XEN) Xen version 4.5.4-pre ( 4.5.4~pre-1skyport2) (eswi...@skyportsystems.com) 
(gcc (Debian 5.2.1-19.1skyport1) 5.2.1 20150930) debug=n Thu May 19 12:06:20 
PDT 2016
(XEN) Bootloader: SYSLINUX 4.05 20140113
(XEN) Command line: xen console=com1,vga com1=115200 no-bootscrub 
dom0_mem=2048M,max:2048M ignore_loglevel
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009f800 (usable)
(XEN)  0009f800 - 000a (reserved)
(XEN)  000dc000 - 0010 (reserved)
(XEN)  0010 - bfef (usable)
(XEN)  bfef - bfeff000 (ACPI data)
(XEN)  bfeff000 - bff0 (ACPI NVS)
(XEN)  bff0 - c000 (usable)
(XEN)  f000 - f800 (reserved)
(XEN)  fec0 - fec1 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  fffe - 0001 (reserved)
(XEN)  0001 - 0001c000 (usable)
(XEN) ACPI: RSDP 000F6B80, 0024 (r2 PTLTD )
(XEN) ACPI: XSDT BFEF0F70, 0054 (r1 INTEL  440BX 604 VMW   1324272)
(XEN) ACPI: FACP BFEFEE73, 00F4 (r4 INTEL  440BX 604 PTL F4240)
(XEN) ACPI: DSDT BFEF1252, DC21 (r1 PTLTD  Custom604 MSFT  301)
(XEN) ACPI: FACS BFEFFFC0, 0040
(XEN) ACPI: BOOT BFEF122A, 0028 (r1 PTLTD  $SBFTBL$  604  LTP1)
(XEN) ACPI: APIC BFEF1194, 0096 (r1 PTLTDAPIC604  LTP0)
(XEN) ACPI: MCFG BFEF1158, 003C (r1 PTLTD  $PCITBL$  604  LTP1)
(XEN) ACPI: SRAT BFEF1028, 0130 (r2 VMWARE MEMPLUG   604 VMW 1)
(XEN) ACPI: WAET BFEF1000, 0028 (r1 VMWARE VMW WAET  604 VMW 1)
(XEN) System RAM: 6143MB (6291004kB)
(XEN) Domain heap initialised
(XEN) Processor #0 7:15 APIC version 21
(XEN) Processor #2 7:15 APIC version 21
(XEN) Processor #4 7:15 APIC version 21
(XEN) Processor #6 7:15 APIC version 21
(XEN) Processor #8 7:15 APIC version 21
(XEN) Processor #10 7:15 APIC version 21
(XEN) IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-23
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Not enabling x2APIC: depends on iommu_supports_eim.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2299.474 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) Platform timer is 3.579MHz ACPI PM Timer
(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) not detected
(XEN) Brought up 6 CPUs
(XEN) Dom0 has maximum 600 PIRQs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x300
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0001b000->0001b400 (504002 pages to be 
allocated)
(XEN)  Init. ramdisk: 0001bf0c2000->0001be00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 8100->8300
(XEN)  Init. ramdisk: ->
(XEN)  Phys-Mach map: 0080->00800040
(XEN)  Start info:8300->830004b4
(XEN)  Page tables:   83001000->8301e000
(XEN)  Boot stack:8301e000->8301f000
(XEN)  TOTAL: 8000->8340
(XEN)  ENTRY ADDRESS: 8200d1f0
(XEN) Dom0 has maximum 6 VCPUs
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to 
Xen)
(XEN) Freed 308kB init memory.
mapping kernel into physical memory
(XEN) traps.c:459:d0v0 Unhandled invalid opcode fault/trap [#6] on VCPU 0 
[ec=]
(XEN) domain_crash_sync called from entry.S: fault at 82d0802286c3 
create_bounce_frame+0x12b/0x13a
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) [ Xen-4.5.4-pre  x86_64  debug=n  Not tainted ]
(XEN) CPU:0
(XEN) RIP:e033:[]
(XEN) RFLAGS: 0206   EM: 1   

[Xen-devel] [PATCH v7 11/15] qapi: Change Netdev into a flat union

[Eric Blake]

From: Kővágó, Zoltán 

Except qapi-schema.json, this patch was generated by:

find . -name .git -prune -o -type f \! -name '*~' -print0 | \
  xargs -0 sed -i \
-e 's/NetClientOptionsKind/NetClientDriver/g' \
-e 's/NET_CLIENT_OPTIONS_KIND_/NET_CLIENT_DRIVER_/g' \
-e 's/netdev->opts/netdev/g'

Signed-off-by: Kővágó, Zoltán 
Message-Id: 
<01a527fbf1a5de880091f98cf011616a78ad.1441627176.git.dirty.ice...@gmail.com>

Additional changes:
Rebase the patch on top of an earlier change from netdev->kind to
netdev->type, so that tweak is no longer needed here.  Rebase to
latest master which enhanced multiqueue.

Rework so that NetdevLegacy doesn't pollute QMP command but is instead
copied piecewise into the new Netdev, which means that NetClientOptions
must still remain in qapi. Since legacy previously always rejected
'hubport', we can now make that explicit by having the two unions be
slightly different; but that means we must manually map between the
two structures.

Signed-off-by: Eric Blake 

---
v7: rebase to latest master
v6: rebase to latest master
---
 qapi-schema.json |  47 ++
 include/net/net.h|   4 +-
 hw/arm/musicpal.c|   2 +-
 hw/core/qdev-properties-system.c |   2 +-
 hw/net/allwinner_emac.c  |   2 +-
 hw/net/cadence_gem.c |   2 +-
 hw/net/dp8393x.c |   2 +-
 hw/net/e1000.c   |   2 +-
 hw/net/eepro100.c|   2 +-
 hw/net/etraxfs_eth.c |   2 +-
 hw/net/fsl_etsec/etsec.c |   2 +-
 hw/net/imx_fec.c |   2 +-
 hw/net/lan9118.c |   2 +-
 hw/net/lance.c   |   2 +-
 hw/net/mcf_fec.c |   2 +-
 hw/net/milkymist-minimac2.c  |   2 +-
 hw/net/mipsnet.c |   2 +-
 hw/net/ne2000-isa.c  |   2 +-
 hw/net/ne2000.c  |   2 +-
 hw/net/opencores_eth.c   |   2 +-
 hw/net/pcnet-pci.c   |   2 +-
 hw/net/rocker/rocker_fp.c|   2 +-
 hw/net/rtl8139.c |   2 +-
 hw/net/smc91c111.c   |   2 +-
 hw/net/spapr_llan.c  |   2 +-
 hw/net/stellaris_enet.c  |   2 +-
 hw/net/vhost_net.c   |  18 +++---
 hw/net/virtio-net.c  |  10 +--
 hw/net/vmxnet3.c |   2 +-
 hw/net/xen_nic.c |   2 +-
 hw/net/xgmac.c   |   2 +-
 hw/net/xilinx_axienet.c  |   2 +-
 hw/net/xilinx_ethlite.c  |   2 +-
 hw/usb/dev-network.c |   2 +-
 monitor.c|  14 ++---
 net/dump.c   |   6 +-
 net/hub.c|  22 +++
 net/l2tpv3.c |   6 +-
 net/net.c| 133 +--
 net/netmap.c |   4 +-
 net/slirp.c  |   6 +-
 net/socket.c |   8 +--
 net/tap-win32.c  |   6 +-
 net/tap.c|  24 +++
 net/vde.c|   6 +-
 net/vhost-user.c |  18 +++---
 46 files changed, 225 insertions(+), 167 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 54634c4..4fee44b 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2744,16 +2744,32 @@
 '*queues':'int' } }

 ##
-# @NetClientOptions
+# @NetClientDriver
 #
-# A discriminated record of network device traits.
+# Available netdev drivers.
+#
+# Since 2.7
+##
+{ 'enum': 'NetClientDriver',
+  'data': [ 'none', 'nic', 'user', 'tap', 'l2tpv3', 'socket', 'vde', 'dump',
+'bridge', 'hubport', 'netmap', 'vhost-user' ] }
+
+##
+# @Netdev
+#
+# Captures the configuration of a network device.
+#
+# @id: identifier for monitor commands.
+#
+# @type: Specify the driver used for interpreting remaining arguments.
 #
 # Since 1.2
 #
 # 'l2tpv3' - since 2.1
-#
 ##
-{ 'union': 'NetClientOptions',
+{ 'union': 'Netdev',
+  'base': { 'id': 'str', 'type': 'NetClientDriver' },
+  'discriminator': 'type',
   'data': {
 'none': 'NetdevNoneOptions',
 'nic':  'NetLegacyNicOptions',
@@ -2791,20 +2807,25 @@
 'opts':  'NetClientOptions' } }

 ##
-# @Netdev
+# @NetClientOptions
 #
-# Captures the configuration of a network device.
-#
-# @id: identifier for monitor commands.
-#
-# @opts: device type specific properties
+# Like Netdev, but for use only by the legacy command line options
 #
 # Since 1.2
 ##
-{ 'struct': 'Netdev',
+{ 'union': 'NetClientOptions',
   'data': {
-'id':   'str',
-'opts': 'NetClientOptions' } }
+'none': 'NetdevNoneOptions',
+'nic':  'NetLegacyNicOptions',
+'user': 'NetdevUserOptions',
+'tap':  'NetdevTapOptions',
+'l2tpv3':   'NetdevL2TPv3Options',
+'socket':   'NetdevSocketOptions',
+'vde':  'NetdevVdeOptions',
+'dump': 'NetdevDumpOptions',
+'bridge':  

Re: [Xen-devel] [PATCH net-next] xen-netback: only deinitialized hash if it was initialized

[David Miller]

From: Paul Durrant 
Date: Wed, 18 May 2016 15:55:42 +0100

> A domain with a frontend that does not implement a control ring has been
> seen to cause a crash during domain save. This was apparently because
> the call to xenvif_deinit_hash() in xenvif_disconnect_ctrl() is made
> regardless of whether a control ring was connected, and hence
> xenvif_hash_init() was called.
> 
> This patch brings the call to xenvif_deinit_hash() in
> xenvif_disconnect_ctrl() inside the if clause that checks whether the
> control ring event channel was connected. This is sufficient to ensure
> it is only called if xenvif_init_hash() was called previously.
> 
> Signed-off-by: Paul Durrant 
> Reported-by: Boris Ostrovsky 
> Tested-by: Boris Ostrovsky 

Applied, thanks.

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

Re: [Xen-devel] [PATCH] xen/events: don't migrate disabled IRQs

[Boris Ostrovsky]

On 05/20/2016 05:22 PM, Munehisa Kamata wrote:
> Commit ff1e22e7a638 ("xen/events: Mask a moving irq") introduced
> a crash below. This can be triggered after being resumed from suspend
>  (e.g. live migration) if there are disabled IRQs with
> IRQD_SETAFFINITY_PENDING set.

A patch just like this has been submitted recently
(http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00956.html)
and should go in soon.

Thanks.
-boris




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

[Xen-devel] [qemu-upstream-4.3-testing test] 94613: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  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-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  104 days
Testing same since93977  2016-05-10 11:09:16 Z   10 days   30 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94586
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94586

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu22b31af26ff31ef97a9d482fb5e336d699ae33f3
baseline version:
 qemuu6bd8ab6889f45a42d69a3a65a4d6e7fc2453c84c

Last test of basis94586  2016-05-19 21:15:40 Z0 days
Testing same since94612  2016-05-20 13:16:10 Z0 days1 attempts


People who touched revisions under test:
  Paolo Bonzini 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass   

Re: [Xen-devel] [RFC v2 4/7] asm/sections: add a generic push_section_tbl()

[Luis R. Rodriguez]

On Fri, Feb 26, 2016 at 03:56:04PM +0100, Heiko Carstens wrote:
> On Sun, Feb 21, 2016 at 06:55:05PM -0800, H. Peter Anvin wrote:
> > On 02/19/16 13:06, Luis R. Rodriguez wrote:
> > >>
> > >> I think the \n\t is unnecessary.
> > > 
> > > Super! I wonder if we we can just use this on s390 as well without it 
> > > pooping?
> > > I ask as this would set a precedent.
> > > 
> > 
> > Ask Heike, but I think just ; or \n ought be be fine.  I do not know of
> > *any* case where \t at the end of a string would ever be necessary, and
> > it would *always* be possible to replace it with a space in a pinch.
> 
> \n should be fine on s390.

Great, thanks, I'll move forward with just \n in v3.

  Luis

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf edddb945519cf71c048e82a2f009db3e1e7f7d74
baseline version:
 ovmf 66e5133ce0a8940a99451842a804dc5a37b4b687

Last test of basis94600  2016-05-20 07:43:34 Z0 days
Testing same since94614  2016-05-20 17:42:54 Z0 days1 attempts


People who touched revisions under test:
  Maurice Ma 

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



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

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

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

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


Pushing revision :

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94580

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 94580
 build-i386-rumpuserxen6 xen-buildfail   like 94580
 build-amd64-rumpuserxen   6 xen-buildfail   like 94580
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94580
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94580
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94580
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94580
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94580

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

version targeted for testing:
 xen  a396c2549e079ab2f644aab8b2e7f47a8d0e3937
baseline version:
 xen  bab2bd8e222de9e596699ac080ea985af828c4c4

Last test of basis94580  2016-05-19 13:08:47 Z1 days
Testing same since94589  2016-05-20 02:45:09 Z0 days2 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v2 for-4.7] docs/xsplice: Fix syntax when compiling to pdf with pandoc

[Konrad Rzeszutek Wilk]

On Fri, May 20, 2016 at 07:09:42PM +0100, Andrew Cooper wrote:
> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n in
> the signature checking paragraph.
> 
>   /usr/bin/pandoc --number-sections --toc --standalone misc/xsplice.markdown
> --output pdf/misc/xsplice.pdf
>   ! Undefined control sequence.
>   l.1085 appended\textasciitilde{}\n
> 
> Surround the string in backticks to make it verbatim text.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Konrad Rzeszutek Wilk 

Reviewed-by: Konrad Rzeszutek Wilk 

Thanks!
> 
> v2: Don't strip whitespace.  (That issue can be fixed later)
> ---
>  docs/misc/xsplice.markdown | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
> index 4a98be1..05c1a55 100644
> --- a/docs/misc/xsplice.markdown
> +++ b/docs/misc/xsplice.markdown
> @@ -1007,7 +1007,7 @@ expecting such that it can properly do signature 
> verification.
>  
>  The signature is based on the all of the payloads continuously laid out
>  in memory. The signature is to be appended at the end of the ELF payload
> -prefixed with the string '~Module signature appended~\n', followed by
> +prefixed with the string `'~Module signature appended~\n'`, followed by
>  an signature header then followed by the signature, key identifier, and 
> signers
>  name.
>  
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH v2 for-4.7] docs/xsplice: Fix syntax when compiling to pdf with pandoc

[Andrew Cooper]

Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n in
the signature checking paragraph.

  /usr/bin/pandoc --number-sections --toc --standalone misc/xsplice.markdown
--output pdf/misc/xsplice.pdf
  ! Undefined control sequence.
  l.1085 appended\textasciitilde{}\n

Surround the string in backticks to make it verbatim text.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Konrad Rzeszutek Wilk 

v2: Don't strip whitespace.  (That issue can be fixed later)
---
 docs/misc/xsplice.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index 4a98be1..05c1a55 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -1007,7 +1007,7 @@ expecting such that it can properly do signature 
verification.
 
 The signature is based on the all of the payloads continuously laid out
 in memory. The signature is to be appended at the end of the ELF payload
-prefixed with the string '~Module signature appended~\n', followed by
+prefixed with the string `'~Module signature appended~\n'`, followed by
 an signature header then followed by the signature, key identifier, and signers
 name.
 
-- 
2.1.4


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

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Wei Liu]

On Fri, May 20, 2016 at 07:04:20PM +0100, Wei Liu wrote:
> On Fri, May 20, 2016 at 06:58:40PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [RFC] libxl hotplug / unplug emulated devices"):
> > > On Fri, May 20, 2016 at 05:38:44PM +0100, Ian Jackson wrote:
> > > > Maybe the fix should be that xl network-attach should default hotplug
> > > > nics to pv only.
> > > 
> > > Here is a patch to do this. :-)
> > 
> > Acked-by: Ian Jackson 
> > 
> > Although I have a style nit:
> > 
> > >  if (libxl__device_model_version_running(gc, domid) ==
> > > -LIBXL_DEVICE_MODEL_VERSION_NONE)
> > > +LIBXL_DEVICE_MODEL_VERSION_NONE || hotplug)
> > >  nic->nictype = LIBXL_NIC_TYPE_VIF;
> > 
> > This is rather odd formatting.  It makes it look like
> >if (version = (NONE || hotplug)) { ...
> > 
> 
> Perhaps you mean
> 
>  if ((version == NONE) || hotplug)
> 
> ?

Never mind. I misread.

I will fix that.

> 
> > You might prefer to put another line break, before the || perhaps.
> > 
> > Ian.

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

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Ian Jackson]

Wei Liu writes ("Re: [RFC] libxl hotplug / unplug emulated devices"):
> On Fri, May 20, 2016 at 06:58:40PM +0100, Ian Jackson wrote:
> > Although I have a style nit:
> > 
> > >  if (libxl__device_model_version_running(gc, domid) ==
> > > -LIBXL_DEVICE_MODEL_VERSION_NONE)
> > > +LIBXL_DEVICE_MODEL_VERSION_NONE || hotplug)
> > >  nic->nictype = LIBXL_NIC_TYPE_VIF;
> > 
> > This is rather odd formatting.  It makes it look like
> >if (version = (NONE || hotplug)) { ...
> 
> Perhaps you mean
>  if ((version == NONE) || hotplug)
> ?

That's what you meant, and the compiler knows you meant (because of
the relative precedence of == and ||).

My point is that the formatting is misleading.

Ian.

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

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Wei Liu]

On Fri, May 20, 2016 at 06:58:40PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [RFC] libxl hotplug / unplug emulated devices"):
> > On Fri, May 20, 2016 at 05:38:44PM +0100, Ian Jackson wrote:
> > > Maybe the fix should be that xl network-attach should default hotplug
> > > nics to pv only.
> > 
> > Here is a patch to do this. :-)
> 
> Acked-by: Ian Jackson 
> 
> Although I have a style nit:
> 
> >  if (libxl__device_model_version_running(gc, domid) ==
> > -LIBXL_DEVICE_MODEL_VERSION_NONE)
> > +LIBXL_DEVICE_MODEL_VERSION_NONE || hotplug)
> >  nic->nictype = LIBXL_NIC_TYPE_VIF;
> 
> This is rather odd formatting.  It makes it look like
>if (version = (NONE || hotplug)) { ...
> 

Perhaps you mean

 if ((version == NONE) || hotplug)

?

> You might prefer to put another line break, before the || perhaps.
> 
> Ian.

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

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Ian Jackson]

Wei Liu writes ("Re: [RFC] libxl hotplug / unplug emulated devices"):
> On Fri, May 20, 2016 at 05:38:44PM +0100, Ian Jackson wrote:
> > Maybe the fix should be that xl network-attach should default hotplug
> > nics to pv only.
> 
> Here is a patch to do this. :-)

Acked-by: Ian Jackson 

Although I have a style nit:

>  if (libxl__device_model_version_running(gc, domid) ==
> -LIBXL_DEVICE_MODEL_VERSION_NONE)
> +LIBXL_DEVICE_MODEL_VERSION_NONE || hotplug)
>  nic->nictype = LIBXL_NIC_TYPE_VIF;

This is rather odd formatting.  It makes it look like
   if (version = (NONE || hotplug)) { ...

You might prefer to put another line break, before the || perhaps.

Ian.

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

Re: [Xen-devel] Question about the best practice to install two versions of Xen toolstack on the same machine

[Meng Xu]

Hi Jan,

On Fri, May 20, 2016 at 6:20 AM, Jan Beulich  wrote:
 On 19.05.16 at 20:40,  wrote:
>> Does anyone try to install two version of Xen toolstack on the same machine?
>> Is there any documentation about the best practice to install two
>> versions of Xen onto the same machine?
>
> Or, as an alternative to Olaf's reply, don't install the tools at all, but
> instead run everything right out of the build trees. That requires some
> script wrappers to get things like the library search path set up
> correctly, but with that in place it has been working fine for me for
> years.
>

Thank you so much for your suggestions!  I tried to add the library
and bins in xen/dist/install into the PATH and LD_LIBRARY_PATH, but
failed to have the system work properly.

I'm wondering if it's convenient for you, would you mind sharing your
script wrapper? I can learn from it and customize it for my machine.

Once I have it set up successfully, I can write a xen wiki to describe
how to do it.

Thank you again for your time and help!

Best Regards,

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

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

Re: [Xen-devel] Question about the best practice to install two versions of Xen toolstack on the same machine

[Meng Xu]

On Fri, May 20, 2016 at 4:52 AM, Olaf Hering  wrote:
> On Thu, May 19, Meng Xu wrote:
>
>> Does anyone try to install two version of Xen toolstack on the same machine?
>
> I do that. See the INSTALL file which has examples at the end:
>
> * To build a private copy of tools and xen:
> configure --prefix=/odd/path --sysconfdir=/odd/path/etc --enable-rpath
> make
> sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi
>
> Note that pygrub has no concept of "rpath". Use pvgrub2 instead.

Thank you so much, Olaf!
I will try it out. :-)

Best Regards,

Meng

-- 
Best Regards,

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

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

Re: [Xen-devel] [PATCH net-next] xen-netback: correct length checks on hash copy_ops

[David Miller]

From: Paul Durrant 
Date: Wed, 18 May 2016 08:53:01 +0100

> The length checks on the grant table copy_ops for setting hash key and
> hash mapping are checking the local 'len' value which is correct in
> the case of the former but not the latter. This was picked up by
> static analysis checks.
> 
> This patch replaces checks of 'len' with 'copy_op.len' in both cases
> to correct the incorrect check, keep the two checks consistent, and to
> make it clear what the checks are for.
> 
> Signed-off-by: Paul Durrant 
> Reported-by: Dan Carpenter 

Applied.

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

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Wei Liu]

On Fri, May 20, 2016 at 05:38:44PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[RFC] libxl hotplug / unplug emulated devices"):
> > Recently I got a report on xen-users@ about xl network-attach not
> > working for HVM guest.
> > 
> > I try to use
> >   xl network-attach jessie-hvm 'bridge=xenbr0'
> > and vif-bridge script complains that it can't add vifXX-emu to bridge.
> > 
> > The underlying issue is that the vif spec provided defaults to
> > emulated nic, but libxl only populates a pv nic but doesn't call out
> > via QMP to QEMU to populate one. Note that this issue not only affects
> > nic device but essentially all device types.
> 
> Is it really sensible to offer emulated nic hotplug ?  That'd be
> presented to the guest as pci hotplug, I guess ?
> 
> > I also experimented with block device:
> >   xl block-attach jessie-hvm 'phy:/dev/DATA/disk,hdb,w'
> > and it succeed, only pv disk is populated though.
> 
> That's what I would have expected.
> 
> Maybe the fix should be that xl network-attach should default hotplug
> nics to pv only.
> 

Here is a patch to do this. :-)

---8<---
From 0a0a0ac76f825983bb13d70e46a59cabb05ed77b Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Fri, 20 May 2016 18:16:05 +0100
Subject: [PATCH for-4.7] libxl: nic type defaults to vif in hotplug for hvm 
guest

We don't support plugging in emulated nic to a HVM guest.

The "update_json" flag is only set when doing hotplug, so use that as an
indicator in libxl__device_nic_add. The new hotplug flag to _setdefault
function should be false in all other locations.

This then requires saving nic type in JSON file, because we don't want
the receiving end to recalculate the nic type.

Signed-off-by: Wei Liu 
---
 tools/libxl/libxl.c  | 6 +++---
 tools/libxl/libxl_create.c   | 3 ++-
 tools/libxl/libxl_dm.c   | 3 ++-
 tools/libxl/libxl_internal.h | 3 ++-
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c39d745..62e9294 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3319,7 +3319,7 @@ out:
 
/**/
 
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
- uint32_t domid)
+ uint32_t domid, bool hotplug)
 {
 int rc;
 
@@ -3358,7 +3358,7 @@ int libxl__device_nic_setdefault(libxl__gc *gc, 
libxl_device_nic *nic,
 case LIBXL_DOMAIN_TYPE_HVM:
 if (!nic->nictype) {
 if (libxl__device_model_version_running(gc, domid) ==
-LIBXL_DEVICE_MODEL_VERSION_NONE)
+LIBXL_DEVICE_MODEL_VERSION_NONE || hotplug)
 nic->nictype = LIBXL_NIC_TYPE_VIF;
 else
 nic->nictype = LIBXL_NIC_TYPE_VIF_IOEMU;
@@ -3411,7 +3411,7 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t 
domid,
 libxl_device_nic_init(_saved);
 libxl_device_nic_copy(CTX, _saved, nic);
 
-rc = libxl__device_nic_setdefault(gc, nic, domid);
+rc = libxl__device_nic_setdefault(gc, nic, domid, aodev->update_json);
 if (rc) goto out;
 
 front = flexarray_make(gc, 16, 1);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 5000bd0..7e57215 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -946,7 +946,8 @@ static void initiate_domain_create(libxl__egc *egc,
  * called libxl_device_nic_add when domcreate_launch_dm gets called,
  * but qemu needs the nic information to be complete.
  */
-ret = libxl__device_nic_setdefault(gc, _config->nics[i], domid);
+ret = libxl__device_nic_setdefault(gc, _config->nics[i], domid,
+   false);
 if (ret) {
 LOG(ERROR, "Unable to set nic defaults for nic %d", i);
 goto error_out;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 4aff323a..65dceee 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1809,7 +1809,8 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
  * called libxl_device_nic_add at this point, but qemu needs
  * the nic information to be complete.
  */
-ret = libxl__device_nic_setdefault(gc, _config->nics[i], dm_domid);
+ret = libxl__device_nic_setdefault(gc, _config->nics[i], dm_domid,
+   false);
 if (ret)
 goto out;
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c791418..fac5751 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1217,7 +1217,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
   libxl_device_disk *disk,
   uint32_t domid);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, 

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Meng Xu]

On Fri, May 20, 2016 at 1:23 PM, Andrii Anisov
 wrote:
> Meng,
>
>> From my previous experience, the board may not be supported by Xen even 
>> though
>> the processor it uses has virtualization extension.. :-(
>
> I still insist it depends on SoC ;)

Ah-ha, I totally agree about this...

>
> If you are saying about this case:
>
>> Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
>> It uses Cortex A15 processor...
>> However, I tried the Arndale Octo board two years ago
>> (http://www.arndaleboard.org/wiki/index.php/Main_Page).
>
> Cortex A15 just implements ARMv7 architecture more efficiently then
> A9, while VE are still optional. You should read chip specs more
> careful.
> You remember I wrote:
>>> The most outstanding example is a chip with Cortex A15 MPCore, but
>>> without any VE support at all.
> It was another Samsung's SoC in my experience.

Yes. I just started looking at the ARM now and tried to evaluate the
RTDS scheduler on ARM. That's why I'm very interested in the use case
here and tried to run it. :-)

I will keep an eye on your patches. ;-)

Thanks and Best Regards,

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

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Andrii Anisov]

Meng,

> From my previous experience, the board may not be supported by Xen even though
> the processor it uses has virtualization extension.. :-(

I still insist it depends on SoC ;)

If you are saying about this case:

> Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
> It uses Cortex A15 processor...
> However, I tried the Arndale Octo board two years ago
> (http://www.arndaleboard.org/wiki/index.php/Main_Page).

Cortex A15 just implements ARMv7 architecture more efficiently then
A9, while VE are still optional. You should read chip specs more
careful.
You remember I wrote:
>> The most outstanding example is a chip with Cortex A15 MPCore, but
>> without any VE support at all.
It was another Samsung's SoC in my experience.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Andrii Anisov]

> If I understand correctly, all the initiators but the GPU will be used by
> DOM0 which is already direct mapped. The only issue here is allocating
> memory enough memory below 4GB.
It's not about memory allocation for domain. It is rather about SDRAM
mapping on the bus. J6 has first 2GB for iomems, starting from
0x8000 2GB of SDRAM mapping plus more SDRAM mapped over 4GB line.
Changing rambase_pfn is painful for J6 release kernel so we just make
it configurable by
- [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file.
- [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn'
setting for kernel Dom0


> By default Xen will try to allocate as much RAM as possible below 4GB for
> DOM0.

Also we are providing both domains with a piece of non-dma memory for
applications with a patch [PATCH RFC 16/18] xen: Add dom0_mem_high
option & over 4GB memory allocation for Dom0.

> If you are concerned about the amount allocated, you could pre-allocate them 
> before
> hand (such as via the DT as propose in [1]).
I've quickly checked the proposal, looks interesting we would evaluate.

> For the GPU, on another reply you said it was protected by an IPMMU. I
> remembered a series from globallogic to virtualize it in Xen [2]. Can you
> details why this option would not fit in your use case?
> [2]
> http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg03359.html
We have a successor of that patch series. But the GPU MMU is still
32-bit and is not able to address SDRAM mapped over 4GB on the bus.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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

Re: [Xen-devel] [PATCH] docs: Fix device_model_user description of its default value

[Wei Liu]

On Fri, May 20, 2016 at 05:48:37PM +0100, Anthony PERARD wrote:
> On Fri, May 20, 2016 at 05:34:10PM +0100, Ian Jackson wrote:
> > Anthony PERARD writes ("[PATCH] docs: Fix device_model_user description of 
> > its default value"):
> > > docs/misc/qemu-deprivilege.txt and libxl suggest that "xen-qemuuser" is
> > > the default prefix, reflect that in the man.
> > > 
> > > Also add some emphasis.
> > 
> > I'm going to make a perhaps-controversial suggestion:
> > 
> > This feature should be deprecated for 4.7.  Specifically,
> >  - the warning about running qemu as root should go away
> >  - the docs should mention that running qemu not as root
> >may well break things
> 
> Yes. The doc bearly mention an issue with migration and pci passthrough.
> I could boot a guest, but shutdown did not work.
> 

So I guess we should just remove relevant manpage sections? The code can
be left as-is so that we can develop this thing further.

Wei.

> > Right now, the privsep is not finished and I think trying to run qemu
> > as non-root won't (usually) actually work.
> > 
> > Ian.
> 
> -- 
> Anthony PERARD

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

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Wei Liu]

On Fri, May 20, 2016 at 05:45:53PM +0100, Andrew Cooper wrote:
> On 20/05/16 17:42, Wei Liu wrote:
> > On Fri, May 20, 2016 at 05:38:44PM +0100, Ian Jackson wrote:
> >> Wei Liu writes ("[RFC] libxl hotplug / unplug emulated devices"):
> >>> Recently I got a report on xen-users@ about xl network-attach not
> >>> working for HVM guest.
> >>>
> >>> I try to use
> >>>   xl network-attach jessie-hvm 'bridge=xenbr0'
> >>> and vif-bridge script complains that it can't add vifXX-emu to bridge.
> >>>
> >>> The underlying issue is that the vif spec provided defaults to
> >>> emulated nic, but libxl only populates a pv nic but doesn't call out
> >>> via QMP to QEMU to populate one. Note that this issue not only affects
> >>> nic device but essentially all device types.
> >> Is it really sensible to offer emulated nic hotplug ?  That'd be
> >> presented to the guest as pci hotplug, I guess ?
> > Suppose you have a Windows guest doesn't have PV driver? Or any other
> > OSes that have PCI drivers with hotplug support but not Xen drivers?
> 
> On qemu-trad, none of the devices support hotplug, so the option
> shouldn't be available in xl.
> 
> I believe qemu-upstream does offer hotplug devices, but it still has to
> create empty PCIe slots at boot time to hotplug into later, along with
> appropriate ACPI tables.
> 

I don't think it requires that much setup TBH. I tried to issue two QMP
commands and a nic shows up in the guest. Admittedly I only played with
it to see if it actually works so I could be missing a lot of things.

Wei.

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

Re: [Xen-devel] [PATCH] docs: Fix device_model_user description of its default value

[Anthony PERARD]

On Fri, May 20, 2016 at 05:34:10PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH] docs: Fix device_model_user description of 
> its default value"):
> > docs/misc/qemu-deprivilege.txt and libxl suggest that "xen-qemuuser" is
> > the default prefix, reflect that in the man.
> > 
> > Also add some emphasis.
> 
> I'm going to make a perhaps-controversial suggestion:
> 
> This feature should be deprecated for 4.7.  Specifically,
>  - the warning about running qemu as root should go away
>  - the docs should mention that running qemu not as root
>may well break things

Yes. The doc bearly mention an issue with migration and pci passthrough.
I could boot a guest, but shutdown did not work.

> Right now, the privsep is not finished and I think trying to run qemu
> as non-root won't (usually) actually work.
> 
> Ian.

-- 
Anthony PERARD

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

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Andrew Cooper]

On 20/05/16 17:42, Wei Liu wrote:
> On Fri, May 20, 2016 at 05:38:44PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("[RFC] libxl hotplug / unplug emulated devices"):
>>> Recently I got a report on xen-users@ about xl network-attach not
>>> working for HVM guest.
>>>
>>> I try to use
>>>   xl network-attach jessie-hvm 'bridge=xenbr0'
>>> and vif-bridge script complains that it can't add vifXX-emu to bridge.
>>>
>>> The underlying issue is that the vif spec provided defaults to
>>> emulated nic, but libxl only populates a pv nic but doesn't call out
>>> via QMP to QEMU to populate one. Note that this issue not only affects
>>> nic device but essentially all device types.
>> Is it really sensible to offer emulated nic hotplug ?  That'd be
>> presented to the guest as pci hotplug, I guess ?
> Suppose you have a Windows guest doesn't have PV driver? Or any other
> OSes that have PCI drivers with hotplug support but not Xen drivers?

On qemu-trad, none of the devices support hotplug, so the option
shouldn't be available in xl.

I believe qemu-upstream does offer hotplug devices, but it still has to
create empty PCIe slots at boot time to hotplug into later, along with
appropriate ACPI tables.


>
> For the second question, yes, more or less the same if you're talking
> about libxl side implementation. It's going to call some QMP commands.
>
>>> I also experimented with block device:
>>>   xl block-attach jessie-hvm 'phy:/dev/DATA/disk,hdb,w'
>>> and it succeed, only pv disk is populated though.
>> That's what I would have expected.
>>
>> Maybe the fix should be that xl network-attach should default hotplug
>> nics to pv only.
>>
> I certainly am fine with this.

+1.

~Andrew

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

Re: [Xen-devel] Bug in x86 instruction emulator?

[William Z.]

On 2016-05-18 11:12, Jan Beulich wrote:

On 06.04.16 at 01:38,  wrote:

I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
with vga="qxl", Xorg will segfault instantly if tried started. 
Multiple

Linux distros have been tested and Xorg segfaults in all.

Attached are a full backtrace from domU generated by Xorg, and a
assembler dump of function 'sse2_blt'.


Just FYI: Looks like I can repro this finally, and it also looks like 
at

least for me it isn't an SSE2 instruction that the issue is with.
Instead I'm getting an #UD in the middle of an instruction a few
lines down from the last SSE2 one, which suggests we're having
an issue with sizing instructions (however odd that may seem).
Now that I can repro it, at least I have something to actually
debug ...

Jan


I have patched Xen 4.6.1 with commit 
2bb230972c5ddb1ca823f47750b5d46a9d302d0e
(x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn 
emulation) and
tested with different Linux distros. I can say with confidence that the 
patch
has solved my initial problem as Xorg no longer segfaults when started. 
Thanks

to everyone that has helped with this.

However, while testing I have found a new problem. This may not be 
related to
my initial problem or even Xen, but I will try to describe it here as 
I'm hoping

someone can point me in the right direction.

Various actions will now raise the CPU usage of Xorg to 100% and freeze 
the

entire X Window System for some time. E.g.:

Starting xterm in a window manager or directly from .xinitrc and 
executing
dmesg. This will print a few lines per second while the Xorg CPU usage 
is 100%
and the X Window System is frozen for about 60 seconds until all dmesg 
output

has been printed.

I have run 'perf record -g -a sleep 60' while connected via SSH and then
executed dmesg in xterm. I have attached a few lines of 'perf report -g' 
with

the first one expanded.

I have also run 'strace -p $(pidof Xorg)' while dmesg was running in 
xterm. The
lines I have attached will repeat until all dmesg output has been 
printed. File

descriptor 8 is pointing on '/dev/dri/card0'.

Any ideas on what could cause this?

William Z.
Samples: 239K of event 'cpu-clock', Event count (approx.): 5999200
  Children  Self  Command Shared Object  Symbol
-   98.63%98.53%  Xorglibpixman-1.so.0.33.6  [.] sse2_blt.part.0
   - sse2_blt.part.0
  - 0.10% xen_hvm_callback_vector
   xen_evtchn_do_upcall
   irq_exit
   __do_softirq
   run_timer_softirq
   call_timer_fn
   rh_timer_func
 - usb_hcd_poll_rh_status
- 0.10% uhci_hub_status_data
 _raw_spin_unlock_irqrestore
  0.00% mod_timer
  - 0.00% retint_user
   prepare_exit_to_usermode
   exit_to_usermode_loop
   schedule
   __schedule
   finish_task_switch
+0.57% 0.00%  Xorg[kernel.kallsyms]  [k] 
entry_SYSCALL_64_fastpath
+0.51% 0.00%  Xorglibc-2.23.so   [.] __GI___ioctl
+0.51% 0.00%  Xorg[kernel.kallsyms]  [k] sys_ioctl
+0.51% 0.00%  swapper [kernel.kallsyms]  [k] rest_init
+0.51% 0.00%  swapper [kernel.kallsyms]  [k] start_kernel
+0.51% 0.00%  swapper [kernel.kallsyms]  [k] 
x86_64_start_reservations
+0.51% 0.00%  swapper [kernel.kallsyms]  [k] 
x86_64_start_kernel
+0.50% 0.00%  swapper [kernel.kallsyms]  [k] 
cpu_startup_entry
+0.50% 0.00%  Xorg[kernel.kallsyms]  [k] do_vfs_ioctl
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 14965392016
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 13436, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x107931000) = 
0x7f5489ddb000
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 48, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x107935000) = 
0x7f5489dda000
ioctl(8, DRM_IOCTL_QXL_EXECBUFFER, 0x7ffce28a6830) = 0
munmap(0x7f5489ddb000, 13436)   = 0
ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffce28a6800) = 0
munmap(0x7f5489dda000, 48)  = 0
ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffce28a6860) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
select(512, [1 3 4 5 6 9], NULL, NULL, {0, 0}) = 0 (Timeout)
setitimer(ITIMER_REAL, {it_interval={0, 5000}, it_value={0, 5000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {5298, 406984775}) = 0
ioctl(8, DRM_IOCTL_QXL_UPDATE_AREA, 0x7ffce28a6820) = 0
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 14965411184
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 14965435536
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Wei Liu]

On Fri, May 20, 2016 at 05:38:44PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[RFC] libxl hotplug / unplug emulated devices"):
> > Recently I got a report on xen-users@ about xl network-attach not
> > working for HVM guest.
> > 
> > I try to use
> >   xl network-attach jessie-hvm 'bridge=xenbr0'
> > and vif-bridge script complains that it can't add vifXX-emu to bridge.
> > 
> > The underlying issue is that the vif spec provided defaults to
> > emulated nic, but libxl only populates a pv nic but doesn't call out
> > via QMP to QEMU to populate one. Note that this issue not only affects
> > nic device but essentially all device types.
> 
> Is it really sensible to offer emulated nic hotplug ?  That'd be
> presented to the guest as pci hotplug, I guess ?

Suppose you have a Windows guest doesn't have PV driver? Or any other
OSes that have PCI drivers with hotplug support but not Xen drivers?

For the second question, yes, more or less the same if you're talking
about libxl side implementation. It's going to call some QMP commands.

> 
> > I also experimented with block device:
> >   xl block-attach jessie-hvm 'phy:/dev/DATA/disk,hdb,w'
> > and it succeed, only pv disk is populated though.
> 
> That's what I would have expected.
> 
> Maybe the fix should be that xl network-attach should default hotplug
> nics to pv only.
> 

I certainly am fine with this.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH] docs: Fix device_model_user description of its default value

[Andrew Cooper]

On 20/05/16 17:34, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH] docs: Fix device_model_user description of 
> its default value"):
>> docs/misc/qemu-deprivilege.txt and libxl suggest that "xen-qemuuser" is
>> the default prefix, reflect that in the man.
>>
>> Also add some emphasis.
> I'm going to make a perhaps-controversial suggestion:
>
> This feature should be deprecated for 4.7.  Specifically,
>  - the warning about running qemu as root should go away
>  - the docs should mention that running qemu not as root
>may well break things

Definitely does break migration (as reported back around Christmas).
Probably breaks other things.

The warning is definitely annoying, and not helpful.

~Andrew

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

Re: [Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Ian Jackson]

Wei Liu writes ("[RFC] libxl hotplug / unplug emulated devices"):
> Recently I got a report on xen-users@ about xl network-attach not
> working for HVM guest.
> 
> I try to use
>   xl network-attach jessie-hvm 'bridge=xenbr0'
> and vif-bridge script complains that it can't add vifXX-emu to bridge.
> 
> The underlying issue is that the vif spec provided defaults to
> emulated nic, but libxl only populates a pv nic but doesn't call out
> via QMP to QEMU to populate one. Note that this issue not only affects
> nic device but essentially all device types.

Is it really sensible to offer emulated nic hotplug ?  That'd be
presented to the guest as pci hotplug, I guess ?

> I also experimented with block device:
>   xl block-attach jessie-hvm 'phy:/dev/DATA/disk,hdb,w'
> and it succeed, only pv disk is populated though.

That's what I would have expected.

Maybe the fix should be that xl network-attach should default hotplug
nics to pv only.

Ian.

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

Re: [Xen-devel] [PATCH] docs: Fix device_model_user description of its default value

[Ian Jackson]

Anthony PERARD writes ("[PATCH] docs: Fix device_model_user description of its 
default value"):
> docs/misc/qemu-deprivilege.txt and libxl suggest that "xen-qemuuser" is
> the default prefix, reflect that in the man.
> 
> Also add some emphasis.

I'm going to make a perhaps-controversial suggestion:

This feature should be deprecated for 4.7.  Specifically,
 - the warning about running qemu as root should go away
 - the docs should mention that running qemu not as root
   may well break things

Right now, the privsep is not finished and I think trying to run qemu
as non-root won't (usually) actually work.

Ian.

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

[Xen-devel] [RFC] libxl hotplug / unplug emulated devices

[Wei Liu]

Hi all

Recently I got a report on xen-users@ about xl network-attach not
working for HVM guest.

I try to use

  xl network-attach jessie-hvm 'bridge=xenbr0'

and vif-bridge script complains that it can't add vifXX-emu to bridge.

The underlying issue is that the vif spec provided defaults to
emulated nic, but libxl only populates a pv nic but doesn't call out
via QMP to QEMU to populate one. Note that this issue not only affects
nic device but essentially all device types.

I also experimented with block device:

  xl block-attach jessie-hvm 'phy:/dev/DATA/disk,hdb,w'

and it succeed, only pv disk is populated though.

I think the ability to plug in emulated devices is nice to have -- how
important this is is up for debate.  As far as I can tell, at
least for nic, plugging in an emulated nic never worked in libxl. I
can't speak for xend. I also don't see many complains, so this is
probably not that important after all. On the other hand, it might be a
prerequisite for HVM usb passthrough?

The other angle is that we only support plugging in pv devices. Then
the rest of this email is moot. I will fix the network attach command
and we call it a day. :-)

To plug in emulated devices, calling out to QEMU is probably the easy
part. Also currently libxl__device_XXX_add always populates xenstore
entries, which we might not need or want. This is not too hard to
change, either.

The harder bit is to decide what should libxl do when disk and nic are
involved. That is, device that has the ability to use either emulated
path and pv path (which I think there are only disk and nic at the
moment).

Guest has ability to unplug emulated devices and switch to pv
devices. But the switch can only happen when the guest is booting. So
it would be ok to provide both emulated and pv disk / nic during guest
start up but not hotplug.

What if the user indeed wants to hotplug an emulated disk?

1. Add an extra field in diskspec to indicate intention (pv, emulated,
   both), defaults to "pv" when hotplug, "both" when creating domain.
   
2. Strictly follow the disk spec when doing hotplug, if it is emulated
   device identifier (hda, sda etc), add only emulated device, if it
   is pv identifier (xvdx etc), add only pv device. Refuse to proceed
   if nothing is specified. Note this might subtly change the device
   the guest sees, but there is no danger of data corruption.

3. Query QEMU if unplug has happened and combine this with option 1 to
   make libxl "smarter". For example, if unplug has happened, the
   intention flag defaults to pv, otherwise it defaults to both. This
   requires modifying QEMU.

Follow the same principle for nic.

Do we expect more devices to be able to switch from emulation path to
pv path?

I can take a stab at this if we make a decision on what to do.

Wei.

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Andrii Anisov]

> If a malicious user has access to the Android guest (via USB key, wifi,...)
> he would be able to crash the platform using the GPU because there is no
> SMMU protection.
That's why we are shadowing GPU MMU translation tables in xen heap.
And this is leaded us to need of [PATCH RFC 18/18] arm: Add ability to
allocate Xen heap in lowmem.
Patche for GPU MMU shadowing is not published yet, I still have to
check if it lacks of proprietary information.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94611: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  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-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  104 days
Testing same since93977  2016-05-10 11:09:16 Z   10 days   29 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [PATCH 2/2] xen: add update indicator to vcpu_runstate_info

[Jan Beulich]

>>> On 20.05.16 at 17:54,  wrote:
> On 20/05/16 17:36, Jan Beulich wrote:
> On 20.05.16 at 17:04,  wrote:
>>> On 20/05/16 16:49, Jan Beulich wrote:
>>> On 20.05.16 at 15:22,  wrote:
>  if ( guest_handle_is_null(runstate_guest(v)) )
>  return 1;
>  
> +update_flag = VM_ASSIST(v->domain, runstate_update_flag);
> +
>  smap_policy = smap_policy_change(v, SMAP_CHECK_ENABLED);
>  
> +if ( update_flag )
> +{
> +off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;

 How come this is outside the following if()? Also sizeof(...) - 1 please
 instead of the literal 7.
>>>
>>> I'm using off for the source address in __raw_copy_to_guest(), too.
>> 
>> But the offset should, afaict, be different for 32-bit (x86) and
>> 64-bit (or ARM).
> 
> Why? The offset is applied to v->runstate which clearly is the same
> for 32 and 64 bit domains, as it is the hypervisor private structure.
> Different offsets have to be applied at the destination side only, and
> this is done properly (at least I think so).

But as you say you use the offset for two purposes: The use on
the guest handle is which is problematic; the use on the hypervisor
internal structure is of course fine.

Jan


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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Edgar E. Iglesias]

On Fri, May 20, 2016 at 04:04:43PM +0100, Julien Grall wrote:
> Hello Oleksandr,
> 
> On 20/05/16 15:19, Oleksandr Dmytryshyn wrote:
> >On Fri, May 20, 2016 at 12:59 PM, Jan Beulich  wrote:
> >On 20.05.16 at 10:45,  wrote:
> >>>On Thu, May 19, 2016 at 5:36 PM, Jan Beulich  wrote:
> >>>On 19.05.16 at 15:58,  wrote:
> >Case 1: Dom0 is driver domain:
> >There is a Ducati firmware which runs on dedicated M4 core and decodes
> >video. This firmware uses hardcoded physical addresses for graphics
> >buffers. Those addresses should be inside address-space of the driver
> >domain (Dom0). Ducati firmware is proprietary and we have no ability
> >to rework it. So Dom0 kernel should be placed to the configured
> >address (to the DOM0 RAM bank with specific address).
> >
> >Case 2: Dom0 is Thin and DomD is driver domain.
> >All is the same: Ducati firmware requires special (hardcoded) addresses.
> 
> For both of these cases I would then wonder whether such
> environments are actually suitable for doing virtualization on.
> >>>Currently we use Jacinto 6 evaluation board with DRA74X processor.
> >>>We have both configurations (Thin Dom0 and Thich Dom0).
> >>
> >>Which says nothing about their suitability for virtualization.
> >Our solution is based on Jacinto 6 evaluation board with DRA74X
> >processor. We need video-playback. Ducati firmware decodes video and
> >it works only with hardcoded addresses so we need this patch.
> 
> This patch is a way to solve the problem and may not be the only one.
> I would like to explore all the possibilities before taking an approach that
> requires to modify the memory allocator in Xen.
> 
> In my previous mails, I suggested a different solution (see [1] and [2]). If
> you think it is not suitable, please share more details or explain why you
> think your patch is the only way to solve it.

Hi,

We have similar needs (not exactly the same) in some of our setups.
We need to map certain OCMs (On Chip Memories) to dom0. Among other things,
these are used to communicate with remote accelerators/CPUs that have
"hardcoded" addresses to these RAMs.

Our approach is more along the lines of Juliens second suggestion. We're
trying to use the mmio-sram DTS bindings to bring in these memories into
dom0.

IIUC the Ducati FW issue correctly, you need to allocate a chunk of DDR.

Another possible solution:
I think you could reserve the memory area by simply not mentioning it
in the main memory node (these nodes support multiple ranges so you can
introduce gaps). Then you could for example create an mmio-sram node to
get the memory explicitely mapped 1:1 into dom0.

Just a moment ago, I posted an RFC for the mmio-sram support to the list.

Cheers,
Edgar


> 
> Regards,
> 
> [1]
> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01879.html
> [2]
> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01894.html
> 
> -- 
> Julien Grall
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall

[Juergen Gross]

On 20/05/16 17:33, Jan Beulich wrote:
 On 20.05.16 at 17:08,  wrote:
>> On 20/05/16 16:51, Jan Beulich wrote:
>> On 20.05.16 at 16:42,  wrote:
 On 20/05/16 16:34, Jan Beulich wrote:
 On 20.05.16 at 15:22,  wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1408,7 +1408,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
 XEN_GUEST_HANDLE_PARAM(void) arg)
>>  return rc;
>>  }
>>  
>> -#ifdef VM_ASSIST_VALID
>>  long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
>> unsigned long valid)
>>  {
>> @@ -1427,7 +1426,6 @@ long vm_assist(struct domain *p, unsigned int cmd, 
>> unsigned int type,
>>  
>>  return -ENOSYS;
>>  }
>> -#endif
>>  
>>  struct pirq *pirq_get_info(struct domain *d, int pirq)
>>  {
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -441,12 +441,10 @@ DO(nmi_op)(unsigned int cmd, 
 XEN_GUEST_HANDLE_PARAM(void) arg)
>>  return rc;
>>  }
>>  
>> -#ifdef VM_ASSIST_VALID
>>  DO(vm_assist)(unsigned int cmd, unsigned int type)
>>  {
>>  return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
>>  }
>> -#endif
>
> Removing these #ifdef-s is neither necessary for this patch (at least
> afaict) nor desirable (after all they had got added so that an arch
> doesn't get this code compiled for no reason).

 Removing is not necessary, right.

 OTOH there is no arch left needing those #ifdef-s to be in place. Or do
 you think we should guard each single functionality in xen/common by
 such means? I don't think so. In this case keeping the #ifdef-s would be
 for historical reasons only.
>>>
>>> No, I don't want to go overboard with this. But we added these
>>> not so long ago, so I see no reason why they should now be
>>> removed again, just to maybe have them added in a couple of
>>> years again.
>>
>> Hmm, those #ifdef-s where needed for ARM, as on ARM there just was no
>> flag to be set via vm_assist hypercall. The new flag added in the next
>> patch is suitable for all architectures, so there would be no reason
>> for not supporting vm_assist in a new to be supported architecture.
> 
> Hmm, you have a point here. Otoh new architectures should
> probably assume that behavior even without having explicitly
> asked for it.

I don't think so, but you are the maintainer. In case there are no
objections by other maintainers I'll leave the #ifdef-s in place.


Juergen


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

Re: [Xen-devel] [PATCH 2/2] xen: add update indicator to vcpu_runstate_info

[Juergen Gross]

On 20/05/16 17:36, Jan Beulich wrote:
 On 20.05.16 at 17:04,  wrote:
>> On 20/05/16 16:49, Jan Beulich wrote:
>> On 20.05.16 at 15:22,  wrote:
  if ( guest_handle_is_null(runstate_guest(v)) )
  return 1;
  
 +update_flag = VM_ASSIST(v->domain, runstate_update_flag);
 +
  smap_policy = smap_policy_change(v, SMAP_CHECK_ENABLED);
  
 +if ( update_flag )
 +{
 +off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;
>>>
>>> How come this is outside the following if()? Also sizeof(...) - 1 please
>>> instead of the literal 7.
>>
>> I'm using off for the source address in __raw_copy_to_guest(), too.
> 
> But the offset should, afaict, be different for 32-bit (x86) and
> 64-bit (or ARM).

Why? The offset is applied to v->runstate which clearly is the same
for 32 and 64 bit domains, as it is the hypervisor private structure.
Different offsets have to be applied at the destination side only, and
this is done properly (at least I think so).


Juergen


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

[Xen-devel] [RFC for-4.8 5/6] xen/arm: Add an mmio-sram device

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add an mmio-sram device. This device takes care of mapping
mmio-sram regions as MEMORY as opposed to the generic DT
mappings as DEVICE.

We only map the outer regions as children of mmio-sram nodes
describe allocations within it that really only mean something
to the guest.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/mmio-sram.c | 92 
 2 files changed, 93 insertions(+)
 create mode 100644 xen/arch/arm/mmio-sram.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ead0cc0..224c9ae 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -18,6 +18,7 @@ obj-y += io.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += mm.o
+obj-y += mmio-sram.o
 obj-y += p2m.o
 obj-y += percpu.o
 obj-y += guestcopy.o
diff --git a/xen/arch/arm/mmio-sram.c b/xen/arch/arm/mmio-sram.c
new file mode 100644
index 000..e0dbf7c
--- /dev/null
+++ b/xen/arch/arm/mmio-sram.c
@@ -0,0 +1,92 @@
+/*
+ * xen/arch/arm/mmio-sram.c
+ *
+ * MMIO-SRAM
+ *
+ * Edgar E. Iglesias 
+ * Copyright (c) 2016 Xilinx Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+// #define DEBUG_DT
+
+#ifdef DEBUG_DT
+# define DPRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
+#else
+# define DPRINT(fmt, args...) do {} while ( 0 )
+#endif
+
+static int sram_map(struct domain *d, struct dt_device_node *dev)
+{
+   unsigned int naddr;
+   u64 addr, size;
+   int res = 0;
+   int i;
+
+   naddr = dt_number_of_address(dev);
+
+   /* Give perms to access the region.  */
+   res = iomem_permit_access(d, paddr_to_pfn(addr),
+ paddr_to_pfn(PAGE_ALIGN(addr + size - 1)));
+
+   /*
+* Map the memory regions.
+*
+* We only map the outer regions. Child regions represent
+* sub allocations that really are the guest's business.
+*/
+   for (i = 0; i < naddr; i++)
+   {
+   res = dt_device_get_address(dev, i, , );
+   if (res) {
+   printk(XENLOG_ERR
+   "Unable to retrieve address %u for %s\n",
+   i, dt_node_full_name(dev));
+   return res;
+   }
+
+   DPRINT("  - MEMORY: %s %010"PRIx64" - %010"PRIx64"\n",
+  dt_node_full_name(dev), addr, addr + size);
+   res = map_regions_rwx_cache(d, paddr_to_pfn(addr & PAGE_MASK),
+   DIV_ROUND_UP(size, PAGE_SIZE),
+   paddr_to_pfn(addr & PAGE_MASK));
+   if (res)
+   return res;
+   }
+   return res;
+}
+
+static const struct dt_device_match sram_dt_match[] __initconst =
+{
+   DT_MATCH_COMPATIBLE("mmio-sram"),
+   { /* sentinel */ },
+};
+
+DT_DEVICE_START(sram, "MMIO-SRAM", DEVICE_MEMORY)
+   .dt_match = sram_dt_match,
+   .map = sram_map,
+DT_DEVICE_END
-- 
2.5.0


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

[Xen-devel] [RFC for-4.8 2/6] xen/arm: Add an optional map function to the device descriptor

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add an optional map function to the device descriptor. If
registered, the map function will be called to do custom
device specific mappings of the device. If not registered,
the generic DT version (handle_device) will be used.

This is in preparation for adding support for "mmio-sram"
memory that needs to be mapped as MEMORY and not DEVICE.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/domain_build.c  | 13 -
 xen/include/asm-arm/device.h | 10 ++
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 00dc07a..15b6dbe 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1212,6 +1212,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 DT_MATCH_PATH("/hypervisor"),
 { /* sentinel */ },
 };
+const struct device_desc *desc;
 struct dt_device_node *child;
 int res;
 const char *name;
@@ -1233,6 +1234,8 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return 0;
 }
 
+desc = device_get_desc(node);
+
 /*
  * Replace these nodes with our own. Note that the original may be
  * used_by DOMID_XEN so this check comes first.
@@ -1268,7 +1271,15 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
"WARNING: Path %s is reserved, skip the node as we may re-use 
the path.\n",
path);
 
-res = handle_device(d, node);
+if ( desc && desc->map )
+{
+res = desc->map(d, node);
+}
+else
+{
+res = handle_device(d, node);
+}
+
 if ( res)
 return res;
 
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 1a40a02..98b9fe1 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -48,6 +48,16 @@ struct device_desc {
 const struct dt_device_match *dt_match;
 /* Device initialization */
 int (*init)(struct dt_device_node *dev, const void *data);
+
+/**
+ *  map - Custom map function to map a devices memory regions and IRQs
+ *  @d: Domain to map device into
+ *  @dev: Device tree node representing the device
+ *
+ *  OPTIONAL: If not set the generic DT code will take care of creating
+ *  the mappings.
+ */
+int (*map)(struct domain *d, struct dt_device_node *dev);
 };
 
 struct acpi_device_desc {
-- 
2.5.0


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

[Xen-devel] [RFC for-4.8 0/6] xen/arm: Add support for mapping mmio-sram nodes into dom0

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

This series adds support for mapping mmio-sram nodes into dom0
as MEMORY, cached and with RWX perms.

Dom0 can then choose to further restrict these mappings if needed.
We only look at the outer mmio-sram region. The sub-area nodes that
describe allocations within the mmio-sram region are only meaningful
to the guest AFAICT.

In an attempt to avoid growing the already fairly large domain_build.c
file, I've tried to implement a distributed way to deal with these kind
of special/custom mapping needs. These can live outside of domain_build.c
and are registerd by means of a .map method in the device_spec.

If this approach is not good, I'm happy to bin it and try something else.

Comments welcome!

Best regards,
Edgar

Edgar E. Iglesias (6):
  xen/arm: Add device_get_desc()
  xen/arm: Add an optional map function to the device descriptor
  xen/arm: Add a DEVICE_MEMORY class
  xen/arm: Add helper functions to map RWX memory regions
  xen/arm: Add an mmio-sram device
  xen/arm: Avoid multiple dev class lookups in handle_node

 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/device.c| 15 
 xen/arch/arm/domain_build.c  | 19 +++--
 xen/arch/arm/mmio-sram.c | 92 
 xen/arch/arm/p2m.c   | 26 +
 xen/include/asm-arm/device.h | 12 ++
 xen/include/asm-arm/p2m.h| 10 +
 7 files changed, 172 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/arm/mmio-sram.c

-- 
2.5.0


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

[Xen-devel] [RFC for-4.8 1/6] xen/arm: Add device_get_desc()

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add device_get_desc, a function to lookup the device descriptor
for a DT node. This is in preparation for adding per device
mapping implementations.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/device.c| 15 +++
 xen/include/asm-arm/device.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index a0072c1..1b934b9 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -83,6 +83,21 @@ enum device_class device_get_class(const struct 
dt_device_node *dev)
 return DEVICE_UNKNOWN;
 }
 
+const struct device_desc *device_get_desc(const struct dt_device_node *dev)
+{
+const struct device_desc *desc;
+
+ASSERT(dev != NULL);
+
+for ( desc = _sdevice; desc != _edevice; desc++ )
+{
+if ( dt_match_node(desc->dt_match, dev) )
+return desc;
+}
+
+return NULL;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8..1a40a02 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -89,6 +89,7 @@ int __init device_init(struct dt_device_node *dev, enum 
device_class class,
  * Return the device type on success or DEVICE_ANY on failure
  */
 enum device_class device_get_class(const struct dt_device_node *dev);
+const struct device_desc *device_get_desc(const struct dt_device_node *dev);
 
 #define DT_DEVICE_START(_name, _namestr, _class)\
 static const struct device_desc __dev_desc_##_name __used   \
-- 
2.5.0


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

[Xen-devel] [RFC for-4.8 3/6] xen/arm: Add a DEVICE_MEMORY class

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add a DEVICE_MEMORY class to be used for things like "mmio-sram"
or memory controllers.

Signed-off-by: Edgar E. Iglesias 
---
 xen/include/asm-arm/device.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 98b9fe1..99073bf 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -35,6 +35,7 @@ enum device_class
 DEVICE_SERIAL,
 DEVICE_IOMMU,
 DEVICE_GIC,
+DEVICE_MEMORY,
 /* Use for error */
 DEVICE_UNKNOWN,
 };
-- 
2.5.0


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

[Xen-devel] [RFC for-4.8 4/6] xen/arm: Add helper functions to map RWX memory regions

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Create a helper function to map regions as MEMORY with
cached attributes and read-write-execute permissions.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/p2m.c| 26 ++
 xen/include/asm-arm/p2m.h | 10 ++
 2 files changed, 36 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index db21433..7e788f9 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1219,6 +1219,32 @@ int p2m_populate_ram(struct domain *d,
  d->arch.p2m.default_access);
 }
 
+int map_regions_rwx_cache(struct domain *d,
+ unsigned long start_gfn,
+ unsigned long nr,
+ unsigned long mfn)
+{
+return apply_p2m_changes(d, INSERT,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, 0, p2m_ram_rw,
+ p2m_access_rwx);
+}
+
+int unmap_regions_rwx_cache(struct domain *d,
+   unsigned long start_gfn,
+   unsigned long nr,
+   unsigned long mfn)
+{
+return apply_p2m_changes(d, REMOVE,
+ pfn_to_paddr(start_gfn),
+ pfn_to_paddr(start_gfn + nr),
+ pfn_to_paddr(mfn),
+ MATTR_MEM, 0, p2m_invalid,
+ p2m_access_rwx);
+}
+
 int map_regions_rw_cache(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index d240d1e..294050e 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -144,6 +144,16 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, 
xen_pfn_t end_mfn);
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
 
+int map_regions_rwx_cache(struct domain *d,
+  unsigned long start_gfn,
+  unsigned long nr_mfns,
+  unsigned long mfn);
+
+int unmap_regions_rwx_cache(struct domain *d,
+unsigned long start_gfn,
+unsigned long nr_mfns,
+unsigned long mfn);
+
 int map_regions_rw_cache(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr_mfns,
-- 
2.5.0


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

[Xen-devel] [RFC for-4.8 6/6] xen/arm: Avoid multiple dev class lookups in handle_node

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Avoid looking up the device class multiple times in handle_node().
This optimization should not have any functional change.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/domain_build.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 15b6dbe..65c2df7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1213,6 +1213,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 { /* sentinel */ },
 };
 const struct device_desc *desc;
+enum device_class dev_class;
 struct dt_device_node *child;
 int res;
 const char *name;
@@ -1235,12 +1236,13 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 }
 
 desc = device_get_desc(node);
+dev_class = desc ? desc->class : DEVICE_UNKNOWN;
 
 /*
  * Replace these nodes with our own. Note that the original may be
  * used_by DOMID_XEN so this check comes first.
  */
-if ( device_get_class(node) == DEVICE_GIC )
+if ( dev_class == DEVICE_GIC )
 return make_gic_node(d, kinfo->fdt, node);
 if ( dt_match_node(timer_matches, node) )
 return make_timer_node(d, kinfo->fdt, node);
@@ -1256,7 +1258,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
  * Even if the IOMMU device is not used by Xen, it should not be
  * passthrough to DOM0
  */
-if ( device_get_class(node) == DEVICE_IOMMU )
+if ( dev_class == DEVICE_IOMMU )
 {
 DPRINT(" IOMMU, skip it\n");
 return 0;
-- 
2.5.0


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

[Xen-devel] [PATCH] docs: Fix device_model_user description of its default value

[Anthony PERARD]

docs/misc/qemu-deprivilege.txt and libxl suggest that "xen-qemuuser" is
the default prefix, reflect that in the man.

Also add some emphasis.

Signed-off-by: Anthony PERARD 
---
 docs/man/xl.cfg.pod.5 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index a4cc1b3..accd9b4 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1952,7 +1952,7 @@ option to the device-model.
 =item 

Re: [Xen-devel] [PATCH 2/2] xen: add update indicator to vcpu_runstate_info

[Jan Beulich]

>>> On 20.05.16 at 17:04,  wrote:
> On 20/05/16 16:49, Jan Beulich wrote:
> On 20.05.16 at 15:22,  wrote:
>>>  if ( guest_handle_is_null(runstate_guest(v)) )
>>>  return 1;
>>>  
>>> +update_flag = VM_ASSIST(v->domain, runstate_update_flag);
>>> +
>>>  smap_policy = smap_policy_change(v, SMAP_CHECK_ENABLED);
>>>  
>>> +if ( update_flag )
>>> +{
>>> +off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;
>> 
>> How come this is outside the following if()? Also sizeof(...) - 1 please
>> instead of the literal 7.
> 
> I'm using off for the source address in __raw_copy_to_guest(), too.

But the offset should, afaict, be different for 32-bit (x86) and
64-bit (or ARM).

Jan


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

Re: [Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall

[Jan Beulich]

>>> On 20.05.16 at 17:08,  wrote:
> On 20/05/16 16:51, Jan Beulich wrote:
> On 20.05.16 at 16:42,  wrote:
>>> On 20/05/16 16:34, Jan Beulich wrote:
>>> On 20.05.16 at 15:22,  wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1408,7 +1408,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>  return rc;
>  }
>  
> -#ifdef VM_ASSIST_VALID
>  long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
> unsigned long valid)
>  {
> @@ -1427,7 +1426,6 @@ long vm_assist(struct domain *p, unsigned int cmd, 
> unsigned int type,
>  
>  return -ENOSYS;
>  }
> -#endif
>  
>  struct pirq *pirq_get_info(struct domain *d, int pirq)
>  {
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -441,12 +441,10 @@ DO(nmi_op)(unsigned int cmd, 
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>  return rc;
>  }
>  
> -#ifdef VM_ASSIST_VALID
>  DO(vm_assist)(unsigned int cmd, unsigned int type)
>  {
>  return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
>  }
> -#endif

 Removing these #ifdef-s is neither necessary for this patch (at least
 afaict) nor desirable (after all they had got added so that an arch
 doesn't get this code compiled for no reason).
>>>
>>> Removing is not necessary, right.
>>>
>>> OTOH there is no arch left needing those #ifdef-s to be in place. Or do
>>> you think we should guard each single functionality in xen/common by
>>> such means? I don't think so. In this case keeping the #ifdef-s would be
>>> for historical reasons only.
>> 
>> No, I don't want to go overboard with this. But we added these
>> not so long ago, so I see no reason why they should now be
>> removed again, just to maybe have them added in a couple of
>> years again.
> 
> Hmm, those #ifdef-s where needed for ARM, as on ARM there just was no
> flag to be set via vm_assist hypercall. The new flag added in the next
> patch is suitable for all architectures, so there would be no reason
> for not supporting vm_assist in a new to be supported architecture.

Hmm, you have a point here. Otoh new architectures should
probably assume that behavior even without having explicitly
asked for it.

Jan


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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Meng Xu]

On Thu, May 19, 2016 at 5:53 PM, Andrii Anisov
 wrote:
> Meng,
>

Hi Andrii,

Thank you very much for your explanation about the use case in previous email!

>>> If the board is not supported by Xen, can we say Xen will support the
>>> board with the warkaround?
>
> I would not say boards are supported by XEN (except earlyprintk).
> Rather architectures are supported in general, and SoC's are supported
> in architecture implementation defined deviations (i.e. SMMU absence).

Yes. I searched around for the "Jacinto 6" Automotive processor.[1]
It uses Cortex A15 processor...
However, I tried the Arndale Octo board two years ago
(http://www.arndaleboard.org/wiki/index.php/Main_Page). From my
previous experience, the board may not be supported by Xen even though
the processor it uses has virtualization extension.. :-(
That's why I asked if the board itself can run Xen. If the board can
run Xen, I would like to buy one and try it out. :-)

[1] http://www.ti.com/lit/ds/symlink/dra746.pdf

Thanks and Best Regards,

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

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

Re: [Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall

[Jan Beulich]

>>> On 20.05.16 at 16:42,  wrote:
> On 20/05/16 16:34, Jan Beulich wrote:
> On 20.05.16 at 15:22,  wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -1408,7 +1408,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  return rc;
>>>  }
>>>  
>>> -#ifdef VM_ASSIST_VALID
>>>  long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
>>> unsigned long valid)
>>>  {
>>> @@ -1427,7 +1426,6 @@ long vm_assist(struct domain *p, unsigned int cmd, 
>>> unsigned int type,
>>>  
>>>  return -ENOSYS;
>>>  }
>>> -#endif
>>>  
>>>  struct pirq *pirq_get_info(struct domain *d, int pirq)
>>>  {
>>> --- a/xen/common/kernel.c
>>> +++ b/xen/common/kernel.c
>>> @@ -441,12 +441,10 @@ DO(nmi_op)(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  return rc;
>>>  }
>>>  
>>> -#ifdef VM_ASSIST_VALID
>>>  DO(vm_assist)(unsigned int cmd, unsigned int type)
>>>  {
>>>  return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
>>>  }
>>> -#endif
>> 
>> Removing these #ifdef-s is neither necessary for this patch (at least
>> afaict) nor desirable (after all they had got added so that an arch
>> doesn't get this code compiled for no reason).
> 
> Removing is not necessary, right.
> 
> OTOH there is no arch left needing those #ifdef-s to be in place. Or do
> you think we should guard each single functionality in xen/common by
> such means? I don't think so. In this case keeping the #ifdef-s would be
> for historical reasons only.

No, I don't want to go overboard with this. But we added these
not so long ago, so I see no reason why they should now be
removed again, just to maybe have them added in a couple of
years again.

Jan


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

Re: [Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall

[Juergen Gross]

On 20/05/16 16:51, Jan Beulich wrote:
 On 20.05.16 at 16:42,  wrote:
>> On 20/05/16 16:34, Jan Beulich wrote:
>> On 20.05.16 at 15:22,  wrote:
 --- a/xen/common/domain.c
 +++ b/xen/common/domain.c
 @@ -1408,7 +1408,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
  return rc;
  }
  
 -#ifdef VM_ASSIST_VALID
  long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
 unsigned long valid)
  {
 @@ -1427,7 +1426,6 @@ long vm_assist(struct domain *p, unsigned int cmd, 
 unsigned int type,
  
  return -ENOSYS;
  }
 -#endif
  
  struct pirq *pirq_get_info(struct domain *d, int pirq)
  {
 --- a/xen/common/kernel.c
 +++ b/xen/common/kernel.c
 @@ -441,12 +441,10 @@ DO(nmi_op)(unsigned int cmd, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
  return rc;
  }
  
 -#ifdef VM_ASSIST_VALID
  DO(vm_assist)(unsigned int cmd, unsigned int type)
  {
  return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
  }
 -#endif
>>>
>>> Removing these #ifdef-s is neither necessary for this patch (at least
>>> afaict) nor desirable (after all they had got added so that an arch
>>> doesn't get this code compiled for no reason).
>>
>> Removing is not necessary, right.
>>
>> OTOH there is no arch left needing those #ifdef-s to be in place. Or do
>> you think we should guard each single functionality in xen/common by
>> such means? I don't think so. In this case keeping the #ifdef-s would be
>> for historical reasons only.
> 
> No, I don't want to go overboard with this. But we added these
> not so long ago, so I see no reason why they should now be
> removed again, just to maybe have them added in a couple of
> years again.

Hmm, those #ifdef-s where needed for ARM, as on ARM there just was no
flag to be set via vm_assist hypercall. The new flag added in the next
patch is suitable for all architectures, so there would be no reason
for not supporting vm_assist in a new to be supported architecture.


Juergen


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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Julien Grall]

Hello Oleksandr,

On 20/05/16 15:19, Oleksandr Dmytryshyn wrote:

On Fri, May 20, 2016 at 12:59 PM, Jan Beulich  wrote:

On 20.05.16 at 10:45,  wrote:

On Thu, May 19, 2016 at 5:36 PM, Jan Beulich  wrote:

On 19.05.16 at 15:58,  wrote:

Case 1: Dom0 is driver domain:
There is a Ducati firmware which runs on dedicated M4 core and decodes
video. This firmware uses hardcoded physical addresses for graphics
buffers. Those addresses should be inside address-space of the driver
domain (Dom0). Ducati firmware is proprietary and we have no ability
to rework it. So Dom0 kernel should be placed to the configured
address (to the DOM0 RAM bank with specific address).

Case 2: Dom0 is Thin and DomD is driver domain.
All is the same: Ducati firmware requires special (hardcoded) addresses.


For both of these cases I would then wonder whether such
environments are actually suitable for doing virtualization on.

Currently we use Jacinto 6 evaluation board with DRA74X processor.
We have both configurations (Thin Dom0 and Thich Dom0).


Which says nothing about their suitability for virtualization.

Our solution is based on Jacinto 6 evaluation board with DRA74X
processor. We need video-playback. Ducati firmware decodes video and
it works only with hardcoded addresses so we need this patch.


This patch is a way to solve the problem and may not be the only one.
I would like to explore all the possibilities before taking an approach 
that requires to modify the memory allocator in Xen.


In my previous mails, I suggested a different solution (see [1] and 
[2]). If you think it is not suitable, please share more details or 
explain why you think your patch is the only way to solve it.


Regards,

[1] 
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01879.html
[2] 
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01894.html


--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] xen: add update indicator to vcpu_runstate_info

[Juergen Gross]

On 20/05/16 16:49, Jan Beulich wrote:
 On 20.05.16 at 15:22,  wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1925,13 +1925,37 @@ static void paravirt_ctxt_switch_to(struct vcpu *v)
>>  bool_t update_runstate_area(struct vcpu *v)
>>  {
>>  bool_t rc;
>> +bool_t update_flag;
> 
> I think this variable is superfluous (and causes more register pressure
> in the compiler), since ...
> 
>>  smap_check_policy_t smap_policy;
>> +void __user *guest_handle = NULL;
> 
> ... you can key off of this being non-NULL or ...
> 
>> +unsigned off = 0;
> 
> ... this being non-zero in the second if().

Okay. Will change.

> 
>>  if ( guest_handle_is_null(runstate_guest(v)) )
>>  return 1;
>>  
>> +update_flag = VM_ASSIST(v->domain, runstate_update_flag);
>> +
>>  smap_policy = smap_policy_change(v, SMAP_CHECK_ENABLED);
>>  
>> +if ( update_flag )
>> +{
>> +off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;
> 
> How come this is outside the following if()? Also sizeof(...) - 1 please
> instead of the literal 7.

I'm using off for the source address in __raw_copy_to_guest(), too.
Regarding sizeof(): okay.

> 
>> --- a/xen/include/public/vcpu.h
>> +++ b/xen/include/public/vcpu.h
>> @@ -84,6 +84,12 @@ struct vcpu_runstate_info {
>>  /* When was current state entered (system time, ns)? */
>>  uint64_t state_entry_time;
>>  /*
>> + * Update indicator set in state_entry_time:
>> + * When activated via VMASST_TYPE_runstate_update_flag, set during
>> + * updates in guest memory mapped copy of vcpu_runstate_info.
>> + */
>> +#define XEN_RUNSTATE_UPDATE  (1ULL << 63)
> 
> I think this should be UINT64_C(1), as ULL is not a C89 compatible
> suffix, but by requiring uint64_t I think we can imply that along with
> that C99 type the platform also surfaces respective macros.

Okay.


Juergen

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

Re: [Xen-devel] [PATCH 2/2] xen: add update indicator to vcpu_runstate_info

[Jan Beulich]

>>> On 20.05.16 at 15:22,  wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1925,13 +1925,37 @@ static void paravirt_ctxt_switch_to(struct vcpu *v)
>  bool_t update_runstate_area(struct vcpu *v)
>  {
>  bool_t rc;
> +bool_t update_flag;

I think this variable is superfluous (and causes more register pressure
in the compiler), since ...

>  smap_check_policy_t smap_policy;
> +void __user *guest_handle = NULL;

... you can key off of this being non-NULL or ...

> +unsigned off = 0;

... this being non-zero in the second if().

>  if ( guest_handle_is_null(runstate_guest(v)) )
>  return 1;
>  
> +update_flag = VM_ASSIST(v->domain, runstate_update_flag);
> +
>  smap_policy = smap_policy_change(v, SMAP_CHECK_ENABLED);
>  
> +if ( update_flag )
> +{
> +off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;

How come this is outside the following if()? Also sizeof(...) - 1 please
instead of the literal 7.

> --- a/xen/include/public/vcpu.h
> +++ b/xen/include/public/vcpu.h
> @@ -84,6 +84,12 @@ struct vcpu_runstate_info {
>  /* When was current state entered (system time, ns)? */
>  uint64_t state_entry_time;
>  /*
> + * Update indicator set in state_entry_time:
> + * When activated via VMASST_TYPE_runstate_update_flag, set during
> + * updates in guest memory mapped copy of vcpu_runstate_info.
> + */
> +#define XEN_RUNSTATE_UPDATE  (1ULL << 63)

I think this should be UINT64_C(1), as ULL is not a C89 compatible
suffix, but by requiring uint64_t I think we can imply that along with
that C99 type the platform also surfaces respective macros.

Jan


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

Re: [Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall

[Juergen Gross]

On 20/05/16 16:34, Jan Beulich wrote:
 On 20.05.16 at 15:22,  wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -1408,7 +1408,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>  return rc;
>>  }
>>  
>> -#ifdef VM_ASSIST_VALID
>>  long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
>> unsigned long valid)
>>  {
>> @@ -1427,7 +1426,6 @@ long vm_assist(struct domain *p, unsigned int cmd, 
>> unsigned int type,
>>  
>>  return -ENOSYS;
>>  }
>> -#endif
>>  
>>  struct pirq *pirq_get_info(struct domain *d, int pirq)
>>  {
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -441,12 +441,10 @@ DO(nmi_op)(unsigned int cmd, 
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>  return rc;
>>  }
>>  
>> -#ifdef VM_ASSIST_VALID
>>  DO(vm_assist)(unsigned int cmd, unsigned int type)
>>  {
>>  return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
>>  }
>> -#endif
> 
> Removing these #ifdef-s is neither necessary for this patch (at least
> afaict) nor desirable (after all they had got added so that an arch
> doesn't get this code compiled for no reason).

Removing is not necessary, right.

OTOH there is no arch left needing those #ifdef-s to be in place. Or do
you think we should guard each single functionality in xen/common by
such means? I don't think so. In this case keeping the #ifdef-s would be
for historical reasons only.

If you really want I can keep them or do the removal in a separate patch
if you want to split functional addition and related cleanup.


Juergen

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

Re: [Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall

[Jan Beulich]

>>> On 20.05.16 at 15:22,  wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1408,7 +1408,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  return rc;
>  }
>  
> -#ifdef VM_ASSIST_VALID
>  long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
> unsigned long valid)
>  {
> @@ -1427,7 +1426,6 @@ long vm_assist(struct domain *p, unsigned int cmd, 
> unsigned int type,
>  
>  return -ENOSYS;
>  }
> -#endif
>  
>  struct pirq *pirq_get_info(struct domain *d, int pirq)
>  {
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -441,12 +441,10 @@ DO(nmi_op)(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  return rc;
>  }
>  
> -#ifdef VM_ASSIST_VALID
>  DO(vm_assist)(unsigned int cmd, unsigned int type)
>  {
>  return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
>  }
> -#endif

Removing these #ifdef-s is neither necessary for this patch (at least
afaict) nor desirable (after all they had got added so that an arch
doesn't get this code compiled for no reason).

Jan


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

Re: [Xen-devel] [sun8i][H3] Question about running Xen on OrangePi PC

[Julien Grall]

On 19/05/16 18:31, bharat gohil wrote:

Hello All,


Hello,


I am trying to boot xen on OrangePi PC(based upon Allwinner H3). It is
able to boot on this target board but it hangs when it try to boot
unmodified linux guest(with xen configuration enable).

Please find following log for same.Can anyone guide me to debug this
problem(hang)?

Starting kernel ...

- UART enabled -
- CPU  booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - 7fff
(XEN)
(XEN) MODULE[0]: 7ec0 - 7ec04000 Device Tree
(XEN) MODULE[1]: 7f60 - 7f955328 Kernel
console=hvc0 d


The end of the command line seems to have been eaten.

What's the full command line? I would recommend you to use earlycon for 
Linux to get some early log. The parameter looks like:


earlycon=uart,mmio32,0x0700

(Note, I do not know if the parameters are correct)


(XEN)  RESVD[0]: 7ffa1000 - 7ffa15e8
(XEN)  RESVD[1]: 7ec0 - 7ec04000
(XEN)
(XEN) Command line: console=dtuart dtuart=/soc@01c0/serial@01c28000
dom0_meM


Same here.


(XEN) Placing Xen at 0x7fc0-0x7fe0
(XEN) Update BOOTMOD_XEN from 7ea0-7eb01701 =>
7fc01
(XEN) Xen heap: 7c00-7e00 (8192 pages)
(XEN) Dom heap: 253952 pages
(XEN) Domain heap initialised
(XEN) Platform: Generic System
(XEN) Looking for dtuart at "/soc@01c0/serial@01c28000", options ""
(XEN) Unable to find device "/soc@01c0/serial@01c28000"
(XEN) Bad console= option 'dtuart'


Not related to your issue, but Xen is not able to find the serial you 
passed on the command line.



  Xen 4.6.2-pre
(XEN) Xen version 4.6.2-pre (bgohil@) (arm-eabi-gcc (Linaro GCC
5.3-2016.02) 5.6


The board is not officially supported by Xen. I would highly recommend 
you to use Xen upstream (i.e master or staging) when trying to port the 
hypervisor on a new board.



(XEN) Latest ChangeSet: Tue Apr 26 12:07:49 2016 +0200 git:39546d1
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10101105 4000 0124 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
(XEN) Using PSCI-0.1 for SMP bringup
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=01c81000
(XEN) gic_cpu_addr=01c82000
(XEN) gic_hyp_addr=01c84000
(XEN) gic_vcpu_addr=01c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 160 lines, 4 cpus, secure (IID 0100143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 32 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 7f60
(XEN) Allocating 1:1 mappings totalling 128MB for dom0:
(XEN) BANK[0] 0x007000-0x007800 (128MB)
(XEN) Grant table range: 0x007fc0-0x007fc61000
(XEN) Loading zImage from 7f60 to
77c0-77f55328
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x77a0-0x77a03cd0
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) ..done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xe)
(XEN) Freed 264kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) traps.c:2447:d0v0 HSR=0x93840047 pc=0xc08170e8 gva=0xc8800384
gpa=0x04


It looks like your guest received a data abort when trying to access the 
physical address 0x04.


I would recommend you to find who is trying to access this address. You 
can use addr2line with the PC to find the associated line code.


Regards,

--
Julien Grall

___

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

On Fri, May 20, 2016 at 12:59 PM, Jan Beulich  wrote:
 On 20.05.16 at 10:45,  wrote:
>> On Thu, May 19, 2016 at 5:36 PM, Jan Beulich  wrote:
>> On 19.05.16 at 15:58,  wrote:
 Case 1: Dom0 is driver domain:
 There is a Ducati firmware which runs on dedicated M4 core and decodes
 video. This firmware uses hardcoded physical addresses for graphics
 buffers. Those addresses should be inside address-space of the driver
 domain (Dom0). Ducati firmware is proprietary and we have no ability
 to rework it. So Dom0 kernel should be placed to the configured
 address (to the DOM0 RAM bank with specific address).

 Case 2: Dom0 is Thin and DomD is driver domain.
 All is the same: Ducati firmware requires special (hardcoded) addresses.
>>>
>>> For both of these cases I would then wonder whether such
>>> environments are actually suitable for doing virtualization on.
>> Currently we use Jacinto 6 evaluation board with DRA74X processor.
>> We have both configurations (Thin Dom0 and Thich Dom0).
>
> Which says nothing about their suitability for virtualization.
Our solution is based on Jacinto 6 evaluation board with DRA74X
processor. We need video-playback. Ducati firmware decodes video and
it works only with hardcoded addresses so we need this patch.

> Jan
>

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

Re: [Xen-devel] [PATCH 0/2] Support consistent reads of mapped vcpu_runstate_info

[Juergen Gross]

On 20/05/16 16:10, Julien Grall wrote:
> Hi Juergen,
> 
> On 20/05/16 14:22, Juergen Gross wrote:
>> A guest mapping vcpu_runstate_info into its memory can't read this
>> information from another cpu but the one the data is referring to.
>> Reason is there is no reliable way for the guest to detect a concurrent
>> data update by the hypervisor.
>>
>> This patch series adds an update flag to the mapped data which can be
>> used by the guest to detect an update is occurring. As this flag is
>> modifying the current interface it has to be activated by using a
>> vm_assist hypercall, which in turn has to be made available for ARM.
>>
>> Runtime tested on x86 with a modified Linux kernel using the new
>> feature.
>> Compile tested only for ARM.
> 
> I would like to give a go on ARM. Who it be possible to provide the
> patch for Linux and how to test it?

Sure. You'll need the four attached patches (to be applied on top of
kernel 4.6). With CONFIG_PARAVIRT_TIME_ACCOUNTING set in the kernel
config, full functionality will be used (without being set the runstate
info of other cpus won't be read).

You can verify the vm_assist hypercall has worked via "xl debug-keys q"
and "xl dmesg | grep vm_assist" (value should be 0020 on ARM).


Juergen

>From 689b4ba8c13be73ed51e485a7f7baea593d0ce6e Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Tue, 17 May 2016 14:03:02 +0200
Subject: [PATCH v4] xen: add steal_clock support on x86

The pv_time_ops structure contains a function pointer for the
"steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
uses its own mechanism to account for the "stolen" time a thread wasn't
able to run due to hypervisor scheduling.

Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen and remove the x86 Xen
hack.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
---
V4: minor adjustments as requested by Stefano Stabellini (remove
no longer needed #include, remove __init from header)
V3: add #include  to avoid build error on arm
V2: remove the x86 do_stolen_accounting() hack
---
 arch/arm/xen/enlighten.c| 18 ++
 arch/x86/xen/time.c | 44 ++--
 drivers/xen/time.c  | 20 
 include/linux/kernel_stat.h |  1 -
 include/xen/xen-ops.h   |  1 +
 kernel/sched/cputime.c  | 10 --
 6 files changed, 25 insertions(+), 69 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..71db30c 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -84,19 +83,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
 
-static unsigned long long xen_stolen_accounting(int cpu)
-{
-   struct vcpu_runstate_info state;
-
-   BUG_ON(cpu != smp_processor_id());
-
-   xen_get_runstate_snapshot();
-
-   WARN_ON(state.state != RUNSTATE_running);
-
-   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
-}
-
 static void xen_read_wallclock(struct timespec64 *ts)
 {
u32 version;
@@ -355,8 +341,8 @@ static int __init xen_guest_init(void)
 
register_cpu_notifier(_cpu_notifier);
 
-   pv_time_ops.steal_clock = xen_stolen_accounting;
-   static_key_slow_inc(_steal_enabled);
+   xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
 
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..6be31df 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -11,8 +11,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -31,44 +29,6 @@
 
 /* Xen may fire a timer up to this many ns early */
 #define TIMER_SLOP 10
-#define NS_PER_TICK(10LL / HZ)
-
-/* snapshots of runstate info */
-static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
-
-/* unused ns of stolen time */
-static DEFINE_PER_CPU(u64, xen_residual_stolen);
-
-static void do_stolen_accounting(void)
-{
-   struct vcpu_runstate_info state;
-   struct vcpu_runstate_info *snap;
-   s64 runnable, offline, stolen;
-   cputime_t ticks;
-
-   xen_get_runstate_snapshot();
-
-   WARN_ON(state.state != RUNSTATE_running);
-
-   snap = this_cpu_ptr(_runstate_snapshot);
-
-   /* work out how much time the VCPU has not been runn*ing*  */
-   runnable = state.time[RUNSTATE_runnable] - 
snap->time[RUNSTATE_runnable];
-   offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
-
-   *snap = state;
-
-   /* Add the appropriate number of ticks of stolen time,
-  including any left-overs from last time. */
-   stolen = 

Re: [Xen-devel] [PATCH 0/2] Support consistent reads of mapped vcpu_runstate_info

[Julien Grall]

Hi Juergen,

On 20/05/16 14:22, Juergen Gross wrote:

A guest mapping vcpu_runstate_info into its memory can't read this
information from another cpu but the one the data is referring to.
Reason is there is no reliable way for the guest to detect a concurrent
data update by the hypervisor.

This patch series adds an update flag to the mapped data which can be
used by the guest to detect an update is occurring. As this flag is
modifying the current interface it has to be activated by using a
vm_assist hypercall, which in turn has to be made available for ARM.

Runtime tested on x86 with a modified Linux kernel using the new
feature.
Compile tested only for ARM.


I would like to give a go on ARM. Who it be possible to provide the 
patch for Linux and how to test it?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall

[Julien Grall]

Hi Juergen,

On 20/05/16 14:22, Juergen Gross wrote:

Up to now the vm_assist hypercall hasn't been supported on ARM, as
there are only x86 specific features to switch. Add support of
vm_assist on ARM for future use.

Signed-off-by: Juergen Gross 


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

[Xen-devel] [PATCH qemu-traditional] ioreq: Support 32-bit default_ioport_* accesses

[Boris Ostrovsky]

Recent changes in ACPICA (specifically, Linux commit 66b1ed5aa8dd ("ACPICA:
ACPI 2.0, Hardware: Add access_width/bit_offset support for
acpi_hw_write()") result in guests issuing 32-bit accesses to IO space.

QEMU needs to be able to handle them.

Signed-off-by: Boris Ostrovsky 
---
 vl.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/vl.c b/vl.c
index c864e7d..79d3ab5 100644
--- a/vl.c
+++ b/vl.c
@@ -350,17 +350,18 @@ static void default_ioport_writew(void *opaque, uint32_t 
address, uint32_t data)
 
 static uint32_t default_ioport_readl(void *opaque, uint32_t address)
 {
-#ifdef DEBUG_UNUSED_IOPORT
-fprintf(stderr, "unused inl: port=0x%04x\n", address);
-#endif
-return 0x;
+uint32_t data;
+data = default_ioport_readw(opaque, address) & 0x;
+address = (address + 2) & (MAX_IOPORTS - 1);
+data |= default_ioport_readw(opaque, address) << 16;
+return data;
 }
 
 static void default_ioport_writel(void *opaque, uint32_t address, uint32_t 
data)
 {
-#ifdef DEBUG_UNUSED_IOPORT
-fprintf(stderr, "unused outl: port=0x%04x data=0x%02x\n", address, data);
-#endif
+default_ioport_writew(opaque, address, data & 0x);
+address = (address + 2) & (MAX_IOPORTS - 1);
+default_ioport_writew(opaque, address, data >> 16);
 }
 
 /* size is the word size in byte */
-- 
1.8.1.4


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

Re: [Xen-devel] [PATCH 2/2] xen: add update indicator to vcpu_runstate_info

[Andrew Cooper]

On 20/05/16 14:22, Juergen Gross wrote:
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 1365b4a..91f256b 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -239,10 +239,32 @@ static void ctxt_switch_to(struct vcpu *n)
>  /* Update per-VCPU guest runstate shared memory area (if registered). */
>  static void update_runstate_area(struct vcpu *v)
>  {
> +bool_t update_flag;
> +void __user *guest_handle = NULL;
> +unsigned off = 0;
> +
>  if ( guest_handle_is_null(runstate_guest(v)) )
>  return;
>  
> +update_flag = VM_ASSIST(v->domain, runstate_update_flag);
> +if ( update_flag )
> +{
> +off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;
> +guest_handle = v->runstate_guest.p;
> +guest_handle += off;
> +v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
> +__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
> +wmb();

smp_wmb(), throughout.

A whole lot of code gets this wrong in Xen, and plan to clean it all up
in 4.8

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] xen: add update indicator to vcpu_runstate_info

[Juergen Gross]

On 20/05/16 15:34, Andrew Cooper wrote:
> On 20/05/16 14:22, Juergen Gross wrote:
>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>> index 1365b4a..91f256b 100644
>> --- a/xen/arch/arm/domain.c
>> +++ b/xen/arch/arm/domain.c
>> @@ -239,10 +239,32 @@ static void ctxt_switch_to(struct vcpu *n)
>>  /* Update per-VCPU guest runstate shared memory area (if registered). */
>>  static void update_runstate_area(struct vcpu *v)
>>  {
>> +bool_t update_flag;
>> +void __user *guest_handle = NULL;
>> +unsigned off = 0;
>> +
>>  if ( guest_handle_is_null(runstate_guest(v)) )
>>  return;
>>  
>> +update_flag = VM_ASSIST(v->domain, runstate_update_flag);
>> +if ( update_flag )
>> +{
>> +off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;
>> +guest_handle = v->runstate_guest.p;
>> +guest_handle += off;
>> +v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
>> +__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
>> +wmb();
> 
> smp_wmb(), throughout.

Okay.


Juergen

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

[Xen-devel] [for-4.7 v2 1/2] xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary

[Julien Grall]

Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
Xen has been undoing the P2M mappings when an error occurred during
insertion or memory allocation.

The function apply_p2m_changes can work with region not-aligned to a
block size (2MB, 1G) or page size (4K). The mapping will be done by
splitting the region in a set of regions aligned to the size supported
by the page table.

The mapping of a region could fail when it is not possible to allocate
memory for an intermediate table (i.e a new or when shattering a block).

When the mapping is undone, the end of the region is computed using the
base address of the current region and the size of the failing level.
However the failing level may not be the leaf one, therefore unrelated
entries will be removed.

Fix it by removing the mapping from the start address up to the last
region that has been successfully mapped.

Signed-off-by: Julien Grall 
Reviewed-by: Wei Chen 
Reviewed-by: Stefano Stabellini 

---
This patch is a bug fix for Xen 4.7 and candidate for backporting
up to Xen 4.5. Without this patch, Xen may undo mapping which are
not part of the region mapped when memory allocation has failed.

Note that Xen 4.7 has code to remove empty translation table (see
commit de5162b "xen/arm: p2m: Remove translation table when it's
empty"), however with this patch those tables will not be removed
in case of failure. This will be fixed after the release as
the change will be too intrusive for Xen 4.7.

Changes in v2:
- Add Stefano's and Wei's reviewed-by
---
 xen/arch/arm/p2m.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index db21433..68c67b0 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1189,13 +1189,10 @@ out:
 {
 BUG_ON(addr == end_gpaddr);
 /*
- * addr keeps the address of the last successfully-inserted mapping,
- * while apply_p2m_changes() considers an address range which is
- * exclusive of end_gpaddr: add level_size to addr to obtain the
- * right end of the range
+ * addr keeps the address of the end of the last successfully-inserted
+ * mapping.
  */
-apply_p2m_changes(d, REMOVE,
-  start_gpaddr, addr + level_sizes[level], orig_maddr,
+apply_p2m_changes(d, REMOVE, start_gpaddr, addr, orig_maddr,
   mattr, 0, p2m_invalid, d->arch.p2m.default_access);
 }
 
-- 
1.9.1


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

[Xen-devel] [for-4.7 v2 0/2] xen/arm: Bug fixes in the P2M code

[Julien Grall]

Hello,

This small series fixes potential deadlock and the removal of unrelated
mapping when the P2M code fails to insert/allocate mappings.

This series contains bug fix for Xen 4.7 and candidate for backporting
up to Xen 4.5.

Yours sincerely,

Release-acked-by: Wei Liu 

Julien Grall (2):
  xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary
  xen/arm: p2m: Release the p2m lock before undoing the mappings

 xen/arch/arm/p2m.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

-- 
1.9.1


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

[Xen-devel] [for-4.7 v2 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings

[Julien Grall]

Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
Xen has been undoing the P2M mappings when an error occurred during
insertion or memory allocation.

This is done by calling recursively apply_p2m_changes, however the
second call is done with the p2m lock taken which will result in a
deadlock for the current processor.

The p2m lock is here to protect 2 threads modifying concurrently the
page tables. However, it does not guarantee the ordering of the
changes. I.e if 2 threads request change on regions that overlaps,
then the result is undefined.

Therefore it is fine to move the recursive call to undo the changes
after the lock is released.

Signed-off-by: Julien Grall 
Reviewed-by: Wei Chen 
Tested-by: Wei Chen 

---
I think we could unlock the p2m lock before freeing the temporary
mapping. Although, I played safe as this is a bug fix for Xen 4.7
and to be backported up to Xen 4.5.

Changes in v2:
- Update the commit message to explain why unlocking before
the recursive call is fine.
- Add Wei Chen's reviewed-by and tested-by
---
 xen/arch/arm/p2m.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 68c67b0..838d004 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1184,6 +1184,14 @@ out:
 while ( (pg = page_list_remove_head(_pages)) )
 free_domheap_page(pg);
 
+for ( level = P2M_ROOT_LEVEL; level < 4; level ++ )
+{
+if ( mappings[level] )
+unmap_domain_page(mappings[level]);
+}
+
+spin_unlock(>lock);
+
 if ( rc < 0 && ( op == INSERT || op == ALLOCATE ) &&
  addr != start_gpaddr )
 {
@@ -1196,14 +1204,6 @@ out:
   mattr, 0, p2m_invalid, d->arch.p2m.default_access);
 }
 
-for ( level = P2M_ROOT_LEVEL; level < 4; level ++ )
-{
-if ( mappings[level] )
-unmap_domain_page(mappings[level]);
-}
-
-spin_unlock(>lock);
-
 return rc;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH 1/2] xen/arm: add support for vm_assist hypercall

[Juergen Gross]

Up to now the vm_assist hypercall hasn't been supported on ARM, as
there are only x86 specific features to switch. Add support of
vm_assist on ARM for future use.

Signed-off-by: Juergen Gross 
---
 xen/arch/arm/traps.c | 1 +
 xen/common/domain.c  | 2 --
 xen/common/kernel.c  | 2 --
 xen/include/asm-arm/config.h | 2 ++
 4 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1828ea1..ccc6351 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1284,6 +1284,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 HYPERCALL(multicall, 2),
 HYPERCALL(platform_op, 1),
 HYPERCALL_ARM(vcpu_op, 3),
+HYPERCALL(vm_assist, 2),
 };
 
 #ifndef NDEBUG
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 45273d4..0afb1ee 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1408,7 +1408,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 return rc;
 }
 
-#ifdef VM_ASSIST_VALID
 long vm_assist(struct domain *p, unsigned int cmd, unsigned int type,
unsigned long valid)
 {
@@ -1427,7 +1426,6 @@ long vm_assist(struct domain *p, unsigned int cmd, 
unsigned int type,
 
 return -ENOSYS;
 }
-#endif
 
 struct pirq *pirq_get_info(struct domain *d, int pirq)
 {
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 1a6823a..74b6e1f 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -441,12 +441,10 @@ DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 return rc;
 }
 
-#ifdef VM_ASSIST_VALID
 DO(vm_assist)(unsigned int cmd, unsigned int type)
 {
 return vm_assist(current->domain, cmd, type, VM_ASSIST_VALID);
 }
-#endif
 
 DO(ni_hypercall)(void)
 {
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 2d11b62..563f49b 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -199,6 +199,8 @@ extern unsigned long frametable_virt_end;
 #define watchdog_disable() ((void)0)
 #define watchdog_enable()  ((void)0)
 
+#define VM_ASSIST_VALID  (0)
+
 #endif /* __ARM_CONFIG_H__ */
 /*
  * Local variables:
-- 
2.6.6


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

[Xen-devel] [PATCH 0/2] Support consistent reads of mapped vcpu_runstate_info

[Juergen Gross]

A guest mapping vcpu_runstate_info into its memory can't read this
information from another cpu but the one the data is referring to.
Reason is there is no reliable way for the guest to detect a concurrent
data update by the hypervisor.

This patch series adds an update flag to the mapped data which can be
used by the guest to detect an update is occurring. As this flag is
modifying the current interface it has to be activated by using a
vm_assist hypercall, which in turn has to be made available for ARM.

Runtime tested on x86 with a modified Linux kernel using the new
feature.
Compile tested only for ARM.

Juergen Gross (2):
  xen/arm: add support for vm_assist hypercall
  xen: add update indicator to vcpu_runstate_info

 xen/arch/arm/domain.c| 22 ++
 xen/arch/arm/traps.c |  1 +
 xen/arch/x86/domain.c| 31 +++
 xen/common/domain.c  |  2 --
 xen/common/kernel.c  |  2 --
 xen/include/asm-arm/config.h |  2 ++
 xen/include/asm-x86/config.h |  1 +
 xen/include/public/vcpu.h|  6 ++
 xen/include/public/xen.h |  7 +++
 9 files changed, 70 insertions(+), 4 deletions(-)

-- 
2.6.6


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

[Xen-devel] [PATCH 2/2] xen: add update indicator to vcpu_runstate_info

[Juergen Gross]

In order to support reading another vcpu's mapped vcpu_runstate_info
an indicator for an occurring update of the runstate information is
needed.

Add the possibility to activate setting this indicator in the highest
bit of state_entry_time via a vm_assist hypercall. When activated the
update indicator will be set before the runstate information is
modified in guest memory and it will be reset after modification is
done. As state_entry_time is guaranteed to be different after each
update the guest can detect any update (either in progress or while
reading the runstate data) by comparing state_entry_time before and
after reading runstate data: in case the values differ or the update
indicator was set the data might be inconsistent and should be reread.

Signed-off-by: Juergen Gross 
---
 xen/arch/arm/domain.c| 22 ++
 xen/arch/x86/domain.c| 31 +++
 xen/include/asm-arm/config.h |  2 +-
 xen/include/asm-x86/config.h |  1 +
 xen/include/public/vcpu.h|  6 ++
 xen/include/public/xen.h |  7 +++
 6 files changed, 68 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1365b4a..91f256b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -239,10 +239,32 @@ static void ctxt_switch_to(struct vcpu *n)
 /* Update per-VCPU guest runstate shared memory area (if registered). */
 static void update_runstate_area(struct vcpu *v)
 {
+bool_t update_flag;
+void __user *guest_handle = NULL;
+unsigned off = 0;
+
 if ( guest_handle_is_null(runstate_guest(v)) )
 return;
 
+update_flag = VM_ASSIST(v->domain, runstate_update_flag);
+if ( update_flag )
+{
+off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;
+guest_handle = v->runstate_guest.p;
+guest_handle += off;
+v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
+__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
+wmb();
+}
+
 __copy_to_guest(runstate_guest(v), >runstate, 1);
+
+if ( update_flag )
+{
+v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+wmb();
+__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
+}
 }
 
 static void schedule_tail(struct vcpu *prev)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 5af2cc5..dfaee5d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1925,13 +1925,37 @@ static void paravirt_ctxt_switch_to(struct vcpu *v)
 bool_t update_runstate_area(struct vcpu *v)
 {
 bool_t rc;
+bool_t update_flag;
 smap_check_policy_t smap_policy;
+void __user *guest_handle = NULL;
+unsigned off = 0;
 
 if ( guest_handle_is_null(runstate_guest(v)) )
 return 1;
 
+update_flag = VM_ASSIST(v->domain, runstate_update_flag);
+
 smap_policy = smap_policy_change(v, SMAP_CHECK_ENABLED);
 
+if ( update_flag )
+{
+off = offsetof(struct vcpu_runstate_info, state_entry_time) + 7;
+if ( has_32bit_shinfo(v->domain) )
+{
+guest_handle = v->runstate_guest.compat.p;
+guest_handle += offsetof(struct compat_vcpu_runstate_info,
+ state_entry_time) + 7;
+}
+else
+{
+guest_handle = v->runstate_guest.native.p;
+guest_handle += off;
+}
+v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
+__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
+wmb();
+}
+
 if ( has_32bit_shinfo(v->domain) )
 {
 struct compat_vcpu_runstate_info info;
@@ -1944,6 +1968,13 @@ bool_t update_runstate_area(struct vcpu *v)
 rc = __copy_to_guest(runstate_guest(v), >runstate, 1) !=
  sizeof(v->runstate);
 
+if ( update_flag )
+{
+v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+wmb();
+__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
+}
+
 smap_policy_change(v, smap_policy);
 
 return rc;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 563f49b..ce3edc2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -199,7 +199,7 @@ extern unsigned long frametable_virt_end;
 #define watchdog_disable() ((void)0)
 #define watchdog_enable()  ((void)0)
 
-#define VM_ASSIST_VALID  (0)
+#define VM_ASSIST_VALID  (1UL << VMASST_TYPE_runstate_update_flag)
 
 #endif /* __ARM_CONFIG_H__ */
 /*
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index c10129d..6fd84e7 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -332,6 +332,7 @@ extern unsigned long xen_phys_start;
   (1UL << VMASST_TYPE_writable_pagetables) | \
   (1UL << VMASST_TYPE_pae_extended_cr3)| \
  

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

[Juergen Gross]

On 18/05/16 18:14, Juergen Gross wrote:
> On 18/05/16 18:09, Tony S wrote:
>> On Wed, May 18, 2016 at 8:57 AM, Dario Faggioli
>>  wrote:
>>> On Wed, 2016-05-18 at 14:24 +0200, Juergen Gross wrote:
 On 17/05/16 11:33, George Dunlap wrote:
>> Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting
>> process
>> times. KVM uses it but Xen doesn't.
> Is someone on the Linux side going to put this on their to-do list
> then? :-)

 Patch sent.

>>> Yep, seen it, thanks.
>>>
 Support was already existing for arm.

>>> Yes!! I remember Stefano talking about introducing it, and that was
>>> also why I thought we had it already since long time on x86.
>>>
>>> Well, anyway... :-)
>>>
 What is missing is support for
 paravirt_steal_rq_enabled which requires to be able to read the
 stolen
 time of another cpu. This can't work today as accessing another cpu's
 vcpu_runstate_info isn't possible without risking inconsistent data.
 I plan to add support for this, too, but this will require adding
 another hypercall to map a modified vcpu_runstate_info containing an
 indicator for an ongoing update of the data.

>>> Understood.
>>>
>>> So, Tony, up for trying again your workload with this patch applied to
>>> Linux?
>>>
>>> Most likely, it _won't_ fix all the problems you're seeing, but I'm
>>> curious to see if it helps.
>>
>> Hi Dario,
>>
>> I did not see the patch. Can you please send me the patch and I will
>> try to test it later.
> 
> Here is an updated version.

Tony, would you be interested to test a complete solution?

This would require to use a Xen 4.7 hypervisor with some patches applied
and some patches for the Linux kernel (I've done some basic tests with
kernel 4.6). I've attached the patches in case you want to try them. :-)
You should set CONFIG_PARAVIRT_TIME_ACCOUNTING=y in the kernel .config


Juergen

From 689b4ba8c13be73ed51e485a7f7baea593d0ce6e Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Tue, 17 May 2016 14:03:02 +0200
Subject: [PATCH v4] xen: add steal_clock support on x86

The pv_time_ops structure contains a function pointer for the
"steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
uses its own mechanism to account for the "stolen" time a thread wasn't
able to run due to hypervisor scheduling.

Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen and remove the x86 Xen
hack.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
---
V4: minor adjustments as requested by Stefano Stabellini (remove
no longer needed #include, remove __init from header)
V3: add #include  to avoid build error on arm
V2: remove the x86 do_stolen_accounting() hack
---
 arch/arm/xen/enlighten.c| 18 ++
 arch/x86/xen/time.c | 44 ++--
 drivers/xen/time.c  | 20 
 include/linux/kernel_stat.h |  1 -
 include/xen/xen-ops.h   |  1 +
 kernel/sched/cputime.c  | 10 --
 6 files changed, 25 insertions(+), 69 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..71db30c 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -84,19 +83,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
 }
 EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
 
-static unsigned long long xen_stolen_accounting(int cpu)
-{
-   struct vcpu_runstate_info state;
-
-   BUG_ON(cpu != smp_processor_id());
-
-   xen_get_runstate_snapshot();
-
-   WARN_ON(state.state != RUNSTATE_running);
-
-   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
-}
-
 static void xen_read_wallclock(struct timespec64 *ts)
 {
u32 version;
@@ -355,8 +341,8 @@ static int __init xen_guest_init(void)
 
register_cpu_notifier(_cpu_notifier);
 
-   pv_time_ops.steal_clock = xen_stolen_accounting;
-   static_key_slow_inc(_steal_enabled);
+   xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
 
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..6be31df 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -11,8 +11,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -31,44 +29,6 @@
 
 /* Xen may fire a timer up to this many ns early */
 #define TIMER_SLOP 10
-#define NS_PER_TICK(10LL / HZ)
-
-/* snapshots of runstate info */
-static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
-
-/* unused ns of stolen time */
-static DEFINE_PER_CPU(u64, xen_residual_stolen);
-
-static void 

Re: [Xen-devel] netif.h clarifications

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 20 May 2016 13:34
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Wei Liu; David Vrabel
> Subject: Re: netif.h clarifications
> 
> On Fri, May 20, 2016 at 12:55:16PM +0100, Paul Durrant wrote:
> > > -Original Message-
> > [snip]
> > > > > And then I've also seen some issues with TSO/LRO (GSO in Linux
> > > > > terminology)
> > > > > when using packet forwarding inside of a FreeBSD DomU. For
> example in
> > > the
> > > > > following scenario:
> > > > >
> > > > >+
> > > > >|
> > > > >+-+   ++   +--+
> > > > >| |A B|   router   |C D|  |
> > > > >| Guest 1 +---+ +  +---+ Guest 2  |
> > > > >| |  bridge0  | |  |  bridge1  |  |
> > > > >+-+   ++   +--+
> > > > >172.16.1.67  172.16.1.66|   10.0.1.1   10.0.1.2
> > > > >|
> > > > >  +->
> > > > >   ssh 10.0.1.2 |
> > > > >|
> > > > >|
> > > > >|
> > > > >+
> > > > >
> > > > > All those VMs are inside of the same host, and one of them acts as a
> > > gateway
> > > > > between them because they are on two different subnets. In this
> case
> > > I'm
> > > > > seeing issues because even though I disable TSO/LRO on the "router"
> at
> > > > > runtime, the backend doesn't watch the xenstore feature flag, and
> never
> > > > > disables it from the vif on the Dom0 bridge. This causes LRO packets
> > > > > (non-fragmented) to be received at point 'C', and then when the
> > > gateway
> > > > > tries to inject them into the other NIC it fails because the size is
> greater
> > > > > than the MTU, and the "no fragment" bit is set.
> > > > >
> > > >
> > > > Yes, GSO cannot be disabled/enabled dynamically on the netback tx
> side
> > > (i.e. guest rx side) so you can't turn it off. The Windows PV driver 
> > > leave sit
> on
> > > all the time and does the fragmentation itself if the stack doesn't want
> GRO.
> > > Doing the fragmentation in the frontend makes more sense anyway since
> > > the cpu cycles are burned by the VM rather than dom0 and so it scales
> > > better.
> > >
> > > The weird thing is that GSO can usually be dinamically enabled/disabled
> on
> > > all network cards, so it would make sense to allow netfront to do the
> same.
> > > I guess the only way is to reset the netfront/netback connection when
> > > changing this property.
> >
> > Or implement GSO fragmentation in netfront, as I did for Windows.
> >
> > >
> > > > > How does Linux deal with this situation? Does it simply ignore the no
> > > > > fragment flag and fragments the packet? Does it simply inject the
> packet
> > > to
> > > > > the other end ignoring the MTU and propagating the GSO flag?
> > > > >
> > > >
> > > > I've not looked at the netfront rx code but I assume that the large
> packet
> > > that is passed from netback is just marked as GSO and makes its way to
> > > wherever it's going (being fragmented by the stack if it's forwarded to an
> > > interface that doesn't have the TSO flag set).
> > >
> > > But it cannot be fragmented if it has the IP "don't fragment" flag set.
> > >
> >
> > Huh? This is GSO we're talking about here, not IP fragmentation. They are
> not the same thing.
> 
> Well, as I understand it GSO works by offloading the fragmentation to the
> NIC, so the NIC performs the TCP/IP fragmentation itself. In which case I
> think it's relevant, because if you receive a 64KB GSO packet with the
> "don't fragment" IP flags set, you should not fragment it AFAIK, even if
> it's a GSO packet.

I don't believe that is the case. The DF bit is not relevant because you are 
not fragmenting an IP packet, you are taking a large TCP segment and splitting 
it into MSS sized segments.

> 
> I think this is all caused because there's no real media here, it's all
> bridges and virtual network interfaces on the same host. The bridge has no
> real MTU, but on the real world the packet would be fragmented the
> moment it
> hits the wire.
> 

Yes. MTU is not really relevant until a bit of wire gets involved.

> OTOH, when using the PV net protocol we are basically passing mbufs (or
> skbs
> in Linux world) around, so is it expected that the fragmentation is going to
> be performed when the packet is put on a real wire that has a real MTU, so
> the last entity that touches it must do the fragmentation?
> 

Let's call it 'segmentation' to avoid getting confused again... Yes, if 
something along the path does not know about large TCP 

Re: [Xen-devel] netif.h clarifications

[Roger Pau Monne]

On Fri, May 20, 2016 at 12:55:16PM +0100, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > > > And then I've also seen some issues with TSO/LRO (GSO in Linux
> > > > terminology)
> > > > when using packet forwarding inside of a FreeBSD DomU. For example in
> > the
> > > > following scenario:
> > > >
> > > >+
> > > >|
> > > >+-+   ++   +--+
> > > >| |A B|   router   |C D|  |
> > > >| Guest 1 +---+ +  +---+ Guest 2  |
> > > >| |  bridge0  | |  |  bridge1  |  |
> > > >+-+   ++   +--+
> > > >172.16.1.67  172.16.1.66|   10.0.1.1   10.0.1.2
> > > >|
> > > >  +->
> > > >   ssh 10.0.1.2 |
> > > >|
> > > >|
> > > >|
> > > >+
> > > >
> > > > All those VMs are inside of the same host, and one of them acts as a
> > gateway
> > > > between them because they are on two different subnets. In this case
> > I'm
> > > > seeing issues because even though I disable TSO/LRO on the "router" at
> > > > runtime, the backend doesn't watch the xenstore feature flag, and never
> > > > disables it from the vif on the Dom0 bridge. This causes LRO packets
> > > > (non-fragmented) to be received at point 'C', and then when the
> > gateway
> > > > tries to inject them into the other NIC it fails because the size is 
> > > > greater
> > > > than the MTU, and the "no fragment" bit is set.
> > > >
> > >
> > > Yes, GSO cannot be disabled/enabled dynamically on the netback tx side
> > (i.e. guest rx side) so you can't turn it off. The Windows PV driver leave 
> > sit on
> > all the time and does the fragmentation itself if the stack doesn't want 
> > GRO.
> > Doing the fragmentation in the frontend makes more sense anyway since
> > the cpu cycles are burned by the VM rather than dom0 and so it scales
> > better.
> > 
> > The weird thing is that GSO can usually be dinamically enabled/disabled on
> > all network cards, so it would make sense to allow netfront to do the same.
> > I guess the only way is to reset the netfront/netback connection when
> > changing this property.
> 
> Or implement GSO fragmentation in netfront, as I did for Windows.
>
> > 
> > > > How does Linux deal with this situation? Does it simply ignore the no
> > > > fragment flag and fragments the packet? Does it simply inject the packet
> > to
> > > > the other end ignoring the MTU and propagating the GSO flag?
> > > >
> > >
> > > I've not looked at the netfront rx code but I assume that the large packet
> > that is passed from netback is just marked as GSO and makes its way to
> > wherever it's going (being fragmented by the stack if it's forwarded to an
> > interface that doesn't have the TSO flag set).
> > 
> > But it cannot be fragmented if it has the IP "don't fragment" flag set.
> > 
> 
> Huh? This is GSO we're talking about here, not IP fragmentation. They are not 
> the same thing.

Well, as I understand it GSO works by offloading the fragmentation to the 
NIC, so the NIC performs the TCP/IP fragmentation itself. In which case I 
think it's relevant, because if you receive a 64KB GSO packet with the 
"don't fragment" IP flags set, you should not fragment it AFAIK, even if 
it's a GSO packet.

I think this is all caused because there's no real media here, it's all 
bridges and virtual network interfaces on the same host. The bridge has no 
real MTU, but on the real world the packet would be fragmented the moment it 
hits the wire.

OTOH, when using the PV net protocol we are basically passing mbufs (or skbs 
in Linux world) around, so is it expected that the fragmentation is going to 
be performed when the packet is put on a real wire that has a real MTU, so 
the last entity that touches it must do the fragmentation?

IMHO, this apporach seems very dangerous, and we are breaking the end-to-end 
principle.

> > What I'm seeing here is that at point C netback passes GSO packets to the
> > "router" VM, this packets have not been fragmented, and then when the
> > router
> > VM tries to forward them to point B it has to issue a "need fragmentation"
> > icmp message because the MTU of the interface is 1500 and the IP header
> > has
> > the "don't fragment" set (and of course the GSO chain is bigger than 1500).
> > 
> 
> That's presumably because they've lost the GSO information somewhere (i.e. 
> the flag saying it's GSO and the MSS).

AFAICT, I'm correctly passing the GSO information around.

> > Is Linux ignoring the "don't fragment" IP flag here and simply fragmenting
> > it?
> 
> Yes. As 

[Xen-devel] [qemu-upstream-4.3-testing test] 94604: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  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-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  103 days
Testing same since93977  2016-05-10 11:09:16 Z   10 days   28 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [PATCH v4] xen: add steal_clock support on x86

[Stefano Stabellini]

On Fri, 20 May 2016, Juergen Gross wrote:
> The pv_time_ops structure contains a function pointer for the
> "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> uses its own mechanism to account for the "stolen" time a thread wasn't
> able to run due to hypervisor scheduling.
> 
> Add support in Xen arch independent time handling for this feature by
> moving it out of the arm arch into drivers/xen and remove the x86 Xen
> hack.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Boris Ostrovsky 

Reviewed-by: Stefano Stabellini 


> V4: minor adjustments as requested by Stefano Stabellini (remove
> no longer needed #include, remove __init from header)
> V3: add #include  to avoid build error on arm
> V2: remove the x86 do_stolen_accounting() hack
> ---
>  arch/arm/xen/enlighten.c| 18 ++
>  arch/x86/xen/time.c | 44 ++--
>  drivers/xen/time.c  | 20 
>  include/linux/kernel_stat.h |  1 -
>  include/xen/xen-ops.h   |  1 +
>  kernel/sched/cputime.c  | 10 --
>  6 files changed, 25 insertions(+), 69 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 75cd734..71db30c 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -84,19 +83,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
>  }
>  EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
>  
> -static unsigned long long xen_stolen_accounting(int cpu)
> -{
> - struct vcpu_runstate_info state;
> -
> - BUG_ON(cpu != smp_processor_id());
> -
> - xen_get_runstate_snapshot();
> -
> - WARN_ON(state.state != RUNSTATE_running);
> -
> - return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> -}
> -
>  static void xen_read_wallclock(struct timespec64 *ts)
>  {
>   u32 version;
> @@ -355,8 +341,8 @@ static int __init xen_guest_init(void)
>  
>   register_cpu_notifier(_cpu_notifier);
>  
> - pv_time_ops.steal_clock = xen_stolen_accounting;
> - static_key_slow_inc(_steal_enabled);
> + xen_time_setup_guest();
> +
>   if (xen_initial_domain())
>   pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
>  
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index a0a4e55..6be31df 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -11,8 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -31,44 +29,6 @@
>  
>  /* Xen may fire a timer up to this many ns early */
>  #define TIMER_SLOP   10
> -#define NS_PER_TICK  (10LL / HZ)
> -
> -/* snapshots of runstate info */
> -static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
> -
> -/* unused ns of stolen time */
> -static DEFINE_PER_CPU(u64, xen_residual_stolen);
> -
> -static void do_stolen_accounting(void)
> -{
> - struct vcpu_runstate_info state;
> - struct vcpu_runstate_info *snap;
> - s64 runnable, offline, stolen;
> - cputime_t ticks;
> -
> - xen_get_runstate_snapshot();
> -
> - WARN_ON(state.state != RUNSTATE_running);
> -
> - snap = this_cpu_ptr(_runstate_snapshot);
> -
> - /* work out how much time the VCPU has not been runn*ing*  */
> - runnable = state.time[RUNSTATE_runnable] - 
> snap->time[RUNSTATE_runnable];
> - offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
> -
> - *snap = state;
> -
> - /* Add the appropriate number of ticks of stolen time,
> -including any left-overs from last time. */
> - stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
> -
> - if (stolen < 0)
> - stolen = 0;
> -
> - ticks = iter_div_u64_rem(stolen, NS_PER_TICK, );
> - __this_cpu_write(xen_residual_stolen, stolen);
> - account_steal_ticks(ticks);
> -}
>  
>  /* Get the TSC speed from Xen */
>  static unsigned long xen_tsc_khz(void)
> @@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void 
> *dev_id)
>   ret = IRQ_HANDLED;
>   }
>  
> - do_stolen_accounting();
> -
>   return ret;
>  }
>  
> @@ -431,6 +389,8 @@ static void __init xen_time_init(void)
>   xen_setup_timer(cpu);
>   xen_setup_cpu_clockevents();
>  
> + xen_time_setup_guest();
> +
>   if (xen_initial_domain())
>   pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
>  }
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index 7107842..2257b66 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -75,6 +76,15 @@ bool xen_vcpu_stolen(int vcpu)
>   return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
>  

Re: [Xen-devel] netif.h clarifications

[Paul Durrant]

> -Original Message-
[snip]
> > > And then I've also seen some issues with TSO/LRO (GSO in Linux
> > > terminology)
> > > when using packet forwarding inside of a FreeBSD DomU. For example in
> the
> > > following scenario:
> > >
> > >+
> > >|
> > >+-+   ++   +--+
> > >| |A B|   router   |C D|  |
> > >| Guest 1 +---+ +  +---+ Guest 2  |
> > >| |  bridge0  | |  |  bridge1  |  |
> > >+-+   ++   +--+
> > >172.16.1.67  172.16.1.66|   10.0.1.1   10.0.1.2
> > >|
> > >  +->
> > >   ssh 10.0.1.2 |
> > >|
> > >|
> > >|
> > >+
> > >
> > > All those VMs are inside of the same host, and one of them acts as a
> gateway
> > > between them because they are on two different subnets. In this case
> I'm
> > > seeing issues because even though I disable TSO/LRO on the "router" at
> > > runtime, the backend doesn't watch the xenstore feature flag, and never
> > > disables it from the vif on the Dom0 bridge. This causes LRO packets
> > > (non-fragmented) to be received at point 'C', and then when the
> gateway
> > > tries to inject them into the other NIC it fails because the size is 
> > > greater
> > > than the MTU, and the "no fragment" bit is set.
> > >
> >
> > Yes, GSO cannot be disabled/enabled dynamically on the netback tx side
> (i.e. guest rx side) so you can't turn it off. The Windows PV driver leave 
> sit on
> all the time and does the fragmentation itself if the stack doesn't want GRO.
> Doing the fragmentation in the frontend makes more sense anyway since
> the cpu cycles are burned by the VM rather than dom0 and so it scales
> better.
> 
> The weird thing is that GSO can usually be dinamically enabled/disabled on
> all network cards, so it would make sense to allow netfront to do the same.
> I guess the only way is to reset the netfront/netback connection when
> changing this property.

Or implement GSO fragmentation in netfront, as I did for Windows.

> 
> > > How does Linux deal with this situation? Does it simply ignore the no
> > > fragment flag and fragments the packet? Does it simply inject the packet
> to
> > > the other end ignoring the MTU and propagating the GSO flag?
> > >
> >
> > I've not looked at the netfront rx code but I assume that the large packet
> that is passed from netback is just marked as GSO and makes its way to
> wherever it's going (being fragmented by the stack if it's forwarded to an
> interface that doesn't have the TSO flag set).
> 
> But it cannot be fragmented if it has the IP "don't fragment" flag set.
> 

Huh? This is GSO we're talking about here, not IP fragmentation. They are not 
the same thing.

> What I'm seeing here is that at point C netback passes GSO packets to the
> "router" VM, this packets have not been fragmented, and then when the
> router
> VM tries to forward them to point B it has to issue a "need fragmentation"
> icmp message because the MTU of the interface is 1500 and the IP header
> has
> the "don't fragment" set (and of course the GSO chain is bigger than 1500).
> 

That's presumably because they've lost the GSO information somewhere (i.e. the 
flag saying it's GSO and the MSS).

> Is Linux ignoring the "don't fragment" IP flag here and simply fragmenting
> it?

Yes. As I said GSO != IP fragmentation; the DF bit has no bearing on it. You do 
need the GSO information though.

  Paul

> Because AFAICT I don't see any option in Linux netfront to prevent
> advertising "feature-gso-tcpv4", so netback will always inject GSO packets
> on the netfront RX path if possible.
> 
> Roger.

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

Re: [Xen-devel] netif.h clarifications

[Roger Pau Monne]

On Fri, May 20, 2016 at 10:09:43AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: 19 May 2016 17:28
> > To: xen-de...@lists.xenproject.org
> > Cc: Wei Liu; David Vrabel; Paul Durrant
> > Subject: netif.h clarifications
> > 
> > Hello,
> > 
> > While trying to solve a FreeBSD netfront bug [0] I came across a couple
> > of netif.h dark spots that I think should be documented in the netif.h
> > header. I'm willing to make those changes, but I want to make sure my
> > understanding is right.
> > 
> > Regarding checksum offloading, I had a hard time figuring out what the
> > different flags actually mean:
> > 
> > /* Packet data has been validated against protocol checksum. */
> > #define _NETRXF_data_validated (0)
> > #define  NETRXF_data_validated (1U<<_NETRXF_data_validated)
> > 
> > /* Protocol checksum field is blank in the packet (hardware offload)? */
> > #define _NETRXF_csum_blank (1)
> > #define  NETRXF_csum_blank (1U<<_NETRXF_csum_blank)
> > 
> > (Same applies to the TX flags, I'm not copying them there because they are
> > the same)
> > 
> > First of all, I assume "protocol" here refers to Layer 3 and Layer 4
> > protocol, so that would be IP and TCP/UDP/SCTP checksum offloading? In
> > any
> > case this needs clarification and proper wording.
> > 
> > Then, I have some questions regarding the meaning of the flags themselves
> > and the content of the checksum field in all the possible scenarios.
> > 
> > On RX path:
> > 
> >  - NETRXF_data_validated only: data has been validated, but what's the state
> >of the checksum field itself? If the data is validated again, would it
> >match against the checksum?
> >  - NETRXF_csum_blank only: I don't think this makes much sense, data is in
> >unknown state and checksum is not present, so there's no way to validate
> >it. Packet should be dropped?
> 
> Yes, in practice it's not used on its own. As you say, I don't think it makes 
> any sense.
> 
> >  - NETRXF_data_validated | NETRXF_csum_blank: this combination seems to
> > be
> >the one that makes more sense to me, data is valid, but checksum is not
> >there. This matches what some real NICs already do, that is to provide
> >the result of the checksum check _without_ actually providing the
> >checksum itself on the RX path.
> > 
> 
> In Linux netback this is set if the checksum info is partial, which I take to 
> mean that the packet has a valid pseudo-header checksum. I think packets 
> coming from NICs are more likely to be 'checksum unnecessary' which results 
> in NETRXF_data_validated only, which I take to mean that the checksum has 
> been verified but may have been trashed in the process.

Hm, if the checksum might have been trashed, I think NETRXF_csum_blank 
should be there, in the absence of NETRXF_csum_blank I would like to assume 
that the checksum is there and hasn't been trashed.

> 
> > On TX path:
> > 
> >  - NETTXF_data_validated only: I don't think this makes any sense, data is
> >always valid from the senders point of view.
> >  - NETTXF_csum_blank only: checksum calculation offload, it should be
> >performed by the other end.
> >  - NETTXF_data_validated | NETTXF_csum_blank: again, I don't think it makes
> >much sense, data is always valid from the senders point of view, or else
> >why bother sending it?
> > 
> 
> In Linux netback, the code goes:
> 
>   if (txp->flags & XEN_NETTXF_csum_blank)
>   skb->ip_summed = CHECKSUM_PARTIAL;
>   else if (txp->flags & XEN_NETTXF_data_validated)
>   skb->ip_summed = CHECKSUM_UNNECESSARY;
> 
> So, csum_blank with or without data_validated means that it's assumed that 
> the packet contains a valid pseudo-header checksum, but if csum_blank is not 
> set then data_validated means that the data is good but the checksum is in an 
> unknown state which is ok if the packet is then forwarded to another vif, and 
> I assume 'unnecessary' is ignored by NIC drivers on their TX side (I guess 
> they would only be interesting in 'partial').

OK, csum_blank means there's a pseudo-header, and data_validated means 
there's no checksum at all? Sorry, this is all very confusing.

> > So it looks to me like we could get away with just two flags, one on the RX
> > side that signals that the packet doesn't have a checksum but that the
> > checksum validation has already been performed, and another one on the TX
> > side to signal that the packet doesn't have a calculated checksum
> > (typical checksum offload).
> > 
> 
> On the TX side it would be useful to have flags which indicate:
> 
> - Full checksum present
> - Pseudo-header checksum present
> - State of checksum is unknown
> 
> On the RX side it would be useful to have
> 
> - Data validated, checksum state unknown
> - Data validated, checksum correct
> - Data not validated

+1 clearly.

> > And then I've also seen some 

Re: [Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, May 20, 2016 6:27 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; konrad.w...@oracle.com; k...@xen.org
> Subject: Re: [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu
> blocking list
> 
> >>> On 20.05.16 at 10:53,  wrote:
> > I still have two opens, which needs comments/suggestions from you guys.
> > - What should we do for the per-cpu blocking list during vcpu hotplug?
> 
> What do you mean with vcpu hotplug? vcpus never get removed
> from a VM (from hypervisor perspective), and all the guest may
> ever use need to be created before the guest starts.

Thanks for the reply, Jan. First of all, I am not familiar with vcpu 
hotplug/pcup hotplug,
and that is why I list them as two opens here. When I wrote "vcpu hotplug", I 
was planning
to refer to the following case:
1. use 'xl vcpu-set ${dom_id} ${vcpu_num}', where ${vcpu_num} is less than the 
current
online vcpus.
2. In the guest, use ' echo 1 > /sys/devices/system/cpu/cpuX/online ' to make 
the vcpus
offline.

Yes, I know the maximum vcpus are allocated for the guest, but I am not quite 
sure
whether the above operations will affect the blocking list. If you can 
elaborate a bit
more what hypervisor will do for the above operations, That should be very 
helpful.
such as, will the vcpu's state be changed, etc? And if the vcpu is current in 
blocking
state, while try to offline it, it will still remain in the blocking list, 
right, will this cause
some problems? 

> 
> > - What should we do for the per-cpu blocking list during pcpu hotplug?
> 
> I think it would help if you said what issue you see.

I didn't see any issues related to this, this open just comes out in my mind 
when I wrote
this patch to fix the bug. As mentioned above, when the pCPU is removed, what 
is the
status of its blocking list? But thinking a bit more about this, I feel it 
should work this way,
before the pCPU is removed, all the vCPUs running on it has been moved to 
another
pCPU, right? If this is the case, it can address part of my concern. Another 
concern is
if a vCPU is blocking on a pCPU, then the pCPU is going to be unplugged, what 
does
Xen do for the blocking vCPU?

Thanks,
Feng

> 
> Jan


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

[Xen-devel] [xen-unstable test] 94589: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)broken REGR. vs. 94580
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94580

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 94580
 build-i386-rumpuserxen6 xen-buildfail   like 94580
 build-amd64-rumpuserxen   6 xen-buildfail   like 94580
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94580
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94580
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94580
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94580
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94580

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

version targeted for testing:
 xen  a396c2549e079ab2f644aab8b2e7f47a8d0e3937
baseline version:
 xen  bab2bd8e222de9e596699ac080ea985af828c4c4

Last test of basis94580  2016-05-19 13:08:47 Z0 days
Testing same since94589  2016-05-20 02:45:09 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

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

Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.

[Julien Grall]

Hello Andrii,

Thank you for sharing details on your use case.

On 19/05/16 22:28, Andrii Anisov wrote:

See the system details I can reveal below:

  * There are two OS in the system Linux(Dom0) and Android(DomU)
  * Android provides almost all infotainment functionality. Linux covers
functionality with higher reliability requirements and backup in
case if Android crashes/glitches.


If a malicious user has access to the Android guest (via USB key, 
wifi,...) he would be able to crash the platform using the GPU because 
there is no SMMU protection.


So can you expand what are your expectations for reliability?


  * Linux (Dom0) handles all HW except GPU.
  * Android (DomD) runs with number of PV drivers, has an exclusive
access to GPU.
  * The system has 2Gb(-16MB due to errata) RAM under 4GB, and a memory
bank mapped over 4GB
  * Due to relatively small amount of dma-able memory both domains
should have assigned RAM both from under 4GB and over 4GB spaces.
  * Several "data flow" mixing scenarios should be provided on Linux
side I.e. controlling Android audio level, Android audio mute,
mixing Android audio stream from stream generated by Linux. Same for
Android displaying, events passing.
  * Domains should share HW codecs.

 >> Similarly, what are the limitations for the Jacinto6 SoC that need to
 >> be workaround?

The main limitation is that Jacinto6 lacks of SMMU. All transaction
initiators can address 32bit only, some initiators have no MMU and do
not support sg-lists (require buffers continuous in maddr).


If I understand correctly, all the initiators but the GPU will be used 
by DOM0 which is already direct mapped. The only issue here is 
allocating memory enough memory below 4GB.


By default Xen will try to allocate as much RAM as possible below 4GB 
for DOM0. If you are concerned about the amount allocated, you could 
pre-allocate them before hand (such as via the DT as propose in [1]).


For the GPU, on another reply you said it was protected by an IPMMU. I 
remembered a series from globallogic to virtualize it in Xen [2]. Can 
you details why this option would not fit in your use case?


Regards,

[1] 
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01879.html
[2] 
http://lists.xenproject.org/archives/html/xen-devel/2014-06/msg03359.html


--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list

[Jan Beulich]

>>> On 20.05.16 at 10:53,  wrote:
> I still have two opens, which needs comments/sugguestions from you guys.
> - What shoule we do for the per-cpu blocking list during vcpu hotplug?

What do you mean with vcpu hotplug? vcpus never get removed
from a VM (from hypervisor perspective), and all the guest may
ever use need to be created before the guest starts.

> - What shoule we do for the per-cpu blocking list during pcpu hotplug?

I think it would help if you said what issue you see.

Jan


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

Re: [Xen-devel] Question about the best practice to install two versions of Xen toolstack on the same machine

[Jan Beulich]

>>> On 19.05.16 at 20:40,  wrote:
> Does anyone try to install two version of Xen toolstack on the same machine?
> Is there any documentation about the best practice to install two
> versions of Xen onto the same machine?

Or, as an alternative to Olaf's reply, don't install the tools at all, but
instead run everything right out of the build trees. That requires some
script wrappers to get things like the library search path set up
correctly, but with that in place it has been working fine for me for
years.

Jan


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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Jan Beulich]

>>> On 20.05.16 at 10:45,  wrote:
> On Thu, May 19, 2016 at 5:36 PM, Jan Beulich  wrote:
> On 19.05.16 at 15:58,  wrote:
>>> Case 1: Dom0 is driver domain:
>>> There is a Ducati firmware which runs on dedicated M4 core and decodes
>>> video. This firmware uses hardcoded physical addresses for graphics
>>> buffers. Those addresses should be inside address-space of the driver
>>> domain (Dom0). Ducati firmware is proprietary and we have no ability
>>> to rework it. So Dom0 kernel should be placed to the configured
>>> address (to the DOM0 RAM bank with specific address).
>>>
>>> Case 2: Dom0 is Thin and DomD is driver domain.
>>> All is the same: Ducati firmware requires special (hardcoded) addresses.
>>
>> For both of these cases I would then wonder whether such
>> environments are actually suitable for doing virtualization on.
> Currently we use Jacinto 6 evaluation board with DRA74X processor.
> We have both configurations (Thin Dom0 and Thich Dom0).

Which says nothing about their suitability for virtualization.

Jan


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

Re: [Xen-devel] [PATCH v10 3/3] vt-d: fix vt-d Device-TLB flush timeout issue

[Jan Beulich]

>>> On 20.05.16 at 09:15,  wrote:
> On May 17, 2016 10:00 PM, Jan Beulich  wrote:
>> >>> On 22.04.16 at 12:54,  wrote:
>> > --- a/xen/drivers/passthrough/vtd/qinval.c
>> > +++ b/xen/drivers/passthrough/vtd/qinval.c
>> > @@ -206,10 +206,71 @@ static int invalidate_sync(struct iommu *iommu)
>> >  return 0;
>> >  }
>> >
>> > +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
>> > + u16 seg, u8 bus, u8 devfn) {
>> > +struct domain *d = NULL;
>> > +struct pci_dev *pdev;
>> > +
>> > +if ( test_bit(did, iommu->domid_bitmap) )
>> > +d = rcu_lock_domain_by_id(iommu->domid_map[did]);
>> > +
>> > +/*
>> > + * In case the domain has been freed or the IOMMU domid bitmap is
>> > + * not valid, the device no longer belongs to this domain.
>> > + */
>> > +if ( d == NULL )
>> > +return;
>> > +
>> > +pcidevs_lock();
>> > +
>> > +for_each_pdev(d, pdev)
>> > +{
>> > +if ( (pdev->seg == seg) &&
>> > + (pdev->bus == bus) &&
>> > + (pdev->devfn == devfn) )
>> > +{
>> > +ASSERT(pdev->domain);
>> > +list_del(>domain_list);
>> > +pdev->domain = NULL;
>> > +pci_hide_existing_device(pdev);
>> > +break;
>> > +}
>> > +}
>> 
>> A loop like this is of course not ideal (especially for Dom0, which may have
>> many devices). And I wonder why you, ...
>> 
>> > @@ -134,8 +133,9 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16
>> did,
>> >  /* invalidate all translations: sbit=1,bit_63=0,bit[62:12]=1 
> */
>> >  sbit = 1;
>> >  addr = (~0UL << PAGE_SHIFT_4K) & 0x7FFF;
>> > -rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth,
>> > -  sid, sbit, addr);
>> > +rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth, 
>> > did,
>> > +  pdev->seg, pdev->bus, 
>> > pdev->devfn,
>> > +  sbit, addr);
>> >  break;
>> >  case DMA_TLB_PSI_FLUSH:
>> >  if ( !device_in_domain(iommu, pdev, did) ) @@ -154,8
>> > +154,9 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
>> >  addr |= (((u64)1 << (size_order - 1)) - 1) << 
>> > PAGE_SHIFT_4K;
>> >  }
>> >
>> > -rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth,
>> > -  sid, sbit, addr);
>> > +rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth, 
>> > did,
>> > +  pdev->seg, pdev->bus, 
>> > pdev->devfn,
>> > +  sbit, addr);
>> >  break;
>> 
>> ... holding pdev in your hands here, don't just pass it down (which at once
>> would make the function signature less convoluted: you could even eliminate
>> the currently 2nd parameter that way).
> 
> I am afraid we need to leave it as is.. this pdev , in 
> dev_invalidate_iotlb(), is 'struct pci_ats_dev',
> but we need a 'struct pci_dev' to hide device in 
> dev_invalidate_iotlb_timeout().
> 
> 'struct pci_ats_dev' and 'struct pci_dev' are quite different, however, SBDF 
> is connection between them..

Oh, indeed. Yet - can't enable_ats_device() be passed a
struct pci_dev *, and that be stored instead of SBDF inside
struct pci_ats_dev?

Jan


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 66e5133ce0a8940a99451842a804dc5a37b4b687
baseline version:
 ovmf 1f1ec99dea4d6d04fed96fa8a2e299212f6bc8cb

Last test of basis94588  2016-05-20 01:14:27 Z0 days
Failing since 94590  2016-05-20 03:46:31 Z0 days3 attempts
Testing same since94600  2016-05-20 07:43:34 Z0 days1 attempts


People who touched revisions under test:
  Fu Siyuan 
  Gary Lin 
  Hao Wu 
  Marvin H?user 
  Marvin Haeuser 
  Qiu Shumin 
  Star Zeng 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [PATCH 3/3] VMX: Remove the vcpu from the per-cpu blocking list after domain termination

[Feng Wu]

We need to make sure the bocking vcpu is not in any per-cpu blocking list
when the associated domain is going to be destroyed.

Signed-off-by: Feng Wu 
---
 xen/arch/x86/hvm/vmx/vmx.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 4862b13..e74b3e7 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -248,6 +248,36 @@ void vmx_pi_hooks_deassign(struct domain *d)
 d->arch.hvm_domain.vmx.pi_switch_to = NULL;
 }
 
+static void vmx_pi_blocking_list_cleanup(struct domain *d)
+{
+unsigned int cpu;
+
+for_each_online_cpu ( cpu )
+{
+struct vcpu *v;
+unsigned long flags;
+struct arch_vmx_struct *vmx, *tmp;
+spinlock_t *lock = _cpu(vmx_pi_blocking, cpu).lock;
+struct list_head *blocked_vcpus = _cpu(vmx_pi_blocking, cpu).list;
+
+spin_lock_irqsave(lock, flags);
+
+list_for_each_entry_safe(vmx, tmp, blocked_vcpus, pi_blocking.list)
+{
+v = container_of(vmx, struct vcpu, arch.hvm_vmx);
+
+if (v->domain == d)
+{
+list_del(>pi_blocking.list);
+ASSERT(vmx->pi_blocking.lock == lock);
+vmx->pi_blocking.lock = NULL;
+}
+}
+
+spin_unlock_irqrestore(lock, flags);
+}
+}
+
 static int vmx_domain_initialise(struct domain *d)
 {
 int rc;
@@ -265,6 +295,8 @@ static int vmx_domain_initialise(struct domain *d)
 
 static void vmx_domain_destroy(struct domain *d)
 {
+vmx_pi_blocking_list_cleanup(d);
+
 if ( !has_vlapic(d) )
 return;
 
-- 
2.1.0


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

[Xen-devel] [PATCH 2/3] VMX: Make hook pi_do_resume always available

[Feng Wu]

Make hook pi_do_resume always available, so when the last
assigned device is dettached from a domain, the blocked
vcpu can be removed from the per-cpu blocking list properly.

Signed-off-by: Feng Wu 
---
 xen/arch/x86/hvm/vmx/vmx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3fbc7b1..4862b13 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -233,7 +233,6 @@ void vmx_pi_hooks_assign(struct domain *d)
 d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
 d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
 d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
-d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
 }
 
 /* This function is called when pcidevs_lock is held */
@@ -247,13 +246,14 @@ void vmx_pi_hooks_deassign(struct domain *d)
 d->arch.hvm_domain.vmx.vcpu_block = NULL;
 d->arch.hvm_domain.vmx.pi_switch_from = NULL;
 d->arch.hvm_domain.vmx.pi_switch_to = NULL;
-d->arch.hvm_domain.vmx.pi_do_resume = NULL;
 }
 
 static int vmx_domain_initialise(struct domain *d)
 {
 int rc;
 
+d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
+
 if ( !has_vlapic(d) )
 return 0;
 
-- 
2.1.0


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

[Xen-devel] [PATCH 1/3] VMX: Properly adjuest the status of pi descriptor

[Feng Wu]

When the last assigned device is dettached from the domain, all
the PI related hooks are removed then, however, the vCPU can be
blocked, switched to another pCPU, etc, all without the aware of
PI. After the next time we attach another device to the domain,
which makes the PI realted hooks avaliable again, the status
of the pi descriptor is not true, we need to properly adjust
it.

Signed-off-by: Feng Wu 
---
 xen/arch/x86/hvm/vmx/vmx.c | 29 ++---
 xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bc4410f..3fbc7b1 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -107,12 +107,22 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
 static void vmx_vcpu_block(struct vcpu *v)
 {
 unsigned long flags;
-unsigned int dest;
+unsigned int dest = cpu_physical_id(v->processor);
 spinlock_t *old_lock;
 spinlock_t *pi_blocking_list_lock =
_cpu(vmx_pi_blocking, v->processor).lock;
 struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
 
+if (v->arch.hvm_vmx.pi_back_from_hotplug == 1)
+{
+write_atomic(_desc->ndst,
+ x2apic_enabled ? dest : MASK_INSR(dest, 
PI_xAPIC_NDST_MASK));
+write_atomic(_desc->nv, posted_intr_vector);
+pi_clear_sn(pi_desc);
+
+v->arch.hvm_vmx.pi_back_from_hotplug = 0;
+}
+
 spin_lock_irqsave(pi_blocking_list_lock, flags);
 old_lock = cmpxchg(>arch.hvm_vmx.pi_blocking.lock, NULL,
pi_blocking_list_lock);
@@ -130,8 +140,6 @@ static void vmx_vcpu_block(struct vcpu *v)
 
 ASSERT(!pi_test_sn(pi_desc));
 
-dest = cpu_physical_id(v->processor);
-
 ASSERT(pi_desc->ndst ==
(x2apic_enabled ? dest : MASK_INSR(dest, PI_xAPIC_NDST_MASK)));
 
@@ -164,6 +172,16 @@ static void vmx_pi_do_resume(struct vcpu *v)
 unsigned long flags;
 spinlock_t *pi_blocking_list_lock;
 struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
+unsigned int dest = cpu_physical_id(v->processor);
+
+if (v->arch.hvm_vmx.pi_back_from_hotplug == 1)
+{
+write_atomic(_desc->ndst,
+ x2apic_enabled ? dest : MASK_INSR(dest, 
PI_xAPIC_NDST_MASK));
+pi_clear_sn(pi_desc);
+
+v->arch.hvm_vmx.pi_back_from_hotplug = 0;
+}
 
 ASSERT(!test_bit(_VPF_blocked, >pause_flags));
 
@@ -202,9 +220,14 @@ static void vmx_pi_do_resume(struct vcpu *v)
 /* This function is called when pcidevs_lock is held */
 void vmx_pi_hooks_assign(struct domain *d)
 {
+struct vcpu *v;
+
 if ( !iommu_intpost || !has_hvm_container_domain(d) )
 return;
 
+for_each_vcpu ( d, v )
+v->arch.hvm_vmx.pi_back_from_hotplug = 1;
+
 ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
 
 d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index b54f52f..3feb60a 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -231,6 +231,7 @@ struct arch_vmx_struct {
  * pCPU and wakeup the related vCPU.
  */
 struct pi_blocking_vcpu pi_blocking;
+int pi_back_from_hotplug;
 };
 
 int vmx_create_vmcs(struct vcpu *v);
-- 
2.1.0


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

[Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list

[Feng Wu]

The current VT-d PI related code may operate incorrectly in the following
scenarios:
- When the last assigned device is dettached from the domain, all
the PI related hooks are removed then, however, the vCPU can be
blocked, switched to another pCPU, etc, all without the aware of
PI. After the next time we attach another device to the domain,
which makes the PI realted hooks avaliable again, the status
of the pi descriptor is not true. Beside that, the blocking vcpu
may still remain in the per-cpu blocking in this case
- After the domain is destroyed, the the blocking vcpu may also
remain in the per-cpu blocking.

This series fix the above issue.

I still have two opens, which needs comments/sugguestions from you guys.
- What shoule we do for the per-cpu blocking list during vcpu hotplug?
- What shoule we do for the per-cpu blocking list during pcpu hotplug?

Feng Wu (3):
  VMX: Properly adjuest the status of pi descriptor
  VMX: Make hook pi_do_resume always available
  VMX: Remove the vcpu from the per-cpu blocking list after domain
termination

 xen/arch/x86/hvm/vmx/vmx.c | 65 +++---
 xen/include/asm-x86/hvm/vmx/vmcs.h |  1 +
 2 files changed, 61 insertions(+), 5 deletions(-)

-- 
2.1.0


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

Re: [Xen-devel] netif.h clarifications

[Paul Durrant]

> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: 19 May 2016 17:28
> To: xen-de...@lists.xenproject.org
> Cc: Wei Liu; David Vrabel; Paul Durrant
> Subject: netif.h clarifications
> 
> Hello,
> 
> While trying to solve a FreeBSD netfront bug [0] I came across a couple
> of netif.h dark spots that I think should be documented in the netif.h
> header. I'm willing to make those changes, but I want to make sure my
> understanding is right.
> 
> Regarding checksum offloading, I had a hard time figuring out what the
> different flags actually mean:
> 
> /* Packet data has been validated against protocol checksum. */
> #define _NETRXF_data_validated (0)
> #define  NETRXF_data_validated (1U<<_NETRXF_data_validated)
> 
> /* Protocol checksum field is blank in the packet (hardware offload)? */
> #define _NETRXF_csum_blank (1)
> #define  NETRXF_csum_blank (1U<<_NETRXF_csum_blank)
> 
> (Same applies to the TX flags, I'm not copying them there because they are
> the same)
> 
> First of all, I assume "protocol" here refers to Layer 3 and Layer 4
> protocol, so that would be IP and TCP/UDP/SCTP checksum offloading? In
> any
> case this needs clarification and proper wording.
> 
> Then, I have some questions regarding the meaning of the flags themselves
> and the content of the checksum field in all the possible scenarios.
> 
> On RX path:
> 
>  - NETRXF_data_validated only: data has been validated, but what's the state
>of the checksum field itself? If the data is validated again, would it
>match against the checksum?
>  - NETRXF_csum_blank only: I don't think this makes much sense, data is in
>unknown state and checksum is not present, so there's no way to validate
>it. Packet should be dropped?

Yes, in practice it's not used on its own. As you say, I don't think it makes 
any sense.

>  - NETRXF_data_validated | NETRXF_csum_blank: this combination seems to
> be
>the one that makes more sense to me, data is valid, but checksum is not
>there. This matches what some real NICs already do, that is to provide
>the result of the checksum check _without_ actually providing the
>checksum itself on the RX path.
> 

In Linux netback this is set if the checksum info is partial, which I take to 
mean that the packet has a valid pseudo-header checksum. I think packets coming 
from NICs are more likely to be 'checksum unnecessary' which results in 
NETRXF_data_validated only, which I take to mean that the checksum has been 
verified but may have been trashed in the process.

> On TX path:
> 
>  - NETTXF_data_validated only: I don't think this makes any sense, data is
>always valid from the senders point of view.
>  - NETTXF_csum_blank only: checksum calculation offload, it should be
>performed by the other end.
>  - NETTXF_data_validated | NETTXF_csum_blank: again, I don't think it makes
>much sense, data is always valid from the senders point of view, or else
>why bother sending it?
> 

In Linux netback, the code goes:

if (txp->flags & XEN_NETTXF_csum_blank)
skb->ip_summed = CHECKSUM_PARTIAL;
else if (txp->flags & XEN_NETTXF_data_validated)
skb->ip_summed = CHECKSUM_UNNECESSARY;

So, csum_blank with or without data_validated means that it's assumed that the 
packet contains a valid pseudo-header checksum, but if csum_blank is not set 
then data_validated means that the data is good but the checksum is in an 
unknown state which is ok if the packet is then forwarded to another vif, and I 
assume 'unnecessary' is ignored by NIC drivers on their TX side (I guess they 
would only be interesting in 'partial').

> So it looks to me like we could get away with just two flags, one on the RX
> side that signals that the packet doesn't have a checksum but that the
> checksum validation has already been performed, and another one on the TX
> side to signal that the packet doesn't have a calculated checksum
> (typical checksum offload).
> 

On the TX side it would be useful to have flags which indicate:

- Full checksum present
- Pseudo-header checksum present
- State of checksum is unknown

On the RX side it would be useful to have

- Data validated, checksum state unknown
- Data validated, checksum correct
- Data not validated

> And then I've also seen some issues with TSO/LRO (GSO in Linux
> terminology)
> when using packet forwarding inside of a FreeBSD DomU. For example in the
> following scenario:
> 
>+
>|
>+-+   ++   +--+
>| |A B|   router   |C D|  |
>| Guest 1 +---+ +  +---+ Guest 2  |
>| |  bridge0  | |  |  bridge1  |  |
>+-+   ++   +--+
>172.16.1.67  

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  4a718d6a0ef5db034b8b779cdf57347074f07994
baseline version:
 libvirt  20a0fa8eb216f03b5e873ed61272083f7a801632

Last test of basis94572  2016-05-19 04:20:56 Z1 days
Testing same since94591  2016-05-20 04:21:50 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Erik Skultety 
  John Ferlan 
  Jovanka Gulicoska 
  Ján Tomko 
  Katerina Koukiou 
  Katerina Koukiou 
  Maxim Nestratov 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 
  Qiaowei Ren 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=4a718d6a0ef5db034b8b779cdf57347074f07994
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;

Re: [Xen-devel] Question about the best practice to install two versions of Xen toolstack on the same machine

[Olaf Hering]

On Thu, May 19, Meng Xu wrote:

> Does anyone try to install two version of Xen toolstack on the same machine?

I do that. See the INSTALL file which has examples at the end:

* To build a private copy of tools and xen:
configure --prefix=/odd/path --sysconfdir=/odd/path/etc --enable-rpath
make
sudo make install BOOT_DIR=/ood/path/boot EFI_DIR=/odd/path/efi

Note that pygrub has no concept of "rpath". Use pvgrub2 instead.

Olaf

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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

On Thu, May 19, 2016 at 5:36 PM, Jan Beulich  wrote:
 On 19.05.16 at 15:58,  wrote:
>> Case 1: Dom0 is driver domain:
>> There is a Ducati firmware which runs on dedicated M4 core and decodes
>> video. This firmware uses hardcoded physical addresses for graphics
>> buffers. Those addresses should be inside address-space of the driver
>> domain (Dom0). Ducati firmware is proprietary and we have no ability
>> to rework it. So Dom0 kernel should be placed to the configured
>> address (to the DOM0 RAM bank with specific address).
>>
>> Case 2: Dom0 is Thin and DomD is driver domain.
>> All is the same: Ducati firmware requires special (hardcoded) addresses.
>
> For both of these cases I would then wonder whether such
> environments are actually suitable for doing virtualization on.
Currently we use Jacinto 6 evaluation board with DRA74X processor.
We have both configurations (Thin Dom0 and Thich Dom0).

> Jan
>

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

Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

[Oleksandr Dmytryshyn]

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Thu, May 19, 2016 at 5:34 PM, Julien Grall  wrote:
> Hello Oleksandr,
>
>
> On 19/05/16 14:58, Oleksandr Dmytryshyn wrote:
>>>
>>> Why would a user want to allocate DOM0 RAM bank to a specific address?
>>>
>>> If I understand correctly your patch, DOM0 will only able to allocate one
>>> bank of the given size at the specific address. You also add this
>>> possibility for guest domain (see patch #4) and try to control where the
>>> guest memory will be allocated. This will increase a lot the chance of the
>>> memory allocation to fail.
>>>
>>> For instance, the RAM region requested for DOM0 may have been used to
>>> allocate memory for Xen internal. So you need a way to reserve memory in
>>> order to avoid Xen using it.
>>>
>>> I expect most of the users who want to use direct memory mapped guest to
>>> know the number of guests which will use this feature.
>>>
>>> A such feature is only useful when pass-through a device to the guest on
>>> platfom without SMMU, so it is by default insecure.
>>>
>>> So I would suggest to create a new device-tree binding (or re-use an
>>> actual one) to reserve memory region to be used for direct memory mapped
>>> domain.
>>>
>>> Those regions could have an identifier to be used later during the
>>> allocation. This would avoid memory fragmentation, allow multiple RAM bank
>>> for DOM0,...
>>>
>>> Any opinions?
>>
>>
>> Case 1: Dom0 is driver domain:
>> There is a Ducati firmware which runs on dedicated M4 core and decodes
>> video. This firmware uses hardcoded physical addresses for graphics
>> buffers. Those addresses should be inside address-space of the driver
>> domain (Dom0). Ducati firmware is proprietary and we have no ability
>> to rework it. So Dom0 kernel should be placed to the configured
>> address (to the DOM0 RAM bank with specific address).
>>
>> Case 2: Dom0 is Thin and DomD is driver domain.
>> All is the same: Ducati firmware requires special (hardcoded) addresses.
>
>
> So if I understand correctly, patches #4, #13, #16 are only here to
> workaround a firmware which does not do the right thing?
>
> IHMO, modifying the memory allocator in Xen to make a firmware happy is just
> overkill. We need to explore all the possible solutions before going
> forward.
Yes, You are right. This patch written to make a firmware happy.

> From your description, it looks like to me that the device-tree does not
> correctly describe the platform. The graphic buffers should be reserved
> using /memreserve or via a specific binding.
>
> This would be used later by Xen to map the buffer into dom0 or allow dom0 to
> map it to a guest.
>
> Regards,
>
> --
> Julien Grall

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

Re: [Xen-devel] [PATCH RFC 01/18] xen/tools: Fix virtual disks helper scripts.

[Andrii Anisov]

> My bottom line is the error reporting mechanism needs to be preserved,
> otherwise we risk breaking other users. Libxl currently relies on those
> nodes to report error.

Got it.

Andrii Anisov | Associate Manager, Engineering
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

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