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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 seabios  5adc8bdea6a77bdb457d9cbca9a49a7d01cc25cd
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  138 days
Failing since115733  2017-11-10 17:19:59 Z  131 days  151 attempts
Testing same since   120197  2018-03-03 11:37:53 Z   18 days   11 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Nikolay Nikolov 
  Paul Menzel 
  Stefan Berger 
  Stephen Douthit 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.

(No revision log; it would be 336 lines long.)

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

[Xen-devel] [linux-4.1 test] 120984: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 6 kernel-build fail REGR. vs. 118294
 build-i386-pvops  6 kernel-build fail REGR. vs. 118294

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale 5 host-ping-check-native fail in 120846 pass in 
120984
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 120846
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 120916

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118294
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118294
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118294
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118294
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 

[Xen-devel] [xen-4.7-testing test] 120974: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  broken in 120908
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119780

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 4 host-install(4) broken in 120908 pass 
in 120974
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
120908 pass in 120974
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 120908 pass in 120974
 test-xtf-amd64-amd64-3   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120908
 test-armhf-armhf-xl-vhd   6 xen-installfail pass in 120908

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 120908 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 120908 never pass
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119780
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119780
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 119780
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119780
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119780
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119780
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119780
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119780
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119780
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119780
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119780
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 119780
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 119780
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 tes

Re: [Xen-devel] [PATCH v3 15/39] ARM: new VGIC: Implement vgic_vcpu_pending_irq

[Julien Grall]

Hi Andre,

On 03/21/2018 04:32 PM, Andre Przywara wrote:

Tell Xen whether a particular VCPU has an IRQ that needs handling
in the guest. This is used to decide whether a VCPU is runnable or
if a hypercall should be preempted to let the guest handle the IRQ.

This is based on Linux commit 90eee56c5f90, written by Eric Auger.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- adjust vgic_vcpu_pending_irq() to return integers, not false/true


I would have preferred to have the return switch to bool instead. I 
guess this can be done on a follow-up. With one comment below:


Reviewed-by: Julien Grall 



Changelog v1 ... v2:
- adjust to new vgic_vcpu_pending_irq() prototype, drop wrapper

  xen/arch/arm/vgic/vgic.c | 37 +
  1 file changed, 37 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 2fa595f4f7..925cda4580 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -647,6 +647,43 @@ void vgic_sync_to_lrs(void)
  gic_hw_ops->update_hcr_status(GICH_HCR_EN, 1);
  }
  
+/**

+ * vgic_vcpu_pending_irq() - determine if interrupts need to be injected
+ * @vcpu: The vCPU on which to check for interrupts.
+ *
+ * Checks whether there is an interrupt on the given VCPU which needs
+ * handling in the guest. This requires at least one IRQ to be pending
+ * and enabled.
+ *
+ * Returns: 1 if the guest should run to handle interrupts, 0 otherwise.


NIT: Because of "ret = irq_is_pending(irq) && irq->enabled", you will 
return a non-zero value if the guest should run to handle interrupts.



+ */
+int vgic_vcpu_pending_irq(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+struct vgic_irq *irq;
+unsigned long flags;
+int ret = 0;
+
+if ( !vcpu->domain->arch.vgic.enabled )
+return 0;
+
+spin_lock_irqsave(&vgic_cpu->ap_list_lock, flags);
+
+list_for_each_entry(irq, &vgic_cpu->ap_list_head, ap_list)
+{
+spin_lock(&irq->irq_lock);
+ret = irq_is_pending(irq) && irq->enabled;
+spin_unlock(&irq->irq_lock);
+
+if ( ret )
+break;
+}
+
+spin_unlock_irqrestore(&vgic_cpu->ap_list_lock, flags);
+
+return ret;
+}
+
  /*
   * Local variables:
   * mode: C



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 14/39] ARM: new VGIC: Add GICv2 world switch backend

[Julien Grall]

Hi Andre,

On 03/21/2018 04:32 PM, Andre Przywara wrote:

+/*
+ * If a hardware mapped IRQ has been handled for good, we need to
+ * clear the _IRQ_INPROGRESS bit to allow handling of new IRQs.
+ */
+if ( irq->hw && !lr_val.active && !lr_val.pending )
+{
+struct irq_desc *irqd = irq_to_desc(irq->hwintid);
+
+clear_bit(_IRQ_INPROGRESS, &irqd->status);


I realize the current vGIC is doing exactly the same thing. But this is 
racy.


Imagine the interrupt is firing on another pCPU (I wasn't able to rule 
out this even when the interrupt is following the vCPU), that pCPU may 
set _IRQ_INPROGRESS before this is cleared here.


So you would end up clearing _IRQ_INPROGRESS here, making the desc state 
inconsistent and would affect the removal of the IRQ from a guest (see 
gic_remove_irq_from_guest).


I am not entirely sure how to fix this because taking the desc->lock 
would not be enough. Indeed you may end up to clear right after the flag 
was set in do_IRQ.


Because the race is already there in the current vGIC and only affecting 
release IRQ, I guess I would be ok to keep like that for now. Can you 
add a TODO?



+}
+
+/* Always preserve the active bit */
+irq->active = lr_val.active;
+
+/* Edge is the only case where we preserve the pending bit */
+if ( irq->config == VGIC_CONFIG_EDGE && lr_val.pending )
+{
+irq->pending_latch = true;
+
+if ( vgic_irq_is_sgi(intid) )
+irq->source |= (1U << lr_val.virt.source);
+}
+
+/* Clear soft pending state when level irqs have been acked. */
+if ( irq->config == VGIC_CONFIG_LEVEL && !lr_val.pending )
+irq->pending_latch = false;
+
+/*
+ * Level-triggered mapped IRQs are special because we only
+ * observe rising edges as input to the VGIC.
+ *
+ * If the guest never acked the interrupt we have to sample
+ * the physical line and set the line level, because the
+ * device state could have changed or we simply need to
+ * process the still pending interrupt later.
+ *
+ * If this causes us to lower the level, we have to also clear
+ * the physical active state, since we will otherwise never be
+ * told when the interrupt becomes asserted again.
+ */
+if ( vgic_irq_is_mapped_level(irq) && lr_val.pending )
+{
+struct irq_desc *irqd;
+
+ASSERT(irq->hwintid >= VGIC_NR_PRIVATE_IRQS);
+
+irqd = irq_to_desc(irq->hwintid);
+irq->line_level = gic_read_pending_state(irqd);
+
+if ( !irq->line_level )
+gic_set_active_state(irqd, false);


Sorry, I didn't notice it before. gic_set_active_state expect the 
desc->lock to be taken. But I can't see the code here to do that.


Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf df67a480eb81821ba21ad6909e2fda287e745834
baseline version:
 ovmf ae38c9765a27264ecea03c6430b956b74a427213

Last test of basis   120951  2018-03-19 02:43:26 Z3 days
Testing same since   120991  2018-03-20 12:58:39 Z1 days1 attempts


People who touched revisions under test:
  Bob Feng 
  Feng, Bob C 
  Hao Wu 
  Jiewen Yao 
  Liming Gao 
  Pete Batard 
  Ruiyu Ni 
  Star Zeng 
  Yonghong Zhu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   ae38c9765a..df67a480eb  df67a480eb81821ba21ad6909e2fda287e745834 -> 
xen-tested-master

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

[Xen-devel] [xen-4.10-testing test] 120967: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  cee48d83cb5a7023c4bde93bbb5d42f8c110579d
baseline version:
 xen  b6a6458b13dc6f04e17620447a760ff70b1eb4c6

Last test of basis   120244  2018-03-04 20:58:36 Z   17 days
Failing since120284  2018-03-06 15:09:01 Z   15 days8 attempts
Testing same since   120890  2018-03-17 22:46:11 Z4 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Haozhong Zhang 
  Ian Jackson 
  Igor Druzhinin 
  Jan Beulich 
  Jo

Re: [Xen-devel] [PATCH v3 13/39] ARM: new VGIC: Add IRQ sync/flush framework

[Julien Grall]

Hi Andre,

On 03/21/2018 04:32 PM, Andre Przywara wrote:

Implement the framework for syncing IRQs between our emulation and the
list registers, which represent the guest's view of IRQs.
This is done in vgic_sync_from_lrs() and vgic_sync_to_lrs(), which
get called on guest entry and exit, respectively.
The code talking to the actual GICv2/v3 hardware is added in the
following patches.

This is based on Linux commit 0919e84c0fc1, written by Marc Zyngier.

Signed-off-by: Andre Przywara 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 11/39] Add list_sort() routine from Linux

[Julien Grall]

Hi Andre,

On 03/21/2018 04:32 PM, Andre Przywara wrote:

This pulls in Linux' list_sort.c, which is a merge sort implementation


s/Linux'/Linux's/ ?


for linked lists. Apart from adding a full featured license header and
adjusting the #include file, nothing has been changed in this code.
Define a promptless Kconfig which configurations can select when they
need this code and add it to the Makefile.

This is from Linux' lib/list_sort.c, as of commit e327fd7c8667
("lib: add module support to linked list sorting tests").

Signed-off-by: Andre Przywara 


With the NIT above and Jan's comment addressed:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 09/39] ARM: new VGIC: Add accessor to new struct vgic_irq instance

[Julien Grall]

Hi Andre,

On 03/21/2018 04:32 PM, Andre Przywara wrote:

The new VGIC implementation centers around a struct vgic_irq instance
per virtual IRQ.
Provide a function to retrieve the right instance for a given IRQ
number and (in case of private interrupts) the right VCPU.
This also includes the corresponding put function, which does nothing
for private interrupts and SPIs, but handles the ref-counting for LPIs.

This is based on Linux commit 64a959d66e47, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- extend comments to note preliminary nature of vgic_get_lpi()


Thank you for the update.



Changelog v1 ... v2:
- reorder header file inclusion

  xen/arch/arm/vgic/vgic.c | 134 +++
  xen/arch/arm/vgic/vgic.h |  41 +++
  2 files changed, 175 insertions(+)
  create mode 100644 xen/arch/arm/vgic/vgic.c
  create mode 100644 xen/arch/arm/vgic/vgic.h

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
new file mode 100644
index 00..a818e382b1
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include "vgic.h"
+
+/*
+ * Iterate over the VM's list of mapped LPIs to find the one with a
+ * matching interrupt ID and return a reference to the IRQ structure.
+ *
+ * TODO: This is more documentation of how it should be done. A list is
+ * not a good data structure for Dom0's LPIs, it merely serves as an
+ * example here how to properly do the locking, allocation and refcounting.
+ * So lpi_list_head should be replaced with something more appropriate.
+ */
+static struct vgic_irq *vgic_get_lpi(struct domain *d, u32 intid)


It looks like I forgot to mention it on previous version. Please replace 
u32 with uint32_t.


[...]


+struct vgic_irq *vgic_get_irq(struct domain *d, struct vcpu *vcpu,
+  u32 intid)


Here too.


+{
+/* SGIs and PPIs */
+if ( intid <= VGIC_MAX_PRIVATE )
+return &vcpu->arch.vgic.private_irqs[intid];
+
+/* SPIs */
+if ( intid <= VGIC_MAX_SPI )
+return &d->arch.vgic.spis[intid - VGIC_NR_PRIVATE_IRQS];
+
+/* LPIs */
+if ( intid >= VGIC_MIN_LPI )
+return vgic_get_lpi(d, intid);
+
+ASSERT_UNREACHABLE();
+
+return NULL;
+}
+


[...]


diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
new file mode 100644
index 00..a3befd386b
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic.h


[...]


+struct vgic_irq *vgic_get_irq(struct domain *d, struct vcpu *vcpu,
+  u32 intid);


And here too.

With that:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly

[Julien Grall]

On 03/21/2018 04:32 PM, Andre Przywara wrote:

The event channel IRQ has level triggered semantics, however the current
VGIC treats everything as edge triggered.
To correctly process those IRQs, we have to lower the (virtual) IRQ line
at some point in time, depending on whether ther interrupt condition


NIT: s/ther/the/

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 05/39] ARM: timer: Handle level triggered IRQs correctly

[Julien Grall]

Hi Andre,

On 03/21/2018 04:32 PM, Andre Przywara wrote:

The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we also have to keep track of when the line lowers, as the
emulation depends on it: Upon entering the guest, the new VGIC will
*clear* the virtual interrupt line, so it needs to re-sample the actual
state after returning from the guest.
So we have to sync the state of the interrupt condition at certain
points to catch when the line goes low and we can remove the vtimer vIRQ
from the vGIC (and the LR).
The VGIC in Xen so far only implemented edge triggered vIRQs, really, so
we need to add new functionality to re-sample the interrupt state.
Do this only when the new VGIC is in use.

Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 03/39] ARM: GIC: Allow tweaking the active and pending state of an IRQ

[Julien Grall]

Hi Andre,

On 03/21/2018 04:31 PM, Andre Przywara wrote:

When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active or pending state of an
interrupt at some point.
To prepare the GIC for that, we introduce a set_active_state() and a
set_pending_state() function to let the VGIC manipulate the state of
an associated hardware IRQ.
This takes care of properly setting the _IRQ_INPROGRESS bit.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- rework setting _IRQ_INPROGRESS bit:
   - no change when changing active state
   - unconditional set/clear on changing pending state
- drop introduction of gicv[23]_peek_irq() (only needed in the next patch now)

Changelog v1 ... v2:
- properly set _IRQ_INPROGRESS bit
- add gicv[23]_peek_irq() (pulled in from later patch)
- move wrappers functions into gic.h

  xen/arch/arm/gic-v2.c | 36 
  xen/arch/arm/gic-v3.c | 32 
  xen/include/asm-arm/gic.h | 24 
  3 files changed, 92 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index aa0fc6c1a1..d1f1578c05 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -243,6 +243,40 @@ static void gicv2_poke_irq(struct irq_desc *irqd, uint32_t 
offset)
  writel_gicd(1U << (irqd->irq % 32), offset + (irqd->irq / 32) * 4);
  }
  
+static void gicv2_set_active_state(struct irq_desc *irqd, bool active)

+{
+ASSERT(spin_is_locked(&irqd->lock));
+
+if ( active )
+{
+if ( test_bit(_IRQ_GUEST, &irqd->status) )


I don't understand why you only set/clear INPROGRESS bit for interrupt 
routed to guest. This will matter when releasing interrupt used by Xen 
(see release_irq).


Note that I don't expect this helper to be call on Xen IRQ, but I think 
we should make


Other than same remark on GICv3 code, the pending implementation looks 
good to me now.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 02/39] ARM: GIC: add GIC_INVALID to enum gic_version

[Julien Grall]

Hi Andre,

On 03/21/2018 04:31 PM, Andre Przywara wrote:

The enum gic_version at the moment just contains GIC_V2 and GIC_V3,
where GIC_V2 happens to map to 0. So without having initialised a
variable of that type, we will read back GIC_V2 (when allocated with zeroing
the memory).
To prevent ambiguities and to give an explicitly uninitialised state, add
a new first member: GIC_INVALID. Also make it obvious that this has a
"0" encoding.

Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,


---
  xen/include/asm-arm/gic.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 565b0875ca..3079387e06 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -227,6 +227,7 @@ struct gic_lr {
  };
  
  enum gic_version {

+GIC_INVALID = 0,/* the default until explicitly set up */
  GIC_V2,
  GIC_V3,
  };



--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

[Boris Ostrovsky]

On 03/21/2018 10:58 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].



I won't claim that I really understand what's going on here as far as 
DRM stuff is concerned but I didn't see any obvious issues with Xen bits.


So for that you can tack on my
Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Alexey G]

On Wed, 21 Mar 2018 17:06:28 +
Paul Durrant  wrote:
[...]
>> Well, this might work actually. Although the overall scenario will be
>> overcomplicated a bit for _PCI_CONFIG ioreqs. Here is how it will
>> look:
>> 
>> QEMU receives PCIEXBAR update -> calls the new dmop to tell Xen new
>> MMCONFIG address/size -> Xen (re)maps MMIO trapping area -> someone
>> is
>> accessing this area -> Xen intercepts this MMIO access
>> 
>> But here's what happens next:
>> 
>> Xen translates MMIO access into PCI_CONFIG and sends it to DM ->
>> DM receives _PCI_CONFIG ioreq -> DM translates BDF/addr info back to
>> the offset in emulated MMCONFIG range -> DM calls
>> address_space_read/write to trigger MMIO emulation
>>   
>
>That would only be true of a dm that cannot handle PCI config ioreqs
>directly.

It's just a bit problematic for xen-hvm.c (Xen ioreq processor in QEMU).

It receives these PCI conf ioreqs out of any context. To workaround
this, existing code issues I/O to emulated CF8h/CFCh ports in order to
allow QEMU to find their target. But we can't use the same method for
MMCONFIG accesses -- this works for basic PCI conf space only.

We need to either locate PCIBus/PCIDevice manually via object lookups
and then proceed to something like pci_host_config_read_common(), or to
convert the PCI conf access into the emulated MMIO access... again, a
required piece of information is missing -- we need to somehow learn the
current MMCONFIG address to recreate the memory address to be emulated.

Let's put it simply -- the goal to make PCI conf ioreqs to reach their
MMCONFIG targets in xen-hvm.c is easily achievable but it will look like
a hack. MMIO ioreqs are preferable for MMCONFIG -- no extra logic
needed for them, we can directly pass them for emulation in a way
somewhat reminiscent of CF8h/CFCh replay, except for memory.

Ideally it would be PCI conf ioreq translation for supplemental device
emulators while skipping this translation for QEMU. QEMU expects PCI
config ioreqs only for CF8/CFC accesses. I assume it's DEMU/VGPU which
of primary concern here, not experimental users like XenGT.

>  Paul
>
>> I tnink some parts of this equation can be collapsed, isn't it?
>> 
>> Above scenario makes it obvious that at least for QEMU the MMIO->PCI
>> conf translation is a redundant step. Why not to allow specifying
>> for DM whether it prefers to receive MMCONFIG accesses as native
>> (MMIO ones) or as translated PCI conf ioreqs? We can still route
>> either ioreq type to multiple device emulators accordingly.
>> 
>> This will be the most universal and consistent approach -- either
>> _COPY or _PCI_CONFIG-type ioreqs can be sent to DM, whatever it
>> likes more. 
>> >> 9. Existing MMCONFIG-handling code in QEMU will be unused in this
>> >> scenario  
>> >
>> >If you replay the read/write I don't think so. In any case this is
>> >irrelevant. QEMU CPU emulation code is also unused when running
>> >under Xen.
>> >  
>> >> 10. All this needed primarily to make the specific "Multiple
>> >> device emulators" feature to work (XenGT was mentioned as its
>> >> user) on Q35 with MMCONFIG.
>> >>
>> >> Anything wrong/missing here?  
>> >
>> >I think that's correct.
>> >
>> >Thanks, Roger.  
>


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8df3821c08d024684a6c83659d8d794b565067f9
baseline version:
 xen  bde2870e7da1896b36d5117d307a8ac2f07ae276

Last test of basis   121036  2018-03-21 17:01:08 Z0 days
Testing same since   121043  2018-03-21 21:04:22 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  Paul Durrant 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   bde2870e7d..8df3821c08  8df3821c08d024684a6c83659d8d794b565067f9 -> smoke

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

[Xen-devel] [linux-3.18 test] 120977: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
120911 pass in 120977
 test-armhf-armhf-xl-xsm  10 debian-install fail pass in 120911

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 120911 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 120911 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 120780
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 120780
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 120780
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120780
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120780
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120780
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120780
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux5fcd9374919e35f015c283d6900a1f0fca00477e
baseline version:
 linux89dad4ea47357950b8ba09886e02ff4fd0793f9e

Last test of basis   120780  2018-03-15 06:17:10 Z6 days
Testing same since   120911  2018-03-18 11:05:49 Z3 days2 attempts


People who touched revisions under test:
  Borislav Petkov 
  Clay McClure 
  Danilo Krummrich 
  Dmitry Torokhov 
  Eric Dumaze

Re: [Xen-devel] [for-4.11][PATCH v6 01/16] x86/mm: skip incrementing mfn if it is not a valid mfn

[Julien Grall]

On 03/21/2018 02:11 PM, Jan Beulich wrote:

On 21.03.18 at 05:47,  wrote:

From: Wei Liu 

In a follow-up patches, some callers will be switched to pass
INVALID_MFN instead of zero for non-present mappings. So skip
incrementing mfn if it is not a valid one.

Signed-off-by: Wei Liu 
Signed-off-by: Julien Grall 
[Rework the commit message]


Where did my

Reviewed-by: Jan Beulich 

go?


I considered the rewording as a reason to drop the tags.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Alexey G]

On Wed, 21 Mar 2018 17:15:04 +
Roger Pau Monné  wrote:
[...]
>> Above scenario makes it obvious that at least for QEMU the MMIO->PCI
>> conf translation is a redundant step. Why not to allow specifying
>> for DM whether it prefers to receive MMCONFIG accesses as native
>> (MMIO ones) or as translated PCI conf ioreqs?  
>
>You are just adding an extra level of complexity to an interface
>that's fairly simple. You register a PCI device using
>XEN_DMOP_IO_RANGE_PCI and you get IOREQ_TYPE_PCI_CONFIG ioreqs.

Yes, and it is still needed as we have two distinct (and not equal)
interfaces to PCI conf space. Apart from 0..FFh range overlapping they
can be considered very different interfaces. And whether it is a real
system or emulated -- we can use either one of these two interfaces or
both.

For QEMU zero changes are needed to support MMCONFIG MMIO accesses if
they come as MMIO ioreqs. It's just what its MMCONFIG emulation code
expects.
Anyway, for (kind of vague) users of the multiple ioreq servers
capability we can enable MMIO translation to PCI conf ioreqs. Note that
actually this is an extra step, not forwarding trapped MMCONFIG MMIO
accesses to the selected device model as is.

>Getting both IOREQ_TYPE_PCI_CONFIG and IOREQ_TYPE_COPY for PCI config
>space access is misleading.

These are very different accesses, both in transport and capabilities.

>In both cases Xen would have to do the MCFG access decoding in order
>to figure out which IOREQ server will handle the request. At which
>point the only step that you avoid is the reconstruction of the memory
>access from the IOREQ_TYPE_PCI_CONFIG which is trivial.

The "reconstruction of the memory access" you mentioned won't be easy
actually. The thing is, address_space_read/write is not all what we
need.

In order to translate PCI conf ioreqs back to emulated MMIO ops, we
need to be an involved party, mainly to know where MMCONFIG area is
located so we can construct the address within its range from BDF.
This piece of information is destroyed in the process of MMIO ioreq
translation to PCI conf type.

The code which parse PCI conf ioreqs in xen-hvm.c doesn't know anything
about the current emulated MMCONFIG state. The correct way to have this
info is to participate in its emulation. As we don't participate, we
have no other way than trying to gain backdoor access to PCIHost fields
via things like object_resolve_*(). This solution is cumbersome and
ugly but will work... and may break anytime due to changes in QEMU. 

QEMU maintainers will grin while looking at all this I'm afraid --
trapped MMIO accesses which are translated to PCI conf accesses which
in turn translated back to emulated MMIO accesses upon receiving, along
with tedious attempts to gain access to MMCONFIG-related info as we're
not invited to the MMCONFIG emulation party.

