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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  3ee5a4ddf717cf8438a6b3c359bf6be48fd6bee7
baseline version:
 libvirt  60b3fcd90cbd83e5721484d72414dfee1706dab8

Last test of basis   120863  2018-03-17 07:41:00 Z2 days
Testing same since   120921  2018-03-18 17:14:03 Z1 days1 attempts


People who touched revisions under test:
  Chen Hanxiao 
  Michal Privoznik 

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



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

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

Explanation of these reports, and of osstest in general, is at
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

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

[osstest service owner]

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

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-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  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  366 days
Testing same since   120360  2018-03-09 04:19:20 Z   10 days8 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 20/20] xen/domain: Allocate d->vcpu[] in arch_domain_create()

[Julien Grall]

(+ Andre)

On 03/19/2018 07:13 PM, Andrew Cooper wrote:

On the ARM side, audit config->max_vcpus after the vgic has been initialised,
at which point we have a real upper bound to test against.  This allows for
the removal of the vgic_max_vcpus() juggling to cope with the call from
evtchn_init() before the vgic settings are known.


I would rather keep vgic_max_vcpus() around. We are introducing a new 
vGIC in Xen that will cohabit with the current vGIC for a few releases. 
See [1].


So a better solution is to rework vgic_max_vcpus() to drop the NULL check.

I would also fine to directly call vgic_max_vcpus() in 
arch_domain_create and therefore drop domain_max_vcpus().


Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2018-03/msg01831.html

--
Julien Grall

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

Re: [Xen-devel] [PATCH 18/20] xen/dom0: Arrange for dom0_cfg to contain the real max_vcpus value

[Julien Grall]

Hi Andrew,

On 03/19/2018 07:13 PM, Andrew Cooper wrote:

Make dom0_max_vcpus() a common interface, and implement it on ARM by splitting
the existing alloc_dom0_vcpu0() function in half.

As domain_create() doesn't yet set up the vcpu array, the max value is also
passed into alloc_dom0_vcpu0().  This is temporary for bisectibility and
removed in the following patch.

Signed-off-by: Andrew Cooper 


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 14/20] xen/gnttab: Remove replace_grant_supported()

[Julien Grall]

Hi Andrew,

On 03/19/2018 07:13 PM, Andrew Cooper wrote:

It is identical on all architecture, and this is a better overall than fixing
it up to have a proper boolean return value.

Signed-off-by: Andrew Cooper 


Reviewed-by: Julien Grall 

Cheers,


---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
  xen/common/grant_table.c  | 3 ---
  xen/include/asm-arm/grant_table.h | 4 
  xen/include/asm-x86/grant_table.h | 5 -
  3 files changed, 12 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 1820191..93443be 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3459,9 +3459,6 @@ do_grant_table_op(
  
  if ( unlikely(!guest_handle_okay(unmap, count)) )

  goto out;
-rc = -ENOSYS;
-if ( unlikely(!replace_grant_supported()) )
-goto out;
  rc = gnttab_unmap_and_replace(unmap, count);
  if ( rc > 0 )
  {
diff --git a/xen/include/asm-arm/grant_table.h 
b/xen/include/asm-arm/grant_table.h
index d2027d2..63a2fdd 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -23,10 +23,6 @@ int replace_grant_host_mapping(unsigned long gpaddr, 
unsigned long mfn,
  void gnttab_mark_dirty(struct domain *d, unsigned long l);
  #define gnttab_create_status_page(d, t, i) do {} while (0)
  #define gnttab_release_host_mappings(domain) 1
-static inline int replace_grant_supported(void)
-{
-return 1;
-}
  
  /*

   * The region used by Xen on the memory will never be mapped in DOM0
diff --git a/xen/include/asm-x86/grant_table.h 
b/xen/include/asm-x86/grant_table.h
index 4ac0b9b..514eaf3 100644
--- a/xen/include/asm-x86/grant_table.h
+++ b/xen/include/asm-x86/grant_table.h
@@ -101,9 +101,4 @@ static inline void gnttab_clear_flag(unsigned int nr, 
uint16_t *st)
  #define gnttab_need_iommu_mapping(d)\
  (!paging_mode_translate(d) && need_iommu(d))
  
-static inline int replace_grant_supported(void)

-{
-return 1;
-}
-
  #endif /* __ASM_GRANT_TABLE_H__ */



--
Julien Grall

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

[Xen-devel] [linux-4.9 test] 120913: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120670
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120670
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120670
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120670
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120670
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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-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-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   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-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-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:
 linux46e076f0dad02f5c445a5c27adbd3f06147e33ed
baseline version:
 linuxb67416226a0cff3f49032de36906ad1ebe5694a0

Last test of basis   120670  2018-03-13 10:59:23 Z6 days
Testing same since   120913  2018-03-18 11:32:38 Z1 days1 attempts


People who touched revisions under test:
  Adrian Hunter 
  Alan Stern 
  Alex Deucher 
  Arnaldo 

Re: [Xen-devel] Xen ARM Community Call Wednesday 4th April 4PM UTC

[Julien Grall]

On 03/16/2018 09:57 AM, Julien Grall wrote:

On 16/03/18 00:08, Stefano Stabellini wrote:

Hi all,


Hi Stefano,


I suggest to have the next community call on Wednesday 4th April 4PM
UTC. Keep in mind that due to Daylight Savings Time 4PM UTC is the usual
time slot: 9AM California, 5PM UK. Does it work for everybody?


This works for me.


[...]



If you have any specific topics to discuss, please reply to this email.


I would like to discuss about Xen on Automotive. What would be the 
requirements and missing pieces.


The outcome of the discussion would be tracked on the wiki (maybe [1]).

Cheers,

[1] 
https://wiki.xenproject.org/wiki/Embedded_and_Automotive_PV_Drivers/Roadmap




Cheers,

Stefano





--
Julien Grall

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

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

[Julien Grall]

Hi Andre,

On 03/15/2018 08:30 PM, Andre Przywara wrote:

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 4b9664f313..342b95be31 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -968,6 +968,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


Why not just avoid selecting HAS_GICV3?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 43/45] ARM: new VGIC: vgic-init: implement map_resources

[Julien Grall]

Hi Andre,

On 03/15/2018 08:30 PM, Andre Przywara wrote:

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 

Cheers,


---
Changelog v1 ... v2:
- whitespace fixes

  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 4662346327..c35f406a06 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -225,6 +225,72 @@ void vgic_v2_enable(struct vcpu *vcpu)
  gic_hw_ops->update_hcr_status(GICH_HCR_EN, 1);
  }
  
+int vgic_v2_map_resources(struct domain *d)

+{
+struct vgic_dist *dist = >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 def1ac478a..7af982f100 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -63,6 +63,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);
  



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 42/45] ARM: new VGIC: vgic-init: implement vgic_init

[Julien Grall]

Hi Andre,

On 03/15/2018 08:30 PM, Andre Przywara wrote:

+/* 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 = >arch.vgic;
+unsigned int i;
+int ret;
+
+/* Limit the number of virtual SPIs supported to (1020 - 32) = 988  */
+if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
+return -EINVAL;
+nr_spis = ROUNDUP(nr_spis, 32);


I think the roundup is misplaced. Here you might allow the guest to 
inject IRQs 1020-1023. From the Spec, using those values in the LRs for 
the vINTID field will result to unpredictable behavior.


So you want to move the ROUNDUP before the check. This will limit the 
SPI INT ID to 992, but this is not a big deal for 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 v2 40/45] ARM: new VGIC: vgic-init: register VGIC

[Julien Grall]

Hi Andre,

On 03/15/2018 08:30 PM, Andre Przywara wrote:

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 002fec57e6..4b9664f313 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -946,6 +946,28 @@ void vgic_sync_hardware_irq(struct domain *d,
  spin_unlock_irqrestore(>lock, flags);
  }
  
+unsigned int vgic_max_vcpus(const struct domain *d)

+{
+unsigned int vgic_vcpu_limit;
+
+switch ( d->arch.vgic.version )
+{
+#ifdef CONFIG_HAS_GICV3
+case GIC_V3:
+vgic_vcpu_limit = VGIC_V3_MAX_CPUS;
+break;
+#endif


It is a bit strange that you handle GICV3 here but don't in 
domain_vgic_register.



+case GIC_V2:
+vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
+break;
+default:
+vgic_vcpu_limit = MAX_VIRT_CPUS;


I feel this is a bit odd. We only support GICv2 and GICv3 and the enum 
has two values. Likely GCC will complain if CONFIG_HAS_GICV3 is set 
because default label is not used.


Lastly, I can't see how you handle the corner case mentioned in the 
current vGIC:


/*
 * Since evtchn_init would call domain_max_vcpus for poll_mask
 * allocation when the vgic_ops haven't been initialised yet,
 * we return MAX_VIRT_CPUS if d->arch.vgic.handler is null.
 */

The comment in the code would also be very useful as the reason to call 
vgic_max_vcpus before the full initialization is not that straightforward.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 09/45] ARM: GIC: Allow tweaking the active and pending state of an IRQ

[Julien Grall]

Hi Andre,

On 03/19/2018 05:54 PM, Andre Przywara wrote:

Which helpers? The set_{pending,active}_state() functions? I already put
some kind of warning before the (wrapper) prototypes:
/*
  * Set the active state of an IRQ. This should be used with care, as
  * this directly forces the active bit, without considering the GIC
  * state machine.
  * For private IRQs this only works for those of the current CPU.
  */


Oh yes, I missed that. Sorry for the noise.

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 05/12] hvmloader: add Q35 DSDT table loading

[Alexey G]

On Mon, 19 Mar 2018 14:45:29 +
Roger Pau Monné  wrote:

>On Tue, Mar 13, 2018 at 04:33:50AM +1000, Alexey Gerasimenko wrote:
>> Allows to select Q35 DSDT table in hvmloader_acpi_build_tables().
>> Function get_pc_machine_type() is used to select a proper table
>> (i440/q35).
>> 
>> As we are bound to the qemu-xen device model for Q35, no need
>> to initialize config->dsdt_15cpu/config->dsdt_15cpu_len fields.
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---
>>  tools/firmware/hvmloader/util.c | 13 +++--
>>  tools/firmware/hvmloader/util.h |  2 ++
>>  2 files changed, 13 insertions(+), 2 deletions(-)
>> 
>> diff --git a/tools/firmware/hvmloader/util.c
>> b/tools/firmware/hvmloader/util.c index 5739a87628..d8db9e3c8e 100644
>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -955,8 +955,17 @@ void hvmloader_acpi_build_tables(struct
>> acpi_config *config, }
>>  else if ( !strncmp(s, "qemu_xen", 9) )
>>  {
>> -config->dsdt_anycpu = dsdt_anycpu_qemu_xen;
>> -config->dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len;
>> +if (get_pc_machine_type() == MACHINE_TYPE_Q35)  
>
>Coding style (missing spaces between parentheses), and I would prefer
>a switch here.

OK, will change to a switch.

>IMO you should add a BUG_ON(Q35) in the qemu_xen_traditional condition
>above this one..

AFAIR qemu-traditional knows nothing about Q35 emulation, so we won't
ever encounter a Q35 chipset while using qemu-traditional.

>> +{
>> +config->dsdt_anycpu = dsdt_q35_anycpu_qemu_xen;
>> +config->dsdt_anycpu_len = dsdt_q35_anycpu_qemu_xen_len;
>> +}
>> +else
>> +{
>> +config->dsdt_anycpu = dsdt_anycpu_qemu_xen;
>> +config->dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len;
>> +}
>> +
>>  config->dsdt_15cpu = NULL;
>>  config->dsdt_15cpu_len = 0;
>>  }
>> diff --git a/tools/firmware/hvmloader/util.h
>> b/tools/firmware/hvmloader/util.h index 7c77bedb00..fd2d885c96 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -288,7 +288,9 @@ bool check_overlap(uint64_t start, uint64_t size,
>> uint64_t reserved_start, uint64_t reserved_size);
>>  
>>  extern const unsigned char dsdt_anycpu_qemu_xen[], dsdt_anycpu[],
>> dsdt_15cpu[]; +extern const unsigned char dsdt_q35_anycpu_qemu_xen[];
>>  extern const int dsdt_anycpu_qemu_xen_len, dsdt_anycpu_len,
>> dsdt_15cpu_len; +extern const int dsdt_q35_anycpu_qemu_xen_len;  
>
>Since you are adding this, maybe unsigned int? (or size_t?)

No problem, ok.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 120780

Tests which did not succeed, but are not blocking:
 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-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 120780
 test-armhf-armhf-libvirt 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-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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 Z4 days
Testing same since   120911  2018-03-18 11:05:49 Z1 days1 attempts


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

Re: [Xen-devel] [RFC PATCH 06/12] hvmloader: add basic Q35 support

[Alexey G]

On Mon, 19 Mar 2018 15:30:14 +
Roger Pau Monné  wrote:

>On Tue, Mar 13, 2018 at 04:33:51AM +1000, Alexey Gerasimenko wrote:
>> This patch does following:
>> 
>> 1. Move PCI-device specific initialization out of pci_setup function
>> to the newly created class_specific_pci_device_setup function to
>> simplify code.
>> 
>> 2. PCI-device specific initialization extended with LPC controller
>> initialization
>> 
>> 3. Initialize PIRQA...{PIRQD, PIRQH} routing accordingly to the
>> emulated south bridge (either located on PCI_ISA_DEVFN or
>> PCI_ICH9_LPC_DEVFN).
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---
>>  tools/firmware/hvmloader/config.h |   1 +
>>  tools/firmware/hvmloader/pci.c| 162
>> -- 2 files changed, 104
>> insertions(+), 59 deletions(-)
>> 
>> diff --git a/tools/firmware/hvmloader/config.h
>> b/tools/firmware/hvmloader/config.h index 6e00413f2e..6fde6b7b60
>> 100644 --- a/tools/firmware/hvmloader/config.h
>> +++ b/tools/firmware/hvmloader/config.h
>> @@ -52,6 +52,7 @@ extern uint8_t ioapic_version;
>>  
>>  #define PCI_ISA_DEVFN   0x08/* dev 1, fn 0 */
>>  #define PCI_ISA_IRQ_MASK0x0c20U /* ISA IRQs 5,10,11 are PCI
>> connected */ +#define PCI_ICH9_LPC_DEVFN  0xf8/* dev 31, fn 0 */
>>  
>>  /* MMIO hole: Hardcoded defaults, which can be dynamically
>> expanded. */ #define PCI_MEM_END 0xfc00
>> diff --git a/tools/firmware/hvmloader/pci.c
>> b/tools/firmware/hvmloader/pci.c index 0b708bf578..033bd20992 100644
>> --- a/tools/firmware/hvmloader/pci.c
>> +++ b/tools/firmware/hvmloader/pci.c
>> @@ -35,6 +35,7 @@ unsigned long pci_mem_end = PCI_MEM_END;
>>  uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>>  
>>  enum virtual_vga virtual_vga = VGA_none;
>> +uint32_t vga_devfn = 256;  
>
>uint8_t should be enough to store a devfn. Also this should be static
>maybe?

Yep, forgot 'static'. Changing uint32_t to uint8_t here will require
to change the
'if ( vga_devfn != 256 )' condition as well -- it's a bit out of the
patch scope, probably a separate tiny patch would be better.

>>  unsigned long igd_opregion_pgbase = 0;
>>  
>>  /* Check if the specified range conflicts with any reserved device
>> memory. */ @@ -76,14 +77,93 @@ static int find_next_rmrr(uint32_t
>> base) return next_rmrr;
>>  }
>>  
>> +#define SCI_EN_IOPORT  (ACPI_PM1A_EVT_BLK_ADDRESS_V1 + 0x30)
>> +#define GBL_SMI_EN  (1 << 0)
>> +#define APMC_EN (1 << 5)  
>
>Alignment.

Will correct.

>> +
>> +static void class_specific_pci_device_setup(uint16_t vendor_id,
>> +uint16_t device_id,
>> +uint8_t bus, uint8_t
>> devfn) +{
>> +uint16_t class;
>> +
>> +class = pci_readw(devfn, PCI_CLASS_DEVICE);
>> +
>> +switch ( class )  
>
>switch ( pci_readw(devfn, PCI_CLASS_DEVICE) ) ?
>
>I don't see class being used elsewhere.

>Also why is vendor_id/device_id provided by the caller but not class?
>It seems kind of pointless.

'class' is not used by pci_setup(), thus moved to
class_specific_pci_device_setup().

pci_readw(devfn, PCI_CLASS_DEVICE) inside the switch condition to drop
the variable -- sure, agree.

Passing vendor_id/device_id pair via function args allows to avoid
reading the vendor_id/device_id from PCI conf twice -- a bit less
garbage in the polluted PCI setup debuglog. It's not a big problem
really, so this can be changed to passing only BDF to
class_specific_pci_device_setup().

>Why not fetch vendor/device from the function itself and move the
>(vendor_id == 0x) && (device_id == 0x) check inside the
>function?

Hmm, this is a part of the PCI bus enumeration, not PCI device setup.

>Also in this case I think it would be better to have a non-functional
>patch that introduces class_specific_pci_device_setup and a second
>patch that adds support for ICH9.
>
>Having code movement and new code in the same patch makes it harder to
>very what you are actually moving vs introducing.

Agree, will split this actions to separate patches for the next version.

>> +{
>> +case 0x0300:  
>
>All this values need to be defines documented somewhere.

Agree... although it was not me who introduced all these hardcoded PCI
class values. :) I'll change these numbers into newly added pci_regs.h
#defines in the non-functional patch.

>> +/* If emulated VGA is found, preserve it as primary VGA. */
>> +if ( (vendor_id == 0x1234) && (device_id == 0x) )
>> +{
>> +vga_devfn = devfn;
>> +virtual_vga = VGA_std;
>> +}
>> +else if ( (vendor_id == 0x1013) && (device_id == 0xb8) )
>> +{
>> +vga_devfn = devfn;
>> +virtual_vga = VGA_cirrus;
>> +}
>> +else if ( virtual_vga == VGA_none )
>> +{
>> +vga_devfn = devfn;
>> +virtual_vga = VGA_pt;
>> +if ( vendor_id == 0x8086 )

Re: [Xen-devel] [PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend

[Boris Ostrovsky]

On 03/13/2018 12:21 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> Hello!
>
> Resending with all the patches squashed on Daniel's request.

Which of the two series are we supposed to review? The 8-patch one or
this? (I hope it's the former)

-boris




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

Re: [Xen-devel] [PATCH v2] xen: fix null sched build with debug=n

[Dario Faggioli]

On Mon, 2018-03-19 at 13:41 -0500, Doug Goldstein wrote:
> The null_dom() static inline is just used when debug=y so it results
> in
> a error with the default CFLAGS and debug=n. This function is used in
> only one place and it a one line helper so remove it until we
> actually
> need it.
> 
> Signed-off-by: Doug Goldstein 
>
Acked-by: Dario Faggioli 

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

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

Re: [Xen-devel] [PATCH] x86/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

s/This is works/This works/

Reviewed-by: Boris Ostrovsky 

Do we still need 4f277295e54?

-boris

> 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 
> ---
>  arch/x86/xen/enlighten_pv.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 3c2c2530737e..c36d23aa6c35 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -1259,10 +1259,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
>*/
>   __userpte_alloc_gfp &= ~__GFP_HIGHMEM;
>  
> - /* Work out if we support NX */
> - get_cpu_cap(_cpu_data);
> - x86_configure_nx();
> -
>   /* Get mfn list */
>   xen_build_dynamic_phys_to_machine();
>  
> @@ -1272,6 +1268,10 @@ asmlinkage __visible void __init xen_start_kernel(void)
>*/
>   xen_setup_gdt(0);
>  
> + /* Work out if we support NX */
> + get_cpu_cap(_cpu_data);
> + x86_configure_nx();
> +
>   xen_init_irq_ops();
>  
>   /* Let's presume PV guests always boot on vCPU with id 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)

[Alexey G]

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.

>> 
>> Note that omitting device_model_machine parameter means i440 system
>> by default, so the default behavior doesn't change for existing
>> domain config files.
>> 
>> Setting device_model_machine to "q35" sends '-machine q35,accel=xen'
>> argument to QEMU. Unlike i440, there no separate machine type
>> to enable/disable Xen platform device, it is controlled via a
>> machine  
>
>But I assume the xen_platform_pci option still works as expected?

Yes, xen_platform_pci should work as before.

>> property only. See 'libxl: Xen Platform device support for Q35'
>> patch for a detailed description.
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---
>>  tools/libxl/libxl_dm.c  | 16 ++--
>>  tools/libxl/libxl_types.idl |  7 +++
>>  tools/xl/xl_parse.c | 14 ++
>>  3 files changed, 31 insertions(+), 6 deletions(-)
>> 
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index a3cddce8b7..7b531050c7 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -1443,13 +1443,17 @@ static int
>> libxl__build_device_model_args_new(libxl__gc *gc,
>> flexarray_append(dm_args, b_info->extra_pv[i]); break;
>>  case LIBXL_DOMAIN_TYPE_HVM:
>> -if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
>> -/* Switching here to the machine "pc" which does not add
>> - * the xen-platform device instead of the default
>> "xenfv" machine.
>> - */
>> -machinearg = libxl__strdup(gc, "pc,accel=xen");
>> +if (b_info->device_model_machine ==
>> LIBXL_DEVICE_MODEL_MACHINE_Q35) {
>> +machinearg = libxl__sprintf(gc, "q35,accel=xen");
>>  } else {
>> -machinearg = libxl__strdup(gc, "xenfv");
>> +if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci))
>> {
>> +/* Switching here to the machine "pc" which does
>> not add
>> + * the xen-platform device instead of the default
>> "xenfv" machine.
>> + */
>> +machinearg = libxl__strdup(gc, "pc,accel=xen");
>> +} else {
>> +machinearg = libxl__strdup(gc, "xenfv");
>> +}
>>  }
>>  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.

>> +(1, "I440"),
>> +(2, "Q35"),
>> +])
>> +
>>  libxl_console_type = Enumeration("console_type", [
>>  (0, "UNKNOWN"),
>>  (1, "SERIAL"),
>> @@ -491,6 +497,7 @@ libxl_domain_build_info =
>> Struct("domain_build_info",[ ("device_model_ssid_label", string),
>>  # device_model_user is not ready for use yet
>>  ("device_model_user", string),
>> +("device_model_machine", libxl_device_model_machine),
>>  
>>  # extra parameters pass directly to qemu, NULL terminated
>>  ("extra",libxl_string_list),
>> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
>> index f6842540ca..a7506a426b 100644
>> --- a/tools/xl/xl_parse.c
>> +++ b/tools/xl/xl_parse.c
>> @@ -2110,6 +2110,20 @@ skip_usbdev:
>>  xlu_cfg_replace_string(config, "device_model_user",
>> _info->device_model_user, 0);
>>  
>> +if (!xlu_cfg_get_string (config, "device_model_machine", ,
>> 0)) {
>> +if (!strcmp(buf, "i440")) {
>> +b_info->device_model_machine =
>> LIBXL_DEVICE_MODEL_MACHINE_I440;
>> +} else if (!strcmp(buf, "q35")) {
>> +b_info->device_model_machine =
>> LIBXL_DEVICE_MODEL_MACHINE_Q35;
>> +} else {
>> + 

Re: [Xen-devel] [PATCH 28/57] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

[Julien Grall]

On 03/19/2018 05:32 PM, Andre Przywara wrote:

Hi,


Hi,


On 06/03/18 18:13, Julien Grall wrote:

Hi Andre,

On 05/03/18 16:03, 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 RFC ... v1:
- add kernel-doc comments to exported functions
- adapt to previous changes (new_vgic.h, arch_vcpu member name)
- use ASSERT_UNREACHABLE

   xen/arch/arm/vgic/vgic.c | 124
+++
   xen/arch/arm/vgic/vgic.h |  41 
   2 files changed, 165 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..ace30f78d0
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic.c
@@ -0,0 +1,124 @@
+/*
+ * 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.
+ */
+static struct vgic_irq *vgic_get_lpi(struct domain *d, u32 intid)
+{
+    struct vgic_dist *dist = >arch.vgic;
+    struct vgic_irq *irq = NULL;
+
+    spin_lock(>lpi_list_lock);
+
+    list_for_each_entry( irq, >lpi_list_head, lpi_list )


I am still not a big fan of the list solution. Strictly speaking nobody
is populating that list and likely going to be too slow in Xen case (I
am thinking for the hardware domain). So I think I would prefer to see
the LPI related code disappear for this cut. This could easily be added
back as they are standalone.


I was thinking about that, but dismissed the idea:
Considering LPIs as first class citizens is a crucial property of the
new VGIC and actually the main driver for its creation: the refcounting
is solely in for that purpose, and the per-IRQ data structure and its
lock are mainly driven by it. So removing the LPI support completely
will make the refcounting look very awkward (since useless and unused).
Consequently one would need to remove that as well. In the worst case we
run into issues with unused functions, like vgic_get_irq_kref().

I already removed a lot of code from the KVM VGIC, which I feel we will
need back one day. So I really like to keep this one in, and be it just
for documentation how the refcounting is supposed to be used.
I will add a comment to this respect.
And I believe replacing the list_for_each_entry() with something more
sophisticated is the least of our problems later on.


Using a list for LPIs means the search is O(n). That search will be done 
each time you want to get the LPI information.


While in guest you may have limited LPIs, this will not be the case for 
the hardware domain. Indeed that domain has access to all devices and 
likely going to use a lot of MSIs.


So I still can't understand why you dismiss that problem.

To be honest, I don't mind to keep the refcounting around. What I don't 
want to see in Xen is using a data structure that we know will not fit 
Xen (even for well-behave guests).


You may remove a lot of code, and re-add the code later but that's the 
price to convert KVM to Xen code. It makes much more sense to get all 
the LPIs infrastructure together.


And to be clear, what I am asking for is implementing vgic_get_lpi with 
return NULL + a comment.


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 10/12] libacpi: build ACPI MCFG table if requested

[Alexey G]

On Mon, 19 Mar 2018 17:33:34 +
Roger Pau Monné  wrote:

>On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko wrote:
>> This adds construct_mcfg() function to libacpi which allows to build
>> MCFG table for a given mmconfig_addr/mmconfig_len pair if the
>> ACPI_HAS_MCFG flag was specified in acpi_config struct.
>> 
>> The maximum bus number is calculated from mmconfig_len using
>> MCFG_SIZE_TO_NUM_BUSES macro (1MByte of MMIO space per bus).
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---
>>  tools/libacpi/acpi2_0.h | 21 +
>>  tools/libacpi/build.c   | 42
>> ++ tools/libacpi/libacpi.h
>> |  4  3 files changed, 67 insertions(+)
>> 
>> diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
>> index 2619ba32db..209ad1acd3 100644
>> --- a/tools/libacpi/acpi2_0.h
>> +++ b/tools/libacpi/acpi2_0.h
>> @@ -422,6 +422,25 @@ struct acpi_20_slit {
>>  };
>>  
>>  /*
>> + * PCI Express Memory Mapped Configuration Description Table
>> + */
>> +struct mcfg_range_entry {
>> +uint64_t base_address;
>> +uint16_t pci_segment;
>> +uint8_t  start_pci_bus_num;
>> +uint8_t  end_pci_bus_num;
>> +uint32_t reserved;
>> +};
>> +
>> +struct acpi_mcfg {
>> +struct acpi_header header;
>> +uint8_t reserved[8];
>> +struct mcfg_range_entry entries[1];
>> +};  
>
>I would define this as:
>
>struct acpi_10_mcfg {
>struct acpi_header header;
>uint8_t reserved[8];
>struct acpi_10_mcfg_entry {
>uint64_t base_address;
>uint16_t pci_segment;
>uint8_t  start_pci_bus;
>uint8_t  end_pci_bus;
>uint32_t reserved;
>} entries[1];
>};

Hmm, a choice of preference, but OK, will move it inside.

>> +
>> +#define MCFG_SIZE_TO_NUM_BUSES(size)  ((size) >> 20)  
>
>I'm not sure the following macro belongs here. This is not directly
>related to ACPI.

Yeah, pci_regs.h might be better I think.

>> +
>> +/*
>>   * Table Signatures.
>>   */
>>  #define ACPI_2_0_RSDP_SIGNATURE ASCII64('R','S','D','
>> ','P','T','R',' ') @@ -435,6 +454,7 @@ struct acpi_20_slit {
>>  #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
>>  #define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
>>  #define ACPI_2_0_SLIT_SIGNATURE ASCII32('S','L','I','T')
>> +#define ACPI_MCFG_SIGNATURE ASCII32('M','C','F','G')
>>  
>>  /*
>>   * Table revision numbers.
>> @@ -449,6 +469,7 @@ struct acpi_20_slit {
>>  #define ACPI_1_0_FADT_REVISION 0x01
>>  #define ACPI_2_0_SRAT_REVISION 0x01
>>  #define ACPI_2_0_SLIT_REVISION 0x01
>> +#define ACPI_1_0_MCFG_REVISION 0x01
>>  
>>  #pragma pack ()
>>  
>> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
>> index f9881c9604..5daf1fc5b8 100644
>> --- a/tools/libacpi/build.c
>> +++ b/tools/libacpi/build.c
>> @@ -303,6 +303,37 @@ static struct acpi_20_slit
>> *construct_slit(struct acpi_ctxt *ctxt, return slit;
>>  }
>>  
>> +static struct acpi_mcfg *construct_mcfg(struct acpi_ctxt *ctxt,
>> +const struct acpi_config
>> *config) +{
>> +struct acpi_mcfg *mcfg;
>> +
>> +/* Warning: this code expects that we have only one PCI segment
>> */
>> +mcfg = ctxt->mem_ops.alloc(ctxt, sizeof(*mcfg), 16);
>> +if (!mcfg)  
>
>Coding style.

OK

>> +return NULL;
>> +
>> +memset(mcfg, 0, sizeof(*mcfg));
>> +mcfg->header.signature= ACPI_MCFG_SIGNATURE;
>> +mcfg->header.revision = ACPI_1_0_MCFG_REVISION;
>> +fixed_strcpy(mcfg->header.oem_id, ACPI_OEM_ID);
>> +fixed_strcpy(mcfg->header.oem_table_id, ACPI_OEM_TABLE_ID);
>> +mcfg->header.oem_revision = ACPI_OEM_REVISION;
>> +mcfg->header.creator_id   = ACPI_CREATOR_ID;
>> +mcfg->header.creator_revision = ACPI_CREATOR_REVISION;
>> +mcfg->header.length = sizeof(*mcfg);  
>
>As said before, if you want to align things, please do it for the
>whole block.

Agree, will reorder lines.

>> +
>> +mcfg->entries[0].base_address = config->mmconfig_addr;
>> +mcfg->entries[0].pci_segment = 0;
>> +mcfg->entries[0].start_pci_bus_num = 0;
>> +mcfg->entries[0].end_pci_bus_num =
>> +MCFG_SIZE_TO_NUM_BUSES(config->mmconfig_len) - 1;  
>
>Why not pass the start_bus and end_bus values in acpi_config at least?

start_pci_bus_num will be always 0.

It will be kinda ugly to pass config->mmconfig_addr along with
config->end_pci_bus_num, baseaddr+size combo looks nicer I think.

>> +
>> +set_checksum(mcfg, offsetof(struct acpi_header, checksum),
>> sizeof(*mcfg)); +
>> +return mcfg;;  
>
>Double ;;

Oops, missed this one.

>> +}
>> +
>>  static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
>>  unsigned long *table_ptrs,
>>  int nr_tables,
>> @@ -350,6 +381,7 @@ static int construct_secondary_tables(struct
>> acpi_ctxt *ctxt, struct acpi_20_hpet *hpet;
>>  struct acpi_20_waet *waet;
>>  

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

[Christian Lindig]

> On 19. Mar 2018, at 19:13, Andrew Cooper  wrote:
> 
> + max_grant_frames: int32;
> + max_maptrack_frames: int32;

As part of:

> +type domctl_create_config =
> +{
> +   ssidref: int32;
> +   handle: string;
> +   flags: domain_create_flag list;
> +   max_vcpus: int32;
> +   max_evtchn_port: int32;
> +   max_grant_frames: int32;
> +   max_maptrack_frames: int32;
> +   arch: arch_domainconfig;
> +}

This is a minor point: in OCaml, values of type int32 and int64 are represented 
as pointers to a memory block containing the value. This is unlike an int, 
which is represented simply as part of a memory block that represents the 
record value. Because OCaml uses one bit as a tag, the range of int and int32 
(on a 32-bit system) is different. Most of the time the range is large enough 
and people use int rather than int32 or int64 for that reason. I would expect 
that an int is large enough, especially on a 64-bit system. However, if int32 
makes it easier to align this with the C code, this is fine, especially because 
there are not many values of omctl_create_config to be expected.

— Christian


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

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

[Alexey G]

On Mon, 19 Mar 2018 17:49:09 +
Roger Pau Monné  wrote:

>On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote:
>> This patch extends hvmloader_acpi_build_tables() with code which
>> detects if MMCONFIG is available -- i.e. initialized and enabled
>> (+we're running on Q35), obtains its base address and size and asks
>> libacpi to build MCFG table for it via setting the flag
>> ACPI_HAS_MCFG in a manner similar to other optional ACPI tables
>> building.
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---
>>  tools/firmware/hvmloader/util.c | 70
>> + 1 file changed, 70
>> insertions(+)
>> 
>> diff --git a/tools/firmware/hvmloader/util.c
>> b/tools/firmware/hvmloader/util.c index d8db9e3c8e..c6fc81d52a 100644
>> --- a/tools/firmware/hvmloader/util.c
>> +++ b/tools/firmware/hvmloader/util.c
>> @@ -782,6 +782,69 @@ int get_pc_machine_type(void)
>>  return machine_type;
>>  }
>>  
>> +#define PCIEXBAR_ADDR_MASK_64MB (~((1ULL << 26) - 1))
>> +#define PCIEXBAR_ADDR_MASK_128MB(~((1ULL << 27) - 1))
>> +#define PCIEXBAR_ADDR_MASK_256MB(~((1ULL << 28) - 1))
>> +#define PCIEXBAR_LENGTH_BITS(reg)   (((reg) >> 1) & 3)
>> +#define PCIEXBAREN  1  
>
>PCIEXBAR_ENABLE maybe?

PCIEXBAREN is just an official name of this bit from the
Intel datasheet. :) OK, will rename it to PCIEXBAR_ENABLE.

>> +
>> +static uint64_t mmconfig_get_base(void)
>> +{
>> +uint64_t base;
>> +uint32_t reg = pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR);
>> +
>> +base = reg | (uint64_t) pci_readl(PCI_MCH_DEVFN,
>> PCI_MCH_PCIEXBAR+4) << 32;  
>
>Please add parentheses in the above expression.

Agree, parentheses will make the op priority clearer.

>> +
>> +switch (PCIEXBAR_LENGTH_BITS(reg))
>> +{
>> +case 0:
>> +base &= PCIEXBAR_ADDR_MASK_256MB;
>> +break;
>> +case 1:
>> +base &= PCIEXBAR_ADDR_MASK_128MB;
>> +break;
>> +case 2:
>> +base &= PCIEXBAR_ADDR_MASK_64MB;
>> +break;  
>
>Missing newlines, plus this looks like it wants to use the defines
>introduced in patch 7 (PCIEXBAR_{64,128,256}_BUSES). Also any reason
>this patch and patch 7 cannot be put sequentially?

I think all these #defines should find a way to pci_regs.h, it seems
like an appropriate place for them.

Regarding the order of hvmloader patches -- will verify this for
the next version.

>They are very related, and in fact I'm not sure why we need to write
>this info to the device in patch 7 and then fetch it from the device
>here. Isn't there an easier way to pass this information? At the end
>this is all in hvmloader.

Well, the hvmloader_acpi_build_tables() function mostly does device
probing (using I/O instruction) and xenstore reads to collect system
information in order to discover which ACPI_HAS_* flags it should pass
to acpi_build_tables(), but using global variables to pass this kind of
information for MMCONFIG will be OK too I think.

>> +case 3:  
>
>default:

There is '& 3' for the switch argument, but ok I guess, it's clearer
with 'default'.

>> +BUG();  /* a reserved value encountered */
>> +}
>> +
>> +return base;
>> +}
>> +
>> +static uint32_t mmconfig_get_size(void)  
>
>unsigned int or size_t?

Using types which are common to the existing code.

size_t have almost zero use in hvmloader.

unsigned int instead of uint32_t... well, the uint32_t still
used more often as a type name anyway, but I have no objections to
either choice.

>> +{
>> +uint32_t reg = pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR);
>> +
>> +switch (PCIEXBAR_LENGTH_BITS(reg))
>> +{
>> +case 0: return MB(256);
>> +case 1: return MB(128);
>> +case 2: return MB(64);
>> +case 3:
>> +BUG();  /* a reserved value encountered */  
>
>Same comments as above about the labels and the case 3 label.
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static uint32_t mmconfig_is_enabled(void)
>> +{
>> +return pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR) & PCIEXBAREN;
>> +}
>> +
>> +static int is_mmconfig_used(void)  
>
>bool

OK

>> +{
>> +if (get_pc_machine_type() == MACHINE_TYPE_Q35)
>> +{
>> +if (mmconfig_is_enabled() && mmconfig_get_base())  
>
>Coding style.
>
>Also you can join the conditions:
>
>if ( get_pc_machine_type() == MACHINE_TYPE_Q35 &&
>mmconfig_is_enabled() &&
> mmconfig_get_base() )
> return true;
>
>Looking at this, is it actually a valid state to have
>mmconfig_is_enabled() == true and mmconfig_get_base() == 0?

Yes, in theory we can have either PCIEXBAREN=0 and a valid PCIEXBAR
base, or vice versa.
Of course normally we should not encounter a situation where base=0 and
PCIEXBAREN=1, just covering here possible cases which the register
format allows.

Regarding check merging -- ok, sure. Short-circuit evaluation should
guaranty that these registers are not touched on a different
machine.

>> +return 1;
>> +

[Xen-devel] [xen-4.7-testing test] 120908: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 broken
 test-amd64-amd64-xl-qemuu-win7-amd64 4 host-install(4) broken REGR. vs. 119780
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119780
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 119780

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 119780

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119780
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  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 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-i386-libvirt-xsm  13 migrate-support-checkfail   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-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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-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 

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

[Alexey G]

On Mon, 19 Mar 2018 15:58:02 +
Roger Pau Monné  wrote:

>On Tue, Mar 13, 2018 at 04:33:52AM +1000, Alexey Gerasimenko wrote:
>> Much like normal PCI BARs or other chipset-specific memory-mapped
>> resources, MMCONFIG area needs space in MMIO hole, so we must
>> allocate it manually.
>> 
>> The actual MMCONFIG size depends on a number of PCI buses available
>> which should be covered by ECAM. Possible options are 64MB, 128MB
>> and 256MB. As we are limited to the bus 0 currently, thus using
>> lowest possible setting (64MB), #defined via PCI_MAX_MCFG_BUSES in
>> hvmloader/config.h. When multiple PCI buses support for Xen will be
>> implemented, PCI_MAX_MCFG_BUSES may be changed to calculation of the
>> number of buses according to results of the PCI devices enumeration.
>> 
>> The way to allocate MMCONFIG range in MMIO hole is similar to how
>> other PCI BARs are allocated. The patch extends 'bars' structure to
>> make it universal for any arbitrary BAR type -- either IO, MMIO, ROM
>> or a chipset-specific resource.  
>
>I'm not sure this is fully correct. The IOREQ interface can
>differentiate PCI devices and forward config space accesses to
>different emulators (see IOREQ_TYPE_PCI_CONFIG). With this change you
>will forward all MCFG accesses to QEMU, which will likely be wrong if
>there are multiple PCI-device emulators for the same domain.
>
>Ie: AFAICT Xen needs to know about the MCFG emulation and detect
>accesses to it in order to forward them to the right emulators.
>
>Adding Paul who knows more about all this.

In which use cases multiple PCI-device emulators are used for a single
HVM domain? Is it a proprietary setup?

I assume it is somehow related to this code in xen-hvm.c:
/* Fake a write to port 0xCF8 so that
 * the config space access will target the
 * correct device model.
 */
val = (1u << 31) | ((req->addr & 0x0f00) <...>
do_outp(0xcf8, 4, val);
if yes, similar thing can be made for IOREQ_TYPE_COPY accesses to
the emulated MMCONFIG if needed.

In HVM+QEMU case we are not limited to merely passed through devices,
most of the observable PCI config space devices belong to one particular
QEMU instance. This dictates the overall emulated MMCONFIG layout
for a domain which should be in sync to what QEMU emulates via CF8h/CFCh
accesses... and between multiple device model instances (if there are
any, still not sure what multiple PCI-device emulators you mentioned
really are).

Basically, we have an emulated MMCONFIG area of 64/128/256MB size in
the MMIO hole of the guest HVM domain. (BTW, this area itself can be
considered a feature of the chipset the device model emulates.)
It can be relocated to some other place in MMIO hole, this means that
QEMU will trap accesses to the specific to the emulated chipset
PCIEXBAR register and will issue same MMIO unmap/map calls as for
any normal emulated MMIO range.

On the other hand, it won't be easy to provide emulated MMCONFIG
translation into IOREQ_TYPE_PCI_CONFIG from Xen side. Xen should know
current emulated MMCONFIG area position and size in order to translate
(or not) accesses to it into corresponding BDF/reg pair (+whether that
area is enabled for decoding or not). This will likely require to
introduce new hypercall(s).

The question is if there will be any difference or benefit at all.

It's basically the same emulated MMIO range after all, but in one case
we trap accesses to it in Xen and translate them into
IOREQ_TYPE_PCI_CONFIG requests.
We have to provide some infrastructure to let Xen know where the device 
model/guest expects to use the MMCONFIG area (and its size). The
device model will need to use this infrastructure, informing Xen of
any changes. Also, due to MMCONFIG nature there might be some pitfalls
like a necessity to send multiple IOREQ_TYPE_PCI_CONFIG ioreqs caused by
a single memory read/write operation.

In another case, we still have an emulated MMIO range, but Xen will send
plain IOREQ_TYPE_COPY requests to QEMU which it handles itself.
In such case, all code to work with MMCONFIG accesses is available for
reuse right away (mmcfg -> pci_* translation in QEMU), no new
functionality required neither in Xen or QEMU.

>> One important new field is addr_mask, which tells which bits of the
>> base address can (should) be written. Different address types (ROM,
>> MMIO BAR, PCIEXBAR) will have different addr_mask values.
>> 
>> For every assignable BAR range we store its size, PCI device BDF
>> (devfn actually) to which it belongs, BAR type (mem/io/mem64) and
>> corresponding register offset in device PCI conf space. This way we
>> can insert MMCONFIG entry into bars array in the same manner like
>> for any other BARs. In this case, the devfn field will point to MCH
>> PCI device and bar_reg will contain PCIEXBAR register offset. It
>> will be assigned a slot in MMIO hole later in a very same way like
>> for plain 

[Xen-devel] [PATCH 18/20] xen/dom0: Arrange for dom0_cfg to contain the real max_vcpus value

[Andrew Cooper]

Make dom0_max_vcpus() a common interface, and implement it on ARM by splitting
the existing alloc_dom0_vcpu0() function in half.

As domain_create() doesn't yet set up the vcpu array, the max value is also
passed into alloc_dom0_vcpu0().  This is temporary for bisectibility and
removed in the following patch.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/domain_build.c | 12 +---
 xen/arch/arm/setup.c|  3 ++-
 xen/arch/x86/dom0_build.c   |  5 ++---
 xen/arch/x86/setup.c|  3 ++-
 xen/include/asm-x86/setup.h |  2 --
 xen/include/xen/domain.h|  5 -
 6 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a375de0..2e145d9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -66,17 +66,23 @@ struct map_range_data
  */
 #define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry))
 
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+unsigned int __init dom0_max_vcpus(void)
 {
 if ( opt_dom0_max_vcpus == 0 )
 opt_dom0_max_vcpus = num_online_cpus();
 if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
 opt_dom0_max_vcpus = MAX_VIRT_CPUS;
 
-dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+return opt_dom0_max_vcpus;
+}
+
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0,
+ unsigned int max_vcpus)
+{
+dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
 if ( !dom0->vcpu )
 return NULL;
-dom0->max_vcpus = opt_dom0_max_vcpus;
+dom0->max_vcpus = max_vcpus;
 
 return alloc_vcpu(dom0, 0, 0);
 }
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c181389..be24f20 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -856,9 +856,10 @@ void __init start_xen(unsigned long boot_phys_offset,
 /* The vGIC for DOM0 is exactly emulating the hardware GIC */
 dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
 dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
+dom0_cfg.max_vcpus = dom0_max_vcpus();
 
 dom0 = domain_create(0, _cfg);
-if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
+if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0, dom0_cfg.max_vcpus) == NULL) )
 panic("Error creating domain 0");
 
 dom0->is_privileged = 1;
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 555660b..e82bc48 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -200,10 +200,9 @@ unsigned int __init dom0_max_vcpus(void)
 return max_vcpus;
 }
 
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0,
+ unsigned int max_vcpus)
 {
-unsigned int max_vcpus = dom0_max_vcpus();
-
 dom0->node_affinity = dom0_nodes;
 dom0->auto_node_affinity = !dom0_nr_pxms;
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a79a8b6..b0e85b0 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1645,10 +1645,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 dom0_cfg.arch.emulation_flags |=
 XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC;
 }
+dom0_cfg.max_vcpus = dom0_max_vcpus();
 
 /* Create initial domain 0. */
 dom0 = domain_create(get_initial_domain_id(), _cfg);
-if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
+if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0, dom0_cfg.max_vcpus) == NULL) )
 panic("Error creating domain 0");
 
 if ( !pv_shim )
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index 19232af..751c245 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -51,8 +51,6 @@ unsigned long initial_images_nrpages(nodeid_t node);
 void discard_initial_images(void);
 void *bootstrap_map(const module_t *mod);
 
