Re: [Xen-devel] [PATCH v4 1/2] xen/kbdif: Add string constants for raw pointer

[Oleksandr Andrushchenko]

Konrad?

On 05/02/2018 05:49 PM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Add missing string constants for {feature|request}-raw-pointer
to align with the rest of the interface file.

Fixes 7868654ff7fe ("kbdif: Define "feature-raw-pointer" and 
"request-raw-pointer")

Signed-off-by: Oleksandr Andrushchenko 
---
  xen/include/public/io/kbdif.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 3ce54e9a44c1..daf4bc2063c9 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -178,8 +178,10 @@
  #define XENKBD_DRIVER_NAME "vkbd"
  
  #define XENKBD_FIELD_FEAT_ABS_POINTER  "feature-abs-pointer"

+#define XENKBD_FIELD_FEAT_RAW_POINTER  "feature-raw-pointer"
  #define XENKBD_FIELD_FEAT_MTOUCH   "feature-multi-touch"
  #define XENKBD_FIELD_REQ_ABS_POINTER   "request-abs-pointer"
+#define XENKBD_FIELD_REQ_RAW_POINTER   "request-raw-pointer"
  #define XENKBD_FIELD_REQ_MTOUCH"request-multi-touch"
  #define XENKBD_FIELD_RING_GREF "page-gref"
  #define XENKBD_FIELD_EVT_CHANNEL   "event-channel"



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

Re: [Xen-devel] [PATCH] x86-64/Xen: fix stack switching

[Andy Lutomirski]

On Mon, May 7, 2018 at 5:16 AM Jan Beulich  wrote:

> While on native entry into the kernel happens on the trampoline stack,
> PV Xen kernels are being entered with the current thread stack right
> away. Hence source and destination stacks are identical in that case,
> and special care is needed.

> Other than in sync_regs() the copying done on the INT80 path as well as
> on the NMI path itself isn't NMI / #MC safe, as either of these events
> occurring in the middle of the stack copying would clobber data on the
> (source) stack. (Of course, in the NMI case only #MC could break
> things.)

I think I'd rather fix this by changing the stack switch code or
alternativing around it on non-stack-switching kernels.  Or make Xen use a
trampoline stack just like native.


> I'm not altering the similar code in interrupt_entry(), as that code
> path is unreachable when running an PV Xen guest afaict.

> Signed-off-by: Jan Beulich 
> Cc: sta...@kernel.org
> ---
> There would certainly have been the option of using alternatives
> patching, but afaict the patching code isn't NMI / #MC safe, so I'd
> rather stay away from patching the NMI path. And I thought it would be
> better to use similar code in both cases.

I would hope we do the patching before we enable any NMIs.


> Another option would be to make the Xen case match the native one, by
> going through the trampoline stack, but to me this would look like extra
> overhead for no gain.

Avoiding even more complexity in the nmi code seems like a big gain to me.

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

[Xen-devel] [linux-4.14 test] 122628: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-libvirt  broken
 test-arm64-arm64-xl-xsm  broken
 test-arm64-arm64-xl-credit2  broken
 build-arm64-libvirt   4 host-install(4)broken REGR. vs. 122368
 test-amd64-i386-libvirt-xsm  broken  in 122572
 build-arm64-pvopsbroken  in 122613
 build-arm64-pvops  4 host-install(4) broken in 122613 REGR. vs. 122368

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm  4 host-install(4) broken in 122572 pass in 122628
 test-arm64-arm64-xl-credit2   4 host-install(4)  broken pass in 122572
 test-arm64-arm64-xl-xsm   4 host-install(4)  broken pass in 122572
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 
fail in 122613 pass in 122628
 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail 
pass in 122613

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked in 122613 n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked in 122613 n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 122613 n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked in 122613 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 122572 never pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 122572 never 
pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 122572 never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 122572 never 
pass
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 122572 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 122572 never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail 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-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-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-xsm 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-amd64-amd64-xl-qemuu-win7-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-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th

[Stefano Stabellini]

On Fri, 6 Apr 2018, Stefano Stabellini wrote:
> > > > > 3) Understand how to address dom0. FreeRTOS Dom0 sounds like a good
> > > > > solution.
> > > > > Next step: reach out to Dornerworks and/or others that worked with
> > > > > FreeRTOS on Xen before. Figure out whether FreeRTOS is actually a
> > > > > suitable solution and what needs to be done to run FreeRTOS as Dom0.
> > > > 
> > > > Some things to check at this stage:
> > > > a) I believe there is a safety certified version of FreeRTOS - I could 
> > > > not
> > > > find
> > > > much, except for https://www.freertos.org/FreeRTOS-
> > > > Plus/Safety_Critical_Certified/SafeRTOS-Safety-Critical-Certification.shtml
> > > > -
> > > > which describes SafeRTOS a commercial safety certified FreeRTOS and
> > > > (mostly) API compliant version of FreeRTOS. Or am I missing something
> > > > here?
> > > > b) There is a DomU capable version from Galois (Jonathan Docherty 
> > > > CC'ed) -
> > > > I don't know whether others also have such versions
> > > 
> > > I ported the version of FreeRTOS that Xilinx distributes with their SDK to
> > > run as a domU on the ZUS+ in 2016 and round tripped the change set back to
> > > Richard Barry.
> > > I've also heard interest in running RTEMS as a guest OS.
> > > 
> > 
> > We've had experience in running QNX in domu, but that was not very welcomed 
> > by
> > BB QSSL folks back then :) They dont really like OSS

One more option (apparently taken by others) is to demonstrate that
after boot Dom0 cannot affect the system anymore. To do that, we would
have to get rid of Dom0 entirely after booting all domains, or,
deprivilege/restrict its possible effects on the system. Something like
turning Dom0 into a DomU after booting all the other guests.

This might actually be easier to achieve than "dom0-less" or using
FreeRTOS as dom0.

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

[Xen-devel] [xen-4.10-testing test] 122627: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122490
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 122490
 build-arm64   4 host-install(4)broken REGR. vs. 122490

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-xsm  13 migrate-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 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 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-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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-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-armhf-armhf-libvirt 14 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:
 xen  99e50001bea6f3d777b86bbb9bb41ef66ba47974
baseline version:
 xen  c30ab3d97c8ff0d2ed8948dd013737befc7a2223

Last test of basis   122490  2018-04-28 06:03:56 Z9 days
Testing same since   122560  2018-05-02 10:07:00 Z5 days5 attempts


People who 

[Xen-devel] [PATCH v2 10/10] x86/SVM: Append AMD AVIC related data to IRQ keyhandler 'i'

[Janakarajan Natarajan]

From: Suravee Suthikulpanit 

Append AVIC related data when IRQ information is dumped with key 'i'.
Here is an example of per-domain statistics being dumped.

*** SVM AVIC Statistics **
>>> Domain 1 <<<
VCPU 0
* incomp_ipi = 3110
* noaccel= 236475
* post_intr  = 116176
* doorbell   = 715
VCPU 1
* incomp_ipi = 2565
* noaccel= 233061
* post_intr  = 115765
* doorbell   = 771
**

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Janakarajan Natarajan 
---
 xen/arch/x86/hvm/svm/avic.c| 54 +-
 xen/arch/x86/irq.c |  2 ++
 xen/include/asm-x86/hvm/svm/avic.h |  3 +++
 xen/include/asm-x86/hvm/svm/vmcb.h |  6 +
 4 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
index 19caaeda53..fd86c578db 100644
--- a/xen/arch/x86/hvm/svm/avic.c
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -48,6 +48,11 @@ bool svm_avic = false;
 static const char __section(".bss.page_aligned.const") __aligned(PAGE_SIZE)
 avic_backing_page[PAGE_SIZE];
 
+static inline const bool svm_is_avic_domain(struct domain *d)
+{
+return d->arch.hvm_domain.svm.avic_physical_id_table != 0;
+}
+
 static struct avic_physical_id_entry*
 avic_get_physical_id_entry(struct svm_domain *d, unsigned int index)
 {
@@ -252,6 +257,8 @@ void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs 
*regs)
 u32 id = vmcb->exitinfo2 >> 32;
 u32 index = vmcb->exitinfo2 && 0xFF;
 
+curr->arch.hvm_svm.cnt_avic_incomp_ipi++;
+
 switch ( id )
 {
 case AVIC_INCMP_IPI_ERR_INVALID_INT_TYPE:
@@ -494,6 +501,8 @@ void svm_avic_vmexit_do_noaccel(struct cpu_user_regs *regs)
 u32 offset = vmcb->exitinfo1 & 0xFF0;
 u32 rw = (vmcb->exitinfo1 >> 32) & 0x1;
 
+curr->arch.hvm_svm.cnt_avic_noaccel++;
+
 if ( avic_is_trap(offset) )
 {
 /* Handling AVIC Trap (intercept right after the access). */
@@ -541,14 +550,57 @@ void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec)
 if ( vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) )
 return;
 
+v->arch.hvm_svm.cnt_avic_post_intr++;
 /*
  * If vcpu is running on another cpu, hit the doorbell to signal
  * it to process interrupt. Otherwise, kick it.
  */
 if ( v->is_running && (v != current) )
+{
 wrmsrl(MSR_AMD_AVIC_DOORBELL, cpu_data[v->processor].apicid);
-else
+v->arch.hvm_svm.cnt_avic_doorbell++;
+}
+else {
 vcpu_kick(v);
+}
+}
+
+void dump_avic_info()
+{
+struct domain *d;
+struct vcpu *v;
+
+if ( !svm_avic )
+return;
+
+printk("*** SVM AVIC Statistics **\n");
+
+rcu_read_lock(_read_lock);
+
+for_each_domain ( d )
+{
+if ( !svm_is_avic_domain(d) )
+continue;
+
+printk(">>> Domain %d <<<\n", d->domain_id);
+for_each_vcpu ( d, v )
+{
+printk("\tVCPU %d\n", v->vcpu_id);
+printk("\t* incomp_ipi = %u\n",
+   v->arch.hvm_svm.cnt_avic_incomp_ipi);
+printk("\t* noaccel= %u\n",
+   v->arch.hvm_svm.cnt_avic_noaccel);
+printk("\t* post_intr  = %u\n",
+   v->arch.hvm_svm.cnt_avic_post_intr);
+printk("\t* doorbell   = %u\n",
+   v->arch.hvm_svm.cnt_avic_doorbell);
+}
+}
+
+rcu_read_unlock(_read_lock);
+
+printk("**\n");
+
 }
 
 /*
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 87ef2e801f..62fe9c3177 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -2351,6 +2352,7 @@ static void dump_irqs(unsigned char key)
 printk("   %#02x -> %ps()\n", i, direct_apic_vector[i]);
 
 dump_ioapic_irq_info();
+dump_avic_info();
 }
 
 static int __init setup_dump_irqs(void)
diff --git a/xen/include/asm-x86/hvm/svm/avic.h 
b/xen/include/asm-x86/hvm/svm/avic.h
index 8e8c4c9422..92326a77a3 100644
--- a/xen/include/asm-x86/hvm/svm/avic.h
+++ b/xen/include/asm-x86/hvm/svm/avic.h
@@ -40,4 +40,7 @@ void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs 
*regs);
 void svm_avic_vmexit_do_noaccel(struct cpu_user_regs *regs);
 
 void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vector);
+
+void dump_avic_info(void);
+
 #endif /* _SVM_AVIC_H_ */
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index f27bdbd83d..e902d51b25 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -557,6 +557,12 @@ struct arch_svm_struct {
 
 struct avic_physical_id_entry *avic_last_phy_id;
 u32 avic_last_ldr;
+
+ 

[Xen-devel] [PATCH v2 08/10] x86/HVM: Hook up miscellaneous AVIC functions

[Janakarajan Natarajan]

From: Suravee Suthikulpanit 

This patch modifies the hvm_function_table.virtual_intr_delivery_enabled()
to become a bool variable as both VMX and SVM simply return static value.

Also, this patch hooks up virtual_intr_delivery_enabled and
deliver_posted_intr functions when AVIC is enabled.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/svm.c|  3 +++
 xen/arch/x86/hvm/vlapic.c | 12 ++--
 xen/arch/x86/hvm/vmx/vmx.c|  8 ++--
 xen/include/asm-x86/hvm/hvm.h |  4 +++-
 4 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 15744a16a7..3057d232bc 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1730,7 +1730,10 @@ const struct hvm_function_table * __init start_svm(void)
 svm_avic = 0;
 
 if ( svm_avic )
+{
 svm_function_table.deliver_posted_intr  = svm_avic_deliver_posted_intr;
+svm_function_table.virtual_intr_delivery_enabled = svm_avic;
+}
 
 #define P(p,s) if ( p ) { printk(" - %s\n", s); printed = 1; }
 P(cpu_has_svm_npt, "Nested Page Tables (NPT)");
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index eb71cc21ed..7fccfb4f06 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1258,14 +1258,6 @@ void vlapic_adjust_i8259_target(struct domain *d)
 pt_adjust_global_vcpu_target(v);
 }
 
-int vlapic_virtual_intr_delivery_enabled(void)
-{
-if ( hvm_funcs.virtual_intr_delivery_enabled )
-return hvm_funcs.virtual_intr_delivery_enabled();
-else
-return 0;
-}
-
 int vlapic_has_pending_irq(struct vcpu *v)
 {
 struct vlapic *vlapic = vcpu_vlapic(v);
@@ -1278,7 +1270,7 @@ int vlapic_has_pending_irq(struct vcpu *v)
 if ( irr == -1 )
 return -1;
 
-if ( vlapic_virtual_intr_delivery_enabled() &&
+if ( hvm_funcs.virtual_intr_delivery_enabled &&
  !nestedhvm_vcpu_in_guestmode(v) )
 return irr;
 
@@ -1316,7 +1308,7 @@ int vlapic_ack_pending_irq(struct vcpu *v, int vector, 
bool_t force_ack)
 int isr;
 
 if ( !force_ack &&
- vlapic_virtual_intr_delivery_enabled() )
+ hvm_funcs.virtual_intr_delivery_enabled )
 return 1;
 
 /* If there's no chance of using APIC assist then bail now. */
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 970751494c..8c228c4bab 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1900,11 +1900,6 @@ static void vmx_update_eoi_exit_bitmap(struct vcpu *v, 
u8 vector, u8 trig)
 vmx_clear_eoi_exit_bitmap(v, vector);
 }
 
-static int vmx_virtual_intr_delivery_enabled(void)
-{
-return cpu_has_vmx_virtual_intr_delivery;
-}
-
 static void vmx_process_isr(int isr, struct vcpu *v)
 {
 unsigned long status;
@@ -2283,7 +2278,6 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .nhvm_intr_blocked= nvmx_intr_blocked,
 .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
 .update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
-.virtual_intr_delivery_enabled = vmx_virtual_intr_delivery_enabled,
 .process_isr  = vmx_process_isr,
 .deliver_posted_intr  = vmx_deliver_posted_intr,
 .sync_pir_to_irr  = vmx_sync_pir_to_irr,
@@ -2423,6 +2417,8 @@ const struct hvm_function_table * __init start_vmx(void)
 vmx_function_table.process_isr = NULL;
 vmx_function_table.handle_eoi = NULL;
 }
+else
+vmx_function_table.virtual_intr_delivery_enabled = true;
 
 if ( cpu_has_vmx_posted_intr_processing )
 {
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index ef5e198ebd..8d2f0c1acc 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -97,6 +97,9 @@ struct hvm_function_table {
 /* Necessary hardware support for alternate p2m's? */
 bool altp2m_supported;
 
+/* Hardware virtual interrupt delivery enable? */
+bool virtual_intr_delivery_enabled;
+
 /* Indicate HAP capabilities. */
 unsigned int hap_capabilities;
 
@@ -195,7 +198,6 @@ struct hvm_function_table {
 
 /* Virtual interrupt delivery */
 void (*update_eoi_exit_bitmap)(struct vcpu *v, u8 vector, u8 trig);
-int (*virtual_intr_delivery_enabled)(void);
 void (*process_isr)(int isr, struct vcpu *v);
 void (*deliver_posted_intr)(struct vcpu *v, u8 vector);
 void (*sync_pir_to_irr)(struct vcpu *v);
-- 
2.11.0


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

[Xen-devel] [PATCH v2 04/10] x86/HVM/SVM: Add AVIC initialization code

[Janakarajan Natarajan]

From: Suravee Suthikulpanit 

Introduce AVIC base initialization code. This includes:
* Setting up per-VM data structures.
* Setting up per-vCPU data structure.
* Initializing AVIC-related VMCB bit fields.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Janakarajan Natarajan 
---
 xen/arch/x86/hvm/svm/Makefile  |   1 +
 xen/arch/x86/hvm/svm/avic.c| 190 +
 xen/arch/x86/hvm/svm/svm.c |   8 +-
 xen/arch/x86/hvm/svm/vmcb.c|   3 +
 xen/arch/x86/hvm/vlapic.c  |   4 +
 xen/include/asm-x86/hvm/svm/avic.h |  39 
 xen/include/asm-x86/hvm/svm/svm.h  |   2 +
 xen/include/asm-x86/hvm/svm/vmcb.h |  18 
 8 files changed, 264 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/x86/hvm/svm/avic.c
 create mode 100644 xen/include/asm-x86/hvm/svm/avic.h

diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
index 760d2954da..e0e4a59f7d 100644
--- a/xen/arch/x86/hvm/svm/Makefile
+++ b/xen/arch/x86/hvm/svm/Makefile
@@ -1,4 +1,5 @@
 obj-y += asid.o
+obj-y += avic.o
 obj-y += emulate.o
 obj-bin-y += entry.o
 obj-y += intr.o
diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
new file mode 100644
index 00..d6b8638bab
--- /dev/null
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -0,0 +1,190 @@
+/*
+ * avic.c: implements AMD Advanced Virtual Interrupt Controller (AVIC) support
+ * Copyright (c) 2018, Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Note: Current max index allowed for physical APIC ID table is 255. */
+#define AVIC_PHY_APIC_ID_MAXGET_xAPIC_ID(APIC_ID_MASK)
+
+/*
+ * Note:
+ * Currently, svm-avic mode is not supported with nested virtualization.
+ * Therefore, it is not yet currently enabled by default. Once the support
+ * is in-place, this should be enabled by default.
+ */
+bool svm_avic = false;
+
+static const char __section(".bss.page_aligned.const") __aligned(PAGE_SIZE)
+avic_backing_page[PAGE_SIZE];
+
+static struct avic_physical_id_entry*
+avic_get_physical_id_entry(struct svm_domain *d, unsigned int index)
+{
+if ( !d->avic_physical_id_table )
+return NULL;
+
+/*
+* Note: APIC ID = 0xFF is used for broadcast.
+*   APIC ID > 0xFF is reserved.
+*/
+ASSERT(index < AVIC_PHY_APIC_ID_MAX);
+
+if ( index >= AVIC_PHY_APIC_ID_MAX )
+return NULL;
+
+return >avic_physical_id_table[index];
+}
+
+int svm_avic_dom_init(struct domain *d)
+{
+int ret = 0;
+struct page_info *pg;
+
+if ( !svm_avic || !has_vlapic(d) )
+return 0;
+
+/*
+ * Note:
+ * AVIC hardware walks the nested page table to check permissions,
+ * but does not use the SPA address specified in the leaf page
+ * table entry since it uses  address in the AVIC_BACKING_PAGE pointer
+ * field of the VMCB. Therefore, we set up a dummy page for APIC.
+ */
+set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE),
+   _mfn(virt_to_mfn(avic_backing_page)), PAGE_ORDER_4K,
+   p2m_access_rw);
+
+/* Init AVIC logical APIC ID table */
+pg = alloc_domheap_page(d, MEMF_no_owner);
+if ( !pg )
+{
+ret = -ENOMEM;
+goto err_out;
+}
+clear_domain_page(page_to_mfn(pg));
+d->arch.hvm_domain.svm.avic_logical_id_table_pg = pg;
+d->arch.hvm_domain.svm.avic_logical_id_table = 
__map_domain_page_global(pg);
+
+/* Init AVIC physical APIC ID table */
+pg = alloc_domheap_page(d, MEMF_no_owner);
+if ( !pg )
+{
+ret = -ENOMEM;
+goto err_out;
+}
+clear_domain_page(page_to_mfn(pg));
+d->arch.hvm_domain.svm.avic_physical_id_table_pg = pg;
+d->arch.hvm_domain.svm.avic_physical_id_table = 
__map_domain_page_global(pg);
+
+return ret;
+ err_out:
+svm_avic_dom_destroy(d);
+return ret;
+}
+
+void svm_avic_dom_destroy(struct domain *d)
+{
+if ( !svm_avic || !has_vlapic(d) )
+return;
+
+if ( d->arch.hvm_domain.svm.avic_physical_id_table )
+{
+
unmap_domain_page_global(d->arch.hvm_domain.svm.avic_physical_id_table);
+

[Xen-devel] [PATCH v2 06/10] x86/SVM: Add vcpu scheduling support for AVIC

[Janakarajan Natarajan]

From: Suravee Suthikulpanit 

Add hooks to manage AVIC data structure during vcpu scheduling.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Janakarajan Natarajan 
---
 xen/arch/x86/hvm/svm/avic.c | 51 +
 xen/arch/x86/hvm/svm/svm.c  | 10 +
 2 files changed, 61 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
index 2fba35fe47..7cc10c313a 100644
--- a/xen/arch/x86/hvm/svm/avic.c
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -36,6 +36,7 @@
 
 #define AVIC_UNACCEL_ACCESS_OFFSET_MASK0xFF0
 
+#define IS_RUNNING_BIT62
 /*
  * Note:
  * Currently, svm-avic mode is not supported with nested virtualization.
@@ -65,6 +66,51 @@ avic_get_physical_id_entry(struct svm_domain *d, unsigned 
int index)
 return >avic_physical_id_table[index];
 }
 
+static void avic_vcpu_load(struct vcpu *v)
+{
+struct arch_svm_struct *s = >arch.hvm_svm;
+int h_phy_apic_id;
+
+ASSERT(!test_bit(_VPF_blocked, >pause_flags));
+
+/*
+ * Note: APIC ID = 0xff is used for broadcast.
+ *   APIC ID > 0xff is reserved.
+ */
+h_phy_apic_id = cpu_data[v->processor].apicid;
+ASSERT(h_phy_apic_id < AVIC_PHY_APIC_ID_MAX);
+
+s->avic_last_phy_id->host_phy_apic_id = h_phy_apic_id;
+smp_wmb();
+set_bit(IS_RUNNING_BIT, (u64*)(s->avic_last_phy_id));
+}
+
+static void avic_vcpu_unload(struct vcpu *v)
+{
+struct arch_svm_struct *s = >arch.hvm_svm;
+
+clear_bit(IS_RUNNING_BIT, (u64*)(s->avic_last_phy_id));
+}
+
+static void avic_vcpu_resume(struct vcpu *v)
+{
+struct arch_svm_struct *s = >arch.hvm_svm;
+
+ASSERT(svm_avic_vcpu_enabled(v));
+ASSERT(!test_bit(_VPF_blocked, >pause_flags));
+
+set_bit(IS_RUNNING_BIT, (u64*)(s->avic_last_phy_id));
+}
+
+static void avic_vcpu_block(struct vcpu *v)
+{
+struct arch_svm_struct *s = >arch.hvm_svm;
+
+ASSERT(svm_avic_vcpu_enabled(v));
+
+clear_bit(IS_RUNNING_BIT, (u64*)(s->avic_last_phy_id));
+}
+
 int svm_avic_dom_init(struct domain *d)
 {
 int ret = 0;
@@ -108,6 +154,11 @@ int svm_avic_dom_init(struct domain *d)
 
 spin_lock_init(>arch.hvm_domain.svm.avic_dfr_mode_lock);
 
+d->arch.hvm_domain.pi_ops.switch_from = avic_vcpu_unload;
+d->arch.hvm_domain.pi_ops.switch_to = avic_vcpu_load;
+d->arch.hvm_domain.pi_ops.vcpu_block = avic_vcpu_block;
+d->arch.hvm_domain.pi_ops.do_resume = avic_vcpu_resume;
+
 return ret;
  err_out:
 svm_avic_dom_destroy(d);
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 249059625c..b3e3c84175 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1088,6 +1088,10 @@ static void svm_ctxt_switch_from(struct vcpu *v)
 svm_tsc_ratio_save(v);
 
 svm_sync_vmcb(v);
+
+if ( v->domain->arch.hvm_domain.pi_ops.switch_from )
+v->domain->arch.hvm_domain.pi_ops.switch_from(v);
+
 svm_vmload_pa(per_cpu(host_vmcb, cpu));
 
 /* Resume use of ISTs now that the host TR is reinstated. */
@@ -1120,6 +1124,9 @@ static void svm_ctxt_switch_to(struct vcpu *v)
 svm_lwp_load(v);
 svm_tsc_ratio_load(v);
 
+if ( v->domain->arch.hvm_domain.pi_ops.switch_to )
+v->domain->arch.hvm_domain.pi_ops.switch_to(v);
+
 if ( cpu_has_rdtscp )
 wrmsr_tsc_aux(hvm_msr_tsc_aux(v));
 }
@@ -1167,6 +1174,9 @@ static void noreturn svm_do_resume(struct vcpu *v)
 vmcb_set_vintr(vmcb, intr);
 }
 
+if ( v->domain->arch.hvm_domain.pi_ops.do_resume )
+v->domain->arch.hvm_domain.pi_ops.do_resume(v);
+
 hvm_do_resume(v);
 
 reset_stack_and_jump(svm_asm_do_resume);
-- 
2.11.0


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

[Xen-devel] [PATCH v2 01/10] x86/SVM: Modify VMCB fields to add AVIC support

[Janakarajan Natarajan]

From: Suravee Suthikulpanit 

Introduce AVIC-related VMCB fields.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Janakarajan Natarajan 
---
 xen/include/asm-x86/hvm/svm/vmcb.h | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index de07429dff..591d98fc8c 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -324,16 +324,17 @@ typedef union
 struct
 {
 u64 tpr:  8;
-u64 irq:  1;
+u64 irq:  1; /* ignored in avic mode */
 u64 vgif: 1;
 u64 rsvd0:6;
-u64 prio: 4;
-u64 ign_tpr:  1;
+u64 prio: 4; /* ignored in avic mode */
+u64 ign_tpr:  1; /* ignored in avic mode */
 u64 rsvd1:3;
 u64 intr_masking: 1;
 u64 vgif_enable:  1;
-u64 rsvd2:6;
-u64 vector:   8;
+u64 rsvd2:5;
+u64 avic_enable:  1;
+u64 vector:   8; /* ignored in avic mode */
 u64 rsvd3:   24;
 } fields;
 } vintr_t;