The more I think about it, the more I like the existing
map_io_range_to_ioreq_server() approach. :( It works without doing
anything, no hacks, no new interfaces, both MMCONFIG and CF8/CFC are
working as expected. There is a problem to make it compatible with
the specific multiple ioreq servers feature, but providing a new
dmop/hypercall (which you suggest is a must have thing to trap MMCONFIG
MMIO to give QEMU only the freedom to tell where it is located) allows
to solve this problem in any possible way, either MMIO -> PCI conf
translation or anything else.

>> We can still route either ioreq
>> type to multiple device emulators accordingly.  
>
>It's exactly the same that's done for IO space PCI config space
>addresses. QEMU gets an IOREQ_TYPE_PCI_CONFIG and it replays the IO
>space access using do_outp and cpu_ioreq_pio.

...And it is completely limited to basic PCI conf space. I don't know
the context of this line in xen-hvm.c:

val = (1u << 31) | ((req->addr & 0x0f00) << 16) | ((sbdf & 0x) << 8)
   | (req->addr & 0xfc);

but seems like current QEMU versions do not expect anything similar to
AMD ECS-style accesses for 0CF8h. It is limited to basic PCI conf only.

>If you think using IOREQ_TYPE_COPY for MCFG accesses is such a benefit
>for QEMU, why not just translate the IOREQ_TYPE_PCI_CONFIG into
>IOREQ_TYPE_COPY in handle_ioreq and dispatch it using
>cpu_ioreq_move?

Answered above, we need to somehow have access to the info which don't
belong to us for this step.

>Thanks, Roger.

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

[Xen-devel] [xen-4.8-testing test] 120965: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 120885 pass 
in 120965
 test-armhf-armhf-xl 5 host-ping-check-native fail in 120885 pass in 120965
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
120885 pass in 120965
 test-xtf-amd64-amd64-5   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120885
 test-xtf-amd64-amd64-3   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120885
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 120885

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 120116

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120116
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120116
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120116
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120116
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 120116
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 120116
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 120116
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120116
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 t

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

[Boris Ostrovsky]

On 03/15/2018 10:22 AM, Joao Martins wrote:
> All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
> changing only the acpi_id. For processors which P-state coordination type
> is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information
> (_PSD), because Xen will ignore any cpufreq domains created for past CPUs.
>
> Albeit for platforms which expose coordination types as SW_ANY or SW_ALL,
> this will have some unintended side effects. Effectively, it will look at
> the P-state domain existence and *if it already exists* it will skip the
> acpi-cpufreq initialization and thus inherit the policy from the first CPU
> in the cpufreq domain. This will finally lead to the original cpu not
> changing target freq to P0 other than the first in the domain. Which will
> make turbo boost not getting enabled (e.g. for 'performance' governor) for
> all cpus.
>
> This patch fixes that, by also evaluating _PSD when we enumerate all ACPI
> processors and thus always uploading the correct info to Xen. We export
> acpi_processor_get_psd() for that this purpose, but change signature
> to not assume an existent of acpi_processor given that ACPI isn't creating
> an acpi_processor for non-dom0 CPUs.
>
> Signed-off-by: Joao Martins 



Applied to for-linus-4.17


-boris

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

Re: [Xen-devel] [PATCH] x86/xen: Delay get_cpu_cap until stack canary is established

[Boris Ostrovsky]

On 03/19/2018 12:58 PM, Jason Andryuk wrote:
> Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") introduced a
> call to get_cpu_cap, which is fstack-protected.  This is works on x86-64
> as commit 4f277295e54c ("x86/xen: init %gs very early to avoid page
> faults with stack protector") ensures the stack protector is configured,
> but it it did not cover x86-32.
>
> Delay calling get_cpu_cap until after xen_setup_gdt has initialized the
> stack canary.  Without this, a 32bit PV machine crashes early
> in boot.
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) [ Xen-4.6.6-xc  x86_64  debug=n  Tainted:C ]
> (XEN) CPU:0
> (XEN) RIP:e019:[]
>
> And the PV kernel IP corresponds to init_scattered_cpuid_features
>0xc10362f8 <+24>:mov%gs:0x14,%eax
>
> Fixes 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings")
>
> Signed-off-by: Jason Andryuk 
>


Applied to for-linus-4.17

-boris

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

Re: [Xen-devel] [PATCH v2 1/3] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling

[Boris Ostrovsky]

On 03/14/2018 10:43 PM, Simon Gaiser wrote:
> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
> concurrent xenstore accesses") made a subtle change to the semantic of
> xenbus_dev_request_and_reply() and xenbus_transaction_end().
>
> Before on an error response to XS_TRANSACTION_END
> xenbus_dev_request_and_reply() would not decrement the active
> transaction counter. But xenbus_transaction_end() has always counted the
> transaction as finished regardless of the response.
>
> The new behavior is that xenbus_dev_request_and_reply() and
> xenbus_transaction_end() will always count the transaction as finished
> regardless the response code (handled in xs_request_exit()).
>
> But xenbus_dev_frontend tries to end a transaction on closing of the
> device if the XS_TRANSACTION_END failed before. Trying to close the
> transaction twice corrupts the reference count. So fix this by also
> considering a transaction closed if we have sent XS_TRANSACTION_END once
> regardless of the return code.
>
> Cc:  # 4.11
> Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent 
> xenstore accesses")
> Signed-off-by: Simon Gaiser 

Applied the series to for-linus-4.17

-boris

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

Re: [Xen-devel] [PATCH v5 4/5] x86/msr: update domain policy on CPUID policy changes

[Andrew Cooper]

On 28/02/2018 16:09, Sergey Dyasli wrote:
> diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
> index 419ab6f8a7..4747572871 100644
> --- a/xen/include/asm-x86/msr.h
> +++ b/xen/include/asm-x86/msr.h
> @@ -606,6 +606,9 @@ int init_vcpu_msr_policy(struct vcpu *v);
>  int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val);
>  int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val);
>  
> +/* Update availability of per-domain MSRs based on CPUID policy */
> +void recalculate_msr_policy(struct domain *d);

Either this needs naming to be specifically the domain policy, or the
comment shouldn't specify per-domain only.  As we build up the policies,
I expect we will end up needing to tweak the vcpu policies as well.

Otherwise, Reviewed-by: Andrew Cooper  (with
some full stops at the end of comments, seeing as the series needs
another spin.)

> +
>  #endif /* !__ASSEMBLY__ */
>  
>  #endif /* __ASM_MSR_H */


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

Re: [Xen-devel] [PATCH v5 3/5] x86/cpuid: update signature of hvm_cr4_guest_valid_bits()

[Andrew Cooper]

On 28/02/2018 16:09, Sergey Dyasli wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index aa0505036b..4856ad7c24 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1699,7 +1699,7 @@ static void vmx_update_guest_cr(struct vcpu *v, 
> unsigned int cr)
>   * bits that are controlled by the hypervisor.
>   */
>  v->arch.hvm_vmx.cr4_host_mask = HVM_CR4_HOST_MASK | X86_CR4_PKE |
> -~hvm_cr4_guest_valid_bits(v, 0);
> +~hvm_cr4_guest_valid_bits(v->domain, 
> 0);

Indentation here looks fishy.  Please add some brackets around the
expression, and 0 => false.  Alternatively, reflow the expression to
have a linebreak after the =.

Otherwise, Reviewed-by: Andrew Cooper 

>  v->arch.hvm_vmx.cr4_host_mask |= v->arch.hvm_vmx.vmx_realmode ?
>   X86_CR4_VME : 0;
>  v->arch.hvm_vmx.cr4_host_mask |= !hvm_paging_enabled(v) ?
>


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

Re: [Xen-devel] [PATCH v5 2/5] x86/msr: add VMX MSRs into HVM_max domain policy

[Andrew Cooper]

On 28/02/2018 16:09, Sergey Dyasli wrote:
> Currently, when nested virt is enabled, the set of L1 VMX features
> is fixed and calculated by nvmx_msr_read_intercept() as an intersection
> between the full set of Xen's supported L1 VMX features, the set of
> actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of
> features that Xen uses.
>
> Add calculate_hvm_max_vmx_policy() which will save the end result of
> nvmx_msr_read_intercept() on current H/W into HVM_max domain policy.
> There will be no functional change to what L1 sees in VMX MSRs. But the
> actual use of HVM_max domain policy will happen later, when VMX MSRs
> are handled by guest_rd/wrmsr().
>
> Signed-off-by: Sergey Dyasli 
> ---
> v4 --> v5:
> - Macros are removed and now supported bitmask is used to derive policy
> - Added vmx_clear_policy() helper
> ---
>  xen/arch/x86/msr.c | 134 
> +
>  1 file changed, 134 insertions(+)
>
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index 43607b5107..f700e05570 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -106,6 +106,138 @@ static void __init calculate_host_policy(void)
>  dp->plaform_info.cpuid_faulting = cpu_has_cpuid_faulting;
>  }
>  
> +static void vmx_clear_policy(struct msr_domain_policy *dp)
> +{
> +memset(dp->vmx.raw, 0, sizeof(dp->vmx.raw));
> +dp->vmx_procbased_ctls2.raw = 0;
> +dp->vmx_ept_vpid_cap.raw = 0;
> +memset(dp->vmx_true_ctls.raw, 0, sizeof(dp->vmx_true_ctls.raw));
> +dp->vmx_vmfunc.raw = 0;
> +}
> +
> +static void __init calculate_hvm_max_vmx_policy(struct msr_domain_policy *dp)

It might be worth leaving a /* TODO - actually make this feature
selection sane. */ ?  For one, it should be built up as a whitelist of
features (bounded by hardware support), rather than the mixed
blacklist/whitelist that it currently is.

Either way, changing the selection logic is work for a later series, not
this one.

> +{
> +const struct msr_domain_policy *hp = &host_msr_domain_policy;
> +uint32_t supported;
> +
> +if ( !cpu_has_vmx )
> +return;

This should probably be hvm_max_cpuid_policy->basic.vmx.  i.e. if by
some mechanism a user has elected to not offer the vmx feature even in
the max policy, we shouldn't offer the MSRs even if they are actually
available on the hardware.

> +
> +vmx_clear_policy(dp);
> +
> +dp->vmx.basic.raw = hp->vmx.basic.raw;
> +
> +dp->vmx.pinbased_ctls.allowed_0.raw = VMX_PINBASED_CTLS_DEFAULT1;
> +dp->vmx.pinbased_ctls.allowed_1.raw = VMX_PINBASED_CTLS_DEFAULT1;
> +supported = PIN_BASED_EXT_INTR_MASK |
> +PIN_BASED_NMI_EXITING   |
> +PIN_BASED_PREEMPT_TIMER;

Please have a single set of brackets around the entire or statement, so
editors will indent new changes correctly.

> +dp->vmx.pinbased_ctls.allowed_1.raw |= supported;
> +dp->vmx.pinbased_ctls.allowed_1.raw &= 
> hp->vmx.pinbased_ctls.allowed_1.raw;
> +
> +dp->vmx.procbased_ctls.allowed_0.raw = VMX_PROCBASED_CTLS_DEFAULT1;
> +dp->vmx.procbased_ctls.allowed_1.raw = VMX_PROCBASED_CTLS_DEFAULT1;
> +supported = CPU_BASED_HLT_EXITING  |
> +CPU_BASED_VIRTUAL_INTR_PENDING |
> +CPU_BASED_CR8_LOAD_EXITING |
> +CPU_BASED_CR8_STORE_EXITING|
> +CPU_BASED_INVLPG_EXITING   |
> +CPU_BASED_MONITOR_EXITING  |
> +CPU_BASED_MWAIT_EXITING|
> +CPU_BASED_MOV_DR_EXITING   |
> +CPU_BASED_ACTIVATE_IO_BITMAP   |
> +CPU_BASED_USE_TSC_OFFSETING|
> +CPU_BASED_UNCOND_IO_EXITING|
> +CPU_BASED_RDTSC_EXITING|
> +CPU_BASED_MONITOR_TRAP_FLAG|
> +CPU_BASED_VIRTUAL_NMI_PENDING  |
> +CPU_BASED_ACTIVATE_MSR_BITMAP  |
> +CPU_BASED_PAUSE_EXITING|
> +CPU_BASED_RDPMC_EXITING|
> +CPU_BASED_TPR_SHADOW   |
> +CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
> +dp->vmx.procbased_ctls.allowed_1.raw |= supported;
> +dp->vmx.procbased_ctls.allowed_1.raw &=
> +hp->vmx.procbased_ctls.allowed_1.raw;
> +
> +dp->vmx.exit_ctls.allowed_0.raw = VMX_EXIT_CTLS_DEFAULT1;
> +dp->vmx.exit_ctls.allowed_1.raw = VMX_EXIT_CTLS_DEFAULT1;
> +supported = VM_EXIT_ACK_INTR_ON_EXIT   |
> +VM_EXIT_IA32E_MODE |
> +VM_EXIT_SAVE_PREEMPT_TIMER |
> +VM_EXIT_SAVE_GUEST_PAT |
> +VM_EXIT_LOAD_HOST_PAT  |
> +VM_EXIT_SAVE_GUEST_EFER|
> +VM_EXIT_LOAD_HOST_EFER |
> +VM_EXIT_LOAD_PERF_GLOBAL_CTRL;
> +dp->vmx.exit_ctls.allowed_1.raw |= supported;
> +dp->vmx.exit_ctls.allowed_1.raw &= hp->vmx.exit_ctls.allowed_1.raw;
> +
> +dp->vmx.entry_ctls.allowed_0.raw = VMX_ENTRY_CT

[Xen-devel] [rumprun test] 120981: regressions - FAIL

[osstest service owner]

flight 120981 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120981/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumprun   6 rumprun-buildfail REGR. vs. 106754
 build-i386-rumprun6 rumprun-buildfail REGR. vs. 106754

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a

version targeted for testing:
 rumprun  94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c
baseline version:
 rumprun  c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74

Last test of basis   106754  2017-03-18 04:21:25 Z  368 days
Testing same since   120360  2018-03-09 04:19:20 Z   12 days9 attempts


People who touched revisions under test:
  Kent McLeod 
  Kent McLeod 
  Naja Melan 
  Sebastian Wicki 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-rumprun-amd64   blocked 
 test-amd64-i386-rumprun-i386 blocked 



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

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

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

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


Not pushing.


commit 94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c
Merge: 8fe40c8 b3c1033
Author: Kent McLeod 
Date:   Fri Feb 16 09:15:45 2018 +1100

Merge pull request #118 from kent-mcleod/stretch-linking-defaultpie

Fix linking on Debian Stretch (gcc-6)

commit b3c1033b090b65e8e86999ddd063c174502aa3f0
Author: Kent McLeod 
Date:   Wed Feb 14 16:43:16 2018 +1100

Add further -no-pie checks to Rumprun build tools

This builds upon the previous commit to add -no-pie anywhere the
relocatable flag (-Wl,-r) is used to handle compilers that enable -pie
by default (Such as Debian Stretch).

commit 8fe40c84edddfbf472b4a7cce960df749701174c
Merge: c7f2f01 685f4ab
Author: Sebastian Wicki 
Date:   Fri Jan 5 15:04:18 2018 +0100

Merge pull request #112 from najamelan/bugfix/gcc7-fallthrough

Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7

commit 685f4ab3b74b6f1e1b40bdd3d2c42efa44bf385d
Author: Naja Melan 
Date:   Thu Jan 4 16:07:46 2018 +

Make the disabling of the fallthrough warning dependent on GCC version

This should prevent older gcc versions from choking on unknown argument.

I have not tested this, just wrote the code directly on github. Use with 
caution.

commit 34056451174e8722b972229fefc1bf9e0b89a7da
Author: Naja Melan 
Date:   Wed Jan 3 18:57:50 2018 +

Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7

GCC7 comes with a new warning "implicit-fallthrough" which will prevent 
building the netbsd-src.

For more information: 
https://dzone.com/articles/implicit-fallthrough-in-gcc-7

commit 35d81194b7feb75d20af3ba4fdb45ea76230852f
Author: Wei Liu 
Date:   Wed Jun 7 16:30:00 2017 +0100

Fix linking on Debian Stretch

Provide cc-option. Use that to check if -no-pie is available and
append it when necessary.

Signed-off-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 5/5] x86/msr: handle VMX MSRs with guest_rd/wrmsr()

[Andrew Cooper]

On 28/02/2018 16:09, Sergey Dyasli wrote:
> @@ -474,6 +505,10 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t 
> val)
>  break;
>  }
>  
> +case MSR_IA32_VMX_BASIC ... MSR_IA32_VMX_VMFUNC:
> +/* None of these MSRs are writeable. */
> +goto gp_fault;

There is a block at the top of the switch statement for read-only MSRs
(so they can be more easily removed when we finally get rid of the
legacy MSR paths).  With this moved, Reviewed-by: Andrew Cooper


> +
>  default:
>  return X86EMUL_UNHANDLEABLE;
>  }
>


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  bde2870e7da1896b36d5117d307a8ac2f07ae276
baseline version:
 xen  7a1358bbe73e5f749c3d2f53478dc1f30720f949

Last test of basis   120949  2018-03-19 02:41:07 Z2 days
Failing since120987  2018-03-20 10:02:16 Z1 days   10 attempts
Testing same since   121036  2018-03-21 17:01:08 Z0 days1 attempts


People who touched revisions under test:
  Andre Przywara 
  Andre Przywara 
  Andrew Cooper 
  Dario Faggioli 
  David E. Box 
  Doug Goldstein 
  Jan Beulich 
  Julien Grall 
  Len Brown 
  Rafael J. Wysocki 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   7a1358bbe7..bde2870e7d  bde2870e7da1896b36d5117d307a8ac2f07ae276 -> smoke

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

Re: [Xen-devel] [PATCH v5 1/5] x86/msr: add VMX MSRs definitions and populate Raw domain policy

[Andrew Cooper]

On 28/02/18 16:09, Sergey Dyasli wrote:
> New definitions provide a convenient way of accessing contents of
> VMX MSRs. They are separated into 5 logical blocks based on the
> availability conditions of MSRs in the each block:
>
> 1. vmx: [VMX_BASIC, VMX_VMCS_ENUM]
> 2. VMX_PROCBASED_CTLS2
> 3. VMX_EPT_VPID_CAP
> 4. vmx_true_ctls: [VMX_TRUE_PINBASED_CTLS, VMX_TRUE_ENTRY_CTLS]
> 5. VMX_VMFUNC
>
> Every bit value is accessible by its name and bit names match existing
> Xen's definitions as close as possible. There is a "raw" 64-bit field
> for each MSR as well as "raw" arrays for vmx and vmx_true_ctls blocks.
>
> Add calculate_raw_vmx_policy() which fills Raw policy with H/W values
> of VMX MSRs. Host policy will contain a copy of these values (for now).
>
> Signed-off-by: Sergey Dyasli 

Overall, I think this is good.  However, I'd like to take this
opportunity to make the names shorter, because there is a huge quantity
of unnecessary code volume in these names.  Some suggestions inline.