-unsigned int dom0_max_vcpus(void);
-
 int xen_in_range(unsigned long mfn);
 
 void microcode_grab_module(
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 1929fa0..dc022b4 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -15,7 +15,10 @@ typedef union {
 
 struct vcpu *alloc_vcpu(
 struct domain *d, unsigned int vcpu_id, unsigned int cpu_id);
-struct vcpu *alloc_dom0_vcpu0(struct domain *dom0);
+
+unsigned int dom0_max_vcpus(void);
+struct vcpu *alloc_dom0_vcpu0(struct domain *dom0, unsigned int max_vcpus);
+
 int vcpu_reset(struct vcpu *);
 int vcpu_up(struct vcpu *v);
 
-- 
2.1.4


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

[Xen-devel] [PATCH 15/20] xen/gnttab: Export opt_max_{grant, maptrack}_frames

[Andrew Cooper]

This is to facilitate the values being passed in via domain_create(), at which
point the dom0 construction code needs to know them.

While cleaning up, drop the DEFAULT_* defines, which are only used immediately
adjacent in a context which makes it obvious that they are the defaults, and
drop the (unused) logic to allow a per-arch override of
DEFAULT_MAX_NR_GRANT_FRAMES.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/grant_table.c  | 26 +-
 xen/include/xen/grant_table.h |  3 +++
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 93443be..5596659 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -82,20 +82,11 @@ struct grant_table {
 struct grant_table_arch arch;
 };
 
-#ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
-/* Default maximum size of a grant table. [POLICY] */
-#define DEFAULT_MAX_NR_GRANT_FRAMES   64
-#endif
-
-static unsigned int __read_mostly max_grant_frames =
-   DEFAULT_MAX_NR_GRANT_FRAMES;
-integer_runtime_param("gnttab_max_frames", max_grant_frames);
-
-#define DEFAULT_MAX_MAPTRACK_FRAMES 1024
+unsigned int __read_mostly opt_max_grant_frames = 64;
+integer_runtime_param("gnttab_max_frames", opt_max_grant_frames);
 
-static unsigned int __read_mostly max_maptrack_frames =
-   DEFAULT_MAX_MAPTRACK_FRAMES;
-integer_runtime_param("gnttab_max_maptrack_frames", max_maptrack_frames);
+unsigned int __read_mostly opt_max_maptrack_frames = 1024;
+integer_runtime_param("gnttab_max_maptrack_frames", opt_max_maptrack_frames);
 
 static unsigned int __read_mostly opt_gnttab_max_version = 2;
 static bool __read_mostly opt_transitive_grants = true;
@@ -3601,7 +3592,8 @@ grant_table_create(
 
 if ( d->domain_id == 0 )
 {
-ret = grant_table_init(d, t, gnttab_dom0_frames(), 
max_maptrack_frames);
+ret = grant_table_init(d, t, gnttab_dom0_frames(),
+   opt_max_maptrack_frames);
 }
 
 return ret;
@@ -3803,8 +3795,8 @@ int grant_table_set_limits(struct domain *d, unsigned int 
grant_frames,
 struct grant_table *gt = d->grant_table;
 
 if ( grant_frames < INITIAL_NR_GRANT_FRAMES ||
- grant_frames > max_grant_frames ||
- maptrack_frames > max_maptrack_frames )
+ grant_frames > opt_max_grant_frames ||
+ maptrack_frames > opt_max_maptrack_frames )
 return -EINVAL;
 if ( !gt )
 return -ENOENT;
@@ -3984,7 +3976,7 @@ __initcall(gnttab_usage_init);
 
 unsigned int __init gnttab_dom0_frames(void)
 {
-return min(max_grant_frames, gnttab_dom0_max());
+return min(opt_max_grant_frames, gnttab_dom0_max());
 }
 
 /*
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index b3a95fd..0286ba3 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -31,6 +31,9 @@
 
 struct grant_table;
 
+extern unsigned int opt_max_grant_frames;
+extern unsigned int opt_max_maptrack_frames;
+
 /* Create/destroy per-domain grant table context. */
 int grant_table_create(
 struct domain *d);
-- 
2.1.4


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

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

[Andrew Cooper]

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 
---
CC: Jan Beulich 
CC: Ian Jackson 
CC: Wei Liu 
CC: Christian Lindig 
CC: David Scott 
CC: Jon Ludlam 
CC: Rob Hoes 
CC: Marek Marczykowski-Górecki 
CC: Daniel De Graaf 

Hypervisor side cleanup is present in a later patch
---
 tools/flask/policy/modules/dom0.te   |  2 +-
 tools/flask/policy/modules/xen.if|  2 +-
 tools/helpers/init-xenstore-domain.c |  1 +
 tools/libxc/include/xenctrl.h| 12 
 tools/libxc/xc_domain.c  | 11 ---
 tools/libxl/libxl_create.c   |  2 ++
 tools/libxl/libxl_dom.c  |  7 ---
 tools/ocaml/libs/xc/xenctrl.ml   |  1 +
 tools/ocaml/libs/xc/xenctrl.mli  |  1 +
 tools/ocaml/libs/xc/xenctrl_stubs.c  |  5 -
 tools/python/xen/lowlevel/xc/xc.c|  1 +
 xen/common/domctl.c  |  9 +++--
 xen/include/public/domctl.h  | 19 ---
 xen/xsm/flask/hooks.c|  3 ---
 xen/xsm/flask/policy/access_vectors  |  2 --
 15 files changed, 23 insertions(+), 55 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index bf794d9..4eb3843 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -38,7 +38,7 @@ allow dom0_t dom0_t:domain {
getpodtarget setpodtarget set_misc_info set_virq_handler
 };
 allow dom0_t dom0_t:domain2 {
-   set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
+   set_cpuid gettsc settsc setscheduler set_vnumainfo
get_vnumainfo psr_cmt_op psr_alloc set_gnttab_limits
 };
 allow dom0_t dom0_t:resource { add remove };
diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 459880b..7dc25be 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -51,7 +51,7 @@ define(`create_domain_common', `
getvcpuinfo getaddrsize getaffinity setaffinity
settime setdomainhandle getvcpucontext set_misc_info };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
-   set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
+   set_vnumainfo get_vnumainfo cacheflush
psr_cmt_op psr_alloc soft_reset set_gnttab_limits };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 785e570..89c329c 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -66,6 +66,7 @@ static int build(xc_interface *xch)
 struct xen_domctl_createdomain config = {
 .ssidref = SECINITSID_DOMU,
 .flags = XEN_DOMCTL_CDF_xs_domain,
+.max_evtchn_port = -1, /* No limit. */
 };
 
 xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 6ecc850..88a175f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1072,18 +1072,6 @@ int xc_domain_set_access_required(xc_interface *xch,
 int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /**
- * Set the maximum event channel port a domain may bind.
- *
- * This does not affect ports that are already bound.
- *
- * @param xch a handle to an open hypervisor interface
- * @param domid the domain id
- * @param max_port maximum port number
- */
-int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t domid,
- uint32_t max_port);
-
-/**
  * Set the maximum number of grant frames and maptrack frames a domain
  * can have. Must be used at domain setup time and only then.
  *
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 0124cea..2bc695c 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2256,17 +2256,6 @@ int xc_domain_set_virq_handler(xc_interface *xch, 
uint32_t domid, int virq)
 return do_domctl(xch, );
 }
 
-int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t domid,
- uint32_t max_port)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_set_max_evtchn;
-domctl.domain = domid;
-domctl.u.set_max_evtchn.max_port = max_port;
-return do_domctl(xch, );
-}
-
 int 

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

[Andrew Cooper]

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 
---
CC: Jan Beulich 
CC: Ian Jackson 
CC: Wei Liu 
CC: Christian Lindig 
CC: David Scott 
CC: Jon Ludlam 
CC: Rob Hoes 
CC: Marek Marczykowski-Górecki 
CC: Daniel De Graaf 

Hypervisor side cleanup is present in later patchs
---
 tools/flask/policy/modules/dom0.te   |   2 +-
 tools/flask/policy/modules/xen.if|   2 +-
 tools/helpers/init-xenstore-domain.c |   7 +--
 tools/libxc/include/xenctrl.h|  12 
 tools/libxc/xc_domain.c  |   9 ---
 tools/libxl/libxl_create.c   |   1 +
 tools/libxl/libxl_dom.c  |   5 --
 tools/ocaml/libs/xc/xenctrl.ml   |   4 +-
 tools/ocaml/libs/xc/xenctrl.mli  |   3 +-
 tools/ocaml/libs/xc/xenctrl_stubs.c  |  25 +++-
 tools/python/xen/lowlevel/xc/xc.c|  31 ++
 xen/common/domctl.c  | 110 ---
 xen/include/public/domctl.h  |  10 +---
 xen/xsm/flask/hooks.c|   3 -
 xen/xsm/flask/policy/access_vectors  |   2 -
 15 files changed, 57 insertions(+), 169 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index dfdcdcd..70a35fb 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -32,7 +32,7 @@ allow dom0_t xen_t:mmu memorymap;
 # Allow dom0 to use these domctls on itself. For domctls acting on other
 # domains, see the definitions of create_domain and manage_domain.
 allow dom0_t dom0_t:domain {
-   setvcpucontext max_vcpus setaffinity getaffinity getscheduler
+   setvcpucontext setaffinity getaffinity getscheduler
getdomaininfo getvcpuinfo getvcpucontext setdomainmaxmem setdomainhandle
setdebugging hypercall settime setaddrsize getaddrsize trigger
getpodtarget setpodtarget set_misc_info set_virq_handler
diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 5af984c..350d5fb 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -46,7 +46,7 @@ define(`declare_build_label', `
 ')
 
 define(`create_domain_common', `
-   allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
+   allow $1 $2:domain { create setdomainmaxmem setaddrsize
getdomaininfo hypercall setvcpucontext getscheduler
getvcpuinfo getaddrsize getaffinity setaffinity
settime setdomainhandle getvcpucontext set_misc_info };
diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 4771750..0a09261 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -66,6 +66,7 @@ static int build(xc_interface *xch)
 struct xen_domctl_createdomain config = {
 .ssidref = SECINITSID_DOMU,
 .flags = XEN_DOMCTL_CDF_xs_domain,
+.max_vcpus = 1,
 .max_evtchn_port = -1, /* No limit. */
 
 /*
@@ -100,12 +101,6 @@ static int build(xc_interface *xch)
 fprintf(stderr, "xc_domain_create failed\n");
 goto err;
 }
-rv = xc_domain_max_vcpus(xch, domid, 1);
-if ( rv )
-{
-fprintf(stderr, "xc_domain_max_vcpus failed\n");
-goto err;
-}
 rv = xc_domain_setmaxmem(xch, domid, limit_kb);
 if ( rv )
 {
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0c7c07c..b7ea16c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -521,18 +521,6 @@ int xc_domain_dumpcore_via_callback(xc_interface *xch,
   

[Xen-devel] [PATCH 16/20] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()

[Andrew Cooper]

... rather than setting the limits up after domain_create() has completed.

This removes all the gnttab infrastructure for calculating the number of dom0
grant frames, opting instead to require the dom0 construction code to pass a
sane value in via the configuration.

In practice, this now means that there is never a partially constructed grant
table for a reference-able domain.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/domain_build.c   |  3 ++-
 xen/arch/arm/setup.c  | 12 
 xen/arch/x86/setup.c  |  3 +++
 xen/common/domain.c   |  3 ++-
 xen/common/domctl.c   |  5 -
 xen/common/grant_table.c  | 16 +++-
 xen/include/asm-arm/grant_table.h | 12 
 xen/include/asm-x86/grant_table.h |  5 -
 xen/include/xen/grant_table.h |  6 ++
 9 files changed, 24 insertions(+), 41 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9ef9030..a375de0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2078,7 +2078,8 @@ static void __init find_gnttab_region(struct domain *d,
  * enough space for a large grant table
  */
 kinfo->gnttab_start = __pa(_stext);
-kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
+kinfo->gnttab_size = min_t(unsigned int, opt_max_grant_frames,
+   PFN_DOWN(_etext - _stext)) << PAGE_SHIFT;
 
 #ifdef CONFIG_ARM_32
 /*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f07c826..c181389 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -695,6 +696,17 @@ void __init start_xen(unsigned long boot_phys_offset,
 struct domain *dom0;
 struct xen_domctl_createdomain dom0_cfg = {
 .max_evtchn_port = -1,
+
+/*
+ * The region used by Xen on the memory will never be mapped in DOM0
+ * memory layout. Therefore it can be used for the grant table.
+ *
+ * Only use the text section as it's always present and will contain
+ * enough space for a large grant table
+ */
+.max_grant_frames = min_t(unsigned int, opt_max_grant_frames,
+  PFN_DOWN(_etext - _stext)),
+.max_maptrack_frames = opt_max_maptrack_frames,
 };
 
 dcache_line_bytes = read_dcache_line_bytes();
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index a82e3a1..a79a8b6 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -674,6 +675,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 struct xen_domctl_createdomain dom0_cfg = {
 .flags = XEN_DOMCTL_CDF_s3_integrity,
 .max_evtchn_port = -1,
+.max_grant_frames = opt_max_grant_frames,
+.max_maptrack_frames = opt_max_maptrack_frames,
 };
 
 /* Critical region without IDT or TSS.  Any fault is deadly! */
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 946d0e1..4539c39 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -364,7 +364,8 @@ struct domain *domain_create(domid_t domid,
 goto fail;
 init_status |= INIT_evtchn;
 
-if ( (err = grant_table_create(d)) != 0 )
+if ( (err = grant_table_create(d, config->max_grant_frames,
+   config->max_maptrack_frames)) != 0 )
 goto fail;
 init_status |= INIT_gnttab;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d59fa9e..2f9d993 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -547,11 +547,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 op->domain = d->domain_id;
 copyback = true;
 
-ret = grant_table_set_limits(d, op->u.createdomain.max_grant_frames,
- op->u.createdomain.max_maptrack_frames);
-if ( !ret )
-goto createdomain_fail_late;
-
 ret = -EINVAL;
 if ( vcpus > domain_max_vcpus(d) )
 goto createdomain_fail_late;
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 5596659..cf47c78 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3572,9 +3572,8 @@ do_grant_table_op(
 #include "compat/grant_table.c"
 #endif
 
-int
-grant_table_create(
-struct domain *d)
+int grant_table_create(struct domain *d, unsigned int max_grant_frames,
+   unsigned int max_maptrack_frames)
 {
 struct grant_table *t;
 int ret = 0;
@@ -3590,11 +3589,7 @@ grant_table_create(
 t->domain = d;
 d->grant_table = t;
 
-if ( d->domain_id == 0 )
-{
-ret 

[Xen-devel] [PATCH 17/20] xen/gnttab: Fold grant_table_{create, set_limits}() into grant_table_init()

[Andrew Cooper]

Now that the max_{grant,maptrack}_frames are specified from the very beginning
of grant table construction, the various initialisation functions can be
folded together and simplified as a result.

Leave grant_table_init() as the public interface, which is more consistent
with other subsystems.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/domain.c   |  4 +--
 xen/common/grant_table.c  | 71 +--
 xen/include/xen/grant_table.h |  6 ++--
 3 files changed, 25 insertions(+), 56 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 4539c39..c86cf47 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -364,8 +364,8 @@ struct domain *domain_create(domid_t domid,
 goto fail;
 init_status |= INIT_evtchn;
 
-if ( (err = grant_table_create(d, config->max_grant_frames,
-   config->max_maptrack_frames)) != 0 )
+if ( (err = grant_table_init(d, config->max_grant_frames,
+ config->max_maptrack_frames)) != 0 )
 goto fail;
 init_status |= INIT_gnttab;
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index cf47c78..cb6e875 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1808,22 +1808,28 @@ gnttab_grow_table(struct domain *d, unsigned int 
req_nr_frames)
 return -ENOMEM;
 }
 
-static int
-grant_table_init(struct domain *d, struct grant_table *gt,
- unsigned int grant_frames, unsigned int maptrack_frames)
+int grant_table_init(struct domain *d, unsigned int max_grant_frames,
+ unsigned int max_maptrack_frames)
 {
+struct grant_table *gt;
 int ret = -ENOMEM;
 
-grant_write_lock(gt);
+if ( max_grant_frames < INITIAL_NR_GRANT_FRAMES ||
+ max_grant_frames > opt_max_grant_frames ||
+ max_maptrack_frames > opt_max_maptrack_frames )
+return -EINVAL;
 
-if ( gt->active )
-{
-ret = -EBUSY;
-goto out_no_cleanup;
-}
+if ( (gt = xzalloc(struct grant_table)) == NULL )
+return -ENOMEM;
+
+/* Simple stuff. */
+percpu_rwlock_resource_init(>lock, grant_rwlock);
+spin_lock_init(>maptrack_lock);
+
+grant_write_lock(gt);
 
-gt->max_grant_frames = grant_frames;
-gt->max_maptrack_frames = maptrack_frames;
+gt->max_grant_frames = max_grant_frames;
+gt->max_maptrack_frames = max_maptrack_frames;
 
 /* Active grant table. */
 gt->active = xzalloc_array(struct active_grant_entry *,
@@ -1854,6 +1860,10 @@ grant_table_init(struct domain *d, struct grant_table 
*gt,
 if ( ret )
 goto out;
 
+/* Okay, install the structure. */
+gt->domain = d;
+d->grant_table = gt;
+
 /* gnttab_grow_table() allocates a min number of frames, so 0 is okay. */
 ret = gnttab_grow_table(d, 0);
 
@@ -1871,7 +1881,6 @@ grant_table_init(struct domain *d, struct grant_table *gt,
 gt->active = NULL;
 }
 
- out_no_cleanup:
 grant_write_unlock(gt);
 
 return ret;
@@ -3572,28 +3581,6 @@ do_grant_table_op(
 #include "compat/grant_table.c"
 #endif
 
-int grant_table_create(struct domain *d, unsigned int max_grant_frames,
-   unsigned int max_maptrack_frames)
-{
-struct grant_table *t;
-int ret = 0;
-
-if ( (t = xzalloc(struct grant_table)) == NULL )
-return -ENOMEM;
-
-/* Simple stuff. */
-percpu_rwlock_resource_init(>lock, grant_rwlock);
-spin_lock_init(>maptrack_lock);
-
-/* Okay, install the structure. */
-t->domain = d;
-d->grant_table = t;
-
-ret = grant_table_set_limits(d, max_maptrack_frames, max_maptrack_frames);
-
-return ret;
-}
-
 void
 gnttab_release_mappings(
 struct domain *d)
@@ -3784,22 +3771,6 @@ void grant_table_init_vcpu(struct vcpu *v)
 v->maptrack_tail = MAPTRACK_TAIL;
 }
 
-int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
-   unsigned int maptrack_frames)
-{
-struct grant_table *gt = d->grant_table;
-
-if ( grant_frames < INITIAL_NR_GRANT_FRAMES ||
- grant_frames > opt_max_grant_frames ||
- maptrack_frames > opt_max_maptrack_frames )
-return -EINVAL;
-if ( !gt )
-return -ENOENT;
-
-/* Set limits. */
-return grant_table_init(d, gt, grant_frames, maptrack_frames);
-}
-
 #ifdef CONFIG_HAS_MEM_SHARING
 int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
 gfn_t *gfn, uint16_t *status)
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index ebd5024..424afe0 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -35,13 +35,11 @@ extern unsigned int opt_max_grant_frames;
 extern unsigned int 

[Xen-devel] [PATCH 14/20] xen/gnttab: Remove replace_grant_supported()

[Andrew Cooper]

It is identical on all architecture, and this is a better overall than fixing
it up to have a proper boolean return value.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/grant_table.c  | 3 ---
 xen/include/asm-arm/grant_table.h | 4 
 xen/include/asm-x86/grant_table.h | 5 -
 3 files changed, 12 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 1820191..93443be 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3459,9 +3459,6 @@ do_grant_table_op(
 
 if ( unlikely(!guest_handle_okay(unmap, count)) )
 goto out;
-rc = -ENOSYS;
-if ( unlikely(!replace_grant_supported()) )
-goto out;
 rc = gnttab_unmap_and_replace(unmap, count);
 if ( rc > 0 )
 {
diff --git a/xen/include/asm-arm/grant_table.h 
b/xen/include/asm-arm/grant_table.h
index d2027d2..63a2fdd 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -23,10 +23,6 @@ int replace_grant_host_mapping(unsigned long gpaddr, 
unsigned long mfn,
 void gnttab_mark_dirty(struct domain *d, unsigned long l);
 #define gnttab_create_status_page(d, t, i) do {} while (0)
 #define gnttab_release_host_mappings(domain) 1
-static inline int replace_grant_supported(void)
-{
-return 1;
-}
 
 /*
  * The region used by Xen on the memory will never be mapped in DOM0
diff --git a/xen/include/asm-x86/grant_table.h 
b/xen/include/asm-x86/grant_table.h
index 4ac0b9b..514eaf3 100644
--- a/xen/include/asm-x86/grant_table.h
+++ b/xen/include/asm-x86/grant_table.h
@@ -101,9 +101,4 @@ static inline void gnttab_clear_flag(unsigned int nr, 
uint16_t *st)
 #define gnttab_need_iommu_mapping(d)\
 (!paging_mode_translate(d) && need_iommu(d))
 
-static inline int replace_grant_supported(void)
-{
-return 1;
-}
-
 #endif /* __ASM_GRANT_TABLE_H__ */
-- 
2.1.4


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

[Xen-devel] [PATCH 13/20] xen/evtchn: Pass max_evtchn_port into evtchn_init()

[Andrew Cooper]

... rather than setting it up domain_create() has completed.  This involves
constructing a default value for dom0.

No practical change in functionality.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/setup.c   | 4 +++-
 xen/arch/x86/setup.c   | 1 +
 xen/common/domain.c| 2 +-
 xen/common/domctl.c| 3 ---
 xen/common/event_channel.c | 4 ++--
 xen/include/xen/sched.h| 2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e6f8e23..f07c826 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -693,7 +693,9 @@ void __init start_xen(unsigned long boot_phys_offset,
 const char *cmdline;
 struct bootmodule *xen_bootmodule;
 struct domain *dom0;
-struct xen_domctl_createdomain dom0_cfg = {};
+struct xen_domctl_createdomain dom0_cfg = {
+.max_evtchn_port = -1,
+};
 
 dcache_line_bytes = read_dcache_line_bytes();
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index fa77bae..a82e3a1 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -673,6 +673,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 };
 struct xen_domctl_createdomain dom0_cfg = {
 .flags = XEN_DOMCTL_CDF_s3_integrity,
+.max_evtchn_port = -1,
 };
 
 /* Critical region without IDT or TSS.  Any fault is deadly! */
diff --git a/xen/common/domain.c b/xen/common/domain.c
index b00cc1f..946d0e1 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -360,7 +360,7 @@ struct domain *domain_create(domid_t domid,
 
 radix_tree_init(>pirq_tree);
 
-if ( (err = evtchn_init(d)) != 0 )
+if ( (err = evtchn_init(d, config->max_evtchn_port)) != 0 )
 goto fail;
 init_status |= INIT_evtchn;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 0326e43..d59fa9e 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -547,9 +547,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 op->domain = d->domain_id;
 copyback = true;
 
-d->max_evtchn_port =
-min_t(unsigned int, op->u.createdomain.max_evtchn_port, INT_MAX);
-
 ret = grant_table_set_limits(d, op->u.createdomain.max_grant_frames,
  op->u.createdomain.max_maptrack_frames);
 if ( !ret )
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index c620465..41cbbae 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1284,10 +1284,10 @@ void evtchn_check_pollers(struct domain *d, unsigned 
int port)
 }
 }
 
-int evtchn_init(struct domain *d)
+int evtchn_init(struct domain *d, unsigned int max_port)
 {
 evtchn_2l_init(d);
-d->max_evtchn_port = INT_MAX;
+d->max_evtchn_port = min_t(unsigned int, max_port, INT_MAX);
 
 d->evtchn = alloc_evtchn_bucket(d, 0);
 if ( !d->evtchn )
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index f89896e..7e8a79c 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -133,7 +133,7 @@ struct evtchn
 #endif
 } __attribute__((aligned(64)));
 
-int  evtchn_init(struct domain *d); /* from domain_create */
+int  evtchn_init(struct domain *d, unsigned int max_port); /* from 
domain_create */
 void evtchn_destroy(struct domain *d); /* from domain_kill */
 void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy */
 
-- 
2.1.4


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

[Xen-devel] [PATCH 20/20] xen/domain: Allocate d->vcpu[] in arch_domain_create()

[Andrew Cooper]

On the ARM side, audit config->max_vcpus after the vgic has been initialised,
at which point we have a real upper bound to test against.  This allows for
the removal of the vgic_max_vcpus() juggling to cope with the call from
evtchn_init() before the vgic settings are known.

For each arch's dom0's, drop the temporary max_vcpus parameter, and allocation
of dom0->vcpu.

With arch_domain_create() now in charge of auditing config->max_vcpus, the
per-arch domain_max_vcpus() can be dropped.  Finally, evtchn_init() can be
updated to allocate a poll mask suitable for the domain, rather than suitable
for the worst case setting.

From this point on, d->max_vcpus and d->vcpus[] are valid for any domain which
can be looked up by ID.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/domain.c| 13 +
 xen/arch/arm/domain_build.c  |  8 +---
 xen/arch/arm/setup.c |  2 +-
 xen/arch/arm/vgic.c  | 14 --
 xen/arch/x86/dom0_build.c|  8 +---
 xen/arch/x86/domain.c| 11 +++
 xen/arch/x86/setup.c |  2 +-
 xen/common/domctl.c  | 14 --
 xen/common/event_channel.c   |  4 ++--
 xen/include/asm-arm/domain.h |  6 --
 xen/include/asm-arm/vgic.h   |  2 --
 xen/include/asm-x86/domain.h |  2 --
 xen/include/xen/domain.h |  2 +-
 13 files changed, 31 insertions(+), 57 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 0931ce6..ae40971 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -646,6 +646,19 @@ int arch_domain_create(struct domain *d,
 if ( (rc = domain_vtimer_init(d, >arch)) != 0 )
 goto fail;
 
+rc = -EINVAL;
+/* On ARM, the number of VCPUs is limited by the type of GIC emulated. */
+if ( (config->max_vcpus < 1) ||
+ (config->max_vcpus > min_t(unsigned int, MAX_VIRT_CPUS,
+d->arch.vgic.handler->max_vcpus)) )
+goto fail;
+
+rc = -ENOMEM;
+d->vcpu = xzalloc_array(struct vcpu *, config->max_vcpus);
+if ( !d->vcpu )
+goto fail;
+d->max_vcpus = config->max_vcpus;
+
 update_domain_wallclock_time(d);
 
 /*
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2e145d9..b13c47e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -76,14 +76,8 @@ unsigned int __init dom0_max_vcpus(void)
 return opt_dom0_max_vcpus;
 }
 
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0,
- unsigned int max_vcpus)
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 {
-dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
-if ( !dom0->vcpu )
-return NULL;
-dom0->max_vcpus = max_vcpus;
-
 return alloc_vcpu(dom0, 0, 0);
 }
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index be24f20..0ada4d5 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -859,7 +859,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 dom0_cfg.max_vcpus = dom0_max_vcpus();
 
 dom0 = domain_create(0, _cfg);
-if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0, dom0_cfg.max_vcpus) == NULL) )
+if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
 panic("Error creating domain 0");
 
 dom0->is_privileged = 1;
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index eb09d9c..dc89b81 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -672,20 +672,6 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
 clear_bit(virq, d->arch.vgic.allocated_irqs);
 }
 
-unsigned int vgic_max_vcpus(const struct domain *d)
-{
-/*
- * Since evtchn_init would call domain_max_vcpus for poll_mask
- * allocation when the vgic_ops haven't been initialised yet,
- * we return MAX_VIRT_CPUS if d->arch.vgic.handler is null.
- */
-if ( !d->arch.vgic.handler )
-return MAX_VIRT_CPUS;
-else
-return min_t(unsigned int, MAX_VIRT_CPUS,
- d->arch.vgic.handler->max_vcpus);
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index e82bc48..4c25789 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -200,17 +200,11 @@ unsigned int __init dom0_max_vcpus(void)
 return max_vcpus;
 }
 
-struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0,
- unsigned int max_vcpus)
+struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 {
 dom0->node_affinity = dom0_nodes;
 dom0->auto_node_affinity = !dom0_nr_pxms;
 
-dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
-if ( !dom0->vcpu )
-return NULL;
-dom0->max_vcpus = max_vcpus;
-
 return dom0_setup_vcpu(dom0, 0,
cpumask_last(_cpus) /* so it 

[Xen-devel] [PATCH 07/20] tools/ocaml: Drop int_array_of_uuid_string()

[Andrew Cooper]

This function is entirely internal to xenctrl stubs, and serves only to
convert the uuid string to an integer array (making 16 memory allocations as
it goes), while the C stubs turns the integer array back into a binary array.

Instead, pass the string all the way down into C, and have sscanf() unpack it
directly into a xen_domain_handle_t object.

Signed-off-by: Andrew Cooper 
---
CC: Christian Lindig 
CC: David Scott 
CC: Jon Ludlam 
CC: Rob Hoes 
---
 tools/ocaml/libs/xc/xenctrl.ml  | 21 +++
 tools/ocaml/libs/xc/xenctrl.mli |  5 +++--
 tools/ocaml/libs/xc/xenctrl_stubs.c | 41 +++--
 3 files changed, 32 insertions(+), 35 deletions(-)

diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index 1a01faa..b3b33bb 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -135,26 +135,11 @@ let with_intf f =
interface_close xc;
r
 
-external _domain_create: handle -> int32 -> domain_create_flag list -> int 
array -> arch_domainconfig -> domid
+external domain_create: handle -> int32 -> domain_create_flag list -> string 
-> arch_domainconfig -> domid
= "stub_xc_domain_create"
 
-let int_array_of_uuid_string s =
-   try
-   Scanf.sscanf s
-   
"%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x"
-   (fun a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 
a15 ->
-   [| a0; a1; a2; a3; a4; a5; a6; a7;
-  a8; a9; a10; a11; a12; a13; a14; a15 |])
-   with _ -> invalid_arg ("Xc.int_array_of_uuid_string: " ^ s)
-
-let domain_create handle n flags uuid =
-   _domain_create handle n flags (int_array_of_uuid_string uuid)
-
-external _domain_sethandle: handle -> domid -> int array -> unit
-  = "stub_xc_domain_sethandle"
-
-let domain_sethandle handle n uuid =
-   _domain_sethandle handle n (int_array_of_uuid_string uuid)
+external domain_sethandle: handle -> domid -> string -> unit
+   = "stub_xc_domain_sethandle"
 
 external domain_max_vcpus: handle -> domid -> int -> unit
= "stub_xc_domain_max_vcpus"
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index 7d2e6f0..35303ab 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -98,8 +98,9 @@ type handle
 external interface_open : unit -> handle = "stub_xc_interface_open"
 external interface_close : handle -> unit = "stub_xc_interface_close"
 val with_intf : (handle -> 'a) -> 'a
-val domain_create : handle -> int32 -> domain_create_flag list -> string -> 
arch_domainconfig -> domid
-val domain_sethandle : handle -> domid -> string -> unit
+external domain_create : handle -> int32 -> domain_create_flag list -> string 
-> arch_domainconfig -> domid
+  = "stub_xc_domain_create"
+external domain_sethandle : handle -> domid -> string -> unit = 
"stub_xc_domain_sethandle"
 external domain_max_vcpus : handle -> domid -> int -> unit
   = "stub_xc_domain_max_vcpus"
 external domain_pause : handle -> domid -> unit = "stub_xc_domain_pause"
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index 45d4e20..af92bfa 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define XC_WANT_COMPAT_MAP_FOREIGN_API
 #include 
@@ -97,6 +98,27 @@ CAMLprim value stub_xc_interface_close(value xch)
CAMLreturn(Val_unit);
 }
 
+static void domain_handle_of_uuid_string(xen_domain_handle_t h,
+const char *uuid)
+{
+#define X "%02"SCNx8
+#define UUID_FMT (X X X X "-" X X "-" X X "-" X X "-" X X X X X X)
+
+   if ( sscanf(uuid, UUID_FMT, [0], [1], [2], [3], [4],
+   [5], [6], [7], [8], [9], [10], [11],
+   [12], [13], [14], [15]) != 16 )
+   {
+   char buf[128];
+
+   snprintf(buf, sizeof(buf),
+"Xc.int_array_of_uuid_string: %s", uuid);
+
+   caml_invalid_argument(buf);
+   }
+
+#undef X
+}
+
 CAMLprim value stub_xc_domain_create(value xch, value ssidref,
  value flags, value handle,
  value domconfig)
@@ -104,20 +126,14 @@ CAMLprim value stub_xc_domain_create(value xch, value 
ssidref,
CAMLparam4(xch, ssidref, flags, handle);
 
uint32_t domid = 0;
-   xen_domain_handle_t h = { 0 };
+   xen_domain_handle_t h;
int result;
-   int i;
uint32_t c_ssidref = Int32_val(ssidref);
unsigned int c_flags = 0;
value l;
xc_domain_configuration_t config = {};
 
-if (Wosize_val(handle) != 16)
- 

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

[Andrew Cooper]

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 
---
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxl/libxl_create.c   | 12 ++--
 tools/libxl/libxl_dm.c   |  3 +--
 tools/libxl/libxl_internal.h |  5 +
 3 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c4981352..f92c383 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -538,7 +538,7 @@ int libxl__domain_build(libxl__gc *gc,
 }
 
 int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
-   uint32_t *domid, xc_domain_configuration_t *xc_config)
+   uint32_t *domid)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
 int flags, ret, rc, nb_vm;
@@ -551,6 +551,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 xs_transaction_t t = 0;
 xen_domain_handle_t handle;
 libxl_vminfo *vm_list;
+xc_domain_configuration_t xc_config = {};
 
 /* convenience aliases */
 libxl_domain_create_info *info = _config->c_info;
@@ -571,7 +572,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
 libxl_uuid_copy(ctx, (libxl_uuid *)handle, >uuid);
 
-ret = libxl__arch_domain_prepare_config(gc, d_config, xc_config);
+ret = libxl__arch_domain_prepare_config(gc, d_config, _config);
 if (ret < 0) {
 LOGED(ERROR, *domid, "fail to get domain config");
 rc = ERROR_FAIL;
@@ -581,7 +582,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 /* Valid domid here means we're soft resetting. */
 if (!libxl_domid_valid_guest(*domid)) {
 ret = xc_domain_create(ctx->xch, info->ssidref, handle, flags, domid,
-   xc_config);
+   _config);
 if (ret < 0) {
 LOGED(ERROR, *domid, "domain creation fail");
 rc = ERROR_FAIL;
@@ -589,7 +590,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 }
 }
 
-rc = libxl__arch_domain_save_config(gc, d_config, xc_config);
+rc = libxl__arch_domain_save_config(gc, d_config, _config);
 if (rc < 0)
 goto out;
 
@@ -822,7 +823,6 @@ static void initiate_domain_create(libxl__egc *egc,
 
 /* convenience aliases */
 libxl_domain_config *const d_config = dcs->guest_config;
-libxl__domain_build_state *const state = >build_state;
 const int restore_fd = dcs->restore_fd;
 
 domid = dcs->domid_soft_reset;
@@ -957,7 +957,7 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
-ret = libxl__domain_make(gc, d_config, , >config);
+ret = libxl__domain_make(gc, d_config, );
 if (ret) {
 LOGD(ERROR, domid, "cannot make domain: %d", ret);
 dcs->guest_domid = domid;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a3cddce..49678bd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1953,8 +1953,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
libxl__stub_dm_spawn_state *sdss)
 stubdom_state->pv_ramdisk.path = "";
 
 /* fixme: this function can leak the stubdom if it fails */
-ret = libxl__domain_make(gc, dm_config, >pvqemu.guest_domid,
- _state->config);
+ret = libxl__domain_make(gc, dm_config, >pvqemu.guest_domid);
 if (ret)
 goto out;
 uint32_t dm_domid = sdss->pvqemu.guest_domid;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8dd6331..663fcb2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1145,8 +1145,6 @@ typedef struct {
 xen_vmemrange_t *vmemranges;
 uint32_t num_vmemranges;
 
-xc_domain_configuration_t config;
-
 xen_pfn_t vuart_gfn;
 evtchn_port_t vuart_port;
 } libxl__domain_build_state;
@@ -1657,8 +1655,7 @@ _hidden  void libxl__exec(libxl__gc *gc, int stdinfd, int 
stdoutfd,
   * on exit (even error exit), domid may be valid and refer to a domain */
 _hidden int libxl__domain_make(libxl__gc *gc,
libxl_domain_config *d_config,
-   uint32_t *domid,
-   xc_domain_configuration_t *xc_config);
+   uint32_t *domid);
 
 _hidden int libxl__domain_build(libxl__gc *gc,
 libxl_domain_config *d_config,
-- 
2.1.4


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

[Xen-devel] [PATCH 08/20] tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()

[Andrew Cooper]

The underlying C function is about to make the same change, and the structure
is going to gain extra fields.

Signed-off-by: Andrew Cooper 
---
CC: Christian Lindig 
CC: David Scott 
CC: Jon Ludlam 
CC: Rob Hoes 
---
 tools/ocaml/libs/xc/xenctrl.ml  | 14 ++---
 tools/ocaml/libs/xc/xenctrl.mli | 13 ++---
 tools/ocaml/libs/xc/xenctrl_stubs.c | 39 +++--
 3 files changed, 45 insertions(+), 21 deletions(-)

diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
index b3b33bb..3b7526e 100644
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -56,6 +56,16 @@ type arch_domainconfig =
| ARM of xen_arm_arch_domainconfig
| X86 of xen_x86_arch_domainconfig
 
+type domain_create_flag = CDF_HVM | CDF_HAP
+
+type domctl_create_config =
+{
+   ssidref: int32;
+   handle: string;
+   flags: domain_create_flag list;
+   arch: arch_domainconfig;
+}
+
 type domaininfo =
 {
domid : domid;
@@ -120,8 +130,6 @@ type compile_info =
 
 type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Watchdog | 
Soft_reset
 
-type domain_create_flag = CDF_HVM | CDF_HAP
-
 exception Error of string
 
 type handle
@@ -135,7 +143,7 @@ let with_intf f =
interface_close xc;
r
 
-external domain_create: handle -> int32 -> domain_create_flag list -> string 
-> arch_domainconfig -> domid
+external domain_create: handle -> domctl_create_config -> domid
= "stub_xc_domain_create"
 
 external domain_sethandle: handle -> domid -> string -> unit
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
index 35303ab..d103a33 100644
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -49,6 +49,15 @@ type arch_domainconfig =
   | ARM of xen_arm_arch_domainconfig
   | X86 of xen_x86_arch_domainconfig
 
+type domain_create_flag = CDF_HVM | CDF_HAP
+
+type domctl_create_config = {
+  ssidref: int32;
+  handle: string;
+  flags: domain_create_flag list;
+  arch: arch_domainconfig;
+}
+
 type domaininfo = {
   domid : domid;
   dying : bool;
@@ -91,14 +100,12 @@ type compile_info = {
 }
 type shutdown_reason = Poweroff | Reboot | Suspend | Crash | Watchdog | 
Soft_reset
 
-type domain_create_flag = CDF_HVM | CDF_HAP
-
 exception Error of string
 type handle
 external interface_open : unit -> handle = "stub_xc_interface_open"
 external interface_close : handle -> unit = "stub_xc_interface_close"
 val with_intf : (handle -> 'a) -> 'a
-external domain_create : handle -> int32 -> domain_create_flag list -> string 
-> arch_domainconfig -> domid
+external domain_create : handle -> domctl_create_config -> domid
   = "stub_xc_domain_create"
 external domain_sethandle : handle -> domid -> string -> unit = 
"stub_xc_domain_sethandle"
 external domain_max_vcpus : handle -> domid -> int -> unit
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index af92bfa..fd8341e 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -119,36 +119,39 @@ static void 
domain_handle_of_uuid_string(xen_domain_handle_t h,
 #undef X
 }
 
-CAMLprim value stub_xc_domain_create(value xch, value ssidref,
- value flags, value handle,
- value domconfig)
+CAMLprim value stub_xc_domain_create(value xch, value config)
 {
-   CAMLparam4(xch, ssidref, flags, handle);
+   CAMLparam2(xch, config);
+
+   /* Mnemonics for the named fields inside domctl_create_config */
+#define VAL_SSIDREF Field(config, 0)
+#define VAL_HANDLE  Field(config, 1)
+#define VAL_FLAGS   Field(config, 2)
+#define VAL_ARCHField(config, 3)
 
uint32_t domid = 0;
-   xen_domain_handle_t h;
int result;
-   uint32_t c_ssidref = Int32_val(ssidref);
-   unsigned int c_flags = 0;
value l;
-   xc_domain_configuration_t config = {};
+   struct xen_domctl_createdomain cfg = {
+   .ssidref = Int32_val(VAL_SSIDREF),
+   };
 
-   domain_handle_of_uuid_string(h, String_val(handle));
+   domain_handle_of_uuid_string(cfg.handle, String_val(VAL_HANDLE));
 
-   for (l = flags; l != Val_none; l = Field(l, 1))
-   c_flags |= 1u << Int_val(Field(l, 0));
+   for (l = VAL_FLAGS; l != Val_none; l = Field(l, 1))
+   cfg.flags |= 1u << Int_val(Field(l, 0));
 
-   switch(Tag_val(domconfig)) {
+   switch(Tag_val(VAL_ARCH)) {
case 0: /* ARM - nothing to do */
caml_failwith("Unhandled: ARM");
break;
 
case 1: /* X86 - emulation flags in the block */
 #if defined(__i386__) || defined(__x86_64__)
-   for (l = Field(Field(domconfig, 0), 0);

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

[Andrew Cooper]

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 
---
CC: Ian Jackson 
CC: Wei Liu 

This patch is far more easily reviewed with `git diff --ignore-all-space`.
---
 tools/libxl/libxl_create.c | 47 +++---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f92c383..60a5542 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -541,7 +541,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
uint32_t *domid)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
-int flags, ret, rc, nb_vm;
+int ret, rc, nb_vm;
 const char *dom_type;
 char *uuid_string;
 char *dom_path, *vm_path, *libxl_path;
@@ -549,9 +549,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 struct xs_permissions rwperm[1];
 struct xs_permissions noperm[1];
 xs_transaction_t t = 0;
-xen_domain_handle_t handle;
 libxl_vminfo *vm_list;
-xc_domain_configuration_t xc_config = {};
 
 /* convenience aliases */
 libxl_domain_create_info *info = _config->c_info;
@@ -562,25 +560,28 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 goto out;
 }
 
-flags = 0;
-if (info->type != LIBXL_DOMAIN_TYPE_PV) {
-flags |= XEN_DOMCTL_CDF_hvm_guest;
-flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
-flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
-}
+/* Valid domid here means we're soft resetting. */
+if (!libxl_domid_valid_guest(*domid)) {
+int flags = 0;
+xen_domain_handle_t handle;
+xc_domain_configuration_t xc_config = {};
+
+if (info->type != LIBXL_DOMAIN_TYPE_PV) {
+flags |= XEN_DOMCTL_CDF_hvm_guest;
+flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
+}
 
-/* Ultimately, handle is an array of 16 uint8_t, same as uuid */
-libxl_uuid_copy(ctx, (libxl_uuid *)handle, >uuid);
+/* Ultimately, handle is an array of 16 uint8_t, same as uuid */
+libxl_uuid_copy(ctx, (libxl_uuid *)handle, >uuid);
 
-ret = libxl__arch_domain_prepare_config(gc, d_config, _config);
-if (ret < 0) {
-LOGED(ERROR, *domid, "fail to get domain config");
-rc = ERROR_FAIL;
-goto out;
-}
+ret = libxl__arch_domain_prepare_config(gc, d_config, _config);
+if (ret < 0) {
+LOGED(ERROR, *domid, "fail to get domain config");
+rc = ERROR_FAIL;
+goto out;
+}
 
-/* Valid domid here means we're soft resetting. */
-if (!libxl_domid_valid_guest(*domid)) {
 ret = xc_domain_create(ctx->xch, info->ssidref, handle, flags, domid,
_config);
 if (ret < 0) {
@@ -588,11 +589,11 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 rc = ERROR_FAIL;
 goto out;
 }
-}
 
-rc = libxl__arch_domain_save_config(gc, d_config, _config);
-if (rc < 0)
-goto out;
+rc = libxl__arch_domain_save_config(gc, d_config, _config);
+if (rc < 0)
+goto out;
+}
 
 ret = xc_cpupool_movedomain(ctx->xch, info->poolid, *domid);
 if (ret < 0) {
-- 
2.1.4


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

[Xen-devel] [PATCH 06/20] tools/ocaml: Drop domain_create_flag_table[]

[Andrew Cooper]

This is a logarithm in disguise.  Update the logic to match how
x86_arch_emulation_flags works in c/s 9d683b5e37 and b38d96f596.

Signed-off-by: Andrew Cooper 
---
CC: Christian Lindig 
CC: David Scott 
CC: Jon Ludlam 
CC: Rob Hoes 
---
 tools/ocaml/libs/xc/xenctrl_stubs.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c 
b/tools/ocaml/libs/xc/xenctrl_stubs.c
index f97070c..45d4e20 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -97,11 +97,6 @@ CAMLprim value stub_xc_interface_close(value xch)
CAMLreturn(Val_unit);
 }
 
-static int domain_create_flag_table[] = {
-   XEN_DOMCTL_CDF_hvm_guest,
-   XEN_DOMCTL_CDF_hap,
-};
-
 CAMLprim value stub_xc_domain_create(value xch, value ssidref,
  value flags, value handle,
  value domconfig)
@@ -124,10 +119,8 @@ CAMLprim value stub_xc_domain_create(value xch, value 
ssidref,
h[i] = Int_val(Field(handle, i)) & 0xff;
}
 
-   for (l = flags; l != Val_none; l = Field(l, 1)) {
-   int v = Int_val(Field(l, 0));
-   c_flags |= domain_create_flag_table[v];
-   }
+   for (l = flags; l != Val_none; l = Field(l, 1))
+   c_flags |= 1u << Int_val(Field(l, 0));
 
switch(Tag_val(domconfig)) {
case 0: /* ARM - nothing to do */
-- 
2.1.4


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

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

[Andrew Cooper]

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 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Juergen Gross 
CC: Christian Lindig 
CC: David Scott 
CC: Jon Ludlam 
CC: Rob Hoes 
CC: Marek Marczykowski-Górecki 
---
 tools/helpers/init-xenstore-domain.c | 16 +++-
 tools/libxc/include/xenctrl.h|  6 ++
 tools/libxc/xc_domain.c  | 31 ---
 tools/libxl/libxl_arch.h |  4 ++--
 tools/libxl/libxl_arm.c  | 16 
 tools/libxl/libxl_create.c   | 23 ---
 tools/libxl/libxl_x86.c  | 10 +-
 tools/ocaml/libs/xc/xenctrl_stubs.c  |  3 +--
 tools/python/xen/lowlevel/xc/xc.c| 28 
 9 files changed, 61 insertions(+), 76 deletions(-)

diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 8453be2..785e570 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -60,11 +60,13 @@ static void usage(void)
 static int build(xc_interface *xch)
 {
 char cmdline[512];
-uint32_t ssid;
-xen_domain_handle_t handle = { 0 };
 int rv, xs_fd;
 struct xc_dom_image *dom = NULL;
 int limit_kb = (maxmem ? : (memory + 1)) * 1024;
+struct xen_domctl_createdomain config = {
+.ssidref = SECINITSID_DOMU,
+.flags = XEN_DOMCTL_CDF_xs_domain,
+};
 
 xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
 if ( xs_fd == -1 )
@@ -75,19 +77,15 @@ static int build(xc_interface *xch)
 
 if ( flask )
 {
-rv = xc_flask_context_to_sid(xch, flask, strlen(flask), );
+rv = xc_flask_context_to_sid(xch, flask, strlen(flask), 
);
 if ( rv )
 {
 fprintf(stderr, "xc_flask_context_to_sid failed\n");
 goto err;
 }
 }
-else
-{
-ssid = SECINITSID_DOMU;
-}
-rv = xc_domain_create(xch, ssid, handle, XEN_DOMCTL_CDF_xs_domain,
-  , NULL);
+
+rv = xc_domain_create(xch, , );
 if ( rv )
 {
 fprintf(stderr, "xc_domain_create failed\n");
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 543abfc..6ecc850 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -494,10 +494,8 @@ typedef struct xc_vcpu_extstate {
 void *buffer;
 } xc_vcpu_extstate_t;
 
-typedef struct xen_arch_domainconfig xc_domain_configuration_t;
-int xc_domain_create(xc_interface *xch, uint32_t ssidref,
- xen_domain_handle_t handle, uint32_t flags,
- uint32_t *pdomid, xc_domain_configuration_t *config);
+int xc_domain_create(xc_interface *xch, uint32_t *pdomid,
+ struct xen_domctl_createdomain *config);
 
 
 /* Functions to produce a dump of a given domain
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index f122ea6..0124cea 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -26,43 +26,20 @@
 #include 
 #include 
 
-int xc_domain_create(xc_interface *xch, uint32_t ssidref,
- xen_domain_handle_t handle, uint32_t flags,
- uint32_t *pdomid, xc_domain_configuration_t *config)
+int xc_domain_create(xc_interface *xch, uint32_t *pdomid,
+ struct xen_domctl_createdomain *config)
 {
-xc_domain_configuration_t lconfig;
 int err;
 DECLARE_DOMCTL;
 
-if ( config == NULL )
-{
-memset(, 0, sizeof(lconfig));
-
-#if defined (__i386) || defined(__x86_64__)
-if ( flags & XEN_DOMCTL_CDF_hvm_guest )
-lconfig.emulation_flags = XEN_X86_EMU_ALL;
-#elif defined (__arm__) || defined(__aarch64__)
-lconfig.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
-lconfig.nr_spis = 0;
-#else
-#error Architecture not supported
-#endif
-
-config = 
-}
-
 domctl.cmd = XEN_DOMCTL_createdomain;
 domctl.domain = *pdomid;
-domctl.u.createdomain.ssidref = ssidref;
-domctl.u.createdomain.flags   = flags;
-memcpy(domctl.u.createdomain.handle, handle, sizeof(xen_domain_handle_t));
-/* xc_domain_configure_t is an alias of arch_domainconfig_t */
-memcpy(, config, 

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

[Andrew Cooper]

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.

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.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/platform_hypercall.c | 15 ---
 xen/common/domctl.c   | 18 --
 xen/include/xen/domain.h  |  1 -
 3 files changed, 34 deletions(-)

diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index ea18c32..b19f6ec 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -280,24 +280,9 @@ ret_t 
do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 
 guest_from_compat_handle(data, op->u.microcode.data);
 
-/*
- * alloc_vcpu() will access data which is modified during
- * microcode update
- */
-while ( !spin_trylock(_alloc_lock) )
-{
-if ( hypercall_preempt_check() )
-{
-ret = hypercall_create_continuation(
-__HYPERVISOR_platform_op, "h", u_xenpf_op);
-goto out;
-}
-}
-
 ret = microcode_update(
 guest_handle_to_param(data, const_void),
 op->u.microcode.length);
-spin_unlock(_alloc_lock);
 }
 break;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9b7bc08..4d275ff 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -34,7 +34,6 @@
 #include 
 
 static DEFINE_SPINLOCK(domctl_lock);
-DEFINE_SPINLOCK(vcpu_alloc_lock);
 
 static int bitmap_to_xenctl_bitmap(struct xenctl_bitmap *xenctl_bitmap,
const unsigned long *bitmap,
@@ -567,20 +566,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 /* Needed, for example, to ensure writable p.t. state is synced. */
 domain_pause(d);
 
-/*
- * Certain operations (e.g. CPU microcode updates) modify data which is
- * used during VCPU allocation/initialization
- */
-while ( !spin_trylock(_alloc_lock) )
-{
-if ( hypercall_preempt_check() )
-{
-ret =  hypercall_create_continuation(
-__HYPERVISOR_domctl, "h", u_domctl);
-goto maxvcpu_out_novcpulock;
-}
-}
-
 /* We cannot reduce maximum VCPUs. */
 ret = -EINVAL;
 if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
@@ -630,9 +615,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 ret = 0;
 
 maxvcpu_out:
-spin_unlock(_alloc_lock);
-
-maxvcpu_out_novcpulock:
 domain_unpause(d);
 break;
 }
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 177cb35..1929fa0 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -82,7 +82,6 @@ void arch_dump_domain_info(struct domain *d);
 
 int arch_vcpu_reset(struct vcpu *);
 
-extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 
-- 
2.1.4


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

[Xen-devel] [PATCH For-4.11 00/20] Improvements to domain creation

[Andrew Cooper]

The purpose of this patch series is for the final patch.  See the commit
message for details.

Patches 1 and 2 have been posted before, but are included here as they are
required for the eventual functionality.

This series can be found in git form here:
  
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-create-v1

It is semi-RFC because it has only had light testing so far.  It has been
build tested for ARM, but not functionally tested.

Andrew Cooper (20):
  tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state
  tools/libxl: Don't prepare or save xc_config when soft resetting a domain
  xen/public: Rename xen_domctl_createdomain.config to arch
  xen/domctl: Drop vcpu_alloc_lock
  arm/boot: Mark construct_dom0() as __init
  tools/ocaml: Drop domain_create_flag_table[]
  tools/ocaml: Drop int_array_of_uuid_string()
  tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()
  tools: Rework xc_domain_create() to take a full xen_domctl_createdomain
  xen/domctl: Merge set_max_evtchn into createdomain
  xen/domctl: Merge set_gnttab_limits into createdomain
  xen/domctl: Merge max_vcpus into createdomain
  xen/evtchn: Pass max_evtchn_port into evtchn_init()
  xen/gnttab: Remove replace_grant_supported()
  xen/gnttab: Export opt_max_{grant,maptrack}_frames
  xen/gnttab: Pass max_{grant,maptrack}_frames into grant_table_create()
  xen/gnttab: Fold grant_table_{create,set_limits}() into grant_table_init()
  xen/dom0: Arrange for dom0_cfg to contain the real max_vcpus value
  xen/domain: Call arch_domain_create() as early as possible in domain_create()
  xen/domain: Allocate d->vcpu[] in arch_domain_create()

 tools/flask/policy/modules/dom0.te   |   6 +-
 tools/flask/policy/modules/xen.if|   6 +-
 tools/helpers/init-xenstore-domain.c |  43 +---
 tools/libxc/include/xenctrl.h|  43 +---
 tools/libxc/xc_domain.c  |  64 ++
 tools/libxl/libxl_arch.h |   4 +-
 tools/libxl/libxl_arm.c  |  16 ++---
 tools/libxl/libxl_create.c   |  61 +
 tools/libxl/libxl_dm.c   |   3 +-
 tools/libxl/libxl_dom.c  |  18 -
 tools/libxl/libxl_internal.h |   5 +-
 tools/libxl/libxl_x86.c  |  10 +--
 tools/ocaml/libs/xc/xenctrl.ml   |  40 +--
 tools/ocaml/libs/xc/xenctrl.mli  |  22 --
 tools/ocaml/libs/xc/xenctrl_stubs.c  | 106 +++--
 tools/python/xen/lowlevel/xc/xc.c|  64 +-
 xen/arch/arm/domain.c|  23 +--
 xen/arch/arm/domain_build.c  |  15 +++--
 xen/arch/arm/setup.c |  21 +-
 xen/arch/arm/vgic.c  |  14 
 xen/arch/x86/dom0_build.c|   7 --
 xen/arch/x86/domain.c|  13 +++-
 xen/arch/x86/platform_hypercall.c|  15 -
 xen/arch/x86/setup.c |   7 +-
 xen/common/domain.c  |  39 +--
 xen/common/domctl.c  | 125 +--
 xen/common/event_channel.c   |   8 +--
 xen/common/grant_table.c | 100 +++-
 xen/include/asm-arm/domain.h |   6 --
 xen/include/asm-arm/grant_table.h|  16 -
 xen/include/asm-arm/vgic.h   |   2 -
 xen/include/asm-x86/domain.h |   2 -
 xen/include/asm-x86/grant_table.h|  10 ---
 xen/include/asm-x86/setup.h  |   2 -
 xen/include/public/domctl.h  |  41 
 xen/include/xen/domain.h |   4 +-
 xen/include/xen/grant_table.h|  11 ++-
 xen/include/xen/sched.h  |   2 +-
 xen/xsm/flask/hooks.c|   9 ---
 xen/xsm/flask/policy/access_vectors  |   6 --
 40 files changed, 366 insertions(+), 643 deletions(-)

-- 
2.1.4


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

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

[Andrew Cooper]

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 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/libxc/xc_domain.c |  4 ++--
 xen/arch/arm/domain.c   | 10 +-
 xen/arch/arm/setup.c|  4 ++--
 xen/arch/x86/domain.c   |  2 +-
 xen/arch/x86/setup.c|  2 +-
 xen/include/public/domctl.h |  2 +-
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ea3df1e..f122ea6 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -57,12 +57,12 @@ int xc_domain_create(xc_interface *xch, uint32_t ssidref,
 domctl.u.createdomain.flags   = flags;
 memcpy(domctl.u.createdomain.handle, handle, sizeof(xen_domain_handle_t));
 /* xc_domain_configure_t is an alias of arch_domainconfig_t */
-memcpy(, config, sizeof(*config));
+memcpy(, config, sizeof(*config));
 if ( (err = do_domctl(xch, )) != 0 )
 return err;
 
 *pdomid = (uint16_t)domctl.domain;
-memcpy(config, , sizeof(*config));
+memcpy(config, , sizeof(*config));
 
 return 0;
 }
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7193531..0931ce6 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -601,18 +601,18 @@ int arch_domain_create(struct domain *d,
 clear_page(d->shared_info);
 share_xen_page_with_guest(virt_to_page(d->shared_info), d, SHARE_rw);
 
-switch ( config->config.gic_version )
+switch ( config->arch.gic_version )
 {
 case XEN_DOMCTL_CONFIG_GIC_NATIVE:
 switch ( gic_hw_version () )
 {
 case GIC_V2:
-config->config.gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
+config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V2;
 d->arch.vgic.version = GIC_V2;
 break;
 
 case GIC_V3:
-config->config.gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
+config->arch.gic_version = XEN_DOMCTL_CONFIG_GIC_V3;
 d->arch.vgic.version = GIC_V3;
 break;
 
@@ -640,10 +640,10 @@ int arch_domain_create(struct domain *d,
 if ( (rc = domain_io_init(d, count + MAX_IO_HANDLER)) != 0 )
 goto fail;
 
-if ( (rc = domain_vgic_init(d, config->config.nr_spis)) != 0 )
+if ( (rc = domain_vgic_init(d, config->arch.nr_spis)) != 0 )
 goto fail;
 
-if ( (rc = domain_vtimer_init(d, >config)) != 0 )
+if ( (rc = domain_vtimer_init(d, >arch)) != 0 )
 goto fail;
 
 update_domain_wallclock_time(d);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b17797d..e6f8e23 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -840,8 +840,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 /* Create initial domain 0. */
 /* The vGIC for DOM0 is exactly emulating the hardware GIC */
-dom0_cfg.config.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
-dom0_cfg.config.nr_spis = gic_number_lines() - 32;
+dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
+dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
 
 dom0 = domain_create(0, _cfg);
 if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 4cac890..c4c34b4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -480,7 +480,7 @@ int arch_domain_create(struct domain *d,
 
 d->arch.s3_integrity = config->flags & XEN_DOMCTL_CDF_s3_integrity;
 
-emflags = config->config.emulation_flags;
+emflags = config->arch.emulation_flags;
 
 if ( is_hardware_domain(d) && is_pv_domain(d) )
 emflags |= XEN_X86_EMU_PIT;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 3f6ecf4..fa77bae 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1638,7 +1638,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
((hvm_funcs.hap_supported && !opt_dom0_shadow) ?
 XEN_DOMCTL_CDF_hap : 0));
 
-dom0_cfg.config.emulation_flags |=
+dom0_cfg.arch.emulation_flags |=
 XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC;
 }
 
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index ec7a860..0535da8 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -65,7 +65,7 @@ struct xen_domctl_createdomain {
 #define _XEN_DOMCTL_CDF_xs_domain 4
 #define XEN_DOMCTL_CDF_xs_domain  (1U<<_XEN_DOMCTL_CDF_xs_domain)
 uint32_t flags;
-struct xen_arch_domainconfig config;
+struct xen_arch_domainconfig arch;
 };
 
 /* XEN_DOMCTL_getdomaininfo */
-- 
2.1.4


___

[Xen-devel] [PATCH 05/20] arm/boot: Mark construct_dom0() as __init

[Andrew Cooper]

Its sole caller, start_xen(), is __init.

Signed-off-by: Andrew Cooper 
---
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/domain_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 28ee876..9ef9030 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2094,7 +2094,7 @@ static void __init find_gnttab_region(struct domain *d,
kinfo->gnttab_start, kinfo->gnttab_start + kinfo->gnttab_size);
 }
 
-int construct_dom0(struct domain *d)
+int __init construct_dom0(struct domain *d)
 {
 struct kernel_info kinfo = {};
 struct vcpu *saved_current;
-- 
2.1.4


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

[Xen-devel] broken build: 448c03b3cbe14873ee637755a29ea26ee7ca9ef9

[Doug Goldstein]

commit 448c03b3cbe14873ee637755a29ea26ee7ca9ef9
Author: Juergen Gross 
Date:   Mon Feb 26 09:46:12 2018 +0100

This commit breaks the build of qemu-xen-traditional for:

Ubuntu 14.04: https://gitlab.com/cardoe/xen/-/jobs/58266170
Ubuntu 16.04: https://gitlab.com/cardoe/xen/-/jobs/58266174

A short snippet of the failure is:

  ARi386-dm/libqemu.a
  LINK  i386-dm/qemu-dm
/builds/cardoe/xen/tools/../tools/xenstore/libxenstore.so: undefined
reference to `dlsym'
collect2: error: ld returned 1 exit status
make[5]: *** [qemu-dm] Error 1
make[5]: Leaving directory
`/builds/cardoe/xen/tools/qemu-xen-traditional-dir-remote/i386-dm'
make[4]: *** [subdir-i386-dm] Error 2
make[4]: Leaving directory
`/builds/cardoe/xen/tools/qemu-xen-traditional-dir-remote'
make[3]: *** [subdir-all-qemu-xen-traditional-dir] Error 2
make[3]: Leaving directory `/builds/cardoe/xen/tools'
make[2]: *** [subdirs-install] Error 2
make[2]: Leaving directory `/builds/cardoe/xen/tools'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/builds/cardoe/xen/tools'
make: *** [install-tools] Error 2

-- 
Doug Goldstein

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

[Xen-devel] [PATCH v2] xen: fix null sched build with debug=n

[Doug Goldstein]

The null_dom() static inline is just used when debug=y so it results in
a error with the default CFLAGS and debug=n. This function is used in
only one place and it a one line helper so remove it until we actually
need it.

Signed-off-by: Doug Goldstein 
---
environment: Debian stretch
compiler: clang
full log: https://gitlab.com/cardoe/xen/-/jobs/58011527
error:
sched_null.c:123:32: error: unused function 'null_dom' 
[-Werror,-Wunused-function]
---
change since v1:
- removed the helper function as per Dario
---
 xen/common/sched_null.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index 58e306a7ea..58ddf7d889 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -120,11 +120,6 @@ static inline struct null_vcpu *null_vcpu(const struct 
vcpu *v)
 return v->sched_priv;
 }
 
-static inline struct null_dom *null_dom(const struct domain *d)
-{
-return d->sched_priv;
-}
-
 static inline bool vcpu_check_affinity(struct vcpu *v, unsigned int cpu,
unsigned int balance_step)
 {
@@ -677,7 +672,7 @@ static void null_vcpu_migrate(const struct scheduler *ops, 
struct vcpu *v,
 static inline void null_vcpu_check(struct vcpu *v)
 {
 struct null_vcpu * const nvc = null_vcpu(v);
-struct null_dom * const ndom = null_dom(v->domain);
+struct null_dom * const ndom = v->domain->sched_priv;
 
 BUG_ON(nvc->vcpu != v);
 
-- 
2.16.1


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

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

[Roger Pau Monné]

On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote:
> This patch extends hvmloader_acpi_build_tables() with code which detects
> if MMCONFIG is available -- i.e. initialized and enabled (+we're running
> on Q35), obtains its base address and size and asks libacpi to build MCFG
> table for it via setting the flag ACPI_HAS_MCFG in a manner similar
> to other optional ACPI tables building.
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/firmware/hvmloader/util.c | 70 
> +
>  1 file changed, 70 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index d8db9e3c8e..c6fc81d52a 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -782,6 +782,69 @@ int get_pc_machine_type(void)
>  return machine_type;
>  }
>  
> +#define PCIEXBAR_ADDR_MASK_64MB (~((1ULL << 26) - 1))
> +#define PCIEXBAR_ADDR_MASK_128MB(~((1ULL << 27) - 1))
> +#define PCIEXBAR_ADDR_MASK_256MB(~((1ULL << 28) - 1))
> +#define PCIEXBAR_LENGTH_BITS(reg)   (((reg) >> 1) & 3)
> +#define PCIEXBAREN  1

PCIEXBAR_ENABLE maybe?

> +
> +static uint64_t mmconfig_get_base(void)
> +{
> +uint64_t base;
> +uint32_t reg = pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR);
> +
> +base = reg | (uint64_t) pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR+4) << 
> 32;

Please add parentheses in the above expression.

> +
> +switch (PCIEXBAR_LENGTH_BITS(reg))
> +{
> +case 0:
> +base &= PCIEXBAR_ADDR_MASK_256MB;
> +break;
> +case 1:
> +base &= PCIEXBAR_ADDR_MASK_128MB;
> +break;
> +case 2:
> +base &= PCIEXBAR_ADDR_MASK_64MB;
> +break;

Missing newlines, plus this looks like it wants to use the defines
introduced in patch 7 (PCIEXBAR_{64,128,256}_BUSES). Also any reason
this patch and patch 7 cannot be put sequentially?

They are very related, and in fact I'm not sure why we need to write
this info to the device in patch 7 and then fetch it from the device
here. Isn't there an easier way to pass this information? At the end
this is all in hvmloader.

> +case 3:

default:

> +BUG();  /* a reserved value encountered */
> +}
> +
> +return base;
> +}
> +
> +static uint32_t mmconfig_get_size(void)

unsigned int or size_t?

> +{
> +uint32_t reg = pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR);
> +
> +switch (PCIEXBAR_LENGTH_BITS(reg))
> +{
> +case 0: return MB(256);
> +case 1: return MB(128);
> +case 2: return MB(64);
> +case 3:
> +BUG();  /* a reserved value encountered */

Same comments as above about the labels and the case 3 label.

> +}
> +
> +return 0;
> +}
> +
> +static uint32_t mmconfig_is_enabled(void)
> +{
> +return pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR) & PCIEXBAREN;
> +}
> +
> +static int is_mmconfig_used(void)

bool

> +{
> +if (get_pc_machine_type() == MACHINE_TYPE_Q35)
> +{
> +if (mmconfig_is_enabled() && mmconfig_get_base())

Coding style.

Also you can join the conditions:

if ( get_pc_machine_type() == MACHINE_TYPE_Q35 && mmconfig_is_enabled() &&
 mmconfig_get_base() )
 return true;

Looking at this, is it actually a valid state to have
mmconfig_is_enabled() == true and mmconfig_get_base() == 0?

> +return 1;
> +}
> +
> +return 0;
> +}
> +
>  static void validate_hvm_info(struct hvm_info_table *t)
>  {
>  uint8_t *ptr = (uint8_t *)t;
> @@ -993,6 +1056,13 @@ void hvmloader_acpi_build_tables(struct acpi_config 
> *config,
>  config->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
>  }
>  
> +if ( is_mmconfig_used() )
> +{
> +config->table_flags |= ACPI_HAS_MCFG;
> +config->mmconfig_addr = mmconfig_get_base();
> +config->mmconfig_len  = mmconfig_get_size();
> +}
> +
>  s = xenstore_read("platform/generation-id", "0:0");
>  if ( s )
>  {
> -- 
> 2.11.0
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [RFC PATCH 10/12] libacpi: build ACPI MCFG table if requested

[Roger Pau Monné]

On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko wrote:
> This adds construct_mcfg() function to libacpi which allows to build MCFG
> table for a given mmconfig_addr/mmconfig_len pair if the ACPI_HAS_MCFG
> flag was specified in acpi_config struct.
> 
> The maximum bus number is calculated from mmconfig_len using
> MCFG_SIZE_TO_NUM_BUSES macro (1MByte of MMIO space per bus).
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/libacpi/acpi2_0.h | 21 +
>  tools/libacpi/build.c   | 42 ++
>  tools/libacpi/libacpi.h |  4 
>  3 files changed, 67 insertions(+)
> 
> diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
> index 2619ba32db..209ad1acd3 100644
> --- a/tools/libacpi/acpi2_0.h
> +++ b/tools/libacpi/acpi2_0.h
> @@ -422,6 +422,25 @@ struct acpi_20_slit {
>  };
>  
>  /*
> + * PCI Express Memory Mapped Configuration Description Table
> + */
> +struct mcfg_range_entry {
> +uint64_t base_address;
> +uint16_t pci_segment;
> +uint8_t  start_pci_bus_num;
> +uint8_t  end_pci_bus_num;
> +uint32_t reserved;
> +};
> +
> +struct acpi_mcfg {
> +struct acpi_header header;
> +uint8_t reserved[8];
> +struct mcfg_range_entry entries[1];
> +};

I would define this as:

struct acpi_10_mcfg {
struct acpi_header header;
uint8_t reserved[8];
struct acpi_10_mcfg_entry {
uint64_t base_address;
uint16_t pci_segment;
uint8_t  start_pci_bus;
uint8_t  end_pci_bus;
uint32_t reserved;
} entries[1];
};

> +
> +#define MCFG_SIZE_TO_NUM_BUSES(size)  ((size) >> 20)

I'm not sure the following macro belongs here. This is not directly
related to ACPI.

> +
> +/*
>   * Table Signatures.
>   */
>  #define ACPI_2_0_RSDP_SIGNATURE ASCII64('R','S','D',' ','P','T','R',' ')
> @@ -435,6 +454,7 @@ struct acpi_20_slit {
>  #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
>  #define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
>  #define ACPI_2_0_SLIT_SIGNATURE ASCII32('S','L','I','T')
> +#define ACPI_MCFG_SIGNATURE ASCII32('M','C','F','G')
>  
>  /*
>   * Table revision numbers.
> @@ -449,6 +469,7 @@ struct acpi_20_slit {
>  #define ACPI_1_0_FADT_REVISION 0x01
>  #define ACPI_2_0_SRAT_REVISION 0x01
>  #define ACPI_2_0_SLIT_REVISION 0x01
> +#define ACPI_1_0_MCFG_REVISION 0x01
>  
>  #pragma pack ()
>  
> diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
> index f9881c9604..5daf1fc5b8 100644
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -303,6 +303,37 @@ static struct acpi_20_slit *construct_slit(struct 
> acpi_ctxt *ctxt,
>  return slit;
>  }
>  
> +static struct acpi_mcfg *construct_mcfg(struct acpi_ctxt *ctxt,
> +const struct acpi_config *config)
> +{
> +struct acpi_mcfg *mcfg;
> +
> +/* Warning: this code expects that we have only one PCI segment */
> +mcfg = ctxt->mem_ops.alloc(ctxt, sizeof(*mcfg), 16);
> +if (!mcfg)

Coding style.

> +return NULL;
> +
> +memset(mcfg, 0, sizeof(*mcfg));
> +mcfg->header.signature= ACPI_MCFG_SIGNATURE;
> +mcfg->header.revision = ACPI_1_0_MCFG_REVISION;
> +fixed_strcpy(mcfg->header.oem_id, ACPI_OEM_ID);
> +fixed_strcpy(mcfg->header.oem_table_id, ACPI_OEM_TABLE_ID);
> +mcfg->header.oem_revision = ACPI_OEM_REVISION;
> +mcfg->header.creator_id   = ACPI_CREATOR_ID;
> +mcfg->header.creator_revision = ACPI_CREATOR_REVISION;
> +mcfg->header.length = sizeof(*mcfg);

As said before, if you want to align things, please do it for the
whole block.

> +
> +mcfg->entries[0].base_address = config->mmconfig_addr;
> +mcfg->entries[0].pci_segment = 0;
> +mcfg->entries[0].start_pci_bus_num = 0;
> +mcfg->entries[0].end_pci_bus_num =
> +MCFG_SIZE_TO_NUM_BUSES(config->mmconfig_len) - 1;

Why not pass the start_bus and end_bus values in acpi_config at least?

> +
> +set_checksum(mcfg, offsetof(struct acpi_header, checksum), 
> sizeof(*mcfg));
> +
> +return mcfg;;

Double ;;

> +}
> +
>  static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
>  unsigned long *table_ptrs,
>  int nr_tables,
> @@ -350,6 +381,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
> *ctxt,
>  struct acpi_20_hpet *hpet;
>  struct acpi_20_waet *waet;
>  struct acpi_20_tcpa *tcpa;
> +struct acpi_mcfg *mcfg;
>  unsigned char *ssdt;
>  static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
>  void *lasa;
> @@ -417,6 +449,16 @@ static int construct_secondary_tables(struct acpi_ctxt 
> *ctxt,
>  printf("CONV disabled\n");
>  }
>  
> +/* MCFG */
> +if ( config->table_flags & ACPI_HAS_MCFG )
> +{
> +mcfg = construct_mcfg(ctxt, config);
> +if (!mcfg)

Coding style.

> +return -1;
> +
> +

Re: [Xen-devel] [PATCH v2 19/45] ARM: new VGIC: Add IRQ sync/flush framework

[Andre Przywara]

Hi,

On 19/03/18 14:17, Julien Grall wrote:
> Hi,
> 
> On 03/15/2018 08:30 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 
>> ---
>> Changelog v1 ... v2:
>> - make functions void
> 
> Hmmm, the function were already void in the previous version. However,
> you switch from static inline to static. Did I miss anything?

Ah right, I just saw the diff hitting on the prototype line ;-)
For the records: static inline in a .c file is a red herring:
https://www.kernel.org/doc/local/inline.html
summary: Use static inline in header files, just static in .c files.
inline is a hint, and the compiler knows best what to do. Really.

Will adjust the change log.

Cheers,
Andre.

> 
> [...]
> 
>> +static void vgic_set_underflow(struct vcpu *vcpu)
>> +{
>> +    ASSERT(vcpu == current);
>> +
>> +    gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
> 
> The second is a boolean, so please use true.
> 
> Cheers,
> 

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

Re: [Xen-devel] [PATCH 28/57] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

[Andre Przywara]

Hi,

On 06/03/18 18:13, Julien Grall wrote:
> Hi Andre,
> 
> On 05/03/18 16:03, 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 RFC ... v1:
>> - add kernel-doc comments to exported functions
>> - adapt to previous changes (new_vgic.h, arch_vcpu member name)
>> - use ASSERT_UNREACHABLE
>>
>>   xen/arch/arm/vgic/vgic.c | 124
>> +++
>>   xen/arch/arm/vgic/vgic.h |  41 
>>   2 files changed, 165 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..ace30f78d0
>> --- /dev/null
>> +++ b/xen/arch/arm/vgic/vgic.c
>> @@ -0,0 +1,124 @@
>> +/*
>> + * 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.
>> + */
>> +static struct vgic_irq *vgic_get_lpi(struct domain *d, u32 intid)
>> +{
>> +    struct vgic_dist *dist = >arch.vgic;
>> +    struct vgic_irq *irq = NULL;
>> +
>> +    spin_lock(>lpi_list_lock);
>> +
>> +    list_for_each_entry( irq, >lpi_list_head, lpi_list )
> 
> I am still not a big fan of the list solution. Strictly speaking nobody
> is populating that list and likely going to be too slow in Xen case (I
> am thinking for the hardware domain). So I think I would prefer to see
> the LPI related code disappear for this cut. This could easily be added
> back as they are standalone.

I was thinking about that, but dismissed the idea:
Considering LPIs as first class citizens is a crucial property of the
new VGIC and actually the main driver for its creation: the refcounting
is solely in for that purpose, and the per-IRQ data structure and its
lock are mainly driven by it. So removing the LPI support completely
will make the refcounting look very awkward (since useless and unused).
Consequently one would need to remove that as well. In the worst case we
run into issues with unused functions, like vgic_get_irq_kref().

I already removed a lot of code from the KVM VGIC, which I feel we will
need back one day. So I really like to keep this one in, and be it just
for documentation how the refcounting is supposed to be used.
I will add a comment to this respect.

And I believe replacing the list_for_each_entry() with something more
sophisticated is the least of our problems later on.

Cheers,
Andre.

___
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)

[Roger Pau Monné]

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.

> 
> Note that omitting device_model_machine parameter means i440 system
> by default, so the default behavior doesn't change for existing domain
> config files.
> 
> Setting device_model_machine to "q35" sends '-machine q35,accel=xen'
> argument to QEMU. Unlike i440, there no separate machine type
> to enable/disable Xen platform device, it is controlled via a machine

But I assume the xen_platform_pci option still works as expected?

> property only. See 'libxl: Xen Platform device support for Q35' patch for
> a detailed description.
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/libxl/libxl_dm.c  | 16 ++--
>  tools/libxl/libxl_types.idl |  7 +++
>  tools/xl/xl_parse.c | 14 ++
>  3 files changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index a3cddce8b7..7b531050c7 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1443,13 +1443,17 @@ static int 
> libxl__build_device_model_args_new(libxl__gc *gc,
>  flexarray_append(dm_args, b_info->extra_pv[i]);
>  break;
>  case LIBXL_DOMAIN_TYPE_HVM:
> -if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> -/* Switching here to the machine "pc" which does not add
> - * the xen-platform device instead of the default "xenfv" 
> machine.
> - */
> -machinearg = libxl__strdup(gc, "pc,accel=xen");
> +if (b_info->device_model_machine == LIBXL_DEVICE_MODEL_MACHINE_Q35) {
> +machinearg = libxl__sprintf(gc, "q35,accel=xen");
>  } else {
> -machinearg = libxl__strdup(gc, "xenfv");
> +if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> +/* Switching here to the machine "pc" which does not add
> + * the xen-platform device instead of the default "xenfv" 
> machine.
> + */
> +machinearg = libxl__strdup(gc, "pc,accel=xen");
> +} else {
> +machinearg = libxl__strdup(gc, "xenfv");
> +}
>  }
>  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?

> +(1, "I440"),
> +(2, "Q35"),
> +])
> +
>  libxl_console_type = Enumeration("console_type", [
>  (0, "UNKNOWN"),
>  (1, "SERIAL"),
> @@ -491,6 +497,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  ("device_model_ssid_label", string),
>  # device_model_user is not ready for use yet
>  ("device_model_user", string),
> +("device_model_machine", libxl_device_model_machine),
>  
>  # extra parameters pass directly to qemu, NULL terminated
>  ("extra",libxl_string_list),
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index f6842540ca..a7506a426b 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -2110,6 +2110,20 @@ skip_usbdev:
>  xlu_cfg_replace_string(config, "device_model_user",
> _info->device_model_user, 0);
>  
> +if (!xlu_cfg_get_string (config, "device_model_machine", , 0)) {
> +if (!strcmp(buf, "i440")) {
> +b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_I440;
> +} else if (!strcmp(buf, "q35")) {
> +b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_Q35;
> +} else {
> +fprintf(stderr,
> +"Unknown device_model_machine \"%s\" specified\n", buf);
> +exit(1);
> +}
> +} else {
> +b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_UNKNOWN;

That seems to be it's usage. I'm not sure you should explicitly set it
in the default case (DEFAULT == 0 already).

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

[Paul Durrant]

> -Original Message-
[snip]
> >> How are you making sure this is a mapping that was established via
> >> the map op? Without that this can be (ab)used to ...
> >>
> >> > +put_page(page);
> >>
> >> ... underflow the refcount of a page.
> >>
> >
> > Yes, I guess I need to ensure that only non-RAM (i.e. RMRR and E820
> reserved
> > areas) are mapped through the IOMMU or this could indeed be abused.
> 
> Now I'm confused - then you don't need to deal with struct page_info
> and page references at all. Nor would you need to call
> get_page_from_gfn() and check p2m_is_any_ram(). Also - what use
> would the interface be if you couldn't map any RAM?
> 

Sorry to confuse...

What I meant was that safety (against underflow) is predicated on 
iommu_lookup_page() failing if the mapping was not established through an iommu 
op hypercall. So, the only things that should be valid in the iommu (and hence 
that iommu_lookup_page() would succeed for) at the point where the guest starts 
to boot must all fall within reserved regions, so thay they are ruled out by 
the earlier check.

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

Re: [Xen-devel] [PATCH 2/3] x86/pv: Fold {compat_}unregister_guest_callback() into its non-compat counterpart

[Jan Beulich]

>>> On 15.03.18 at 12:58,  wrote:
> These functions are almost identical.  They differ only in the error emitted
> for the use of CALLBACKTYPE_syscall (which is inconsequential to guests),

I'm not entirely convinced - so far there's been a match here between
map and unmap, i.e. with the change it may be advisable for
compat_register_guest_callback() to also return -EINVAL for
CALLBACKTYPE_syscall. However, I don't feel strongly about this, so
either way ...

> and
> the type of their argument.
> 
> Have the callers pass the unreg.type parameter directly, avoiding the need for
> differently typed parameters.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 1/3] x86/pv: Avoid locked bit manipulation in register_guest_callback()

[Jan Beulich]

>>> On 15.03.18 at 12:58,  wrote:
> Changes to arch.vgc_flags are made to current in syncrhonous context only, and
> don't need to be locked.  (The only other changes are via
> arch_set_info_guest(), which operates on descheduled vcpus only).
> 
> Replace the {set,clear}_bit() calls with compiler-visible bitwise 
> operations.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

[Xen-devel] [RFC PATCH] Make Security Policy Doc ready to become a CNA

[Lars Kurth]

And this time with patch: note to myself - never try sendmail with --compose 
again (-;

This patch contains a proposal to change 
https://xenproject.org/security-policy.html 
such that it points to SUPPORT.md. Having scope and process information is 
necessary
to become a CNA. This is the last piece, before formally asking to become a CNA.

To make the review of this easier, I based it on xenbits:/larsk/governance.git
(contains the pandoc as published today and the html)

Regards
Lars
---
[PATCH] Make Security Policy Doc ready to become a CNA

To become a CNA, we need to more clearly specifiy the scope of
security support. This change updates the document and points
to SUPPORT.md and pages generated from SUPPORT.md

Expected changes:
- Resend once the URL that is currently open has been agreed
  with Ian Jackson

Signed-off-by: Lars Kurth 
---
 security-policy.pandoc | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/security-policy.pandoc b/security-policy.pandoc
index 5783183..22e274b 100644
--- a/security-policy.pandoc
+++ b/security-policy.pandoc
@@ -19,6 +19,14 @@ Scope of this process
 
 This process primarily covers the [Xen Hypervisor
 
Project](index.php?option=com_content=article=82:xen-hypervisor=80:developers=484).
+Specific information about features with security support can be found in
+
+1.  [SUPPORT.md](http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=SUPPORT.md)
+in the releases' tar ball and its xen.git tree and on
+[web pages generated from the SUPPORT.md file](add URL)
+2.  For releases that do not contain SUPPORT.md, this information can be found
+pm the [Release Feature wiki 
page](https://wiki.xenproject.org/wiki/Xen_Project_Release_Features)
+
 Vulnerabilties reported against other Xen Project teams will be handled on a
 best effort basis by the relevant Project Lead together with the Security
 Response Team.
@@ -401,7 +409,7 @@ Change History
 --
 
 
-
+-   **v3.18 March 19th 2017:** Added reference to SUPPORT.md
 -   **v3.17 July 20th 2017:** Added Zynstra
 -   **v3.16 April 21st 2017:** Added HostPapa
 -   **v3.15 March 21st 2017:** Added CloudVPS (Feb 13) and BitDefender SRL
-- 
2.13.0


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

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

[Jason Andryuk]

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 
---
 arch/x86/xen/enlighten_pv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 3c2c2530737e..c36d23aa6c35 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1259,10 +1259,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 */
__userpte_alloc_gfp &= ~__GFP_HIGHMEM;
 
-   /* Work out if we support NX */
-   get_cpu_cap(_cpu_data);
-   x86_configure_nx();
-
/* Get mfn list */
xen_build_dynamic_phys_to_machine();
 
@@ -1272,6 +1268,10 @@ asmlinkage __visible void __init xen_start_kernel(void)
 */
xen_setup_gdt(0);
 
+   /* Work out if we support NX */
+   get_cpu_cap(_cpu_data);
+   x86_configure_nx();
+
xen_init_irq_ops();
 
/* Let's presume PV guests always boot on vCPU with id 0. */
-- 
2.14.3


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

Re: [Xen-devel] What is the option 'e' used for in 'xl create' command

[Stefano Stabellini]

On Mon, 19 Mar 2018, Dongli Zhang wrote:
> Hi,
> 
> There is an 'e' option when running the following xl command:
> 
> - xl create
> - xl restore
> - xl migrate
> - xl remus
> 
> The 'e' option is used to "Do not wait in the background (on ) for the
> death of the domain". This option dates back to Dec 2009.
> 
> Would you please help me understand the objective of the below patch 
> introduced
> in Dec 2009?
> 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=de7c9106c1a22c0fd759cefcecf2c428e5a76a00
> 
> Thank you very much for your help!

Hi Dongli,

The idea back then was that xl is a command line tool which doesn't rely
on any daemons running except for xenstored. However, there were a
couple of events that needed to be handled at runtime, naming domain
destruction and cdrom insert/eject for HVM guests. For that reason, xl
started forking and executing an instance of itself in the background,
just waiting to handle these events.

The "-e" command line option was meant to prevent xl from running any
background processes. This way, xl would just terminate after executing
the requested command. Of course, in that case one would have to
manually destroy the domains and cdrom insert/eject might not work, but
everything else should work as usual.

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges

[Jan Beulich]

>>> On 19.03.18 at 16:36,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 19 March 2018 15:14
>> 
>> >>> On 12.02.18 at 11:47,  wrote:
>> > --- a/xen/arch/x86/iommu_op.c
>> > +++ b/xen/arch/x86/iommu_op.c
>> > @@ -22,6 +22,58 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> > +
>> > +struct get_rdm_ctxt {
>> > +unsigned int max_entries;
>> > +unsigned int nr_entries;
>> > +XEN_GUEST_HANDLE(xen_iommu_reserved_region_t) regions;
>> > +};
>> > +
>> > +static int get_rdm(xen_pfn_t start, xen_ulong_t nr, u32 id, void *arg)
>> > +{
>> > +struct get_rdm_ctxt *ctxt = arg;
>> > +
>> > +if ( ctxt->nr_entries < ctxt->max_entries )
>> > +{
>> > +xen_iommu_reserved_region_t region = {
>> > +.start_bfn = start,
>> > +.nr_frames = nr,
>> > +};
>> > +
>> > +if ( copy_to_guest_offset(ctxt->regions, ctxt->nr_entries, 
>> > ,
>> > +  1) )
>> > +return -EFAULT;
>> > +}
>> > +
>> > +ctxt->nr_entries++;
>> > +
>> > +return 1;
>> > +}
>> > +
>> > +static int iommuop_query_reserved(struct
>> xen_iommu_op_query_reserved *op)
>> > +{
>> > +struct get_rdm_ctxt ctxt = {
>> > +.max_entries = op->nr_entries,
>> > +.regions = op->regions,
>> > +};
>> > +int rc;
>> > +
>> > +if (op->pad != 0)
>> > +return -EINVAL;
>> > +
>> > +rc = iommu_get_reserved_device_memory(get_rdm, );
>> > +if ( rc )
>> > +return rc;
>> > +
>> > +/* Pass back the actual number of reserved regions */
>> > +op->nr_entries = ctxt.nr_entries;
>> > +
>> > +if ( ctxt.nr_entries > ctxt.max_entries )
>> > +return -ENOBUFS;
>> > +
>> > +return 0;
>> > +}
>> 
>> One more note here: As it looks we can only hope there won't be
>> too many RMRRs, as the number of entries that can be requested
>> here is basically unbounded.
>> 
> 
> The caller has to be able to allocate a buffer large enough but, yes there 
> is no explicit limit. I'll add pre-empt checks.

Thing is - preempt check probably won't be easy with the way
iommu_get_reserved_device_memory() works.

Jan


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

Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges

[Jan Beulich]

>>> On 19.03.18 at 16:13,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 19 March 2018 14:10
>> 
>> >>> On 12.02.18 at 11:47,  wrote:
>> > +for ( j = 0; \
>> > +  j < min_t(unsigned int, (_d_)->nr_entries, \
>> > +*nr_entries); \
>> 
>> Do you really need min_t() here (rather than the more safe min())?
>> 
> 
> I've been asked to preferentially use min_t() before (although I don't think 
> it was by you) so I'm not sure what the expectation is. I'm happy to use 
> min().

I'd be curious who that was and why. The type check in min() makes
it preferable to use whenever the two types are (supposed to be)
compatible.

>> > +struct xen_iommu_reserved_region {
>> > +xen_bfn_t start_bfn;
>> > +unsigned int nr_frames;
>> > +unsigned int pad;
>> 
>> Fixed width types (i.e. uint32_t) in the public interface please.
>> Also, this not being the main MMU, page granularity needs to be
>> specified somehow (also for the conversion between xen_bfn_t
>> and a bus address).
>> 
> 
> Do you think it would be better to have a separate query call to get the 
> IOMMU page size back, or are you anticipating heterogeneous ranges (in which 
> case I'm going to need to adjust the map and unmap functions to allow for 
> that)?

Fundamentally (on x86) I can't see why we couldn't eventually
permit 2M and 1G mappings to be established this way. For
RMRRs I don't know how large they can get. I think I've seen
larger than single pages ones for graphics devices, but I don't
recall how big they were, or whether they were suitable aligned
to allow large page mappings.

But we should also have ARM (and ideally make this abstract
enough to even fit other architectures) in mind. Also remember
that someone already has a series somewhere to extend the
iommu_{,un}map_page() functions with an order parameter.

Jan


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

Re: [Xen-devel] [RFC PATCH 03/12] hvmloader: add function to query an emulated machine type (i440/Q35)

[Alexey G]

On Mon, 19 Mar 2018 12:56:51 +
Roger Pau Monné  wrote:

>On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote:
>> This adds a new function get_pc_machine_type() which allows to
>> determine the emulated chipset type. Supported return values:
>> 
>> - MACHINE_TYPE_I440
>> - MACHINE_TYPE_Q35
>> - MACHINE_TYPE_UNKNOWN, results in the error message being printed
>>   followed by calling BUG() in hvmloader.  
>
>This is not correct, the return values are strictly MACHINE_TYPE_I440
>or MACHINE_TYPE_Q35. Everything else ends up in a BUG().
>
>Also makes me wonder whether this should instead be init_machine_type,
>and users should just read machine_type directly.

Completely agree here, get_-style function should normally return a
value, not to perform extra checks and call BUG().

Renaming the function to init_machine_type() and replacing
get_pc_machine_type() usage to reading the machine_type (extern)
variable should be more clear (or, perhaps, one-line function to return
its value).

This way we can assume the machine type was successfully validated,
hence no need for additional checks for MACHINE_TYPE_UNKNOWN value (and
the MACHINE_TYPE_UNKNOWN itself).

>>  tools/firmware/hvmloader/pci_regs.h |  5 
>>  tools/firmware/hvmloader/util.c | 47
>> +
>> tools/firmware/hvmloader/util.h |  8 +++ 3 files changed, 60
>> insertions(+)
>> 
>> diff --git a/tools/firmware/hvmloader/pci_regs.h
>> b/tools/firmware/hvmloader/pci_regs.h index 7bf2d873ab..ba498b840e
>> 100644 --- a/tools/firmware/hvmloader/pci_regs.h
>> +++ b/tools/firmware/hvmloader/pci_regs.h

>> +static int machine_type = MACHINE_TYPE_UNDEFINED;  
>
>There's no need to init this, _UNDEFINED is 0 which is the default
>value.

Using the explicit initialization with the named constant here merely
improves readability. Comparing the enum-style variable later with
MACHINE_TYPE_UNDEFINED seems better than comparing it with 0. It's zero
difference for a compiler, but makes difference for a human. :)

Besides, it will be converted to enum type anyway, so some named entry
for the 'unassigned' value will be appropriate I think. 

>> +int get_pc_machine_type(void)  
>
>You introduce a function that's not used anywhere, and the commit log
>doesn't mention why this is needed at all. In general I prefer
>functions to be introduced with at least a caller, or else it needs to
>be described in the commit message why this is not the case.

There are multiple users, will merge the function with some
of its callers (Wei suggested the same).

>> +{
>> +uint16_t vendor_id;
>> +uint16_t device_id;
>> +
>> +if (machine_type != MACHINE_TYPE_UNDEFINED)
>> +return machine_type;
>> +
>> +machine_type = MACHINE_TYPE_UNKNOWN;
>> +
>> +vendor_id = pci_readw(0, PCI_VENDOR_ID);
>> +device_id = pci_readw(0, PCI_DEVICE_ID);
>> +
>> +/* only Intel platforms are emulated currently */
>> +if (vendor_id == PCI_VENDOR_ID_INTEL)  
>
>Should this maybe be a BUG_ON(vendor_id != PCI_VENDOR_ID_INTEL) then?
>Note that in this case you end up with a BUG later anyway.

Yes, this is intentional. Non-Intel vendor => unknown machine.

>> +{
>> +switch (device_id)
>> +{
>> +case PCI_DEVICE_ID_INTEL_82441:
>> +machine_type = MACHINE_TYPE_I440;
>> +printf("Detected i440 chipset\n");
>> +break;
>> +
>> +case PCI_DEVICE_ID_INTEL_Q35_MCH:
>> +machine_type = MACHINE_TYPE_Q35;
>> +printf("Detected Q35 chipset\n");
>> +break;
>> +
>> +default:
>> +break;
>> +}
>> +}
>> +
>> +if (machine_type == MACHINE_TYPE_UNKNOWN)
>> +{
>> +printf("Unknown emulated chipset encountered, VID=%04Xh,
>> DID=%04Xh\n",
>> +   vendor_id, device_id);
>> +BUG();  
>
>Why not place this in the default switch label? That would allow you
>to get rid of the MACHINE_TYPE_UNKNOWN define also.

This check outside the switch covers cases (Vendor is not Intel)
OR (Vendor is Intel but the host bridge is unknown).

I guess it can be moved into the switch, but it means there will
be two copies of printf(VID:DID)/BUG() block -- one for Vendor ID check,
second is for Device ID processing. Placing this check outside allows
to reuse it for both cases.

>> +}
>> +
>> +return machine_type;
>> +}
>> +
>>  static void validate_hvm_info(struct hvm_info_table *t)
>>  {
>>  uint8_t *ptr = (uint8_t *)t;
>> diff --git a/tools/firmware/hvmloader/util.h
>> b/tools/firmware/hvmloader/util.h index 7bca6418d2..7c77bedb00 100644
>> --- a/tools/firmware/hvmloader/util.h
>> +++ b/tools/firmware/hvmloader/util.h
>> @@ -100,6 +100,14 @@ void pci_write(uint32_t devfn, uint32_t reg,
>> uint32_t len, uint32_t val); #define pci_writew(devfn, reg, val)
>> pci_write(devfn, reg, 2, (uint16_t)(val)) #define pci_writel(devfn,
>> reg, val) pci_write(devfn, reg, 4, 

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

[Roger Pau Monné]

On Tue, Mar 13, 2018 at 04:33:52AM +1000, Alexey Gerasimenko wrote:
> Much like normal PCI BARs or other chipset-specific memory-mapped
> resources, MMCONFIG area needs space in MMIO hole, so we must allocate
> it manually.
> 
> The actual MMCONFIG size depends on a number of PCI buses available which
> should be covered by ECAM. Possible options are 64MB, 128MB and 256MB.
> As we are limited to the bus 0 currently, thus using lowest possible
> setting (64MB), #defined via PCI_MAX_MCFG_BUSES in hvmloader/config.h.
> When multiple PCI buses support for Xen will be implemented,
> PCI_MAX_MCFG_BUSES may be changed to calculation of the number of buses
> according to results of the PCI devices enumeration.
> 
> The way to allocate MMCONFIG range in MMIO hole is similar to how other
> PCI BARs are allocated. The patch extends 'bars' structure to make
> it universal for any arbitrary BAR type -- either IO, MMIO, ROM or
> a chipset-specific resource.

I'm not sure this is fully correct. The IOREQ interface can
differentiate PCI devices and forward config space accesses to
different emulators (see IOREQ_TYPE_PCI_CONFIG). With this change you
will forward all MCFG accesses to QEMU, which will likely be wrong if
there are multiple PCI-device emulators for the same domain.

Ie: AFAICT Xen needs to know about the MCFG emulation and detect
accesses to it in order to forward them to the right emulators.

Adding Paul who knows more about all this.

> One important new field is addr_mask, which tells which bits of the base
> address can (should) be written. Different address types (ROM, MMIO BAR,
> PCIEXBAR) will have different addr_mask values.
> 
> For every assignable BAR range we store its size, PCI device BDF (devfn
> actually) to which it belongs, BAR type (mem/io/mem64) and corresponding
> register offset in device PCI conf space. This way we can insert MMCONFIG
> entry into bars array in the same manner like for any other BARs. In this
> case, the devfn field will point to MCH PCI device and bar_reg will
> contain PCIEXBAR register offset. It will be assigned a slot in MMIO hole
> later in a very same way like for plain PCI BARs, with respect to its size
> alignment.
> 
> Also, to reduce code complexity, all long mem/mem64 BAR flags checks are
> replaced by simple bars[i] field probing, eg.:
> -if ( (bar_reg == PCI_ROM_ADDRESS) ||
> - ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> -  PCI_BASE_ADDRESS_SPACE_MEMORY) )
> +if ( bars[i].is_mem )

This should be a separate change IMO.

> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/firmware/hvmloader/config.h   |   4 ++
>  tools/firmware/hvmloader/pci.c  | 127 
> 
>  tools/firmware/hvmloader/pci_regs.h |   2 +
>  3 files changed, 106 insertions(+), 27 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/config.h 
> b/tools/firmware/hvmloader/config.h
> index 6fde6b7b60..5443ecd804 100644
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -53,10 +53,14 @@ extern uint8_t ioapic_version;
>  #define PCI_ISA_DEVFN   0x08/* dev 1, fn 0 */
>  #define PCI_ISA_IRQ_MASK0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
>  #define PCI_ICH9_LPC_DEVFN  0xf8/* dev 31, fn 0 */
> +#define PCI_MCH_DEVFN   0   /* bus 0, dev 0, func 0 */
>  
>  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
>  #define PCI_MEM_END 0xfc00
>  
> +/* possible values are: 64, 128, 256 */
> +#define PCI_MAX_MCFG_BUSES  64

What the reasoning for this value? Do we know which devices need ECAM
areas?

> +
>  #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
>  
>  extern unsigned long pci_mem_start, pci_mem_end;
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index 033bd20992..6de124bbd5 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -158,9 +158,10 @@ static void class_specific_pci_device_setup(uint16_t 
> vendor_id,
>  
>  void pci_setup(void)
>  {
> -uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> +uint8_t is_64bar, using_64bar, bar64_relocate = 0, is_mem;
>  uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
>  uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> +uint64_t addr_mask;
>  uint16_t vendor_id, device_id;
>  unsigned int bar, pin, link, isa_irq;
>  int is_running_on_q35 = 0;
> @@ -172,10 +173,14 @@ void pci_setup(void)
>  
>  /* Create a list of device BARs in descending order of size. */
>  struct bars {
> -uint32_t is_64bar;
>  uint32_t devfn;
>  uint32_t bar_reg;
>  uint64_t bar_sz;
> +uint64_t addr_mask; /* which bits of the base address can be written 
> */
> +uint32_t bar_data;  /* initial value - BAR flags here */
> +uint8_t  is_64bar;
> +uint8_t  is_mem;
> +uint8_t  padding[2];

Why are you manually 

[Xen-devel] [xen-4.6-testing test] 120897: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  broken in 
120734
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
119227

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken in 
120734 pass in 120897
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 120734 pass 
in 120897
 test-xtf-amd64-amd64-1   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120734
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 120734
 test-xtf-amd64-amd64-3   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120830
 test-amd64-i386-freebsd10-i386 15 guest-localmigrate   fail pass in 120830

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 120734 like 
119227
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 120830 like 
119187
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 120830 like 
119227
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 120830 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 120830 never pass
 test-xtf-amd64-amd64-2  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119187
 test-armhf-armhf-xl-rtds 12 guest-start  fail  like 119227
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119227
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119227
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119227
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119227
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119227
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119227
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119227
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119227
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   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-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   76 xtf/test-pv32pae-xsa-194 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-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  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  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 

[Xen-devel] [RFC Patch] Make Security Policy Doc ready to become a CNA

[Lars Kurth]

This contains a proposal to change https://xenproject.org/security-policy.html 
such 
that it points to SUPPORT.md. Having scope and process information is necessary
to become a CNA. This is the last piece, before formally asking to become a CNA.

To make the review of this easier, I based it on xenbits:/larsk/governance.git

Note that I still need to fix the final URL and also add the change to the
changelog.   

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

Re: [Xen-devel] [PATCH v2 31/45] ARM: new VGIC: Add SGIR register handler

[Andre Przywara]

Hi,

On 19/03/18 09:47, Julien Grall wrote:
> Hi Andre,
> 
> On 03/15/2018 08:30 PM, Andre Przywara wrote:
>> 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 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..7e17cdc2ad 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, 0);  /* limit to
>> existing VCPUs */
> 
> Shouldn't it be 'nr_vcpus - 1'?

D'oh! Indeed looks like it.
Thanks for catching this!

Cheers,
Andre.

>> +    break;
>> +    case GICD_SGI_TARGET_OTHERS:
>> +    targets = GENMASK(nr_vcpus, 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;
>> +    }
> 
> Cheers,
> 

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

Re: [Xen-devel] [PATCH v10 07/11] vpci/bars: add handlers to map the BARs

[Jan Beulich]

>>> On 16.03.18 at 14:30,  wrote:
> +static int map_range(unsigned long s, unsigned long e, void *data,
> + unsigned long *c)
> +{
> +const struct map_data *map = data;
> +int rc;
> +
> +for ( ; ; )
> +{
> +unsigned long size = e - s + 1;
> +
> +/*
> + * ARM TODOs:
> + * - On ARM whether the memory is prefetchable or not should be 
> passed
> + *   to map_mmio_regions in order to decide which memory attributes
> + *   should be used.
> + *
> + * - {un}map_mmio_regions doesn't support preemption.
> + */
> +
> +rc = (map->map ? map_mmio_regions : unmap_mmio_regions)
> + (map->d, _gfn(s), size, _mfn(s));

This, btw, is one of those instances where a pair of direct calls
may end up being translated to an indirect one by the compiler.
Despite growing redundancy in source if you address that, I
think I agree with Andrew that we'd prefer to avoid the indirect
call here.

> +bool vpci_process_pending(struct vcpu *v)
> +{
> +if ( v->vpci.mem )
> +{
> +struct map_data data = {
> +.d = v->domain,
> +.map = v->vpci.map,
> +};
> +int rc = rangeset_consume_ranges(v->vpci.mem, map_range, );
> +
> +if ( rc == -ERESTART )
> +return true;
> +
> +spin_lock(>vpci.pdev->vpci->lock);
> +/* Disable memory decoding unconditionally on failure. */
> +modify_decoding(v->vpci.pdev, rc ? false : v->vpci.map,
> +rc ? false : v->vpci.rom_only);

These two ternary expressions could be simplified to "!rc && ..."
afaict.

> +static int __init apply_map(struct domain *d, struct pci_dev *pdev,
> +struct rangeset *mem)
> +{
> +struct map_data data = { .d = d, .map = true };
> +int rc;
> +
> +while ( (rc = rangeset_consume_ranges(mem, map_range, )) == 
> -ERESTART )
> +process_pending_softirqs();
> +rangeset_destroy(mem);
> +if ( rc )
> +return rc;
> +modify_decoding(pdev, true, false);
> +
> +return rc;
> +}

if ( !rc )
modify_decoding(pdev, true, false);

return rc;

would make this function have just a single return point without
adversely affecting readability.

> +static int modify_bars(const struct pci_dev *pdev, bool map, bool rom_only)
> +{
> +struct vpci_header *header = >vpci->header;
> +struct rangeset *mem = rangeset_new(NULL, NULL, 0);
> +struct pci_dev *tmp, *dev = NULL;
> +unsigned int i;
> +int rc;
> +
> +if ( !mem )
> +return -ENOMEM;
> +
> +/*
> + * Create a rangeset that represents the current device BARs memory 
> region
> + * and compare it against all the currently active BAR memory regions. If
> + * an overlap is found, subtract it from the region to be 
> mapped/unmapped.
> + *
> + * First fill the rangeset with all the BARs of this device or with the 
> ROM
> + * BAR only, depending on whether the guest is toggling the memory decode
> + * bit of the command register, or the enable bit of the ROM BAR 
> register.
> + */
> +for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
> +{
> +const struct vpci_bar *bar = >bars[i];
> +
> +if ( !MAPPABLE_BAR(bar) ||
> + (rom_only ? bar->type != VPCI_BAR_ROM
> +   : (bar->type == VPCI_BAR_ROM && 
> !header->rom_enabled)) )
> +continue;
> +
> +rc = rangeset_add_range(mem, PFN_DOWN(bar->addr),
> +PFN_DOWN(bar->addr + bar->size - 1));
> +if ( rc )
> +{
> +printk(XENLOG_G_WARNING
> +   "Failed to add [%" PRI_gfn ", %" PRI_gfn "]: %d\n",
> +   PFN_DOWN(bar->addr), PFN_DOWN(bar->addr + bar->size - 1),
> +   rc);
> +rangeset_destroy(mem);
> +return rc;
> +}
> +}
> +
> +/*
> + * Check for overlaps with other BARs. Note that only BARs that are
> + * currently mapped (enabled) are checked for overlaps.
> + */
> +list_for_each_entry(tmp, >domain->arch.pdev_list, domain_list)
> +{
> +if ( tmp == pdev )
> +{
> +/*
> + * Need to store the device so it's not constified and
> + * maybe_defer_map can modify it in case of error.
> + */
> +dev = tmp;

There's no maybe_defer_map anymore.

And then I'm having a problem with this comment on const-ness:
apply_map() only wants to hand the device to modify_decoding(),
whose respective argument is const. defer_map() stores the
pointer, but afaics again only for vpci_process_pending() to hand
it on to modify_decoding(); the lock the function takes is in a
structure pointed to from the device, so unaffected by the const.

> +if ( !rom_only )
> +/*
> + * If memory decoding is toggled 

Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 March 2018 15:14
> To: Paul Durrant 
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org; Konrad Rzeszutek
> Wilk ; Tim (Xen.org) 
> Subject: Re: [PATCH 6/7] x86: add iommu_op to query reserved ranges
> 
> >>> On 12.02.18 at 11:47,  wrote:
> > --- a/xen/arch/x86/iommu_op.c
> > +++ b/xen/arch/x86/iommu_op.c
> > @@ -22,6 +22,58 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +
> > +struct get_rdm_ctxt {
> > +unsigned int max_entries;
> > +unsigned int nr_entries;
> > +XEN_GUEST_HANDLE(xen_iommu_reserved_region_t) regions;
> > +};
> > +
> > +static int get_rdm(xen_pfn_t start, xen_ulong_t nr, u32 id, void *arg)
> > +{
> > +struct get_rdm_ctxt *ctxt = arg;
> > +
> > +if ( ctxt->nr_entries < ctxt->max_entries )
> > +{
> > +xen_iommu_reserved_region_t region = {
> > +.start_bfn = start,
> > +.nr_frames = nr,
> > +};
> > +
> > +if ( copy_to_guest_offset(ctxt->regions, ctxt->nr_entries, ,
> > +  1) )
> > +return -EFAULT;
> > +}
> > +
> > +ctxt->nr_entries++;
> > +
> > +return 1;
> > +}
> > +
> > +static int iommuop_query_reserved(struct
> xen_iommu_op_query_reserved *op)
> > +{
> > +struct get_rdm_ctxt ctxt = {
> > +.max_entries = op->nr_entries,
> > +.regions = op->regions,
> > +};
> > +int rc;
> > +
> > +if (op->pad != 0)
> > +return -EINVAL;
> > +
> > +rc = iommu_get_reserved_device_memory(get_rdm, );
> > +if ( rc )
> > +return rc;
> > +
> > +/* Pass back the actual number of reserved regions */
> > +op->nr_entries = ctxt.nr_entries;
> > +
> > +if ( ctxt.nr_entries > ctxt.max_entries )
> > +return -ENOBUFS;
> > +
> > +return 0;
> > +}
> 
> One more note here: As it looks we can only hope there won't be
> too many RMRRs, as the number of entries that can be requested
> here is basically unbounded.
> 

The caller has to be able to allocate a buffer large enough but, yes there is 
no explicit limit. I'll add pre-empt checks.

  Paul

> Jan


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

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 March 2018 15:12
> To: Paul Durrant 
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org; Konrad Rzeszutek
> Wilk ; Tim (Xen.org) 
> Subject: Re: [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and
> also to flush the IOTLB
> 
> >>> On 12.02.18 at 11:47,  wrote:
> > This patch adds iommu_ops to allow a domain with control_iommu
> privilege
> > to map and unmap pages from any guest over which it has mapping
> privilege
> > in the IOMMU.
> > These operations implicitly disable IOTLB flushing so that the caller can
> > batch operations and then explicitly flush the IOTLB using the iommu_op
> > also added by this patch.
> 
> Can't this be abused for unmaps?

Hmm. I think we're ok. The calls just play with the CPU local flush disable 
flag so they should only disable anything resulting from the current hypercall. 
Manipulation of other IOMMU page tables (on behalf of other domains) should not 
be affected AFAICT. I'll double check though.

> 
> > --- a/xen/arch/x86/iommu_op.c
> > +++ b/xen/arch/x86/iommu_op.c
> > @@ -24,6 +24,174 @@
> >  #include 
> >  #include 
> >
> > +/* Override macros from asm/page.h to make them work with mfn_t */
> > +#undef mfn_to_page
> > +#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
> > +#undef page_to_mfn
> > +#define page_to_mfn(page) _mfn(__page_to_mfn(page))
> 
> I guess with Julien's this needs to go away, but it looks like his
> series hasn't landed yet.
> 

Yes, I'll remove this once that happens.

> > +struct check_rdm_ctxt {
> > +bfn_t bfn;
> > +};
> > +
> > +static int check_rdm(xen_pfn_t start, xen_ulong_t nr, u32 id, void *arg)
> 
> uint32_t
> 

Yep.

> > +{
> > +struct check_rdm_ctxt *ctxt = arg;
> > +
> > +if ( bfn_x(ctxt->bfn) >= start &&
> > + bfn_x(ctxt->bfn) < start + nr )
> > +return -EINVAL;
> 
> Something more distinguishable than EINVAL would certainly be
> nice here. Also how come this check does not depend on the
> domain? Only RMRRs of devices owned by a domain are relevant
> in the BFN range (unless I still didn't fully understand how BFN is
> meant to be different from GFN and MFN).
> 

I thought that the reserved range check was only for the current domain's 
mappings (optionally limited to a single initiator), but I could be wrong. I'll 
check.

> > +static int iommuop_map(struct xen_iommu_op_map *op, unsigned int
> flags)
> > +{
> > +struct domain *d, *od, *currd = current->domain;
> > +struct domain_iommu *iommu = dom_iommu(currd);
> > +const struct iommu_ops *ops = iommu->platform_ops;
> > +domid_t domid = op->domid;
> > +gfn_t gfn = _gfn(op->gfn);
> > +bfn_t bfn = _bfn(op->bfn);
> > +mfn_t mfn;
> > +struct check_rdm_ctxt ctxt = {
> > +.bfn = bfn,
> > +};
> > +p2m_type_t p2mt;
> > +p2m_query_t p2mq;
> > +struct page_info *page;
> > +unsigned int prot;
> > +int rc;
> > +
> > +if (op->pad0 != 0 || op->pad1 != 0)
> 
> Missing blanks again (and please again consider dropping the " != 0").
> 
> > +return -EINVAL;
> > +
> > +/*
> > + * Both map_page and lookup_page operations must be implemented.
> > + * The lookup_page method is not used here but is relied upon by
> > + * iommuop_unmap() to drop the page reference taken here.
> > + */
> > +if ( !ops->map_page || !ops->lookup_page )
> > +return -ENOSYS;
> 
> EOPNOTSUPP (also further down)
> 

I wanted the 'not implemented' case to be distinct from the 'not supported 
because of some configuration detail' case, which is why I chose ENOSYS. I'll 
change it if you don't think that matters though.

> Also how about the unmap hook? If that's not implemented, how
> would the page ref obtained below ever be dropped again? Or
> you may need to re-order the unmap side code.

Ok. I'll just check for all map, unmap and lookup in both cases.

> 
> > +/* Check whether the specified BFN falls in a reserved region */
> > +rc = iommu_get_reserved_device_memory(check_rdm, );
> > +if ( rc )
> > +return rc;
> > +
> > +d = rcu_lock_domain_by_any_id(domid);
> > +if ( !d )
> > +return -ESRCH;
> > +
> > +p2mq = (flags & XEN_IOMMUOP_map_readonly) ?
> > +P2M_UNSHARE : P2M_ALLOC;
> 
> Isn't this the wrong way round?
> 

I don't think so. If we're doing a readonly mapping then the page should not be 
forcibly populated, right?

> > +page = get_page_from_gfn(d, gfn_x(gfn), , p2mq);
> > +
> > +rc = -ENOENT;
> > +if ( !page )
> > +goto unlock;
> > +
> > +if ( p2m_is_paged(p2mt) )
> > +{
> > +p2m_mem_paging_populate(d, gfn_x(gfn));
> > +goto 

Re: [Xen-devel] [RFC PATCH 06/12] hvmloader: add basic Q35 support

[Roger Pau Monné]

On Tue, Mar 13, 2018 at 04:33:51AM +1000, Alexey Gerasimenko wrote:
> This patch does following:
> 
> 1. Move PCI-device specific initialization out of pci_setup function
> to the newly created class_specific_pci_device_setup function to simplify
> code.
> 
> 2. PCI-device specific initialization extended with LPC controller
> initialization
> 
> 3. Initialize PIRQA...{PIRQD, PIRQH} routing accordingly to the emulated
> south bridge (either located on PCI_ISA_DEVFN or PCI_ICH9_LPC_DEVFN).
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/firmware/hvmloader/config.h |   1 +
>  tools/firmware/hvmloader/pci.c| 162 
> --
>  2 files changed, 104 insertions(+), 59 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/config.h 
> b/tools/firmware/hvmloader/config.h
> index 6e00413f2e..6fde6b7b60 100644
> --- a/tools/firmware/hvmloader/config.h
> +++ b/tools/firmware/hvmloader/config.h
> @@ -52,6 +52,7 @@ extern uint8_t ioapic_version;
>  
>  #define PCI_ISA_DEVFN   0x08/* dev 1, fn 0 */
>  #define PCI_ISA_IRQ_MASK0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
> +#define PCI_ICH9_LPC_DEVFN  0xf8/* dev 31, fn 0 */
>  
>  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
>  #define PCI_MEM_END 0xfc00
> diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
> index 0b708bf578..033bd20992 100644
> --- a/tools/firmware/hvmloader/pci.c
> +++ b/tools/firmware/hvmloader/pci.c
> @@ -35,6 +35,7 @@ unsigned long pci_mem_end = PCI_MEM_END;
>  uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
>  
>  enum virtual_vga virtual_vga = VGA_none;
> +uint32_t vga_devfn = 256;

uint8_t should be enough to store a devfn. Also this should be static
maybe?

>  unsigned long igd_opregion_pgbase = 0;
>  
>  /* Check if the specified range conflicts with any reserved device memory. */
> @@ -76,14 +77,93 @@ static int find_next_rmrr(uint32_t base)
>  return next_rmrr;
>  }
>  
> +#define SCI_EN_IOPORT  (ACPI_PM1A_EVT_BLK_ADDRESS_V1 + 0x30)
> +#define GBL_SMI_EN  (1 << 0)
> +#define APMC_EN (1 << 5)

Alignment.

> +
> +static void class_specific_pci_device_setup(uint16_t vendor_id,
> +uint16_t device_id,
> +uint8_t bus, uint8_t devfn)
> +{
> +uint16_t class;
> +
> +class = pci_readw(devfn, PCI_CLASS_DEVICE);
> +
> +switch ( class )

switch ( pci_readw(devfn, PCI_CLASS_DEVICE) ) ?

I don't see class being used elsewhere.

Also why is vendor_id/device_id provided by the caller but not class?
It seems kind of pointless.

Why not fetch vendor/device from the function itself and move the
(vendor_id == 0x) && (device_id == 0x) check inside the
function?

Also in this case I think it would be better to have a non-functional
patch that introduces class_specific_pci_device_setup and a second
patch that adds support for ICH9.

Having code movement and new code in the same patch makes it harder to
very what you are actually moving vs introducing.

> +{
> +case 0x0300:

All this values need to be defines documented somewhere.

> +/* If emulated VGA is found, preserve it as primary VGA. */
> +if ( (vendor_id == 0x1234) && (device_id == 0x) )
> +{
> +vga_devfn = devfn;
> +virtual_vga = VGA_std;
> +}
> +else if ( (vendor_id == 0x1013) && (device_id == 0xb8) )
> +{
> +vga_devfn = devfn;
> +virtual_vga = VGA_cirrus;
> +}
> +else if ( virtual_vga == VGA_none )
> +{
> +vga_devfn = devfn;
> +virtual_vga = VGA_pt;
> +if ( vendor_id == 0x8086 )
> +{
> +igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
> +/*
> + * Write the the OpRegion offset to give the opregion
> + * address to the device model. The device model will trap
> + * and map the OpRegion at the give address.
> + */
> +pci_writel(vga_devfn, PCI_INTEL_OPREGION,
> +   igd_opregion_pgbase << PAGE_SHIFT);
> +}
> +}
> +break;
> +
> +case 0x0680:
> +/* PIIX4 ACPI PM. Special device with special PCI config space. */
> +ASSERT((vendor_id == 0x8086) && (device_id == 0x7113));
> +pci_writew(devfn, 0x20, 0x); /* No smb bus IO enable */
> +pci_writew(devfn, 0xd2, 0x); /* No smb bus IO enable */
> +pci_writew(devfn, 0x22, 0x);
> +pci_writew(devfn, 0x3c, 0x0009); /* Hardcoded IRQ9 */
> +pci_writew(devfn, 0x3d, 0x0001);
> +pci_writel(devfn, 0x40, ACPI_PM1A_EVT_BLK_ADDRESS_V1 | 1);
> +pci_writeb(devfn, 0x80, 0x01); /* enable PM io space */
> +break;
> +
> +case 0x0601:
> +/* LPC bridge */
> +if 

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

[Alexandru Stefan ISAILA]

On Lu, 2018-03-19 at 14:22 +, Andrew Cooper wrote:
> On 19/03/18 14:07, Alexandru Isaila wrote:
> > 
> > -case VMEXIT_EXCEPTION_BP:
> > -inst_len = __get_instruction_length(v, INSTR_INT3);
> > +case VMEXIT_EXCEPTION_BP:;
> > +inst_len = vmcb->nextrip - vmcb->rip;
> Sorry, but no.  This will break on older AMD hardware.  You must
> retain
> the __get_instruction_length().
> 
> NextRIP support was only introduced in Gen2 SVM, and we still support
> Gen1.
> 
> ~Andrew
Yes, you are right, I will re-use the __get_instruction_length() and
add support for the ICEBP instruction fort the next version of the
patch. Just did some tests and it works fine for the int3/int $3
instruction length.

Thanks for the heads-up. 

~Alex 
> 
> 
> This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[Daniel Vetter]

On Mon, Mar 19, 2018 at 3:19 PM, Oleksandr Andrushchenko
 wrote:
> On 03/19/2018 03:51 PM, Daniel Vetter wrote:
>>
>> On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:
>>>
>>> Hi, Daniel!
>>> Sorry, if I strip the patch too much below.
>>>
>>> On 03/16/2018 10:23 AM, Daniel Vetter wrote:

 S-o-b line went missing here :-)
>>>
>>> will restore it back ;)

 I've read through it, 2 actual review comments (around hot-unplug and
 around the error recovery for failed flips), a few bikesheds, but looks
 all reasonable to me. And much easier to read as one big patch (it's
 just
 3k).

 One more thing I'd do as a follow-up (don't rewrite everything, this is
 close to merge, better to get it in first): You have a lot of
 indirections
 and function calls across sources files. That's kinda ok if you have a
 huge driver with 100+k lines of code where you have to split things up.
 But for a small driver like yours here it's a bit overkill.
>>>
>>> will review and try to rework after the driver is in
>
> I'll probably merge xen_drm_front_drv.c and xen_drm_front.c now as
> anyway I have to re-work driver unloading, e.g. "fishy" code below.

 Personally I'd merge at least the xen backend stuff into the
 corresponding
 kms code, but that's up to you.
>>>
>>> I prefer to have it in smaller chunks and all related code at
>>> one place, so it is easier to maintain. That is why I didn't
>>> plumb frontend <-> backend code right into the KMS code.

 And as mentioned, if you decide to do
 that, a follow-up patch (once this has merged) is perfectly fine.
>>>
>>> Ok, after the merge
>>
>> If you prefer your current layout, then pls keep it. Bikeshed = personal
>> style nit, feel free to ignore if you like stuff differently. In the end
>> it's your driver, not mine, and I can easily navigate the current code
>> (with a few extra jumps).
>
> Some of the indirections will be removed by merging
> xen_drm_front_drv.c and xen_drm_front.c. Are these what you
> mean or is there anything else?
>
>> -Daniel
>>
 -Daniel

> +int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info
> *front_info,
> +   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
> +   uint32_t bpp, uint64_t size, struct sg_table *sgt)
> +{
> +   return be_dbuf_create_int(front_info, dbuf_cookie, width,
> height,
> +   bpp, size, NULL, sgt);
> +}
> +
> +int xen_drm_front_dbuf_create_from_pages(struct xen_drm_front_info
> *front_info,
> +   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
> +   uint32_t bpp, uint64_t size, struct page **pages)
> +{
> +   return be_dbuf_create_int(front_info, dbuf_cookie, width,
> height,
> +   bpp, size, pages, NULL);
> +}

 The above two wrappers seem a bit much, just to set sgt = NULL or pages
 =
 NULL in one of them. I'd drop them, but that's a bikeshed so feel free
 to
 ignore.
>>>
>>> I had that the way you say in some of the previous implementations,
>>> but finally decided to have these dummy wrappers: seems
>>> to be cleaner this way
>
> +static void displback_disconnect(struct xen_drm_front_info
> *front_info)
> +{
> +   bool removed = true;
> +
> +   if (front_info->drm_pdev) {
> +   if (xen_drm_front_drv_is_used(front_info->drm_pdev)) {
> +   DRM_WARN("DRM driver still in use, deferring
> removal\n");
> +   removed = false;
> +   } else
> +   xen_drv_remove_internal(front_info);

 Ok this logic here is fishy, since you're open-coding the drm unplug
 infrastructure, but slightly differently and slightyl racy. If you have
 a
 driver where your underlying "hw" (well it's virtual here, but same
 idea)
 can disappear any time while userspace is still using the drm driver,
 you
 need to use the drm_dev_unplug() function and related code.
 drm_dev_unplug() works like drm_dev_unregister, except for the hotplug
 case.

 Then you also have to guard all the driver entry points where you do
 access the backchannel using drm_dev_is_unplugged() (I've seen a few of
 those already). Then you can rip out all the logic here and the
 xen_drm_front_drv_is_used() helper.
>>>
>>> Will rework it with drm_dev_unplug, thank you

 I thought there's some patches from Noralf in-flight that improved the
 docs on this, I need to check
>
> Yes, I will definitely use those as soon as they are available.
> But at the moment let me clarify a bit on the use-cases for driver
> unplugging and backend disconnection.
>
> The backend, by disconnecting, expects full DRM driver teardown, because,
> for 

Re: [Xen-devel] [PATCH 5/5] hvmloader: Use iPXE ROM loaded from a standalone file

[Jan Beulich]

>>> On 19.03.18 at 15:24,  wrote:
> On 16/03/18 11:26, Jan Beulich wrote:
>>>
>>> +/* Physical address of iPXE ROM, loaded by domain builder
>>> + * when using ROMBIOS
>>> + */
>>> +unsigned int *ipxe_rom_addresss;
>> Comment style. And can the pointer be to const?
> 
> I will fixup the comment style and but making ipxe_rom_address a pointer 
> to const will require codes changes in hvmloader/rombios.c, 
> hvmloader/optionroms.c to make all function that use ipxe_rom_address 
> const as well. Are you fine with changing these files/functions.

In a separate patch, yes. If you don't want to create a separate
patch, I'm also fine with your explanation of why it can't be const
for now.

Jan


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

Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges

[Jan Beulich]

>>> On 12.02.18 at 11:47,  wrote:
> --- a/xen/arch/x86/iommu_op.c
> +++ b/xen/arch/x86/iommu_op.c
> @@ -22,6 +22,58 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +struct get_rdm_ctxt {
> +unsigned int max_entries;
> +unsigned int nr_entries;
> +XEN_GUEST_HANDLE(xen_iommu_reserved_region_t) regions;
> +};
> +
> +static int get_rdm(xen_pfn_t start, xen_ulong_t nr, u32 id, void *arg)
> +{
> +struct get_rdm_ctxt *ctxt = arg;
> +
> +if ( ctxt->nr_entries < ctxt->max_entries )
> +{
> +xen_iommu_reserved_region_t region = {
> +.start_bfn = start,
> +.nr_frames = nr,
> +};
> +
> +if ( copy_to_guest_offset(ctxt->regions, ctxt->nr_entries, ,
> +  1) )
> +return -EFAULT;
> +}
> +
> +ctxt->nr_entries++;
> +
> +return 1;
> +}
> +
> +static int iommuop_query_reserved(struct xen_iommu_op_query_reserved *op)
> +{
> +struct get_rdm_ctxt ctxt = {
> +.max_entries = op->nr_entries,
> +.regions = op->regions,
> +};
> +int rc;
> +
> +if (op->pad != 0)
> +return -EINVAL;
> +
> +rc = iommu_get_reserved_device_memory(get_rdm, );
> +if ( rc )
> +return rc;
> +
> +/* Pass back the actual number of reserved regions */
> +op->nr_entries = ctxt.nr_entries;
> +
> +if ( ctxt.nr_entries > ctxt.max_entries )
> +return -ENOBUFS;
> +
> +return 0;
> +}

One more note here: As it looks we can only hope there won't be
too many RMRRs, as the number of entries that can be requested
here is basically unbounded.

Jan


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

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

[Jan Beulich]

>>> On 12.02.18 at 11:47,  wrote:
> This patch adds iommu_ops to allow a domain with control_iommu privilege
> to map and unmap pages from any guest over which it has mapping privilege
> in the IOMMU.
> These operations implicitly disable IOTLB flushing so that the caller can
> batch operations and then explicitly flush the IOTLB using the iommu_op
> also added by this patch.

Can't this be abused for unmaps?

> --- a/xen/arch/x86/iommu_op.c
> +++ b/xen/arch/x86/iommu_op.c
> @@ -24,6 +24,174 @@
>  #include 
>  #include 
>  
> +/* Override macros from asm/page.h to make them work with mfn_t */
> +#undef mfn_to_page
> +#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
> +#undef page_to_mfn
> +#define page_to_mfn(page) _mfn(__page_to_mfn(page))

I guess with Julien's this needs to go away, but it looks like his
series hasn't landed yet.

> +struct check_rdm_ctxt {
> +bfn_t bfn;
> +};
> +
> +static int check_rdm(xen_pfn_t start, xen_ulong_t nr, u32 id, void *arg)

uint32_t

> +{
> +struct check_rdm_ctxt *ctxt = arg;
> +
> +if ( bfn_x(ctxt->bfn) >= start &&
> + bfn_x(ctxt->bfn) < start + nr )
> +return -EINVAL;

Something more distinguishable than EINVAL would certainly be
nice here. Also how come this check does not depend on the
domain? Only RMRRs of devices owned by a domain are relevant
in the BFN range (unless I still didn't fully understand how BFN is
meant to be different from GFN and MFN).

> +static int iommuop_map(struct xen_iommu_op_map *op, unsigned int flags)
> +{
> +struct domain *d, *od, *currd = current->domain;
> +struct domain_iommu *iommu = dom_iommu(currd);
> +const struct iommu_ops *ops = iommu->platform_ops;
> +domid_t domid = op->domid;
> +gfn_t gfn = _gfn(op->gfn);
> +bfn_t bfn = _bfn(op->bfn);
> +mfn_t mfn;
> +struct check_rdm_ctxt ctxt = {
> +.bfn = bfn,
> +};
> +p2m_type_t p2mt;
> +p2m_query_t p2mq;
> +struct page_info *page;
> +unsigned int prot;
> +int rc;
> +
> +if (op->pad0 != 0 || op->pad1 != 0)

Missing blanks again (and please again consider dropping the " != 0").

> +return -EINVAL;
> +
> +/*
> + * Both map_page and lookup_page operations must be implemented.
> + * The lookup_page method is not used here but is relied upon by
> + * iommuop_unmap() to drop the page reference taken here.
> + */
> +if ( !ops->map_page || !ops->lookup_page )
> +return -ENOSYS;

EOPNOTSUPP (also further down)

Also how about the unmap hook? If that's not implemented, how
would the page ref obtained below ever be dropped again? Or
you may need to re-order the unmap side code.

> +/* Check whether the specified BFN falls in a reserved region */
> +rc = iommu_get_reserved_device_memory(check_rdm, );
> +if ( rc )
> +return rc;
> +
> +d = rcu_lock_domain_by_any_id(domid);
> +if ( !d )
> +return -ESRCH;
> +
> +p2mq = (flags & XEN_IOMMUOP_map_readonly) ?
> +P2M_UNSHARE : P2M_ALLOC;

Isn't this the wrong way round?

> +page = get_page_from_gfn(d, gfn_x(gfn), , p2mq);
> +
> +rc = -ENOENT;
> +if ( !page )
> +goto unlock;
> +
> +if ( p2m_is_paged(p2mt) )
> +{
> +p2m_mem_paging_populate(d, gfn_x(gfn));
> +goto release;
> +}
> +
> +if ( (p2mq & P2M_UNSHARE) && p2m_is_shared(p2mt) )
> +goto release;

Same for this check then?

> +/*
> + * Make sure the page is RAM and, if it is read-only, that the
> + * read-only flag is present.
> + */
> +rc = -EPERM;
> +if ( !p2m_is_any_ram(p2mt) ||
> + (p2m_is_readonly(p2mt) && !(flags & XEN_IOMMUOP_map_readonly)) )
> +goto release;

Don't you also need to obtain a PGT_writable reference in the
"not r/o" case?

> +/*
> + * If the calling domain does not own the page then make sure it
> + * has mapping privilege over the page owner.
> + */
> +od = page_get_owner(page);
> +if ( od != currd )
> +{
> +rc = xsm_domain_memory_map(XSM_TARGET, od);
> +if ( rc )
> +goto release;
> +}

With XSM_TARGET I don't see the point of the if() around here.
Perhaps simply

rc = xsm_domain_memory_map(XSM_TARGET, page_get_owner(page));

?

> +static int iommuop_unmap(struct xen_iommu_op_unmap *op)
> +{
> +struct domain *currd = current->domain;
> +struct domain_iommu *iommu = dom_iommu(currd);
> +const struct iommu_ops *ops = iommu->platform_ops;
> +bfn_t bfn = _bfn(op->bfn);
> +mfn_t mfn;
> +struct check_rdm_ctxt ctxt = {
> +.bfn = bfn,
> +};
> +unsigned int flags;
> +struct page_info *page;
> +int rc;
> +
> +/*
> + * Both unmap_page and lookup_page operations must be implemented.
> + */

Single line comment (there are more below).

> +if ( !ops->unmap_page || !ops->lookup_page )
> +return -ENOSYS;
> +
> +/* Check whether the specified BFN falls in a 

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

[Alexey G]

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.

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?

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

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

[Razvan Cojocaru]

On 03/19/2018 04:48 PM, Tamas K Lengyel wrote:
> On Mon, Mar 19, 2018 at 8:07 AM, Alexandru Isaila
>  wrote:
>> At this moment the Debug events for the AMD architecture are not
>> forwarded to the monitor layer.
>>
>> This patch adds the Debug event to the common capabilities, adds
>> the VMEXIT_ICEBP then forwards the event to the monitor layer.
>>
>> Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1
>> exception generated by the single byte INT1
>> instruction (also known as ICEBP) does not trigger the #DB
>> intercept. Software should use the dedicated ICEBP
>> intercept to intercept ICEBP"
>>
>> Signed-off-by: Alexandru Isaila 
>> ---
>>  xen/arch/x86/hvm/svm/svm.c| 41 +
>>  xen/arch/x86/hvm/svm/vmcb.c   |  2 +-
>>  xen/include/asm-x86/monitor.h |  4 ++--
>>  3 files changed, 32 insertions(+), 15 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> index c34f5b5..aa1feaa 100644
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1109,7 +1109,8 @@ static void noreturn svm_do_resume(struct vcpu *v)
>>  {
>>  struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>>  bool debug_state = (v->domain->debugger_attached ||
>> -
>> v->domain->arch.monitor.software_breakpoint_enabled);
>> +v->domain->arch.monitor.software_breakpoint_enabled 
>> ||
>> +v->domain->arch.monitor.debug_exception_enabled);
> 
> I'm not sure this should be bundled under "debug_exception", on Intel
> this event type usually gets you things like singlestepping. To me
> ICEBP sounds like it would better fit under "software_breakpoint".
> Thoughts?
I also found it a bit curious that ICEBP is under the DEBUG vmexit with
VMX/Intel, but that's how it currently goes (you can see this easily by
running the swint-emulation XTF test). Xen-access will get this as a
debug (not breakpoint) event.

So if we move this, we'd need to also move it on VMX, for consistency.


Thanks,
Razvan

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

Re: [Xen-devel] [RFC PATCH 05/12] hvmloader: add Q35 DSDT table loading

[Roger Pau Monné]

On Tue, Mar 13, 2018 at 04:33:50AM +1000, Alexey Gerasimenko wrote:
> Allows to select Q35 DSDT table in hvmloader_acpi_build_tables(). Function
> get_pc_machine_type() is used to select a proper table (i440/q35).
> 
> As we are bound to the qemu-xen device model for Q35, no need
> to initialize config->dsdt_15cpu/config->dsdt_15cpu_len fields.
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/firmware/hvmloader/util.c | 13 +++--
>  tools/firmware/hvmloader/util.h |  2 ++
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 5739a87628..d8db9e3c8e 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -955,8 +955,17 @@ void hvmloader_acpi_build_tables(struct acpi_config 
> *config,
>  }
>  else if ( !strncmp(s, "qemu_xen", 9) )
>  {
> -config->dsdt_anycpu = dsdt_anycpu_qemu_xen;
> -config->dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len;
> +if (get_pc_machine_type() == MACHINE_TYPE_Q35)

Coding style (missing spaces between parentheses), and I would prefer
a switch here.


IMO you should add a BUG_ON(Q35) in the qemu_xen_traditional condition
above this one..

> +{
> +config->dsdt_anycpu = dsdt_q35_anycpu_qemu_xen;
> +config->dsdt_anycpu_len = dsdt_q35_anycpu_qemu_xen_len;
> +}
> +else
> +{
> +config->dsdt_anycpu = dsdt_anycpu_qemu_xen;
> +config->dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len;
> +}
> +
>  config->dsdt_15cpu = NULL;
>  config->dsdt_15cpu_len = 0;
>  }
> diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
> index 7c77bedb00..fd2d885c96 100644
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -288,7 +288,9 @@ bool check_overlap(uint64_t start, uint64_t size,
> uint64_t reserved_start, uint64_t reserved_size);
>  
>  extern const unsigned char dsdt_anycpu_qemu_xen[], dsdt_anycpu[], 
> dsdt_15cpu[];
> +extern const unsigned char dsdt_q35_anycpu_qemu_xen[];
>  extern const int dsdt_anycpu_qemu_xen_len, dsdt_anycpu_len, dsdt_15cpu_len;
> +extern const int dsdt_q35_anycpu_qemu_xen_len;

Since you are adding this, maybe unsigned int? (or size_t?)

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 3/5] libxc: Allow loading of firmware modules for HVM guest

[Anoob Soman]

On 18/03/18 01:32, Doug Goldstein wrote:

On 3/15/18 12:31 PM, Anoob Soman wrote:

This allows to load iPXE rom as a firmware module, instead of requiring
it to be embedded into hvmloader.

Signed-off-by: Anoob Soman 
---
  tools/libxc/xc_dom_x86.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0b65dab..be06d43 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -1723,6 +1723,19 @@ static int bootlate_hvm(struct xc_dom_image *dom)
  {
  add_module_to_list(dom, >system_firmware_module, "firmware",
 modlist, start_info);
+for ( i = 0; i < dom->num_modules; i++ )
+{
+struct xc_hvm_firmware_module mod;
+
+DOMPRINTF("Adding module %u", i);

nothing more helpful for debugging than the for loop's number available?



I will add guest_addr_out, cmdline and length to DOMPRINTF.



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

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

[Andrew Cooper]

On 19/03/18 14:07, Alexandru Isaila wrote:
> -case VMEXIT_EXCEPTION_BP:
> -inst_len = __get_instruction_length(v, INSTR_INT3);
> +case VMEXIT_EXCEPTION_BP:;
> +inst_len = vmcb->nextrip - vmcb->rip;

Sorry, but no.  This will break on older AMD hardware.  You must retain
the __get_instruction_length().

NextRIP support was only introduced in Gen2 SVM, and we still support Gen1.

~Andrew

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

Re: [Xen-devel] [PATCH 5/5] hvmloader: Use iPXE ROM loaded from a standalone file

[Anoob Soman]

On 16/03/18 11:26, Jan Beulich wrote:


+/* Physical address of iPXE ROM, loaded by domain builder
+ * when using ROMBIOS
+ */
+unsigned int *ipxe_rom_addresss;

Comment style. And can the pointer be to const?


I will fixup the comment style and but making ipxe_rom_address a pointer 
to const will require codes changes in hvmloader/rombios.c, 
hvmloader/optionroms.c to make all function that use ipxe_rom_address 
const as well. Are you fine with changing these files/functions.


-Anoob

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

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

On 03/19/2018 03:51 PM, Daniel Vetter wrote:

On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:

Hi, Daniel!
Sorry, if I strip the patch too much below.

On 03/16/2018 10:23 AM, Daniel Vetter wrote:

S-o-b line went missing here :-)

will restore it back ;)

I've read through it, 2 actual review comments (around hot-unplug and
around the error recovery for failed flips), a few bikesheds, but looks
all reasonable to me. And much easier to read as one big patch (it's just
3k).

One more thing I'd do as a follow-up (don't rewrite everything, this is
close to merge, better to get it in first): You have a lot of indirections
and function calls across sources files. That's kinda ok if you have a
huge driver with 100+k lines of code where you have to split things up.
But for a small driver like yours here it's a bit overkill.

will review and try to rework after the driver is in

I'll probably merge xen_drm_front_drv.c and xen_drm_front.c now as
anyway I have to re-work driver unloading, e.g. "fishy" code below.

Personally I'd merge at least the xen backend stuff into the corresponding
kms code, but that's up to you.

I prefer to have it in smaller chunks and all related code at
one place, so it is easier to maintain. That is why I didn't
plumb frontend <-> backend code right into the KMS code.

And as mentioned, if you decide to do
that, a follow-up patch (once this has merged) is perfectly fine.

Ok, after the merge

If you prefer your current layout, then pls keep it. Bikeshed = personal
style nit, feel free to ignore if you like stuff differently. In the end
it's your driver, not mine, and I can easily navigate the current code
(with a few extra jumps).

Some of the indirections will be removed by merging
xen_drm_front_drv.c and xen_drm_front.c. Are these what you
mean or is there anything else?

-Daniel


-Daniel


+int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info *front_info,
+   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
+   uint32_t bpp, uint64_t size, struct sg_table *sgt)
+{
+   return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
+   bpp, size, NULL, sgt);
+}
+
+int xen_drm_front_dbuf_create_from_pages(struct xen_drm_front_info *front_info,
+   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
+   uint32_t bpp, uint64_t size, struct page **pages)
+{
+   return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
+   bpp, size, pages, NULL);
+}

The above two wrappers seem a bit much, just to set sgt = NULL or pages =
NULL in one of them. I'd drop them, but that's a bikeshed so feel free to
ignore.

I had that the way you say in some of the previous implementations,
but finally decided to have these dummy wrappers: seems
to be cleaner this way

+static void displback_disconnect(struct xen_drm_front_info *front_info)
+{
+   bool removed = true;
+
+   if (front_info->drm_pdev) {
+   if (xen_drm_front_drv_is_used(front_info->drm_pdev)) {
+   DRM_WARN("DRM driver still in use, deferring 
removal\n");
+   removed = false;
+   } else
+   xen_drv_remove_internal(front_info);

Ok this logic here is fishy, since you're open-coding the drm unplug
infrastructure, but slightly differently and slightyl racy. If you have a
driver where your underlying "hw" (well it's virtual here, but same idea)
can disappear any time while userspace is still using the drm driver, you
need to use the drm_dev_unplug() function and related code.
drm_dev_unplug() works like drm_dev_unregister, except for the hotplug
case.

Then you also have to guard all the driver entry points where you do
access the backchannel using drm_dev_is_unplugged() (I've seen a few of
those already). Then you can rip out all the logic here and the 
xen_drm_front_drv_is_used() helper.

Will rework it with drm_dev_unplug, thank you

I thought there's some patches from Noralf in-flight that improved the
docs on this, I need to check

Yes, I will definitely use those as soon as they are available.
But at the moment let me clarify a bit on the use-cases for driver
unplugging and backend disconnection.

The backend, by disconnecting, expects full DRM driver teardown, because,
for example, it might need to replace current frontend’s configuration
completely or stop supporting para-virtualized display for some reason.

This means that once I have displback_disconnected callback (on XenBus state
change) I am trying to unregister and remove the DRM driver which seems 
to be
not possible if I have relevant code in DRM callbacks (e.g. I cannot try 
removing

driver from driver's callback).

So, even if I add drm_dev_unplug (which anyway seems to be the right thing)
I’ll have to have that fishy code for XenBus state handling.

These are the unplug/disconnect use-cases we have:

1. Rmmod

1.1. If DRM 

Re: [Xen-devel] [RFC PATCH 02/12] Makefile: build and use new DSDT table for Q35

[Alexey G]

On Mon, 19 Mar 2018 12:46:05 +
Roger Pau Monné  wrote:

>On Tue, Mar 13, 2018 at 04:33:47AM +1000, Alexey Gerasimenko wrote:
>> Provide building for newly added dsdt_q35.asl file, in a way similar
>> to dsdt.asl.
>> 
>> Note that '15cpu' ACPI tables are only applicable to qemu-traditional
>> (which have no support for Q35), so we need to use 'anycpu' version
>> only.  
>
>You should do this in the same patch that adds dsdt_q35.asl, at the
>end without this the previous patch just adds dead code.
>
>Thanks, Roger.

Agree, I've abused recommendation to granulate patches for easier
review. :) Will merge it with the previous patch.

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

Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges

[Jan Beulich]

>>> On 12.02.18 at 11:47,  wrote:
> --- a/xen/arch/x86/iommu_op.c
> +++ b/xen/arch/x86/iommu_op.c
> @@ -22,6 +22,58 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +struct get_rdm_ctxt {
> +unsigned int max_entries;
> +unsigned int nr_entries;
> +XEN_GUEST_HANDLE(xen_iommu_reserved_region_t) regions;
> +};
> +
> +static int get_rdm(xen_pfn_t start, xen_ulong_t nr, u32 id, void *arg)

uint32_t please in new code.

> +static int iommuop_query_reserved(struct xen_iommu_op_query_reserved *op)
> +{
> +struct get_rdm_ctxt ctxt = {
> +.max_entries = op->nr_entries,
> +.regions = op->regions,
> +};
> +int rc;
> +
> +if (op->pad != 0)

Missing blanks. Perhaps also drop the " != 0".

> +return -EINVAL;
> +
> +rc = iommu_get_reserved_device_memory(get_rdm, );
> +if ( rc )
> +return rc;
> +
> +/* Pass back the actual number of reserved regions */
> +op->nr_entries = ctxt.nr_entries;
> +
> +if ( ctxt.nr_entries > ctxt.max_entries )
> +return -ENOBUFS;

Perhaps unless the handle is null?

> @@ -132,12 +190,75 @@ int 
> compat_iommu_op(XEN_GUEST_HANDLE_PARAM(compat_iommu_op_t) uops,
>  break;
>  }
>  
> +/*
> + * The xlat magic doesn't quite know how to handle the union so
> + * we need to fix things up here.
> + */

That's quite sad, as this is the second instance in a relatively short
period of time. We really should see whether the translation code
can't be adjusted suitably.

> +#define XLAT_iommu_op_u_query_reserved XEN_IOMMUOP_query_reserved
> +u = cmp.op;
> +
> +#define XLAT_iommu_op_query_reserved_HNDL_regions(_d_, _s_) \
> +do \
> +{ \
> +if ( !compat_handle_is_null((_s_)->regions) ) \

In the context of the earlier missing null handle check I find this
a little surprising (but correct).

> +{ \
> +unsigned int *nr_entries = COMPAT_ARG_XLAT_VIRT_BASE; \
> +xen_iommu_reserved_region_t *regions = \
> +(void *)(nr_entries + 1); \
> +\
> +if ( sizeof(*nr_entries) + \
> + (sizeof(*regions) * (_s_)->nr_entries) > \
> + COMPAT_ARG_XLAT_SIZE ) \
> +return -E2BIG; \
> +\
> +*nr_entries = (_s_)->nr_entries; \
> +set_xen_guest_handle((_d_)->regions, regions); \

I don't understand why nr_entries has to be a pointer into the
translation area. Can't this be a simple local variable?

> +} \
> +else \
> +set_xen_guest_handle((_d_)->regions, NULL); \
> +} while (false)
> +
>  XLAT_iommu_op(, );
>  
> +#undef XLAT_iommu_op_query_reserved_HNDL_regions
> +
>  iommu_op();
>  
> +status = nat.status;
> +
> +#define XLAT_iommu_op_query_reserved_HNDL_regions(_d_, _s_) \
> +do \
> +{ \
> +if ( !compat_handle_is_null((_d_)->regions) ) \
> +{ \
> +unsigned int *nr_entries = COMPAT_ARG_XLAT_VIRT_BASE; \
> +xen_iommu_reserved_region_t *regions = \
> +(void *)(nr_entries + 1); \
> +unsigned int j; \

Without any i in an outer scope, using j is a little unusual (but of
course okay).

> +\
> +for ( j = 0; \
> +  j < min_t(unsigned int, (_d_)->nr_entries, \
> +*nr_entries); \

Do you really need min_t() here (rather than the more safe min())?

> +  j++ ) \
> +{ \
> +compat_iommu_reserved_region_t region; \
> +\
> +XLAT_iommu_reserved_region(, [j]); \
> +\
> +if ( __copy_to_compat_offset((_d_)->regions, j, \
> + , 1) ) \

If you use the __-prefixed variant here, where's the address
validity check?

> --- a/xen/include/public/iommu_op.h
> +++ b/xen/include/public/iommu_op.h
> @@ -25,11 +25,46 @@
>  
>  #include "xen.h"
>  
> +typedef unsigned long xen_bfn_t;

Is this suitable for e.g. ARM, who don't use unsigned long for e.g.
xen_pfn_t? Is there in fact any reason not to re-use the generic
xen_pfn_t here (also see your get_rdm() above)? Otoh this is an
opportunity to not widen the problem of limited addressability in
32-bit guests - the type could be 64-bit wide across the board.

> +struct xen_iommu_reserved_region {
> +xen_bfn_t start_bfn;
> +unsigned int nr_frames;
> +unsigned int pad;

Fixed width types (i.e. uint32_t) in the public interface please.
Also, this not being the main MMU, page granularity needs to be
specified somehow (also for the conversion between xen_bfn_t
and a bus address).

> +struct xen_iommu_op_query_reserved {
> +/*
> + * IN/OUT - On entries this is 

Re: [Xen-devel] [RFC PATCH 02/12] Makefile: build and use new DSDT table for Q35

[Alexey G]

On Mon, 19 Mar 2018 07:07:34 -0600
"Jan Beulich"  wrote:

 On 12.03.18 at 19:33,  wrote:  
>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/hvmloader/Makefile
>> @@ -75,7 +75,7 @@ rombios.o: roms.inc
>>  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>>  
>>  ACPI_PATH = ../../libacpi
>> -DSDT_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
>> +DSDT_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
>> dsdt_q35_anycpu_qemu_xen.c  
>
>Unless you intend to add a second flavor, please omit the "anycpu"
>part from the name of the new instance.

Just following same "anycpu/15cpu" naming scheme, there will be no need
for dsdt_q35_15cpu.c, so I guess its ok to drop anycpu/15cpu part of
the name, will rename it.

>> @@ -56,6 +56,13 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl:
>> dsdt.asl dsdt_acpi_info.asl $(MK_DSD $(MK_DSDT) --debug=$(debug)
>> --dm-version qemu-xen >> $@.$(TMP_SUFFIX) mv -f $@.$(TMP_SUFFIX) $@
>>  
>> +$(ACPI_BUILD_DIR)/dsdt_q35_anycpu_qemu_xen.asl: dsdt_q35.asl
>> dsdt_acpi_info.asl $(MK_DSDT)
>> +# Remove last bracket
>> +awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
>> +cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
>> +$(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >>
>> $@.$(TMP_SUFFIX)
>> +mv -f $@.$(TMP_SUFFIX) $@  
>
>The commands look to be exactly the same as those for
>dsdt_anycpu_qemu_xen.asl - please let's not duplicate such
>things, but instead use a pattern rule.

Agree, reusing the rule will be better.

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

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

[Alexandru Isaila]

At this moment the Debug events for the AMD architecture are not
forwarded to the monitor layer.

This patch adds the Debug event to the common capabilities, adds
the VMEXIT_ICEBP then forwards the event to the monitor layer.

Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1
exception generated by the single byte INT1
instruction (also known as ICEBP) does not trigger the #DB
intercept. Software should use the dedicated ICEBP
intercept to intercept ICEBP"

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/svm/svm.c| 41 +
 xen/arch/x86/hvm/svm/vmcb.c   |  2 +-
 xen/include/asm-x86/monitor.h |  4 ++--
 3 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c34f5b5..aa1feaa 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1109,7 +1109,8 @@ static void noreturn svm_do_resume(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
 bool debug_state = (v->domain->debugger_attached ||
-v->domain->arch.monitor.software_breakpoint_enabled);
+v->domain->arch.monitor.software_breakpoint_enabled ||
+v->domain->arch.monitor.debug_exception_enabled);
 bool_t vcpu_guestmode = 0;
 struct vlapic *vlapic = vcpu_vlapic(v);
 
@@ -2438,16 +2439,15 @@ static bool svm_get_pending_event(struct vcpu *v, 
struct x86_event *info)
 return true;
 }
 
-static void svm_propagate_intr(struct vcpu *v, unsigned long insn_len)
+static void svm_propagate_intr(unsigned long insn_len, int16_t vector, uint8_t 
type)
 {
-struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
 struct x86_event event = {
-.vector = vmcb->eventinj.fields.type,
-.type = vmcb->eventinj.fields.type,
-.error_code = vmcb->exitinfo1,
+.vector = vector,
+.type = type,
+.error_code = X86_EVENT_NO_EC,
+.insn_len = insn_len,
 };
 
-event.insn_len = insn_len;
 hvm_inject_event();
 }
 
@@ -2655,16 +2655,33 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 /* Asynchronous event, handled when we STGI'd after the VMEXIT. */
 HVMTRACE_0D(SMI);
 break;
-
+case VMEXIT_ICEBP:
 case VMEXIT_EXCEPTION_DB:
 if ( !v->domain->debugger_attached )
-hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
+{
+int rc;
+unsigned long trap_type = exit_reason == VMEXIT_ICEBP ?
+X86_EVENTTYPE_PRI_SW_EXCEPTION : X86_EVENTTYPE_HW_EXCEPTION;
+
+inst_len = 0;
+
+if ( trap_type >= X86_EVENTTYPE_SW_INTERRUPT )
+inst_len = vmcb->nextrip - vmcb->rip;
+
+rc = hvm_monitor_debug(regs->rip,
+   HVM_MONITOR_DEBUG_EXCEPTION,
+   trap_type, inst_len);
+if ( rc < 0 )
+goto unexpected_exit_type;
+if ( !rc )
+svm_propagate_intr(inst_len, TRAP_debug, trap_type);
+}
 else
 domain_pause_for_debugger();
 break;
 
-case VMEXIT_EXCEPTION_BP:
-inst_len = __get_instruction_length(v, INSTR_INT3);
+case VMEXIT_EXCEPTION_BP:;
+inst_len = vmcb->nextrip - vmcb->rip;
 
 if ( inst_len == 0 )
  break;
@@ -2687,7 +2704,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
if ( rc < 0 )
goto unexpected_exit_type;
if ( !rc )
-   svm_propagate_intr(v, inst_len);
+   svm_propagate_intr(inst_len, TRAP_int3, 
X86_EVENTTYPE_SW_EXCEPTION);
 }
 break;
 
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index ae60d8d..06920d3 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -73,7 +73,7 @@ static int construct_vmcb(struct vcpu *v)
 GENERAL2_INTERCEPT_STGI| GENERAL2_INTERCEPT_CLGI|
 GENERAL2_INTERCEPT_SKINIT  | GENERAL2_INTERCEPT_MWAIT   |
 GENERAL2_INTERCEPT_WBINVD  | GENERAL2_INTERCEPT_MONITOR |
-GENERAL2_INTERCEPT_XSETBV;
+GENERAL2_INTERCEPT_XSETBV  | GENERAL2_INTERCEPT_ICEBP;
 
 /* Intercept all debug-register writes. */
 vmcb->_dr_intercepts = ~0u;
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 99ed4b87..c5a86d1 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -82,12 +82,12 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
 (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
 (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
+(1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
 (1U << 

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-qemuu-nested-amd

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-amd
testid xen-boot/l1

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  1454509726719e0933c800fad00d6999752688ea
  Bug not present: d07aa197c5a1556449361a0cbb5108e2e7b1adb7
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/120966/


  commit 1454509726719e0933c800fad00d6999752688ea
  Author: Thomas Huth 
  Date:   Tue Feb 20 11:42:37 2018 +0100
  
  scsi: Remove automatic creation of SCSI controllers with -drive if=scsi
  
  Automatic creation of SCSI controllers for "-drive if=scsi" for x86
  machines was quite a bad idea (see description of commit f778a82f0c179
  for details). This is marked as deprecated since QEMU v2.9.0, and as
  far as I know, nobody complained that this is still urgently required
  anymore. Time to remove this now.
  
  Suggested-by: Markus Armbruster 
  Signed-off-by: Thomas Huth 
  Message-Id: <1519123357-13225-1-git-send-email-th...@redhat.com>
  Signed-off-by: Paolo Bonzini 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-amd64-qemuu-nested-amd.xen-boot--l1.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-amd64-qemuu-nested-amd.xen-boot--l1
 --summary-out=tmp/120966.bisection-summary --basis-template=120095 
--blessings=real,real-bisect qemu-mainline test-amd64-amd64-qemuu-nested-amd 
xen-boot/l1
Searching for failure / basis pass:
 120795 fail [host=pinot1] / 120095 ok.
Failure / basis pass flights: 120795 / 120095
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest b67416226a0cff3f49032de36906ad1ebe5694a0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
3a2e46ae1de4f45b88211306a2b6c0c5efd368ab 
a823a5280f25ad19a751dd9a41044f556471e61a
Basis pass 19c04ca5b239e6e2277a5b381d1e79482ab9bbc5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
6697439794f72b3501ee16bb95d16854f9981421 
a823a5280f25ad19a751dd9a41044f556471e61a
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#19c04ca5b239e6e2277a5b381d1e79482ab9bbc5-b67416226a0cff3f49032de36906ad1ebe5694a0
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://git.qemu.org/qemu.git#6697439794f72b3501ee16bb95d16854f9981421-3a2e46ae1de4f45b88211306a2b6c0c5efd368ab
 
git://xenbits.xen.org/xen.git#a823a5280f25ad19a751dd9a41044f556471e61a-a823a5280f25ad19a751dd9a41044f556471e61a
From git://cache:9419/git://git.qemu.org/qemu
   590a3914be..2c8cfc0b52  master -> origin/master
Loaded 4289 nodes in revision graph
Searching for test results:
 120095 pass 19c04ca5b239e6e2277a5b381d1e79482ab9bbc5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
6697439794f72b3501ee16bb95d16854f9981421 
a823a5280f25ad19a751dd9a41044f556471e61a
 120318 fail 6a83eb2354543e3263b880eb822c4b0993a2236b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
f32408f3b472a088467474ab152be3b6285b2d7b 
a823a5280f25ad19a751dd9a41044f556471e61a
 120376 fail 6a83eb2354543e3263b880eb822c4b0993a2236b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
e4ae62b802cec437f877f2cadc4ef059cc0eca76 
a823a5280f25ad19a751dd9a41044f556471e61a
 120676 fail irrelevant
 120795 fail b67416226a0cff3f49032de36906ad1ebe5694a0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
3a2e46ae1de4f45b88211306a2b6c0c5efd368ab 
a823a5280f25ad19a751dd9a41044f556471e61a
 120842 pass 19c04ca5b239e6e2277a5b381d1e79482ab9bbc5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
6697439794f72b3501ee16bb95d16854f9981421 
a823a5280f25ad19a751dd9a41044f556471e61a
 120878 pass 6a83eb2354543e3263b880eb822c4b0993a2236b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

[Alexey G]

On Mon, 19 Mar 2018 12:43:05 +
Roger Pau Monné  wrote:

>On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko wrote:
>> This patch adds the DSDT table for Q35 (new
>> tools/libacpi/dsdt_q35.asl file). There are not many differences
>> with dsdt.asl (for i440) at the moment, namely:
>> 
>> - BDF location of LPC Controller
>> - Minor changes related to FDC detection
>> - Addition of _OSC method to inform OSPM about PCIe features
>> supported
>> 
>> As we are still using 4 PCI router links and their corresponding
>> device/register addresses are same (offset 0x60), no need to change
>> PCI routing descriptions.
>> 
>> Also, ACPI hotplug is still used to control passed through device hot
>> (un)plug (as it was for i440).
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---
>>  tools/libacpi/dsdt_q35.asl | 551
>> +  
>
>So this is basically a modified dupe of the current dsdt.asl? AFAICT
>there are a bunch of common bits, which ideally we want to have
>defined in a single place.
>
>Can't you factor out the common parts of the dsdt.asl into smaller
>parts an include them for both dsdt.asl and dsdt_q35.asl?
>
>I would first have a patch that extract the common parts of the
>dsdt into file(s), and then a second patch which creates a
>dsdt_q35.asl based on those common bits plus the specific q35 code.

Yes, it's a good thing that many registers have same addresses on
i440 and Q35. Some encountered common things were unexpected though --
AFAIR _S5 SLP_TYP value do not correspond to the ICH9 datasheet,
a different value used instead to trigger ACPI Soft-Off emulation.

Regarding dsdt.asl/dsdt_q35.asl -- OK, I'll split these files into
common/specific parts.

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

Re: [Xen-devel] [PATCH v5 03/14] x86emul: abstract out XCRn accesses

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 March 2018 13:04
> To: xen-devel 
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap 
> Subject: [PATCH v5 03/14] x86emul: abstract out XCRn accesses
> 
> Use hooks, just like done for other special purpose registers.
> 
> This includes moving XCR0 checks from hvmemul_get_fpu() to the emulator
> itself as well as adding support for XGETBV emulation.
> 
> For now fuzzer reads will obtain the real values (minus the fuzzing of
> the hook pointer itself).
> 
> Signed-off-by: Jan Beulich 

hvm/emulate parts...

Reviewed-by: Paul Durrant 

> ---
> v5: Move index validation into hook functions. Introduce
> x86emul_{read,write}_xcr().
> v4: Have hvmemul_read_xcr() raise an exception instead of returning
> X86EMUL_UNHANDLEABLE for invalid indexes. Introduce xgetbv() and add
> volatile to the asm() moved there. Split out _XSTATE_* movement.
> v2: Re-base.
> 
> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> @@ -459,6 +459,8 @@ static int fuzz_write_cr(
>  return X86EMUL_OKAY;
>  }
> 
> +#define fuzz_read_xcr emul_test_read_xcr
> +
>  enum {
>  MSRI_IA32_SYSENTER_CS,
>  MSRI_IA32_SYSENTER_ESP,
> @@ -577,6 +579,7 @@ static const struct x86_emulate_ops all_
>  SET(write_io),
>  SET(read_cr),
>  SET(write_cr),
> +SET(read_xcr),
>  SET(read_msr),
>  SET(write_msr),
>  SET(wbinvd),
> @@ -685,6 +688,7 @@ enum {
>  HOOK_write_cr,
>  HOOK_read_dr,
>  HOOK_write_dr,
> +HOOK_read_xcr,
>  HOOK_read_msr,
>  HOOK_write_msr,
>  HOOK_wbinvd,
> @@ -729,6 +733,7 @@ static void disable_hooks(struct x86_emu
>  MAYBE_DISABLE_HOOK(write_io);
>  MAYBE_DISABLE_HOOK(read_cr);
>  MAYBE_DISABLE_HOOK(write_cr);
> +MAYBE_DISABLE_HOOK(read_xcr);
>  MAYBE_DISABLE_HOOK(read_msr);
>  MAYBE_DISABLE_HOOK(write_msr);
>  MAYBE_DISABLE_HOOK(wbinvd);
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -371,6 +371,7 @@ static struct x86_emulate_ops emulops =
>  .read_segment = read_segment,
>  .cpuid  = emul_test_cpuid,
>  .read_cr= emul_test_read_cr,
> +.read_xcr   = emul_test_read_xcr,
>  .read_msr   = read_msr,
>  .get_fpu= emul_test_get_fpu,
>  .put_fpu= emul_test_put_fpu,
> --- a/tools/tests/x86_emulator/x86-emulate.c
> +++ b/tools/tests/x86_emulator/x86-emulate.c
> @@ -163,6 +163,35 @@ int emul_test_read_cr(
>  return X86EMUL_UNHANDLEABLE;
>  }
> 
> +int emul_test_read_xcr(
> +unsigned int reg,
> +uint64_t *val,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +uint32_t lo, hi;
> +
> +ASSERT(cpu_has_xsave);
> +
> +switch ( reg )
> +{
> +case 0:
> +break;
> +
> +case 1:
> +if ( cpu_has_xgetbv1 )
> +break;
> +/* fall through */
> +default:
> +x86_emul_hw_exception(13 /* #GP */, 0, ctxt);
> +return X86EMUL_EXCEPTION;
> +}
> +
> +asm ( "xgetbv" : "=a" (lo), "=d" (hi) : "c" (reg) );
> +*val = lo | ((uint64_t)hi << 32);
> +
> +return X86EMUL_OKAY;
> +}
> +
>  int emul_test_get_fpu(
>  void (*exception_callback)(void *, struct cpu_user_regs *),
>  void *exception_callback_arg,
> --- a/tools/tests/x86_emulator/x86-emulate.h
> +++ b/tools/tests/x86_emulator/x86-emulate.h
> @@ -186,6 +186,16 @@ static inline uint64_t xgetbv(uint32_t x
>  (res.b & (1U << 5)) != 0; \
>  })
> 
> +#define cpu_has_xgetbv1 ({ \
> +struct cpuid_leaf res; \
> +emul_test_cpuid(1, 0, , NULL); \
> +if ( !(res.c & (1U << 27)) ) \
> +res.a = 0; \
> +else \
> +emul_test_cpuid(0xd, 1, , NULL); \
> +(res.a & (1U << 2)) != 0; \
> +})
> +
>  #define cpu_has_bmi1 ({ \
>  struct cpuid_leaf res; \
>  emul_test_cpuid(7, 0, , NULL); \
> @@ -247,6 +257,11 @@ int emul_test_read_cr(
>  unsigned long *val,
>  struct x86_emulate_ctxt *ctxt);
> 
> +int emul_test_read_xcr(
> +unsigned int reg,
> +uint64_t *val,
> +struct x86_emulate_ctxt *ctxt);
> +
>  int emul_test_get_fpu(
>  void (*exception_callback)(void *, struct cpu_user_regs *),
>  void *exception_callback_arg,
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1826,6 +1826,29 @@ static int hvmemul_write_cr(
>  return rc;
>  }
> 
> +static int hvmemul_read_xcr(
> +unsigned int reg,
> +uint64_t *val,
> +struct x86_emulate_ctxt *ctxt)
> +{
> +int rc = x86emul_read_xcr(reg, val, ctxt);
> +
> +if ( rc == X86EMUL_OKAY )
> +HVMTRACE_LONG_2D(XCR_READ, reg, TRC_PAR_LONG(*val));
> +
> +return rc;
> +}
> +
> +static int hvmemul_write_xcr(
> +unsigned int reg,
> +uint64_t val,
> +struct 

Re: [Xen-devel] [PATCH 1/5] tools/firmware: Build ipxe as a standalone ROM

[Doug Goldstein]

On 3/19/18 2:48 AM, Jan Beulich wrote:
 On 18.03.18 at 02:30,  wrote:
>> On 3/16/18 6:18 AM, Jan Beulich wrote:
>> On 15.03.18 at 18:31,  wrote:
 @@ -71,7 +72,7 @@ all: acpi subdirs-all
  acpi:
$(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR) 
 DSDT_FILES="$(DSDT_FILES)"
  
 -rombios.o: roms.inc
 +rombios.o: $(ETHERBOOT_ROM) roms.inc
>>>
>>> Please don't introduce dead dependencies: If a need for this arises
>>> in a later patch, add the dependency there.
>>
>> Well this is what's creating the ipxe.bin that's being installed in the
>> section you snipped out.
> 
> I don't understand: The question isn't what is being generated, but
> whether rombios.o really depends on that binary blob, and nothing
> in the patch here suggests it does. If the goal is simply to have a
> dependency triggering the creation of the blob, then this should be
> done via e.g. TARGET, and the whole logic should rather sit in
> firmware/Makefile (matching the installation of it done there).
> 
> Jan
> 

Oh, 100% agreement there.

-- 
Doug Goldstein

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

Re: [Xen-devel] [PATCH] xen: fix null sched build with debug=n

[Doug Goldstein]

On 3/19/18 4:40 AM, Jan Beulich wrote:
 On 19.03.18 at 03:20,  wrote:
>> The null_dom() static inline is just used when debug=y so it results in
>> a error with the default CFLAGS and debug=n.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> sched_null.c:123:32: error: unused function 'null_dom' 
>> [-Werror,-Wunused-function]
> 
> Since generally only non-inline functions get warned about by gcc
> (afaik), I'm wondering: Is this with clang? Or with some specific,
> non-standard version of gcc? Adding such specifics to the commit
> message would generally be advisable (and indeed I'm not really
> happy to see such an #ifdef added, but then again I'm not the
> maintainer of that code).
> 
> Jan
> 

The full log is here: https://gitlab.com/cardoe/xen/-/jobs/58011527

It's a Debian Stretch instance using clang and debug=n. Should have
included all that, sorry.

-- 
Doug Goldstein

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

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[Daniel Vetter]

On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:
> Hi, Daniel!
> Sorry, if I strip the patch too much below.
> 
> On 03/16/2018 10:23 AM, Daniel Vetter wrote:
> > 
> > S-o-b line went missing here :-)
> will restore it back ;)
> > 
> > I've read through it, 2 actual review comments (around hot-unplug and
> > around the error recovery for failed flips), a few bikesheds, but looks
> > all reasonable to me. And much easier to read as one big patch (it's just
> > 3k).
> > 
> > One more thing I'd do as a follow-up (don't rewrite everything, this is
> > close to merge, better to get it in first): You have a lot of indirections
> > and function calls across sources files. That's kinda ok if you have a
> > huge driver with 100+k lines of code where you have to split things up.
> > But for a small driver like yours here it's a bit overkill.
> will review and try to rework after the driver is in
> > 
> > Personally I'd merge at least the xen backend stuff into the corresponding
> > kms code, but that's up to you.
> I prefer to have it in smaller chunks and all related code at
> one place, so it is easier to maintain. That is why I didn't
> plumb frontend <-> backend code right into the KMS code.
> > And as mentioned, if you decide to do
> > that, a follow-up patch (once this has merged) is perfectly fine.
> Ok, after the merge

If you prefer your current layout, then pls keep it. Bikeshed = personal
style nit, feel free to ignore if you like stuff differently. In the end
it's your driver, not mine, and I can easily navigate the current code
(with a few extra jumps).
-Daniel

> > -Daniel
> > 
> > > +int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info 
> > > *front_info,
> > > + uint64_t dbuf_cookie, uint32_t width, uint32_t height,
> > > + uint32_t bpp, uint64_t size, struct sg_table *sgt)
> > > +{
> > > + return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
> > > + bpp, size, NULL, sgt);
> > > +}
> > > +
> > > +int xen_drm_front_dbuf_create_from_pages(struct xen_drm_front_info 
> > > *front_info,
> > > + uint64_t dbuf_cookie, uint32_t width, uint32_t height,
> > > + uint32_t bpp, uint64_t size, struct page **pages)
> > > +{
> > > + return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
> > > + bpp, size, pages, NULL);
> > > +}
> > The above two wrappers seem a bit much, just to set sgt = NULL or pages =
> > NULL in one of them. I'd drop them, but that's a bikeshed so feel free to
> > ignore.
> I had that the way you say in some of the previous implementations,
> but finally decided to have these dummy wrappers: seems
> to be cleaner this way
> > > +static void displback_disconnect(struct xen_drm_front_info *front_info)
> > > +{
> > > + bool removed = true;
> > > +
> > > + if (front_info->drm_pdev) {
> > > + if (xen_drm_front_drv_is_used(front_info->drm_pdev)) {
> > > + DRM_WARN("DRM driver still in use, deferring 
> > > removal\n");
> > > + removed = false;
> > > + } else
> > > + xen_drv_remove_internal(front_info);
> > Ok this logic here is fishy, since you're open-coding the drm unplug
> > infrastructure, but slightly differently and slightyl racy. If you have a
> > driver where your underlying "hw" (well it's virtual here, but same idea)
> > can disappear any time while userspace is still using the drm driver, you
> > need to use the drm_dev_unplug() function and related code.
> > drm_dev_unplug() works like drm_dev_unregister, except for the hotplug
> > case.
> > 
> > Then you also have to guard all the driver entry points where you do
> > access the backchannel using drm_dev_is_unplugged() (I've seen a few of
> > those already). Then you can rip out all the logic here and the 
> > xen_drm_front_drv_is_used() helper.
> Will rework it with drm_dev_unplug, thank you
> > I thought there's some patches from Noralf in-flight that improved the
> > docs on this, I need to check
> > 
> > > +#define XEN_DRM_NUM_VIDEO_MODES  1
> > > +#define XEN_DRM_CRTC_VREFRESH_HZ 60
> > > +
> > > +static int connector_get_modes(struct drm_connector *connector)
> > > +{
> > > + struct xen_drm_front_drm_pipeline *pipeline =
> > > + to_xen_drm_pipeline(connector);
> > > + struct drm_display_mode *mode;
> > > + struct videomode videomode;
> > > + int width, height;
> > > +
> > > + mode = drm_mode_create(connector->dev);
> > > + if (!mode)
> > > + return 0;
> > > +
> > > + memset(, 0, sizeof(videomode));
> > > + videomode.hactive = pipeline->width;
> > > + videomode.vactive = pipeline->height;
> > > + width = videomode.hactive + videomode.hfront_porch +
> > > + videomode.hback_porch + videomode.hsync_len;
> > > + height = videomode.vactive + videomode.vfront_porch +
> > > + videomode.vback_porch + videomode.vsync_len;
> > > + videomode.pixelclock = width * height * XEN_DRM_CRTC_VREFRESH_HZ;

Re: [Xen-devel] [PATCH v4 2/8] x86: disable XPTI when RDCL_NO

[Jan Beulich]

>>> On 19.03.18 at 14:38,  wrote:
> Use the respective ARCH_CAPABILITIES MSR bit, but don't expose the MSR
> to guests yet.
> 
> Signed-off-by: Jan Beulich 
> Tested-by: Juergen Gross 
> Reviewed-by: Juergen Gross 
> Reviewed-by: Andrew Cooper 
> ---
> v3: Re-base.
> v2: New.

And I realize I've once again forgot to Cc the two of you for the
smallish tools side changes.

Jan

> --- a/tools/libxl/libxl_cpuid.c
> +++ b/tools/libxl/libxl_cpuid.c
> @@ -204,6 +204,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
>  {"avx512-4fmaps",0x0007,  0, CPUID_REG_EDX,  3,  1},
>  {"ibrsb",0x0007,  0, CPUID_REG_EDX, 26,  1},
>  {"stibp",0x0007,  0, CPUID_REG_EDX, 27,  1},
> +{"arch-caps",0x0007,  0, CPUID_REG_EDX, 29,  1},
>  
>  {"lahfsahf", 0x8001, NA, CPUID_REG_ECX,  0,  1},
>  {"cmplegacy",0x8001, NA, CPUID_REG_ECX,  1,  1},
> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -143,6 +143,7 @@ static const char *str_7d0[32] =
>  [ 2] = "avx512_4vnniw", [ 3] = "avx512_4fmaps",
>  
>  [26] = "ibrsb", [27] = "stibp",
> +/* 28 */[29] = "arch_caps",
>  };
>  
>  static struct {
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1547,7 +1547,16 @@ void __init noreturn __start_xen(unsigne
>  cr4_pv32_mask = mmu_cr4_features & XEN_CR4_PV32_BITS;
>  
>  if ( opt_xpti < 0 )
> -opt_xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
> +{
> +uint64_t caps = 0;
> +
> +if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
> +caps = ARCH_CAPABILITIES_RDCL_NO;
> +else if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
> +rdmsrl(MSR_ARCH_CAPABILITIES, caps);
> +
> +opt_xpti = !(caps & ARCH_CAPABILITIES_RDCL_NO);
> +}
>  if ( opt_xpti )
>  setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
>  else
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -40,6 +40,8 @@
>  #define PRED_CMD_IBPB(_AC(1, ULL) << 0)
>  
>  #define MSR_ARCH_CAPABILITIES0x010a
> +#define ARCH_CAPABILITIES_RDCL_NO(_AC(1, ULL) << 0)
> +#define ARCH_CAPABILITIES_IBRS_ALL   (_AC(1, ULL) << 1)
>  
>  /* Intel MSRs. Some also available on other CPUs */
>  #define MSR_IA32_PERFCTR00x00c1
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -244,6 +244,7 @@ XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /
>  XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation 
> Single Precision */
>  XEN_CPUFEATURE(IBRSB, 9*32+26) /*A  IBRS and IBPB support (used by 
> Intel) */
>  XEN_CPUFEATURE(STIBP, 9*32+27) /*A! STIBP */
> +XEN_CPUFEATURE(ARCH_CAPS, 9*32+29) /*   IA32_ARCH_CAPABILITIES MSR */
>  
>  #endif /* XEN_CPUFEATURE */
>  
> 
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org 
> https://lists.xenproject.org/mailman/listinfo/xen-devel 




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

[Xen-devel] [PATCH v4 8/8] x86: avoid double CR3 reload when switching to guest user mode

[Jan Beulich]

When XPTI is active, the CR3 load in restore_all_guest is sufficient
when switching to user mode, improving in particular system call and
page fault exit paths for the guest.

Signed-off-by: Jan Beulich 
Tested-by: Juergen Gross 
Reviewed-by: Juergen Gross 
---
v2: Add ASSERT(!in_irq()).

--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -219,10 +219,22 @@ int pv_domain_initialise(struct domain *
 return rc;
 }
 
-static void _toggle_guest_pt(struct vcpu *v)
+static void _toggle_guest_pt(struct vcpu *v, bool force_cr3)
 {
+ASSERT(!in_irq());
+
 v->arch.flags ^= TF_kernel_mode;
 update_cr3(v);
+
+/*
+ * There's no need to load CR3 here when it is going to be loaded on the
+ * way out to guest mode again anyway, and when the page tables we're
+ * currently on are the kernel ones (whereas when switching to kernel
+ * mode we need to be able to write a bounce frame onto the kernel stack).
+ */
+if ( !force_cr3 && !(v->arch.flags & TF_kernel_mode) )
+return;
+
 /* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
 asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
 
@@ -252,13 +264,13 @@ void toggle_guest_mode(struct vcpu *v)
 }
 asm volatile ( "swapgs" );
 
-_toggle_guest_pt(v);
+_toggle_guest_pt(v, cpu_has_no_xpti);
 }
 
 void toggle_guest_pt(struct vcpu *v)
 {
 if ( !is_pv_32bit_vcpu(v) )
-_toggle_guest_pt(v);
+_toggle_guest_pt(v, true);
 }
 
 /*




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

[Xen-devel] [PATCH v4 6/8] x86: enable interrupts earlier with XPTI disabled

[Jan Beulich]

The STI instances were moved (or added in the INT80 case) to meet TLB
flush requirements. When XPTI is disabled, they can be put back where
they were (or omitted in the INT80 case).

Signed-off-by: Jan Beulich 
---
v4: Split off from earlier patch.
---
TBD: It is questionable whether having two back-to-back alternatives
 keyed to the same feature is a good idea. The original patch had
 them as a single instance each, but the variant here requires fewer
 (explicit) labels and hence results in overall more readable code.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -194,7 +194,7 @@ ENTRY(compat_post_handle_exception)
 
 /* See lstar_enter for entry register state. */
 ENTRY(cstar_enter)
-/* sti could live here when we don't switch page tables below. */
+ALTERNATIVE nop, sti, X86_FEATURE_NO_XPTI
 CR4_PV32_RESTORE
 movq  8(%rsp),%rax /* Restore %rax. */
 movq  $FLAT_KERNEL_SS,8(%rsp)
@@ -220,7 +220,7 @@ ENTRY(cstar_enter)
 mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lcstar_cr3_okay:
 ALTERNATIVE_NOP .Lcstar_cr3_start, .Lcstar_cr3_okay, 
X86_FEATURE_NO_XPTI
-sti
+ALTERNATIVE sti, "", X86_FEATURE_NO_XPTI
 
 movq  STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
 movq  VCPU_domain(%rbx),%rcx
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -245,7 +245,7 @@ UNLIKELY_END(exit_cr3)
  * %ss must be saved into the space left by the trampoline.
  */
 ENTRY(lstar_enter)
-/* sti could live here when we don't switch page tables below. */
+ALTERNATIVE nop, sti, X86_FEATURE_NO_XPTI
 movq  8(%rsp),%rax /* Restore %rax. */
 movq  $FLAT_KERNEL_SS,8(%rsp)
 pushq %r11
@@ -270,7 +270,7 @@ ENTRY(lstar_enter)
 mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Llstar_cr3_okay:
 ALTERNATIVE_NOP .Llstar_cr3_start, .Llstar_cr3_okay, 
X86_FEATURE_NO_XPTI
-sti
+ALTERNATIVE sti, "", X86_FEATURE_NO_XPTI
 
 movq  STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
 testb $TF_kernel_mode,VCPU_thread_flags(%rbx)
@@ -281,7 +281,7 @@ ENTRY(lstar_enter)
 jmp   test_all_events
 
 ENTRY(sysenter_entry)
-/* sti could live here when we don't switch page tables below. */
+ALTERNATIVE nop, sti, X86_FEATURE_NO_XPTI
 pushq $FLAT_USER_SS
 pushq $0
 pushfq
@@ -310,7 +310,7 @@ GLOBAL(sysenter_eflags_saved)
 mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lsyse_cr3_okay:
 ALTERNATIVE_NOP .Lsyse_cr3_start, .Lsyse_cr3_okay, X86_FEATURE_NO_XPTI
-sti
+ALTERNATIVE sti, "", X86_FEATURE_NO_XPTI
 
 movq  STACK_CPUINFO_FIELD(current_vcpu)(%rbx), %rbx
 cmpb  $0,VCPU_sysenter_disables_events(%rbx)
@@ -363,7 +363,7 @@ ENTRY(int80_direct_trap)
 mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lint80_cr3_okay:
 ALTERNATIVE_NOP .Lint80_cr3_start, .Lint80_cr3_okay, 
X86_FEATURE_NO_XPTI
-sti
+ALTERNATIVE sti, "", X86_FEATURE_NO_XPTI
 
 cmpb  $0,untrusted_msi(%rip)
 UNLIKELY_START(ne, msi_check)




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

[Xen-devel] [PATCH v4 7/8] x86: also NOP out xen_cr3 restores of XPTI

[Jan Beulich]

... despite quite likely the gain being rather limited.

Signed-off-by: Jan Beulich 
---
v4: Split off from earlier patch.

--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -583,7 +583,8 @@ ENTRY(common_interrupt)
 CR4_PV32_RESTORE
 movq %rsp,%rdi
 callq do_IRQ
-mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
+ALTERNATIVE __stringify(mov %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)), 
\
+"", X86_FEATURE_NO_XPTI
 jmp ret_from_intr
 
 ENTRY(page_fault)
@@ -665,7 +666,8 @@ handle_exception_saved:
 PERFC_INCR(exceptions, %rax, %rbx)
 mov   (%rdx, %rax, 8), %rdx
 INDIRECT_CALL %rdx
-mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
+ALTERNATIVE __stringify(mov %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)), 
\
+"", X86_FEATURE_NO_XPTI
 testb $3,UREGS_cs(%rsp)
 jzrestore_all_xen
 leaq  VCPU_trap_bounce(%rbx),%rdx
@@ -698,7 +700,8 @@ exception_with_ints_disabled:
 rep;  movsq # make room for ec/ev
 1:  movq  UREGS_error_code(%rsp),%rax # ec/ev
 movq  %rax,UREGS_kernel_sizeof(%rsp)
-mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
+ALTERNATIVE __stringify(mov %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)), 
\
+"", X86_FEATURE_NO_XPTI
 jmp   restore_all_xen   # return to fixup code
 
 /* No special register assumptions. */
@@ -849,7 +852,8 @@ handle_ist_exception:
 leaq  exception_table(%rip),%rdx
 mov   (%rdx, %rax, 8), %rdx
 INDIRECT_CALL %rdx
-mov   %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
+ALTERNATIVE __stringify(mov %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)), 
\
+"", X86_FEATURE_NO_XPTI
 cmpb  $TRAP_nmi,UREGS_entry_vector(%rsp)
 jne   ret_from_intr
 




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

[Xen-devel] [PATCH v4 5/8] x86/XPTI: reduce .text.entry

[Jan Beulich]

This exposes less code pieces and at the same time reduces the range
covered from slightly above 3 pages to a little below 2 of them.

The code being moved is unchanged, except for the removal of trailing
blanks, insertion of blanks between operands, and a pointless q suffix
from "retq".

A few more small pieces could be moved, but it seems better to me to
leave them where they are to not make it overly hard to follow code
paths.

Signed-off-by: Jan Beulich 
---
v4: Re-base.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -13,8 +13,6 @@
 #include 
 #include 
 
-.section .text.entry, "ax", @progbits
-
 ENTRY(entry_int82)
 ASM_CLAC
 pushq $0
@@ -192,6 +190,8 @@ ENTRY(compat_post_handle_exception)
 movb  $0,TRAPBOUNCE_flags(%rdx)
 jmp   compat_test_all_events
 
+.section .text.entry, "ax", @progbits
+
 /* See lstar_enter for entry register state. */
 ENTRY(cstar_enter)
 /* sti could live here when we don't switch page tables below. */
@@ -249,6 +249,8 @@ UNLIKELY_END(compat_syscall_gpf)
 movb  %cl,TRAPBOUNCE_flags(%rdx)
 jmp   .Lcompat_bounce_exception
 
+.text
+
 ENTRY(compat_sysenter)
 CR4_PV32_RESTORE
 movq  VCPU_trap_ctxt(%rbx),%rcx
@@ -268,9 +270,6 @@ ENTRY(compat_int80_direct_trap)
 call  compat_create_bounce_frame
 jmp   compat_test_all_events
 
-/* compat_create_bounce_frame & helpers don't need to be in 
.text.entry */
-.text
-
 /* CREATE A BASIC EXCEPTION FRAME ON GUEST OS (RING-1) STACK:*/
 /*   {[ERRCODE,] EIP, CS, EFLAGS, [ESP, SS]} */
 /* %rdx: trap_bounce, %rbx: struct vcpu  */
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -14,8 +14,6 @@
 #include 
 #include 
 
-.section .text.entry, "ax", @progbits
-
 /* %rbx: struct vcpu */
 ENTRY(switch_to_kernel)
 leaq  VCPU_trap_bounce(%rbx),%rdx
@@ -34,8 +32,91 @@ ENTRY(switch_to_kernel)
 movb  %cl,TRAPBOUNCE_flags(%rdx)
 call  create_bounce_frame
 andl  $~X86_EFLAGS_DF,UREGS_eflags(%rsp)
+/* %rbx: struct vcpu */
+test_all_events:
+ASSERT_NOT_IN_ATOMIC
+cli # tests must not race interrupts
+/*test_softirqs:*/
+movl  VCPU_processor(%rbx), %eax
+shll  $IRQSTAT_shift, %eax
+leaq  irq_stat+IRQSTAT_softirq_pending(%rip), %rcx
+cmpl  $0, (%rcx, %rax, 1)
+jne   process_softirqs
+cmpb  $0, VCPU_mce_pending(%rbx)
+jne   process_mce
+.Ltest_guest_nmi:
+cmpb  $0, VCPU_nmi_pending(%rbx)
+jne   process_nmi
+test_guest_events:
+movq  VCPU_vcpu_info(%rbx), %rax
+movzwl VCPUINFO_upcall_pending(%rax), %eax
+decl  %eax
+cmpl  $0xfe, %eax
+jarestore_all_guest
+/*process_guest_events:*/
+sti
+leaq  VCPU_trap_bounce(%rbx), %rdx
+movq  VCPU_event_addr(%rbx), %rax
+movq  %rax, TRAPBOUNCE_eip(%rdx)
+movb  $TBF_INTERRUPT, TRAPBOUNCE_flags(%rdx)
+call  create_bounce_frame
 jmp   test_all_events
 
+ALIGN
+/* %rbx: struct vcpu */
+process_softirqs:
+sti
+call do_softirq
+jmp  test_all_events
+
+ALIGN
+/* %rbx: struct vcpu */
+process_mce:
+testb $1 << VCPU_TRAP_MCE, VCPU_async_exception_mask(%rbx)
+jnz  .Ltest_guest_nmi
+sti
+movb $0, VCPU_mce_pending(%rbx)
+call set_guest_machinecheck_trapbounce
+test %eax, %eax
+jz   test_all_events
+movzbl VCPU_async_exception_mask(%rbx), %edx # save mask for the
+movb %dl, VCPU_mce_old_mask(%rbx)# iret hypercall
+orl  $1 << VCPU_TRAP_MCE, %edx
+movb %dl, VCPU_async_exception_mask(%rbx)
+jmp  process_trap
+
+ALIGN
+/* %rbx: struct vcpu */
+process_nmi:
+testb $1 << VCPU_TRAP_NMI, VCPU_async_exception_mask(%rbx)
+jnz  test_guest_events
+sti
+movb $0, VCPU_nmi_pending(%rbx)
+call set_guest_nmi_trapbounce
+test %eax, %eax
+jz   test_all_events
+movzbl VCPU_async_exception_mask(%rbx), %edx # save mask for the
+movb %dl, VCPU_nmi_old_mask(%rbx)# iret hypercall
+orl  $1 << VCPU_TRAP_NMI, %edx
+movb %dl, VCPU_async_exception_mask(%rbx)
+/* FALLTHROUGH */
+process_trap:
+leaq VCPU_trap_bounce(%rbx), %rdx
+call create_bounce_frame
+jmp  test_all_events
+
+/* No special register assumptions. */
+ENTRY(ret_from_intr)
+GET_CURRENT(bx)
+testb $3, UREGS_cs(%rsp)
+jzrestore_all_xen
+movq  VCPU_domain(%rbx), %rax
+cmpb  $0, DOMAIN_is_32bit_pv(%rax)
+jetest_all_events
+jmp   compat_test_all_events
+
+.section .text.entry, "ax", @progbits
+
 /* %rbx: struct vcpu, interrupts disabled 

[Xen-devel] [PATCH v4 4/8] x86/XPTI: use %r12 to write zero into xen_cr3

[Jan Beulich]

Now that we zero all registers early on all entry paths, use that to
avoid a couple of immediates here.

Signed-off-by: Jan Beulich 
Acked-by: Andrew Cooper 
---
v4: Add comments about the %r12 being zero
---
We may want to consider eliminating a few more $0 this way. But
especially for byte ones I'm not sure it's worth it, due to the REX
prefix the use of %r12 would incur.

--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -216,7 +216,8 @@ ENTRY(cstar_enter)
 mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 neg   %rcx
 mov   %rcx, %cr3
-movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
+/* %r12 is still zero at this point. */
+mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lcstar_cr3_okay:
 ALTERNATIVE_NOP .Lcstar_cr3_start, .Lcstar_cr3_okay, 
X86_FEATURE_NO_XPTI
 sti
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -185,7 +185,8 @@ ENTRY(lstar_enter)
 mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 neg   %rcx
 mov   %rcx, %cr3
-movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
+/* %r12 is still zero at this point. */
+mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Llstar_cr3_okay:
 ALTERNATIVE_NOP .Llstar_cr3_start, .Llstar_cr3_okay, 
X86_FEATURE_NO_XPTI
 sti
@@ -296,7 +297,8 @@ GLOBAL(sysenter_eflags_saved)
 mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 neg   %rcx
 mov   %rcx, %cr3
-movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
+/* %r12 is still zero at this point. */
+mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lsyse_cr3_okay:
 ALTERNATIVE_NOP .Lsyse_cr3_start, .Lsyse_cr3_okay, X86_FEATURE_NO_XPTI
 sti
@@ -348,7 +350,8 @@ ENTRY(int80_direct_trap)
 mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 neg   %rcx
 mov   %rcx, %cr3
-movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
+/* %r12 is still zero at this point. */
+mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%rbx)
 .Lint80_cr3_okay:
 ALTERNATIVE_NOP .Lint80_cr3_start, .Lint80_cr3_okay, 
X86_FEATURE_NO_XPTI
 sti
@@ -561,10 +564,10 @@ ENTRY(common_interrupt)
 neg   %rcx
 .Lintr_cr3_load:
 mov   %rcx, %cr3
-xor   %ecx, %ecx
-mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
+/* %r12 is still zero at this point. */
+mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
 testb $3, UREGS_cs(%rsp)
-cmovnz %rcx, %r15
+cmovnz %r12, %r15
 .Lintr_cr3_okay:
 ALTERNATIVE_NOP .Lintr_cr3_start, .Lintr_cr3_okay, X86_FEATURE_NO_XPTI
 
@@ -605,10 +608,10 @@ GLOBAL(handle_exception)
 neg   %rcx
 .Lxcpt_cr3_load:
 mov   %rcx, %cr3
-xor   %ecx, %ecx
-mov   %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
+/* %r12 is still zero at this point. */
+mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
 testb $3, UREGS_cs(%rsp)
-cmovnz %rcx, %r15
+cmovnz %r12, %r15
 .Lxcpt_cr3_okay:
 ALTERNATIVE_NOP .Lxcpt_cr3_start, .Lxcpt_cr3_okay, X86_FEATURE_NO_XPTI
 
@@ -824,7 +827,8 @@ handle_ist_exception:
 neg   %rcx
 .List_cr3_load:
 mov   %rcx, %cr3
-movq  $0, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
+/* %r12 is still zero at this point. */
+mov   %r12, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
 .List_cr3_okay:
 ALTERNATIVE_NOP .List_cr3_start, .List_cr3_okay, X86_FEATURE_NO_XPTI
 




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

[Xen-devel] [PATCH v4 3/8] x86: log XPTI enabled status

[Jan Beulich]

At the same time also report the state of the two defined
ARCH_CAPABILITIES MSR bits. To avoid further complicating the
conditional around that printk(), drop it (it's a debug level one only
anyway).

Issue the main message without any XENLOG_*, and also drop XENLOG_INFO
from the respective BTI message, to make sure they're visible at default
log level also in release builds.

Signed-off-by: Jan Beulich 
Tested-by: Juergen Gross 
Reviewed-by: Juergen Gross 
Reviewed-by: Andrew Cooper 
---
v4: Drop XENLOG_INFO (also from respective BTI message).
v2: Re-base over split off earlier patch. Drop MSR_ from
MSR_ARCH_CAPABILITIES_*. Drop conditional around debug printk().

--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -21,7 +21,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -100,30 +100,31 @@ custom_param("bti", parse_bti);
 static void __init print_details(enum ind_thunk thunk)
 {
 unsigned int _7d0 = 0, e8b = 0, tmp;
+uint64_t caps = 0;
 
 /* Collect diagnostics about available mitigations. */
 if ( boot_cpu_data.cpuid_level >= 7 )
 cpuid_count(7, 0, , , , &_7d0);
 if ( boot_cpu_data.extended_cpuid_level >= 0x8008 )
 cpuid(0x8008, , , , );
+if ( _7d0 & cpufeat_mask(X86_FEATURE_ARCH_CAPS) )
+rdmsrl(MSR_ARCH_CAPABILITIES, caps);
 
 printk(XENLOG_DEBUG "Speculative mitigation facilities:\n");
 
 /* Hardware features which pertain to speculative mitigations. */
-if ( (_7d0 & (cpufeat_mask(X86_FEATURE_IBRSB) |
-  cpufeat_mask(X86_FEATURE_STIBP))) ||
- (e8b & cpufeat_mask(X86_FEATURE_IBPB)) )
-printk(XENLOG_DEBUG "  Hardware features:%s%s%s\n",
-   (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
-   (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
-   (e8b  & cpufeat_mask(X86_FEATURE_IBPB))  ? " IBPB"  : "");
+printk(XENLOG_DEBUG "  Hardware features:%s%s%s%s%s\n",
+   (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
+   (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
+   (e8b  & cpufeat_mask(X86_FEATURE_IBPB))  ? " IBPB"  : "",
+   (caps & ARCH_CAPABILITIES_IBRS_ALL)  ? " IBRS_ALL"  : "",
+   (caps & ARCH_CAPABILITIES_RDCL_NO)   ? " RDCL_NO"   : "");
 
 /* Compiled-in support which pertains to BTI mitigations. */
 if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
 printk(XENLOG_DEBUG "  Compiled-in support: INDIRECT_THUNK\n");
 
-printk(XENLOG_INFO
-   "BTI mitigations: Thunk %s, Others:%s%s%s%s\n",
+printk("BTI mitigations: Thunk %s, Others:%s%s%s%s\n",
thunk == THUNK_NONE  ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE? "LFENCE" :
@@ -133,6 +134,9 @@ static void __init print_details(enum in
opt_ibpb  ? " IBPB"   : "",
boot_cpu_has(X86_FEATURE_RSB_NATIVE)  ? " RSB_NATIVE" : "",
boot_cpu_has(X86_FEATURE_RSB_VMEXIT)  ? " RSB_VMEXIT" : "");
+
+printk("XPTI: %s\n",
+   boot_cpu_has(X86_FEATURE_NO_XPTI) ? "disabled" : "enabled");
 }
 
 /* Calculate whether Retpoline is known-safe on this CPU. */




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

[Xen-devel] [PATCH v4 2/8] x86: disable XPTI when RDCL_NO

[Jan Beulich]

Use the respective ARCH_CAPABILITIES MSR bit, but don't expose the MSR
to guests yet.

Signed-off-by: Jan Beulich 
Tested-by: Juergen Gross 
Reviewed-by: Juergen Gross 
Reviewed-by: Andrew Cooper 
---
v3: Re-base.
v2: New.

--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -204,6 +204,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
 {"avx512-4fmaps",0x0007,  0, CPUID_REG_EDX,  3,  1},
 {"ibrsb",0x0007,  0, CPUID_REG_EDX, 26,  1},
 {"stibp",0x0007,  0, CPUID_REG_EDX, 27,  1},
+{"arch-caps",0x0007,  0, CPUID_REG_EDX, 29,  1},
 
 {"lahfsahf", 0x8001, NA, CPUID_REG_ECX,  0,  1},
 {"cmplegacy",0x8001, NA, CPUID_REG_ECX,  1,  1},
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -143,6 +143,7 @@ static const char *str_7d0[32] =
 [ 2] = "avx512_4vnniw", [ 3] = "avx512_4fmaps",
 
 [26] = "ibrsb", [27] = "stibp",
+/* 28 */[29] = "arch_caps",
 };
 
 static struct {
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1547,7 +1547,16 @@ void __init noreturn __start_xen(unsigne
 cr4_pv32_mask = mmu_cr4_features & XEN_CR4_PV32_BITS;
 
 if ( opt_xpti < 0 )
-opt_xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
+{
+uint64_t caps = 0;
+
+if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+caps = ARCH_CAPABILITIES_RDCL_NO;
+else if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
+rdmsrl(MSR_ARCH_CAPABILITIES, caps);
+
+opt_xpti = !(caps & ARCH_CAPABILITIES_RDCL_NO);
+}
 if ( opt_xpti )
 setup_clear_cpu_cap(X86_FEATURE_NO_XPTI);
 else
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -40,6 +40,8 @@
 #define PRED_CMD_IBPB  (_AC(1, ULL) << 0)
 
 #define MSR_ARCH_CAPABILITIES  0x010a
+#define ARCH_CAPABILITIES_RDCL_NO  (_AC(1, ULL) << 0)
+#define ARCH_CAPABILITIES_IBRS_ALL (_AC(1, ULL) << 1)
 
 /* Intel MSRs. Some also available on other CPUs */
 #define MSR_IA32_PERFCTR0  0x00c1
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -244,6 +244,7 @@ XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /
 XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation 
Single Precision */
 XEN_CPUFEATURE(IBRSB, 9*32+26) /*A  IBRS and IBPB support (used by 
Intel) */
 XEN_CPUFEATURE(STIBP, 9*32+27) /*A! STIBP */
+XEN_CPUFEATURE(ARCH_CAPS, 9*32+29) /*   IA32_ARCH_CAPABILITIES MSR */
 
 #endif /* XEN_CPUFEATURE */
 




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

Re: [Xen-devel] [RFC PATCH 02/12] Makefile: build and use new DSDT table for Q35

[Jan Beulich]

>>> On 12.03.18 at 19:33,  wrote:
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -75,7 +75,7 @@ rombios.o: roms.inc
>  smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
>  
>  ACPI_PATH = ../../libacpi
> -DSDT_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
> +DSDT_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c 
> dsdt_q35_anycpu_qemu_xen.c

Unless you intend to add a second flavor, please omit the "anycpu"
part from the name of the new instance.

> @@ -56,6 +56,13 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl 
> dsdt_acpi_info.asl $(MK_DSD
>   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
>   mv -f $@.$(TMP_SUFFIX) $@
>  
> +$(ACPI_BUILD_DIR)/dsdt_q35_anycpu_qemu_xen.asl: dsdt_q35.asl 
> dsdt_acpi_info.asl $(MK_DSDT)
> + # Remove last bracket
> + awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
> + cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
> + $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
> + mv -f $@.$(TMP_SUFFIX) $@

The commands look to be exactly the same as those for
dsdt_anycpu_qemu_xen.asl - please let's not duplicate such
things, but instead use a pattern rule.

Jan


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

Re: [Xen-devel] [RFC PATCH 04/12] hvmloader: add ACPI enabling for Q35

[Roger Pau Monné]

On Tue, Mar 13, 2018 at 04:33:49AM +1000, Alexey Gerasimenko wrote:
> In order to turn on ACPI for OS, we need to write a chipset-specific value
> to SMI_CMD register (sort of imitation of the APM->ACPI switch on real
> systems). Modify acpi_enable_sci() function to support both i440 and Q35
> emulation.
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/firmware/hvmloader/hvmloader.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/hvmloader.c 
> b/tools/firmware/hvmloader/hvmloader.c
> index f603f68ded..070698440e 100644
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -257,9 +257,16 @@ static const struct bios_config *detect_bios(void)
>  static void acpi_enable_sci(void)
>  {
>  uint8_t pm1a_cnt_val;
> +uint8_t acpi_enable_val;
>  
> -#define PIIX4_SMI_CMD_IOPORT 0xb2
> +#define SMI_CMD_IOPORT   0xb2
>  #define PIIX4_ACPI_ENABLE0xf1
> +#define ICH9_ACPI_ENABLE 0x02
> +
> +if (get_pc_machine_type() == MACHINE_TYPE_Q35)
> +acpi_enable_val = ICH9_ACPI_ENABLE;
> +else
> +acpi_enable_val = PIIX4_ACPI_ENABLE;

Coding style, but I would rather:

switch ( get_pc_machine_type() )
{
case MACHINE_TYPE_Q35:
...
case MACHINE_TYPE_I440:
...
default:
BUG();
}

I think storing the machine type in a global variable is better than
calling get_pc_machine_type each time.

Thanks, Roger.

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