@@ -393,7 +394,8 @@ typedef union
 uint32_t cr2: 1;
 /* debugctlmsr, last{branch,int}{to,from}ip */
 uint32_t lbr: 1;
-uint32_t resv: 21;
+uint32_t avic: 1;
+uint32_t resv: 20;
 } fields;
 } vmcbcleanbits_t;
 
@@ -427,7 +429,8 @@ struct vmcb_struct {
 u64 exitinfo2;  /* offset 0x80 */
 eventinj_t  exitintinfo;/* offset 0x88 */
 u64 _np_enable; /* offset 0x90 - cleanbit 4 */
-u64 res08[2];
+u64 avic_vapic_bar; /* offset 0x98 */
+u64 res08;  /* offset 0xA0 */
 eventinj_t  eventinj;   /* offset 0xA8 */
 u64 _h_cr3; /* offset 0xB0 - cleanbit 4 */
 virt_ext_t virt_ext;/* offset 0xB8 */
@@ -436,7 +439,11 @@ struct vmcb_struct {
 u64 nextrip;/* offset 0xC8 */
 u8  guest_ins_len;  /* offset 0xD0 */
 u8  guest_ins[15];  /* offset 0xD1 */
-u64 res10a[100];/* offset 0xE0 pad to save area */
+u64 avic_bk_pg_pa;  /* offset 0xE0 */
+u64 res09a; /* offset 0xE8 */
+u64 avic_logical_id_table_pa;  /* offset 0xF0 */
+u64 avic_physical_id_table_pa; /* offset 0xF8 */
+u64 res10a[96]; /* offset 0x100 pad to save area */
 
 union {
 struct segment_register sreg[6];
-- 
2.11.0


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

[Xen-devel] [PATCH v2 07/10] x86/SVM: Add interrupt management code via AVIC

[Janakarajan Natarajan]

From: Suravee Suthikulpanit 

Enabling AVIC implicitly disables the V_IRQ, V_INTR_PRIO, V_IGN_TPR,
and V_INTR_VECTOR fields in the VMCB Control Word. Therefore, this patch
introduces new interrupt injection code via AVIC backing page.

Signed-off-by: Suravee Suthikulpanit 
---
 xen/arch/x86/hvm/svm/avic.c| 29 +
 xen/arch/x86/hvm/svm/intr.c|  4 
 xen/arch/x86/hvm/svm/svm.c | 15 +--
 xen/include/asm-x86/hvm/svm/avic.h |  1 +
 xen/include/asm-x86/msr-index.h|  1 +
 5 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
index 7cc10c313a..19caaeda53 100644
--- a/xen/arch/x86/hvm/svm/avic.c
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -522,6 +522,35 @@ void svm_avic_vmexit_do_noaccel(struct cpu_user_regs *regs)
 return;
 }
 
+void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec)
+{
+struct vlapic *vlapic = vcpu_vlapic(v);
+
+/* Fallback to use non-AVIC if vcpu is not enabled with AVIC. */
+if ( !svm_avic_vcpu_enabled(v) )
+{
+if ( !vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) )
+vcpu_kick(v);
+return;
+}
+
+/* If interrupt is disabled, do not ignore the interrupt */
+if ( !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
+return;
+
+if ( vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) )
+return;
+
+/*
+ * If vcpu is running on another cpu, hit the doorbell to signal
+ * it to process interrupt. Otherwise, kick it.
+ */
+if ( v->is_running && (v != current) )
+wrmsrl(MSR_AMD_AVIC_DOORBELL, cpu_data[v->processor].apicid);
+else
+vcpu_kick(v);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
index 8511ff0b70..8c5a2eb2cd 100644
--- a/xen/arch/x86/hvm/svm/intr.c
+++ b/xen/arch/x86/hvm/svm/intr.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include  /* for nestedhvm_vcpu_in_guestmode */
@@ -100,6 +101,9 @@ static void svm_enable_intr_window(struct vcpu *v, struct 
hvm_intack intack)
 HVMTRACE_3D(INTR_WINDOW, intack.vector, intack.source,
 vmcb->eventinj.fields.v?vmcb->eventinj.fields.vector:-1);
 
+if ( svm_avic_vcpu_enabled(v) )
+return;
+
 /*
  * Create a dummy virtual interrupt to intercept as soon as the
  * guest can accept the real interrupt.
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b3e3c84175..15744a16a7 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1163,7 +1163,8 @@ static void noreturn svm_do_resume(struct vcpu *v)
 hvm_asid_flush_vcpu(v);
 }
 
-if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
+if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) &&
+ !svm_avic_vcpu_enabled(v) )
 {
 vintr_t intr;
 
@@ -1728,6 +1729,9 @@ const struct hvm_function_table * __init start_svm(void)
 if ( !cpu_has_svm_avic )
 svm_avic = 0;
 
+if ( svm_avic )
+svm_function_table.deliver_posted_intr  = svm_avic_deliver_posted_intr;
+
 #define P(p,s) if ( p ) { printk(" - %s\n", s); printed = 1; }
 P(cpu_has_svm_npt, "Nested Page Tables (NPT)");
 P(cpu_has_svm_lbrv, "Last Branch Record (LBR) Virtualisation");
@@ -2559,7 +2563,8 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
  * NB. We need to preserve the low bits of the TPR to make checked builds
  * of Windows work, even though they don't actually do anything.
  */
-if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) )
+if ( !vcpu_guestmode && !vlapic_hw_disabled(vlapic) &&
+ !svm_avic_vcpu_enabled(v) )
 {
 intr = vmcb_get_vintr(vmcb);
 vlapic_set_reg(vlapic, APIC_TASKPRI,
@@ -2792,6 +2797,12 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
 intr = vmcb_get_vintr(vmcb);
 
+if ( svm_avic_vcpu_enabled(v) )
+{
+gdprintk(XENLOG_ERR, "AVIC VINTR:\n");
+domain_crash(v->domain);
+}
+
 intr.fields.irq = 0;
 general1_intercepts &= ~GENERAL1_INTERCEPT_VINTR;
 
diff --git a/xen/include/asm-x86/hvm/svm/avic.h 
b/xen/include/asm-x86/hvm/svm/avic.h
index 1961daa578..8e8c4c9422 100644
--- a/xen/include/asm-x86/hvm/svm/avic.h
+++ b/xen/include/asm-x86/hvm/svm/avic.h
@@ -39,4 +39,5 @@ int svm_avic_init_vmcb(struct vcpu *v);
 void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs *regs);
 void svm_avic_vmexit_do_noaccel(struct cpu_user_regs *regs);
 
+void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vector);
 #endif /* _SVM_AVIC_H_ */
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index 8416756f02..f37b08bf83 100644
--- 

[Xen-devel] [PATCH v2 02/10] x86/HVM: Rename vlapic_read_aligned() to vlapic_reg_read()

[Janakarajan Natarajan]

Rename vlapic_read_aligned() to vlapic_reg_read() to make it a pair of
vlapic_reg_write().

Signed-off-by: Janakarajan Natarajan 
---
 xen/arch/x86/hvm/vlapic.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 1b9f00a0e4..c9b6461cbf 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -592,7 +592,7 @@ static void vlapic_set_tdcr(struct vlapic *vlapic, unsigned 
int val)
 "timer_divisor: %d", vlapic->hw.timer_divisor);
 }
 