> ---
> v4 --> v5:
> - Clarified the reason for splitting MSRs into 5 blocks
> - Added raw field into cr0/4_bits
> - Moved cr0/4_bits definitions into asm-x86/x86-defns.h
> - Added msr availability helpers
> ---
>  xen/arch/x86/msr.c  | 118 ++
>  xen/include/asm-x86/msr.h   | 330 
> 
>  xen/include/asm-x86/x86-defns.h |  54 +++
>  3 files changed, 502 insertions(+)
>
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index 8ae3b4e616..43607b5107 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -34,10 +34,65 @@ struct msr_domain_policy __read_mostly 
> raw_msr_domain_policy,
>  struct msr_vcpu_policy __read_mostly hvm_max_msr_vcpu_policy,
> __read_mostly  pv_max_msr_vcpu_policy;
>  
> +static bool vmx_procbased_ctls2_available(const struct msr_domain_policy *dp)
> +{
> +return dp->vmx.procbased_ctls.allowed_1.activate_secondary_controls;
> +}
> +
> +static bool vmx_ept_vpid_cap_available(const struct msr_domain_policy *dp)
> +{
> +return dp->vmx_procbased_ctls2.allowed_1.enable_ept ||
> +   dp->vmx_procbased_ctls2.allowed_1.enable_vpid;
> +}
> +
> +static bool vmx_true_ctls_available(const struct msr_domain_policy *dp)
> +{
> +return dp->vmx.basic.default1_zero;
> +}
> +
> +static bool vmx_vmfunc_available(const struct msr_domain_policy *dp)
> +{
> +return dp->vmx_procbased_ctls2.allowed_1.enable_vm_functions;
> +}
> +
> +static void __init calculate_raw_vmx_policy(struct msr_domain_policy *dp)
> +{
> +unsigned int i, start_msr, end_msr;
> +
> +if ( !cpu_has_vmx )
> +return;
> +
> +start_msr = MSR_IA32_VMX_BASIC;
> +end_msr = MSR_IA32_VMX_VMCS_ENUM;
> +for ( i = start_msr; i <= end_msr; i++ )
> +rdmsrl(i, dp->vmx.raw[i - start_msr]);
> +
> +if ( vmx_procbased_ctls2_available(dp) )
> +rdmsrl(MSR_IA32_VMX_PROCBASED_CTLS2, dp->vmx_procbased_ctls2.raw);
> +
> +if ( vmx_ept_vpid_cap_available(dp) )
> +rdmsrl(MSR_IA32_VMX_EPT_VPID_CAP, dp->vmx_ept_vpid_cap.raw);
> +
> +if ( vmx_true_ctls_available(dp) )
> +{
> +start_msr = MSR_IA32_VMX_TRUE_PINBASED_CTLS;
> +end_msr = MSR_IA32_VMX_TRUE_ENTRY_CTLS;
> +for ( i = start_msr; i <= end_msr; i++ )
> +rdmsrl(i, dp->vmx_true_ctls.raw[i - start_msr]);
> +}
> +
> +if ( vmx_vmfunc_available(dp) )
> +rdmsrl(MSR_IA32_VMX_VMFUNC, dp->vmx_vmfunc.raw);
> +}
> +
>  static void __init calculate_raw_policy(void)
>  {
> +struct msr_domain_policy *dp = &raw_msr_domain_policy;
> +
>  /* 0x00ce  MSR_INTEL_PLATFORM_INFO */
>  /* Was already added by probe_cpuid_faulting() */
> +
> +calculate_raw_vmx_policy(dp);
>  }
>  
>  static void __init calculate_host_policy(void)
> @@ -260,6 +315,69 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t 
> val)
>  return X86EMUL_EXCEPTION;
>  }
>  
> +static void __init __maybe_unused build_assertions(void)
> +{
> +struct msr_domain_policy dp;
> +
> +BUILD_BUG_ON(sizeof(dp.vmx.basic) !=
> + sizeof(dp.vmx.basic.raw));
> +BUILD_BUG_ON(sizeof(dp.vmx.pinbased_ctls) !=
> + sizeof(dp.vmx.pinbased_ctls.raw));
> +BUILD_BUG_ON(sizeof(dp.vmx.procbased_ctls) !=
> + sizeof(dp.vmx.procbased_ctls.raw));
> +BUILD_BUG_ON(sizeof(dp.vmx.exit_ctls) !=
> + sizeof(dp.vmx.exit_ctls.raw));
> +BUILD_BUG_ON(sizeof(dp.vmx.entry_ctls) !=
> + sizeof(dp.vmx.entry_ctls.raw));
> +BUILD_BUG_ON(sizeof(dp.vmx.misc) !=
> + sizeof(dp.vmx.misc.raw));
> +BUILD_BUG_ON(sizeof(dp.vmx.cr0_fixed0) !=
> + sizeof(dp.vmx.cr0_fixed0.raw));
> +BUILD_BUG_ON(sizeof(dp.vmx.cr0_fixed1) !=
> + sizeof(dp.vmx.cr0_fixed1.raw));
> +BUILD_BUG_ON(sizeof(dp.vmx.cr4_fixed0) !=
> + sizeof(dp.vmx.cr4_fixed0.raw));
> +BUILD_BUG_ON(size

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemuu-win7-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win7-amd64
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  c698ca5278934c0ae32297a8725ced2e27585d7f
  Bug not present: b46dc8ae17a427c50c00241898832807576fd28a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/121039/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-qemuu-win7-amd64.xen-boot
 --summary-out=tmp/121039.bisection-summary --basis-template=118324 
--blessings=real,real-bisect linux-linus test-amd64-i386-xl-qemuu-win7-amd64 
xen-boot
Searching for failure / basis pass:
 120952 fail [host=elbling0] / 118629 ok.
Failure / basis pass flights: 120952 / 118629
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c698ca5278934c0ae32297a8725ced2e27585d7f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
a823a5280f25ad19a751dd9a41044f556471e61a
Basis pass b46dc8ae17a427c50c00241898832807576fd28a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#b46dc8ae17a427c50c00241898832807576fd28a-c698ca5278934c0ae32297a8725ced2e27585d7f
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#2b033e396f4fa0981bae1213cdacd15775655a97-5c3fdee026a204a59cb392e43a313ab558de9682
 
git://xenbits.xen.org/xen.git#1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0-a823a5280f25ad19a751dd9a41044f556471e61a
adhoc-revtuple-generator: tree discontiguous: linux-2.6
From git://cache:9419/git://xenbits.xen.org/xen
   f5eff146ef..8df3821c08  staging-> origin/staging
Loaded 5743 nodes in revision graph
Searching for test results:
 118629 pass b46dc8ae17a427c50c00241898832807576fd28a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0
 118598 pass irrelevant
 118638 fail irrelevant
 118672 fail irrelevant
 118775 fail irrelevant
 118893 fail irrelevant
 118968 fail irrelevant
 119064 fail irrelevant
 119117 fail irrelevant
 119201 fail irrelevant
 119350 fail irrelevant
 119435 fail irrelevant
 119511 fail irrelevant
 119582 fail irrelevant
 119639 fail irrelevant
 119687 fail irrelevant
 119751 fail irrelevant
 119922 fail irrelevant
 119992 fail irrelevant
 120022 fail irrelevant
 120055 fail irrelevant
 120092 fail irrelevant
 120228 fail irrelevant
 120305 fail irrelevant
 120269 fail irrelevant
 120441 fail irrelevant
 120654 fail irrelevant
 120779 fail irrelevant
 120866 fail irrelevant
 121002 pass b46dc8ae17a427c50c00241898832807576fd28a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
8f9ccfe93570ecae18d9cc224931787d0bca9c66
 121013 fail c698ca5278934c0ae32297a8725ced2e27585d7f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
a823a5280f25ad19a751dd9a41044f556471e61a
 121006 pass b46dc8ae17a427c50c00241898832807576fd28a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c99775d597fae9b8b8b27827b3d7845c49a2a0d7
 120995 pass b46dc8ae17a427c50c00241898832807576fd28a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0
 120952 fail c698ca527

Re: [Xen-devel] [PATCH v3 8/8] ci: add new bits to MAINTAINERS combine with Travis

[Doug Goldstein]

On 3/21/18 11:58 AM, Wei Liu wrote:
> On Wed, Mar 21, 2018 at 11:09:13AM -0500, Doug Goldstein wrote:
>> On 3/21/18 6:11 AM, George Dunlap wrote:
>>> On 03/21/2018 03:01 AM, Doug Goldstein wrote:
 Created a new section just called 'CI' since this is adding GitLab CI
 and still leaving the old Travis CI files around. This consolidates the
 two sections and adds the new files as well as adding another Travis
 file that was missing.

 Signed-off-by: Doug Goldstein 
 Reviewed-by: Konrad Rzeszutek Wilk 
 ---
  MAINTAINERS | 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

 diff --git a/MAINTAINERS b/MAINTAINERS
 index a5b3e95..81ec312 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -181,6 +181,16 @@ BLKTAP2
  S:Orphaned
  F:tools/blktap2/
  
 +CI
 +M:Doug Goldstein 
 +W:https://gitlab.com/xen-project/xen
 +W:https://travis-ci.org/xen-project/xen
 +S:Supported
 +F:.gitlab-ci.yml
 +F:.travis.yml
 +F:automation/
 +F:scripts/travis-build
>>>
>>> "CI" seems awfully short without a context.  "Travis CI" gives you
>>> enough context to figure out what CI is (or enough to Google it).
>>>
>>> "Automation / CI"?  "Continuous Integration (CI)"?
>>>
>>> Otherwise +1.
>>>
>>>  -George
>>>
>>
>> Let's go with "Continuous Integration (CI)". I can post a follow up if
>> that's helpful.
>>
> 
> Give me a branch to pull from. That's better.
> 
> Wei.
> 

Thanks Wei. Not sure of the right URL that can be easily pulled from but
I think its.

https://gitlab.com/cardoe/xen/commits/gitlab

repo is https://gitlab.com/cardoe/xen.git and the branch is gitlab

-- 
Doug Goldstein

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

Re: [Xen-devel] [PATCH for-4.11 2/2] libxc/x86: do not unconditionally set the module cmdline address

[Wei Liu]

On Wed, Mar 21, 2018 at 02:42:11PM +, Roger Pau Monne wrote:
> This will lead to writing a wrong module command line physical memory
> address if no command line is actually provided.
> 
> This hasn't caused problems so far because hvmloader is the only
> consumer of the modules command line, and it's unconditionally set
> in that case.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH for-4.11 1/2] libxc/x86: fix mapping of the start_info area

[Wei Liu]

On Wed, Mar 21, 2018 at 02:42:10PM +, Roger Pau Monne wrote:
> The start_info size calculated in bootlate_hvm is wrong. It should use
> HVMLOADER_MODULE_MAX_COUNT instead of dom->num_modules and it doesn't
> take into account the size of the modules command line.
> 
> This is not a problem so far because the actually used amount of
> memory doesn't cross a page boundary, and so no page-fault is
> triggered.

I get the cmdline bit.

What does it need to be HVMLOADER_MODULE_MAX_COUNT? Isn't better to just
map what we need here?

Wei.

> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxc/xc_dom_x86.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index 0b65dab4bc..e29c666b89 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -1671,7 +1671,11 @@ static int bootlate_hvm(struct xc_dom_image *dom)
>  unsigned int i;
>  
>  start_info_size = sizeof(*start_info) + dom->cmdline_size;
> -start_info_size += sizeof(struct hvm_modlist_entry) * dom->num_modules;
> +start_info_size += sizeof(struct hvm_modlist_entry) *
> +   HVMLOADER_MODULE_MAX_COUNT;
> +start_info_size += HVMLOADER_MODULE_CMDLINE_SIZE *
> +   HVMLOADER_MODULE_MAX_COUNT;
> +
>  
>  if ( start_info_size >
>   dom->start_info_seg.pages << XC_DOM_PAGE_SHIFT(dom) )
> -- 
> 2.16.2
> 

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

Re: [Xen-devel] [PATCH 04/20] xen/domctl: Drop vcpu_alloc_lock

[Andrew Cooper]

On 21/03/18 05:46, Juergen Gross wrote:
> On 20/03/18 18:22, Andrew Cooper wrote:
>> On 20/03/18 16:58, Jan Beulich wrote:
>> On 19.03.18 at 20:13,  wrote:
 It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
 "x86/AMD: Add support for AMD's OSVW feature in guests".

 At the time, svm_handle_osvw() could have seen an unexpected change in OSVW
 (not the case now, due to the new CPUID Policy infrastructure), but even 
 then,
 it would have caused spurious changes in behaviour when handling
 OSVW_{ID_LENGTH,STATUS} read requests on behalf of an already-running 
 guest.

 There are plenty of other aspects of domain creation which depend on 
 hardware
 details which may change across a microcode load, but where not protected 
 by
 this interlock.
>>> Are there? We don't re-read CPUID (yet), for example. But of
>>> course it is also not really specified which aspects may change
>>> across microcode updates.
>>>
 A host administrator choosing to perform late microcode loading has plenty 
 of
 other problems to worry about, and is it not unreasonable to expect them to
 temporarily cease domain construction activities while the microcode 
 loading
 is in progress.
>>> But it is also not unreasonable to expect the hypervisor to guard
>>> against inconsistencies here. On the whole I'm not really
>>> convinced; I think I'd like to hear others' opinions.
>> The underlying problem is that this lock cannot say when merging
>> max_cpus into createdomain, because we cannot continue the hypercall
>> midway through.
>>
>> As it doesn't currently protect createdomain, which amongst other things
>> contains init_domain_cpuid_policy() and init_domain_msr_policy() (the
>> most likely structures to be affected by microcode updates), I don't see
>> any purpose in keeping it for the minute area it does cover.
> What about failing domain creation e.g. via -EAGAIN in case a
> microcode update happened in between? This would be easy by adding a
> microcode generation count which would have to be the same for start
> and end of the create domain hypercall.

Failing the hypercall is very complicated once domain_create() has
completed successfully.  See patch 11

(Although in writing this reply, I see that patch 11 is buggy).

Amongst other things, failing that late burns a domid, because there is
a period during which the domain has to live in the domain list.

I don't see the point of trying to retain a broken mechanism, especially
at the expense of error path complexity.

~Andrew

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

Re: [Xen-devel] [PATCH v4 2/4] libxl/x86: Build e820 map earlier for HVM/PVH guests

[Boris Ostrovsky]

On 03/21/2018 01:49 PM, Wei Liu wrote:
> On Tue, Mar 20, 2018 at 09:50:50AM -0700, Maran Wilson wrote:
>>  case LIBXL_DOMAIN_TYPE_PV:
>> -ret = libxl__build_pv(gc, domid, info, state);
>> +ret = libxl__build_pv(gc, domid, d_config, info, state);
>>  if (ret)
>>  goto out;
>>  
>> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
>> index 2e29b52..e83aeb9 100644
>> --- a/tools/libxl/libxl_dom.c
>> +++ b/tools/libxl/libxl_dom.c
>> @@ -698,6 +698,7 @@ static int set_vnuma_info(libxl__gc *gc, uint32_t domid,
>>  }
>>  
>>  static int libxl__build_dom(libxl__gc *gc, uint32_t domid,
>> + libxl_domain_config *d_config,
>>   libxl_domain_build_info *info, libxl__domain_build_state 
>> *state,
> AFAICT build_info is a member of domain_config. You can only take the
> latter in this function. Further adjustment is required to accommodate
> that change.


Yes, Roger also pointed this out to me.

-boris

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

Re: [Xen-devel] [for-4.11][PATCH v6 01/16] x86/mm: skip incrementing mfn if it is not a valid mfn

[Wei Liu]

On Wed, Mar 21, 2018 at 04:47:22AM +, Julien Grall wrote:
> From: Wei Liu 
> 
> In a follow-up patches, some callers will be switched to pass

s/patches/patch/

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

Re: [Xen-devel] [PATCH v4 4/4] libxc: Pass e820 map to HVM/PVH guests via hvm_start_info

[Boris Ostrovsky]

On 03/21/2018 10:18 AM, Roger Pau Monné wrote:
> On Wed, Mar 21, 2018 at 09:37:09AM -0400, Boris Ostrovsky wrote:
>> On 03/21/2018 06:07 AM, Roger Pau Monné wrote:
>>> On Tue, Mar 20, 2018 at 09:50:52AM -0700, Maran Wilson wrote:
 From: Boris Ostrovsky 

 Signed-off-by: Boris Ostrovsky 
 Signed-off-by: Maran Wilson 
 ---
  tools/libxc/xc_dom_x86.c | 29 -
  1 file changed, 28 insertions(+), 1 deletion(-)

 diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
 index 0b65dab..b2d8403 100644
 --- a/tools/libxc/xc_dom_x86.c
 +++ b/tools/libxc/xc_dom_x86.c
 @@ -35,6 +35,8 @@
  #include 
  #include 
  
 +#include 
 +
  #include "xg_private.h"
  #include "xc_dom.h"
  #include "xenctrl.h"
 @@ -640,6 +642,8 @@ static int alloc_magic_pages_hvm(struct xc_dom_image 
 *dom)
  dom->cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
  start_info_size += dom->cmdline_size;
  }
 +
 +start_info_size += dom->e820_entries * sizeof(*(dom->e820));
>>> This is not correct because sizeof(struct e820entry) != sizeof(struct
>>> hvm_modlist_entry) AFAICT. This should instead be sizeof(struct
>>> hvm_modlist_entry).
>>
>> The area for modlist is calculated above:
>>
>> start_info_size +=
>>     sizeof(struct hvm_modlist_entry) * HVMLOADER_MODULE_MAX_COUNT;
>>
>> (What I should do though is move this from under 'if (
>> !dom->device_model )', now that we are providing this data to both HVM
>> and PVH guests.
> Sorry, I meant sizeof(struct hvm_memmap_table_entry) != sizeof(e820entry), so
> the above should be:
>
> start_info_size += dom->e820_entries * sizeof(struct hvm_memmap_table_entry);


Oh, duh!

>
  }
  else
  {
 @@ -1666,8 +1670,9 @@ static int bootlate_hvm(struct xc_dom_image *dom)
  uint32_t domid = dom->guest_domid;
  xc_interface *xch = dom->xch;
  struct hvm_start_info *start_info;
 -size_t start_info_size;
 +size_t start_info_size, modsize;
  struct hvm_modlist_entry *modlist;
 +struct hvm_memmap_table_entry *memmap;
  unsigned int i;
  
  start_info_size = sizeof(*start_info) + dom->cmdline_size;
 @@ -1731,7 +1736,29 @@ static int bootlate_hvm(struct xc_dom_image *dom)
  ((uintptr_t)modlist - (uintptr_t)start_info);
  }
  
 +/*
 + * Check a couple of XEN_HVM_MEMMAP_TYPEs to verify consistency with
 + * their corresponding e820 numerical values.
 + */
 +BUILD_BUG_ON(XEN_HVM_MEMMAP_TYPE_RAM != E820_RAM);
 +BUILD_BUG_ON(XEN_HVM_MEMMAP_TYPE_ACPI != E820_ACPI);
 +
 +modsize = HVMLOADER_MODULE_MAX_COUNT *
 +(sizeof(*modlist) + HVMLOADER_MODULE_CMDLINE_SIZE);
>>> Hm, I'm not sure this is fully correct, but I think there are previous
>>> issues in this area.
>>>
>>> The mapped area (start_info) is of size sizeof(*start_info) +
>>> dom->cmdline_size + sizeof(struct hvm_modlist_entry) *
>>> dom->num_modules. Yet here you seem to assume num_modules ==
>>> HVMLOADER_MODULE_MAX_COUNT?
>> Yes, see my response above. We've already allocated the segment to
>> accommodate HVMLOADER_MODULE_MAX_COUNT entries. Which may indeed be an
>> overkill.
> I'm sorry, but I don't think I follow. There's only a single
> xc_map_foreign_range call that maps start_info_size space:
>
> start_info_size = sizeof(*start_info) + dom->cmdline_size;
> start_info_size += sizeof(struct hvm_modlist_entry) * dom->num_modules;
>
> So for start_info_size bootlate_hvm takes into account the exact
> number of modules used.
>
> Yet modsize seems to assume dom->num_modules ==
> HVMLOADER_MODULE_MAX_COUNT?


If you look at add_module_to_list() above you'll notice that it stores
modules' commandlines after HVMLOADER_MODULE_MAX_COUNT modules:

    void *modules_cmdline_start = modlist + HVMLOADER_MODULE_MAX_COUNT;


One thing I could do is

    modsize = HVMLOADER_MODULE_MAX_COUNT *(sizeof(*modlist)) + 
dom->num_modules * HVMLOADER_MODULE_CMDLINE_SIZE;

but I think the resulting difference between expected/reserved number of
modules vs number of commandlines makes this not worthwhile.

(As a side note, dom->num_modules is meaningless for HVM guests here ---
we only add one module, the FW blob.)


>
> I think those are all previous issues in this code, TBH.
>
>>> Also the initial space calculation doesn't seem to take
>>> HVMLOADER_MODULE_CMDLINE_SIZE into account at all.
>>
>> modlist's offset is calculated with commandline's size in mind:
>>
>>     modlist = (void*)(start_info + 1) + dom->cmdline_size;
> Yes, that's fine AFAICT.
>
>>> And cmdline_paddr seems to be set to point to garbage if cmdline is not
>>> set.
>> Isn't the hvm_start_info set to zero when allocated?
> Yes, but the following code in add_module_to_list seems wrong to me:
>
> if ( cmdline )
> 

Re: [Xen-devel] [PATCH v4 2/4] libxl/x86: Build e820 map earlier for HVM/PVH guests

[Wei Liu]

On Tue, Mar 20, 2018 at 09:50:50AM -0700, Maran Wilson wrote:
>  case LIBXL_DOMAIN_TYPE_PV:
> -ret = libxl__build_pv(gc, domid, info, state);
> +ret = libxl__build_pv(gc, domid, d_config, info, state);
>  if (ret)
>  goto out;
>  
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 2e29b52..e83aeb9 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -698,6 +698,7 @@ static int set_vnuma_info(libxl__gc *gc, uint32_t domid,
>  }
>  
>  static int libxl__build_dom(libxl__gc *gc, uint32_t domid,
> + libxl_domain_config *d_config,
>   libxl_domain_build_info *info, libxl__domain_build_state *state,

AFAICT build_info is a member of domain_config. You can only take the
latter in this function. Further adjustment is required to accommodate
that change.

Wei.

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

Re: [Xen-devel] [PATCH 11/20] xen/domctl: Merge set_gnttab_limits into createdomain

[Wei Liu]

On Mon, Mar 19, 2018 at 07:13:50PM +, Andrew Cooper wrote:
> XEN_DOMCTL_set_gnttab_limits is a fairly new hypercall, and is strictly
> mandatory.  Adding support for it introduced a state where a domain has a
> mostly un-constructed grant table, and there were cases where mis-ordering of
> toolstack hypercalls could cause a NULL pointer deference in the hypervisor.
> In fixing this, the grant table initialisation code became very tangled.
> 
> As the settings are mandatory, delete XEN_DOMCTL_set_gnttab_limits (including
> XSM hooks and libxc wrappers) and retain the functionality in
> XEN_DOMCTL_createdomain.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 12/20] xen/domctl: Merge max_vcpus into createdomain

[Wei Liu]

On Mon, Mar 19, 2018 at 07:13:51PM +, Andrew Cooper wrote:
> XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a
> toolstack from unpausing a domain with no vcpus.
> 
> Originally, d->vcpus[] was an embedded array in struct domain, but c/s
> fb442e217 "x86_64: allow more vCPU-s per guest" in Xen 4.0 altered it to being
> dynamically allocated.  A side effect of this is that d->vcpu[] is NULL until
> XEN_DOMCTL_max_vcpus has completed, but a lot of hypercalls blindly
> dereference it.
> 
> Even today, the behaviour of XEN_DOMCTL_max_vcpus is a mandatory singleton
> call which can't change the number of vcpus once a value has been chosen.
> Therefore, delete XEN_DOMCTL_max_vcpus (including XSM hooks and toolstack
> wrappers) and retain the functionality in XEN_DOMCTL_createdomain.
> 
> This will allow future cleanup to ensure that d->vcpus[] is always valid for a
> locatable domain, and allow simplification of some creation logic which needs
> to size domain-wide objects based on max_cpus, which currently have to be
> deferred until vcpu construction.
> 
> For the python stubs, extend the domain_create keyword list to take a
> max_vcpus parameter, in lieu of deleting the pyxc_domain_max_vcpus function.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Alexey G]

On Wed, 21 Mar 2018 14:54:16 +
Paul Durrant  wrote:

>> -Original Message-
>> From: Alexey G [mailto:x19...@gmail.com]
>> Sent: 21 March 2018 14:26
>> To: Roger Pau Monne 
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
>> ; Ian Jackson ;
>> Jan Beulich ; Wei Liu ; Paul
>> Durrant ; Anthony Perard
>> ; Stefano Stabellini
>>  Subject: Re: [Xen-devel] [RFC PATCH 07/12]
>> hvmloader: allocate MMCONFIG area in the MMIO hole + minor code
>> refactoring
>> 
>> On Wed, 21 Mar 2018 09:09:11 +
>> Roger Pau Monné  wrote:
>>   
>> >On Wed, Mar 21, 2018 at 10:58:40AM +1000, Alexey G wrote:  
>> [...]  
>> >> According to public slides for the feature, both PCI conf and MMIO
>> >> accesses can be routed to the designated device model. It looks
>> >> like for this particular setup it doesn't really matter which
>> >> particular ioreq type must be used for MMCONFIG accesses -- either
>> >> IOREQ_TYPE_PCI_CONFIG or IOREQ_TYPE_COPY (MMIO accesses) should  
>> be  
>> >> acceptable.  
>> >
>> >Isn't that going to be quite messy? How is the IOREQ server supposed
>> >to decode a MCFG access received as IOREQ_TYPE_COPY?  
>> 
>> This code is already available and in sync with QEMU legacy PCI conf
>> emulation infrastructure.
>>   
>> >I don't think the IOREQ server needs to know the start of the MCFG
>> >region, in which case it won't be able to detect and decode the
>> >access if it's of type IOREQ_TYPE_COPY.  
>> 
>> How do you think Xen will be able to know if arbitrary MMIO
>> access targets MMCONFIG area and to which BDF the offset in this area
>> belongs, without knowing where MMCONFIG is located and what PCI bus
>> layout is? It's QEMU who emulate PCIEXBAR and can tell Xen where
>> MMCONFIG is expected to be.
>>   
>> >MCFG accesses need to be sent to the IOREQ server as
>> >IOREQ_TYPE_PCI_CONFIG, or else you are forcing each IOREQ server to
>> >know the position of the MCFG area in order to do the decoding. In
>> >your case this would work because QEMU controls the position of the
>> >MCFG region, but there's no need for other IOREQ servers to know the
>> >position of the MCFG area.
>> >  
>> >> The only thing which matters is ioreq routing itself --
>> >> making decisions to which device model the PCI conf/MMIO ioreq
>> >> should be sent.  
>> >
>> >Hm, see above, but I'm fairly sure you need to forward those MCFG
>> >accesses as IOREQ_TYPE_PCI_CONFIG to the IOREQ server.  
>> 
>> (a detailed answer below)
>>   
>> >> >Traditional PCI config space accesses are not IO port space
>> >> >accesses.  
>> >>
>> >> (assuming 'not' mistyped here)  
>> >
>> >Not really, this should instead be:
>> >
>> >"Traditional PCI config space accesses are not forwarded to the
>> >IOREQ server as IO port space accesses (IOREQ_TYPE_PIO) but rather
>> >as PCI config space accesses (IOREQ_TYPE_PCI_CONFIG)."
>> >
>> >Sorry for the confusion.
>> >  
>> >> >The IOREQ code in Xen detects accesses to ports 0xcf8/0xcfc and
>> >> >IOREQ servers can register devices they would like to receive
>> >> >configuration space accesses for. QEMU is already making use of
>> >> >this, see for  
>> >>
>> >> That's one of the reasons why current IOREQ_TYPE_PCI_CONFIG
>> >> implementation is a bit inconvenient for MMCONFIG MMIO accesses --
>> >> it's too much CF8h/CFCh-centric in its implementation, might be
>> >> painful to change something in the code which was intended for
>> >> CF8h/CFCh handling (and not for MMIO processing).  
>> >
>> >I'm not sure I follow. Do you mean that changes should be made to
>> >the ioreq struct in order to forward MCFG accesses using
>> >IOREQ_TYPE_PCI_CONFIG as it's type?  
>> 
>> No changes for ioreq structures needed for now.
>>   
>> >> It will be handled by IOREQ too, just using a different IOREQ type
>> >> (MMIO one). The basic question is why do we have to stick to PCI
>> >> conf space ioreqs for emulating MMIO accesses to MMCONFIG.  
>> >
>> >Because other IOREQ servers don't need to know about the
>> >position/size of the MCFG area, and cannot register MMIO ranges
>> >that cover their device's PCI configuration space in the MCFG
>> >region.
>> >
>> >Not to mention that it would would be a terrible design flaw to
>> >force IOREQ servers to register PCI devices and MCFG areas
>> >belonging to those devices separately as MMIO in order to trap all
>> >possible PCI configuration space accesses.  
>> 
>> PCI conf space layout is shared by the emulated machine. And MMCONFIG
>> layout is mandated by this common PCI bus map.
>> 
>> Even if those 'multiple device models' see a different picture of PCI
>> conf space, their visions of PCI bus must not overlap + MMCONFIG
>> layout must be consistent between different device models.
>> 
>> Although it is a terrible mistake to think about the emulated PCI bus
>> like it's a set of distinct PCI devices unrelated to each other. It's
>> all coupled together. And this is especially true for PCIe.
>> Many PCIe features rely on PCIe device interaction in PCIe fabric,
>> 

Re: [Xen-devel] [PATCH 10/20] xen/domctl: Merge set_max_evtchn into createdomain

[Wei Liu]

On Mon, Mar 19, 2018 at 07:13:49PM +, Andrew Cooper wrote:
> set_max_evtchn is somewhat weird.  It was introduced with the event_fifo work,
> but has never been used.  Still, it is a bounding on resources consumed by the
> event channel infrastructure, and should be part of createdomain, rather than
> editable after the fact.
> 
> Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
> wrappers), and retain the functionality in XEN_DOMCTL_createdomain.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 09/20] tools: Rework xc_domain_create() to take a full xen_domctl_createdomain