-static uint32_t vlapic_read_aligned(const struct vlapic *vlapic,
+static uint32_t vlapic_reg_read(const struct vlapic *vlapic,
 unsigned int offset)
 {
 switch ( offset )
@@ -627,7 +627,7 @@ static int vlapic_read(
 if ( offset > (APIC_TDCR + 0x3) )
 goto out;
 
-tmp = vlapic_read_aligned(vlapic, offset & ~3);
+tmp = vlapic_reg_read(vlapic, offset & ~3);
 
 switch ( len )
 {
@@ -691,10 +691,10 @@ int hvm_x2apic_msr_read(struct vcpu *v, unsigned int msr, 
uint64_t *msr_content)
 return X86EMUL_UNHANDLEABLE;
 
 if ( offset == APIC_ICR )
-high = vlapic_read_aligned(vlapic, APIC_ICR2);
+high = vlapic_reg_read(vlapic, APIC_ICR2);
 
 *msr_content = ((uint64_t)high << 32) |
-   vlapic_read_aligned(vlapic, offset);
+   vlapic_reg_read(vlapic, offset);
 
 return X86EMUL_OKAY;
 }
@@ -926,7 +926,7 @@ static int vlapic_write(struct vcpu *v, unsigned long 
address,
  */
 if ( unlikely(len != 4) )
 {
-unsigned int tmp = vlapic_read_aligned(vlapic, offset & ~3);
+unsigned int tmp = vlapic_reg_read(vlapic, offset & ~3);
 unsigned char alignment = (offset & 3) * 8;
 
 switch ( len )
-- 
2.11.0


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

[Xen-devel] [PATCH v2 00/10] Introduce AMD SVM AVIC

[Janakarajan Natarajan]

OVERVIEW

This patchset is the first of a two-part patch series to introduce
the AMD Advanced Virtual Interrupt Controller (AVIC) support.

The AVIC hardware virtualizes local APIC registers of each vCPU via
the virtual APIC (vAPIC) backing page. This allows the guest to access
certain APIC registers without the need for emulation of hardware
behaviour in the hypervisor. More information about AVIC can be found in

* AMD64 Architecture Programmers Manual Volume 2 - System Programming
  https://support.amd.com/TechDocs/24593.pdf

For SVM AVIC, we extend the existing SVM driver to:
* Check CPUID to detect AVIC support in the processor.
* Program new fields in VMCB to enable AVIC.
* Introduce new AVIC data structures and add code to manage them.
* Handle two new AVIC #VMEXITs.
* Add new interrupt injection code using vAPIC backing page
  instead of the existing V_IRQ, V_INTR_PRIO, V_INTR_VECTOR and
  V_IGN_TPR fields.

This patchset does not enable AVIC by default since it does not
yet support nested VMs. Until then, users can enable SVM AVIC by
specifying Xen parameter svm=avic.

Later, in Part 2, we will introduce the IOMMU AVIC support, which
provides speed-up for the PCI device passthrough use case by allowing
the IOMMU hardware to inject interrupts directly into the guest via
the vAPIC backing page.

OVERALL PERFORMANCE
===
AVIC is available on AMD Family 15h models 6Xh (Carrizo) processors
and newer. An AMD Family 17h Epyc processor is used to collect the
performance data shown below.

Generally, SVM AVIC alone (w/o IOMMU AVIC) should provide overall
speed-up for HVM guest since it does not require #VMEXIT into the
hypervisor to emulate certain guest accesses to local APIC registers.

It should also improve performance when the hypervisor wants to
inject interrupts into a running vcpu. It can do this by setting the 
corresponding IRR bit in the vAPIC backing page and triggering the
AVIC_DOORBELL.

For sending IPI interrupts between running vcpus in a Linux guest,
Xen defaults to using event channels. However, in case of
non-paravirtualized guests, AVIC can also provide performance
improvements for sending IPIs.

BENCHMARK: HACKBENCH

For measuring IPI performance used for scheduling workload, some
performance numbers are collected using hackbench.

# hackbench -p -l 10
Running in process mode with 10 groups using 40 file descriptors
each (== 400 tasks)
Each sender will pass 10 messages of 100 bytes
  |  3 vcpus (sec)|
---
No AVIC w/ xen_nopv   |   517 |
AVIC w/ xen_nopv  |   238 |
No AVIC w/o xen_nopv  |   141 |
AVIC w/o xen_nopv |   135 |

Each benchmark test was averaged over 10 runs.

CURRENT UNTESTED USE_CASES
==
* Nested VM

Any feedback and comments are very much appreciated.

v1->v2:
* Remove use of MFN 0 as dummy page for AVIC as suggested by
  Jan and Andrew.
* Rename vlapic_read_aligned().
* Moved AVIC stats dump from new keyhandler to IRQ keyhandler.
* Changed avic_logical_id_entry from struct to union.
* Updated cover letter and patch descriptions.
* Miscellaneous fixes based on feedback.

Janakarajan Natarajan (2):
  x86/HVM: Rename vlapic_read_aligned() to vlapic_reg_read()
  x86/HVM: Make vlapic_reg_read/write() non-static

Suravee Suthikulpanit (8):
  x86/SVM: Modify VMCB fields to add AVIC support
  x86/HVM/SVM: Add AVIC initialization code
  x86/SVM: Add AVIC vmexit handlers
  x86/SVM: Add vcpu scheduling support for AVIC
  x86/SVM: Add interrupt management code via AVIC
  x86/HVM: Hook up miscellaneous AVIC functions
  x86/SVM: Introduce svm command line option
  x86/SVM: Append AMD AVIC related data to IRQ keyhandler 'i'

 docs/misc/xen-command-line.markdown |  16 +
 xen/arch/x86/hvm/svm/Makefile   |   1 +
 xen/arch/x86/hvm/svm/avic.c | 614 
 xen/arch/x86/hvm/svm/intr.c |   4 +
 xen/arch/x86/hvm/svm/svm.c  |  76 -
 xen/arch/x86/hvm/svm/vmcb.c |   3 +
 xen/arch/x86/hvm/vlapic.c   |  28 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   8 +-
 xen/arch/x86/irq.c  |   2 +
 xen/include/asm-x86/hvm/hvm.h   |   4 +-
 xen/include/asm-x86/hvm/svm/avic.h  |  46 +++
 xen/include/asm-x86/hvm/svm/svm.h   |   2 +
 xen/include/asm-x86/hvm/svm/vmcb.h  |  53 +++-
 xen/include/asm-x86/hvm/vlapic.h|   4 +
 xen/include/asm-x86/msr-index.h |   1 +
 15 files changed, 828 insertions(+), 34 deletions(-)
 create mode 100644 xen/arch/x86/hvm/svm/avic.c
 create mode 100644 xen/include/asm-x86/hvm/svm/avic.h

-- 
2.11.0


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

[Xen-devel] [PATCH v2 09/10] x86/SVM: Introduce svm command line option

[Janakarajan Natarajan]

From: Suravee Suthikulpanit 

This patch introduces a new Xen command line option to enable/disable
SVM sub-options. Currently, it supports sub-option "avic", which can
be used to enable/disable SVM AVIC feature.

Signed-off-by: Suavee Suthikulpant 
Signed-off-by: Janakarajan Natarajan 
---
 docs/misc/xen-command-line.markdown | 16 
 xen/arch/x86/hvm/svm/svm.c  | 32 
 2 files changed, 48 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index b353352adf..60a1005c42 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1730,6 +1730,22 @@ enforces the maximum theoretically necessary timeout of 
670ms. Any number
 is being interpreted as a custom timeout in milliseconds. Zero or boolean
 false disable the quirk workaround, which is also the default.
 
+### svm
+> `= List of [ avic ]`
+
+> Sub-options:
+
+> All sub-options are of boolean kind and can be prefixed with `no-` to
+> effect the inverse meaning.
+
+> `avic`
+
+> Default: `false`
+
+>> This option enables Advanced Virtual Interrupt Controller (AVIC),
+>> which is an extension of AMD Secure Virtual Machine (SVM) to virtualize
+>> local APIC for guest VM.
+
 ### sync\_console
 > `= `
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 3057d232bc..bf851f83a1 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -64,6 +64,16 @@
 #include 
 #include 
 
+static int parse_svm_param(const char *s);
+
+/*
+ * The 'svm' parameter en/dis-ables various SVM features.
+ * Optional comma separated value may contain:
+ *
+ *   avic - Enable SVM Advanced Virtual Interrupt Controller (AVIC)
+ */
+custom_param("svm", parse_svm_param);
+
 void svm_asm_do_resume(void);
 
 u32 svm_feature_flags;
@@ -89,6 +99,28 @@ static bool_t amd_erratum383_found __read_mostly;
 static uint64_t osvw_length, osvw_status;
 static DEFINE_SPINLOCK(osvw_lock);
 
+static int __init parse_svm_param(const char *s)
+{
+char *ss;
+int val;
+
+do {
+val = !!strncmp(s, "no-", 3);
+if ( !val )
+s += 3;
+
+ss = strchr(s, ',');
+if ( ss )
+*ss = '\0';
+
+if ( !strcmp(s, "avic") )
+svm_avic = val;
+
+s = ss + 1;
+} while ( ss );
+
+return 0;
+}
 /* Only crash the guest if the problem originates in kernel mode. */
 static void svm_crash_or_fault(struct vcpu *v)
 {
-- 
2.11.0


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

[Xen-devel] [PATCH v2 05/10] x86/SVM: Add AVIC vmexit handlers

[Janakarajan Natarajan]

From: Suravee Suthikulpanit 

AVIC introduces two new #vmexit handlers:

VMEXIT_INCOMP_IPI:
This occurs when an IPI could not be delivered to all targeted guest
virtual processors because at least one guest virtual processor
was not allocated to a physical core at the time. In this case,
Xen would try to emulate IPI.

VMEXIT_DO_NOACCEL:
This occurs when a guest access to an APIC register that cannot be
accelerated by AVIC. In this case, Xen tries to emulate register accesses.

This fault is also generated if an EOI is attempted when the highest priority
in-service interrupt is set for level-triggered mode.

Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Janakarajan Natarajan 
---
 xen/arch/x86/hvm/svm/avic.c| 292 +
 xen/arch/x86/hvm/svm/svm.c |   8 +
 xen/include/asm-x86/hvm/svm/avic.h |   3 +
 xen/include/asm-x86/hvm/svm/vmcb.h |   6 +
 4 files changed, 309 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
index d6b8638bab..2fba35fe47 100644
--- a/xen/arch/x86/hvm/svm/avic.c
+++ b/xen/arch/x86/hvm/svm/avic.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,8 @@
 /* Note: Current max index allowed for physical APIC ID table is 255. */
 #define AVIC_PHY_APIC_ID_MAXGET_xAPIC_ID(APIC_ID_MASK)
 
+#define AVIC_UNACCEL_ACCESS_OFFSET_MASK0xFF0
+
 /*
  * Note:
  * Currently, svm-avic mode is not supported with nested virtualization.
@@ -103,6 +106,8 @@ int svm_avic_dom_init(struct domain *d)
 d->arch.hvm_domain.svm.avic_physical_id_table_pg = pg;
 d->arch.hvm_domain.svm.avic_physical_id_table = 
__map_domain_page_global(pg);
 
+spin_lock_init(>arch.hvm_domain.svm.avic_dfr_mode_lock);
+
 return ret;
  err_out:
 svm_avic_dom_destroy(d);
@@ -180,6 +185,293 @@ int svm_avic_init_vmcb(struct vcpu *v)
 }
 
 /*
+ * Note:
+ * This function handles the AVIC_INCOMP_IPI #vmexit when AVIC is enabled.
+ * The hardware generates this fault when an IPI could not be delivered
+ * to all targeted guest virtual processors because at least one guest
+ * virtual processor was not allocated to a physical core at the time.
+ */
+void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs *regs)
+{
+struct vcpu *curr = current;
+struct domain *currd = curr->domain;
+struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
+u32 icrh = vmcb->exitinfo1 >> 32;
+u32 icrl = vmcb->exitinfo1;
+u32 id = vmcb->exitinfo2 >> 32;
+u32 index = vmcb->exitinfo2 && 0xFF;
+
+switch ( id )
+{
+case AVIC_INCMP_IPI_ERR_INVALID_INT_TYPE:
+/*
+ * AVIC hardware handles the delivery of
+ * IPIs when the specified Message Type is Fixed
+ * (also known as fixed delivery mode) and
+ * the Trigger Mode is edge-triggered. The hardware
+ * also supports self and broadcast delivery modes
+ * specified via the Destination Shorthand(DSH)
+ * field of the ICRL. Logical and physical APIC ID
+ * formats are supported. All other IPI types cause
+ * a #VMEXIT, which needs to emulated.
+ */
+vlapic_reg_write(curr, APIC_ICR2, icrh);
+vlapic_reg_write(curr, APIC_ICR, icrl);
+break;
+
+case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN:
+{
+/*
+ * At this point, we expect that the AVIC HW has already
+ * set the appropriate IRR bits on the valid target
+ * vcpus. So, we just need to kick the appropriate vcpu.
+ */
+struct vcpu *v;
+uint32_t dest = GET_xAPIC_DEST_FIELD(icrh);
+uint32_t short_hand = icrl & APIC_SHORT_MASK;
+bool dest_mode = icrl & APIC_DEST_MASK;
+
+for_each_vcpu ( currd,  v )
+{
+if ( v != curr &&
+ vlapic_match_dest(vcpu_vlapic(v), vcpu_vlapic(curr),
+   short_hand, dest, dest_mode) )
+{
+vcpu_kick(v);
+break;
+}
+}
+break;
+}
+
+case AVIC_INCMP_IPI_ERR_INV_TARGET:
+gprintk(XENLOG_ERR,
+"SVM: %s: Invalid IPI target (icr=%#08x:%08x, idx=%u)\n",
+__func__, icrh, icrl, index);
+domain_crash(currd);
+break;
+
+case AVIC_INCMP_IPI_ERR_INV_BK_PAGE:
+gprintk(XENLOG_ERR,
+"SVM: %s: Invalid bk page (icr=%#08x:%08x, idx=%u)\n",
+__func__, icrh, icrl, index);
+domain_crash(currd);
+break;
+
+default:
+gprintk(XENLOG_ERR, "SVM: %s: Unknown IPI interception (%#x)\n",
+__func__, id);
+domain_crash(currd);
+}
+}
+
+static avic_logical_id_entry_t *
+avic_get_logical_id_entry(struct svm_domain *d, u32 ldr, bool flat)
+{
+unsigned int index;
+unsigned int dest_id = 

[Xen-devel] [PATCH v2 03/10] x86/HVM: Make vlapic_reg_read/write() non-static

[Janakarajan Natarajan]

AMD AVIC code makes use of vlapic_reg_read() and vlapic_reg_write(). To
do this make the functions non-static.

Signed-off-by: Janakarajan Natarajan 
---
 xen/arch/x86/hvm/vlapic.c| 4 ++--
 xen/include/asm-x86/hvm/vlapic.h | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index c9b6461cbf..60d1f7e748 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -592,7 +592,7 @@ static void vlapic_set_tdcr(struct vlapic *vlapic, unsigned 
int val)
 "timer_divisor: %d", vlapic->hw.timer_divisor);
 }
 
-static uint32_t vlapic_reg_read(const struct vlapic *vlapic,
+uint32_t vlapic_reg_read(const struct vlapic *vlapic,
 unsigned int offset)
 {
 switch ( offset )
@@ -788,7 +788,7 @@ static void vlapic_update_timer(struct vlapic *vlapic, 
uint32_t lvtt,
 }
 }
 
-static void vlapic_reg_write(struct vcpu *v,
+void vlapic_reg_write(struct vcpu *v,
  unsigned int offset, uint32_t val)
 {
 struct vlapic *vlapic = vcpu_vlapic(v);
diff --git a/xen/include/asm-x86/hvm/vlapic.h b/xen/include/asm-x86/hvm/vlapic.h
index 212c36b5c2..692e34ad4c 100644
--- a/xen/include/asm-x86/hvm/vlapic.h
+++ b/xen/include/asm-x86/hvm/vlapic.h
@@ -137,6 +137,10 @@ void vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, 
uint32_t icr_high);
 
 int vlapic_apicv_write(struct vcpu *v, unsigned int offset);
 
+void vlapic_reg_write(struct vcpu *v, unsigned int offset, uint32_t val);
+
+uint32_t vlapic_reg_read(const struct vlapic *vlapic, unsigned int offset);
+
 struct vlapic *vlapic_lowest_prio(
 struct domain *d, const struct vlapic *source,
 int short_hand, uint32_t dest, bool_t dest_mode);
-- 
2.11.0


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

Re: [Xen-devel] [RFC PATCH] x86/pagewalk: Honor SMAP_CHECK_DISABLED

[Andrew Cooper]

On 07/05/2018 20:57, Jason Andryuk wrote:
> commit 4c5d78a10dc89427140a50a1df5a0b8e9f073e82 (x86/pagewalk:
> Re-implement the pagetable walker) removed honoring the
> smap_check_policy of the running VCPU.  guest_walk_tables is used by
> copy_{to,from}_guest for HVMs, so it is called when the hypervisor is
> copying data and SMAP is inappropriate to enforce.
>
> The out-of-tree v4v hypercall copies a domain's source buffer into a
> different domain's destination ring.  For an HVM, the kernel makes the
> hypercall from ring 0, so the userspace buffer access looks like a SMAP
> violation.  In Xen 4.6, v4v could set SMAP_CHECK_DISABLED to avoid this
> SMAP failure, but that no longer works since the re-write.
>
> Signed-off-by: Jason Andryuk 

I'm sorry, but no.  It is never appropriate to ignore the guest paging
settings.  The correct fix here is in the kernel, to surround the v4v
hypercall handler with stac/clac to whitelist userspace accesses.  See
the implementation of the privcmd hypercall which already does this.

If I could go back in time and nack the introduction of
smap_check_policy, I would.  As it stands, I'm (slowly) removing its
use, and will eventually delete it.

~Andrew

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

[Xen-devel] [RFC PATCH] x86/pagewalk: Honor SMAP_CHECK_DISABLED

[Jason Andryuk]

commit 4c5d78a10dc89427140a50a1df5a0b8e9f073e82 (x86/pagewalk:
Re-implement the pagetable walker) removed honoring the
smap_check_policy of the running VCPU.  guest_walk_tables is used by
copy_{to,from}_guest for HVMs, so it is called when the hypervisor is
copying data and SMAP is inappropriate to enforce.

The out-of-tree v4v hypercall copies a domain's source buffer into a
different domain's destination ring.  For an HVM, the kernel makes the
hypercall from ring 0, so the userspace buffer access looks like a SMAP
violation.  In Xen 4.6, v4v could set SMAP_CHECK_DISABLED to avoid this
SMAP failure, but that no longer works since the re-write.

Signed-off-by: Jason Andryuk 
---
commit 31ae587e6f0181bf1f7d196fe1b49357c8922e60 (x86/hvm: always do SMAP
check when updating runstate_guest(v)) added smap_check_policy
originally.  It contained SMAP_CHECK_ENABLED, SMAP_CHECK_DISABLED, and
SMAP_CHECK_HONOR_CPL_AC.  SMAP_CHECK_HONOR_CPL_AC is the default and
conditionalized the SMAP check on the CPL and EFLAGS.AC.
SMAP_CHECK_ENABLED always turned on the SMAP check.

guest_walk_tables no longer has a CPL check.  This seems to be set by
emulation code through the PFEC_user_mode or PFEC_implicit walk
arguments.  Also with the re-write, the EFLAGS.AC check is always
enforced.  So update_runstate_area and update_secondary_system_time may
no longer need the smap policy change?  SMAP_CHECK_HONOR_CPL_AC could
probably be dropped as well if that is the case.

 xen/arch/x86/mm/guest_walk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 6055fec1ad..627b7f91e8 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -416,6 +416,7 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 goto out;
 
 if ( !(walk & PFEC_insn_fetch) && guest_smap_enabled(v) &&
+ v->arch.smap_check_policy != SMAP_CHECK_DISABLED &&
  ((walk & PFEC_implicit) ||
   !(guest_cpu_user_regs()->eflags & X86_EFLAGS_AC)) )
 /* User data access and smap? Fail. */
-- 
2.14.3


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

Re: [Xen-devel] [PATCH 1/1] x86/xen: Reset VCPU0 info pointer after shared_info remap

[van der Linden, Frank]

On 5/7/18, 11:54 AM, "Boris Ostrovsky"  wrote:


OK, fair enough. This should go to stable as well I think (4.12+),
copying them.

Reviewed-by: Boris Ostrovsky 

Great, thanks Boris.

Frank

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

Re: [Xen-devel] [PATCH 1/1] x86/xen: Reset VCPU0 info pointer after shared_info remap

[Boris Ostrovsky]

On 05/07/2018 02:00 PM, van der Linden, Frank wrote:
> Hi Boris,
>
> Thanks for the feedback.
>
> On 5/7/18, 8:13 AM, "Boris Ostrovsky"  wrote:
>
> > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> > index 6b424da1ce75..c78b3e8fb2e5 100644
> > --- a/arch/x86/xen/enlighten_hvm.c
> > +++ b/arch/x86/xen/enlighten_hvm.c
> > @@ -71,6 +71,19 @@ static void __init xen_hvm_init_mem_mapping(void)
> >  {
> > early_memunmap(HYPERVISOR_shared_info, PAGE_SIZE);
> > HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
> > +
> > +   /*
> > +* The virtual address of the shared_info page has changed, so
> > +* the vcpu_info pointer for VCPU 0 is now stale.
> 
> Is it "has changed" or "has changed if kaslr is on"?
>
> It's "has changed".  See commit 4ca83dcf4e3bc0c98836dbb97553792ca7ea5429 .  
> It's a way to make kaslr work, but it's done regardless of whether it's 
> enabled or not.


I completely forgot about this one.


>  
> > +*
> > +* The prepare_boot_cpu callback will re-initialize it via
> > +* xen_vcpu_setup, but we can't rely on that to be called for
> > +* old Xen versions (xen_have_vector_callback == 0).
> > +*
> > +* It is, in any case, bad to have a stale vcpu_info pointer
> > +* so reset it now.
> > +*/
> > +   xen_vcpu_info_reset(0);
> 
> 
> Why not xen_vcpu_setup(0)?
> 
> Basically, I wanted to be minimally invasive. xen_vcpu_setup does a little 
> more work (tries to do the VCPU placement hypercall), and will be called 
> later in any case. So doing just the basic xen_vcpu_info_reset for VCPU 0 
> seems like the best way to do it; it just re-iterates what is done for VCPU 0 
> earlier in boot, which is also a vcpu_info_reset.


OK, fair enough. This should go to stable as well I think (4.12+),
copying them.

Reviewed-by: Boris Ostrovsky 


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f78c8322850dbe3dbe9cd828ee00767190529100
baseline version:
 xen  3abe241190af31760c506a9f32bf25e958ea060c

Last test of basis   122635  2018-05-07 10:01:00 Z0 days
Testing same since   122636  2018-05-07 12:00:28 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   3abe241190..f78c832285  f78c8322850dbe3dbe9cd828ee00767190529100 -> smoke

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

Re: [Xen-devel] [PATCH 1/1] x86/xen: Reset VCPU0 info pointer after shared_info remap

[van der Linden, Frank]

Hi Boris,

Thanks for the feedback.

On 5/7/18, 8:13 AM, "Boris Ostrovsky"  wrote:

> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 6b424da1ce75..c78b3e8fb2e5 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -71,6 +71,19 @@ static void __init xen_hvm_init_mem_mapping(void)
>  {
>   early_memunmap(HYPERVISOR_shared_info, PAGE_SIZE);
>   HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
> +
> + /*
> +  * The virtual address of the shared_info page has changed, so
> +  * the vcpu_info pointer for VCPU 0 is now stale.

Is it "has changed" or "has changed if kaslr is on"?

It's "has changed".  See commit 4ca83dcf4e3bc0c98836dbb97553792ca7ea5429 .  
It's a way to make kaslr work, but it's done regardless of whether it's enabled 
or not.
 
> +  *
> +  * The prepare_boot_cpu callback will re-initialize it via
> +  * xen_vcpu_setup, but we can't rely on that to be called for
> +  * old Xen versions (xen_have_vector_callback == 0).
> +  *
> +  * It is, in any case, bad to have a stale vcpu_info pointer
> +  * so reset it now.
> +  */
> + xen_vcpu_info_reset(0);


Why not xen_vcpu_setup(0)?

Basically, I wanted to be minimally invasive. xen_vcpu_setup does a little more 
work (tries to do the VCPU placement hypercall), and will be called later in 
any case. So doing just the basic xen_vcpu_info_reset for VCPU 0 seems like the 
best way to do it; it just re-iterates what is done for VCPU 0 earlier in boot, 
which is also a vcpu_info_reset.

Frank



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

Re: [Xen-devel] [PATCH v2 for-4.11] x86/pv: Hide more EFER bits from PV guests

[Brian Woods]

On Mon, May 07, 2018 at 11:00:23AM +0100, Andrew Cooper wrote:
> We don't advertise SVM in CPUID so a PV guest shouldn't be under the
> impression that it can use SVM functionality, but despite this, it really
> shouldn't see SVME set when reading EFER.
> 
> On Intel processors, 32bit PV guests don't see, and can't use SYSCALL.
> 
> Introduce EFER_KNOWN_MASK to whitelist the features Xen knows about, and use
> this to clamp the guests view.
> 
> Take the opportunity to reuse the mask to simplify svm_vmcb_isvalid(), and
> change "undefined" to "unknown" in the print message, as there is at least
> EFER.TCE (Translation Cache Extension) defined but unknown to Xen.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Boris Ostrovsky 
> Release-acked-by: Juergen Gross 
> ---
> CC: Jan Beulich 
> CC: Suravee Suthikulpanit 
> CC: Brian Woods 
> 
> Arguably, this wants backporting to the stable trees, so should be considered
> for 4.11 at this point.
> ---
>  xen/arch/x86/hvm/svm/svmdebug.c |  5 ++---
>  xen/arch/x86/pv/emul-priv-op.c  | 11 +--
>  xen/include/asm-x86/msr-index.h |  3 +++
>  3 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
> index 6c215d1..d35e405 100644
> --- a/xen/arch/x86/hvm/svm/svmdebug.c
> +++ b/xen/arch/x86/hvm/svm/svmdebug.c
> @@ -133,9 +133,8 @@ bool svm_vmcb_isvalid(const char *from, const struct 
> vmcb_struct *vmcb,
>  PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n",
> vmcb_get_dr7(vmcb));
>  
> -if ( efer & ~(EFER_SCE | EFER_LME | EFER_LMA | EFER_NX | EFER_SVME |
> -  EFER_LMSLE | EFER_FFXSE) )
> -PRINTF("EFER: undefined bits are not zero (%#"PRIx64")\n", efer);
> +if ( efer & ~EFER_KNOWN_MASK )
> +PRINTF("EFER: unknown bits are not zero (%#"PRIx64")\n", efer);
>  
>  if ( hvm_efer_valid(v, efer, -1) )
>  PRINTF("EFER: %s (%"PRIx64")\n", hvm_efer_valid(v, efer, -1), efer);
> diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
> index 15f42b3..ce2ec76 100644
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -867,9 +867,16 @@ static int read_msr(unsigned int reg, uint64_t *val,
>  return X86EMUL_OKAY;
>  
>  case MSR_EFER:
> -*val = read_efer();
> +/* Hide unknown bits, and unconditionally hide SVME from guests. */
> +*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
> +/*
> + * Hide the 64-bit features from 32-bit guests.  SCE has
> + * vendor-dependent behaviour.
> + */
>  if ( is_pv_32bit_domain(currd) )
> -*val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
> +*val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE |
> +  (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
> +   ? EFER_SCE : 0));
>  return X86EMUL_OKAY;
>  
>  case MSR_K7_FID_VID_CTL:
> diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
> index c9f44eb..6d94d65 100644
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -31,6 +31,9 @@
>  #define EFER_LMSLE   (1<<_EFER_LMSLE)
>  #define EFER_FFXSE   (1<<_EFER_FFXSE)
>  
> +#define EFER_KNOWN_MASK  (EFER_SCE | EFER_LME | EFER_LMA | 
> EFER_NX | \
> +  EFER_SVME | EFER_LMSLE | EFER_FFXSE)
> +
>  /* Speculation Controls. */
>  #define MSR_SPEC_CTRL0x0048
>  #define SPEC_CTRL_IBRS   (_AC(1, ULL) << 0)
> -- 
> 2.1.4
> 

Reviewed-by: Brian Woods 

-- 
Brian Woods

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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Boris Ostrovsky]

On 05/07/2018 11:49 AM, Andrew Cooper wrote:
> On 07/05/18 16:46, Boris Ostrovsky wrote:
>> On 05/07/2018 11:29 AM, Andrew Cooper wrote:
>>> On 07/05/18 16:25, Jan Beulich wrote:
>>> On 07.05.18 at 16:19,  wrote:
> On 07/05/18 15:11, Jan Beulich wrote:
> On 04.05.18 at 17:11,  wrote:
>>> --- a/xen/arch/x86/hvm/svm/entry.S
>>> +++ b/xen/arch/x86/hvm/svm/entry.S
>>> @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
>>>  jmp  .Lsvm_do_resume
>>>  __UNLIKELY_END(nsvm_hap)
>>>  
>>> -call svm_asid_handle_vmrun
>>> -
>>> -cmpb $0,tb_init_done(%rip)
>>> -UNLIKELY_START(nz, svm_trace)
>>> -call svm_trace_vmentry
>>> -UNLIKELY_END(svm_trace)
>>> -
>>> -mov  VCPU_svm_vmcb(%rbx),%rcx
>>> -mov  UREGS_rax(%rsp),%rax
>>> -mov  %rax,VMCB_rax(%rcx)
>>> -mov  UREGS_rip(%rsp),%rax
>>> -mov  %rax,VMCB_rip(%rcx)
>>> -mov  UREGS_rsp(%rsp),%rax
>>> -mov  %rax,VMCB_rsp(%rcx)
>>> -mov  UREGS_eflags(%rsp),%rax
>>> -or   $X86_EFLAGS_MBS,%rax
>>> -mov  %rax,VMCB_rflags(%rcx)
>>> +mov  %rsp, %rdi
>>> +call svm_vmenter_helper
>> While I had committed this earlier today, there's one concern I've just 
>> come
>> to think of: Now that we're calling into C land with CLGI in effect (for 
> more
>> than just the trivial svm_trace_vmentry()) we are at risk of confusing
>> parties using local_irq_is_enabled(), first and foremost
>> common/spinlock.c:check_lock(). While it's some extra overhead, I wonder
>> whether the call wouldn't better be framed by a CLI/STI pair.
> I can't see why the SVM vmentry path uses CLGI/STGI in the first place.
>
> The VMX path uses plain cli/sti and our NMI/MCE handlers can cope. 
> Furthermore, processing NMIs/MCEs at this point will be more efficient
> that taking a vmentry then immediately exiting again.
 Perhaps you're right, i.e. we could replace all current CLGI/STGI by
 CLI/STI, adding a single STGI right after VMRUN.
>> The APM say "It is assumed that VMM software cleared GIF some time before
>> executing the VMRUN instruction, to ensure an atomic state switch."
>>
>> Not sure if this is meant as suggestion or requirement.
> Hmm - that can probably be tested with this proposed patch and a very
> high frequency NMI perf counter.


This may only prove the we do need it, if the test without CLGI fails.

If the test passes I don't think we can say anything one way or the other.

I am adding Suravee and Brian, perhaps they know the answer (or can
check internally).


>
> Basically every other hypervisor does CLGI; VMSAVE (host state); VMLOAD
> (guest state); VMRUN, and Xen's lack of doing this is why we have to
> play with the IDT IST settings, as well as why we can't cope cleanly
> with stack overflows.
>

KVM manipulates both GIF and RFLAGS.IF.

-boris

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

Re: [Xen-devel] [RFC XEN PATCH v4 01/41] x86_64/mm: fix the PDX group check in mem_hotadd_check()

[Jan Beulich]

>>> On 07.12.17 at 11:09,  wrote:
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -1295,12 +1295,8 @@ static int mem_hotadd_check(unsigned long spfn, 
> unsigned long epfn)
>  return 0;
>  
>  /* Make sure the new range is not present now */
> -sidx = ((pfn_to_pdx(spfn) + PDX_GROUP_COUNT - 1)  & ~(PDX_GROUP_COUNT - 
> 1))
> -/ PDX_GROUP_COUNT;
> +sidx = (pfn_to_pdx(spfn) & ~(PDX_GROUP_COUNT - 1)) / PDX_GROUP_COUNT;

I agree that rounding up here is bogus.

>  eidx = (pfn_to_pdx(epfn - 1) & ~(PDX_GROUP_COUNT - 1)) / PDX_GROUP_COUNT;
> -if (sidx >= eidx)
> -return 0;
> -
>  s = find_next_zero_bit(pdx_group_valid, eidx, sidx);

But isn't this one wrong too, needing eidx + 1 as argument instead? Also
for the following find_next_bit() then?

Also please don't drop the blank line there.

Jan



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

[Xen-devel] [xen-unstable-smoke test] 122640: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122635

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f78c8322850dbe3dbe9cd828ee00767190529100
baseline version:
 xen  3abe241190af31760c506a9f32bf25e958ea060c

Last test of basis   122635  2018-05-07 10:01:00 Z0 days
Testing same since   122636  2018-05-07 12:00:28 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 

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



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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.


commit f78c8322850dbe3dbe9cd828ee00767190529100
Author: Juergen Gross 
Date:   Mon May 7 12:16:05 2018 +0200

doc: add credit2_cap_period_ms boot parameter description

credit2_cap_period_ms isn't mentioned in xen-command-line.markdown.
Add a description.

Signed-off-by: Juergen Gross 
Acked-by: Andrew Cooper 

commit 4d1b32e10dd25dc9ed6714c5e245f60a4473665c
Author: Juergen Gross 
Date:   Mon May 7 12:16:04 2018 +0200

doc: add architecture qualifier to boot parameter entries

Many of the architecture specific boot parameters are not qualified
as such. Correct that.  Reorder PKU to be alphabetical.

Signed-off-by: Juergen Gross 
Acked-by: Andrew Cooper 

commit 589263031c04e2ba527783b4e04e8df27d364769
Author: Andrew Cooper 
Date:   Tue Mar 20 19:36:40 2018 +

x86/pv: Hide more EFER bits from PV guests

We don't advertise SVM in CPUID so a PV guest shouldn't be under the
impression that it can use SVM functionality, but despite this, it really
shouldn't see SVME set when reading EFER.

On Intel processors, 32bit PV guests don't see, and can't use SYSCALL.

Introduce EFER_KNOWN_MASK to whitelist the features Xen knows about, and use
this to clamp the guests view.

Take the opportunity to reuse the mask to simplify svm_vmcb_isvalid(), and
change "undefined" to "unknown" in the print message, as there is at least
EFER.TCE (Translation Cache Extension) defined but unknown to Xen.

Signed-off-by: Andrew Cooper 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
Release-acked-by: Juergen Gross 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Andrew Cooper]

On 07/05/18 16:46, Boris Ostrovsky wrote:
> On 05/07/2018 11:29 AM, Andrew Cooper wrote:
>> On 07/05/18 16:25, Jan Beulich wrote:
>> On 07.05.18 at 16:19,  wrote:
 On 07/05/18 15:11, Jan Beulich wrote:
 On 04.05.18 at 17:11,  wrote:
>> --- a/xen/arch/x86/hvm/svm/entry.S
>> +++ b/xen/arch/x86/hvm/svm/entry.S
>> @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
>>  jmp  .Lsvm_do_resume
>>  __UNLIKELY_END(nsvm_hap)
>>  
>> -call svm_asid_handle_vmrun
>> -
>> -cmpb $0,tb_init_done(%rip)
>> -UNLIKELY_START(nz, svm_trace)
>> -call svm_trace_vmentry
>> -UNLIKELY_END(svm_trace)
>> -
>> -mov  VCPU_svm_vmcb(%rbx),%rcx
>> -mov  UREGS_rax(%rsp),%rax
>> -mov  %rax,VMCB_rax(%rcx)
>> -mov  UREGS_rip(%rsp),%rax
>> -mov  %rax,VMCB_rip(%rcx)
>> -mov  UREGS_rsp(%rsp),%rax
>> -mov  %rax,VMCB_rsp(%rcx)
>> -mov  UREGS_eflags(%rsp),%rax
>> -or   $X86_EFLAGS_MBS,%rax
>> -mov  %rax,VMCB_rflags(%rcx)
>> +mov  %rsp, %rdi
>> +call svm_vmenter_helper
> While I had committed this earlier today, there's one concern I've just 
> come
> to think of: Now that we're calling into C land with CLGI in effect (for 
 more
> than just the trivial svm_trace_vmentry()) we are at risk of confusing
> parties using local_irq_is_enabled(), first and foremost
> common/spinlock.c:check_lock(). While it's some extra overhead, I wonder
> whether the call wouldn't better be framed by a CLI/STI pair.
 I can't see why the SVM vmentry path uses CLGI/STGI in the first place.

 The VMX path uses plain cli/sti and our NMI/MCE handlers can cope. 
 Furthermore, processing NMIs/MCEs at this point will be more efficient
 that taking a vmentry then immediately exiting again.
>>> Perhaps you're right, i.e. we could replace all current CLGI/STGI by
>>> CLI/STI, adding a single STGI right after VMRUN.
>
> The APM say "It is assumed that VMM software cleared GIF some time before
> executing the VMRUN instruction, to ensure an atomic state switch."
>
> Not sure if this is meant as suggestion or requirement.

Hmm - that can probably be tested with this proposed patch and a very
high frequency NMI perf counter.

Basically every other hypervisor does CLGI; VMSAVE (host state); VMLOAD
(guest state); VMRUN, and Xen's lack of doing this is why we have to
play with the IDT IST settings, as well as why we can't cope cleanly
with stack overflows.

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Jan Beulich]

>>> On 07.05.18 at 17:46,  wrote:
> On 05/07/2018 11:29 AM, Andrew Cooper wrote:
>> On 07/05/18 16:25, Jan Beulich wrote:
>> On 07.05.18 at 16:19,  wrote:
 On 07/05/18 15:11, Jan Beulich wrote:
 On 04.05.18 at 17:11,  wrote:
>> --- a/xen/arch/x86/hvm/svm/entry.S
>> +++ b/xen/arch/x86/hvm/svm/entry.S
>> @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
>>  jmp  .Lsvm_do_resume
>>  __UNLIKELY_END(nsvm_hap)
>>  
>> -call svm_asid_handle_vmrun
>> -
>> -cmpb $0,tb_init_done(%rip)
>> -UNLIKELY_START(nz, svm_trace)
>> -call svm_trace_vmentry
>> -UNLIKELY_END(svm_trace)
>> -
>> -mov  VCPU_svm_vmcb(%rbx),%rcx
>> -mov  UREGS_rax(%rsp),%rax
>> -mov  %rax,VMCB_rax(%rcx)
>> -mov  UREGS_rip(%rsp),%rax
>> -mov  %rax,VMCB_rip(%rcx)
>> -mov  UREGS_rsp(%rsp),%rax
>> -mov  %rax,VMCB_rsp(%rcx)
>> -mov  UREGS_eflags(%rsp),%rax
>> -or   $X86_EFLAGS_MBS,%rax
>> -mov  %rax,VMCB_rflags(%rcx)
>> +mov  %rsp, %rdi
>> +call svm_vmenter_helper
> While I had committed this earlier today, there's one concern I've just 
> come
> to think of: Now that we're calling into C land with CLGI in effect (for 
 more
> than just the trivial svm_trace_vmentry()) we are at risk of confusing
> parties using local_irq_is_enabled(), first and foremost
> common/spinlock.c:check_lock(). While it's some extra overhead, I wonder
> whether the call wouldn't better be framed by a CLI/STI pair.
 I can't see why the SVM vmentry path uses CLGI/STGI in the first place.

 The VMX path uses plain cli/sti and our NMI/MCE handlers can cope. 
 Furthermore, processing NMIs/MCEs at this point will be more efficient
 that taking a vmentry then immediately exiting again.
>>> Perhaps you're right, i.e. we could replace all current CLGI/STGI by
>>> CLI/STI, adding a single STGI right after VMRUN.
> 
> 
> The APM say "It is assumed that VMM software cleared GIF some time before
> executing the VMRUN instruction, to ensure an atomic state switch."

Well, that means we might additionally need CLGI right before VMRUN.

> Not sure if this is meant as suggestion or requirement.

How do we find out?

Jan



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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Boris Ostrovsky]

On 05/07/2018 11:29 AM, Andrew Cooper wrote:
> On 07/05/18 16:25, Jan Beulich wrote:
> On 07.05.18 at 16:19,  wrote:
>>> On 07/05/18 15:11, Jan Beulich wrote:
>>> On 04.05.18 at 17:11,  wrote:
> --- a/xen/arch/x86/hvm/svm/entry.S
> +++ b/xen/arch/x86/hvm/svm/entry.S
> @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
>  jmp  .Lsvm_do_resume
>  __UNLIKELY_END(nsvm_hap)
>  
> -call svm_asid_handle_vmrun
> -
> -cmpb $0,tb_init_done(%rip)
> -UNLIKELY_START(nz, svm_trace)
> -call svm_trace_vmentry
> -UNLIKELY_END(svm_trace)
> -
> -mov  VCPU_svm_vmcb(%rbx),%rcx
> -mov  UREGS_rax(%rsp),%rax
> -mov  %rax,VMCB_rax(%rcx)
> -mov  UREGS_rip(%rsp),%rax
> -mov  %rax,VMCB_rip(%rcx)
> -mov  UREGS_rsp(%rsp),%rax
> -mov  %rax,VMCB_rsp(%rcx)
> -mov  UREGS_eflags(%rsp),%rax
> -or   $X86_EFLAGS_MBS,%rax
> -mov  %rax,VMCB_rflags(%rcx)
> +mov  %rsp, %rdi
> +call svm_vmenter_helper
 While I had committed this earlier today, there's one concern I've just 
 come
 to think of: Now that we're calling into C land with CLGI in effect (for 
>>> more
 than just the trivial svm_trace_vmentry()) we are at risk of confusing
 parties using local_irq_is_enabled(), first and foremost
 common/spinlock.c:check_lock(). While it's some extra overhead, I wonder
 whether the call wouldn't better be framed by a CLI/STI pair.
>>> I can't see why the SVM vmentry path uses CLGI/STGI in the first place.
>>>
>>> The VMX path uses plain cli/sti and our NMI/MCE handlers can cope. 
>>> Furthermore, processing NMIs/MCEs at this point will be more efficient
>>> that taking a vmentry then immediately exiting again.
>> Perhaps you're right, i.e. we could replace all current CLGI/STGI by
>> CLI/STI, adding a single STGI right after VMRUN.


The APM say "It is assumed that VMM software cleared GIF some time before
executing the VMRUN instruction, to ensure an atomic state switch."

Not sure if this is meant as suggestion or requirement.

-boris

> We want to retain the one STGI on the svm_stgi_label, but I think all
> other CLGI/STGI should be downgraded to CLI/STI.
>
>>> As for running with interrupts disabled, that is already the case on the
>>> VMX side, and I don't see why the SVM side needs to be different.
>> Sure, as does SVM - CLGI is a superset of CLI, after all. My observation
>> was just that this state of interrupts being disabled can't be observed by
>> users of the normal infrastructure (inspecting EFLAGS.IF).
> Ah ok.
>
> ~Andrew


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

Re: [Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable

[Jan Beulich]

>>> On 09.11.17 at 18:09,  wrote:
> --- a/xen/drivers/cpufreq/Kconfig
> +++ b/xen/drivers/cpufreq/Kconfig
> @@ -1,3 +1,6 @@
>  
>  config HAS_CPUFREQ
>   bool
> +
> +config HAS_CPU_TURBO
> + bool

This is about cpufreq, so HAS_CPUFREQ_TURBO please.

Also please try to limit the number of #ifdef-s, perhaps by way of introducing
a few helpers (ending up empty without that setting enabled).

Jan



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

Re: [Xen-devel] [RFC PATCH 03/31] pmstat: move pmstat.c file to the xen/drivers/pm/stat.c location

[Jan Beulich]

>>> On 09.11.17 at 18:09,  wrote:
> From: Oleksandr Dmytryshyn 
> 
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
> 
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00935.html 
> 
> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Oleksandr Tyshchenko 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> ---
>  MAINTAINERS   |   1 +
>  xen/arch/x86/Kconfig  |   1 +
>  xen/common/sysctl.c   |   2 +-
>  xen/drivers/Kconfig   |   2 +
>  xen/drivers/Makefile  |   1 +
>  xen/drivers/acpi/Makefile |   1 -
>  xen/drivers/acpi/pmstat.c | 526 
> --
>  xen/drivers/pm/Kconfig|   3 +
>  xen/drivers/pm/Makefile   |   1 +
>  xen/drivers/pm/stat.c | 526 
> ++

I think I'd prefer drivers/power/*, and please try present movement of files as
renames instead of as delete+create.

> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -23,6 +23,7 @@ config X86
>   select HAS_PDX
>   select NUMA
>   select VGA
> + select HAS_PM

Please insert at the right spot.

> +int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
> +{
> +u32 bits[3];
> +int ret;
> +
> +if ( copy_from_guest(bits, pdc, 2) )
> +ret = -EFAULT;
> +else if ( bits[0] != ACPI_PDC_REVISION_ID || !bits[1] )
> +ret = -EINVAL;
> +else if ( copy_from_guest_offset(bits + 2, pdc, 2, 1) )
> +ret = -EFAULT;
> +else
> +{
> +u32 mask = 0;
> +
> +if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX )
> +mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT;
> +if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX )
> +mask |= ACPI_PDC_P_MASK | ACPI_PDC_SMP_C1PT;
> +if ( xen_processor_pmbits & XEN_PROCESSOR_PM_TX )
> +mask |= ACPI_PDC_T_MASK | ACPI_PDC_SMP_C1PT;
> +bits[2] &= (ACPI_PDC_C_MASK | ACPI_PDC_P_MASK | ACPI_PDC_T_MASK |
> +ACPI_PDC_SMP_C1PT) & ~mask;
> +ret = arch_acpi_set_pdc_bits(acpi_id, bits, mask);
> +}
> +if ( !ret && __copy_to_guest_offset(pdc, 2, bits + 2, 1) )
> +ret = -EFAULT;
> +
> +return ret;
> +}

Looks quite ACPI-specific.

Jan



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

Re: [Xen-devel] [PATCH v3 08/10] xen/arm: Release timer interrupts when CPU is hot-unplugged

[Mirela Simonovic]

Hi Julien,