[Wei Liu]

On Mon, Mar 19, 2018 at 07:13:48PM +, Andrew Cooper wrote:
> In future patches, the structure will be extended with further information,
> and this is far cleaner than adding extra parameters.
> 
> The python stubs are the only user which passes NULL for the existing config
> option (which is actually the arch substructure).  Therefore, the #ifdefary
> moves to compensate.
> 
> For libxl, pass the full config object down into
> libxl__arch_domain_{prepare,save}_config(), as there are in practice arch
> specific settings in the common part of the structure (flags s3_integrity and
> oos_off specifically).
> 
> No practical change in behaviour.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 02/20] tools/libxl: Don't prepare or save xc_config when soft resetting a domain

[Andrew Cooper]

On 21/03/18 16:18, Roger Pau Monné wrote:
> On Mon, Mar 19, 2018 at 07:13:41PM +, Andrew Cooper wrote:
>> xc_config is only used by xc_domain_create(), but by calling
>> libxl__arch_domain_{prepare,save}_config() we clobber the real settings with
>> the default settings.
>>
>> Move all data and calls relating to xc_domain_create() into the path which
>> calls it.
>>
>> As far as I can tell, soft_reset has always been broken for ARM domains using
>> LIBXL_GIC_VERSION_DEFAULT, which elicits a hard error out of
>> libxl__arch_domain_save_config().
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Roger Pau Monné 
>
> AFAICT this didn't affect x86 because libxl__arch_domain_save_config
> is a noop?

Correct.  I've tweaked the commit message to include this.

~Andrew

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

Re: [Xen-devel] [PATCH 03/20] xen/public: Rename xen_domctl_createdomain.config to arch

[Wei Liu]

On Mon, Mar 19, 2018 at 07:13:42PM +, Andrew Cooper wrote:
> This is a tools only hypercall so fine to change.  Altering the name avoids
> having confusing code such as config->config all over the hypervisor and
> toolstack.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 02/20] tools/libxl: Don't prepare or save xc_config when soft resetting a domain

[Wei Liu]

On Mon, Mar 19, 2018 at 07:13:41PM +, Andrew Cooper wrote:
> xc_config is only used by xc_domain_create(), but by calling
> libxl__arch_domain_{prepare,save}_config() we clobber the real settings with
> the default settings.
> 
> Move all data and calls relating to xc_domain_create() into the path which
> calls it.
> 
> As far as I can tell, soft_reset has always been broken for ARM domains using
> LIBXL_GIC_VERSION_DEFAULT, which elicits a hard error out of
> libxl__arch_domain_save_config().
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 01/20] tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state

[Wei Liu]

On Mon, Mar 19, 2018 at 07:13:40PM +, Andrew Cooper wrote:
> The data it stores is initialised and exclusively used within
> libxl__domain_make(), with the important details written back elsewhere by
> libxl__arch_domain_save_config().  Prepare xc_config on libxl__domain_make()'s
> stack, and drop the parameter.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/2] tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state

[Wei Liu]

On Fri, Mar 16, 2018 at 02:06:39PM +, Andrew Cooper wrote:
> The data it stores is initialised and exclusively used within
> libxl__domain_make(), with the important details written back elsewhere by
> libxl__arch_domain_save_config().  Prepare xc_config on libxl__domain_make()'s
> stack, and drop the parameter.
> 
> Signed-off-by: Andrew Cooper 

These two patches are superseded by your other series AIUI.

Wei.

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Roger Pau Monné]

On Thu, Mar 22, 2018 at 02:56:56AM +1000, Alexey G wrote:
> On Wed, 21 Mar 2018 15:20:17 +
> Roger Pau Monné  wrote:
> 
> >On Thu, Mar 22, 2018 at 12:25:40AM +1000, Alexey G wrote:
> >> 8. As these MMCONFIG PCI conf reads occur out of context (just
> >> address/len/data without any emulated device attached to it),
> >> xen-hvm.c should employ special logic to make it QEMU-friendly --
> >> eg. right now it sends received PCI conf access into (emulated by
> >> QEMU) CF8h/CFCh ports.
> >> There is a real problem to embed these "naked" accesses into QEMU
> >> infrastructure, workarounds are required. BTW, find_primary_bus() was
> >> dropped from QEMU code -- it could've been useful here. Let's assume
> >> some workaround is employed (like storing a required object pointers
> >> in global variables for later use in xen-hvm.c)  
> >
> >That seems like a minor nit, but why not just use
> >address_space_{read/write} to replay the MCFG accesses as memory
> >read/writes?
> 
> Well, this might work actually. Although the overall scenario will be
> overcomplicated a bit for _PCI_CONFIG ioreqs. Here is how it will look:
> 
> QEMU receives PCIEXBAR update -> calls the new dmop to tell Xen new
> MMCONFIG address/size -> Xen (re)maps MMIO trapping area -> someone is
> accessing this area -> Xen intercepts this MMIO access
> 
> But here's what happens next:
> 
> Xen translates MMIO access into PCI_CONFIG and sends it to DM ->
> DM receives _PCI_CONFIG ioreq -> DM translates BDF/addr info back to
> the offset in emulated MMCONFIG range -> DM calls
> address_space_read/write to trigger MMIO emulation
> 
> I tnink some parts of this equation can be collapsed, isn't it?
> 
> Above scenario makes it obvious that at least for QEMU the MMIO->PCI
> conf translation is a redundant step. Why not to allow specifying for DM
> whether it prefers to receive MMCONFIG accesses as native (MMIO ones)
> or as translated PCI conf ioreqs?

You are just adding an extra level of complexity to an interface
that's fairly simple. You register a PCI device using
XEN_DMOP_IO_RANGE_PCI and you get IOREQ_TYPE_PCI_CONFIG ioreqs.
Getting both IOREQ_TYPE_PCI_CONFIG and IOREQ_TYPE_COPY for PCI config
space access is misleading.

In both cases Xen would have to do the MCFG access decoding in order
to figure out which IOREQ server will handle the request. At which
point the only step that you avoid is the reconstruction of the memory
access from the IOREQ_TYPE_PCI_CONFIG which is trivial.

> We can still route either ioreq
> type to multiple device emulators accordingly.

It's exactly the same that's done for IO space PCI config space
addresses. QEMU gets an IOREQ_TYPE_PCI_CONFIG and it replays the IO
space access using do_outp and cpu_ioreq_pio.

If you think using IOREQ_TYPE_COPY for MCFG accesses is such a benefit
for QEMU, why not just translate the IOREQ_TYPE_PCI_CONFIG into
IOREQ_TYPE_COPY in handle_ioreq and dispatch it using
cpu_ioreq_move?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v1] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Wei Liu]

On Fri, Mar 16, 2018 at 11:04:22PM +0530, Amit Singh Tomar wrote:
> diff --git a/xen/drivers/char/mvebu-uart.c b/xen/drivers/char/mvebu-uart.c
> new file mode 100644
> index 000..c88d5e7
> --- /dev/null
> +++ b/xen/drivers/char/mvebu-uart.c
> @@ -0,0 +1,260 @@
> +/*
> + * xen/drivers/char/mvebu3700-uart.c
> + *
> + * Driver for Marvell MVEBU UART.
> + *
> + * Amit Singh Tomar 
> + * Copyright (c) 2018.
> + *
> + * 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.
> + *

Picking which licence is entirely up to you. But may I suggest you use
the section in CONTRIBUTING file? The new hypervisor code is normally
GPL v2 only.

Wei.

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

Re: [Xen-devel] [RFC PATCH 08/12] libxl: Q35 support (new option device_model_machine)

[Anthony PERARD]

On Wed, Mar 21, 2018 at 04:27:43PM +, Wei Liu wrote:
> On Tue, Mar 20, 2018 at 09:11:10AM +, Roger Pau Monné wrote:
> > On Tue, Mar 20, 2018 at 08:11:49AM +1000, Alexey G wrote:
> > > On Mon, 19 Mar 2018 17:01:18 +
> > > Roger Pau Monné  wrote:
> > > 
> > > >On Tue, Mar 13, 2018 at 04:33:53AM +1000, Alexey Gerasimenko wrote:
> > > >> Provide a new domain config option to select the emulated machine
> > > >> type, device_model_machine. It has following possible values:
> > > >> - "i440" - i440 emulation (default)
> > > >> - "q35" - emulate a Q35 machine. By default, the storage interface
> > > >> is AHCI.  
> > > >
> > > >I would rather name this machine_chipset or device_model_chipset.
> > > 
> > > device_model_ prefix is a must I think -- multiple device model related
> > > options have names starting with device_model_.
> > > 
> > > device_model_chipset... well, maybe, but we're actually specifying a
> > > QEMU machine here. In QEMU mailing list there was even a suggestion
> > > to allow to pass a machine version number here, like "pc-q35-2.10".
> > > I think some opinions are needed here.
> > 
> > I'm not sure what a 'machine' is in QEMU speak, but in my mind I would
> > consider PC a machine (vs ARM for example).
> > 
> > I think 'chipset' is clearer, but again others should express their
> > opinion.
> 
> AIUI machine is a collection of chipset and peripherals, i.e. it covers
> more than the chipset alone.

The description of the QEMU machine "q35" is
"Standard PC (Q35 + ICH9, 2009)". So right in the description, Q35 is
not enought to describe what -machine=q35 is about. And FYI "pc" or
"pc_piix" description is "Standard PC (i440FX + PIIX, 1996)".

Also, we could expand the option to actually allow a user to select the
exact version of the QEMU machine to use. Having "pc-i440fx-2.12" in
the xl config file instead of just "pc" could prevent compatibility
issue for an existing virtual machine.

I don't know what a chipset is when related to QEMU, beside being a
piece of silicon in hardware. I think a QEMU machine is closer to a
motherboard than just a chipset. Feel free to read
"qemu.git/hw/i386/pc_piix.c" and "qemu.git/hw/i386/pc_q35.c"
to read the difference between both machine.

Anyway, I think "device_model_machine" is better that ".._chipset".
"machine" better describe the change involve when selecting q35.

-- 
Anthony PERARD

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Paul Durrant]

> -Original Message-
> From: Alexey G [mailto:x19...@gmail.com]
> Sent: 21 March 2018 16:57
> To: Roger Pau Monne 
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Ian Jackson ; Jan
> Beulich ; Wei Liu ; Paul Durrant
> ; Anthony Perard ;
> Stefano Stabellini 
> Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG
> area in the MMIO hole + minor code refactoring
> 
> On Wed, 21 Mar 2018 15:20:17 +
> Roger Pau Monné  wrote:
> 
> >On Thu, Mar 22, 2018 at 12:25:40AM +1000, Alexey G wrote:
> >> Roger, Paul,
> >>
> >> Here is what you suggest, just to clarify:
> >>
> >> 1. Add to Xen a new hypercall (+corresponding dmop) so QEMU can tell
> >> Xen where QEMU emulates machine's MMCONFIG (chipset-specific
> >> emulation of PCIEXBAR/HECBASE/etc mmcfg relocation). Xen will rely
> >> on this information to know to which PCI device the address within
> >> MMCONFIG belong.
> >>
> >> 2. Xen will trap this area + remap its trapping to other address if
> >> QEMU will inform Xen about emulated PCIEXBAR value change
> >>
> >> 3. Every MMIO access to the current MMCONFIG range will be converted
> >> into BDF first (by offset within this range, knowing where the range
> >> is)
> >>
> >> 4. Target device model is selected using calculated BDF
> >>
> >> 5. MMIO read/write accesses are converted into PCI config space
> >> ioreqs (like it was a CF8/CFCh operation instead of MMIO access). At
> >> this point ioreq structure allows to specify extended PCI conf offset
> >> (12-bit), so it will fit into PCI conf ioreq. For now let's assume
> >> that eg. a 64-bit memory operation is either aborted or workarounded
> >> by splitting this operation into multiple PCI conf ioreqs.
> >
> >Why can't you just set size = 8 in that case in the ioreq?
> >
> >QEMU should then reject those if the chipset doesn't support 64bit
> >accesses. I cannot find in the spec any mention of whether this
> >chipset supports 64bit MCFG accesses, and according to the PCIe spec
> >64bit accesses to MCFG should not be used unless the chipset is known
> >to handle them correctly.
> Yes, uint64_t should be enough in this particular case in fact, though
> memory nature of MMCONFIG accesses might still require to provide
> specific handling.
> 
> 
> All right then, so it will be a dmop/hypercall to tell Xen where to
> trap MMIO accesses to MMCONFIG as you propose.
> 
> The primary device model (QEMU) will be emulating chipset-specific
> PCIEXBAR/etc and issuing this new dmop to tell Xen which area it needs
> to trap for MMIO MMCONFIG acceses. It's basically what
> map_io_range_to_ioreq_server does currently, but I guess a new dedicated
> dmop/hypercall is bearable.
> 
> >> 6. PCI conf read/write ioreqs are sent to the chosen device model
> >>
> >> 7. QEMU receive MMCONFIG memory reads/writes as PCI conf
> reads/writes
> >>
> >> 8. As these MMCONFIG PCI conf reads occur out of context (just
> >> address/len/data without any emulated device attached to it),
> >> xen-hvm.c should employ special logic to make it QEMU-friendly --
> >> eg. right now it sends received PCI conf access into (emulated by
> >> QEMU) CF8h/CFCh ports.
> >> There is a real problem to embed these "naked" accesses into QEMU
> >> infrastructure, workarounds are required. BTW, find_primary_bus() was
> >> dropped from QEMU code -- it could've been useful here. Let's assume
> >> some workaround is employed (like storing a required object pointers
> >> in global variables for later use in xen-hvm.c)
> >
> >That seems like a minor nit, but why not just use
> >address_space_{read/write} to replay the MCFG accesses as memory
> >read/writes?
> 
> Well, this might work actually. Although the overall scenario will be
> overcomplicated a bit for _PCI_CONFIG ioreqs. Here is how it will look:
> 
> QEMU receives PCIEXBAR update -> calls the new dmop to tell Xen new
> MMCONFIG address/size -> Xen (re)maps MMIO trapping area -> someone
> is
> accessing this area -> Xen intercepts this MMIO access
> 
> But here's what happens next:
> 
> Xen translates MMIO access into PCI_CONFIG and sends it to DM ->
> DM receives _PCI_CONFIG ioreq -> DM translates BDF/addr info back to
> the offset in emulated MMCONFIG range -> DM calls
> address_space_read/write to trigger MMIO emulation
> 

That would only be true of a dm that cannot handle PCI config ioreqs directly.

  Paul

> I tnink some parts of this equation can be collapsed, isn't it?
> 
> Above scenario makes it obvious that at least for QEMU the MMIO->PCI
> conf translation is a redundant step. Why not to allow specifying for DM
> whether it prefers to receive MMCONFIG accesses as native (MMIO ones)
> or as translated PCI conf ioreqs? We can still route either ioreq
> type to multiple device emulators accordingly.
> 
> This will be the most universal and consistent approach -- either _COPY
> or _PCI_CONFIG-type ioreqs can be sent to DM, whatever it likes more.
> 
> >> 9. Existing MMCONFIG-handling code in QEMU will be unused in this
> >>

Re: [Xen-devel] [PATCH v3 11/39] Add list_sort() routine from Linux

[Jan Beulich]

>>> On 21.03.18 at 17:32,  wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -44,6 +44,9 @@ config HAS_GDBSX
>  config HAS_IOPORTS
>   bool
>  
> +config NEEDS_LIST_SORT
> +bool
> +
>  config HAS_BUILD_ID
>   string
>   option env="XEN_HAS_BUILD_ID"

Please look at surrounding code when adding new entries: Tabs are
used for indentation here.

Jan


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

Re: [Xen-devel] [PATCH v4 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

[Roger Pau Monné]

On Wed, Mar 21, 2018 at 09:46:21AM -0700, Maran Wilson wrote:
> On 3/21/2018 2:40 AM, Juergen Gross wrote:
> > On 21/03/18 10:28, Roger Pau Monné wrote:
> > > On Tue, Mar 20, 2018 at 09:48:56AM -0700, Maran Wilson wrote:
> > > > +/*
> > > >* C representation of the x86/HVM start info layout.
> > > >*
> > > >* The canonical definition of this layout is above, this is just a 
> > > > way to
> > > > @@ -86,6 +134,14 @@ struct hvm_start_info {
> > > >   uint64_t cmdline_paddr; /* Physical address of the command 
> > > > line. */
> > > >   uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI 
> > > > data*/
> > > >   /* structure. 
> > > >*/
> > > > +uint64_t memmap_paddr;  /* Physical address of an array of 
> > > >   */
> > > > +/* hvm_memmap_table_entry. Only 
> > > > present in   */
> > > > +/* version 1 and newer of the 
> > > > structure  */
> > > > +uint32_t memmap_entries;/* Number of entries in the memmap 
> > > > table.*/
> > > > +/* Only present in version 1 and newer 
> > > > of*/
> > > > +/* the structure. Value will be zero 
> > > > if  */
> > > > +/* there is no memory map being 
> > > > provided.*/
> > > > +uint32_t reserved;  /* Must be zero for Version 1. 
> > > >   */
> > > I would write "Must be zero." only. If at some point we introduce
> > > version 2 we would likely have to fixup this comment to mention
> > > version 1 and version 2.
> > In case you are going this route I'd suggest to drop the version remarks
> > for the individual fields and just add a comment like:
> > 
> > /* All following fields only present in version 1 and newer. */
> > 
> > above memmap_paddr.
> 
> OK, so combining the above suggestions, I'd have the following. Is the
> formatting and alignment of comments what you had in mind and acceptable to
> all?

It seems like your email client has skewed the formatting (or maybe
mine...)

Anyway, LGTM, I think this is better.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v3 8/8] ci: add new bits to MAINTAINERS combine with Travis

[Wei Liu]

On Wed, Mar 21, 2018 at 11:09:13AM -0500, Doug Goldstein wrote:
> On 3/21/18 6:11 AM, George Dunlap wrote:
> > On 03/21/2018 03:01 AM, Doug Goldstein wrote:
> >> Created a new section just called 'CI' since this is adding GitLab CI
> >> and still leaving the old Travis CI files around. This consolidates the
> >> two sections and adds the new files as well as adding another Travis
> >> file that was missing.
> >>
> >> Signed-off-by: Doug Goldstein 
> >> Reviewed-by: Konrad Rzeszutek Wilk 
> >> ---
> >>  MAINTAINERS | 16 ++--
> >>  1 file changed, 10 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index a5b3e95..81ec312 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -181,6 +181,16 @@ BLKTAP2
> >>  S:Orphaned
> >>  F:tools/blktap2/
> >>  
> >> +CI
> >> +M:Doug Goldstein 
> >> +W:https://gitlab.com/xen-project/xen
> >> +W:https://travis-ci.org/xen-project/xen
> >> +S:Supported
> >> +F:.gitlab-ci.yml
> >> +F:.travis.yml
> >> +F:automation/
> >> +F:scripts/travis-build
> > 
> > "CI" seems awfully short without a context.  "Travis CI" gives you
> > enough context to figure out what CI is (or enough to Google it).
> > 
> > "Automation / CI"?  "Continuous Integration (CI)"?
> > 
> > Otherwise +1.
> > 
> >  -George
> > 
> 
> Let's go with "Continuous Integration (CI)". I can post a follow up if
> that's helpful.
> 

Give me a branch to pull from. That's better.

Wei.

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

Re: [Xen-devel] [PATCH RESEND 3/4] xen: sched: improve checking soft-affinity

[Dario Faggioli]

On Wed, 2018-03-21 at 15:24 +, George Dunlap wrote:
> 
> If you're OK with those changes, 
>
I am cool with every one of them.

> I can make them on check-in (as well as
> changing your email address)
> 
And thanks for this as well,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

[Alexey G]

On Wed, 21 Mar 2018 15:20:17 +
Roger Pau Monné  wrote:

>On Thu, Mar 22, 2018 at 12:25:40AM +1000, Alexey G wrote:
>> Roger, Paul,
>> 
>> Here is what you suggest, just to clarify:
>> 
>> 1. Add to Xen a new hypercall (+corresponding dmop) so QEMU can tell
>> Xen where QEMU emulates machine's MMCONFIG (chipset-specific
>> emulation of PCIEXBAR/HECBASE/etc mmcfg relocation). Xen will rely
>> on this information to know to which PCI device the address within
>> MMCONFIG belong.
>> 
>> 2. Xen will trap this area + remap its trapping to other address if
>> QEMU will inform Xen about emulated PCIEXBAR value change
>> 
>> 3. Every MMIO access to the current MMCONFIG range will be converted
>> into BDF first (by offset within this range, knowing where the range
>> is)
>> 
>> 4. Target device model is selected using calculated BDF
>> 
>> 5. MMIO read/write accesses are converted into PCI config space
>> ioreqs (like it was a CF8/CFCh operation instead of MMIO access). At
>> this point ioreq structure allows to specify extended PCI conf offset
>> (12-bit), so it will fit into PCI conf ioreq. For now let's assume
>> that eg. a 64-bit memory operation is either aborted or workarounded
>> by splitting this operation into multiple PCI conf ioreqs.  
>
>Why can't you just set size = 8 in that case in the ioreq?
>
>QEMU should then reject those if the chipset doesn't support 64bit
>accesses. I cannot find in the spec any mention of whether this
>chipset supports 64bit MCFG accesses, and according to the PCIe spec
>64bit accesses to MCFG should not be used unless the chipset is known
>to handle them correctly.
Yes, uint64_t should be enough in this particular case in fact, though
memory nature of MMCONFIG accesses might still require to provide
specific handling.


All right then, so it will be a dmop/hypercall to tell Xen where to
trap MMIO accesses to MMCONFIG as you propose.

The primary device model (QEMU) will be emulating chipset-specific
PCIEXBAR/etc and issuing this new dmop to tell Xen which area it needs
to trap for MMIO MMCONFIG acceses. It's basically what
map_io_range_to_ioreq_server does currently, but I guess a new dedicated
dmop/hypercall is bearable.

>> 6. PCI conf read/write ioreqs are sent to the chosen device model
>> 
>> 7. QEMU receive MMCONFIG memory reads/writes as PCI conf reads/writes
>> 
>> 8. As these MMCONFIG PCI conf reads occur out of context (just
>> address/len/data without any emulated device attached to it),
>> xen-hvm.c should employ special logic to make it QEMU-friendly --
>> eg. right now it sends received PCI conf access into (emulated by
>> QEMU) CF8h/CFCh ports.
>> There is a real problem to embed these "naked" accesses into QEMU
>> infrastructure, workarounds are required. BTW, find_primary_bus() was
>> dropped from QEMU code -- it could've been useful here. Let's assume
>> some workaround is employed (like storing a required object pointers
>> in global variables for later use in xen-hvm.c)  
>
>That seems like a minor nit, but why not just use
>address_space_{read/write} to replay the MCFG accesses as memory
>read/writes?

Well, this might work actually. Although the overall scenario will be
overcomplicated a bit for _PCI_CONFIG ioreqs. Here is how it will look:

QEMU receives PCIEXBAR update -> calls the new dmop to tell Xen new
MMCONFIG address/size -> Xen (re)maps MMIO trapping area -> someone is
accessing this area -> Xen intercepts this MMIO access

But here's what happens next:

Xen translates MMIO access into PCI_CONFIG and sends it to DM ->
DM receives _PCI_CONFIG ioreq -> DM translates BDF/addr info back to
the offset in emulated MMCONFIG range -> DM calls
address_space_read/write to trigger MMIO emulation

I tnink some parts of this equation can be collapsed, isn't it?

Above scenario makes it obvious that at least for QEMU the MMIO->PCI
conf translation is a redundant step. Why not to allow specifying for DM
whether it prefers to receive MMCONFIG accesses as native (MMIO ones)
or as translated PCI conf ioreqs? We can still route either ioreq
type to multiple device emulators accordingly.

This will be the most universal and consistent approach -- either _COPY
or _PCI_CONFIG-type ioreqs can be sent to DM, whatever it likes more.