On Mon, Apr 30, 2018 at 5:58 PM, Julien Grall  wrote:
> Hi,
>
>
> On 27/04/18 18:12, Mirela Simonovic wrote:
>>
>> When a CPU is hot-unplugged timer interrupts have to be released
>> in order to free the memory that was allocated when the interrupts
>> were requested (using request_irq()). The request_irq is called
>> for each timer interrupt when the CPU gets hotplugged
>> (start_secondary->init_timer_interrupt->request_irq).
>> With this patch the timer interrupts will be released when the
>> newly added callback receives CPU_DYING event.
>>
>> Signed-off-by: Mirela Simonovic 
>>
>> ---
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> ---
>> Changes in v3:
>> -Trigger releasing of timer interrupts using notifiers
>> ---
>>   xen/arch/arm/time.c | 39 +++
>>   1 file changed, 39 insertions(+)
>>
>> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
>> index c11fcfeadd..c7317e4639 100644
>> --- a/xen/arch/arm/time.c
>> +++ b/xen/arch/arm/time.c
>> @@ -29,6 +29,8 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -312,6 +314,17 @@ void init_timer_interrupt(void)
>>   check_timer_irq_cfg(timer_irq[TIMER_PHYS_NONSECURE_PPI],
>> "NS-physical");
>>   }
>>   +/*
>> + * Revert actions done in init_timer_interrupt that are required to
>> properly
>> + * disable this CPU.
>> + */
>> +static void deinit_timer_interrupt(void)
>> +{
>
>
> Any reason to not disable the timer here? But I think we need to finish the
> discussion on the previous series regarding the purpose of the mdelay before
> going further with that patch. See patch v2 7/10. I would also appreciate
> answer to my question there.
>

I just missed it. Will add disabling timers.

>
>> +release_irq(timer_irq[TIMER_HYP_PPI], NULL);
>> +release_irq(timer_irq[TIMER_VIRT_PPI], NULL);
>> +release_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], NULL);
>> +}
>> +
>>   /* Wait a set number of microseconds */
>>   void udelay(unsigned long usecs)
>>   {
>> @@ -340,6 +353,32 @@ void domain_set_time_offset(struct domain *d, int64_t
>> time_offset_seconds)
>>   /* XXX update guest visible wallclock time */
>>   }
>>   +static int cpu_time_callback(
>> +struct notifier_block *nfb, unsigned long action, void *hcpu)
>> +{
>> +switch ( action )
>> +{
>> +case CPU_DYING:
>> +deinit_timer_interrupt();
>> +break;
>> +default:
>> +break;
>> +}
>> +
>> +return NOTIFY_DONE;
>> +}
>> +
>> +static struct notifier_block cpu_time_nfb = {
>> +.notifier_call = cpu_time_callback,
>> +};
>> +
>> +static int __init cpu_time_notifier_init(void)
>> +{
>> +register_cpu_notifier(_time_nfb);
>> +return 0;
>> +}
>> +__initcall(cpu_time_notifier_init);
>> +
>>   /*
>>* Local variables:
>>* mode: C
>>
>
> Cheers,
>
> --
> Julien Grall


Thanks,
Mirela

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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Andrew Cooper]

On 07/05/18 16:25, Jan Beulich wrote:
 On 07.05.18 at 16:19,  wrote:
>> On 07/05/18 15:11, Jan Beulich wrote:
>> On 04.05.18 at 17:11,  wrote:
 --- a/xen/arch/x86/hvm/svm/entry.S
 +++ b/xen/arch/x86/hvm/svm/entry.S
 @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
  jmp  .Lsvm_do_resume
  __UNLIKELY_END(nsvm_hap)
  
 -call svm_asid_handle_vmrun
 -
 -cmpb $0,tb_init_done(%rip)
 -UNLIKELY_START(nz, svm_trace)
 -call svm_trace_vmentry
 -UNLIKELY_END(svm_trace)
 -
 -mov  VCPU_svm_vmcb(%rbx),%rcx
 -mov  UREGS_rax(%rsp),%rax
 -mov  %rax,VMCB_rax(%rcx)
 -mov  UREGS_rip(%rsp),%rax
 -mov  %rax,VMCB_rip(%rcx)
 -mov  UREGS_rsp(%rsp),%rax
 -mov  %rax,VMCB_rsp(%rcx)
 -mov  UREGS_eflags(%rsp),%rax
 -or   $X86_EFLAGS_MBS,%rax
 -mov  %rax,VMCB_rflags(%rcx)
 +mov  %rsp, %rdi
 +call svm_vmenter_helper
>>> While I had committed this earlier today, there's one concern I've just come
>>> to think of: Now that we're calling into C land with CLGI in effect (for 
>> more
>>> than just the trivial svm_trace_vmentry()) we are at risk of confusing
>>> parties using local_irq_is_enabled(), first and foremost
>>> common/spinlock.c:check_lock(). While it's some extra overhead, I wonder
>>> whether the call wouldn't better be framed by a CLI/STI pair.
>> I can't see why the SVM vmentry path uses CLGI/STGI in the first place.
>>
>> The VMX path uses plain cli/sti and our NMI/MCE handlers can cope. 
>> Furthermore, processing NMIs/MCEs at this point will be more efficient
>> that taking a vmentry then immediately exiting again.
> Perhaps you're right, i.e. we could replace all current CLGI/STGI by
> CLI/STI, adding a single STGI right after VMRUN.

We want to retain the one STGI on the svm_stgi_label, but I think all
other CLGI/STGI should be downgraded to CLI/STI.

>
>> As for running with interrupts disabled, that is already the case on the
>> VMX side, and I don't see why the SVM side needs to be different.
> Sure, as does SVM - CLGI is a superset of CLI, after all. My observation
> was just that this state of interrupts being disabled can't be observed by
> users of the normal infrastructure (inspecting EFLAGS.IF).

Ah ok.

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Jan Beulich]

>>> On 07.05.18 at 16:19,  wrote:
> On 07/05/18 15:11, Jan Beulich wrote:
> On 04.05.18 at 17:11,  wrote:
>>> --- a/xen/arch/x86/hvm/svm/entry.S
>>> +++ b/xen/arch/x86/hvm/svm/entry.S
>>> @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
>>>  jmp  .Lsvm_do_resume
>>>  __UNLIKELY_END(nsvm_hap)
>>>  
>>> -call svm_asid_handle_vmrun
>>> -
>>> -cmpb $0,tb_init_done(%rip)
>>> -UNLIKELY_START(nz, svm_trace)
>>> -call svm_trace_vmentry
>>> -UNLIKELY_END(svm_trace)
>>> -
>>> -mov  VCPU_svm_vmcb(%rbx),%rcx
>>> -mov  UREGS_rax(%rsp),%rax
>>> -mov  %rax,VMCB_rax(%rcx)
>>> -mov  UREGS_rip(%rsp),%rax
>>> -mov  %rax,VMCB_rip(%rcx)
>>> -mov  UREGS_rsp(%rsp),%rax
>>> -mov  %rax,VMCB_rsp(%rcx)
>>> -mov  UREGS_eflags(%rsp),%rax
>>> -or   $X86_EFLAGS_MBS,%rax
>>> -mov  %rax,VMCB_rflags(%rcx)
>>> +mov  %rsp, %rdi
>>> +call svm_vmenter_helper
>> While I had committed this earlier today, there's one concern I've just come
>> to think of: Now that we're calling into C land with CLGI in effect (for 
> more
>> than just the trivial svm_trace_vmentry()) we are at risk of confusing
>> parties using local_irq_is_enabled(), first and foremost
>> common/spinlock.c:check_lock(). While it's some extra overhead, I wonder
>> whether the call wouldn't better be framed by a CLI/STI pair.
> 
> I can't see why the SVM vmentry path uses CLGI/STGI in the first place.
> 
> The VMX path uses plain cli/sti and our NMI/MCE handlers can cope. 
> Furthermore, processing NMIs/MCEs at this point will be more efficient
> that taking a vmentry then immediately exiting again.

Perhaps you're right, i.e. we could replace all current CLGI/STGI by
CLI/STI, adding a single STGI right after VMRUN.

> As for running with interrupts disabled, that is already the case on the
> VMX side, and I don't see why the SVM side needs to be different.

Sure, as does SVM - CLGI is a superset of CLI, after all. My observation
was just that this state of interrupts being disabled can't be observed by
users of the normal infrastructure (inspecting EFLAGS.IF).

Jan



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

[Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

[Olaf Hering]

I assume OSS test does not test realworld live migration,
therefore the following regression remained unnoticed:

name="hvm"
builder="hvm"
memory=555
vcpus=4
serial="pty"
boot="c"
disk=[ 'qcow2:/nfs/vdisk.qcow2,hda,w', ]
device_model_version="qemu-xen"

xl create -cf hvm.cfg
sleep N
xl migrate hvm $host

On $host the domU becomes unusable, qemu reports:
xen be: qdisk-768: xen be: qdisk-768: error: Failed to get "write" lock

With qemu-2.10 the sender noticed the error somehow, and migration was aborted:
qemu-system-i386: Failed to get "write" lock

With qemu-2.11 the sender thinks everything is alright and the domU is moved.

What I gathered during debugging so far is that somehow qemu on the receiving 
side locks a region twice:

2018-05-07T09:49:45.810930Z qemu-system-i386: qemu_lock_fcntl: 39 c9 1 
F_UNLCK>F_UNLCK 0 Success
2018-05-07T09:49:45.813717Z qemu-system-i386: qemu_lock_fcntl: 39 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-07T09:49:45.814591Z qemu-system-i386: qemu_lock_fd_test: 39 c9 1 
F_WRLCK>F_RDLCK 0 Success
raw_check_lock_bytes: fcntl on 39 returned -11/0

I do not know how raw_apply_lock_bytes() is supposed to be used. In its current 
form it does not work.
Anyone else seeing this?

Olaf


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

Re: [Xen-devel] [PATCH v6] x86/mm: Suppresses vm_events caused by page-walks

[Tamas K Lengyel]

On Mon, May 7, 2018 at 7:40 AM, Alexandru Isaila
 wrote:
> This patch is adding a way to enable/disable inguest pagefault
> events. It introduces the xc_monitor_inguest_pagefault function
> and adds the inguest_pagefault_disabled in the monitor structure.
> This is needed by the introspection so it will only get gla
> faults and not get spammed with other faults.
> In p2m_mem_access_check() we emulate so no event will get sent.

Thanks for the changes!

Acked-by: Tamas K Lengyel 

> Signed-off-by: Alexandru Isaila 
>
> ---
> Changes since V5:
> - Add comment for the xc_monitor_inguest_pagefault() func.
> - Add altp2m_write_no_gpt test in xen_access
> ---
>  tools/libxc/include/xenctrl.h   |  7 +++
>  tools/libxc/xc_monitor.c| 14 ++
>  tools/tests/xen-access/xen-access.c | 36 +++-
>  xen/arch/x86/mm/mem_access.c|  9 +
>  xen/arch/x86/monitor.c  | 13 +
>  xen/include/asm-x86/domain.h|  5 +
>  xen/include/asm-x86/monitor.h   |  3 ++-
>  xen/include/public/domctl.h |  2 ++
>  8 files changed, 87 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 09e1363..6f9070d 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2056,6 +2056,13 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
> uint32_t domain_id,
>   bool enable);
>  int xc_monitor_guest_request(xc_interface *xch, uint32_t domain_id,
>   bool enable, bool sync, bool allow_userspace);
> +/*
> + * Disables page-walk mem_access events by emulating. If the
> + * emulation can not be performed then a VM_EVENT_REASON_EMUL_UNIMPLEMENTED
> + * event will be issued.
> + */
> +int xc_monitor_inguest_pagefault(xc_interface *xch, uint32_t domain_id,
> + bool disable);
>  int xc_monitor_debug_exceptions(xc_interface *xch, uint32_t domain_id,
>  bool enable, bool sync);
>  int xc_monitor_cpuid(xc_interface *xch, uint32_t domain_id, bool enable);
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index 0233b87..4ac823e 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -163,6 +163,20 @@ int xc_monitor_guest_request(xc_interface *xch, uint32_t 
> domain_id, bool enable,
>  return do_domctl(xch, );
>  }
>
> +int xc_monitor_inguest_pagefault(xc_interface *xch, uint32_t domain_id,
> +bool disable)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_monitor_op;
> +domctl.domain = domain_id;
> +domctl.u.monitor_op.op = disable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
> +domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_INGUEST_PAGEFAULT;
> +
> +return do_domctl(xch, );
> +}
> +
>  int xc_monitor_emulate_each_rep(xc_interface *xch, uint32_t domain_id,
>  bool enable)
>  {
> diff --git a/tools/tests/xen-access/xen-access.c 
> b/tools/tests/xen-access/xen-access.c
> index 9d960e2..e940137 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -362,7 +362,7 @@ void usage(char* progname)
>  {
>  fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
>  #if defined(__i386__) || defined(__x86_64__)
> -fprintf(stderr, 
> "|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access|write_ctrlreg_cr4");
> +fprintf(stderr, 
> "|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access|write_ctrlreg_cr4|altp2m_write_no_gpt");
>  #elif defined(__arm__) || defined(__aarch64__)
>  fprintf(stderr, "|privcall");
>  #endif
> @@ -395,6 +395,7 @@ int main(int argc, char *argv[])
>  int cpuid = 0;
>  int desc_access = 0;
>  int write_ctrlreg_cr4 = 0;
> +int altp2m_write_no_gpt = 0;
>  uint16_t altp2m_view_id = 0;
>
>  char* progname = argv[0];
> @@ -453,6 +454,13 @@ int main(int argc, char *argv[])
>  altp2m = 1;
>  memaccess = 1;
>  }
> +else if ( !strcmp(argv[0], "altp2m_write_no_gpt") )
> +{
> +default_access = XENMEM_access_rw;
> +altp2m_write_no_gpt = 1;
> +memaccess = 1;
> +altp2m = 1;
> +}
>  else if ( !strcmp(argv[0], "debug") )
>  {
>  debug = 1;
> @@ -513,6 +521,22 @@ int main(int argc, char *argv[])
>  xen_pfn_t gfn = 0;
>  unsigned long perm_set = 0;
>
> +if( altp2m_write_no_gpt )
> +{
> +rc = xc_monitor_inguest_pagefault(xch, domain_id, 1);
> +if ( rc < 0 )
> +{
> +ERROR("Error %d setting inguest pagefault\n", rc);
> +goto exit;
> +}
> +

Re: [Xen-devel] [PATCH 1/1] x86/xen: Reset VCPU0 info pointer after shared_info remap

[Boris Ostrovsky]

On 05/04/2018 04:11 PM, van der Linden, Frank wrote:
> This patch fixes crashes during boot for HVM guests on older (pre HVM
> vector callback) Xen versions. Without this, current kernels will always
> fail to boot on those Xen versions.
>
> Sample stack trace:
>
>BUG: unable to handle kernel paging request at ff20
>IP: __xen_evtchn_do_upcall+0x1e/0x80
>PGD 1e0e067 P4D 1e0e067 PUD 1e10067 PMD 235c067 PTE 0
> Oops: 0002 [#1] SMP PTI
>Modules linked in:
>CPU: 0 PID: 512 Comm: kworker/u2:0 Not tainted 4.14.33-52.13.amzn1.x86_64 
> #1
>Hardware name: Xen HVM domU, BIOS 3.4.3.amazon 11/11/2016
>task: 88002531d700 task.stack: c948
>RIP: 0010:__xen_evtchn_do_upcall+0x1e/0x80
>RSP: :880025403ef0 EFLAGS: 00010046
>RAX: 813cc760 RBX: ff20 RCX: c9483ef0
>RDX: 880020540a00 RSI: 880023c78000 RDI: 001c
>RBP: 0001 R08:  R09: 
>R10:  R11:  R12: 
>R13: 880025403f5c R14:  R15: 
>FS:  () GS:88002540() 
> knlGS:
>CS:  0010 DS:  ES:  CR0: 80050033
>CR2: ff20 CR3: 01e0a000 CR4: 06f0
> Call Trace:
>
>do_hvm_evtchn_intr+0xa/0x10
>__handle_irq_event_percpu+0x43/0x1a0
>handle_irq_event_percpu+0x20/0x50
>handle_irq_event+0x39/0x60
>handle_fasteoi_irq+0x80/0x140
>handle_irq+0xaf/0x120
>do_IRQ+0x41/0xd0
>common_interrupt+0x7d/0x7d
>
>
> During boot, the HYPERVISOR_shared_info page gets remapped to make it work
> with KASLR. This means that any pointer derived from it needs to be
> adjusted.
>
> The only value that this applies to is the vcpu_info pointer for VCPU 0.
> For PV and HVM with the callback vector feature, this gets done via the
> smp_ops prepare_boot_cpu callback. Older Xen versions do not support the
> HVM callback vector, so there is no Xen-specific smp_ops set up in that
> scenario. So, the vcpu_info pointer for VCPU 0 never gets set to the proper
> value, and the first reference of it will be bad. Fix this by resetting it
> immediately after the remap.
>
> Signed-off-by: Frank van der Linden 
> Reviewed-by: Eduardo Valentin 
> Reviewed-by: Alakesh Haloi 
> Reviewed-by: Vallish Vaidyeshwara 
> Cc: Juergen Gross 
> Cc: Boris Ostrovsky 
> Cc: xen-devel@lists.xenproject.org
> ---
>  arch/x86/xen/enlighten_hvm.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 6b424da1ce75..c78b3e8fb2e5 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -71,6 +71,19 @@ static void __init xen_hvm_init_mem_mapping(void)
>  {
>   early_memunmap(HYPERVISOR_shared_info, PAGE_SIZE);
>   HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
> +
> + /*
> +  * The virtual address of the shared_info page has changed, so
> +  * the vcpu_info pointer for VCPU 0 is now stale.

Is it "has changed" or "has changed if kaslr is on"?

> +  *
> +  * The prepare_boot_cpu callback will re-initialize it via
> +  * xen_vcpu_setup, but we can't rely on that to be called for
> +  * old Xen versions (xen_have_vector_callback == 0).
> +  *
> +  * It is, in any case, bad to have a stale vcpu_info pointer
> +  * so reset it now.
> +  */
> + xen_vcpu_info_reset(0);


Why not xen_vcpu_setup(0)?

-boris

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

Re: [Xen-devel] [PATCH v3 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume

[Mirela Simonovic]

Hi Julien,


On Mon, Apr 30, 2018 at 4:47 PM, Julien Grall  wrote:
> Hi Mirela,
>
>
> On 27/04/18 18:12, Mirela Simonovic wrote:
>>
>> In existing code the virtual paging for non-boot CPUs is setup only on
>> boot.
>> The setup is triggered from start_xen() after all CPUs are brought online.
>> In other words, the initialization of VTCR_EL2 register is done out of the
>> cpu_up/start_secondary() control flow. However, the cpu_up flow is also
>> used
>> to hotplug non-boot CPUs on resume from suspend to RAM state, in which
>> case
>> the virtual paging will not be configured.
>>
>> With this patch the setting of paging is triggered from start_secondary()
>> function using cpu starting notifier (notify_cpu_starting() call). The
>> notifier is registered in p2m.c using init call. This has to be done with
>> init call rather than presmp_init because the registered callback depends
>> on vtcr configuration value which is setup after the presmp init calls
>> are executed (do_presmp_initcalls() called from start_xen()). Init calls
>> are executed after initial virtual paging is set up for all CPUs on boot.
>> This ensures that no callback can fire until the vtcr value is calculated
>> by Xen and virtual paging is set up initially for all CPUs. Also, this way
>> the virtual paging setup in boot scenario remains unchanged.
>>
>> It is assumed here that after the system completed the boot, CPUs that
>> execute start_secondary() were booted as well when the Xen itself was
>> booted. According to this assumption non-boot CPUs will always be
>> compliant
>> with the VTCR_EL2 value that was selected by Xen on boot.
>> Currently, there is no mechanism to trigger hotplugging of a CPU. This
>> will be added with the suspend to RAM support for ARM, where the hotplug
>> of non-boot CPUs will be triggered via enable_nonboot_cpus() call.
>>
>> Signed-off-by: Mirela Simonovic 
>>
>> ---
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> ---
>> Changes in v2:
>> -Fix commit message
>> -Save configured VTCR_EL2 value into static variable that will be used
>>   by non-boot CPUs on hotplug
>> -Add setup_virt_paging_secondary() and invoke it from start_secondary()
>>   if that CPU has to setup virtual paging (if the system state is not
>> boot)
>>
>> Changes in v3:
>> -Fix commit message
>> -Remove setup_virt_paging_secondary() and use notifier to setup virtual
>>   paging for non-boot CPU on hotplug.
>> -In setup_virt_paging() use vtcr static variable instead of local val
>> -In setup_virt_paging_one() use vtcr static variable instead of provided
>>   argument
>> ---
>>   xen/arch/arm/p2m.c | 82
>> +-
>>   1 file changed, 62 insertions(+), 20 deletions(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index d43c3aa896..98a1fe6de9 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -8,6 +8,8 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>> +#include 
>
>
> Please add them alphabetically.
>
>
>>   #include 
>>   #include 
>>   #include 
>> @@ -1451,24 +1453,17 @@ err:
>>   return page;
>>   }
>>   -static void __init setup_virt_paging_one(void *data)
>> +/* VTCR value to be configured by all CPUs. Set only once by the boot CPU
>> */
>> +static uint64_t __read_mostly vtcr;
>> +
>> +static void setup_virt_paging_one(void *data)
>>   {
>> -unsigned long val = (unsigned long)data;
>> -WRITE_SYSREG32(val, VTCR_EL2);
>> +WRITE_SYSREG32(vtcr, VTCR_EL2);
>>   isb();
>>   }
>> void __init setup_virt_paging(void)
>>   {
>> -/* Setup Stage 2 address translation */
>> -unsigned long val =
>> VTCR_RES1|VTCR_SH0_IS|VTCR_ORGN0_WBWA|VTCR_IRGN0_WBWA;
>> -
>> -#ifdef CONFIG_ARM_32
>> -printk("P2M: 40-bit IPA\n");
>> -p2m_ipa_bits = 40;
>> -val |= VTCR_T0SZ(0x18); /* 40 bit IPA */
>> -val |= VTCR_SL0(0x1); /* P2M starts at first level */
>> -#else /* CONFIG_ARM_64 */
>>   const struct {
>>   unsigned int pabits; /* Physical Address Size */
>>   unsigned int t0sz;   /* Desired T0SZ, minimum in comment */
>> @@ -1491,6 +1486,16 @@ void __init setup_virt_paging(void)
>>   unsigned int pa_range = 0x10; /* Larger than any possible value */
>>   bool vmid_8_bit = false;
>
>
> That's not going to build on arm32 because vmid_8_bit & co are not used.
> While I will not ask you to test the changes on 32-bit board, I would at
> least want each change to be build test it on impacted architecture.
>
> In that particular case, you can just move the initialization of vtcr at
> after the endif because there is nothing that required that to be setup very
> early.
>
>
>>   +/* Setup Stage 2 address translation */
>> +vtcr = VTCR_RES1|VTCR_SH0_IS|VTCR_ORGN0_WBWA|VTCR_IRGN0_WBWA;
>> +
>> +#ifdef CONFIG_ARM_32
>> +printk("P2M: 40-bit IPA\n");
>> +p2m_ipa_bits = 40;
>> +vtcr |= 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a4c35dedd92f2b9b7c68e9bd0490bc14b96457ef
baseline version:
 ovmf 8252e6bf2ddfa210992c3590008029933592ad16

Last test of basis74688  2018-05-05 08:18:58 Z2 days
Testing same since74690  2018-05-07 12:18:29 Z0 days1 attempts


People who touched revisions under test:
  Carsey, Jaben 
  Jaben Carsey 
  Laszlo Ersek 

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



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

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

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


Push not applicable.


commit a4c35dedd92f2b9b7c68e9bd0490bc14b96457ef
Author: Carsey, Jaben 
Date:   Sat May 5 04:25:16 2018 +0800

BaseTools: Ecc - add dict for config file to internal translation

Commit eece4292acc80 changed a variable name, which was tied directly to
a config file entry. This seperates the internal variable names from
the config file entries by having the internal dict accessed through a
translation of key words.

added a test when this is run straight from command line.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey 
Tested-by: Laszlo Ersek 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Yonghong Zhu 

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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Andrew Cooper]

On 07/05/18 15:11, Jan Beulich wrote:
 On 04.05.18 at 17:11,  wrote:
>> --- a/xen/arch/x86/hvm/svm/entry.S
>> +++ b/xen/arch/x86/hvm/svm/entry.S
>> @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
>>  jmp  .Lsvm_do_resume
>>  __UNLIKELY_END(nsvm_hap)
>>  
>> -call svm_asid_handle_vmrun
>> -
>> -cmpb $0,tb_init_done(%rip)
>> -UNLIKELY_START(nz, svm_trace)
>> -call svm_trace_vmentry
>> -UNLIKELY_END(svm_trace)
>> -
>> -mov  VCPU_svm_vmcb(%rbx),%rcx
>> -mov  UREGS_rax(%rsp),%rax
>> -mov  %rax,VMCB_rax(%rcx)
>> -mov  UREGS_rip(%rsp),%rax
>> -mov  %rax,VMCB_rip(%rcx)
>> -mov  UREGS_rsp(%rsp),%rax
>> -mov  %rax,VMCB_rsp(%rcx)
>> -mov  UREGS_eflags(%rsp),%rax
>> -or   $X86_EFLAGS_MBS,%rax
>> -mov  %rax,VMCB_rflags(%rcx)
>> +mov  %rsp, %rdi
>> +call svm_vmenter_helper
> While I had committed this earlier today, there's one concern I've just come
> to think of: Now that we're calling into C land with CLGI in effect (for more
> than just the trivial svm_trace_vmentry()) we are at risk of confusing
> parties using local_irq_is_enabled(), first and foremost
> common/spinlock.c:check_lock(). While it's some extra overhead, I wonder
> whether the call wouldn't better be framed by a CLI/STI pair.

I can't see why the SVM vmentry path uses CLGI/STGI in the first place.

The VMX path uses plain cli/sti and our NMI/MCE handlers can cope. 
Furthermore, processing NMIs/MCEs at this point will be more efficient
that taking a vmentry then immediately exiting again.

As for running with interrupts disabled, that is already the case on the
VMX side, and I don't see why the SVM side needs to be different.

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Jan Beulich]

>>> On 04.05.18 at 17:11,  wrote:
> --- a/xen/arch/x86/hvm/svm/entry.S
> +++ b/xen/arch/x86/hvm/svm/entry.S
> @@ -61,23 +61,8 @@ UNLIKELY_START(ne, nsvm_hap)
>  jmp  .Lsvm_do_resume
>  __UNLIKELY_END(nsvm_hap)
>  
> -call svm_asid_handle_vmrun
> -
> -cmpb $0,tb_init_done(%rip)
> -UNLIKELY_START(nz, svm_trace)
> -call svm_trace_vmentry
> -UNLIKELY_END(svm_trace)
> -
> -mov  VCPU_svm_vmcb(%rbx),%rcx
> -mov  UREGS_rax(%rsp),%rax
> -mov  %rax,VMCB_rax(%rcx)
> -mov  UREGS_rip(%rsp),%rax
> -mov  %rax,VMCB_rip(%rcx)
> -mov  UREGS_rsp(%rsp),%rax
> -mov  %rax,VMCB_rsp(%rcx)
> -mov  UREGS_eflags(%rsp),%rax
> -or   $X86_EFLAGS_MBS,%rax
> -mov  %rax,VMCB_rflags(%rcx)
> +mov  %rsp, %rdi
> +call svm_vmenter_helper

While I had committed this earlier today, there's one concern I've just come
to think of: Now that we're calling into C land with CLGI in effect (for more
than just the trivial svm_trace_vmentry()) we are at risk of confusing
parties using local_irq_is_enabled(), first and foremost
common/spinlock.c:check_lock(). While it's some extra overhead, I wonder
whether the call wouldn't better be framed by a CLI/STI pair.

Jan



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

[Xen-devel] [xen-unstable-smoke test] 122636: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm  broken
 test-arm64-arm64-xl-xsm   4 host-install(4)broken REGR. vs. 122635
 test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR. 
vs. 122635

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

version targeted for testing:
 xen  f78c8322850dbe3dbe9cd828ee00767190529100
baseline version:
 xen  3abe241190af31760c506a9f32bf25e958ea060c

Last test of basis   122635  2018-05-07 10:01:00 Z0 days
Testing same since   122636  2018-05-07 12:00:28 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Juergen Gross 

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



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

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

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

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

broken-job test-arm64-arm64-xl-xsm broken
broken-step test-arm64-arm64-xl-xsm host-install(4)

Not pushing.


commit f78c8322850dbe3dbe9cd828ee00767190529100
Author: Juergen Gross 
Date:   Mon May 7 12:16:05 2018 +0200

doc: add credit2_cap_period_ms boot parameter description

credit2_cap_period_ms isn't mentioned in xen-command-line.markdown.
Add a description.

Signed-off-by: Juergen Gross 
Acked-by: Andrew Cooper 

commit 4d1b32e10dd25dc9ed6714c5e245f60a4473665c
Author: Juergen Gross 
Date:   Mon May 7 12:16:04 2018 +0200

doc: add architecture qualifier to boot parameter entries

Many of the architecture specific boot parameters are not qualified
as such. Correct that.  Reorder PKU to be alphabetical.

Signed-off-by: Juergen Gross 
Acked-by: Andrew Cooper 

commit 589263031c04e2ba527783b4e04e8df27d364769
Author: Andrew Cooper 
Date:   Tue Mar 20 19:36:40 2018 +

x86/pv: Hide more EFER bits from PV guests

We don't advertise SVM in CPUID so a PV guest shouldn't be under the
impression that it can use SVM functionality, but despite this, it really
shouldn't see SVME set when reading EFER.

On Intel processors, 32bit PV guests don't see, and can't use SYSCALL.

Introduce EFER_KNOWN_MASK to whitelist the features Xen knows about, and use
this to clamp the guests view.

Take the opportunity to reuse the mask to simplify svm_vmcb_isvalid(), and
change "undefined" to "unknown" in the print message, as there is at least
EFER.TCE (Translation Cache Extension) defined but unknown to Xen.

Signed-off-by: Andrew Cooper 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
Release-acked-by: Juergen Gross 
(qemu changes not included)

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

[Xen-devel] [PATCH v6] x86/mm: Suppresses vm_events caused by page-walks

[Alexandru Isaila]

This patch is adding a way to enable/disable inguest pagefault
events. It introduces the xc_monitor_inguest_pagefault function
and adds the inguest_pagefault_disabled in the monitor structure.
This is needed by the introspection so it will only get gla
faults and not get spammed with other faults.
In p2m_mem_access_check() we emulate so no event will get sent.

Signed-off-by: Alexandru Isaila 

---
Changes since V5:
- Add comment for the xc_monitor_inguest_pagefault() func.
- Add altp2m_write_no_gpt test in xen_access
---
 tools/libxc/include/xenctrl.h   |  7 +++
 tools/libxc/xc_monitor.c| 14 ++
 tools/tests/xen-access/xen-access.c | 36 +++-
 xen/arch/x86/mm/mem_access.c|  9 +
 xen/arch/x86/monitor.c  | 13 +
 xen/include/asm-x86/domain.h|  5 +
 xen/include/asm-x86/monitor.h   |  3 ++-
 xen/include/public/domctl.h |  2 ++
 8 files changed, 87 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09e1363..6f9070d 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2056,6 +2056,13 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
uint32_t domain_id,
  bool enable);
 int xc_monitor_guest_request(xc_interface *xch, uint32_t domain_id,
  bool enable, bool sync, bool allow_userspace);
+/*
+ * Disables page-walk mem_access events by emulating. If the
+ * emulation can not be performed then a VM_EVENT_REASON_EMUL_UNIMPLEMENTED
+ * event will be issued.
+ */
+int xc_monitor_inguest_pagefault(xc_interface *xch, uint32_t domain_id,
+ bool disable);
 int xc_monitor_debug_exceptions(xc_interface *xch, uint32_t domain_id,
 bool enable, bool sync);
 int xc_monitor_cpuid(xc_interface *xch, uint32_t domain_id, bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 0233b87..4ac823e 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -163,6 +163,20 @@ int xc_monitor_guest_request(xc_interface *xch, uint32_t 
domain_id, bool enable,
 return do_domctl(xch, );
 }
 
+int xc_monitor_inguest_pagefault(xc_interface *xch, uint32_t domain_id,
+bool disable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = disable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_INGUEST_PAGEFAULT;
+
+return do_domctl(xch, );
+}
+
 int xc_monitor_emulate_each_rep(xc_interface *xch, uint32_t domain_id,
 bool enable)
 {
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 9d960e2..e940137 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -362,7 +362,7 @@ void usage(char* progname)
 {
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
-fprintf(stderr, 
"|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access|write_ctrlreg_cr4");
+fprintf(stderr, 
"|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access|write_ctrlreg_cr4|altp2m_write_no_gpt");
 #elif defined(__arm__) || defined(__aarch64__)
 fprintf(stderr, "|privcall");
 #endif
@@ -395,6 +395,7 @@ int main(int argc, char *argv[])
 int cpuid = 0;
 int desc_access = 0;
 int write_ctrlreg_cr4 = 0;
+int altp2m_write_no_gpt = 0;
 uint16_t altp2m_view_id = 0;
 
 char* progname = argv[0];
@@ -453,6 +454,13 @@ int main(int argc, char *argv[])
 altp2m = 1;
 memaccess = 1;
 }
+else if ( !strcmp(argv[0], "altp2m_write_no_gpt") )
+{
+default_access = XENMEM_access_rw;
+altp2m_write_no_gpt = 1;
+memaccess = 1;
+altp2m = 1;
+}
 else if ( !strcmp(argv[0], "debug") )
 {
 debug = 1;
@@ -513,6 +521,22 @@ int main(int argc, char *argv[])
 xen_pfn_t gfn = 0;
 unsigned long perm_set = 0;
 
+if( altp2m_write_no_gpt )
+{
+rc = xc_monitor_inguest_pagefault(xch, domain_id, 1);
+if ( rc < 0 )
+{
+ERROR("Error %d setting inguest pagefault\n", rc);
+goto exit;
+}
+rc = xc_monitor_emul_unimplemented(xch, domain_id, 1);
+if ( rc < 0 )
+{
+ERROR("Error %d failed to enable emul unimplemented\n", rc);
+goto exit;
+}
+}
+
 rc = xc_altp2m_set_domain_state( xch, domain_id, 1 );
 if ( rc < 0 )
 {
@@ -857,6 +881,16 @@ int main(int argc, char *argv[])

[Xen-devel] [xen-4.7-testing test] 122624: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken
 build-arm64  broken
 build-arm64   4 host-install(4)broken REGR. vs. 122131
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122131
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken in 122589
 test-arm64-arm64-libvirt-xsm broken  in 122606

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 4 host-install(4) broken in 122589 
pass in 122624
 test-arm64-arm64-libvirt-xsm 4 host-install(4) broken in 122606 pass in 122589
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 122606 pass in 122624
 test-xtf-amd64-amd64-2   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 122606
 test-armhf-armhf-xl-vhd   6 xen-installfail pass in 122606
 test-armhf-armhf-xl-xsm   6 xen-installfail pass in 122606

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 122589 never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 122589 never 
pass
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 122606 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 122606 never pass
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 122606 never pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 122606 never 
pass
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 122606 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 122606 never pass
 test-arm64-arm64-xl 13 migrate-support-check fail in 122606 never pass
 test-arm64-arm64-xl 14 saverestore-support-check fail in 122606 never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 122606 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 122606 never pass
 test-xtf-amd64-amd64-5  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122131
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122131
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122131
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122131
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 122131
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122131
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122131
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122131
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122131
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122131
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 122131
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122131
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 122131
 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a4c35dedd92f2b9b7c68e9bd0490bc14b96457ef
baseline version:
 ovmf 8252e6bf2ddfa210992c3590008029933592ad16

Last test of basis   122597  2018-05-04 05:42:55 Z3 days
Testing same since   122625  2018-05-06 12:40:37 Z0 days1 attempts


People who touched revisions under test:
  Carsey, Jaben 
  Jaben Carsey 
  Laszlo Ersek 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   8252e6bf2d..a4c35dedd9  a4c35dedd92f2b9b7c68e9bd0490bc14b96457ef -> 
xen-tested-master

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

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

[Jason Andryuk]

Hi Jason,

On Sun, May 6, 2018 at 11:45 AM, Jason Cooper  wrote:
> Hi Marek,
>
> On Sat, May 05, 2018 at 01:03:15AM +0200, Marek Marczykowski-Górecki wrote:
>> On Fri, May 04, 2018 at 06:13:25PM -0400, Rich Persaud wrote:
>> > > On May 1, 2018, at 08:53, Jason Cooper  wrote:
>> > >
>> > > add the link to xen-users thread of me talking to myself.  :-))
>> > >
>> > >> On Tue, May 01, 2018 at 12:37:51PM +, Jason Cooper wrote:
>> > >> When I was first digging into this, I started a thread on xen-users [1],
>> > >> I've attached my xl-reboot.sh script here so you can see exactly what
>> > >> I'm attempting to do:
>> > >
>> > > [1] https://marc.info/?l=xen-users=152389443206023=2
>> >
>> > You may want to look at the code (toolstack and/or frontend-backend
>> > drivers) for Qubes and OpenXT, both of which use network driver
>> > domains and support wired/wireless networks.
>> >
>> > Operational restart of a measured, non-persistent driver domain
>> > (instead of host) is a benefit of Xen disaggregation architectures.
>>
>> In Qubes, on backend restart, we do equivalent of xl network-detach &&
>> xl network-attach (as you do in xl-reboot.sh). xl itself doesn't provide
>> any place to plug such script, but we use libvirt which provide events.
>> Also, we have full control over domain config (libvirt XML), so don't
>> need to extract vif list from xenstore...

OpenXT does the xl network-detach && xl network-attach in its own
daemon: https://github.com/OpenXT/network/blob/master/nwd/Main.hs#L767

>> The problem you describe looks related to
>> https://lkml.org/lkml/2018/2/28/289, but fix is included in 4.16...
>> There was also related libxl patch:
>> https://xen.markmail.org/thread/6qbgmwyjqsshjus7
>> (but it applies to the case where you first shutdown backend and only
>> then do xl network-detach)
>>
>> Do you have xl devd running in your driver domain? Without that xl
>> network-attach wont work (AFAIR udev isn't used here anymore).
>
> Yes, I've now modified the init script (xendomains in Gentoo) to create
> a key /tool/vmstatus/$domname/status, start the domU, loop until it gets
> it's domid, and -chmod the key.  It then does a -watch on that key.  In
> the domU, *after* xl devd is started, it writes "online" to that key.
>
> This allows me to automatically bring up the driver domains, and make
> sure they're ready for connections before proceeding to booting the next
> VM.  This only occurs when the host boots.
>
> After the driver domains are up, the rest of the domains are started in
> parallel.
>
>> Also note that backend shutdown/restart/crash was a source of many
>> problems in frontend kernel and toolstack in the past. Even simple
>> dynamic network-attach/detach sometimes is problematic for the frontend.
>> Links:
>> https://github.com/QubesOS/qubes-issues/issues/3657 (frontend kernel
>> problem)
>> https://github.com/QubesOS/qubes-issues/issues/1426 (toolstack problem,
>> + libvirt)
>> https://github.com/QubesOS/qubes-issues/issues/975 (frontend kernel
>> problem)
>
> Mmm, clearly the state machine and it's implementation needs some
> review.  I'm building v4.16.7 and we'll see how it goes for my usecase.

OpenXT has some patches for reconnecting netfront after the netback
domain is rebooted to a new domid:
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-kernel/linux/4.14/patches/netfront-support-backend-relocate.patch
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-kernel/linux/4.14/patches/xenbus-move-otherend-watches-on-relocate.patch

I'm too familiar with those, so they may be specific to the OpenXT
networking code.

Jason, when you see the vif NO-CARRIER, how do the frontend and
backend XenStore entries look?  Do the domids matchup and is the pair
in state 4 -> XenbusStateConnected?

Regards,
Jason

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

[Xen-devel] [PATCH] x86-64/Xen: fix stack switching

[Jan Beulich]

While on native entry into the kernel happens on the trampoline stack,
PV Xen kernels are being entered with the current thread stack right
away. Hence source and destination stacks are identical in that case,
and special care is needed.

Other than in sync_regs() the copying done on the INT80 path as well as
on the NMI path itself isn't NMI / #MC safe, as either of these events
occurring in the middle of the stack copying would clobber data on the
(source) stack. (Of course, in the NMI case only #MC could break
things.)

I'm not altering the similar code in interrupt_entry(), as that code
path is unreachable when running an PV Xen guest afaict.

Signed-off-by: Jan Beulich 
Cc: sta...@kernel.org 
---
There would certainly have been the option of using alternatives
patching, but afaict the patching code isn't NMI / #MC safe, so I'd
rather stay away from patching the NMI path. And I thought it would be
better to use similar code in both cases.

Another option would be to make the Xen case match the native one, by
going through the trampoline stack, but to me this would look like extra
overhead for no gain.
---
 arch/x86/entry/entry_64.S|8 
 arch/x86/entry/entry_64_compat.S |8 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

--- 4.17-rc4/arch/x86/entry/entry_64.S
+++ 4.17-rc4-x86_64-stack-switch-Xen/arch/x86/entry/entry_64.S
@@ -1399,6 +1399,12 @@ ENTRY(nmi)
swapgs
cld
SWITCH_TO_KERNEL_CR3 scratch_reg=%rdx
+
+   movqPER_CPU_VAR(cpu_current_top_of_stack), %rdx
+   subq$8, %rdx
+   xorq%rsp, %rdx
+   shrq$PAGE_SHIFT, %rdx
+   jz  .Lnmi_keep_stack
movq%rsp, %rdx
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
UNWIND_HINT_IRET_REGS base=%rdx offset=8
@@ -1408,6 +1414,8 @@ ENTRY(nmi)
pushq   2*8(%rdx)   /* pt_regs->cs */
pushq   1*8(%rdx)   /* pt_regs->rip */
UNWIND_HINT_IRET_REGS
+.Lnmi_keep_stack:
+
pushq   $-1 /* pt_regs->orig_ax */
PUSH_AND_CLEAR_REGS rdx=(%rdx)
ENCODE_FRAME_POINTER
--- 4.17-rc4/arch/x86/entry/entry_64_compat.S
+++ 4.17-rc4-x86_64-stack-switch-Xen/arch/x86/entry/entry_64_compat.S
@@ -356,15 +356,21 @@ ENTRY(entry_INT80_compat)
 
/* Need to switch before accessing the thread stack. */
SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi
+
+   movqPER_CPU_VAR(cpu_current_top_of_stack), %rdi
+   subq$8, %rdi
+   xorq%rsp, %rdi
+   shrq$PAGE_SHIFT, %rdi
+   jz  .Lint80_keep_stack
movq%rsp, %rdi
movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp
-
pushq   6*8(%rdi)   /* regs->ss */
pushq   5*8(%rdi)   /* regs->rsp */
pushq   4*8(%rdi)   /* regs->eflags */
pushq   3*8(%rdi)   /* regs->cs */
pushq   2*8(%rdi)   /* regs->ip */
pushq   1*8(%rdi)   /* regs->orig_ax */
+.Lint80_keep_stack:
 
pushq   (%rdi)  /* pt_regs->di */
pushq   %rsi/* pt_regs->si */





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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  3abe241190af31760c506a9f32bf25e958ea060c
baseline version:
 xen  e38e285a51c805cfeee4693962df23e39b3c3bd7

Last test of basis   122620  2018-05-05 21:05:34 Z1 days
Testing same since   122632  2018-05-07 08:01:17 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   e38e285a51..3abe241190  3abe241190af31760c506a9f32bf25e958ea060c -> smoke

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

Re: [Xen-devel] [PATCH v2 for-4.11] x86/pv: Hide more EFER bits from PV guests

[Andrew Cooper]

On 07/05/18 11:43, Jan Beulich wrote:
 On 07.05.18 at 12:00,  wrote:
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -867,9 +867,16 @@ static int read_msr(unsigned int reg, uint64_t *val,
>>  return X86EMUL_OKAY;
>>  
>>  case MSR_EFER:
>> -*val = read_efer();
>> +/* Hide unknown bits, and unconditionally hide SVME from guests. */
>> +*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
>> +/*
>> + * Hide the 64-bit features from 32-bit guests.  SCE has
>> + * vendor-dependent behaviour.
>> + */
>>  if ( is_pv_32bit_domain(currd) )
>> -*val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
>> +*val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE |
>> +  (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
>> +   ? EFER_SCE : 0));
>>  return X86EMUL_OKAY;
> Ideally this would check the domain's x86_vendor, but that would require
> wiring up emulation afaict, so fwiw
> Reviewed-by: Jan Beulich 

Yes - we'd have to hook SYSCALL/SYSRET off the #UD handler, and teach
x86_emulate() to understand PV's idea of guest kernel mode.  That is a
complete can of worms.

If someone feels like making cross-vendor PV work then great, but I
don't think we can plausibly claim that it might work atm.  (Same for
HVM, despite the code we actually have.)

~Andrew

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

Re: [Xen-devel] [PATCH v2 3/5] doc: correct livepatch.markdown syntax

[Juergen Gross]

On 07/05/18 12:37, Andrew Cooper wrote:
> On 07/05/18 11:30, Juergen Gross wrote:
>> On 07/05/18 12:23, Andrew Cooper wrote:
>>> On 07/05/18 11:16, Juergen Gross wrote:
 "make -C docs all" fails due to incorrect markdown syntax in
 livepatch.markdown. Correct it.
>>> Which version of markdown, ooi?  Version 1.0.1 seems fine with this.
>>>
>> ...
>> /usr/bin/pandoc --number-sections --toc --standalone
>> misc/livepatch.markdown --output pdf/misc/livepatch.pdf
>> ! LaTeX Error: Command \textquotesingle unavailable in encoding T1.
>>
>> See the LaTeX manual or LaTeX Companion for explanation.
>> Type  H   for immediate help.
>>  ...
>>
>> l.251 ...nction\ to\ directly\ jump\ to\ the\ new}
>>
>> pandoc: Error producing PDF
>> Makefile:257: recipe for target 'pdf/misc/livepatch.pdf' failed
>> make: *** [pdf/misc/livepatch.pdf] Error 43
>>
>> gross@Desktop:~/xen/docs> /usr/bin/pandoc --version
>> pandoc 1.19.2.1
>> Compiled with pandoc-types 1.17.0.5, texmath 0.9.1, skylighting 0.1.1.5
>> Default user data directory: /home/gross/.pandoc
>> Copyright (C) 2006-2016 John MacFarlane
>> Web:  http://pandoc.org
> 
> According to https://github.com/jgm/pandoc/issues/2439, this is a
> packaging issue, and manually installing texlive-latex-extra resolves
> the problem.

Right. texlive-upquote was missing. The other markdown syntax adaptions
are still necessary, though.


Juergen


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

Re: [Xen-devel] [PATCH v2 for-4.11] x86/pv: Hide more EFER bits from PV guests

[Jan Beulich]

>>> On 07.05.18 at 12:00,  wrote:
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -867,9 +867,16 @@ static int read_msr(unsigned int reg, uint64_t *val,
>  return X86EMUL_OKAY;
>  
>  case MSR_EFER:
> -*val = read_efer();
> +/* Hide unknown bits, and unconditionally hide SVME from guests. */
> +*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
> +/*
> + * Hide the 64-bit features from 32-bit guests.  SCE has
> + * vendor-dependent behaviour.
> + */
>  if ( is_pv_32bit_domain(currd) )
> -*val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
> +*val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE |
> +  (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
> +   ? EFER_SCE : 0));
>  return X86EMUL_OKAY;

Ideally this would check the domain's x86_vendor, but that would require
wiring up emulation afaict, so fwiw
Reviewed-by: Jan Beulich 

Jan



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

Re: [Xen-devel] [PATCH v4] x86/cpu: Add supports for zhaoxin x86 platform

[David Wang]

> -Original Message-
> From: Jan Beulich 
> Sent: Monday, May 7, 2018 4:24 PM
> To: David Wang 
> Cc: xen-devel ; Fiona Li(BJ-RD)
> 
> Subject: Re: [PATCH v4] x86/cpu: Add supports for zhaoxin x86 platform
> 
> >>> On 07.05.18 at 03:37,  wrote:
> > --- a/xen/arch/x86/cpu/intel_cacheinfo.c
> > +++ b/xen/arch/x86/cpu/intel_cacheinfo.c
> > @@ -176,7 +176,9 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86
> *c)
> >  * Don't use cpuid2 if cpuid4 is supported. For P4, we use cpuid2 for
> >  * trace cache
> >  */
> > -   if ((num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1) {
> > +   if ( (num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1
> &&
> > +   c->x86_vendor != X86_VENDOR_SHANGHAI )
> 
> The indentation here is _still_ wrong (and there are stray spaces), but I'll 
> try
> to remember fixing this up when committing (after 4.11 was branched off),
> i.e. with that fixed
To be consistent with context, I indent with two Tabs.  Do I need to submit 
next version patch to revise it ?  Use 4 spaces instead of TAB?
Thank you for your patience.

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

Re: [Xen-devel] [PATCH v2 3/5] doc: correct livepatch.markdown syntax

[Andrew Cooper]

On 07/05/18 11:30, Juergen Gross wrote:
> On 07/05/18 12:23, Andrew Cooper wrote:
>> On 07/05/18 11:16, Juergen Gross wrote:
>>> "make -C docs all" fails due to incorrect markdown syntax in
>>> livepatch.markdown. Correct it.
>> Which version of markdown, ooi?  Version 1.0.1 seems fine with this.
>>
> ...
> /usr/bin/pandoc --number-sections --toc --standalone
> misc/livepatch.markdown --output pdf/misc/livepatch.pdf
> ! LaTeX Error: Command \textquotesingle unavailable in encoding T1.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
>  ...
>
> l.251 ...nction\ to\ directly\ jump\ to\ the\ new}
>
> pandoc: Error producing PDF
> Makefile:257: recipe for target 'pdf/misc/livepatch.pdf' failed
> make: *** [pdf/misc/livepatch.pdf] Error 43
>
> gross@Desktop:~/xen/docs> /usr/bin/pandoc --version
> pandoc 1.19.2.1
> Compiled with pandoc-types 1.17.0.5, texmath 0.9.1, skylighting 0.1.1.5
> Default user data directory: /home/gross/.pandoc
> Copyright (C) 2006-2016 John MacFarlane
> Web:  http://pandoc.org

According to https://github.com/jgm/pandoc/issues/2439, this is a
packaging issue, and manually installing texlive-latex-extra resolves
the problem.

~Andrew

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

Re: [Xen-devel] [PATCH v2 4/5] doc: correct feature-levelling.pandoc syntax

[Juergen Gross]

On 07/05/18 12:26, Andrew Cooper wrote:
> On 07/05/18 11:16, Juergen Gross wrote:
>> "make -C docs all" fails due to incorrect markdown syntax in
>> feature-levelling.pandoc. Correct it.
>>
>> Signed-off-by: Juergen Gross 
> 
> What is trying to render this as markdown? It's pandoc, and the below
> syntax is valid markdown (used extensively in xen-command-line.markdown)
> so should be compatible in pandoc.
> 
>> ---
>>  docs/features/feature-levelling.pandoc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/docs/features/feature-levelling.pandoc 
>> b/docs/features/feature-levelling.pandoc
>> index ef77eb837d..4b2b6df151 100644
>> --- a/docs/features/feature-levelling.pandoc
>> +++ b/docs/features/feature-levelling.pandoc
>> @@ -83,7 +83,7 @@ not trap, leaving Xen no direct ability to control the 
>> information returned.
>>  
>>  Xen-aware PV software can make use of the 'Forced Emulation Prefix'
>>  
>> -> `ud2a; .ascii 'xen'; cpuid`
>> +ud2a; .ascii 'xen'; cpuid

I think the problem are the single quotes here.

>>  
>>  which Xen recognises as a deliberate attempt to get the fully-controlled
>>  `CPUID` information rather than the hardware-reported information.  This 
>> only
> 
> 

...
/usr/bin/pandoc --number-sections --toc --standalone
features/feature-levelling.pandoc --output
pdf/features/feature-levelling.pdf
! LaTeX Error: Command \textquotesingle unavailable in encoding T1.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...

l.195 ...otesingle{}xen\textquotesingle{};\ cpuid}

pandoc: Error producing PDF
Makefile:254: recipe for target 'pdf/features/feature-levelling.pdf' failed


Juergen

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

Re: [Xen-devel] [PATCH v4] x86/cpu: Add supports for zhaoxin x86 platform

[Jan Beulich]

>>> On 07.05.18 at 12:11,  wrote:
>> -Original Message-
>> From: Jan Beulich 
>> Sent: Monday, May 7, 2018 4:24 PM
>> 
>> >>> On 07.05.18 at 03:37,  wrote:
>> > --- a/xen/arch/x86/cpu/intel_cacheinfo.c
>> > +++ b/xen/arch/x86/cpu/intel_cacheinfo.c
>> > @@ -176,7 +176,9 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86
>> *c)
>> > * Don't use cpuid2 if cpuid4 is supported. For P4, we use cpuid2 for
>> > * trace cache
>> > */
>> > -  if ((num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1) {
>> > +  if ( (num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1
>> &&
>> > +  c->x86_vendor != X86_VENDOR_SHANGHAI )
>> 
>> The indentation here is _still_ wrong (and there are stray spaces), but I'll 
>> try
>> to remember fixing this up when committing (after 4.11 was branched off),
>> i.e. with that fixed
> To be consistent with context, I indent with two Tabs.

But two tabs aren't consistent with context - a single tab and enough spaces
to properly align with the previous line would be.

> Do I need to submit next version patch to revise it ?

Not strictly -  as said, I'll try to remember to correct this while committing.

>  Use 4 spaces instead of TAB?

No. You should match the style of surrounding code here, which uses Linux'es
way of indenting.

Jan



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

Re: [Xen-devel] [PATCH v2 3/5] doc: correct livepatch.markdown syntax

[Juergen Gross]

On 07/05/18 12:23, Andrew Cooper wrote:
> On 07/05/18 11:16, Juergen Gross wrote:
>> "make -C docs all" fails due to incorrect markdown syntax in
>> livepatch.markdown. Correct it.
> 
> Which version of markdown, ooi?  Version 1.0.1 seems fine with this.
> 

...
/usr/bin/pandoc --number-sections --toc --standalone
misc/livepatch.markdown --output pdf/misc/livepatch.pdf
! LaTeX Error: Command \textquotesingle unavailable in encoding T1.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...

l.251 ...nction\ to\ directly\ jump\ to\ the\ new}

pandoc: Error producing PDF
Makefile:257: recipe for target 'pdf/misc/livepatch.pdf' failed
make: *** [pdf/misc/livepatch.pdf] Error 43

gross@Desktop:~/xen/docs> /usr/bin/pandoc --version
pandoc 1.19.2.1
Compiled with pandoc-types 1.17.0.5, texmath 0.9.1, skylighting 0.1.1.5
Default user data directory: /home/gross/.pandoc
Copyright (C) 2006-2016 John MacFarlane
Web:  http://pandoc.org


Juergen

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

Re: [Xen-devel] [PATCH v2 2/5] doc: add credit2_cap_period_ms boot parameter description

[Andrew Cooper]

On 07/05/18 11:16, Juergen Gross wrote:
> credit2_cap_period_ms isn't mentioned in xen-command-line.markdown.
> Add a description.
>
> Signed-off-by: Juergen Gross 

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 3/5] doc: correct livepatch.markdown syntax

[Andrew Cooper]

On 07/05/18 11:16, Juergen Gross wrote:
> "make -C docs all" fails due to incorrect markdown syntax in
> livepatch.markdown. Correct it.

Which version of markdown, ooi?  Version 1.0.1 seems fine with this.

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

Re: [Xen-devel] [PATCH v2 1/5] doc: add architecture qualifier to boot parameter entries

[Andrew Cooper]

On 07/05/18 11:16, Juergen Gross wrote:
> Many of the architecture specific boot parameters are not qualified
> as such. Correct that.

You also rearrange PKU to be in order.

> Signed-off-by: Juergen Gross 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH v2 3/5] doc: correct livepatch.markdown syntax

[Juergen Gross]

"make -C docs all" fails due to incorrect markdown syntax in
livepatch.markdown. Correct it.

Signed-off-by: Juergen Gross 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 docs/misc/livepatch.markdown | 590 ---
 1 file changed, 273 insertions(+), 317 deletions(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 54a6b850cb..a4de44472a 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -89,33 +89,27 @@ As example we will assume the hypervisor does not have 
XSA-132 (see
 4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
 the hypervisor with it. The original code looks as so:
 
-
-   48 89 e0  mov%rsp,%rax  
-   48 25 00 80 ff ff and$0x8000,%rax  
-
+   48 89 e0  mov%rsp,%rax
+   48 25 00 80 ff ff and$0x8000,%rax
 
 while the new patched hypervisor would be:
 
-
-   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)  
-   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)  
-   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)  
-   48 89 e0  mov%rsp,%rax  
-   48 25 00 80 ff ff and$0x8000,%rax  
-
+   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)
+   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)
+   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)
+   48 89 e0  mov%rsp,%rax
+   48 25 00 80 ff ff and$0x8000,%rax
 
-This is inside the arch_do_domctl. This new change adds 21 extra
+This is inside the arch\_do\_domctl. This new change adds 21 extra
 bytes of code which alters all the offsets inside the function. To alter
 these offsets and add the extra 21 bytes of code we might not have enough
 space in .text to squeeze this in.
 
 As such we could simplify this problem by only patching the site