>> 9. Existing MMCONFIG-handling code in QEMU will be unused in this
>> scenario  
>
>If you replay the read/write I don't think so. In any case this is
>irrelevant. QEMU CPU emulation code is also unused when running under
>Xen.
>
>> 10. All this needed primarily to make the specific "Multiple device
>> emulators" feature to work (XenGT was mentioned as its user) on Q35
>> with MMCONFIG.
>> 
>> Anything wrong/missing here?  
>
>I think that's correct.
>
>Thanks, Roger.


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

Re: [Xen-devel] [PATCH v3] hvm/svm: Implement Debug events

[Jan Beulich]

>>> On 21.03.18 at 17:00,  wrote:
> On Mi, 2018-03-21 at 08:57 -0600, Jan Beulich wrote:
>> >
>> > >
>> > > >
>> > > > On 21.03.18 at 15:47,  wrote:
>> > --- a/xen/include/asm-x86/hvm/hvm.h
>> > +++ b/xen/include/asm-x86/hvm/hvm.h
>> > @@ -209,6 +209,8 @@ struct hvm_function_table {
>> >  bool_t access_w, bool_t access_x);
>> >
>> >  void (*enable_msr_interception)(struct domain *d, uint32_t
>> > msr);
>> > +void (*enable_icebp_interception)(struct domain *d);
>> > +void (*disable_icebp_interception)(struct domain *d);
>> Why two new hooks when one (with a boolean parameter)
>> would do?
>>
> Would update_icebp_interception() be a suitable name for the hook?

"update" or "set" would both seem fine to me.

Jan


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

Re: [Xen-devel] [PATCH v2] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

[Wei Liu]

On Wed, Mar 14, 2018 at 03:36:08PM +0100, Marek Marczykowski-Górecki wrote:
> When LIBXL_SUSPEND_NO_SAVE flag is set, no savefile will be written, but
> the domain will still be suspended (but not destroyed). The main reason
> for this functionality is to suspend the host while some domains are
> running, potentially holding PCI devices. This will give a chance to a
> driver in such a domain to properly suspend the device.
> 
> It would be better to have a separate function for this, but in fact it
> should be named libxl_domain_suspend, then the current one renamed to
> libxl_domain_save. Since that would break API compatibility, keep it in
> the same function.
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> Signed-off-by: Marcus of Wetware Labs 

The code and idea look fine.

I would like to give Ian a chance to voice his opinion (he's currently
away).

Wei.

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

Re: [Xen-devel] [PATCH v2] xenbaked.c: Avoid divide by zero issue

[Wei Liu]

On Wed, Mar 14, 2018 at 10:14:03AM -0700, Joe Jin wrote:
> xenbaked.c -> dump_stats(), run_time = time(&end_time) - time(&start_time),
> time() returns the value in seconds. If one cancels xenmon.py immediately
> after started, run_time can be zero, and then xenbaked will hit divide by
> zero fault.
> 
> Signed-off-by: Joe Jin 
> Reviewed-by: Konrad Rzeszutek Wilk 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

[Juergen Gross]

On 21/03/18 17:46, Maran Wilson wrote:
> On 3/21/2018 2:40 AM, Juergen Gross wrote:
>> On 21/03/18 10:28, Roger Pau Monné wrote:
>>> On Tue, Mar 20, 2018 at 09:48:56AM -0700, Maran Wilson wrote:
 +/*
    * C representation of the x86/HVM start info layout.
    *
    * The canonical definition of this layout is above, this is just
 a way to
 @@ -86,6 +134,14 @@ struct hvm_start_info {
   uint64_t cmdline_paddr; /* Physical address of the command
 line. */
   uint64_t rsdp_paddr;    /* Physical address of the RSDP
 ACPI data    */
   /*
 structure.    */
 +    uint64_t memmap_paddr;  /* Physical address of an array
 of   */
 +    /* hvm_memmap_table_entry. Only
 present in   */
 +    /* version 1 and newer of the
 structure  */
 +    uint32_t memmap_entries;    /* Number of entries in the memmap
 table.    */
 +    /* Only present in version 1 and
 newer of    */
 +    /* the structure. Value will be
 zero if  */
 +    /* there is no memory map being
 provided.    */
 +    uint32_t reserved;  /* Must be zero for Version
 1.   */
>>> I would write "Must be zero." only. If at some point we introduce
>>> version 2 we would likely have to fixup this comment to mention
>>> version 1 and version 2.
>> In case you are going this route I'd suggest to drop the version remarks
>> for the individual fields and just add a comment like:
>>
>> /* All following fields only present in version 1 and newer. */
>>
>> above memmap_paddr.
> 
> OK, so combining the above suggestions, I'd have the following. Is the
> formatting and alignment of comments what you had in mind and acceptable
> to all?

Looks good to me.


Juergen

> 
> struct hvm_start_info {
>     uint32_t magic; /* Contains the magic value
> 0x336ec578   */
>     /* ("xEn3" with the 0x80 bit of the "E"
> set).*/
>     uint32_t version;   /* Version of this
> structure.    */
>     uint32_t flags; /* SIF_xxx
> flags.    */
>     uint32_t nr_modules;    /* Number of modules passed to the
> kernel.   */
>     uint64_t modlist_paddr; /* Physical address of an array
> of   */
>     /*
> hvm_modlist_entry.    */
>     uint64_t cmdline_paddr; /* Physical address of the command
> line. */
>     uint64_t rsdp_paddr;    /* Physical address of the RSDP ACPI
> data    */
>     /*
> structure.    */
>     /* All following fields only present in version 1 and newer */
>     uint64_t memmap_paddr;  /* Physical address of an array
> of   */
>     /*
> hvm_memmap_table_entry.   */
>     uint32_t memmap_entries;    /* Number of entries in the memmap
> table.    */
>     /* Value will be zero if there is no
> memory  */
>     /* map being
> provided.   */
>     uint32_t reserved;  /* Must be
> zero. */
> };
> 
> Thanks,
> -Maran
> 
> 


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

Re: [Xen-devel] [PATCH] libxc/arm: initialise p2m_size to make gcc happy

[Wei Liu]

On Wed, Mar 14, 2018 at 01:27:37PM +, Julien Grall wrote:
> Hi,
> 
> On 03/14/2018 12:32 PM, Wei Liu wrote:
> > Gcc with -O3 failed to spot the loop to initialise p2m_size runs at
> > least once.
> 
> Aside, Andrew's comment the patch looks okay. But I am wondering why we need
> to allocate p2m_host for Arm?
> 

Not sure, really. :-)

> From a quick look I have seen no real user except xc_dom_update_guest_p2m
> that can cope with p2m_host = NULL.
> 

Maybe it is to work around this limitation in code.

Wei.

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