-which calls arch_do_domctl:
+which calls arch\_do\_domctl:
 
-
-do_domctl:  
- e8 4b b1 05 00  callq  82d08015fbb9   
-
+do_domctl:
+ e8 4b b1 05 00  callq  82d08015fbb9 
 
 with a new address for where the new `arch_do_domctl` would be (this
 area would be allocated dynamically).
@@ -123,15 +117,13 @@ area would be allocated dynamically).
 Astute readers will wonder what we need to do if we were to patch `do_domctl`
 - which is not called directly by hypervisor but on behalf of the guests via
 the `compat_hypercall_table` and `hypercall_table`.
-Patching the offset in `hypercall_table` for `do_domctl:
-(82d080103079 :)
+Patching the offset in `hypercall_table` for `do_domctl`:
+(82d080103079 do\_domctl:)
 
-
-
- 82d08024d490:   79 30  
- 82d08024d492:   10 80 d0 82 ff ff   
-
-
+
+ 82d08024d490:   79 30
+ 82d08024d492:   10 80 d0 82 ff ff
+
 
 with the new address where the new `do_domctl` is possible. The other
 place where it is used is in `hvm_hypercall64_table` which would need
@@ -164,19 +156,17 @@ CPU branching logic (I-cache, but it is just one 
unconditional jump).
 
 For this example we will assume that the hypervisor has not been compiled
 with fe2e079f642effb3d24a6e1a7096ef26e691d93e (XSA-125: *pre-fill structures
-for certain HYPERVISOR_xen_version sub-ops*) which mem-sets an structure
+for certain HYPERVISOR\_xen\_version sub-ops*) which mem-sets an structure
 in `xen_version` hypercall. This function is not called **anywhere** in
 the hypervisor (it is called by the guest) but referenced in the
 `compat_hypercall_table` and `hypercall_table` (and indirectly called
 from that). Patching the offset in `hypercall_table` for the old
-`do_xen_version` (82d080112f9e )
-
-
- 82d08024b270 :   
- ...  
- 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff  
+`do_xen_version` (82d080112f9e do\_xen\_version)
 
-
+ 82d08024b270 :
+ ...
+ 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff
+
 
 with the new address where the new `do_xen_version` is possible. The other
 place where it is used is in `hvm_hypercall64_table` which would need
@@ -184,21 +174,17 @@ to be patched in a similar way. This would require an 
in-place splicing
 of the new virtual address of `do_xen_version`.
 
 An alternative solution would be to patch insert a trampoline in the
-old `do_xen_version' function to directly jump to the new `do_xen_version`.
+old `do_xen_version` function to directly jump to the new `do_xen_version`.
 
-
- 82d080112f9e do_xen_version:  
- 82d080112f9e:   48 c7 c0 da ff ff ffmov
$0xffda,%rax  
- 82d080112fa5:   83 ff 09cmp$0x9,%edi  
- 82d080112fa8:   0f 87 24 05 00 00   ja 82d0801134d2 ; 
do_xen_version+0x534  
-
+ 82d080112f9e do_xen_version:
+ 82d080112f9e:   48 c7 c0 da ff ff ffmov
$0xffda,%rax
+ 82d080112fa5:   83 ff 09  

[Xen-devel] [PATCH v2 0/5] fix several issues in documentation

[Juergen Gross]

docs/misc/xen-command-line.markdown has several issues regarding
missing architecture qualifiers and missing documentation of one
parameter. Fix those.

Some other documents have syntax issues, too, which show up when
trying to do "make all" in the docs directory. Fix those as well.

Changes in V2:
- dropped patches 1 and 4 as already applied
- rebased to current staging
- re-added dropped line in livepatch.markdown (Konrad)

In case the maintainers are fine with my changes I believe the series
should be included in 4.11. So for the series:

Release-acked-by: Juergen Gross 

Juergen Gross (5):
  doc: add architecture qualifier to boot parameter entries
  doc: add credit2_cap_period_ms boot parameter description
  doc: correct livepatch.markdown syntax
  doc: correct feature-levelling.pandoc syntax
  doc: correct intel_psr_cat_cdp.pandoc syntax

 docs/features/feature-levelling.pandoc |   2 +-
 docs/features/intel_psr_cat_cdp.pandoc | 366 ++--
 docs/misc/livepatch.markdown   | 590 +++--
 docs/misc/xen-command-line.markdown| 194 ++-
 4 files changed, 551 insertions(+), 601 deletions(-)

-- 
2.13.6


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

[Xen-devel] [PATCH v2 2/5] doc: add credit2_cap_period_ms boot parameter description

[Juergen Gross]

credit2_cap_period_ms isn't mentioned in xen-command-line.markdown.
Add a description.

Signed-off-by: Juergen Gross 
---
 docs/misc/xen-command-line.markdown | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index b8afa719ac..5b6571adf2 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -568,6 +568,16 @@ which would otherwise require escaping of the < option
 ### credit2\_balance\_under
 > `= `
 
+### credit2\_cap\_period\_ms
+> `= `
+
+> Default: `10`
+
+Domains subject to a cap receive a replenishment of their runtime budget
+once every cap period interval. Default is 10 ms. The amount of budget
+they receive depends on their cap. For instance, a domain with a 50% cap
+will receive 50% of 10 ms, so 5 ms.
+
 ### credit2\_load\_precision\_shift
 > `= `
 
-- 
2.13.6


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

[Xen-devel] [PATCH v2 1/5] doc: add architecture qualifier to boot parameter entries

[Juergen Gross]

Many of the architecture specific boot parameters are not qualified
as such. Correct that.

Signed-off-by: Juergen Gross 
---
 docs/misc/xen-command-line.markdown | 184 ++--
 1 file changed, 92 insertions(+), 92 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 616dc9d34c..b8afa719ac 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -110,7 +110,7 @@ domain 0 command line
 Specify which ACPI MADT table to parse for APIC information, if more
 than one is present.
 
-### acpi\_pstate\_strict
+### acpi\_pstate\_strict (x86)
 > `= `
 
 > Default: `false`
@@ -119,12 +119,12 @@ Enforce checking that P-state transitions by the ACPI 
cpufreq driver
 actually result in the nominated frequency to be established. A warning
 message will be logged if that isn't the case.
 
-### acpi\_skip\_timer\_override
+### acpi\_skip\_timer\_override (x86)
 > `= `
 
 Instruct Xen to ignore timer-interrupt override.
 
-### acpi\_sleep
+### acpi\_sleep (x86)
 > `= s3_bios | s3_mode`
 
 `s3_bios` instructs Xen to invoke video BIOS initialization during S3
@@ -133,7 +133,7 @@ resume.
 `s3_mode` instructs Xen to set up the boot time (option `vga=`) video
 mode during S3 resume.
 
-### allow\_unsafe
+### allow\_unsafe (x86)
 > `= `
 
 > Default: `false`
@@ -152,14 +152,14 @@ to boot on systems with the following errata:
 
 Permit multiple copies of host p2m.
 
-### apic
+### apic (x86)
 > `= bigsmp | default`
 
 Override Xen's logic for choosing the APIC driver.  By default, if
 there are more than 8 CPUs, Xen will switch to `bigsmp` over
 `default`.
 
-### apicv
+### apicv (Intel)
 > `= `
 
 > Default: `true`
@@ -168,12 +168,12 @@ Permit Xen to use APIC Virtualisation Extensions.  This 
is an optimisation
 available as part of VT-x, and allows hardware to take care of the guests APIC
 handling, rather than requiring emulation in Xen.
 
-### apic\_verbosity
+### apic\_verbosity (x86)
 > `= verbose | debug`
 
 Increase the verbosity of the APIC code from the default value.
 
-### arat
+### arat (x86)
 > `= `
 
 > Default: `true`
@@ -182,7 +182,7 @@ Permit Xen to use "Always Running APIC Timer" support on 
compatible hardware
 in combination with cpuidle.  This option is only expected to be useful for
 developers wishing Xen to fall back to older timing methods on newer hardware.
 
-### asid
+### asid (x86)
 > `= `
 
 > Default: `true`
@@ -191,7 +191,7 @@ Permit Xen to use Address Space Identifiers.  This is an 
optimisation which
 tags the TLB entries with an ID per vcpu.  This allows for guest TLB flushes
 to be performed without the overhead of a complete TLB flush.
 
-### async-show-all
+### async-show-all (x86)
 > `= `
 
 > Default: `false`
@@ -199,7 +199,7 @@ to be performed without the overhead of a complete TLB 
flush.
 Forces all CPUs' full state to be logged upon certain fatal asynchronous
 exceptions (watchdog NMIs and unexpected MCEs).
 
-### ats
+### ats (x86)
 > `= `
 
 > Default: `false`
@@ -276,7 +276,7 @@ when the RSB gets overwritten.  The former control all RSB 
overwriting, while
 the latter two can be used to fine tune overwriting on from HVM context, and
 an entry from a native (PV or Xen) context.
 
-### clocksource
+### clocksource (x86)
 > `= pit | hpet | acpi | tsc`
 
 If set, override Xen's default choice for the platform timer.
@@ -287,7 +287,7 @@ the number of allowed CPUs.  When running on platforms that 
can guarantee a
 monotonic TSC across sockets you may want to adjust the "tsc" command line
 parameter to "stable:socket".
 
-### cmci-threshold
+### cmci-threshold (Intel)
 > `= `
 
 > Default: `2`
@@ -295,7 +295,7 @@ parameter to "stable:socket".
 Specify the event count threshold for raising Corrected Machine Check
 Interrupts.  Specifying zero disables CMCI handling.
 
-### cmos-rtc-probe
+### cmos-rtc-probe (x86)
 > `= `
 
 > Default: `false`
@@ -459,7 +459,7 @@ character, but for xen to keep the console.
 
 > Default: `power`
 
-### cpu\_type
+### cpu\_type (x86)
 > `= arch_perfmon`
 
 If set, force use of the performance counters for oprofile, rather than 
detecting
@@ -499,7 +499,7 @@ pre-canned cpuid mask to mask the current processor down to 
appear as
 the specified processor. It is important to ensure that all hosts in a
 pool appear the same to guests to allow successful live migration.
 
-### cpuid\_mask\_{{,ext\_}ecx,edx}
+### cpuid\_mask\_{{,ext\_}ecx,edx} (x86)
 > `= `
 
 > Default: `~0` (all bits set)
@@ -529,10 +529,10 @@ These three command line parameters are also used to 
specify cpuid
 masks to help with cpuid levelling across a pool of hosts.  See the
 description of the other respective options above.
 
-### cpuidle
+### cpuidle (x86)
 > `= `
 
-### cpuinfo
+### cpuinfo (x86)
 > `= `
 
 ### crashinfo\_maxaddr
@@ -647,7 +647,7 @@ trace feature is only enabled in debugging builds of Xen.
 
 Specify the bit width of the DMA heap.
 
-### 

[Xen-devel] [PATCH v2 4/5] doc: correct feature-levelling.pandoc syntax

[Juergen Gross]

"make -C docs all" fails due to incorrect markdown syntax in
feature-levelling.pandoc. Correct it.

Signed-off-by: Juergen Gross 
---
 docs/features/feature-levelling.pandoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/features/feature-levelling.pandoc 
b/docs/features/feature-levelling.pandoc
index ef77eb837d..4b2b6df151 100644
--- a/docs/features/feature-levelling.pandoc
+++ b/docs/features/feature-levelling.pandoc
@@ -83,7 +83,7 @@ not trap, leaving Xen no direct ability to control the 
information returned.
 
 Xen-aware PV software can make use of the 'Forced Emulation Prefix'
 
-> `ud2a; .ascii 'xen'; cpuid`
+ud2a; .ascii 'xen'; cpuid
 
 which Xen recognises as a deliberate attempt to get the fully-controlled
 `CPUID` information rather than the hardware-reported information.  This only
-- 
2.13.6


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

[Xen-devel] [PATCH v2 5/5] doc: correct intel_psr_cat_cdp.pandoc syntax

[Juergen Gross]

"make -C docs all" fails due to incorrect markdown syntax in
intel_psr_cat_cdp.pandoc. Correct it.

Signed-off-by: Juergen Gross 
---
 docs/features/intel_psr_cat_cdp.pandoc | 366 -
 1 file changed, 175 insertions(+), 191 deletions(-)

diff --git a/docs/features/intel_psr_cat_cdp.pandoc 
b/docs/features/intel_psr_cat_cdp.pandoc
index 04fb256dd9..c619e2cc99 100644
--- a/docs/features/intel_psr_cat_cdp.pandoc
+++ b/docs/features/intel_psr_cat_cdp.pandoc
@@ -104,19 +104,18 @@ PSR infrastructure in Xen.
   CAT/CDP defines a range of MSRs to assign different cache access patterns
   which are known as CBMs, each CBM is associated with a COS.
 
-  ```
   E.g. L2 CAT:
-  +++
- IA32_PQR_ASSOC   | MSR (per socket)   |Address |
-   ++---+---+ +++
-   ||COS|   | | IA32_L2_QOS_MASK_0 | 0xD10  |
-   ++---+---+ +++
-  +-> | ...|  ...   |
-  +++
-  | IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
-  +++
-  ```
-
+
+  +++
+ IA32_PQR_ASSOC   | MSR (per socket)   |Address |
+   ++---+---+ +++
+   ||COS|   | | IA32_L2_QOS_MASK_0 | 0xD10  |
+   ++---+---+ +++
+  +-> | ...|  ...   |
+  +++
+  | IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
+  +++
+
   L3 CAT/CDP uses a range of MSRs from 0xC90 ~ 0xC90+n (n<128).
 
   L2 CAT uses a range of MSRs from 0xD10 ~ 0xD10+n (n<64), following the L3
@@ -132,41 +131,39 @@ PSR infrastructure in Xen.
   note that all (and only) contiguous '1' combinations are allowed (e.g. H,
   0FF0H, 003CH, etc.).
 
-  ```
-   +++++++++
-   | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
-   +++++++++
-  COS0 | A  | A  | A  | A  | A  | A  | A  | A  | Default Bitmask
-   +++++++++
-  COS1 | A  | A  | A  | A  | A  | A  | A  | A  |
-   +++++++++
-  COS2 | A  | A  | A  | A  | A  | A  | A  | A  |
-   +++++++++
-
-   +++++++++
-   | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
-   +++++++++
-  COS0 | A  | A  | A  | A  | A  | A  | A  | A  | Overlapped Bitmask
-   +++++++++
-  COS1 ||||| A  | A  | A  | A  |
-   +++++++++
-  COS2 ||||||| A  | A  |
-   +++++++++
-
-   +++++++++
-   | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
-   +++++++++
-  COS0 | A  | A  | A  | A  ||||| Isolated Bitmask
-   +++++++++
-  COS1 ||||| A  | A  |||
-   +++++++++
-  COS2 ||||||| A  | A  |
-   +++++++++
-  ```
+   +++++++++
+   | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
+   +++++++++
+  COS0 | A  | A  | A  | A  | A  | A  | A  | A  | Default Bitmask
+   +++++++++
+  COS1 | A  | A  | A  | A  | A  | A  | A  | A  |
+   +++++++++
+  COS2 | A  | A  | A  | A  | A  | A  | A  | A  |
+   +++++++++
+
+   +++++++++
+   | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
+   +++++++++
+  COS0 | A  | A  | A  | A  | A  | A  | A  | A  | Overlapped Bitmask
+   +++++++++
+  COS1 ||||| A  | A  | A  | A  |
+   +++++++++
+  COS2 ||||||| A  | A  |
+   +++++++++
+
+   +++++++++
+   | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
+   

[Xen-devel] [distros-debian-sid test] 74689: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install   fail like 74650
 test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 74650
 test-amd64-i386-amd64-sid-netboot-pygrub 10 debian-di-install  fail like 74650
 test-amd64-amd64-amd64-sid-netboot-pvgrub 10 debian-di-install fail like 74650
 test-amd64-amd64-i386-sid-netboot-pygrub 10 debian-di-install  fail like 74650

baseline version:
 flight   74650

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



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

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

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


Push not applicable.


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

[Xen-devel] [xen-unstable-smoke test] 122632: regressions - trouble: blocked/broken/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 build-armhf   5 host-build-prep  fail REGR. vs. 122620

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  3abe241190af31760c506a9f32bf25e958ea060c
baseline version:
 xen  e38e285a51c805cfeee4693962df23e39b3c3bd7

Last test of basis   122620  2018-05-05 21:05:34 Z1 days
Testing same since   122632  2018-05-07 08:01:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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

broken-job build-armhf broken

Not pushing.


commit 3abe241190af31760c506a9f32bf25e958ea060c
Author: Jan Beulich 
Date:   Mon May 7 09:12:16 2018 +0200

SVM: introduce a VM entry helper

Neither the register values copying nor the trace entry generation need
doing in assembly. The VMLOAD invocation can also be further deferred
(and centralized). Therefore replace the svm_asid_handle_vmrun()
invocation with one of the new helper.

Similarly move the VM exit side register value copying into
svm_vmexit_handler().

Now that we always make it out to guest context after VMLOAD,
svm_sync_vmcb() no longer overrides vmcb_needs_vmsave, making
svm_vmexit_handler() setting the field early unnecessary.

Signed-off-by: Jan Beulich 
Acked-by: Andrew Cooper 
Reviewed-by: Boris Ostrovsky 
Release-acked-by: Juergen Gross 

commit cb6ff207f7e0bbfe2d9ab3cb1a0866962cf17169
Author: Jan Beulich 
Date:   Mon May 7 09:11:15 2018 +0200

SVM: re-work VMCB sync-ing

While the main problem to be addressed here is the issue of what so far
was named "vmcb_in_sync" starting out with the wrong value (should have
been true instead of false, to prevent performing a VMSAVE without ever
having VMLOADed the vCPU's state), go a step further and make the
sync-ed state a tristate: CPU and memory may be in sync or an update
may be required in either direction. Rename the field and introduce an
enum. Callers of svm_sync_vmcb() now indicate the intended new state
(with a slight "anomaly" when requesting VMLOAD: we could store
vmcb_needs_vmsave in those cases as the callers request, but the VMCB
really is in sync at that point, and hence there's no need to VMSAVE in
case we don't make it out to guest context), and all syncing goes
through that function.

With that, there's no need to VMLOAD the state perhaps multiple times;
all that's needed is loading it once before VM entry.

Signed-off-by: Jan Beulich 
Acked-by: Andrew Cooper 
Reviewed-by: Boris Ostrovsky 
Release-acked-by: Juergen Gross 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH v4] x86/cpu: Add supports for zhaoxin x86 platform

[Jan Beulich]

>>> On 07.05.18 at 03:37,  wrote:
> --- a/xen/arch/x86/cpu/intel_cacheinfo.c
> +++ b/xen/arch/x86/cpu/intel_cacheinfo.c
> @@ -176,7 +176,9 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
>* Don't use cpuid2 if cpuid4 is supported. For P4, we use cpuid2 for
>* trace cache
>*/
> - if ((num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1) {
> + if ( (num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1 &&
> + c->x86_vendor != X86_VENDOR_SHANGHAI )

The indentation here is _still_ wrong (and there are stray spaces), but I'll try
to remember fixing this up when committing (after 4.11 was branched off),
i.e. with that fixed
Acked-by: Jan Beulich 

Also once again - in the future, after the 1st --- separator please add an
overview of what has changed from the previous version.

Jan



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

[Xen-devel] [PATCH v4 1/2] x86/hvm: Introduce *save_one() functions

[Alexandru Isaila]

This patch introduces save_one() functions. They will be called in the
*save() so we can extract data for a single instance.

Signed-off-by: Alexandru Isaila 

---
Changes since V3:
- Rb to the lateste staging version
- Split the patch into 2 patches.
---
 xen/arch/x86/cpu/mcheck/vmce.c |  16 ++-
 xen/arch/x86/hvm/hvm.c | 279 ++---
 xen/arch/x86/hvm/mtrr.c|  51 
 xen/arch/x86/hvm/viridian.c|  13 +-
 4 files changed, 200 insertions(+), 159 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index e07cd2f..15b0f2a 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -349,6 +349,14 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 return ret;
 }
 
+void vmce_save_vcpu_ctxt_one(struct vcpu *v, struct hvm_vmce_vcpu *ctxt)
+{
+ctxt->caps = v->arch.vmce.mcg_cap;
+ctxt->mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
+ctxt->mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
+ctxt->mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
+}
+
 static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -356,13 +364,9 @@ static int vmce_save_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 
 for_each_vcpu ( d, v )
 {
-struct hvm_vmce_vcpu ctxt = {
-.caps = v->arch.vmce.mcg_cap,
-.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2,
-.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2,
-.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl,
-};
+struct hvm_vmce_vcpu ctxt;
 
+vmce_save_vcpu_ctxt_one(v, );
 err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
 if ( err )
 break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c23983c..6733f26 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -740,6 +740,11 @@ void hvm_domain_destroy(struct domain *d)
 destroy_vpci_mmcfg(d);
 }
 
+void hvm_save_tsc_adjust_one(struct vcpu *v, struct hvm_tsc_adjust *ctxt)
+{
+ctxt->tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
+}
+
 static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -748,7 +753,7 @@ static int hvm_save_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 
 for_each_vcpu ( d, v )
 {
-ctxt.tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
+hvm_save_tsc_adjust_one(v, );
 err = hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
 if ( err )
 break;
@@ -780,11 +785,109 @@ static int hvm_load_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
   hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
 
+void hvm_save_cpu_ctxt_one(struct vcpu *v, struct hvm_hw_cpu *ctxt)
+{
+struct segment_register seg;
+
+/* Architecture-specific vmcs/vmcb bits */
+hvm_funcs.save_cpu_ctxt(v, ctxt);
+
+ctxt->tsc = hvm_get_guest_tsc_fixed(v, 
v->domain->arch.hvm_domain.sync_tsc);
+
+ctxt->msr_tsc_aux = hvm_msr_tsc_aux(v);
+
+hvm_get_segment_register(v, x86_seg_idtr, );
+ctxt->idtr_limit = seg.limit;
+ctxt->idtr_base = seg.base;
+
+hvm_get_segment_register(v, x86_seg_gdtr, );
+ctxt->gdtr_limit = seg.limit;
+ctxt->gdtr_base = seg.base;
+
+hvm_get_segment_register(v, x86_seg_cs, );
+ctxt->cs_sel = seg.sel;
+ctxt->cs_limit = seg.limit;
+ctxt->cs_base = seg.base;
+ctxt->cs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ds, );
+ctxt->ds_sel = seg.sel;
+ctxt->ds_limit = seg.limit;
+ctxt->ds_base = seg.base;
+ctxt->ds_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_es, );
+ctxt->es_sel = seg.sel;
+ctxt->es_limit = seg.limit;
+ctxt->es_base = seg.base;
+ctxt->es_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ss, );
+ctxt->ss_sel = seg.sel;
+ctxt->ss_limit = seg.limit;
+ctxt->ss_base = seg.base;
+ctxt->ss_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_fs, );
+ctxt->fs_sel = seg.sel;
+ctxt->fs_limit = seg.limit;
+ctxt->fs_base = seg.base;
+ctxt->fs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_gs, );
+ctxt->gs_sel = seg.sel;
+ctxt->gs_limit = seg.limit;
+ctxt->gs_base = seg.base;
+ctxt->gs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_tr, );
+ctxt->tr_sel = seg.sel;
+ctxt->tr_limit = seg.limit;
+ctxt->tr_base = seg.base;
+ctxt->tr_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ldtr, );
+ctxt->ldtr_sel = seg.sel;
+ctxt->ldtr_limit = seg.limit;
+ctxt->ldtr_base = seg.base;
+ctxt->ldtr_arbytes = seg.attr;
+
+if ( v->fpu_initialised )
+{
+memcpy(ctxt->fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt->fpu_regs));
+ctxt->flags = XEN_X86_FPU_INITIALISED;

[Xen-devel] [PATCH v4 2/2] x86/domctl: Don't pause the whole domain if only getting vcpu state

[Alexandru Isaila]

This patch adds a vcpu param for all the *save() fucntions. The *save()
functions now handle only one instance. The for_each loop is transferred
to the caller.

Signed-off-by: Alexandru Isaila 

---
Changes since V3:
- Rb to the lateste staging version
- Moved the for_each() loop to the caller.

NOTE: tested with xen/tools/misc/xen-hvmctx
---
 tools/tests/vhpet/emul.h   |   3 +-
 tools/tests/vhpet/main.c   |   8 ++-
 xen/arch/x86/cpu/mcheck/vmce.c |  16 ++
 xen/arch/x86/hvm/hpet.c|   3 +-
 xen/arch/x86/hvm/hvm.c | 122 +++--
 xen/arch/x86/hvm/i8254.c   |   3 +-
 xen/arch/x86/hvm/irq.c |   9 ++-
 xen/arch/x86/hvm/mtrr.c|  14 ++---
 xen/arch/x86/hvm/pmtimer.c |   3 +-
 xen/arch/x86/hvm/rtc.c |   3 +-
 xen/arch/x86/hvm/save.c| 115 --
 xen/arch/x86/hvm/vioapic.c |   3 +-
 xen/arch/x86/hvm/viridian.c|  18 +++---
 xen/arch/x86/hvm/vlapic.c  |  28 --
 xen/arch/x86/hvm/vpic.c|   3 +-
 xen/include/asm-x86/hvm/save.h |   3 +-
 16 files changed, 199 insertions(+), 155 deletions(-)

diff --git a/tools/tests/vhpet/emul.h b/tools/tests/vhpet/emul.h
index 383acff..053a1f5 100644
--- a/tools/tests/vhpet/emul.h
+++ b/tools/tests/vhpet/emul.h
@@ -296,7 +296,8 @@ struct hvm_hw_hpet
 };
 
 typedef int (*hvm_save_handler)(struct domain *d,
-hvm_domain_context_t *h);
+hvm_domain_context_t *h,
+struct vcpu *vcpu);
 typedef int (*hvm_load_handler)(struct domain *d,
 hvm_domain_context_t *h);
 
diff --git a/tools/tests/vhpet/main.c b/tools/tests/vhpet/main.c
index 6fe65ea..77143dc 100644
--- a/tools/tests/vhpet/main.c
+++ b/tools/tests/vhpet/main.c
@@ -177,7 +177,13 @@ void __init hvm_register_savevm(uint16_t typecode,
 
 int do_save(uint16_t typecode, struct domain *d, hvm_domain_context_t *h)
 {
-return hvm_sr_handlers[typecode].save(d, h);
+struct vcpu *v;
+
+for_each_vcpu ( d, v )
+{
+hvm_sr_handlers[typecode].save(d, h, v);
+}
+return 0;
 }
 
 int do_load(uint16_t typecode, struct domain *d, hvm_domain_context_t *h)
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 15b0f2a..2286875 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -357,20 +357,14 @@ void vmce_save_vcpu_ctxt_one(struct vcpu *v, struct 
hvm_vmce_vcpu *ctxt)
 ctxt->mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
 }
 
-static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h,
+   struct vcpu *v)
 {
-struct vcpu *v;
 int err = 0;
+struct hvm_vmce_vcpu ctxt;
 
-for_each_vcpu ( d, v )
-{
-struct hvm_vmce_vcpu ctxt;
-
-vmce_save_vcpu_ctxt_one(v, );
-err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
-if ( err )
-break;
-}
+vmce_save_vcpu_ctxt_one(v, );
+err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
 
 return err;
 }
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index f7aed7f..d95c72b 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -509,7 +509,8 @@ static const struct hvm_mmio_ops hpet_mmio_ops = {
 };
 
 
-static int hpet_save(struct domain *d, hvm_domain_context_t *h)
+static int hpet_save(struct domain *d, hvm_domain_context_t *h,
+ struct vcpu *vcpu)
 {
 HPETState *hp = domain_vhpet(d);
 struct vcpu *v = pt_global_vcpu_target(d);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6733f26..16d6736 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -745,19 +745,14 @@ void hvm_save_tsc_adjust_one(struct vcpu *v, struct 
hvm_tsc_adjust *ctxt)
 ctxt->tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
 }
 
-static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h,
+   struct vcpu *v)
 {
-struct vcpu *v;
 struct hvm_tsc_adjust ctxt;
 int err = 0;
 
-for_each_vcpu ( d, v )
-{
-hvm_save_tsc_adjust_one(v, );
-err = hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
-if ( err )
-break;
-}
+hvm_save_tsc_adjust_one(v, );
+err = hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
 
 return err;
 }
@@ -884,25 +879,23 @@ void hvm_save_cpu_ctxt_one(struct vcpu *v, struct 
hvm_hw_cpu *ctxt)
 ctxt->dr7 = v->arch.debugreg[7];
 }
 
-static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h,
+ struct vcpu *v)
 {
-struct vcpu *v;
 struct hvm_hw_cpu ctxt;
 
-

Re: [Xen-devel] domain_crash_sync vs "plain crash"

[Andrew Cooper]

On 07/05/2018 08:09, Jan Beulich wrote:
 On 07.05.18 at 03:06,  wrote:
>> When I'm performing some hypercalls with some "unexpected" parameters
>> (robustness test) sometimes the guest is explicitly  "killed" by xen
>> calling the domain_crash(), but sometimes the guest just crash without any
>> explicit message on dmesg or logs.
>>
>> Are those "plain crashes" an expected behavior by design on Xen or are they
>> some untreated parameter checking or something else?
> A silent crash is never supposed to happen, but you always need to first
> consider whether the crashing component actually has a way to get
> something out to wherever you monitor its logs. That is, without (physical
> or virtual, depending on component) serial console you're often unlikely to
> actually observe any messages connected to the crash.
>
> If you can track down a _truly_ silent crash to its origin, submitting a patch
> to make it non-silent would be appreciated.

Alternatively, if you are fuzzing the hypercalls, which it sounds like
you are, then you need to ensure that you blacklist operations such as
SCHEDOP_shutdown and SCHEDOP_poll to avoid the fuzzer hitting legitimate
hypercalls which shut down or block for indefinite periods of time.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

[Andrew Cooper]

On 07/05/2018 09:00, Jan Beulich wrote:
 On 07.05.18 at 09:30,  wrote:
>> On 07/05/2018 08:03, Jan Beulich wrote:
>> On 04.05.18 at 19:28,  wrote:
 --- a/xen/arch/x86/pv/emul-priv-op.c
 +++ b/xen/arch/x86/pv/emul-priv-op.c
 @@ -867,7 +867,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
  return X86EMUL_OKAY;
  
  case MSR_EFER:
 -*val = read_efer();
 +/* Hide unknown bits, and unconditionally hide SVME from guests. 
 */
 +*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
 +/* Hide the 64-bit features from 32-bit guests. */
  if ( is_pv_32bit_domain(currd) )
  *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
>>> Wouldn't it be better then to also move the LMSLE hiding up?
>> Actually, on second consideration, LMSLE shouldn't be hidden.  If LMSLE
>> is actually active, then segment descriptors behave differently whether
>> the guest knows about it or not.
> Actually - the placement shouldn't matter at all: I think it can't be set 
> anyway,
> as we would only possibly allow HVM guests to set it, i.e. the EFER value
> loaded during #VMEXIT won't ever have the bit set at present. And even the
> HVM side code uniformly forces cpu_has_lmsl to false right now.

On 3rd consideration, the current placement is correct.  LMSLE, if set,
only has any effect on data segment when running with a long mode %cs. 
Therefore, the clobber is in the right place.  Were we ever to enable it
in Xen, this code would be correct.

On the HVM side, yes - we still have it disabled for migration reasons. 
That said, I think we should consider dropping it entirely.  Even AMD
think it is an unused feature.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

[Jan Beulich]

>>> On 07.05.18 at 09:30,  wrote:
> On 07/05/2018 08:03, Jan Beulich wrote:
> On 04.05.18 at 19:28,  wrote:
>>> --- a/xen/arch/x86/pv/emul-priv-op.c
>>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>>> @@ -867,7 +867,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
>>>  return X86EMUL_OKAY;
>>>  
>>>  case MSR_EFER:
>>> -*val = read_efer();
>>> +/* Hide unknown bits, and unconditionally hide SVME from guests. */
>>> +*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
>>> +/* Hide the 64-bit features from 32-bit guests. */
>>>  if ( is_pv_32bit_domain(currd) )
>>>  *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
>> Wouldn't it be better then to also move the LMSLE hiding up?
> 
> Actually, on second consideration, LMSLE shouldn't be hidden.  If LMSLE
> is actually active, then segment descriptors behave differently whether
> the guest knows about it or not.

Actually - the placement shouldn't matter at all: I think it can't be set 
anyway,
as we would only possibly allow HVM guests to set it, i.e. the EFER value
loaded during #VMEXIT won't ever have the bit set at present. And even the
HVM side code uniformly forces cpu_has_lmsl to false right now.

>> And what about SCE?
> 
> Rather more difficult to say, given its cross-vendor behaviour.  It
> should probably be clobbered if 32bit && Intel, but 32bit AMD can use
> SYSCALL if it wishes.

Ah, yes, agreed.

Jan



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

Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

[Andrew Cooper]

On 07/05/2018 08:03, Jan Beulich wrote:
 On 04.05.18 at 19:28,  wrote:
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -867,7 +867,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
>>  return X86EMUL_OKAY;
>>  
>>  case MSR_EFER:
>> -*val = read_efer();
>> +/* Hide unknown bits, and unconditionally hide SVME from guests. */
>> +*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
>> +/* Hide the 64-bit features from 32-bit guests. */
>>  if ( is_pv_32bit_domain(currd) )
>>  *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);
> Wouldn't it be better then to also move the LMSLE hiding up?

Actually, on second consideration, LMSLE shouldn't be hidden.  If LMSLE
is actually active, then segment descriptors behave differently whether
the guest knows about it or not.

> And what about SCE?

Rather more difficult to say, given its cross-vendor behaviour.  It
should probably be clobbered if 32bit && Intel, but 32bit AMD can use
SYSCALL if it wishes.

>  PV guests not being allowed to write EFER, I would think they shouldn't
> see bits they aren't supposed to care about and aren't able to set. If we
> were to allow such writes, I assume it would only be NX and maybe FFXSE
> which we'd permit the guest to control. Obviously (I think) LME and LMA ought
> to be seen set by 64-bit guests.

I don't see any value in letting PV guests write to EFER.  They never
have been able to in the past, and letting them play with NX has a
direct safety impact on Xen when XPTI is not in use.

~Andrew

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

Re: [Xen-devel] domain_crash_sync vs "plain crash"

[Jan Beulich]

>>> On 07.05.18 at 03:06,  wrote:
> When I'm performing some hypercalls with some "unexpected" parameters
> (robustness test) sometimes the guest is explicitly  "killed" by xen
> calling the domain_crash(), but sometimes the guest just crash without any
> explicit message on dmesg or logs.
> 
> Are those "plain crashes" an expected behavior by design on Xen or are they
> some untreated parameter checking or something else?

A silent crash is never supposed to happen, but you always need to first
consider whether the crashing component actually has a way to get
something out to wherever you monitor its logs. That is, without (physical
or virtual, depending on component) serial console you're often unlikely to
actually observe any messages connected to the crash.

If you can track down a _truly_ silent crash to its origin, submitting a patch
to make it non-silent would be appreciated.

Jan



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

Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

[Jan Beulich]

>>> On 04.05.18 at 19:28,  wrote:
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -867,7 +867,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
>  return X86EMUL_OKAY;
>  
>  case MSR_EFER:
> -*val = read_efer();
> +/* Hide unknown bits, and unconditionally hide SVME from guests. */
> +*val = read_efer() & EFER_KNOWN_MASK & ~EFER_SVME;
> +/* Hide the 64-bit features from 32-bit guests. */
>  if ( is_pv_32bit_domain(currd) )
>  *val &= ~(EFER_LME | EFER_LMA | EFER_LMSLE);

Wouldn't it be better then to also move the LMSLE hiding up? And what about
SCE? PV guests not being allowed to write EFER, I would think they shouldn't
see bits they aren't supposed to care about and aren't able to set. If we
were to allow such writes, I assume it would only be NX and maybe FFXSE
which we'd permit the guest to control. Obviously (I think) LME and LMA ought
to be seen set by 64-bit guests.

Jan



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

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

[Juergen Gross]

On 04/05/18 17:11, Jan Beulich wrote:
> Neither the register values copying nor the trace entry generation need
> doing in assembly. The VMLOAD invocation can also be further deferred
> (and centralized). Therefore replace the svm_asid_handle_vmrun()
> invocation with one of the new helper.
> 
> Similarly move the VM exit side register value copying into
> svm_vmexit_handler().
> 
> Now that we always make it out to guest context after VMLOAD,
> svm_sync_vmcb() no longer overrides vmcb_needs_vmsave, making
> svm_vmexit_handler() setting the field early unnecessary.
> 
> Signed-off-by: Jan Beulich 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v3 1/2] SVM: re-work VMCB sync-ing

[Juergen Gross]

On 04/05/18 17:10, Jan Beulich wrote:
> While the main problem to be addressed here is the issue of what so far
> was named "vmcb_in_sync" starting out with the wrong value (should have
> been true instead of false, to prevent performing a VMSAVE without ever
> having VMLOADed the vCPU's state), go a step further and make the
> sync-ed state a tristate: CPU and memory may be in sync or an update
> may be required in either direction. Rename the field and introduce an
> enum. Callers of svm_sync_vmcb() now indicate the intended new state
> (with a slight "anomaly" when requesting VMLOAD: we could store
> vmcb_needs_vmsave in those cases as the callers request, but the VMCB
> really is in sync at that point, and hence there's no need to VMSAVE in
> case we don't make it out to guest context), and all syncing goes
> through that function.
> 
> With that, there's no need to VMLOAD the state perhaps multiple times;
> all that's needed is loading it once before VM entry.
> 
> Signed-off-by: Jan Beulich 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

[Juergen Gross]

On 04/05/18 19:28, Andrew Cooper wrote:
> We don't advertise SVM in CPUID so a PV guest shouldn't be under the
> impression that it can use SVM functionality, but despite this, it really
> shouldn't see SVME set when reading EFER.
> 
> Introduce EFER_KNOWN_MASK to whitelist the features Xen knows about, and use
> this to clamp the guests view.
> 
> Take the opportunity to reuse the mask to simplify svm_vmcb_isvalid(), and
> change "undefined" to "unknown" in the print message, as there is at least
> EFER.TCE (Translation Cache Extension) defined but unknown to Xen.
> 
> Signed-off-by: Andrew Cooper 

Release-acked-by: Juergen Gross 

Juergen

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

Re: [Xen-devel] Community call: PCI Emulation - Future Direction (Wed, May 2nd, UTC 16:00-17:00 / BST 17:00-18:00) - Minutes

[Alexey G]

On Fri, 4 May 2018 15:38:49 +
Lars Kurth  wrote:
[...]
>Julien: where would the reset code live then?
>Christopher: would want to avoid Dom0 having access to the config space. The 
>VM hosting
>the toolstack will need to exercise control over access to the config space.
>Roger: Another option would be to do this inside of Xen via a hypercall
>Julien: moving reset from Linux into Xen would be quote complex.
>Paul: Handling the reset and quirks within Xen seems perfectly reasonable
>Christopher: handling the sequence to reset the device is quite complex
>Stefano: Aside from who does what are there any specific requirements we need 
>to pay
>attention to for complex devices such as GPUs (such as IOMMU mapping)
>Alexey: saw devices which do not like secondary bus reset (e.g. some NVIDIA 
>GPUs) -
>When we use the device and restart the domain, it will hang during boot.
>Roger: know there are issues with some devices.
>Stefano: Surprisingly high number of quirks. So the question is who maintains 
>the quirks. If
>we moved it to Xen, we may not get contributions to fix quirks. We would have 
>to monitor
>Linux and then move code, which increases the codsize
>Roger: The code would be somewhere in any case, either Xen or Dom0 kernel: so 
>why does
>the codesize matter?
>Daniel: the code size does not go away, but the question is how it can be 
>isolated
>Stefano: depending on where it is, the stability of the system is directly 
>impacted
>Alexey: need to provide device specific quirks to reset the device
>Alexey: Have not looked at Linux quirks for resetting devices. Reset is 
>mandatory (must be
>performed in many cases such as domain restart, ...). Can move from secondary 
>reset to
>other reset methods and work around specific quirks.
>Rich: Mentioned that Oracle posted some reset code recently for XenClient into 
>Linux.
>**Next steps:**
>* Should we start a discussion on the mailing list on how to resolve the reset 
>question.
>ACTION: Rich to start the thread (the people participating in the reset 
>discussion to
>be CC’ed)

First of all, sorry for my poor English skills.

Regarding the secondary bus reset VS some nvidia GPUs -- the exact
behavior was like this:

- if we do SBR on the affected device BEFORE it was initialized by its
  proprietary driver -- there is no problem, SBR works exactly the same
  as expected, no issues upon the domain restart (for example, if we
  restart a domain before a guest OS switched to native display drivers).

- the same is applicable if there is no proprietary driver installed at
  all -- no problems for SBR at any time of the domain lifetime

- if we do SBR on the affected device AFTER it was initialized by its
  proprietary driver -- then there will be a problem after restarting
  the domain with such GPU in primary mode -- GPU videobios will hang
  polling one of GPU registers. Interestingly enough, if we hide Option
  ROM and skip videobios execution, leaving GPU to proprietary driver
  only, then there are no issues. The drawback is that there will be no
  early video output (until the Welcome screen).

- in both cases performing SBR looks good at first -- the screen goes
  blank, PCI conf fields got reset (including BAR values), both
  functions are affected by SBR.

- in all cases, a proprietary reset for these GPUs works perfectly

Seems like these particular devices do not fully conform to the PCIe
specification in responding to the PCIe link reset and leave some
state/registers non-reset. This (apparently buggy) behavior is not
common for all nvidia GPUs, but multiple videocards manifesting this
issue were encountered.

With such devices in mind, possible priorities for reset methods can be
(with SBR/FLR priority questionable):

Quirks (if any) -> SBR -> FLR -> (PM reset, though this one is pretty much 
useless as it seems)

Quirks can be handled in a usual way -- probing the device by VID/DID
against a quirk table and calling a custom reset callback if a match
found.

One thing to note is that both quirk reset and SBR may affect multiple
devices (i.e. functions).

So a good topic to discuss might be designing a new interface to
reset passed through devices which can take into account dependencies
between PCI/PCIe devices and the reset methods that may affect a group
of devices at the same time. The existing ('do_flr'-like) interface
currently doesn't know anything about device relations.

>## Stefano/Julien: ​ARM guest pci-passthrough
>
>Julien: the idea was not really speaking about PCI passthrough, but to follow 
>what is
>happening on ARM. Don’t have any specific things to talk about.
>Stefano: The challenge on ARM has been a few incompatible implementations in 
>the config
>space. Initially we didn't know what to do. We then decided to start simple 
>and implement the
>standard compliant functions in the HV. And then cross the bridge of 
>incompatible config
>space registers when we come to it.
>Julien: mostly looking on what is