Re: [Xen-devel] [PATCH v4 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

[Maran Wilson]

On 3/21/2018 2:40 AM, Juergen Gross wrote:

On 21/03/18 10:28, Roger Pau Monné wrote:

On Tue, Mar 20, 2018 at 09:48:56AM -0700, Maran Wilson wrote:

+/*
   * C representation of the x86/HVM start info layout.
   *
   * The canonical definition of this layout is above, this is just a way to
@@ -86,6 +134,14 @@ struct hvm_start_info {
  uint64_t cmdline_paddr; /* Physical address of the command line. 
*/
  uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data
*/
  /* structure.
*/
+uint64_t memmap_paddr;  /* Physical address of an array of   */
+/* hvm_memmap_table_entry. Only present in   */
+/* version 1 and newer of the structure  */
+uint32_t memmap_entries;/* Number of entries in the memmap table.*/
+/* Only present in version 1 and newer of*/
+/* the structure. Value will be zero if  */
+/* there is no memory map being provided.*/
+uint32_t reserved;  /* Must be zero for Version 1.   */

I would write "Must be zero." only. If at some point we introduce
version 2 we would likely have to fixup this comment to mention
version 1 and version 2.

In case you are going this route I'd suggest to drop the version remarks
for the individual fields and just add a comment like:

/* All following fields only present in version 1 and newer. */

above memmap_paddr.


OK, so combining the above suggestions, I'd have the following. Is the 
formatting and alignment of comments what you had in mind and acceptable 
to all?


struct hvm_start_info {
    uint32_t magic; /* Contains the magic value 
0x336ec578   */
    /* ("xEn3" with the 0x80 bit of the "E" 
set).*/
    uint32_t version;   /* Version of this 
structure.    */
    uint32_t flags; /* SIF_xxx 
flags.    */
    uint32_t nr_modules;    /* Number of modules passed to the 
kernel.   */
    uint64_t modlist_paddr; /* Physical address of an array 
of   */
    /* 
hvm_modlist_entry.    */
    uint64_t cmdline_paddr; /* Physical address of the command 
line. */
    uint64_t rsdp_paddr;    /* Physical address of the RSDP ACPI 
data    */
    /* 
structure.    */

    /* All following fields only present in version 1 and newer */
    uint64_t memmap_paddr;  /* Physical address of an array 
of   */
    /* 
hvm_memmap_table_entry.   */
    uint32_t memmap_entries;    /* Number of entries in the memmap 
table.    */
    /* Value will be zero if there is no 
memory  */
    /* map being 
provided.   */
    uint32_t reserved;  /* Must be 
zero. */

};

Thanks,
-Maran


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

Re: [Xen-devel] [PATCH 09/20] tools: Rework xc_domain_create() to take a full xen_domctl_createdomain

[Roger Pau Monné]

On Mon, Mar 19, 2018 at 07:13:48PM +, Andrew Cooper wrote:
> In future patches, the structure will be extended with further information,
> and this is far cleaner than adding extra parameters.
> 
> The python stubs are the only user which passes NULL for the existing config
> option (which is actually the arch substructure).  Therefore, the #ifdefary
> moves to compensate.
> 
> For libxl, pass the full config object down into
> libxl__arch_domain_{prepare,save}_config(), as there are in practice arch
> specific settings in the common part of the structure (flags s3_integrity and
> oos_off specifically).
> 
> No practical change in behaviour.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Roger.

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

Re: [Xen-devel] [RFC PATCH 09/12] libxl: Xen Platform device support for Q35

[Wei Liu]

On Tue, Mar 20, 2018 at 01:05:32AM +1000, Alexey G wrote:
> On Tue, 13 Mar 2018 04:33:54 +1000
> Alexey Gerasimenko  wrote:
> 
> >Current Xen/QEMU method to control Xen Platform device is a bit odd --
> >changing 'xen_platform_device' option value actually modifies QEMU
> >emulated machine type, namely xenfv <--> pc.
> >
> >In order to avoid multiplying machine types, use the new way to control
> >Xen Platform device for QEMU -- xen-platform-dev property. To maintain
> >backward compatibility with existing Xen/QEMU setups, this is only
> >applicable to q35 machine currently. i440 emulation uses the old method
> >(xenfv/pc machine) to control Xen Platform device, this may be changed
> >later to xen-platform-dev property as well.
> >
> >Signed-off-by: Alexey Gerasimenko 
> >---
> > tools/libxl/libxl_dm.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> >diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> >index 7b531050c7..586035aa73 100644
> >--- a/tools/libxl/libxl_dm.c
> >+++ b/tools/libxl/libxl_dm.c
> >@@ -1444,7 +1444,11 @@ static int
> >libxl__build_device_model_args_new(libxl__gc *gc,
> > break;
> > case LIBXL_DOMAIN_TYPE_HVM:
> > if (b_info->device_model_machine ==
> > LIBXL_DEVICE_MODEL_MACHINE_Q35) {
> >-machinearg = libxl__sprintf(gc, "q35,accel=xen");
> >+if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> >+machinearg = libxl__sprintf(gc, "q35,accel=xen");
> >+} else {
> >+machinearg = libxl__sprintf(gc,
> >"q35,accel=xen,xen-platform-dev=on");
> >+}
> > } else {
> > if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> > /* Switching here to the machine "pc" which does not
> > add
> 
> Regarding this one -- QEMU maintainers suggested that supplying '-device
> xen-platform' directly should be a better approach than a machine
> property, so this patch is kinda obsolete.

I agree with QEMU maintainers.

> 
> Right now "xenfv" machine usage for qemu-xen seems to be limited to
> controlling the Xen platform device and applying the HVM_MAX_VCPUS
> value to maxcpus + minor changes related to IGD passthrough. Both
> should be applicable for a "pc,accel=xen" machine as well I think, which
> in fact currently lacks the HVM_MAX_VCPUS check for some reason.
> 
> Adding a distinct method to control Xen platform device for the q35
> machine suggests to propagate the same approach to i440 machine types,
> but... it depends on who else can use xenfv for qemu-xen (not to be
> confused with xenfv usage on qemu-traditional).
> 
> Is there any other toolstacks/code which use xenfv machine solely to
> turn on/off Xen platform device?

Check libvirt?

Wei.

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

Re: [Xen-devel] [PATCH] xen/arm: gic: Read unconditionally the source from the LRs

[Stefano Stabellini]

On Wed, 21 Mar 2018, Julien Grall wrote:
> Commit 5cb00d1 "ARM: GIC: extend LR read/write functions to cover EOI
> and source" extended gic_lr to cover the source. The new field was only
> set for SGIs interrupt in the read function. However, the write function
> is writing the field unconditionally for virtual interrupt.
> 
> This means that if the caller was combining the 2 functions (e.g to
> update the LR), the source need to be set to 0 by the caller.
> Unfortunately, gic_update_one_lr is not zeroing the structure before
> reading the LRs. This will lead to trigger the assert randomly.
> 
> Instead of zeroing the structure in gic_update_one_lr, make sure that
> the source is written unconditionally on read. This is also simplifying
> the code to avoid an if statement in the read path.
> 
> Lastly, properly update the comments in write_lr that was mistakenly
> speaking about the read lr path.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

and committed

> ---
>  xen/arch/arm/gic-v2.c | 15 ---
>  xen/arch/arm/gic-v3.c | 13 -
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 7dfe6fc68d..aa0fc6c1a1 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -480,11 +480,12 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
>  else
>  {
>  lr_reg->virt.eoi = (lrv & GICH_V2_LR_MAINTENANCE_IRQ);
> -if ( lr_reg->virq < NR_GIC_SGI )
> -{
> -lr_reg->virt.source = (lrv >> GICH_V2_LR_CPUID_SHIFT)
> -& GICH_V2_LR_CPUID_MASK;
> -}
> +/*
> + * This is only valid for SGI, but it does not matter to always
> + * read it as it should be 0 by default.
> + */
> +lr_reg->virt.source = (lrv >> GICH_V2_LR_CPUID_SHIFT)
> +& GICH_V2_LR_CPUID_MASK;
>  }
>  }
>  
> @@ -512,8 +513,8 @@ static void gicv2_write_lr(int lr, const struct gic_lr 
> *lr_reg)
>  if ( lr_reg->virt.eoi )
>  lrv |= GICH_V2_LR_MAINTENANCE_IRQ;
>  /*
> - * This is only valid for SGI, but it does not matter to always
> - * read it as it should be 0 by default.
> + * Source is only valid for SGIs, the caller should make sure
> + * the field virt.source is always 0 for non-SGI.
>   */
>  ASSERT(!lr_reg->virt.source || lr_reg->virq < NR_GIC_SGI);
>  lrv |= (uint32_t)lr_reg->virt.source << GICH_V2_LR_CPUID_SHIFT;
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 392cf91b58..cb41844af2 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1018,10 +1018,13 @@ static void gicv3_read_lr(int lr, struct gic_lr 
> *lr_reg)
>  else
>  {
>  lr_reg->virt.eoi = (lrv & ICH_LR_MAINTENANCE_IRQ);
> -/* Source only exists for SGI and in GICv2 compatible mode */
> -if ( lr_reg->virq < NR_GIC_SGI &&
> - current->domain->arch.vgic.version == GIC_V2 )
> +/* Source only exists in GICv2 compatible mode */
> +if ( current->domain->arch.vgic.version == GIC_V2 )
>  {
> +/*
> + * This is only valid for SGI, but it does not matter to always
> + * read it as it should be 0 by default.
> + */
>  lr_reg->virt.source = (lrv >> ICH_LR_CPUID_SHIFT)
>  & ICH_LR_CPUID_MASK;
>  }
> @@ -1056,8 +1059,8 @@ static void gicv3_write_lr(int lr_reg, const struct 
> gic_lr *lr)
>  if ( vgic_version == GIC_V2 )
>  {
>  /*
> - * This is only valid for SGI, but it does not matter to always
> - * read it as it should be 0 by default.
> + * Source is only valid for SGIs, the caller should make
> + * sure the field virt.source is always 0 for non-SGI.
>   */
>  ASSERT(!lr->virt.source || lr->virq < NR_GIC_SGI);
>  lrv |= (uint64_t)lr->virt.source << ICH_LR_CPUID_SHIFT;
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [RFC PATCH 08/12] libxl: Q35 support (new option device_model_machine)

[Wei Liu]

On Tue, Mar 20, 2018 at 09:11:10AM +, Roger Pau Monné wrote:
> On Tue, Mar 20, 2018 at 08:11:49AM +1000, Alexey G wrote:
> > On Mon, 19 Mar 2018 17:01:18 +
> > Roger Pau Monné  wrote:
> > 
> > >On Tue, Mar 13, 2018 at 04:33:53AM +1000, Alexey Gerasimenko wrote:
> > >> Provide a new domain config option to select the emulated machine
> > >> type, device_model_machine. It has following possible values:
> > >> - "i440" - i440 emulation (default)
> > >> - "q35" - emulate a Q35 machine. By default, the storage interface
> > >> is AHCI.  
> > >
> > >I would rather name this machine_chipset or device_model_chipset.
> > 
> > device_model_ prefix is a must I think -- multiple device model related
> > options have names starting with device_model_.
> > 
> > device_model_chipset... well, maybe, but we're actually specifying a
> > QEMU machine here. In QEMU mailing list there was even a suggestion
> > to allow to pass a machine version number here, like "pc-q35-2.10".
> > I think some opinions are needed here.
> 
> I'm not sure what a 'machine' is in QEMU speak, but in my mind I would
> consider PC a machine (vs ARM for example).
> 
> I think 'chipset' is clearer, but again others should express their
> opinion.

AIUI machine is a collection of chipset and peripherals, i.e. it covers
more than the chipset alone.

Cc Anthony for correction.

Wei.

> 
> Thanks, Roger.

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

Re: [Xen-devel] [RFC PATCH 08/12] libxl: Q35 support (new option device_model_machine)

[Wei Liu]

On Tue, Mar 20, 2018 at 08:11:49AM +1000, Alexey G wrote:
> >>  if (b_info->u.hvm.mmio_hole_memkb) {
> >>  uint64_t max_ram_below_4g = (1ULL << 32) -
> >> diff --git a/tools/libxl/libxl_types.idl
> >> b/tools/libxl/libxl_types.idl index 35038120ca..f3ef3cbdde 100644
> >> --- a/tools/libxl/libxl_types.idl
> >> +++ b/tools/libxl/libxl_types.idl
> >> @@ -101,6 +101,12 @@ libxl_device_model_version =
> >> Enumeration("device_model_version", [ (2, "QEMU_XEN"), #
> >> Upstream based qemu-xen device model ])
> >>  
> >> +libxl_device_model_machine = Enumeration("device_model_machine", [
> >> +(0, "UNKNOWN"),  
> >
> >Shouldn't this be named DEFAULT?
> 
> "Unknown" here should be read as "unspecified", but I guess DEFAULT
> will be clearer anyway.
> 

I'm afraid the ship has already sailed. There are far too many UNKNOWNs
in libxl_types.idl so we might as well stick to it here.

Wei.

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

[Xen-devel] [PATCH v3 29/39] ARM: new VGIC: Handle virtual IRQ allocation/reservation

[Andre Przywara]

To find an unused virtual IRQ number Xen uses a scheme to track used
virtual IRQs.
Implement this interface in the new VGIC to make the Xen core/arch code
happy.
This is actually somewhat VGIC agnostic, so is mostly a copy of the code
from the old VGIC. But it has to live in the VGIC files, so we can't
easily reuse the existing implementation.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 3d818a98ad..8aaad4bffa 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -722,6 +722,50 @@ bool vgic_evtchn_irq_pending(struct vcpu *v)
 return pending;
 }
 
+bool vgic_reserve_virq(struct domain *d, unsigned int virq)
+{
+if ( virq >= vgic_num_irqs(d) )
+return false;
+
+return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
+}
+
+int vgic_allocate_virq(struct domain *d, bool spi)
+{
+int first, end;
+unsigned int virq;
+
+if ( !spi )
+{
+/* We only allocate PPIs. SGIs are all reserved */
+first = 16;
+end = 32;
+}
+else
+{
+first = 32;
+end = vgic_num_irqs(d);
+}
+
+/*
+ * There is no spinlock to protect allocated_irqs, therefore
+ * test_and_set_bit may fail. If so retry it.
+ */
+do
+{
+virq = find_next_zero_bit(d->arch.vgic.allocated_irqs, end, first);
+if ( virq >= end )
+return -1;
+} while ( test_and_set_bit(virq, d->arch.vgic.allocated_irqs) );
+
+return virq;
+}
+
+void vgic_free_virq(struct domain *d, unsigned int virq)
+{
+clear_bit(virq, d->arch.vgic.allocated_irqs);
+}
+
 struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
   unsigned int virq)
 {
-- 
2.14.1


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

[Xen-devel] [PATCH v3 32/39] ARM: new VGIC: Implement arch_move_irqs()

[Andre Przywara]

When a VCPU moves to another CPU, we need to adjust the target affinity
of any hardware mapped vIRQs, to observe our "physical-follows-virtual"
policy.
Implement arch_move_irqs() to adjust the physical affinity of all hardware
mapped vIRQs targetting this VCPU.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index ffab0b2635..23b8abfc5e 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -791,6 +791,45 @@ void gic_dump_vgic_info(struct vcpu *v)
 spin_unlock_irqrestore(&v->arch.vgic.ap_list_lock, flags);
 }
 
+/**
+ * arch_move_irqs() - migrate the physical affinity of hardware mapped vIRQs
+ * @v:  the vCPU, already assigned to the new pCPU
+ *
+ * arch_move_irqs() updates the physical affinity of all virtual IRQs
+ * targetting this given vCPU. This only affects hardware mapped IRQs. The
+ * new pCPU to target is already set in v->processor.
+ * This is called by the core code after a vCPU has been migrated to a new
+ * physical CPU.
+ */
+void arch_move_irqs(struct vcpu *v)
+{
+struct domain *d = v->domain;
+unsigned int i;
+
+/* We only target SPIs with this function */
+for ( i = 0; i < d->arch.vgic.nr_spis; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(d, NULL, i + VGIC_NR_PRIVATE_IRQS);
+unsigned long flags;
+
+if ( !irq )
+continue;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+/* only vIRQs that are not on a vCPU yet , but targetting this vCPU */
+if ( irq->hw && !irq->vcpu && irq->target_vcpu == v)
+{
+irq_desc_t *desc = irq_to_desc(irq->hwintid);
+
+irq_set_affinity(desc, cpumask_of(v->processor));
+}
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(d, irq);
+}
+}
+
 struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
   unsigned int virq)
 {
-- 
2.14.1


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

[Xen-devel] [PATCH v3 24/39] ARM: new VGIC: Add TARGET registers handlers

[Andre Przywara]

The target register handlers are v2 emulation specific, so their
implementation lives entirely in vgic-mmio-v2.c.
We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
set in the target mask instead of making it possibly pending on
multiple VCPUs.
We update the physical affinity of a hardware mapped vIRQ on the way.

This is based on Linux commit 2c234d6f1826, written by Andre Przywara.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic-mmio-v2.c | 59 +++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index a28d0e459b..b333de9ed7 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -81,6 +81,63 @@ static void vgic_mmio_write_v2_misc(struct vcpu *vcpu,
 }
 }
 
+static unsigned long vgic_mmio_read_target(struct vcpu *vcpu,
+   paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+uint32_t val = 0;
+unsigned int i;
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+val |= (uint32_t)irq->targets << (i * 8);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return val;
+}
+
+static void vgic_mmio_write_target(struct vcpu *vcpu,
+   paddr_t addr, unsigned int len,
+   unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+uint8_t cpu_mask = GENMASK(vcpu->domain->max_vcpus - 1, 0);
+unsigned int i;
+unsigned long flags;
+
+/* GICD_ITARGETSR[0-7] are read-only */
+if ( intid < VGIC_NR_PRIVATE_IRQS )
+return;
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, NULL, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+irq->targets = (val >> (i * 8)) & cpu_mask;
+if ( irq->targets )
+{
+irq->target_vcpu = vcpu->domain->vcpu[ffs(irq->targets) - 1];
+if ( irq->hw )
+{
+struct irq_desc *desc = irq_to_desc(irq->hwintid);
+
+irq_set_affinity(desc, 
cpumask_of(irq->target_vcpu->processor));
+}
+}
+else
+irq->target_vcpu = NULL;
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
 static const struct vgic_register_region vgic_v2_dist_registers[] = {
 REGISTER_DESC_WITH_LENGTH(GICD_CTLR,
 vgic_mmio_read_v2_misc, vgic_mmio_write_v2_misc, 12,
@@ -110,7 +167,7 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_priority, vgic_mmio_write_priority, 8,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ITARGETSR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
+vgic_mmio_read_target, vgic_mmio_write_target, 8,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICFGR,
 vgic_mmio_read_config, vgic_mmio_write_config, 2,
-- 
2.14.1


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

[Xen-devel] [PATCH v3 34/39] ARM: new VGIC: vgic-init: register VGIC

[Andre Przywara]

This patch implements the function which is called by Xen when it wants
to register the virtual GIC.
This also implements vgic_max_vcpus() for the new VGIC, which reports
back the maximum number of VCPUs a certain GIC model supports. Similar
to the counterpart in the "old" VGIC, we return some maximum value if
the VGIC has not been initialised yet.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- drop premature #ifdef CONFIG_HAS_GICV3
- use new GIC_INVALID to detect uninitialised VGIC

 xen/arch/arm/vgic/vgic-init.c | 60 +++
 xen/arch/arm/vgic/vgic.c  | 25 ++
 xen/arch/arm/vgic/vgic.h  |  3 +++
 3 files changed, 88 insertions(+)
 create mode 100644 xen/arch/arm/vgic/vgic-init.c

diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
new file mode 100644
index 00..d091c92ed0
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic-init.c
@@ -0,0 +1,60 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+
+#include "vgic.h"
+
+/* CREATION */
+
+/**
+ * domain_vgic_register: create a virtual GIC
+ * @d: domain pointer
+ * @mmio_count: pointer to add number of required MMIO regions
+ *
+ * was: kvm_vgic_create
+ */
+int domain_vgic_register(struct domain *d, int *mmio_count)
+{
+switch ( d->arch.vgic.version )
+{
+case GIC_V2:
+*mmio_count = 1;
+break;
+default:
+BUG();
+}
+
+if ( d->max_vcpus > domain_max_vcpus(d) )
+return -E2BIG;
+
+d->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
+d->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
+d->arch.vgic.vgic_redist_base = VGIC_ADDR_UNDEF;
+
+return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index b70fdaaecb..131358a5a1 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -956,6 +956,31 @@ void vgic_sync_hardware_irq(struct domain *d,
 spin_unlock_irqrestore(&desc->lock, flags);
 }
 
+unsigned int vgic_max_vcpus(const struct domain *d)
+{
+unsigned int vgic_vcpu_limit;
+
+switch ( d->arch.vgic.version )
+{
+case GIC_INVALID:
+/*
+ * Since evtchn_init would call domain_max_vcpus for poll_mask
+ * allocation before the VGIC has been initialised, we need to
+ * return some safe value in this case. As this is for allocation
+ * purposes, go with the maximum value.
+ */
+vgic_vcpu_limit = MAX_VIRT_CPUS;
+break;
+case GIC_V2:
+vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
+break;
+default:
+BUG();
+}
+
+return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index c7eeaf7a38..a3fcd4d965 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -25,6 +25,9 @@
 #define VARIANT_ID_XEN  0x01
 #define IMPLEMENTER_ARM 0x43b
 
+#define VGIC_ADDR_UNDEF INVALID_PADDR
+#define IS_VGIC_ADDR_UNDEF(_x)  ((_x) == VGIC_ADDR_UNDEF)
+
 #define VGIC_PRI_BITS   5
 
 #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 37/39] ARM: new VGIC: vgic-init: implement map_resources

[Andre Przywara]

map_resources is the last initialization step needed before the first
VCPU is run. At that stage the code stores the MMIO base addresses used.
Also it registers the respective register frames with the MMIO framework.

This is based on Linux commit cbae53e663ea, written by Eric Auger.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic-v2.c | 66 +
 xen/arch/arm/vgic/vgic.h|  1 +
 2 files changed, 67 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
index ce77e58857..5516a8534f 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -235,6 +235,72 @@ void vgic_v2_enable(struct vcpu *vcpu)
 gic_hw_ops->update_hcr_status(GICH_HCR_EN, true);
 }
 
+int vgic_v2_map_resources(struct domain *d)
+{
+struct vgic_dist *dist = &d->arch.vgic;
+paddr_t cbase, csize;
+paddr_t vbase;
+int ret;
+
+/*
+ * The hardware domain gets the hardware address.
+ * Guests get the virtual platform layout.
+ */
+if ( is_hardware_domain(d) )
+{
+d->arch.vgic.vgic_dist_base = gic_v2_hw_data.dbase;
+/*
+ * For the hardware domain, we always map the whole HW CPU
+ * interface region in order to match the device tree (the "reg"
+ * properties is copied as it is).
+ * Note that we assume the size of the CPU interface is always
+ * aligned to PAGE_SIZE.
+ */
+cbase = gic_v2_hw_data.cbase; /* was: dist->vgic_cpu_base */
+csize = gic_v2_hw_data.csize;
+vbase = gic_v2_hw_data.vbase; /* was: kvm_vgic_global_state.vcpu_base 
*/
+}
+else
+{
+d->arch.vgic.vgic_dist_base = GUEST_GICD_BASE;
+/*
+ * The CPU interface exposed to the guest is always 8kB. We may
+ * need to add an offset to the virtual CPU interface base
+ * address when in the GIC is aliased to get a 8kB contiguous
+ * region.
+ */
+BUILD_BUG_ON(GUEST_GICC_SIZE != SZ_8K);
+cbase = GUEST_GICC_BASE;
+csize = GUEST_GICC_SIZE;
+vbase = gic_v2_hw_data.vbase + gic_v2_hw_data.aliased_offset;
+}
+
+
+ret = vgic_register_dist_iodev(d, gaddr_to_gfn(dist->vgic_dist_base),
+   VGIC_V2);
+if ( ret )
+{
+gdprintk(XENLOG_ERR, "Unable to register VGIC MMIO regions\n");
+return ret;
+}
+
+/*
+ * Map the gic virtual cpu interface in the gic cpu interface
+ * region of the guest.
+ */
+ret = map_mmio_regions(d, gaddr_to_gfn(cbase), csize / PAGE_SIZE,
+   maddr_to_mfn(vbase));
+if ( ret )
+{
+gdprintk(XENLOG_ERR, "Unable to remap VGIC CPU to VCPU\n");
+return ret;
+}
+
+dist->ready = true;
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index 112952fbf9..e8e407adbe 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -67,6 +67,7 @@ void vgic_v2_fold_lr_state(struct vcpu *vcpu);
 void vgic_v2_populate_lr(struct vcpu *vcpu, struct vgic_irq *irq, int lr);
 void vgic_v2_set_underflow(struct vcpu *vcpu);
 void vgic_v2_enable(struct vcpu *vcpu);
+int vgic_v2_map_resources(struct domain *d);
 int vgic_register_dist_iodev(struct domain *d, gfn_t dist_base_fn,
  enum vgic_type);
 
-- 
2.14.1


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

[Xen-devel] [PATCH v3 02/39] ARM: GIC: add GIC_INVALID to enum gic_version

[Andre Przywara]

The enum gic_version at the moment just contains GIC_V2 and GIC_V3,
where GIC_V2 happens to map to 0. So without having initialised a
variable of that type, we will read back GIC_V2 (when allocated with zeroing
the memory).
To prevent ambiguities and to give an explicitly uninitialised state, add
a new first member: GIC_INVALID. Also make it obvious that this has a
"0" encoding.

Signed-off-by: Andre Przywara 
---
 xen/include/asm-arm/gic.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 565b0875ca..3079387e06 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -227,6 +227,7 @@ struct gic_lr {
 };
 
 enum gic_version {
+GIC_INVALID = 0,/* the default until explicitly set up */
 GIC_V2,
 GIC_V3,
 };
-- 
2.14.1


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

[Xen-devel] [PATCH v3 12/39] ARM: new VGIC: Add IRQ sorting

[Andre Przywara]

Adds the sorting function to cover the case where you have more IRQs
to consider than you have LRs. We consider their priorities.
This uses the new sort_list() implementation imported from Linux.

This is based on Linux commit 8e4447457965, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic.c | 59 
 1 file changed, 59 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index f7dfd01c1d..ee0de8d2e0 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -15,6 +15,7 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -193,6 +194,64 @@ static struct vcpu *vgic_target_oracle(struct vgic_irq 
*irq)
 return NULL;
 }
 
+/*
+ * The order of items in the ap_lists defines how we'll pack things in LRs as
+ * well, the first items in the list being the first things populated in the
+ * LRs.
+ *
+ * A hard rule is that active interrupts can never be pushed out of the LRs
+ * (and therefore take priority) since we cannot reliably trap on deactivation
+ * of IRQs and therefore they have to be present in the LRs.
+ *
+ * Otherwise things should be sorted by the priority field and the GIC
+ * hardware support will take care of preemption of priority groups etc.
+ *
+ * Return negative if "a" sorts before "b", 0 to preserve order, and positive
+ * to sort "b" before "a".
+ */
+static int vgic_irq_cmp(void *priv, struct list_head *a, struct list_head *b)
+{
+struct vgic_irq *irqa = container_of(a, struct vgic_irq, ap_list);
+struct vgic_irq *irqb = container_of(b, struct vgic_irq, ap_list);
+bool penda, pendb;
+int ret;
+
+spin_lock(&irqa->irq_lock);
+spin_lock(&irqb->irq_lock);
+
+if ( irqa->active || irqb->active )
+{
+ret = (int)irqb->active - (int)irqa->active;
+goto out;
+}
+
+penda = irqa->enabled && irq_is_pending(irqa);
+pendb = irqb->enabled && irq_is_pending(irqb);
+
+if ( !penda || !pendb )
+{
+ret = (int)pendb - (int)penda;
+goto out;
+}
+
+/* Both pending and enabled, sort by priority */
+ret = irqa->priority - irqb->priority;
+out:
+spin_unlock(&irqb->irq_lock);
+spin_unlock(&irqa->irq_lock);
+return ret;
+}
+
+/* Must be called with the ap_list_lock held */
+static void vgic_sort_ap_list(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+
+ASSERT(spin_is_locked(&vgic_cpu->ap_list_lock));
+
+list_sort(NULL, &vgic_cpu->ap_list_head, vgic_irq_cmp);
+}
+
 /*
  * Only valid injection if changing level for level-triggered IRQs or for a
  * rising edge.
-- 
2.14.1


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

[Xen-devel] [PATCH v3 35/39] ARM: new VGIC: Add vgic_v2_enable

[Andre Przywara]

Enable the VGIC operation by properly initialising the registers
in the hypervisor GIC interface.

This is based on Linux commit f7b6985cc3d0, written by Eric Auger.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
Changelog v2 ... v3:
- replace "1" with "true" in boolean parameter

Changelog v1 ... v2:
- move patch from later part in the series

 xen/arch/arm/vgic/vgic-v2.c | 6 ++
 xen/arch/arm/vgic/vgic.h| 1 +
 2 files changed, 7 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
index 8ab0cfe81d..ce77e58857 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -229,6 +229,12 @@ void vgic_v2_populate_lr(struct vcpu *vcpu, struct 
vgic_irq *irq, int lr)
 gic_hw_ops->write_lr(lr, &lr_val);
 }
 
+void vgic_v2_enable(struct vcpu *vcpu)
+{
+/* Get the show on the road... */
+gic_hw_ops->update_hcr_status(GICH_HCR_EN, true);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index a3fcd4d965..112952fbf9 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -66,6 +66,7 @@ void vgic_sync_hardware_irq(struct domain *d,
 void vgic_v2_fold_lr_state(struct vcpu *vcpu);
 void vgic_v2_populate_lr(struct vcpu *vcpu, struct vgic_irq *irq, int lr);
 void vgic_v2_set_underflow(struct vcpu *vcpu);
+void vgic_v2_enable(struct vcpu *vcpu);
 int vgic_register_dist_iodev(struct domain *d, gfn_t dist_base_fn,
  enum vgic_type);
 
-- 
2.14.1


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

[Xen-devel] [PATCH v3 36/39] ARM: new VGIC: vgic-init: implement vgic_init

[Andre Przywara]

This patch allocates and initializes the data structures used to model
the vgic distributor and virtual cpu interfaces. At that stage the
number of IRQs and number of virtual CPUs is frozen.
Implement the various functions that the Xen arch code is expecting to
call during domain and VCPU setup to initialize the VGIC.
Their prototypes are already in existing header files.

This is based on Linux commit ad275b8bb1e6, written by Eric Auger.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- move ROUNDUP(nr_spis) call before boundary check

Changelog v1 ... v2:
- remove stray kvm_ prefix in comment
- use unsigned int
- ROUNDUP number of SPIs
- fix indentation

 xen/arch/arm/vgic/vgic-init.c | 201 ++
 1 file changed, 201 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
index d091c92ed0..bfd3d09edb 100644
--- a/xen/arch/arm/vgic/vgic-init.c
+++ b/xen/arch/arm/vgic/vgic-init.c
@@ -15,11 +15,83 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 
 #include "vgic.h"
 
+/*
+ * Initialization rules: there are multiple stages to the vgic
+ * initialization, both for the distributor and the CPU interfaces.  The basic
+ * idea is that even though the VGIC is not functional or not requested from
+ * user space, the critical path of the run loop can still call VGIC functions
+ * that just won't do anything, without them having to check additional
+ * initialization flags to ensure they don't look at uninitialized data
+ * structures.
+ *
+ * Distributor:
+ *
+ * - vgic_early_init(): initialization of static data that doesn't
+ *   depend on any sizing information or emulation type. No allocation
+ *   is allowed there.
+ *
+ * - vgic_init(): allocation and initialization of the generic data
+ *   structures that depend on sizing information (number of CPUs,
+ *   number of interrupts). Also initializes the vcpu specific data
+ *   structures. Can be executed lazily for GICv2.
+ *
+ * CPU Interface:
+ *
+ * - vgic_vcpu_early_init(): initialization of static data that
+ *   doesn't depend on any sizing information or emulation type. No
+ *   allocation is allowed there.
+ */
+
+/**
+ * vgic_vcpu_early_init() - Initialize static VGIC VCPU data structures
+ * @vcpu: The VCPU whose VGIC data structures whould be initialized
+ *
+ * Only do initialization, but do not actually enable the VGIC CPU interface
+ * yet.
+ */
+static void vgic_vcpu_early_init(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+unsigned int i;
+
+INIT_LIST_HEAD(&vgic_cpu->ap_list_head);
+spin_lock_init(&vgic_cpu->ap_list_lock);
+
+/*
+ * Enable and configure all SGIs to be edge-triggered and
+ * configure all PPIs as level-triggered.
+ */
+for ( i = 0; i < VGIC_NR_PRIVATE_IRQS; i++ )
+{
+struct vgic_irq *irq = &vgic_cpu->private_irqs[i];
+
+INIT_LIST_HEAD(&irq->ap_list);
+spin_lock_init(&irq->irq_lock);
+irq->intid = i;
+irq->vcpu = NULL;
+irq->target_vcpu = vcpu;
+irq->targets = 1U << vcpu->vcpu_id;
+atomic_set(&irq->refcount, 0);
+if ( vgic_irq_is_sgi(i) )
+{
+/* SGIs */
+irq->enabled = 1;
+irq->config = VGIC_CONFIG_EDGE;
+}
+else
+{
+/* PPIs */
+irq->config = VGIC_CONFIG_LEVEL;
+}
+}
+}
+
 /* CREATION */
 
 /**
@@ -50,6 +122,135 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
 return 0;
 }
 
+/* INIT/DESTROY */
+
+/**
+ * domain_vgic_init: initialize the dist data structures
+ * @d: domain pointer
+ * @nr_spis: number of SPIs
+ */
+int domain_vgic_init(struct domain *d, unsigned int nr_spis)
+{
+struct vgic_dist *dist = &d->arch.vgic;
+unsigned int i;
+int ret;
+
+/* The number of SPIs must be a multiple of 32 per the GIC spec. */
+nr_spis = ROUNDUP(nr_spis, 32);
+
+/* Limit the number of virtual SPIs supported to (1020 - 32) = 988  */
+if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
+return -EINVAL;
+
+dist->nr_spis = nr_spis;
+dist->spis = xzalloc_array(struct vgic_irq, nr_spis);
+if ( !dist->spis )
+return  -ENOMEM;
+
+/*
+ * In the following code we do not take the irq struct lock since
+ * no other action on irq structs can happen while the VGIC is
+ * not initialized yet:
+ * If someone wants to inject an interrupt or does a MMIO access, we
+ * require prior initialization in case of a virtual GICv3 or trigger
+ * initialization when using a virtual GICv2.
+ */
+for ( i = 0; i < nr_spis; i++ )
+{
+struct vgic_irq *irq = &dist->spis[i];
+
+irq->intid = i + VGIC_NR_PRIVATE_IRQS;
+INIT_LIST_HEAD(&irq->ap_list);
+spin_lock_init(&irq->irq_lock);
+irq->vcpu = NULL;
+irq->target_vcpu = NULL;
+atomic_set(&irq

[Xen-devel] [PATCH v3 39/39] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

[Andre Przywara]

Now that we have both the old VGIC prepared to cope with a sibling and
the code for the new VGIC in place, lets add a Kconfig option to enable
the new code and wire it into the Xen build system.
This will add a compile time option to use either the "old" or the "new"
VGIC.
In the moment this is restricted to a vGIC-v2. To make the build system
happy, we provide a temporary dummy implementation of
vgic_v3_setup_hw() to allow building for now.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- fix indentation of Kconfig entry
- select NEEDS_LIST_SORT
- drop unconditional list_sort.o inclusion

Changelog v1 ... v2:
- add Kconfig help text
- use separate Makefile in vgic/ directory
- protect compilation without GICV3 support
- always include list_sort() in build

 xen/arch/arm/Kconfig   | 18 +-
 xen/arch/arm/Makefile  |  5 -
 xen/arch/arm/vgic/Makefile |  5 +
 xen/arch/arm/vgic/vgic.c   | 10 ++
 4 files changed, 36 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/vgic/Makefile

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2782ee6589..8174c0c635 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -48,7 +48,23 @@ config HAS_GICV3
 config HAS_ITS
 bool
 prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
-depends on HAS_GICV3
+depends on HAS_GICV3 && !NEW_VGIC
+
+config NEW_VGIC
+   bool
+   prompt "Use new VGIC implementation"
+   select NEEDS_LIST_SORT
+   ---help---
+
+   This is an alternative implementation of the ARM GIC interrupt
+   controller emulation, based on the Linux/KVM VGIC. It has a better
+   design and fixes many shortcomings of the existing GIC emulation in
+   Xen. It will eventually replace the existing/old VGIC.
+   However at the moment it lacks support for Dom0 using the ITS for
+   using MSIs.
+   Say Y if you want to help testing this new code or if you experience
+   problems with the standard emulation.
+   At the moment this implementation is not security supported.
 
 config SBSA_VUART_CONSOLE
bool "Emulated SBSA UART console support"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 41d7366527..a9533b107e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -16,7 +16,6 @@ obj-y += domain_build.o
 obj-y += domctl.o
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += gic.o
-obj-y += gic-vgic.o
 obj-y += gic-v2.o
 obj-$(CONFIG_HAS_GICV3) += gic-v3.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
@@ -47,10 +46,14 @@ obj-y += sysctl.o
 obj-y += time.o
 obj-y += traps.o
 obj-y += vcpreg.o
+subdir-$(CONFIG_NEW_VGIC) += vgic
+ifneq ($(CONFIG_NEW_VGIC),y)
+obj-y += gic-vgic.o
 obj-y += vgic.o
 obj-y += vgic-v2.o
 obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
+endif
 obj-y += vm_event.o
 obj-y += vtimer.o
 obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
diff --git a/xen/arch/arm/vgic/Makefile b/xen/arch/arm/vgic/Makefile
new file mode 100644
index 00..806826948e
--- /dev/null
+++ b/xen/arch/arm/vgic/Makefile
@@ -0,0 +1,5 @@
+obj-y += vgic.o
+obj-y += vgic-v2.o
+obj-y += vgic-mmio.o
+obj-y += vgic-mmio-v2.o
+obj-y += vgic-init.o
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 131358a5a1..22c70ff7cd 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -981,6 +981,16 @@ unsigned int vgic_max_vcpus(const struct domain *d)
 return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
 }
 
+#ifdef CONFIG_HAS_GICV3
+void vgic_v3_setup_hw(paddr_t dbase,
+  unsigned int nr_rdist_regions,
+  const struct rdist_region *regions,
+  unsigned int intid_bits)
+{
+/* Dummy implementation to allow building without actual vGICv3 support. */
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
-- 
2.14.1


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

[Xen-devel] [PATCH v3 20/39] ARM: new VGIC: Add PENDING registers handlers

[Andre Przywara]

The pending register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
For level triggered interrupts the real line level is unaffected by
this write, so we keep this state separate and combine it with the
device's level to get the actual pending state.
Hardware mapped IRQs need some special handling, as their hardware state
has to be coordinated with the virtual pending bit to avoid hanging
or masked interrupts.

This is based on Linux commit 96b298000db4, written by Andre Przywara.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic-mmio-v2.c |   4 +-
 xen/arch/arm/vgic/vgic-mmio.c| 125 +++
 xen/arch/arm/vgic/vgic-mmio.h|  11 
 3 files changed, 138 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 7efd1c4eb4..a48c554040 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -95,10 +95,10 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_enable, vgic_mmio_write_cenable, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISPENDR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_pending, vgic_mmio_write_spending, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICPENDR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_pending, vgic_mmio_write_cpending, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISACTIVER,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index f219b7c509..53b8978c02 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -156,6 +156,131 @@ void vgic_mmio_write_cenable(struct vcpu *vcpu,
 }
 }
 
+unsigned long vgic_mmio_read_pending(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+uint32_t value = 0;
+unsigned int i;
+
+/* Loop over all IRQs affected by this read */
+for ( i = 0; i < len * 8; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+if ( irq_is_pending(irq) )
+value |= (1U << i);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return value;
+}
+
+void vgic_mmio_write_spending(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len,
+  unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+unsigned long flags;
+irq_desc_t *desc;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+irq->pending_latch = true;
+
+/* To observe the locking order, just take the irq_desc pointer here. 
*/
+if ( irq->hw )
+desc = irq_to_desc(irq->hwintid);
+else
+desc = NULL;
+
+vgic_queue_irq_unlock(vcpu->domain, irq, flags);
+
+/*
+ * When the VM sets the pending state for a HW interrupt on the virtual
+ * distributor we set the active state on the physical distributor,
+ * because the virtual interrupt can become active and then the guest
+ * can deactivate it.
+ */
+if ( desc )
+{
+spin_lock_irqsave(&desc->lock, flags);
+spin_lock(&irq->irq_lock);
+
+/* This h/w IRQ should still be assigned to the virtual IRQ. */
+ASSERT(irq->hw && desc->irq == irq->hwintid);
+
+gic_set_active_state(desc, true);
+
+spin_unlock(&irq->irq_lock);
+spin_unlock_irqrestore(&desc->lock, flags);
+}
+
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
+void vgic_mmio_write_cpending(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len,
+  unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+unsigned long flags;
+irq_desc_t *desc;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+irq->pending_latch = false;
+
+/* To observe the locking order, just take the irq_desc pointer here. 
*/
+if ( irq->hw )
+desc = irq_to_desc(irq->hwintid);
+else
+desc = NULL;
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+
+/*
+ * We don't want the guest to effectively mask the physical
+ * interrupt by doing a write to SPENDR followe

[Xen-devel] [PATCH v3 25/39] ARM: new VGIC: Add SGIR register handler

[Andre Przywara]

Triggering an IPI via this register is v2 specific, so the
implementation lives entirely in vgic-mmio-v2.c.

This is based on Linux commit 55cc01fb9004, written by Andre Przywara.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- fix target mask calculation

Changelog v1 ... v2:
- remove stray rebase artefact

 xen/arch/arm/vgic/vgic-mmio-v2.c | 45 +++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index b333de9ed7..9ef80608c1 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -81,6 +81,49 @@ static void vgic_mmio_write_v2_misc(struct vcpu *vcpu,
 }
 }
 
+static void vgic_mmio_write_sgir(struct vcpu *source_vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+struct domain *d = source_vcpu->domain;
+unsigned int nr_vcpus = d->max_vcpus;
+unsigned int intid = val & GICD_SGI_INTID_MASK;
+unsigned long targets = (val & GICD_SGI_TARGET_MASK) >>
+GICD_SGI_TARGET_SHIFT;
+unsigned int vcpu_id;
+
+switch ( val & GICD_SGI_TARGET_LIST_MASK )
+{
+case GICD_SGI_TARGET_LIST:/* as specified by targets */
+targets &= GENMASK(nr_vcpus - 1, 0);  /* limit to existing VCPUs */
+break;
+case GICD_SGI_TARGET_OTHERS:
+targets = GENMASK(nr_vcpus - 1, 0);   /* all, ...   */
+targets &= ~(1U << source_vcpu->vcpu_id); /*   but self */
+break;
+case GICD_SGI_TARGET_SELF:/* this very vCPU only */
+targets = (1U << source_vcpu->vcpu_id);
+break;
+case 0x3: /* reserved */
+return;
+}
+
+for_each_set_bit( vcpu_id, &targets, 8 )
+{
+struct vcpu *vcpu = d->vcpu[vcpu_id];
+struct vgic_irq *irq = vgic_get_irq(d, vcpu, intid);
+unsigned long flags;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+irq->pending_latch = true;
+irq->source |= 1U << source_vcpu->vcpu_id;
+
+vgic_queue_irq_unlock(d, irq, flags);
+vgic_put_irq(d, irq);
+}
+}
+
 static unsigned long vgic_mmio_read_target(struct vcpu *vcpu,
paddr_t addr, unsigned int len)
 {
@@ -173,7 +216,7 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_config, vgic_mmio_write_config, 2,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_LENGTH(GICD_SGIR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
+vgic_mmio_read_raz, vgic_mmio_write_sgir, 4,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_LENGTH(GICD_CPENDSGIR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
-- 
2.14.1


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

[Xen-devel] [PATCH v3 33/39] ARM: new VGIC: Add preliminary stub implementation

[Andre Przywara]

The ARM arch code requires an interrupt controller emulation to implement
vgic_clear_pending_irqs(), although it is suspected that it is actually
not necessary. Go with a stub for now to make the linker happy.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 23b8abfc5e..b70fdaaecb 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -791,6 +791,14 @@ void gic_dump_vgic_info(struct vcpu *v)
 spin_unlock_irqrestore(&v->arch.vgic.ap_list_lock, flags);
 }
 
+void vgic_clear_pending_irqs(struct vcpu *v)
+{
+/*
+ * TODO: It is unclear whether we really need this, so we might instead
+ * remove it on the caller site.
+ */
+}
+
 /**
  * arch_move_irqs() - migrate the physical affinity of hardware mapped vIRQs
  * @v:  the vCPU, already assigned to the new pCPU
-- 
2.14.1


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

[Xen-devel] [PATCH v3 30/39] ARM: new VGIC: Dump virtual IRQ info

[Andre Przywara]

When we dump guest state on the Xen console, we also print the state of
IRQs that are on a VCPU.
Add the code to dump the state of an IRQ handled by the new VGIC.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 8aaad4bffa..79c6a5553d 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -766,6 +766,31 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
 clear_bit(virq, d->arch.vgic.allocated_irqs);
 }
 
+void gic_dump_vgic_info(struct vcpu *v)
+{
+struct vgic_cpu *vgic_cpu = &v->arch.vgic;
+struct vgic_irq *irq;
+unsigned long flags;
+
+spin_lock_irqsave(&v->arch.vgic.ap_list_lock, flags);
+
+if ( !list_empty(&vgic_cpu->ap_list_head) )
+printk("   active or pending interrupts queued:\n");
+
+list_for_each_entry ( irq, &vgic_cpu->ap_list_head, ap_list )
+{
+spin_lock(&irq->irq_lock);
+printk(" %s %s irq %u: %spending, %sactive, %senabled\n",
+   irq->hw ? "hardware" : "virtual",
+   irq->config == VGIC_CONFIG_LEVEL ? "level" : "edge",
+   irq->intid, irq_is_pending(irq) ? "" : "not ",
+   irq->active ? "" : "not ", irq->enabled ? "" : "not ");
+spin_unlock(&irq->irq_lock);
+}
+
+spin_unlock_irqrestore(&v->arch.vgic.ap_list_lock, flags);
+}
+
 struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
   unsigned int virq)
 {
-- 
2.14.1


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

[Xen-devel] [PATCH v3 04/39] ARM: GIC: Allow reading pending state of a hardware IRQ

[Andre Przywara]

To synchronize level triggered interrupts which are mapped into a guest,
we need to update the virtual line level at certain points in time.
For a hardware mapped interrupt the GIC is the only place where we can
easily access this information.
Implement a gic_hw_operations member to return the pending state of a
particular interrupt. Due to hardware limitations this only works for
private interrupts of the current CPU, so there is no CPU field in the
prototype.
This adds gicv2/3_peek_irq() helper functions, to read a bit in a bitmap
spread over several MMIO registers.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
Changelog v2 ... v3:
- introduce gicv[23]_peek_irq() (moved from patch before)

 xen/arch/arm/gic-v2.c | 15 +++
 xen/arch/arm/gic-v3.c | 19 +++
 xen/include/asm-arm/gic.h | 11 +++
 3 files changed, 45 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d1f1578c05..b440a45e8e 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -243,6 +243,15 @@ static void gicv2_poke_irq(struct irq_desc *irqd, uint32_t 
offset)
 writel_gicd(1U << (irqd->irq % 32), offset + (irqd->irq / 32) * 4);
 }
 
+static bool gicv2_peek_irq(struct irq_desc *irqd, uint32_t offset)
+{
+uint32_t reg;
+
+reg = readl_gicd(offset + (irqd->irq / 32) * 4) & (1U << (irqd->irq % 32));
+
+return reg;
+}
+
 static void gicv2_set_active_state(struct irq_desc *irqd, bool active)
 {
 ASSERT(spin_is_locked(&irqd->lock));
@@ -580,6 +589,11 @@ static unsigned int gicv2_read_apr(int apr_reg)
return readl_gich(GICH_APR);
 }
 
+static bool gicv2_read_pending_state(struct irq_desc *irqd)
+{
+return gicv2_peek_irq(irqd, GICD_ISPENDR);
+}
+
 static void gicv2_irq_enable(struct irq_desc *desc)
 {
 unsigned long flags;
@@ -1325,6 +1339,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .write_lr= gicv2_write_lr,
 .read_vmcr_priority  = gicv2_read_vmcr_priority,
 .read_apr= gicv2_read_apr,
+.read_pending_state  = gicv2_read_pending_state,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
 .make_hwdom_madt = gicv2_make_hwdom_madt,
 .get_hwdom_extra_madt_size = gicv2_get_hwdom_extra_madt_size,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index f244d51661..5c9a783968 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -444,6 +444,19 @@ static void gicv3_poke_irq(struct irq_desc *irqd, u32 
offset, bool wait_for_rwp)
 gicv3_wait_for_rwp(irqd->irq);
 }
 
+static bool gicv3_peek_irq(struct irq_desc *irqd, u32 offset)
+{
+void __iomem *base;
+unsigned int irq = irqd->irq;
+
+if ( irq >= NR_GIC_LOCAL_IRQS)
+base = GICD + (irq / 32) * 4;
+else
+base = GICD_RDIST_SGI_BASE;
+
+return !!(readl(base + offset) & (1U << (irq % 32)));
+}
+
 static void gicv3_unmask_irq(struct irq_desc *irqd)
 {
 gicv3_poke_irq(irqd, GICD_ISENABLER, false);
@@ -1144,6 +1157,11 @@ static unsigned int gicv3_read_apr(int apr_reg)
 }
 }
 
+static bool gicv3_read_pending_state(struct irq_desc *irqd)
+{
+return gicv3_peek_irq(irqd, GICD_ISPENDR);
+}
+
 static void gicv3_irq_enable(struct irq_desc *desc)
 {
 unsigned long flags;
@@ -1812,6 +1830,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .write_lr= gicv3_write_lr,
 .read_vmcr_priority  = gicv3_read_vmcr_priority,
 .read_apr= gicv3_read_apr,
+.read_pending_state  = gicv3_read_pending_state,
 .secondary_init  = gicv3_secondary_cpu_init,
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
 .make_hwdom_madt = gicv3_make_hwdom_madt,
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 2aca243ac3..58b910fe6a 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -373,6 +373,8 @@ struct gic_hw_operations {
 unsigned int (*read_vmcr_priority)(void);
 /* Read APRn register */
 unsigned int (*read_apr)(int apr_reg);
+/* Query the pending state of an interrupt at the distributor level. */
+bool (*read_pending_state)(struct irq_desc *irqd);
 /* Secondary CPU init */
 int (*secondary_init)(void);
 /* Create GIC node for the hardware domain */
@@ -417,6 +419,15 @@ static inline void gic_set_pending_state(struct irq_desc 
*irqd, bool state)
 gic_hw_ops->set_pending_state(irqd, state);
 }
 
+/*
+ * Read the pending state of an interrupt from the distributor.
+ * For private IRQs this only works for those of the current CPU.
+ */
+static inline bool gic_read_pending_state(struct irq_desc *irqd)
+{
+return gic_hw_ops->read_pending_state(irqd);
+}
+
 void register_gic_ops(const struct gic_hw_operations *ops);
 int gic_make_hwdom_dt_node(const struct domain *d,
const struct dt_device_node *gic,
-- 
2.14.1


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

[Xen-devel] [PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly

[Andre Przywara]

The event channel IRQ has level triggered semantics, however the current
VGIC treats everything as edge triggered.
To correctly process those IRQs, we have to lower the (virtual) IRQ line
at some point in time, depending on whether ther interrupt condition
still prevails.
Check the per-VCPU evtchn_upcall_pending variable to make the interrupt
line match its status, and call this function upon every hypervisor
entry.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/domain.c   | 7 +++
 xen/arch/arm/traps.c| 1 +
 xen/include/asm-arm/event.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ff97f2bc76..9688e62f78 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -953,6 +953,13 @@ void vcpu_mark_events_pending(struct vcpu *v)
 vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
 }
 
+void vcpu_update_evtchn_irq(struct vcpu *v)
+{
+bool pending = vcpu_info(v, evtchn_upcall_pending);
+
+vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, pending);
+}
+
 /* The ARM spec declares that even if local irqs are masked in
  * the CPSR register, an irq should wake up a cpu from WFI anyway.
  * For this reason we need to check for irqs that need delivery,
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 2638446693..5c18e918b0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2033,6 +2033,7 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
  * trap and how it can be optimised.
  */
 vtimer_update_irqs(current);
+vcpu_update_evtchn_irq(current);
 #endif
 
 vgic_sync_from_lrs(current);
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index c7a415ef57..2f51864043 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -6,6 +6,7 @@
 
 void vcpu_kick(struct vcpu *v);
 void vcpu_mark_events_pending(struct vcpu *v);
+void vcpu_update_evtchn_irq(struct vcpu *v);
 void vcpu_block_unless_event_pending(struct vcpu *v);
 
 static inline int vcpu_event_delivery_is_enabled(struct vcpu *v)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 14/39] ARM: new VGIC: Add GICv2 world switch backend

[Andre Przywara]

Processing maintenance interrupts and accessing the list registers
are dependent on the host's GIC version.
Introduce vgic-v2.c to contain GICv2 specific functions.
Implement the GICv2 specific code for syncing the emulation state
into the VGIC registers.
This also adds the hook to let Xen setup the host GIC addresses.

This is based on Linux commit 140b086dd197, written by Marc Zyngier.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- remove no longer needed asm/io.h header
- replace 0/1 with false/true for bool's
- clear _IRQ_INPROGRESS bit when retiring hardware mapped IRQ
- fix indentation and w/s issues

Changelog v1 ... v2:
- remove v2 specific underflow function (now generic)
- re-add Linux code to properly handle acked level IRQs

 xen/arch/arm/vgic/vgic-v2.c | 239 
 xen/arch/arm/vgic/vgic.c|   6 ++
 xen/arch/arm/vgic/vgic.h|   9 ++
 3 files changed, 254 insertions(+)
 create mode 100644 xen/arch/arm/vgic/vgic-v2.c

diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
new file mode 100644
index 00..8ab0cfe81d
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -0,0 +1,239 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vgic.h"
+
+static struct {
+bool enabled;
+paddr_t dbase;  /* Distributor interface address */
+paddr_t cbase;  /* CPU interface address & size */
+paddr_t csize;
+paddr_t vbase;  /* Virtual CPU interface address */
+
+/* Offset to add to get an 8kB contiguous region if GIC is aliased */
+uint32_t aliased_offset;
+} gic_v2_hw_data;
+
+void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
+  paddr_t vbase, uint32_t aliased_offset)
+{
+gic_v2_hw_data.enabled = true;
+gic_v2_hw_data.dbase = dbase;
+gic_v2_hw_data.cbase = cbase;
+gic_v2_hw_data.csize = csize;
+gic_v2_hw_data.vbase = vbase;
+gic_v2_hw_data.aliased_offset = aliased_offset;
+}
+
+/*
+ * transfer the content of the LRs back into the corresponding ap_list:
+ * - active bit is transferred as is
+ * - pending bit is
+ *   - transferred as is in case of edge sensitive IRQs
+ *   - set to the line-level (resample time) for level sensitive IRQs
+ */
+void vgic_v2_fold_lr_state(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+unsigned int used_lrs = vcpu->arch.vgic.used_lrs;
+unsigned long flags;
+unsigned int lr;
+
+if ( !used_lrs )/* No LRs used, so nothing to sync back here. */
+return;
+
+gic_hw_ops->update_hcr_status(GICH_HCR_UIE, false);
+
+for ( lr = 0; lr < used_lrs; lr++ )
+{
+struct gic_lr lr_val;
+uint32_t intid;
+struct vgic_irq *irq;
+
+gic_hw_ops->read_lr(lr, &lr_val);
+
+/*
+ * TODO: Possible optimization to avoid reading LRs:
+ * Read the ELRSR to find out which of our LRs have been cleared
+ * by the guest. We just need to know the IRQ number for those, which
+ * we could save in an array when populating the LRs.
+ * This trades one MMIO access (ELRSR) for possibly more than one 
(LRs),
+ * but requires some more code to save the IRQ number and to handle
+ * those finished IRQs according to the algorithm below.
+ * We need some numbers to justify this: chances are that we don't
+ * have many LRs in use most of the time, so we might not save much.
+ */
+gic_hw_ops->clear_lr(lr);
+
+intid = lr_val.virq;
+irq = vgic_get_irq(vcpu->domain, vcpu, intid);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+/*
+ * If a hardware mapped IRQ has been handled for good, we need to
+ * clear the _IRQ_INPROGRESS bit to allow handling of new IRQs.
+ */
+if ( irq->hw && !lr_val.active && !lr_val.pending )
+{
+struct irq_desc *irqd = irq_to_desc(irq->hwintid);
+
+clear_bit(_IRQ_INPROGRESS, &irqd->status);
+}
+
+/* Always preserve the active bit */
+irq->active = lr_val.active;
+
+/* Edge is the only case where we preserve the pending bit */
+if ( irq->config == VGIC_CONFIG_EDGE && lr_val.pending )
+

[Xen-devel] [PATCH v3 17/39] ARM: new VGIC: Add GICv2 MMIO handling framework

[Andre Przywara]

Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers
using the initializer macros provided by the VGIC MMIO framework.
Provide a function to register the GICv2 distributor registers to
the Xen MMIO framework.
The actual handler functions are still stubs in this patch.

This is based on Linux commit fb848db39661, written by Andre Przywara.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic-mmio-v2.c | 83 
 xen/arch/arm/vgic/vgic-mmio.c| 25 
 xen/arch/arm/vgic/vgic-mmio.h|  2 +
 xen/arch/arm/vgic/vgic.h |  2 +
 4 files changed, 112 insertions(+)
 create mode 100644 xen/arch/arm/vgic/vgic-mmio-v2.c

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
new file mode 100644
index 00..6f10cf16ca
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -0,0 +1,83 @@
+/*
+ * VGICv2 MMIO handling functions
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 "vgic.h"
+#include "vgic-mmio.h"
+
+static const struct vgic_register_region vgic_v2_dist_registers[] = {
+REGISTER_DESC_WITH_LENGTH(GICD_CTLR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 12,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IGROUPR,
+vgic_mmio_read_rao, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISENABLER,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICENABLER,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISPENDR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICPENDR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISACTIVER,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICACTIVER,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IPRIORITYR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
+VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ITARGETSR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
+VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICFGR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 2,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_LENGTH(GICD_SGIR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_LENGTH(GICD_CPENDSGIR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
+VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
+REGISTER_DESC_WITH_LENGTH(GICD_SPENDSGIR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
+VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
+};
+
+unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev)
+{
+dev->regions = vgic_v2_dist_registers;
+dev->nr_regions = ARRAY_SIZE(vgic_v2_dist_registers);
+
+return SZ_4K;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index 866023a84d..a03e8d88b9 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -170,6 +170,31 @@ struct mmio_handler_ops vgic_io_ops = {
 .write = dispatch_mmio_write,
 };
 
+int vgic_register_dist_iodev(struct domain *d, gfn_t dist_base_fn,
+ enum vgic_type type)
+{
+struct vgic_io_device *io_device = &d->arch.vgic.dist_iodev;
+unsigned int len;
+
+switch ( type )
+{
+case VGIC_V2:
+len = vgic_v2_init_dist_iodev(io_device);
+break;
+default:
+BUG();
+}
+
+io_device->base_fn = dist_base_fn;
+io_device->iodev_type = IODEV_DIST;
+io_device->redist_vcpu = NULL;
+
+register_mmio_handler(d, &vgic_io_ops, gfn_to_gaddr(dist_base_fn), len,
+  io_device);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic/vgic-mmio.h b/xen/arch/arm/vgic/vgic-mmio.h
index bf062a27ca..c280668694 100644
--- a/xen/arch/arm/vgic/vgic-mmio.h
+++ b/xen/arch/arm/

[Xen-devel] [PATCH v3 38/39] ARM: new VGIC: Allocate two pages for struct vcpu

[Andre Przywara]

At the moment we allocate exactly one page for struct vcpu on ARM, also
have a check in place to prevent it growing beyond 4KB.
As the struct includes the state of all 32 private (per-VCPU) interrupts,
we are at 3840 bytes on arm64 at the moment already. Growing the per-IRQ
VGIC structure even slightly makes the VCPU quickly exceed the 4K limit.
The new VGIC will need more space per virtual IRQ. I spent a few hours
trying to trim this down, but couldn't get it below 4KB, even with the
nasty hacks piling up to save some bytes here and there.
It turns out that beyond efficiency, maybe, there is no real technical
reason this struct has to fit in one page, so lifting the limit to two
pages seems like the most pragmatic solution.
Restrict this to compiling with the new VGIC and for ARM64 only.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- rework alloc_vcpu_struct() to avoid nasty #ifdef

Changelog v1 ... v2:
- confine change to new VGIC and ARM64 only

 xen/arch/arm/domain.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 9688e62f78..23bda3f7db 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -505,19 +505,36 @@ void dump_pageframe_info(struct domain *d)
 
 }
 
+/*
+ * The new VGIC has a bigger per-IRQ structure, so we need more than one
+ * page on ARM64. Cowardly increase the limit in this case.
+ */
+#if defined(CONFIG_NEW_VGIC) && defined(CONFIG_ARM_64)
+#define PAGES_PER_VCPU  2
+#else
+#define PAGES_PER_VCPU  1
+#endif
+
 struct vcpu *alloc_vcpu_struct(void)
 {
 struct vcpu *v;
-BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
-v = alloc_xenheap_pages(0, 0);
+
+BUILD_BUG_ON(sizeof(*v) > PAGES_PER_VCPU * PAGE_SIZE);
+v = alloc_xenheap_pages(get_order_from_pages(PAGES_PER_VCPU), 0);
 if ( v != NULL )
-clear_page(v);
+{
+unsigned int i;
+
+for ( i = 0; i < PAGES_PER_VCPU; i++ )
+clear_page((void *)v + i * PAGE_SIZE);
+}
+
 return v;
 }
 
 void free_vcpu_struct(struct vcpu *v)
 {
-free_xenheap_page(v);
+free_xenheap_pages(v, get_order_from_pages(PAGES_PER_VCPU));
 }
 
 int vcpu_initialise(struct vcpu *v)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 31/39] ARM: new VGIC: Provide system register emulation stub

[Andre Przywara]

The Xen arch code traps system registers writes from the guest and will
relay anything GIC related to the VGIC.
Since this affects only GICv3 (which we don't yet emulate), provide a
stub implementation of vgic_emulate() for now.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 79c6a5553d..ffab0b2635 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -814,6 +814,13 @@ struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, 
struct vcpu *v,
 return desc;
 }
 
+bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
+{
+ASSERT(current->domain->arch.vgic.version == GIC_V3);
+
+return false;
+}
+
 /*
  * was:
  *  int kvm_vgic_map_phys_irq(struct vcpu *vcpu, u32 virt_irq, u32 
phys_irq)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 26/39] ARM: new VGIC: Add SGIPENDR register handlers

[Andre Przywara]

As this register is v2 specific, its implementation lives entirely
in vgic-mmio-v2.c.
This register allows setting the source mask of an IPI.

This is based on Linux commit ed40213ef9b0, written by Andre Przywara.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic-mmio-v2.c | 81 +++-
 1 file changed, 79 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 9ef80608c1..32e0f6fc33 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -181,6 +181,83 @@ static void vgic_mmio_write_target(struct vcpu *vcpu,
 }
 }
 
+static unsigned long vgic_mmio_read_sgipend(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+uint32_t val = 0;
+unsigned int i;
+
+ASSERT(intid < VGIC_NR_SGIS);
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+val |= (uint32_t)irq->source << (i * 8);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return val;
+}
+
+static void vgic_mmio_write_sgipendc(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+unsigned int i;
+unsigned long flags;
+
+ASSERT(intid < VGIC_NR_SGIS);
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+irq->source &= ~((val >> (i * 8)) & 0xff);
+if ( !irq->source )
+irq->pending_latch = false;
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
+static void vgic_mmio_write_sgipends(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+unsigned int i;
+unsigned long flags;
+
+ASSERT(intid < VGIC_NR_SGIS);
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+irq->source |= (val >> (i * 8)) & 0xff;
+
+if ( irq->source )
+{
+irq->pending_latch = true;
+vgic_queue_irq_unlock(vcpu->domain, irq, flags);
+}
+else
+{
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+}
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
 static const struct vgic_register_region vgic_v2_dist_registers[] = {
 REGISTER_DESC_WITH_LENGTH(GICD_CTLR,
 vgic_mmio_read_v2_misc, vgic_mmio_write_v2_misc, 12,
@@ -219,10 +296,10 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_raz, vgic_mmio_write_sgir, 4,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_LENGTH(GICD_CPENDSGIR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
+vgic_mmio_read_sgipend, vgic_mmio_write_sgipendc, 16,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_LENGTH(GICD_SPENDSGIR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
+vgic_mmio_read_sgipend, vgic_mmio_write_sgipends, 16,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 };
 
-- 
2.14.1


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

[Xen-devel] [PATCH v3 28/39] ARM: new VGIC: Add event channel IRQ handling

[Andre Przywara]

The Xen core/arch code relies on two abstracted functions to inject an
event channel IRQ and to query its pending state.
Implement those to query the state of the new VGIC implementation.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 07866d7243..3d818a98ad 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -699,6 +699,29 @@ void vgic_kick_vcpus(struct domain *d)
 }
 }
 
+void arch_evtchn_inject(struct vcpu *v)
+{
+vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
+}
+
+bool vgic_evtchn_irq_pending(struct vcpu *v)
+{
+struct vgic_irq *irq;
+unsigned long flags;
+bool pending;
+
+/* Does not work for LPIs. */
+ASSERT(!is_lpi(v->domain->arch.evtchn_irq));
+
+irq = vgic_get_irq(v->domain, v, v->domain->arch.evtchn_irq);
+spin_lock_irqsave(&irq->irq_lock, flags);
+pending = irq_is_pending(irq);
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(v->domain, irq);
+
+return pending;
+}
+
 struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
   unsigned int virq)
 {
-- 
2.14.1


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

[Xen-devel] [PATCH v3 19/39] ARM: new VGIC: Add ENABLE registers handlers

[Andre Przywara]

As the enable register handlers are shared between the v2 and v3
emulation, their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
This introduces a vgic_sync_hardware_irq() function, which updates the
physical side of a hardware mapped virtual IRQ.
Because the existing locking order between vgic_irq->irq_lock and
irq_desc->lock dictates so, we drop the irq_lock and retake them in the
proper order.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
Changelog v2 ... v3:
- fix indentation
- fix wording in comment
- add Reviewed-by:

Changelog v1 ... v2:
- ASSERT on h/w IRQ and vIRQ staying in sync

 xen/arch/arm/vgic/vgic-mmio-v2.c |   4 +-
 xen/arch/arm/vgic/vgic-mmio.c| 117 +++
 xen/arch/arm/vgic/vgic-mmio.h|  11 
 xen/arch/arm/vgic/vgic.c |  40 +
 xen/arch/arm/vgic/vgic.h |   3 +
 5 files changed, 173 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 43c1ab5906..7efd1c4eb4 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -89,10 +89,10 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_rao, vgic_mmio_write_wi, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISENABLER,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_enable, vgic_mmio_write_senable, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICENABLER,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_enable, vgic_mmio_write_cenable, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISPENDR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index a03e8d88b9..f219b7c509 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -39,6 +39,123 @@ void vgic_mmio_write_wi(struct vcpu *vcpu, paddr_t addr,
 /* Ignore */
 }
 
+/*
+ * Read accesses to both GICD_ICENABLER and GICD_ISENABLER return the value
+ * of the enabled bit, so there is only one function for both here.
+ */
+unsigned long vgic_mmio_read_enable(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+uint32_t value = 0;
+unsigned int i;
+
+/* Loop over all IRQs affected by this read */
+for ( i = 0; i < len * 8; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+if ( irq->enabled )
+value |= (1U << i);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return value;
+}
+
+void vgic_mmio_write_senable(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+unsigned long flags;
+irq_desc_t *desc;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+if ( irq->enabled )/* skip already enabled IRQs */
+{
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+continue;
+}
+
+irq->enabled = true;
+if ( irq->hw )
+{
+/*
+ * The irq cannot be a PPI, we only support delivery
+ * of SPIs to guests.
+ */
+ASSERT(irq->hwintid >= VGIC_NR_PRIVATE_IRQS);
+
+desc = irq_to_desc(irq->hwintid);
+}
+else
+desc = NULL;
+
+vgic_queue_irq_unlock(vcpu->domain, irq, flags);
+
+if ( desc )
+vgic_sync_hardware_irq(vcpu->domain, desc, irq);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
+void vgic_mmio_write_cenable(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq;
+unsigned long flags;
+irq_desc_t *desc;
+
+irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+if ( !irq->enabled )/* skip already disabled IRQs */
+{
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+continue;
+}
+
+irq->enabled = false;
+
+if ( irq->hw )
+{
+/*
+ * The irq cannot be a PPI, we only support delivery
+ * of SPIs to guests.
+ */
+ 

[Xen-devel] [PATCH v3 23/39] ARM: new VGIC: Add CONFIG registers handlers

[Andre Przywara]

The config register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.

This is based on Linux commit 79717e4ac09c, written by Andre Przywara.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic-mmio-v2.c |  2 +-
 xen/arch/arm/vgic/vgic-mmio.c| 54 
 xen/arch/arm/vgic/vgic-mmio.h|  7 ++
 3 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index d2d6a07e1b..a28d0e459b 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -113,7 +113,7 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICFGR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 2,
+vgic_mmio_read_config, vgic_mmio_write_config, 2,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_LENGTH(GICD_SGIR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index 14b69d80d4..5bcb02e8c6 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -419,6 +419,60 @@ void vgic_mmio_write_priority(struct vcpu *vcpu,
 }
 }
 
+unsigned long vgic_mmio_read_config(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 2);
+uint32_t value = 0;
+int i;
+
+for ( i = 0; i < len * 4; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+if ( irq->config == VGIC_CONFIG_EDGE )
+value |= (2U << (i * 2));
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return value;
+}
+
+void vgic_mmio_write_config(struct vcpu *vcpu,
+paddr_t addr, unsigned int len,
+unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 2);
+int i;
+unsigned long flags;
+
+for ( i = 0; i < len * 4; i++ )
+{
+struct vgic_irq *irq;
+
+/*
+ * The configuration cannot be changed for SGIs in general,
+ * for PPIs this is IMPLEMENTATION DEFINED. The arch timer
+ * code relies on PPIs being level triggered, so we also
+ * make them read-only here.
+ */
+if ( intid + i < VGIC_NR_PRIVATE_IRQS )
+continue;
+
+irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+if ( test_bit(i * 2 + 1, &val) )
+irq->config = VGIC_CONFIG_EDGE;
+else
+irq->config = VGIC_CONFIG_LEVEL;
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
 static int match_region(const void *key, const void *elt)
 {
 const unsigned int offset = (unsigned long)key;
diff --git a/xen/arch/arm/vgic/vgic-mmio.h b/xen/arch/arm/vgic/vgic-mmio.h
index b2d572d562..3566cf237c 100644
--- a/xen/arch/arm/vgic/vgic-mmio.h
+++ b/xen/arch/arm/vgic/vgic-mmio.h
@@ -126,6 +126,13 @@ void vgic_mmio_write_priority(struct vcpu *vcpu,
   paddr_t addr, unsigned int len,
   unsigned long val);
 
+unsigned long vgic_mmio_read_config(struct vcpu *vcpu,
+paddr_t addr, unsigned int len);
+
+void vgic_mmio_write_config(struct vcpu *vcpu,
+paddr_t addr, unsigned int len,
+unsigned long val);
+
 unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
 
 #endif
-- 
2.14.1


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

[Xen-devel] [PATCH v3 05/39] ARM: timer: Handle level triggered IRQs correctly

[Andre Przywara]

The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we also have to keep track of when the line lowers, as the
emulation depends on it: Upon entering the guest, the new VGIC will
*clear* the virtual interrupt line, so it needs to re-sample the actual
state after returning from the guest.
So we have to sync the state of the interrupt condition at certain
points to catch when the line goes low and we can remove the vtimer vIRQ
from the vGIC (and the LR).
The VGIC in Xen so far only implemented edge triggered vIRQs, really, so
we need to add new functionality to re-sample the interrupt state.
Do this only when the new VGIC is in use.

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- move vtimer_sync() from time.c into vtimer.c
- rename function to vtimer_update_irqs()
- refactor functionality into new static function, to ...
- handle physical timer as well
- extending comments

Changelog v1 ... v2:
- restrict to new VGIC
- add TODO: comment

 xen/arch/arm/traps.c | 11 ++
 xen/arch/arm/vtimer.c| 49 
 xen/include/asm-arm/vtimer.h |  1 +
 3 files changed, 61 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7411bff7a7..2638446693 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,6 +2024,17 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
 if ( current->arch.hcr_el2 & HCR_VA )
 current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
 
+#ifdef CONFIG_NEW_VGIC
+/*
+ * We need to update the state of our emulated devices using level
+ * triggered interrupts before syncing back the VGIC state.
+ *
+ * TODO: Investigate whether this is necessary to do on every
+ * trap and how it can be optimised.
+ */
+vtimer_update_irqs(current);
+#endif
+
 vgic_sync_from_lrs(current);
 }
 }
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 8164f6c7f1..c99dd237d1 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -334,6 +334,55 @@ bool vtimer_emulate(struct cpu_user_regs *regs, union hsr 
hsr)
 }
 }
 
+static void vtimer_update_irq(struct vcpu *v, struct vtimer *vtimer,
+  uint32_t vtimer_ctl)
+{
+bool level;
+
+/* Filter for the three bits that determine the status of the timer */
+vtimer_ctl &= (CNTx_CTL_ENABLE | CNTx_CTL_PENDING | CNTx_CTL_MASK);
+
+/* The level is high if the timer is pending and enabled, but not masked. 
*/
+level = (vtimer_ctl == (CNTx_CTL_ENABLE | CNTx_CTL_PENDING));
+
+/*
+ * This is mostly here to *lower* the virtual interrupt line if the timer
+ * is no longer pending.
+ * We would have injected an IRQ already via SOFTIRQ when the timer 
expired.
+ * Doing it here again is basically a NOP if the line was already high.
+ */
+vgic_inject_irq(v->domain, v, vtimer->irq, level);
+}
+
+/**
+ * vtimer_update_irqs() - update the virtual timers' IRQ lines after a guest 
run
+ * @vcpu: The VCPU to sync the timer state
+ *
+ * After returning from a guest, update the state of the timers' virtual
+ * interrupt lines, to model the level triggered interrupts correctly.
+ * If the guest has handled a timer interrupt, the virtual interrupt line
+ * needs to be lowered explicitly. vgic_inject_irq() takes care of that.
+ */
+void vtimer_update_irqs(struct vcpu *v)
+{
+/*
+ * For the virtual timer we read the current state from the hardware.
+ * Technically we should keep the CNTx_CTL_MASK bit here, to catch if
+ * the timer interrupt is masked. However Xen *always* masks the timer
+ * upon entering the hypervisor, leaving it up to the guest to un-mask it.
+ * So we would always read a "low" level, despite the condition being
+ * actually "high".  Ignoring the mask bit solves this (for now).
+ *
+ * TODO: The proper fix for this is to make vtimer vIRQ hardware mapped,
+ * but this requires reworking the arch timer to implement this.
+ */
+vtimer_update_irq(v, &v->arch.virt_timer,
+  READ_SYSREG32(CNTV_CTL_EL0) & ~CNTx_CTL_MASK);
+
+/* For the physical timer we rely on our emulated state. */
+vtimer_update_irq(v, &v->arch.phys_timer, v->arch.phys_timer.ctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/vtimer.h b/xen/include/asm-arm/vtimer.h
index 5aaddc6f63..91d88b377f 100644
--- a/xen/include/asm-arm/vtimer.h
+++ b/xen/include/asm-arm/vtimer.h
@@ -27,6 +27,7 @@ extern bool vtimer_emulate(struct cpu_user_regs *regs, union 
hsr hsr);
 extern int virt_timer_save(struct vcpu *v);
 extern int virt_timer_restore(struct vcpu *v);
 extern void vcpu_timer_destroy(struct vcpu *v);
+void vtimer_update_irqs(struct vcpu *v);
 
 #endif
 
-- 
2.14.1


___
Xen-devel 

[Xen-devel] [PATCH v3 07/39] ARM: vPL011: Use the VGIC's level triggered IRQs handling if available

[Andre Przywara]

The emulated ARM SBSA UART is using level triggered IRQ semantics,
however the current VGIC can only handle edge triggered IRQs, really.
Disable the existing workaround for this problem in case we have the
new VGIC in place, which can properly handle level triggered IRQs.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vpl011.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 5dcf4bec18..a281eabd7e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -54,6 +54,7 @@ static void vpl011_update_interrupt_status(struct domain *d)
  */
 ASSERT(spin_is_locked(&vpl011->lock));
 
+#ifndef CONFIG_NEW_VGIC
 /*
  * TODO: PL011 interrupts are level triggered which means
  * that interrupt needs to be set/clear instead of being
@@ -71,6 +72,9 @@ static void vpl011_update_interrupt_status(struct domain *d)
 vgic_inject_irq(d, NULL, GUEST_VPL011_SPI, true);
 
 vpl011->shadow_uartmis = uartmis;
+#else
+vgic_inject_irq(d, NULL, GUEST_VPL011_SPI, uartmis);
+#endif
 }
 
 static uint8_t vpl011_read_data(struct domain *d)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 11/39] Add list_sort() routine from Linux

[Andre Przywara]

This pulls in Linux' list_sort.c, which is a merge sort implementation
for linked lists. Apart from adding a full featured license header and
adjusting the #include file, nothing has been changed in this code.
Define a promptless Kconfig which configurations can select when they
need this code and add it to the Makefile.

This is from Linux' lib/list_sort.c, as of commit e327fd7c8667
("lib: add module support to linked list sorting tests").

Signed-off-by: Andre Przywara 
---
Changelog v2 ... v3:
- introduce promptless Kconfig
- add Makefile line
- note Linux commit ID

 xen/common/Kconfig  |   3 +
 xen/common/Makefile |   1 +
 xen/common/list_sort.c  | 157 
 xen/include/xen/list_sort.h |  11 
 4 files changed, 172 insertions(+)
 create mode 100644 xen/common/list_sort.c
 create mode 100644 xen/include/xen/list_sort.h

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 68abf7a5e5..986f6c4149 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -44,6 +44,9 @@ config HAS_GDBSX
 config HAS_IOPORTS
bool
 
+config NEEDS_LIST_SORT
+bool
+
 config HAS_BUILD_ID
string
option env="XEN_HAS_BUILD_ID"
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 3a349f478b..24d4752ccc 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -19,6 +19,7 @@ obj-y += keyhandler.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-y += lib.o
+obj-$(CONFIG_NEEDS_LIST_SORT) += list_sort.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-y += lzo.o
 obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o
diff --git a/xen/common/list_sort.c b/xen/common/list_sort.c
new file mode 100644
index 00..af2b2f6519
--- /dev/null
+++ b/xen/common/list_sort.c
@@ -0,0 +1,157 @@
+/*
+ * list_sort.c: merge sort implementation for linked lists
+ * Copied from the Linux kernel (lib/list_sort.c)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
+
+#include 
+#include 
+
+#define MAX_LIST_LENGTH_BITS 20
+
+/*
+ * Returns a list organized in an intermediate format suited
+ * to chaining of merge() calls: null-terminated, no reserved or
+ * sentinel head node, "prev" links not maintained.
+ */
+static struct list_head *merge(void *priv,
+   int (*cmp)(void *priv, struct list_head *a,
+   struct list_head *b),
+   struct list_head *a, struct list_head *b)
+{
+   struct list_head head, *tail = &head;
+
+   while (a && b) {
+   /* if equal, take 'a' -- important for sort stability */
+   if ((*cmp)(priv, a, b) <= 0) {
+   tail->next = a;
+   a = a->next;
+   } else {
+   tail->next = b;
+   b = b->next;
+   }
+   tail = tail->next;
+   }
+   tail->next = a?:b;
+   return head.next;
+}
+
+/*
+ * Combine final list merge with restoration of standard doubly-linked
+ * list structure.  This approach duplicates code from merge(), but
+ * runs faster than the tidier alternatives of either a separate final
+ * prev-link restoration pass, or maintaining the prev links
+ * throughout.
+ */
+static void merge_and_restore_back_links(void *priv,
+   int (*cmp)(void *priv, struct list_head *a,
+   struct list_head *b),
+   struct list_head *head,
+   struct list_head *a, struct list_head *b)
+{
+   struct list_head *tail = head;
+   u8 count = 0;
+
+   while (a && b) {
+   /* if equal, take 'a' -- important for sort stability */
+   if ((*cmp)(priv, a, b) <= 0) {
+   tail->next = a;
+   a->prev = tail;
+   a = a->next;
+   } else {
+   tail->next = b;
+   b->prev = tail;
+   b = b->next;
+   }
+   tail = tail->next;
+   }
+   tail->next = a ? : b;
+
+   do {
+   /*
+* In worst cases this loop may run many iterations.
+* Continue callbacks to the client even though no
+* element comparison is needed, so the client's cmp()
+* ro

[Xen-devel] [PATCH v3 27/39] ARM: new VGIC: Handle hardware mapped IRQs

[Andre Przywara]

The VGIC supports virtual IRQs to be connected to a hardware IRQ, so
when a guest EOIs the virtual interrupt, it affects the state of that
corresponding interrupt on the hardware side at the same time.
Implement the interface that the Xen arch/core code expects to connect
the virtual and the physical world.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic.c | 71 
 1 file changed, 71 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 90041eb071..07866d7243 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -699,6 +699,77 @@ void vgic_kick_vcpus(struct domain *d)
 }
 }
 
+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
+  unsigned int virq)
+{
+struct irq_desc *desc = NULL;
+struct vgic_irq *irq = vgic_get_irq(d, v, virq);
+unsigned long flags;
+
+if ( !irq )
+return NULL;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+if ( irq->hw )
+{
+ASSERT(irq->hwintid >= VGIC_NR_PRIVATE_IRQS);
+desc = irq_to_desc(irq->hwintid);
+}
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+
+vgic_put_irq(d, irq);
+
+return desc;
+}
+
+/*
+ * was:
+ *  int kvm_vgic_map_phys_irq(struct vcpu *vcpu, u32 virt_irq, u32 
phys_irq)
+ *  int kvm_vgic_unmap_phys_irq(struct vcpu *vcpu, unsigned int virt_irq)
+ */
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *vcpu,
+unsigned int virt_irq, struct irq_desc *desc,
+bool connect)
+{
+struct vgic_irq *irq = vgic_get_irq(d, vcpu, virt_irq);
+unsigned long flags;
+int ret = 0;
+
+if ( !irq )
+return -EINVAL;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+if ( connect )  /* assign a mapped IRQ */
+{
+/* The VIRQ should not be already enabled by the guest */
+if ( !irq->hw && !irq->enabled )
+{
+irq->hw = true;
+irq->hwintid = desc->irq;
+}
+else
+ret = -EBUSY;
+}
+else/* remove a mapped IRQ */
+{
+if ( desc && irq->hwintid != desc->irq )
+{
+ret = -EINVAL;
+}
+else
+{
+irq->hw = false;
+irq->hwintid = 0;
+}
+}
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(d, irq);
+
+return ret;
+}
+
 static unsigned int translate_irq_type(bool is_level)
 {
 return is_level ? IRQ_TYPE_LEVEL_HIGH : IRQ_TYPE_EDGE_RISING;
-- 
2.14.1


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

[Xen-devel] [PATCH v3 21/39] ARM: new VGIC: Add ACTIVE registers handlers

[Andre Przywara]

The active register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
Since activation/deactivation of an interrupt may happen entirely in the
guest without it ever exiting, we need some extra logic to properly track
the active state.
For clearing the active state, we would basically have to halt the guest
to make sure this is properly propagated into the respective VCPUs.
This is not yet implemented in Xen.
Fortunately this feature is mostly used to reset a just in initialised
GIC, so chances are we are tasked to clear bits that are already zero.
Add a simple check to avoid pointless warnings in this case.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic-mmio-v2.c |  4 +-
 xen/arch/arm/vgic/vgic-mmio.c| 91 
 xen/arch/arm/vgic/vgic-mmio.h| 11 +
 3 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index a48c554040..724681e0f8 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -101,10 +101,10 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_pending, vgic_mmio_write_cpending, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISACTIVER,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_active, vgic_mmio_write_sactive, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICACTIVER,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_active, vgic_mmio_write_cactive, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IPRIORITYR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index 53b8978c02..b79e431f50 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -281,6 +281,97 @@ void vgic_mmio_write_cpending(struct vcpu *vcpu,
 }
 }
 
+/*
+ * The actual active bit for a virtual IRQ is held in the LR. Our shadow
+ * copy in struct vgic_irq is only synced when needed and may not be
+ * up-to-date all of the time.
+ * Returning the actual active state is quite costly (stopping all
+ * VCPUs processing any affected vIRQs), so we use a simple implementation
+ * to get the best possible answer.
+ */
+unsigned long vgic_mmio_read_active(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+uint32_t value = 0;
+unsigned int i;
+
+/* Loop over all IRQs affected by this read */
+for ( i = 0; i < len * 8; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+if ( irq->active )
+value |= (1U << i);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return value;
+}
+
+/*
+ * We don't actually support clearing the active state of an IRQ (yet).
+ * However there is a chance that most guests use this for initialization.
+ * We check whether this MMIO access would actually affect any active IRQ,
+ * and only print our warning in this case. So clearing already non-active
+ * IRQs would not be moaned about in the logs.
+ */
+void vgic_mmio_write_cactive(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+/*
+ * If we know that the IRQ is active or we can't be sure about
+ * it (because it is currently in a CPU), log the not properly
+ * emulated MMIO access.
+ */
+if ( irq->active || irq->vcpu )
+printk(XENLOG_G_ERR
+   "%pv: vGICD: IRQ%u: clearing active state not supported\n",
+   vcpu, irq->intid);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
+/*
+ * We don't actually support setting the active state of an IRQ (yet).
+ * We check whether this MMIO access would actually affect any non-active IRQ,
+ * and only print our warning in this case.
+ */
+void vgic_mmio_write_sactive(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+/*
+ * If we know that the IRQ is not active or we can't be sure about
+ * it (because it is currently in a CPU), log the not properly
+ * emulated MMIO access.
+ 

[Xen-devel] [PATCH v3 22/39] ARM: new VGIC: Add PRIORITY registers handlers

[Andre Przywara]

The priority register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.

This is based on Linux commit 055658bf48fc, written by Andre Przywara.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic/vgic-mmio-v2.c |  2 +-
 xen/arch/arm/vgic/vgic-mmio.c| 47 
 xen/arch/arm/vgic/vgic-mmio.h|  7 ++
 xen/arch/arm/vgic/vgic.h |  2 ++
 4 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 724681e0f8..d2d6a07e1b 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -107,7 +107,7 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_active, vgic_mmio_write_cactive, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IPRIORITYR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
+vgic_mmio_read_priority, vgic_mmio_write_priority, 8,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ITARGETSR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index b79e431f50..14b69d80d4 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -372,6 +372,53 @@ void vgic_mmio_write_sactive(struct vcpu *vcpu,
 }
 }
 
+unsigned long vgic_mmio_read_priority(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+unsigned int i;
+uint32_t val = 0;
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+val |= (uint32_t)irq->priority << (i * 8);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return val;
+}
+
+/*
+ * We currently don't handle changing the priority of an interrupt that
+ * is already pending on a VCPU. If there is a need for this, we would
+ * need to make this VCPU exit and re-evaluate the priorities, potentially
+ * leading to this interrupt getting presented now to the guest (if it has
+ * been masked by the priority mask before).
+ */
+void vgic_mmio_write_priority(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len,
+  unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+unsigned int i;
+unsigned long flags;
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+/* Narrow the priority range to what we actually support */
+irq->priority = (val >> (i * 8)) & GENMASK(7, 8 - VGIC_PRI_BITS);
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
 static int match_region(const void *key, const void *elt)
 {
 const unsigned int offset = (unsigned long)key;
diff --git a/xen/arch/arm/vgic/vgic-mmio.h b/xen/arch/arm/vgic/vgic-mmio.h
index 832e2eb3d8..b2d572d562 100644
--- a/xen/arch/arm/vgic/vgic-mmio.h
+++ b/xen/arch/arm/vgic/vgic-mmio.h
@@ -119,6 +119,13 @@ void vgic_mmio_write_sactive(struct vcpu *vcpu,
  paddr_t addr, unsigned int len,
  unsigned long val);
 
+unsigned long vgic_mmio_read_priority(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len);
+
+void vgic_mmio_write_priority(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len,
+  unsigned long val);
+
 unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
 
 #endif
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index 071e061066..c7eeaf7a38 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -25,6 +25,8 @@
 #define VARIANT_ID_XEN  0x01
 #define IMPLEMENTER_ARM 0x43b
 
+#define VGIC_PRI_BITS   5
+
 #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
 
 static inline bool irq_is_pending(struct vgic_irq *irq)
-- 
2.14.1


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