Re: [Xen-devel] Status of 4.13

[Roman Shaposhnik]

On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper  wrote:
>
> On 21/11/2019 17:31, Roman Shaposhnik wrote:
> > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß  wrote:
> >> Where do we stand with Xen 4.13 regarding blockers and related patches?
> >>
> >> 1. OSStest failure regarding nested test:
> >> I'm not quite sure whether the currently debated patch of Andrew is
> >> fixing the problem. If not, do we know what is missing or how to
> >> address the issue? If yes, could we please come to an agreement?
> >> As an alternative: any thoughts about ignoring this test failure for
> >> 4.13-RC3 (IOW: doing a force push)?
> >>
> >> 2. Ryzen/Rome failures with Windows guests:
> >> What is the currently planned way to address the problem? Who is
> >> working on that?
> >>
> >> 3. Pending patches for 4.13:
> >> Could I please have feedback which patches tagged as "for-4.13" are
> >> fixing real regressions or issues? I don't want to take any patches
> >> not fixing real problems after RC3, and I hope to be able to get a
> >> push rather sooner than later to be able to let Ian cut RC3.
> >>
> >> 4. Are there any blockers for 4.13 other than 1. and 2. (apart of any
> >> pending XSAs)?
> > Any chance the efi=no-rs regression can be added to the list? I understand
> > that I'm still on the hook to provide more details (I promise to do it on 
> > Fri
> > when I get to my lab to actually have a serial console on all these boxes).
> > At the same time this is a pretty serious regression for an entire class of
> > devices where Xen was perfectly happy even during RC1.
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=534f9e29ce28580892b3856036b5e5cd805667cc
> has been committed.  It is in staging, but not in master yet (because
> master is blocked by my regression in 1).

Reporting back after spending some time in the lab today:

1. Good news, the above patch takes care of the regression. I can now
add efi=no-rs
back and Xen boots (and also boots Dom0) on all the boxes involved.

2. Neutral news: Dell product line still requires efi=no-rs and
coredumps without it
(no regression -- that's I started using efi=no-rs to begin with).

3. Bad news: Marek's suggestion didn't work on Dell product line (and yes
I double checked that I built it correctly).

So... when it comes to RC2 regression -- we're all good.

But since we're here anyway -- I'm wondering if anyone would be
interested in helping me figure out why Xen on those Dell boxes coredumps
without efi=no-rs ?

Marek, any chance I can interest you in helping me a bit here? ;-)

Thanks,
Roman.

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

Re: [Xen-devel] [PATCH] x86/mm: Adjust linear uses / entries when a page loses validation

[Jürgen Groß]

On 22.11.19 19:52, George Dunlap wrote:

"Linear pagetables" is a technique which involves either pointing a
pagetable at itself, or to another pagetable the same or higher level.
Xen has limited support for linear pagetables: A page may either point
to itself, or point to another page of the same level (i.e., L2 to L2,
L3 to L3, and so on).

XSA-240 introduced an additional restriction that limited the "depth"
of such chains by allowing pages to either *point to* other pages of
the same level, or *be pointed to* by other pages of the same level,
but not both.  To implement this, we keep track of the number of
outstanding times a page points to or is pointed to another page
table, to prevent both from happening at the same time.

Additionally, XSA-299 introduced a mode whereby if a page was known to
have been only partially validated, _put_page_type() would be called
with PTF_partial_set, indicating that if the page had been
de-validated by someone else, the type count should be left alone.

Unfortunately, this change did not account for the required accounting
for linear page table uses and entries; in the case that a previously
partially-devalidated pagetable was fully-devalidated by someone else,
the linear_pt_counts are not updated.

This could happen in one of two places:

1. In the case a partially-devalidated page was re-validated by
someone else

2. During domain tear-down, when pages are force-invalidated while
leaving the type count intact.

The second could be ignored, since at that point the pages can no
longer be abused; but the first requires handling.  Note however that
this would not be a security issue: having the counts be too high is
overly strict (i.e., will prevent a page from being used in a way
which is perfectly safe), but shouldn't cause any other issues.

Fix this by adjusting the linear counts when a page loses validation,
regardless of whether the de-validation completed or was only partial.

Signed-off-by: George Dunlap 
Reviewed-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.13] x86/vvmx: Fix livelock with XSA-304 fix

[Jürgen Groß]

On 22.11.19 18:54, Andrew Cooper wrote:

It turns out that the XSA-304 / CVE-2018-12207 fix of disabling executable
superpages doesn't work well with the nested p2m code.

Nested virt is experimental and not security supported, but is useful for
development purposes.  In order to not regress the status quo, disable the
XSA-304 workaround until the nested p2m code can be improved.

Introduce a per-domain exec_sp control and set it based on the current
opt_ept_exec_sp setting.  Take the oppotunity to omit a PVH hardware domain
from the performance hit, because it is already permitted to DoS the system in
such ways as issuing a reboot.

When nested virt is enabled on a domain, force it to using executable
superpages and rebuild the p2m.

Having the setting per-domain involves rearranging the internals of
parse_ept_param_runtime() but it still retains the same overall semantics -
for each applicable domain whose setting needs to change, rebuild the p2m.

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] [PATCH v1.5] x86/livepatch: Prevent patching with active waitqueues

[Sarah Newman]

On 11/5/19 11:49 AM, Andrew Cooper wrote:

The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true.  The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different vcpu.

This case is rare, and can be worked around by pausing the offending
domain(s), waiting for their rings to drain, then performing a livepatch.

In the case that there is an active waitqueue, fail the livepatch attempt with
-EBUSY, which is preforable to the fireworks which occur from trying to unwind
the old stack frame at a later point.

Signed-off-by: Andrew Cooper 
---
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 
CC: Juergen Gross 

This fix wants backporting, and is long overdue for posting upstream.

v1.5:
  * Send out a non-stale patch this time.
---
  xen/arch/arm/livepatch.c|  5 +
  xen/arch/x86/livepatch.c| 40 
  xen/common/livepatch.c  |  8 
  xen/include/xen/livepatch.h |  1 +
  4 files changed, 54 insertions(+)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 00c5e2bc45..915e9d926a 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -18,6 +18,11 @@
  
  void *vmap_of_xen_text;
  
+int arch_livepatch_safety_check(void)

+{
+return 0;
+}
+
  int arch_livepatch_quiesce(void)
  {
  mfn_t text_mfn;
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index c82cf53b9e..2749cbc5cf 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -10,10 +10,50 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
  
+static bool has_active_waitqueue(const struct vm_event_domain *ved)

+{
+/* ved may be xzalloc()'d without INIT_LIST_HEAD() yet. */
+return (ved && !list_head_is_null(&ved->wq.list) &&
+!list_empty(&ved->wq.list));
+}
+
+/*
+ * x86's implementation of waitqueue violates the livepatching safey principle
+ * of having unwound every CPUs stack before modifying live content.
+ *
+ * Search through every domain and check that no vCPUs have an active
+ * waitqueue.
+ */
+int arch_livepatch_safety_check(void)
+{
+struct domain *d;
+
+for_each_domain ( d )
+{
+#ifdef CONFIG_MEM_SHARING
+if ( has_active_waitqueue(d->vm_event_share) )
+goto fail;
+#endif
+#ifdef CONFIG_MEM_PAGING
+if ( has_active_waitqueue(d->vm_event_paging) )
+goto fail;
+#endif
+if ( has_active_waitqueue(d->vm_event_monitor) )
+goto fail;
+}
+
+return 0;
+
+ fail:
+printk(XENLOG_ERR LIVEPATCH "%pd found with active waitqueue\n", d);
+return -EBUSY;
+}
+
  int arch_livepatch_quiesce(void)
  {
  /* Disable WP to allow changes to read-only pages. */
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 962647616a..8386e611f2 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1060,6 +1060,14 @@ static int apply_payload(struct payload *data)
  unsigned int i;
  int rc;
  
+rc = arch_livepatch_safety_check();

+if ( rc )
+{
+printk(XENLOG_ERR LIVEPATCH "%s: Safety checks failed: %d\n",
+   data->name, rc);
+return rc;
+}
+


Would it make sense to call arch_livepatch_safety_check from
arch_livepatch_quiesce rather than directly, so that
arch_livepatch_safety_check is also called from revert_payload?

--Sarah


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

Re: [Xen-devel] Xen hiding thermal capabilities from Dom0

[Elliott Mitchell]

On Thu, Nov 21, 2019 at 04:46:21PM +0100, J??rgen Gro?? wrote:
> On 21.11.19 16:36, Jan Beulich wrote:
> > On 21.11.2019 15:24, J??rgen Gro?? wrote:
> >> So: no, just giving dom0 access to the management hardware isn't going
> >> to fly. You need to have a proper virtualization layer for that purpose.
> > 
> > Or, like I had done in our XenoLinux forward port, you need to
> > go through hoops to make the coretemp driver actually understand
> > the environment it's running in.
> 
> This will still not guarantee you'll be able to reach all physical
> cpus. IIRC you pinned the vcpu to the respective physical cpu for
> performing its duty, but with cpupools this might not be possible for
> all physical cpus in the system.

Similar to the issue of MCE support, might it instead be better to have
*less* virtualization here instead of more?  The original idea behind Xen
was to leave the hard to virtualize bits visible and work with Domain 0.

Might it be better to expose this functionality to Domain 0, then
intercept the kernel calls?  Just needs 1 vcpu which can be scheduled on
any processor and that can be moved around to retrieve the data.  This
way Xen wouldn't need a proper driver for the management hardware.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



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

Re: [Xen-devel] [PATCH v1.5] x86/livepatch: Prevent patching with active waitqueues

[Sarah Newman]

On 11/5/19 11:49 AM, Andrew Cooper wrote:

The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true.  The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different vcpu.

This case is rare, and can be worked around by pausing the offending
domain(s), waiting for their rings to drain, then performing a livepatch.

In the case that there is an active waitqueue, fail the livepatch attempt with
-EBUSY, which is preforable to the fireworks which occur from trying to unwind
the old stack frame at a later point.

Signed-off-by: Andrew Cooper 
---
CC: Konrad Rzeszutek Wilk 
CC: Ross Lagerwall 
CC: Juergen Gross 

This fix wants backporting, and is long overdue for posting upstream.

v1.5:
  * Send out a non-stale patch this time.
---
  xen/arch/arm/livepatch.c|  5 +
  xen/arch/x86/livepatch.c| 40 
  xen/common/livepatch.c  |  8 
  xen/include/xen/livepatch.h |  1 +
  4 files changed, 54 insertions(+)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 00c5e2bc45..915e9d926a 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -18,6 +18,11 @@
  
  void *vmap_of_xen_text;
  
+int arch_livepatch_safety_check(void)

+{
+return 0;
+}
+
  int arch_livepatch_quiesce(void)
  {
  mfn_t text_mfn;
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index c82cf53b9e..2749cbc5cf 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -10,10 +10,50 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
  
+static bool has_active_waitqueue(const struct vm_event_domain *ved)

+{
+/* ved may be xzalloc()'d without INIT_LIST_HEAD() yet. */
+return (ved && !list_head_is_null(&ved->wq.list) &&
+!list_empty(&ved->wq.list));
+}
+
+/*
+ * x86's implementation of waitqueue violates the livepatching safey principle
+ * of having unwound every CPUs stack before modifying live content.
+ *
+ * Search through every domain and check that no vCPUs have an active
+ * waitqueue.
+ */
+int arch_livepatch_safety_check(void)
+{
+struct domain *d;
+
+for_each_domain ( d )
+{
+#ifdef CONFIG_MEM_SHARING
+if ( has_active_waitqueue(d->vm_event_share) )
+goto fail;
+#endif
+#ifdef CONFIG_MEM_PAGING
+if ( has_active_waitqueue(d->vm_event_paging) )'


Is this supposed to be CONFIG_HAS_MEM_PAGING?

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

[Xen-devel] [xen-4.12-testing test] 144247: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow217 guest-localmigrate/x10   fail  like 144007
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail 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-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  0138da196c8c334589a25144d4d69bf6553e2658
baseline version:
 xen  278e46ae8f99485915ae662e7905c8333a55048a

Last test of basis   144035  2019-11-12 00:36:50 Z   11 days
Testing same since   144059  2019-11-12 19:10:11 Z   10 days   17 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 

jobs:
 build-amd64

Re: [Xen-devel] [PATCH v3 02/14] mm/mmu_notifier: add an interval tree notifier

[Ralph Campbell]

On 11/13/19 8:46 AM, Jason Gunthorpe wrote:

On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote:

+int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
+ struct mm_struct *mm, unsigned long start,
+ unsigned long length,
+ const struct mmu_interval_notifier_ops 
*ops);
+int mmu_interval_notifier_insert_locked(
+   struct mmu_interval_notifier *mni, struct mm_struct *mm,
+   unsigned long start, unsigned long length,
+   const struct mmu_interval_notifier_ops *ops);


Very inconsistent indentation between these two related functions.


clang-format.. The kernel config is set to prefer a line up under the
( if all the arguments will fit within the 80 cols otherwise it does a
1 tab continuation indent.


+   /*
+* The inv_end incorporates a deferred mechanism like
+* rtnl_unlock(). Adds and removes are queued until the final inv_end
+* happens then they are progressed. This arrangement for tree updates
+* is used to avoid using a blocking lock during
+* invalidate_range_start.


Nitpick:  That comment can be condensed into one less line:


The rtnl_unlock can move up a line too. My editor is failing me on
this.


+   /*
+* TODO: Since we already have a spinlock above, this would be faster
+* as wake_up_q
+*/
+   if (need_wake)
+   wake_up_all(&mmn_mm->wq);


So why is this important enough for a TODO comment, but not important
enough to do right away?


Lets drop the comment, I'm noto sure wake_up_q is even a function this
layer should be calling.


Actually, I think you can remove the "need_wake" variable since it is
unconditionally set to "true".

Also, the comment in__mmu_interval_notifier_insert() says
"mni->mr_invalidate_seq" and I think that should be
"mni->invalidate_seq".

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

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

[osstest service owner]

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

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  ca4cd3668237d50a0b33b48e7de7f93d9475120d
baseline version:
 xen  d7cd999faa1edf745a7597db811956cb882a5436

Last test of basis   144249  2019-11-22 17:01:00 Z0 days
Testing same since   144251  2019-11-22 21:01:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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-amd64pass
 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
   d7cd999faa..ca4cd36682  ca4cd3668237d50a0b33b48e7de7f93d9475120d -> smoke

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

[Xen-devel] [xen-4.11-testing test] 144246: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-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-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-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-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  74507046dbd2c5d2991eeabd1af39af0d6b29d70
baseline version:
 xen  006b2041242129896fbd30135b3dc6f575894a07

Last test of basis   144025  2019-11-11 17:36:00 Z   11 days
Testing same since   144058  2019-11-12 18:05:56 Z   10 days   17 attempts

Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms

[Andreas Kinzler]

On 22.11.2019 13:58, Andrew Cooper wrote:

On 22/11/2019 12:57, Jan Beulich wrote:

On 22.11.2019 13:50, Andrew Cooper wrote:

On 22/11/2019 12:46, Jan Beulich wrote:

Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says

"Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
  PC10, which in consequence marks TSC as unstable because HPET is used as
  watchdog clocksource for TSC."

Adjust a few types in touched or nearby code at the same time.

Reported-by ?

The Linux commit has a Suggested-by, but no Reported-by. Do you
want me to copy that one? Or else do you have any suggestion as
to who the reporter was?

Well - this patch was identified by someone on xen-devel, which I
presume was your basis for looking into it.


https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg00662.html

BTW: Xeon E-2136 @ C242 has 8086:3eca as ID. One needs to check with 
Intel which combinations are really affected.


Regards Andreas

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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 144042

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 144020
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144042
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144042
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144042
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144042
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144042
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144042
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-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-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  df7a19338a892b5cf585fd2bee8584cb15e0cace
baseline version:
 xen  a458d3bd0d2585275c128556ec0cbd818c6a7b0d

Last test of basis   144042  2019-11-12 09:07:51 Z   10 days
Failing since144067  2019-11-13 02:19:05 Z9 days   16 attempts
Testing same since 

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

[osstest service owner]

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

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  d7cd999faa1edf745a7597db811956cb882a5436
baseline version:
 xen  df7a19338a892b5cf585fd2bee8584cb15e0cace

Last test of basis   144237  2019-11-21 16:01:03 Z1 days
Testing same since   144249  2019-11-22 17:01:00 Z0 days1 attempts


People who touched revisions under test:
  Roger Pau Monné 

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-amd64pass
 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
   df7a19338a..d7cd999faa  d7cd999faa1edf745a7597db811956cb882a5436 -> smoke

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

Re: [Xen-devel] [PATCH v2 1/3] arm/arm64/xen: use C inlines for privcmd_call

[Stefano Stabellini]

On Thu, 21 Nov 2019, Pavel Tatashin wrote:
> privcmd_call requires to enable access to userspace for the
> duration of the hypercall.
> 
> Currently, this is done via assembly macros. Change it to C
> inlines instead.
> 
> Signed-off-by: Pavel Tatashin 

I am OK with this.

Acked-by: Stefano Stabellini 


> ---
>  arch/arm/include/asm/assembler.h   |  2 +-
>  arch/arm/include/asm/xen/hypercall.h   | 10 +
>  arch/arm/xen/enlighten.c   |  2 +-
>  arch/arm/xen/hypercall.S   |  4 ++--
>  arch/arm64/include/asm/xen/hypercall.h | 28 ++
>  arch/arm64/xen/hypercall.S | 19 ++---
>  include/xen/arm/hypercall.h| 12 +--
>  7 files changed, 50 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/arm/include/asm/assembler.h 
> b/arch/arm/include/asm/assembler.h
> index 99929122dad7..8e9262a0f016 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -480,7 +480,7 @@ THUMB(orr \reg , \reg , #PSR_T_BIT)
>   .macro  uaccess_disable, tmp, isb=1
>  #ifdef CONFIG_CPU_SW_DOMAIN_PAN
>   /*
> -  * Whenever we re-enter userspace, the domains should always be
> +  * Whenever we re-enter kernel, the domains should always be
>* set appropriately.
>*/
>   mov \tmp, #DACR_UACCESS_DISABLE
> diff --git a/arch/arm/include/asm/xen/hypercall.h 
> b/arch/arm/include/asm/xen/hypercall.h
> index 3522cbaed316..cac5bd9ef519 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -1 +1,11 @@
> +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> +#define _ASM_ARM_XEN_HYPERCALL_H
>  #include 
> +
> +static inline long privcmd_call(unsigned int call, unsigned long a1,
> + unsigned long a2, unsigned long a3,
> + unsigned long a4, unsigned long a5)
> +{
> + return arch_privcmd_call(call, a1, a2, a3, a4, a5);
> +}
> +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index dd6804a64f1a..e87280c6d25d 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -440,4 +440,4 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op_raw);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
>  EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
> -EXPORT_SYMBOL_GPL(privcmd_call);
> +EXPORT_SYMBOL_GPL(arch_privcmd_call);
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> index b11bba542fac..277078c7da49 100644
> --- a/arch/arm/xen/hypercall.S
> +++ b/arch/arm/xen/hypercall.S
> @@ -94,7 +94,7 @@ HYPERCALL2(multicall);
>  HYPERCALL2(vm_assist);
>  HYPERCALL3(dm_op);
>  
> -ENTRY(privcmd_call)
> +ENTRY(arch_privcmd_call)
>   stmdb sp!, {r4}
>   mov r12, r0
>   mov r0, r1
> @@ -119,4 +119,4 @@ ENTRY(privcmd_call)
>  
>   ldm sp!, {r4}
>   ret lr
> -ENDPROC(privcmd_call);
> +ENDPROC(arch_privcmd_call);
> diff --git a/arch/arm64/include/asm/xen/hypercall.h 
> b/arch/arm64/include/asm/xen/hypercall.h
> index 3522cbaed316..1a74fb28607f 100644
> --- a/arch/arm64/include/asm/xen/hypercall.h
> +++ b/arch/arm64/include/asm/xen/hypercall.h
> @@ -1 +1,29 @@
> +#ifndef _ASM_ARM64_XEN_HYPERCALL_H
> +#define _ASM_ARM64_XEN_HYPERCALL_H
>  #include 
> +#include 
> +
> +static inline long privcmd_call(unsigned int call, unsigned long a1,
> + unsigned long a2, unsigned long a3,
> + unsigned long a4, unsigned long a5)
> +{
> + long rv;
> +
> + /*
> +  * Privcmd calls are issued by the userspace. The kernel needs to
> +  * enable access to TTBR0_EL1 as the hypervisor would issue stage 1
> +  * translations to user memory via AT instructions. Since AT
> +  * instructions are not affected by the PAN bit (ARMv8.1), we only
> +  * need the explicit uaccess_enable/disable if the TTBR0 PAN emulation
> +  * is enabled (it implies that hardware UAO and PAN disabled).
> +  */
> + uaccess_ttbr0_enable();
> + rv = arch_privcmd_call(call, a1, a2, a3, a4, a5);
> + /*
> +  * Disable userspace access from kernel once the hyp call completed.
> +  */
> + uaccess_ttbr0_disable();
> +
> + return rv;
> +}
> +#endif /* _ASM_ARM64_XEN_HYPERCALL_H */
> diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S
> index c5f05c4a4d00..921611778d2a 100644
> --- a/arch/arm64/xen/hypercall.S
> +++ b/arch/arm64/xen/hypercall.S
> @@ -49,7 +49,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  
> @@ -86,27 +85,13 @@ HYPERCALL2(multicall);
>  HYPERCALL2(vm_assist);
>  HYPERCALL3(dm_op);
>  
> -ENTRY(privcmd_call)
> +ENTRY(arch_privcmd_call)
>   mov x16, x0
>   mov x0, x1
>   mov x1, x2
>   mov x2, x3
>   mov x3, x4
>   mov x4, x5
> - /*
> -  * Privcmd calls are issued by the userspace. The kernel needs to
> -  * enable access to TT

Re: [Xen-devel] [PATCH V2] arch: arm: vgic-v3: fix GICD_ISACTIVER range

[Stefano Stabellini]

On Fri, 22 Nov 2019, Peng Fan wrote:
> The end should be GICD_ISACTIVERN not GICD_ISACTIVER,
> and also print a warning for the unhandled read.
> 
> Signed-off-by: Peng Fan 
> ---
> 
> V2:
>  Add a warning message
> 
>  xen/arch/arm/vgic-v3.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 422b94f902..a15b9f6441 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -706,7 +706,10 @@ static int __vgic_v3_distr_common_mmio_read(const char 
> *name, struct vcpu *v,
>  goto read_as_zero;
>  
>  /* Read the active status of an IRQ via GICD/GICR is not supported */
> -case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVER):
> +case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
> +printk(XENLOG_G_ERR "%pv: vGICD: unhandled read from ISACTIVER%d\n",
> +   v, (reg - GICD_ISACTIVER) / 4);

All the other similar printks that we have in vgic-v3.c don't have the
"/ 4", for instance:

case VRANGE32(GICD_ISACTIVER, GICD_ISACTIVERN):
if ( dabt.size != DABT_WORD ) goto bad_width;
printk(XENLOG_G_ERR
   "%pv: %s: unhandled word write %#"PRIregister" to ISACTIVER%d\n",
   v, name, r, reg - GICD_ISACTIVER);

However, reg reflects the address of the register, so actually, the
division by 4 looks correct if we want to get the index of the specific
register. Thanks for spotting this. We'll need to do a clean-up in the
file later.

Reviewed-by: Stefano Stabellini 



> +goto read_as_zero;
>  case VRANGE32(GICD_ICACTIVER, GICD_ICACTIVERN):
>  goto read_as_zero;
>  
> -- 
> 2.16.4
> 

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

[Xen-devel] [PATCH] x86/mm: Adjust linear uses / entries when a page loses validation

[George Dunlap]

"Linear pagetables" is a technique which involves either pointing a
pagetable at itself, or to another pagetable the same or higher level.
Xen has limited support for linear pagetables: A page may either point
to itself, or point to another page of the same level (i.e., L2 to L2,
L3 to L3, and so on).

XSA-240 introduced an additional restriction that limited the "depth"
of such chains by allowing pages to either *point to* other pages of
the same level, or *be pointed to* by other pages of the same level,
but not both.  To implement this, we keep track of the number of
outstanding times a page points to or is pointed to another page
table, to prevent both from happening at the same time.

Additionally, XSA-299 introduced a mode whereby if a page was known to
have been only partially validated, _put_page_type() would be called
with PTF_partial_set, indicating that if the page had been
de-validated by someone else, the type count should be left alone.

Unfortunately, this change did not account for the required accounting
for linear page table uses and entries; in the case that a previously
partially-devalidated pagetable was fully-devalidated by someone else,
the linear_pt_counts are not updated.

This could happen in one of two places:

1. In the case a partially-devalidated page was re-validated by
someone else

2. During domain tear-down, when pages are force-invalidated while
leaving the type count intact.

The second could be ignored, since at that point the pages can no
longer be abused; but the first requires handling.  Note however that
this would not be a security issue: having the counts be too high is
overly strict (i.e., will prevent a page from being used in a way
which is perfectly safe), but shouldn't cause any other issues.

Fix this by adjusting the linear counts when a page loses validation,
regardless of whether the de-validation completed or was only partial.

Signed-off-by: George Dunlap 
Reviewed-by: Jan Beulich 
---
Release exception justification: This is a fix for a bug.

CC: Andrew Cooper 
CC: Jan Beulich 
CC: Juergen Gross 
---
 xen/arch/x86/mm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index bd8182f40f..7d4dd80a85 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2780,14 +2780,17 @@ static int _put_final_page_type(struct page_info *page, 
unsigned long type,
 {
 int rc = free_page_type(page, type, preemptible);
 
+if ( ptpg && PGT_type_equal(type, ptpg->u.inuse.type_info) &&
+ (type & PGT_validated) && rc != -EINTR )
+{
+/* Any time we begin de-validation of a page, adjust linear counts */
+dec_linear_uses(page);
+dec_linear_entries(ptpg);
+}
+
 /* No need for atomic update of type_info here: noone else updates it. */
 if ( rc == 0 )
 {
-if ( ptpg && PGT_type_equal(type, ptpg->u.inuse.type_info) )
-{
-dec_linear_uses(page);
-dec_linear_entries(ptpg);
-}
 ASSERT(!page->linear_pt_count || page_get_owner(page)->is_dying);
 set_tlbflush_timestamp(page);
 smp_wmb();
-- 
2.24.0


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

Re: [Xen-devel] [PATCH for-4.13] x86/vvmx: Fix livelock with XSA-304 fix

[Andrew Cooper]

On 22/11/2019 18:08, George Dunlap wrote:
> On Fri, Nov 22, 2019 at 5:55 PM Andrew Cooper  
> wrote:
>> It turns out that the XSA-304 / CVE-2018-12207 fix of disabling executable
>> superpages doesn't work well with the nested p2m code.
>>
>> Nested virt is experimental and not security supported, but is useful for
>> development purposes.  In order to not regress the status quo, disable the
>> XSA-304 workaround until the nested p2m code can be improved.
>>
>> Introduce a per-domain exec_sp control and set it based on the current
>> opt_ept_exec_sp setting.  Take the oppotunity to omit a PVH hardware domain
>> from the performance hit, because it is already permitted to DoS the system 
>> in
>> such ways as issuing a reboot.
>>
>> When nested virt is enabled on a domain, force it to using executable
>> superpages and rebuild the p2m.
>>
>> Having the setting per-domain involves rearranging the internals of
>> parse_ept_param_runtime() but it still retains the same overall semantics -
>> for each applicable domain whose setting needs to change, rebuild the p2m.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> CC: Juergen Gross 
>> ---
>>  xen/arch/x86/hvm/vmx/vmcs.c| 31 +++
>>  xen/arch/x86/hvm/vmx/vmx.c |  6 ++
>>  xen/arch/x86/hvm/vmx/vvmx.c| 13 +
>>  xen/arch/x86/mm/p2m-ept.c  |  2 +-
>>  xen/include/asm-x86/hvm/vmx/vmcs.h |  6 ++
>>  5 files changed, 49 insertions(+), 9 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>> index 477c968409..f10f6b78ec 100644
>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>> @@ -31,6 +31,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -97,6 +98,7 @@ custom_param("ept", parse_ept_param);
>>
>>  static int parse_ept_param_runtime(const char *s)
>>  {
>> +struct domain *d;
>>  int val;
>>
>>  if ( !cpu_has_vmx_ept || !hvm_funcs.hap_supported ||
>> @@ -110,18 +112,31 @@ static int parse_ept_param_runtime(const char *s)
>>  if ( (val = parse_boolean("exec-sp", s, NULL)) < 0 )
>>  return -EINVAL;
>>
>> -if ( val != opt_ept_exec_sp )
>> +opt_ept_exec_sp = val;
>> +
>> +rcu_read_lock(&domlist_read_lock);
>> +for_each_domain ( d )
>>  {
>> -struct domain *d;
>> +/* PV, or HVM Shadow domain?  Not applicable. */
>> +if ( !paging_mode_hap(d) )
>> +continue;
>>
>> -opt_ept_exec_sp = val;
>> +/* Hardware domain? Not applicable. */
>> +if ( is_hardware_domain(d) )
>> +continue;
>>
>> -rcu_read_lock(&domlist_read_lock);
>> -for_each_domain ( d )
>> -if ( paging_mode_hap(d) )
>> -p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_rw);
>> -rcu_read_unlock(&domlist_read_lock);
>> +/* Nested Virt?  Broken and exec_sp forced on to avoid livelocks. */
>> +if ( nestedhvm_enabled(d) )
>> +continue;
>> +
>> +/* Setting already matches?  No need to rebuild the p2m. */
>> +if ( d->arch.hvm.vmx.exec_sp == val )
>> +continue;
>> +
>> +d->arch.hvm.vmx.exec_sp = val;
>> +p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_rw);
>>  }
>> +rcu_read_unlock(&domlist_read_lock);
>>
>>  printk("VMX: EPT executable superpages %sabled\n",
>> val ? "en" : "dis");
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 6a5eeb5c13..a71df71bc1 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -404,6 +404,12 @@ static int vmx_domain_initialise(struct domain *d)
>>
>>  d->arch.ctxt_switch = &csw;
>>
>> +/*
>> + * Work around CVE-2018-12207?  The hardware domain is already permitted
>> + * to reboot the system, so doesn't need mitigating against DoS's.
>> + */
>> +d->arch.hvm.vmx.exec_sp = is_hardware_domain(d) || opt_ept_exec_sp;
>> +
>>  if ( !has_vlapic(d) )
>>  return 0;
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
>> index 6696bd6240..5dd00e11b5 100644
>> --- a/xen/arch/x86/hvm/vmx/vvmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
>> @@ -63,10 +63,23 @@ void nvmx_cpu_dead(unsigned int cpu)
>>
>>  int nvmx_vcpu_initialise(struct vcpu *v)
>>  {
>> +struct domain *d = v->domain;
>>  struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
>>  struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
>>  struct page_info *pg = alloc_domheap_page(NULL, 0);
>>
>> +/*
>> + * Gross bodge.  The nested p2m logic can't cope with the CVE-2018-12207
>> + * workaround of using NX EPT superpages, and livelocks.  Nested HVM 
>> isn't
>> + * security supported, so disable the workaround until the nested p2m
>> + * logic can be improved.
>> + */
>> +if ( !d->arch.hvm.vmx.e

Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce new backend type VINPUT

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce new backend 
type VINPUT"):
> On Fri, Nov 22, 2019 at 04:43:03PM +0100, Jürgen Groß wrote:
> > Release-acked-by: Juergen Gross 
> 
> I take it this applies to both patch 1 and 3?

In the absence of a reply to the contrary by 21:00 UTC today, I will
assume this to be the case and push this to staging.  I hope that
meets with everyone's approval.

Ian.

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

Re: [Xen-devel] [PATCH for-4.13] x86/vvmx: Fix livelock with XSA-304 fix

[George Dunlap]

On Fri, Nov 22, 2019 at 5:55 PM Andrew Cooper  wrote:
>
> It turns out that the XSA-304 / CVE-2018-12207 fix of disabling executable
> superpages doesn't work well with the nested p2m code.
>
> Nested virt is experimental and not security supported, but is useful for
> development purposes.  In order to not regress the status quo, disable the
> XSA-304 workaround until the nested p2m code can be improved.
>
> Introduce a per-domain exec_sp control and set it based on the current
> opt_ept_exec_sp setting.  Take the oppotunity to omit a PVH hardware domain
> from the performance hit, because it is already permitted to DoS the system in
> such ways as issuing a reboot.
>
> When nested virt is enabled on a domain, force it to using executable
> superpages and rebuild the p2m.
>
> Having the setting per-domain involves rearranging the internals of
> parse_ept_param_runtime() but it still retains the same overall semantics -
> for each applicable domain whose setting needs to change, rebuild the p2m.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Juergen Gross 
> ---
>  xen/arch/x86/hvm/vmx/vmcs.c| 31 +++
>  xen/arch/x86/hvm/vmx/vmx.c |  6 ++
>  xen/arch/x86/hvm/vmx/vvmx.c| 13 +
>  xen/arch/x86/mm/p2m-ept.c  |  2 +-
>  xen/include/asm-x86/hvm/vmx/vmcs.h |  6 ++
>  5 files changed, 49 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 477c968409..f10f6b78ec 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -97,6 +98,7 @@ custom_param("ept", parse_ept_param);
>
>  static int parse_ept_param_runtime(const char *s)
>  {
> +struct domain *d;
>  int val;
>
>  if ( !cpu_has_vmx_ept || !hvm_funcs.hap_supported ||
> @@ -110,18 +112,31 @@ static int parse_ept_param_runtime(const char *s)
>  if ( (val = parse_boolean("exec-sp", s, NULL)) < 0 )
>  return -EINVAL;
>
> -if ( val != opt_ept_exec_sp )
> +opt_ept_exec_sp = val;
> +
> +rcu_read_lock(&domlist_read_lock);
> +for_each_domain ( d )
>  {
> -struct domain *d;
> +/* PV, or HVM Shadow domain?  Not applicable. */
> +if ( !paging_mode_hap(d) )
> +continue;
>
> -opt_ept_exec_sp = val;
> +/* Hardware domain? Not applicable. */
> +if ( is_hardware_domain(d) )
> +continue;
>
> -rcu_read_lock(&domlist_read_lock);
> -for_each_domain ( d )
> -if ( paging_mode_hap(d) )
> -p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_rw);
> -rcu_read_unlock(&domlist_read_lock);
> +/* Nested Virt?  Broken and exec_sp forced on to avoid livelocks. */
> +if ( nestedhvm_enabled(d) )
> +continue;
> +
> +/* Setting already matches?  No need to rebuild the p2m. */
> +if ( d->arch.hvm.vmx.exec_sp == val )
> +continue;
> +
> +d->arch.hvm.vmx.exec_sp = val;
> +p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_rw);
>  }
> +rcu_read_unlock(&domlist_read_lock);
>
>  printk("VMX: EPT executable superpages %sabled\n",
> val ? "en" : "dis");
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 6a5eeb5c13..a71df71bc1 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -404,6 +404,12 @@ static int vmx_domain_initialise(struct domain *d)
>
>  d->arch.ctxt_switch = &csw;
>
> +/*
> + * Work around CVE-2018-12207?  The hardware domain is already permitted
> + * to reboot the system, so doesn't need mitigating against DoS's.
> + */
> +d->arch.hvm.vmx.exec_sp = is_hardware_domain(d) || opt_ept_exec_sp;
> +
>  if ( !has_vlapic(d) )
>  return 0;
>
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 6696bd6240..5dd00e11b5 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -63,10 +63,23 @@ void nvmx_cpu_dead(unsigned int cpu)
>
>  int nvmx_vcpu_initialise(struct vcpu *v)
>  {
> +struct domain *d = v->domain;
>  struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
>  struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
>  struct page_info *pg = alloc_domheap_page(NULL, 0);
>
> +/*
> + * Gross bodge.  The nested p2m logic can't cope with the CVE-2018-12207
> + * workaround of using NX EPT superpages, and livelocks.  Nested HVM 
> isn't
> + * security supported, so disable the workaround until the nested p2m
> + * logic can be improved.
> + */
> +if ( !d->arch.hvm.vmx.exec_sp )
> +{
> +d->arch.hvm.vmx.exec_sp = true;
> +p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_rw);

There wasn't an issue with nested guests having to

[Xen-devel] [PATCH for-4.13] x86/vvmx: Fix livelock with XSA-304 fix

[Andrew Cooper]

It turns out that the XSA-304 / CVE-2018-12207 fix of disabling executable
superpages doesn't work well with the nested p2m code.

Nested virt is experimental and not security supported, but is useful for
development purposes.  In order to not regress the status quo, disable the
XSA-304 workaround until the nested p2m code can be improved.

Introduce a per-domain exec_sp control and set it based on the current
opt_ept_exec_sp setting.  Take the oppotunity to omit a PVH hardware domain
from the performance hit, because it is already permitted to DoS the system in
such ways as issuing a reboot.

When nested virt is enabled on a domain, force it to using executable
superpages and rebuild the p2m.

Having the setting per-domain involves rearranging the internals of
parse_ept_param_runtime() but it still retains the same overall semantics -
for each applicable domain whose setting needs to change, rebuild the p2m.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 xen/arch/x86/hvm/vmx/vmcs.c| 31 +++
 xen/arch/x86/hvm/vmx/vmx.c |  6 ++
 xen/arch/x86/hvm/vmx/vvmx.c| 13 +
 xen/arch/x86/mm/p2m-ept.c  |  2 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h |  6 ++
 5 files changed, 49 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 477c968409..f10f6b78ec 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -97,6 +98,7 @@ custom_param("ept", parse_ept_param);
 
 static int parse_ept_param_runtime(const char *s)
 {
+struct domain *d;
 int val;
 
 if ( !cpu_has_vmx_ept || !hvm_funcs.hap_supported ||
@@ -110,18 +112,31 @@ static int parse_ept_param_runtime(const char *s)
 if ( (val = parse_boolean("exec-sp", s, NULL)) < 0 )
 return -EINVAL;
 
-if ( val != opt_ept_exec_sp )
+opt_ept_exec_sp = val;
+
+rcu_read_lock(&domlist_read_lock);
+for_each_domain ( d )
 {
-struct domain *d;
+/* PV, or HVM Shadow domain?  Not applicable. */
+if ( !paging_mode_hap(d) )
+continue;
 
-opt_ept_exec_sp = val;
+/* Hardware domain? Not applicable. */
+if ( is_hardware_domain(d) )
+continue;
 
-rcu_read_lock(&domlist_read_lock);
-for_each_domain ( d )
-if ( paging_mode_hap(d) )
-p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_rw);
-rcu_read_unlock(&domlist_read_lock);
+/* Nested Virt?  Broken and exec_sp forced on to avoid livelocks. */
+if ( nestedhvm_enabled(d) )
+continue;
+
+/* Setting already matches?  No need to rebuild the p2m. */
+if ( d->arch.hvm.vmx.exec_sp == val )
+continue;
+
+d->arch.hvm.vmx.exec_sp = val;
+p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_rw);
 }
+rcu_read_unlock(&domlist_read_lock);
 
 printk("VMX: EPT executable superpages %sabled\n",
val ? "en" : "dis");
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 6a5eeb5c13..a71df71bc1 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -404,6 +404,12 @@ static int vmx_domain_initialise(struct domain *d)
 
 d->arch.ctxt_switch = &csw;
 
+/*
+ * Work around CVE-2018-12207?  The hardware domain is already permitted
+ * to reboot the system, so doesn't need mitigating against DoS's.
+ */
+d->arch.hvm.vmx.exec_sp = is_hardware_domain(d) || opt_ept_exec_sp;
+
 if ( !has_vlapic(d) )
 return 0;
 
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 6696bd6240..5dd00e11b5 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -63,10 +63,23 @@ void nvmx_cpu_dead(unsigned int cpu)
 
 int nvmx_vcpu_initialise(struct vcpu *v)
 {
+struct domain *d = v->domain;
 struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
 struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
 struct page_info *pg = alloc_domheap_page(NULL, 0);
 
+/*
+ * Gross bodge.  The nested p2m logic can't cope with the CVE-2018-12207
+ * workaround of using NX EPT superpages, and livelocks.  Nested HVM isn't
+ * security supported, so disable the workaround until the nested p2m
+ * logic can be improved.
+ */
+if ( !d->arch.hvm.vmx.exec_sp )
+{
+d->arch.hvm.vmx.exec_sp = true;
+p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_rw);
+}
+
 if ( !pg )
 {
 gdprintk(XENLOG_ERR, "nest: allocation for shadow vmcs failed\n");
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index f06e51904a..b5517769c9 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -178,7 +178,7 @@ static void ept_p2m_type_to_flags(struct p2m_domain *

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 144236
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 144236

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail  like 144236
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144236
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144236
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144236
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144236
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144236
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 qemuu2061735ff09f9d5e67c501a96227b470e7de69b1
baseline version:
 qemuu7b5425318a27d0a41c1008a36c502719255b8f5e

Last test of basis   144236  2019-11-21 12:51:56 Z1 days
Testing same since   144243  2019-11-22 02:31:42 Z0 days1 attempts


People who touched revisions under test:
  Eduardo Habkost 
  Gerd Hoffmann 
  Paolo Bonzini 
  Peter Maydell 
  Sai Pavan Boddu 
  Volker Rümelin 
  yanminhui 

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

[Xen-devel] [PATCH v2 for 4.13] x86/microcode: refuse to load the same revision ucode

[Sergey Dyasli]

Currently if a user tries to live-load the same or older ucode revision
than CPU already has, he will get a single message in Xen log like:

(XEN) 128 cores are to update their microcode

No actual ucode loading will happen and this situation can be quite
confusing. Fix this by starting ucode update only when the provided
ucode revision is higher than the currently cached one (if any).
This is based on the property that if microcode_cache exists, all CPUs
in the system should have at least that ucode revision.

Additionally, print a user friendly message if no newer ucode can be
found in the provided blob. This also requires ignoring -ENODATA in
AMD-side code, otherwise the message given to the user is:

(XEN) Parsing microcode blob error -61

Which actually means that a ucode blob was parsed fine, but no matching
ucode was found.

Signed-off-by: Sergey Dyasli 
---
v1 --> v2:
- compare provided ucode with the currently cached one

CC: Jan Beulich 
CC: Andrew Cooper 
CC: Roger Pau Monné 
CC: Chao Gao 
CC: Juergen Gross 
---
 xen/arch/x86/microcode.c| 12 ++--
 xen/arch/x86/microcode_amd.c| 14 ++
 xen/arch/x86/microcode_intel.c  | 12 +---
 xen/include/asm-x86/microcode.h |  3 ++-
 4 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 65d1f41e7c..dcd2c3ff77 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -266,10 +266,16 @@ static const struct microcode_patch *nmi_patch = 
ZERO_BLOCK_PTR;
  */
 static struct microcode_patch *parse_blob(const char *buf, size_t len)
 {
+struct microcode_patch *ret = NULL;
+
 if ( likely(!microcode_ops->collect_cpu_info(&this_cpu(cpu_sig))) )
-return microcode_ops->cpu_request_microcode(buf, len);
+{
+spin_lock(µcode_mutex);
+ret = microcode_ops->cpu_request_microcode(buf, len, microcode_cache);
+spin_unlock(µcode_mutex);
+}
 
-return NULL;
+return ret;
 }
 
 void microcode_free_patch(struct microcode_patch *microcode_patch)
@@ -641,6 +647,8 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) 
buf, unsigned long len)
 if ( !patch )
 {
 ret = -ENOENT;
+printk(XENLOG_WARNING "microcode: couldn't find any newer revision in "
+  "the provided blob!\n");
 goto put;
 }
 
diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
index 1e52f7f49a..cf63aff009 100644
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -419,10 +419,11 @@ static bool_t check_final_patch_levels(unsigned int cpu)
 }
 
 static struct microcode_patch *cpu_request_microcode(const void *buf,
- size_t bufsize)
+size_t bufsize,
+const struct microcode_patch 
*cache)
 {
 struct microcode_amd *mc_amd;
-struct microcode_header_amd *saved = NULL;
+struct microcode_header_amd *saved = NULL, *cached = NULL;
 struct microcode_patch *patch = NULL;
 size_t offset = 0, saved_size = 0;
 int error = 0;
@@ -507,6 +508,9 @@ static struct microcode_patch *cpu_request_microcode(const 
void *buf,
 goto out;
 }
 
+if ( cache && cache->mc_amd && cache->mc_amd->mpb )
+cached = cache->mc_amd->mpb;
+
 /*
  * It's possible the data file has multiple matching ucode,
  * lets keep searching till the latest version
@@ -516,9 +520,11 @@ static struct microcode_patch *cpu_request_microcode(const 
void *buf,
 {
 /*
  * If the new ucode covers current CPU, compare ucodes and store the
- * one with higher revision.
+ * one with higher revision. It must also be higher than currently
+ * cached revision.
  */
 if ( (microcode_fits(mc_amd) != MIS_UCODE) &&
+ (!cached || (compare_header(mc_amd->mpb, cached) == NEW_UCODE)) &&
  (!saved || (compare_header(mc_amd->mpb, saved) == NEW_UCODE)) )
 {
 xfree(saved);
@@ -576,7 +582,7 @@ static struct microcode_patch *cpu_request_microcode(const 
void *buf,
 free_patch(mc_amd);
 
   out:
-if ( error && !patch )
+if ( error && error != -ENODATA && !patch )
 patch = ERR_PTR(error);
 
 return patch;
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index 9f66057aad..a82dd0e701 100644
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -357,13 +357,17 @@ static long get_next_ucode_from_buffer(struct 
microcode_intel **mc,
 }
 
 static struct microcode_patch *cpu_request_microcode(const void *buf,
- size_t size)
+size_t size,
+const struct microcode_patch 
*cache)
 {
 long offset = 0;
 int error =

Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce new backend type VINPUT

[Wei Liu]

On Fri, Nov 22, 2019 at 04:43:03PM +0100, Jürgen Groß wrote:
> On 22.11.19 16:18, Anthony PERARD wrote:
> > On Thu, Nov 21, 2019 at 08:12:58PM +0200, Oleksandr Grytsov wrote:
> > > From: Oleksandr Grytsov 
> > > 
> > > There are two kind of VKBD devices: with QEMU backend and user space PV
> > > backend. In current implementation they can't be distinguished as both use
> > > VKBD backend type. As result, user space PV KBD backend is started and
> > > stopped as QEMU backend. This commit adds new device kind VINPUT to be
> > > used as backend type for user space PV KBD backend.
> > > 
> > > Signed-off-by: Oleksandr Grytsov 
> > > Acked-by: Ian Jackson 
> > 
> > That patch removes the "backend-type" node from xenstore but it wasn't
> > part of the api (kbdif.h) and qemu doesn't read, it so I guess that's
> > fine:
> > 
> > Acked-by: Anthony PERARD 
> 
> Release-acked-by: Juergen Gross 

I take it this applies to both patch 1 and 3?

Wei.

> 
> 
> Juergen

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

[Xen-devel] [libvirt test] 144244: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 
144233

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

version targeted for testing:
 libvirt  d6064e2759a24e0802f363e3a810dc5a7d7ebb15
baseline version:
 libvirt  5e939cea896fb3373a6f68f86e325c657429ed3d

Last test of basis   144233  2019-11-21 04:18:53 Z1 days
Testing same since   144244  2019-11-22 04:18:48 Z0 days1 attempts


People who touched revisions under test:
  Christian Ehrhardt 
  Erik Skultety 
  Jamie Strandboge 
  Ján Tomko 

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



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

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

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

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


Not pushing.


commit d6064e2759a24e0802f363e3a810dc5a7d7ebb15
Author: Erik Skultety 
Date:   

Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce new backend type VINPUT

[Jürgen Groß]

On 22.11.19 16:18, Anthony PERARD wrote:

On Thu, Nov 21, 2019 at 08:12:58PM +0200, Oleksandr Grytsov wrote:

From: Oleksandr Grytsov 

There are two kind of VKBD devices: with QEMU backend and user space PV
backend. In current implementation they can't be distinguished as both use
VKBD backend type. As result, user space PV KBD backend is started and
stopped as QEMU backend. This commit adds new device kind VINPUT to be
used as backend type for user space PV KBD backend.

Signed-off-by: Oleksandr Grytsov 
Acked-by: Ian Jackson 


That patch removes the "backend-type" node from xenstore but it wasn't
part of the api (kbdif.h) and qemu doesn't read, it so I guess that's
fine:

Acked-by: Anthony PERARD 


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 v2 1/3] libxl: introduce new backend type VINPUT

[Anthony PERARD]

On Thu, Nov 21, 2019 at 08:12:58PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> There are two kind of VKBD devices: with QEMU backend and user space PV
> backend. In current implementation they can't be distinguished as both use
> VKBD backend type. As result, user space PV KBD backend is started and
> stopped as QEMU backend. This commit adds new device kind VINPUT to be
> used as backend type for user space PV KBD backend.
> 
> Signed-off-by: Oleksandr Grytsov 
> Acked-by: Ian Jackson 

That patch removes the "backend-type" node from xenstore but it wasn't
part of the api (kbdif.h) and qemu doesn't read, it so I guess that's
fine:

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

[Andrew Cooper]

On 22/11/2019 14:31, Jan Beulich wrote:
> On 22.11.2019 14:55, Andrew Cooper wrote:
>> On 22/11/2019 13:31, Jan Beulich wrote:
>>> On 21.11.2019 23:15, Andrew Cooper wrote:
 +/* Fallthrough */
 +case 0x62: /* bound */
>>> Does "bound" really belong on this list? It raising #BR is like
>>> insns raising random other exceptions, not like INTO / INT3,
>>> where the IDT descriptor also has to have suitable DPL for the
>>> exception to actually get delivered (rather than #GP). I.e. it
>>> shouldn't make it here in the first place, due to the
>>> X86_EVENTTYPE_HW_EXCEPTION check in the caller.
>>>
>>> IOW if "bound" needs to be here, then all others need to be as
>>> well, unless they can't cause any exception at all.
>> More experimentation required.  BOUND doesn't appear to be special cased
>> by SVM, but is by VT-x.  VT-x however does throw it in the same category
>> as #UD, and identify it to be a hardware exception.
>>
>> I suspect you are right, and t doesn't want to be here.
>>
 +case 0x9a: /* call (far, absolute) */
 +case 0xca: /* ret imm16 (far) */
 +case 0xcb: /* ret (far) */
 +case 0xcc: /* int3 */
 +case 0xcd: /* int imm8 */
 +case 0xce: /* into */
 +case 0xcf: /* iret */
 +case 0xea: /* jmp (far, absolute) */
 +case 0xf1: /* icebp */
>>> Same perhaps for ICEBP, albeit I'm less certain here, as its
>>> behavior is too poorly documented (if at all).
>> ICEBP's #DB is a trap, not a fault, so instruction length is important.
> Hmm, this may point at a bigger issue then: Single step and data
> breakpoints are traps, too. But of course they can occur with
> arbitrary insns. Do their intercepts occur with guest RIP already
> updated?

Based on other behaviour, I'm going to guess yes on SVM and no on VT-x.

We'll take the #DB intercept, re-inject, and should see a vectoring task
switch.  The type should match the re-inject, so will be SW_INT/EXC with
a length on VT-x, and be HW_EXCEPTION with no length on SVM.

Either way, I think the logic presented here will work correctly.

> (They wouldn't currently make it here anyway because of
> the X86_EVENTTYPE_HW_EXCEPTION check in the caller.) If they do,
> are you sure ICEBP-#DB's doesn't?

ICEBP itself doesn't get intercepted.  Only the resulting #DB does,
which will will trigger a #DB-vectoring task switch, irrespective of its
exact origin.

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] x86/vtx: Fix fault semantics for early task switch failures

[Andrew Cooper]

On 22/11/2019 13:39, Jan Beulich wrote:
> On 22.11.2019 14:12, Andrew Cooper wrote:
>> On 22/11/2019 13:08, Jan Beulich wrote:
>>> On 22.11.2019 13:37, Roger Pau Monné  wrote:
 On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
> The VT-x task switch handler adds inst_len to rip before calling
> hvm_task_switch().  This causes early faults to be delivered to the guest 
> with
> trap semantics, and break restartibility.
>
> Instead, pass the instruction length into hvm_task_switch() and write it 
> into
> the outgoing tss only, leaving rip in its original location.
>
> For now, pass 0 on the SVM side.  This highlights a separate preexisting 
> bug
> which will be addressed in the following patch.
>
> While adjusting call sites, drop the unnecessary uint16_t cast.
>
> Signed-off-by: Andrew Cooper 
 Code LGTM:

 Reviewed-by: Roger Pau Monné 
>>> Acked-by: Jan Beulich 
>> It occurs to me that this also fixes a vmentry failure in the corner
>> case that an instruction, which crosses the 4G=>0 boundary takes a
>> fault.  %rip will be adjusted without being truncated.
> I was about to say so in my earlier reply, until I paid attention
> to this
>
> @@ -2987,7 +2987,7 @@ void hvm_task_switch(
>  if ( taskswitch_reason == TSW_iret )
>  eflags &= ~X86_EFLAGS_NT;
>  
> -tss.eip= regs->eip;
> +tss.eip= regs->eip + insn_len;
>
> together with the subsequent
>
> regs->rip= tss.eip;
>
> already having taken care of this aspect before, afaict.

This takes care of things for a task switch which completes
successfully, but not for one which faulted (and ended up delivering
with trap semantics).  In that case, the (now deleted) regs->rip +=
inst_len; would end up un-truncated.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

[Andrew Cooper]

On 22/11/2019 13:59, Roger Pau Monné wrote:
> On Thu, Nov 21, 2019 at 10:15:51PM +, Andrew Cooper wrote:
>> The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs
>> assistance with instruction length.  As a result, any instruction-induced 
>> task
>> switch has the outgoing task's %eip pointing at the instruction switch caused
>   ^ that
>> the switch, rather than after it.
>>
>> This causes explicit use of task gates to livelock (as when the task returns,
>> it executes the task-switching instruction again), and any restartable task 
>> to
>> become a nop after its first instantiation (the entry state points at the
>> ret/iret instruction used to exit the task).
>>
>> 32bit Windows in particular is known to use task gates for NMI handling, and
>> to use NMI IPIs.
>>
>> In the task switch handler, distinguish instruction-induced from
>> interrupt/exception-induced task switches, and decode the instruction under
>> %rip to calculate its length.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> CC: Juergen Gross 
>>
>> The implementation of svm_get_task_switch_insn_len() is bug-compatible with
>> svm_get_insn_len() when it comes to conditional #GP'ing.  I still haven't had
>> time to address this more thoroughly.
>>
>> AMD does permit TASK_SWITCH not to be intercepted and, I'm informed does do
>> the right thing when it comes to a TSS crossing a page boundary.  However, it
>> is not actually safe to leave task switches unintercepted.  Any NPT or shadow
>> page fault, even from logdirty/paging/etc will corrupt guest state in an
>> unrecoverable manner.
>> ---
>>  xen/arch/x86/hvm/svm/emulate.c| 55 
>> +++
>>  xen/arch/x86/hvm/svm/svm.c| 46 ++---
>>  xen/include/asm-x86/hvm/svm/emulate.h |  1 +
>>  3 files changed, 92 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/svm/emulate.c b/xen/arch/x86/hvm/svm/emulate.c
>> index 3e52592847..176c25f60d 100644
>> --- a/xen/arch/x86/hvm/svm/emulate.c
>> +++ b/xen/arch/x86/hvm/svm/emulate.c
>> @@ -117,6 +117,61 @@ unsigned int svm_get_insn_len(struct vcpu *v, unsigned 
>> int instr_enc)
>>  }
>>  
>>  /*
>> + * TASK_SWITCH vmexits never provide an instruction length.  We must always
>> + * decode under %rip to find the answer.
>> + */
>> +unsigned int svm_get_task_switch_insn_len(struct vcpu *v)
>> +{
>> +struct hvm_emulate_ctxt ctxt;
>> +struct x86_emulate_state *state;
>> +unsigned int emul_len, modrm_reg;
>> +
>> +ASSERT(v == current);
>> +hvm_emulate_init_once(&ctxt, NULL, guest_cpu_user_regs());
>> +hvm_emulate_init_per_insn(&ctxt, NULL, 0);
>> +state = x86_decode_insn(&ctxt.ctxt, hvmemul_insn_fetch);
>> +if ( IS_ERR_OR_NULL(state) )
> Maybe crash the guest in this case? Not advancing the instruction
> pointer in a software induced task switch will create a loop AFAICT?

Your analysis is correct, but crashing the guest would be a user=>kernel
DoS, which is worse than a livelock.

We do have some logic to try and cope with this in svm.c, and I think
I've got a better idea of how to make use of it.

>
>> +return 0;
>> +
>> +emul_len = x86_insn_length(state, &ctxt.ctxt);
>> +
>> +/*
>> + * Check for an instruction which can cause a task switch.  Any far
>> + * jmp/call/ret, any software interrupt/exception, and iret.
>> + */
>> +switch ( ctxt.ctxt.opcode )
>> +{
>> +case 0xff: /* Grp 5 */
>> +/* call / jmp (far, absolute indirect) */
>> +if ( x86_insn_modrm(state, NULL, &modrm_reg) != 3 ||
>> + (modrm_reg != 3 && modrm_reg != 5) )
>> +{
>> +/* Wrong instruction.  Throw #GP back for now. */
>> +default:
>> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
>> +emul_len = 0;
>> +break;
>> +}
>> +/* Fallthrough */
>> +case 0x62: /* bound */
>> +case 0x9a: /* call (far, absolute) */
> I'm slightly loss here, in the case of call or jmp for example, don't
> you need the instruction pointer to point to the destination of the
> call/jmp instead of the next instruction?

No, but that is by design.

Far calls provide a selector:offset pair (either imm or mem operands),
rather than a displacement within the same code segment.

Selector may be new code selector, at which point offset is important,
and execution continues at %cs:%rip.  This case isn't interesting for
us, and doesn't vmexit in the first place.

When Selector is a Task State Segment, or Task Gate selector, a task
switch occurs (subject to cpl checks, etc).

In this case, the entrypoint of the new task is stashed in the new tasks
TSS (cs and eip fields).  The offset from the original call/jmp
instruction is discarded as it isn't relevant.   (After all,
particularly on a privilege level transition task switch, yo

Re: [Xen-devel] [PATCH v2 2/3] libxl: rename VKB backend type "linux" to "pv"

[Ian Jackson]

Wei Liu writes ("Re: [PATCH v2 2/3] libxl: rename VKB backend type "linux" to 
"pv""):
> The LINUX type was introduced back in 2018.

Oh.  Yes.  I used a wrong git-describe rune to try to find out where
it had been introduced.  The answer in fact is that it was in
4.12.0-rc1.  Thanks for pointing this out.

Thanks also for the 2nd pair of eyes on
 [PATCH v2 3/3] libxl: make default path to add/remove all PV devices

> This patch should have provided at least a
>   #define ...LINUX ...PV
> in libxl.h for backward compatibility purpose.

Under the circumstances, given that I suggested the rename during the
4.13 freeze, and the (IMO wrong) name was shipped in 4.12, it seems
that we should drop this patch for 4.13.  This is something that
perhaps we should think about for the future but if it's been released
already the cost of messing about with the name is sharply larger, and
it may not be worth it at all.  Sorry for messing you about more,
Oleksandr.

The other two patches 1/ and 3/ apply and work just fine without this
middle one, so I don't think we need a resend.

I'm still hoping for a 2nd pair of eyes on
 [PATCH v2 1/3] libxl: introduce new backend type VINPUT

and a release ack for both 1/3 and 3/3.

Ian.

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

Re: [Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

[Jan Beulich]

On 22.11.2019 14:55, Andrew Cooper wrote:
> On 22/11/2019 13:31, Jan Beulich wrote:
>> On 21.11.2019 23:15, Andrew Cooper wrote:
>>> +/* Fallthrough */
>>> +case 0x62: /* bound */
>> Does "bound" really belong on this list? It raising #BR is like
>> insns raising random other exceptions, not like INTO / INT3,
>> where the IDT descriptor also has to have suitable DPL for the
>> exception to actually get delivered (rather than #GP). I.e. it
>> shouldn't make it here in the first place, due to the
>> X86_EVENTTYPE_HW_EXCEPTION check in the caller.
>>
>> IOW if "bound" needs to be here, then all others need to be as
>> well, unless they can't cause any exception at all.
> 
> More experimentation required.  BOUND doesn't appear to be special cased
> by SVM, but is by VT-x.  VT-x however does throw it in the same category
> as #UD, and identify it to be a hardware exception.
> 
> I suspect you are right, and t doesn't want to be here.
> 
>>> +case 0x9a: /* call (far, absolute) */
>>> +case 0xca: /* ret imm16 (far) */
>>> +case 0xcb: /* ret (far) */
>>> +case 0xcc: /* int3 */
>>> +case 0xcd: /* int imm8 */
>>> +case 0xce: /* into */
>>> +case 0xcf: /* iret */
>>> +case 0xea: /* jmp (far, absolute) */
>>> +case 0xf1: /* icebp */
>> Same perhaps for ICEBP, albeit I'm less certain here, as its
>> behavior is too poorly documented (if at all).
> 
> ICEBP's #DB is a trap, not a fault, so instruction length is important.

Hmm, this may point at a bigger issue then: Single step and data
breakpoints are traps, too. But of course they can occur with
arbitrary insns. Do their intercepts occur with guest RIP already
updated? (They wouldn't currently make it here anyway because of
the X86_EVENTTYPE_HW_EXCEPTION check in the caller.) If they do,
are you sure ICEBP-#DB's doesn't?

Jan

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

Re: [Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

[Roger Pau Monné]

On Thu, Nov 21, 2019 at 10:15:51PM +, Andrew Cooper wrote:
> The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs
> assistance with instruction length.  As a result, any instruction-induced task
> switch has the outgoing task's %eip pointing at the instruction switch caused
  ^ that
> the switch, rather than after it.
> 
> This causes explicit use of task gates to livelock (as when the task returns,
> it executes the task-switching instruction again), and any restartable task to
> become a nop after its first instantiation (the entry state points at the
> ret/iret instruction used to exit the task).
> 
> 32bit Windows in particular is known to use task gates for NMI handling, and
> to use NMI IPIs.
> 
> In the task switch handler, distinguish instruction-induced from
> interrupt/exception-induced task switches, and decode the instruction under
> %rip to calculate its length.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Juergen Gross 
> 
> The implementation of svm_get_task_switch_insn_len() is bug-compatible with
> svm_get_insn_len() when it comes to conditional #GP'ing.  I still haven't had
> time to address this more thoroughly.
> 
> AMD does permit TASK_SWITCH not to be intercepted and, I'm informed does do
> the right thing when it comes to a TSS crossing a page boundary.  However, it
> is not actually safe to leave task switches unintercepted.  Any NPT or shadow
> page fault, even from logdirty/paging/etc will corrupt guest state in an
> unrecoverable manner.
> ---
>  xen/arch/x86/hvm/svm/emulate.c| 55 
> +++
>  xen/arch/x86/hvm/svm/svm.c| 46 ++---
>  xen/include/asm-x86/hvm/svm/emulate.h |  1 +
>  3 files changed, 92 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/svm/emulate.c b/xen/arch/x86/hvm/svm/emulate.c
> index 3e52592847..176c25f60d 100644
> --- a/xen/arch/x86/hvm/svm/emulate.c
> +++ b/xen/arch/x86/hvm/svm/emulate.c
> @@ -117,6 +117,61 @@ unsigned int svm_get_insn_len(struct vcpu *v, unsigned 
> int instr_enc)
>  }
>  
>  /*
> + * TASK_SWITCH vmexits never provide an instruction length.  We must always
> + * decode under %rip to find the answer.
> + */
> +unsigned int svm_get_task_switch_insn_len(struct vcpu *v)
> +{
> +struct hvm_emulate_ctxt ctxt;
> +struct x86_emulate_state *state;
> +unsigned int emul_len, modrm_reg;
> +
> +ASSERT(v == current);
> +hvm_emulate_init_once(&ctxt, NULL, guest_cpu_user_regs());
> +hvm_emulate_init_per_insn(&ctxt, NULL, 0);
> +state = x86_decode_insn(&ctxt.ctxt, hvmemul_insn_fetch);
> +if ( IS_ERR_OR_NULL(state) )

Maybe crash the guest in this case? Not advancing the instruction
pointer in a software induced task switch will create a loop AFAICT?

> +return 0;
> +
> +emul_len = x86_insn_length(state, &ctxt.ctxt);
> +
> +/*
> + * Check for an instruction which can cause a task switch.  Any far
> + * jmp/call/ret, any software interrupt/exception, and iret.
> + */
> +switch ( ctxt.ctxt.opcode )
> +{
> +case 0xff: /* Grp 5 */
> +/* call / jmp (far, absolute indirect) */
> +if ( x86_insn_modrm(state, NULL, &modrm_reg) != 3 ||
> + (modrm_reg != 3 && modrm_reg != 5) )
> +{
> +/* Wrong instruction.  Throw #GP back for now. */
> +default:
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +emul_len = 0;
> +break;
> +}
> +/* Fallthrough */
> +case 0x62: /* bound */
> +case 0x9a: /* call (far, absolute) */

I'm slightly loss here, in the case of call or jmp for example, don't
you need the instruction pointer to point to the destination of the
call/jmp instead of the next instruction?

> +case 0xca: /* ret imm16 (far) */
> +case 0xcb: /* ret (far) */
> +case 0xcc: /* int3 */
> +case 0xcd: /* int imm8 */
> +case 0xce: /* into */
> +case 0xcf: /* iret */
> +case 0xea: /* jmp (far, absolute) */
> +case 0xf1: /* icebp */
> +break;
> +}
> +
> +x86_emulate_free_state(state);
> +
> +return emul_len;
> +}
> +
> +/*
>   * Local variables:
>   * mode: C
>   * c-file-style: "BSD"
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 049b800e20..ba9c24a70c 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2776,7 +2776,41 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  
>  case VMEXIT_TASK_SWITCH: {
>  enum hvm_task_switch_reason reason;
> -int32_t errcode = -1;
> +int32_t errcode = -1, insn_len = -1;

Plain int seem better for insn_len?

Also I'm not sure there's a reason that errcode uses int32_t, but
that's not introduced here anyway.

Thanks, Roger.

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

[Andrew Cooper]

On 22/11/2019 13:31, Jan Beulich wrote:
> On 21.11.2019 23:15, Andrew Cooper wrote:
>> --- a/xen/arch/x86/hvm/svm/emulate.c
>> +++ b/xen/arch/x86/hvm/svm/emulate.c
>> @@ -117,6 +117,61 @@ unsigned int svm_get_insn_len(struct vcpu *v, unsigned 
>> int instr_enc)
>>  }
>>  
>>  /*
>> + * TASK_SWITCH vmexits never provide an instruction length.  We must always
>> + * decode under %rip to find the answer.
>> + */
>> +unsigned int svm_get_task_switch_insn_len(struct vcpu *v)
>> +{
>> +struct hvm_emulate_ctxt ctxt;
>> +struct x86_emulate_state *state;
>> +unsigned int emul_len, modrm_reg;
>> +
>> +ASSERT(v == current);
> You look to be using v here just for this ASSERT() - is this really
> worth it? By making the function take "void" it would be quite obvious
> that it would act on the current vCPU only.

This was cribbed largely from svm_get_insn_len(), which also behaves the
same.

>
>> +hvm_emulate_init_once(&ctxt, NULL, guest_cpu_user_regs());
>> +hvm_emulate_init_per_insn(&ctxt, NULL, 0);
>> +state = x86_decode_insn(&ctxt.ctxt, hvmemul_insn_fetch);
>> +if ( IS_ERR_OR_NULL(state) )
>> +return 0;
>> +
>> +emul_len = x86_insn_length(state, &ctxt.ctxt);
>> +
>> +/*
>> + * Check for an instruction which can cause a task switch.  Any far
>> + * jmp/call/ret, any software interrupt/exception, and iret.
>> + */
>> +switch ( ctxt.ctxt.opcode )
>> +{
>> +case 0xff: /* Grp 5 */
>> +/* call / jmp (far, absolute indirect) */
>> +if ( x86_insn_modrm(state, NULL, &modrm_reg) != 3 ||
> DYM "== 3", to bail upon non-memory operands?

Ah yes (and this demonstrates that I really need to get an XTF tested
sorted soon.)

>
>> + (modrm_reg != 3 && modrm_reg != 5) )
>> +{
>> +/* Wrong instruction.  Throw #GP back for now. */
>> +default:
>> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
>> +emul_len = 0;
>> +break;
>> +}
>> +/* Fallthrough */
>> +case 0x62: /* bound */
> Does "bound" really belong on this list? It raising #BR is like
> insns raising random other exceptions, not like INTO / INT3,
> where the IDT descriptor also has to have suitable DPL for the
> exception to actually get delivered (rather than #GP). I.e. it
> shouldn't make it here in the first place, due to the
> X86_EVENTTYPE_HW_EXCEPTION check in the caller.
>
> IOW if "bound" needs to be here, then all others need to be as
> well, unless they can't cause any exception at all.

More experimentation required.  BOUND doesn't appear to be special cased
by SVM, but is by VT-x.  VT-x however does throw it in the same category
as #UD, and identify it to be a hardware exception.

I suspect you are right, and t doesn't want to be here.

>> +case 0x9a: /* call (far, absolute) */
>> +case 0xca: /* ret imm16 (far) */
>> +case 0xcb: /* ret (far) */
>> +case 0xcc: /* int3 */
>> +case 0xcd: /* int imm8 */
>> +case 0xce: /* into */
>> +case 0xcf: /* iret */
>> +case 0xea: /* jmp (far, absolute) */
>> +case 0xf1: /* icebp */
> Same perhaps for ICEBP, albeit I'm less certain here, as its
> behavior is too poorly documented (if at all).

ICEBP's #DB is a trap, not a fault, so instruction length is important.

>
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -2776,7 +2776,41 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>>  
>>  case VMEXIT_TASK_SWITCH: {
>>  enum hvm_task_switch_reason reason;
>> -int32_t errcode = -1;
>> +int32_t errcode = -1, insn_len = -1;
>> +
>> +/*
>> + * All TASK_SWITCH intercepts have fault-like semantics.  NRIP is
>> + * never provided, even for instruction-induced task switches, but 
>> we
>> + * need to know the instruction length in order to set %eip suitably
>> + * in the outgoing TSS.
>> + *
>> + * For a task switch which vectored through the IDT, look at the 
>> type
>> + * to distinguish interrupts/exceptions from instruction based
>> + * switches.
>> + */
>> +if ( vmcb->eventinj.fields.v )
>> +{
>> +/*
>> + * HW_EXCEPTION, NMI and EXT_INTR are not instruction based.  
>> All
>> + * others are.
>> + */
>> +if ( vmcb->eventinj.fields.type <= X86_EVENTTYPE_HW_EXCEPTION )
>> +insn_len = 0;
>> +
>> +/*
>> + * Clobber the vectoring information, as we are going to emulate
>> + * the task switch in full.
>> + */
>> +vmcb->eventinj.bytes = 0;
>> +}
>> +
>> +/*
>> + * insn_len being -1 indicates that we have an instruction-induced
>> + * task switch.  Decode under %rip to find its length.
>> + */
>> +if ( insn_len < 0 && (insn_len = svm_get_task_switch_insn_len(v)) 
>> == 0 )
>> +break;
> Won't

Re: [Xen-devel] [PATCH v3 6/9] x86/mm: add an end_of_loop label in map_pages_to_xen

[Jan Beulich]

On 02.10.2019 19:16, Hongyan Xia wrote:
> We will soon need to clean up mappings whenever the out most loop is
> ended. Add a new label and turn relevant continue's into goto's.

I think already when this still was RFC I did indicate that I'm not
happy about the introduction of these labels (including also patch 8).
I realize it's quite a lot to ask, but both functions would benefit
from splitting up into per-level helper functions, which - afaict -
would avoid the need for such labels, and which would at the same
time likely make it quite a bit easier to extend these to the
5-level page tables case down the road.

Thoughts?

Jan

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

[Xen-devel] [xen-4.12-testing test] 144241: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   7 xen-boot   fail pass in 144235

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 144235 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 144235 never 
pass
 test-amd64-amd64-xl-qcow217 guest-localmigrate/x10   fail  like 144007
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail 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-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  0138da196c8c334589a25144d4d69bf6553e2658
baseline version:
 xen  278e46ae8f99485915ae662e7905c8333a55048a

Last test of basis   144035  2019-11-12 00:36:50 Z   10 days
Testing same since   144059  2019-11-12 19:10:11 Z9 days   16 attempts

--

Re: [Xen-devel] [PATCH 1/2] x86/vtx: Fix fault semantics for early task switch failures

[Jan Beulich]

On 22.11.2019 14:12, Andrew Cooper wrote:
> On 22/11/2019 13:08, Jan Beulich wrote:
>> On 22.11.2019 13:37, Roger Pau Monné  wrote:
>>> On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
 The VT-x task switch handler adds inst_len to rip before calling
 hvm_task_switch().  This causes early faults to be delivered to the guest 
 with
 trap semantics, and break restartibility.

 Instead, pass the instruction length into hvm_task_switch() and write it 
 into
 the outgoing tss only, leaving rip in its original location.

 For now, pass 0 on the SVM side.  This highlights a separate preexisting 
 bug
 which will be addressed in the following patch.

 While adjusting call sites, drop the unnecessary uint16_t cast.

 Signed-off-by: Andrew Cooper 
>>> Code LGTM:
>>>
>>> Reviewed-by: Roger Pau Monné 
>> Acked-by: Jan Beulich 
> 
> It occurs to me that this also fixes a vmentry failure in the corner
> case that an instruction, which crosses the 4G=>0 boundary takes a
> fault.  %rip will be adjusted without being truncated.

I was about to say so in my earlier reply, until I paid attention
to this

@@ -2987,7 +2987,7 @@ void hvm_task_switch(
 if ( taskswitch_reason == TSW_iret )
 eflags &= ~X86_EFLAGS_NT;
 
-tss.eip= regs->eip;
+tss.eip= regs->eip + insn_len;

together with the subsequent

regs->rip= tss.eip;

already having taken care of this aspect before, afaict.

Jan

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

Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms

[Jan Beulich]

On 22.11.2019 13:58, Andrew Cooper wrote:
> On 22/11/2019 12:57, Jan Beulich wrote:
>> On 22.11.2019 13:50, Andrew Cooper wrote:
>>> On 22/11/2019 12:46, Jan Beulich wrote:
 Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says

 "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
  PC10, which in consequence marks TSC as unstable because HPET is used as
  watchdog clocksource for TSC."

 Follow this for Xen as well. Looking at its patch context made me notice
 they have a pre-existing quirk for Bay Trail as well. The comment there,
 however, points at a Cherry Trail document. Looking at the datasheets of
 both, there appear to be similar issues, so go beyond Linux'es coverage
 and exclude both. Also key the disable on the PCI IDs of the actual
 affected devices, rather than those of 00:00.0.

 Apply the workarounds only when the use of HPET was not explicitly
 requested on the command line and when use of (deep) C-states was not
 disabled.

 Adjust a few types in touched or nearby code at the same time.
>>> Reported-by ?
>> The Linux commit has a Suggested-by, but no Reported-by. Do you
>> want me to copy that one? Or else do you have any suggestion as
>> to who the reporter was?
> 
> Well - this patch was identified by someone on xen-devel, which I
> presume was your basis for looking into it.

No, it was me spotting the Linux commit in the stable 5.3 ChangeLog.

Jan

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

Re: [Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

[Jan Beulich]

On 21.11.2019 23:15, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/svm/emulate.c
> +++ b/xen/arch/x86/hvm/svm/emulate.c
> @@ -117,6 +117,61 @@ unsigned int svm_get_insn_len(struct vcpu *v, unsigned 
> int instr_enc)
>  }
>  
>  /*
> + * TASK_SWITCH vmexits never provide an instruction length.  We must always
> + * decode under %rip to find the answer.
> + */
> +unsigned int svm_get_task_switch_insn_len(struct vcpu *v)
> +{
> +struct hvm_emulate_ctxt ctxt;
> +struct x86_emulate_state *state;
> +unsigned int emul_len, modrm_reg;
> +
> +ASSERT(v == current);

You look to be using v here just for this ASSERT() - is this really
worth it? By making the function take "void" it would be quite obvious
that it would act on the current vCPU only.

> +hvm_emulate_init_once(&ctxt, NULL, guest_cpu_user_regs());
> +hvm_emulate_init_per_insn(&ctxt, NULL, 0);
> +state = x86_decode_insn(&ctxt.ctxt, hvmemul_insn_fetch);
> +if ( IS_ERR_OR_NULL(state) )
> +return 0;
> +
> +emul_len = x86_insn_length(state, &ctxt.ctxt);
> +
> +/*
> + * Check for an instruction which can cause a task switch.  Any far
> + * jmp/call/ret, any software interrupt/exception, and iret.
> + */
> +switch ( ctxt.ctxt.opcode )
> +{
> +case 0xff: /* Grp 5 */
> +/* call / jmp (far, absolute indirect) */
> +if ( x86_insn_modrm(state, NULL, &modrm_reg) != 3 ||

DYM "== 3", to bail upon non-memory operands?

> + (modrm_reg != 3 && modrm_reg != 5) )
> +{
> +/* Wrong instruction.  Throw #GP back for now. */
> +default:
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +emul_len = 0;
> +break;
> +}
> +/* Fallthrough */
> +case 0x62: /* bound */

Does "bound" really belong on this list? It raising #BR is like
insns raising random other exceptions, not like INTO / INT3,
where the IDT descriptor also has to have suitable DPL for the
exception to actually get delivered (rather than #GP). I.e. it
shouldn't make it here in the first place, due to the
X86_EVENTTYPE_HW_EXCEPTION check in the caller.

IOW if "bound" needs to be here, then all others need to be as
well, unless they can't cause any exception at all.

> +case 0x9a: /* call (far, absolute) */
> +case 0xca: /* ret imm16 (far) */
> +case 0xcb: /* ret (far) */
> +case 0xcc: /* int3 */
> +case 0xcd: /* int imm8 */
> +case 0xce: /* into */
> +case 0xcf: /* iret */
> +case 0xea: /* jmp (far, absolute) */
> +case 0xf1: /* icebp */

Same perhaps for ICEBP, albeit I'm less certain here, as its
behavior is too poorly documented (if at all).

> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2776,7 +2776,41 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  
>  case VMEXIT_TASK_SWITCH: {
>  enum hvm_task_switch_reason reason;
> -int32_t errcode = -1;
> +int32_t errcode = -1, insn_len = -1;
> +
> +/*
> + * All TASK_SWITCH intercepts have fault-like semantics.  NRIP is
> + * never provided, even for instruction-induced task switches, but we
> + * need to know the instruction length in order to set %eip suitably
> + * in the outgoing TSS.
> + *
> + * For a task switch which vectored through the IDT, look at the type
> + * to distinguish interrupts/exceptions from instruction based
> + * switches.
> + */
> +if ( vmcb->eventinj.fields.v )
> +{
> +/*
> + * HW_EXCEPTION, NMI and EXT_INTR are not instruction based.  All
> + * others are.
> + */
> +if ( vmcb->eventinj.fields.type <= X86_EVENTTYPE_HW_EXCEPTION )
> +insn_len = 0;
> +
> +/*
> + * Clobber the vectoring information, as we are going to emulate
> + * the task switch in full.
> + */
> +vmcb->eventinj.bytes = 0;
> +}
> +
> +/*
> + * insn_len being -1 indicates that we have an instruction-induced
> + * task switch.  Decode under %rip to find its length.
> + */
> +if ( insn_len < 0 && (insn_len = svm_get_task_switch_insn_len(v)) == 
> 0 )
> +break;

Won't this live-lock the guest? I.e. isn't it better to e.g. crash it
if svm_get_task_switch_insn_len() didn't raise #GP(0)?

Jan

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

Re: [Xen-devel] [PATCH 1/2] x86/vtx: Fix fault semantics for early task switch failures

[Andrew Cooper]

On 22/11/2019 13:08, Jan Beulich wrote:
> On 22.11.2019 13:37, Roger Pau Monné  wrote:
>> On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
>>> The VT-x task switch handler adds inst_len to rip before calling
>>> hvm_task_switch().  This causes early faults to be delivered to the guest 
>>> with
>>> trap semantics, and break restartibility.
>>>
>>> Instead, pass the instruction length into hvm_task_switch() and write it 
>>> into
>>> the outgoing tss only, leaving rip in its original location.
>>>
>>> For now, pass 0 on the SVM side.  This highlights a separate preexisting bug
>>> which will be addressed in the following patch.
>>>
>>> While adjusting call sites, drop the unnecessary uint16_t cast.
>>>
>>> Signed-off-by: Andrew Cooper 
>> Code LGTM:
>>
>> Reviewed-by: Roger Pau Monné 
> Acked-by: Jan Beulich 

It occurs to me that this also fixes a vmentry failure in the corner
case that an instruction, which crosses the 4G=>0 boundary takes a
fault.  %rip will be adjusted without being truncated.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] x86/svm: Write the correct %eip into the outgoing task

[Andrew Cooper]

On 21/11/2019 22:15, Andrew Cooper wrote:
> The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs
> assistance with instruction length.  As a result, any instruction-induced task
> switch has the outgoing task's %eip pointing at the instruction switch caused
> the switch, rather than after it.
>
> This causes explicit use of task gates to livelock (as when the task returns,
> it executes the task-switching instruction again), and any restartable task to
> become a nop after its first instantiation (the entry state points at the
> ret/iret instruction used to exit the task).

FWIW, I've rewritten this paragraph as:

This causes callers of task gates to livelock (repeatedly execute the
call/jmp
to enter the task), and any restartable task to become a nop after its first
use (the (re)entry state points at the ret/iret used to exit the task).

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] x86/vtx: Fix fault semantics for early task switch failures

[Jan Beulich]

On 22.11.2019 13:37, Roger Pau Monné  wrote:
> On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
>> The VT-x task switch handler adds inst_len to rip before calling
>> hvm_task_switch().  This causes early faults to be delivered to the guest 
>> with
>> trap semantics, and break restartibility.
>>
>> Instead, pass the instruction length into hvm_task_switch() and write it into
>> the outgoing tss only, leaving rip in its original location.
>>
>> For now, pass 0 on the SVM side.  This highlights a separate preexisting bug
>> which will be addressed in the following patch.
>>
>> While adjusting call sites, drop the unnecessary uint16_t cast.
>>
>> Signed-off-by: Andrew Cooper 
> 
> Code LGTM:
> 
> Reviewed-by: Roger Pau Monné 

Acked-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms

[Andrew Cooper]

On 22/11/2019 12:57, Jan Beulich wrote:
> On 22.11.2019 13:50, Andrew Cooper wrote:
>> On 22/11/2019 12:46, Jan Beulich wrote:
>>> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>>>
>>> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>>>  PC10, which in consequence marks TSC as unstable because HPET is used as
>>>  watchdog clocksource for TSC."
>>>
>>> Follow this for Xen as well. Looking at its patch context made me notice
>>> they have a pre-existing quirk for Bay Trail as well. The comment there,
>>> however, points at a Cherry Trail document. Looking at the datasheets of
>>> both, there appear to be similar issues, so go beyond Linux'es coverage
>>> and exclude both. Also key the disable on the PCI IDs of the actual
>>> affected devices, rather than those of 00:00.0.
>>>
>>> Apply the workarounds only when the use of HPET was not explicitly
>>> requested on the command line and when use of (deep) C-states was not
>>> disabled.
>>>
>>> Adjust a few types in touched or nearby code at the same time.
>> Reported-by ?
> The Linux commit has a Suggested-by, but no Reported-by. Do you
> want me to copy that one? Or else do you have any suggestion as
> to who the reporter was?

Well - this patch was identified by someone on xen-devel, which I
presume was your basis for looking into it.

~Andrew

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

Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms

[Jan Beulich]

On 22.11.2019 13:50, Andrew Cooper wrote:
> On 22/11/2019 12:46, Jan Beulich wrote:
>> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>>
>> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>>  PC10, which in consequence marks TSC as unstable because HPET is used as
>>  watchdog clocksource for TSC."
>>
>> Follow this for Xen as well. Looking at its patch context made me notice
>> they have a pre-existing quirk for Bay Trail as well. The comment there,
>> however, points at a Cherry Trail document. Looking at the datasheets of
>> both, there appear to be similar issues, so go beyond Linux'es coverage
>> and exclude both. Also key the disable on the PCI IDs of the actual
>> affected devices, rather than those of 00:00.0.
>>
>> Apply the workarounds only when the use of HPET was not explicitly
>> requested on the command line and when use of (deep) C-states was not
>> disabled.
>>
>> Adjust a few types in touched or nearby code at the same time.
> 
> Reported-by ?

The Linux commit has a Suggested-by, but no Reported-by. Do you
want me to copy that one? Or else do you have any suggestion as
to who the reporter was?

>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Andrew Cooper 

Thanks.

Jan

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

Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms

[Andrew Cooper]

On 22/11/2019 12:46, Jan Beulich wrote:
> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>
> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>  PC10, which in consequence marks TSC as unstable because HPET is used as
>  watchdog clocksource for TSC."
>
> Follow this for Xen as well. Looking at its patch context made me notice
> they have a pre-existing quirk for Bay Trail as well. The comment there,
> however, points at a Cherry Trail document. Looking at the datasheets of
> both, there appear to be similar issues, so go beyond Linux'es coverage
> and exclude both. Also key the disable on the PCI IDs of the actual
> affected devices, rather than those of 00:00.0.
>
> Apply the workarounds only when the use of HPET was not explicitly
> requested on the command line and when use of (deep) C-states was not
> disabled.
>
> Adjust a few types in touched or nearby code at the same time.

Reported-by ?

> Signed-off-by: Jan Beulich 

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 v1 for 4.13] x86/microcode: refuse to load the same revision ucode

[Chao Gao]

On Fri, Nov 22, 2019 at 12:19:41PM +0100, Jan Beulich wrote:
>On 22.11.2019 11:52, Sergey Dyasli wrote:
>> Currently if a user tries to live-load the same ucode revision that CPU
>> already has, he will get a single message in Xen log like:
>> 
>> (XEN) 128 cores are to update their microcode
>> 
>> No actual ucode loading will happen and this situation can be quite
>> confusing. Fix this by starting ucode update only when a newer ucode
>> revision has been provided. This is based on an assumption that all CPUs
>> in the system have the same ucode revision. If that's not the case,
>> the system must be considered unstable.
>
>Unstable or not, I did specifically convince Chao to handle such
>systems, bringing them into better shape. I can only repeat that
>I actually have a system where on each socket firmware loads ucode
>only on the first core. I don't see why boot time loading and late
>loading should differ in behavior for such a system.

Yes. 

I tried to load an older ucode but also got the same message. So I think
an optimization can be done:
we can assume that if there is a microcode_cache, all CPUs
should have equal or newer revision than the microcode_cache. If
the patch to be loaded has equal or older revision, we can refuse to
load to avoid the heavy stop_machine().

Thanks
Chao

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

[Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms

[Jan Beulich]

Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says

"Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
 PC10, which in consequence marks TSC as unstable because HPET is used as
 watchdog clocksource for TSC."

Follow this for Xen as well. Looking at its patch context made me notice
they have a pre-existing quirk for Bay Trail as well. The comment there,
however, points at a Cherry Trail document. Looking at the datasheets of
both, there appear to be similar issues, so go beyond Linux'es coverage
and exclude both. Also key the disable on the PCI IDs of the actual
affected devices, rather than those of 00:00.0.

Apply the workarounds only when the use of HPET was not explicitly
requested on the command line and when use of (deep) C-states was not
disabled.

Adjust a few types in touched or nearby code at the same time.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -367,12 +368,41 @@ static u64 read_hpet_count(void)
 return hpet_read32(HPET_COUNTER);
 }
 
-static s64 __init init_hpet(struct platform_timesource *pts)
+static int64_t __init init_hpet(struct platform_timesource *pts)
 {
-u64 hpet_rate = hpet_setup(), start;
-u32 count, target;
+uint64_t hpet_rate, start;
+uint32_t count, target;
 
-if ( hpet_rate == 0 )
+if ( hpet_address && strcmp(opt_clocksource, pts->id) &&
+ cpuidle_using_deep_cstate() )
+{
+if ( pci_conf_read16(PCI_SBDF(0, 0, 0x1f, 0),
+ PCI_VENDOR_ID) == PCI_VENDOR_ID_INTEL )
+switch ( pci_conf_read16(PCI_SBDF(0, 0, 0x1f, 0), PCI_DEVICE_ID) )
+{
+/* HPET on Bay Trail platforms will halt in deep C states. */
+case 0x0f1c:
+/* HPET on Cherry Trail platforms will halt in deep C states. */
+case 0x229c:
+hpet_address = 0;
+break;
+}
+
+/*
+ * Some Coffee Lake platforms have a skewed HPET timer once the SoCs
+ * entered PC10.
+ */
+if ( pci_conf_read16(PCI_SBDF(0, 0, 0, 0),
+ PCI_VENDOR_ID) == PCI_VENDOR_ID_INTEL &&
+ pci_conf_read16(PCI_SBDF(0, 0, 0, 0),
+ PCI_DEVICE_ID) == 0x3ec4 )
+hpet_address = 0;
+
+if ( !hpet_address )
+printk("Disabling HPET for being unreliable\n");
+}
+
+if ( (hpet_rate = hpet_setup()) == 0 )
 return 0;
 
 pts->frequency = hpet_rate;

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

Re: [Xen-devel] [PATCH 1/2] x86/vtx: Fix fault semantics for early task switch failures

[Andrew Cooper]

On 22/11/2019 12:37, Roger Pau Monné wrote:
> On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
>> The VT-x task switch handler adds inst_len to rip before calling
>> hvm_task_switch().  This causes early faults to be delivered to the guest 
>> with
> By early faults you mean faults injected by hvm_task_switch itself for
> example?

A task switch is restartable up until a point.  Beyond that point any
chaos will reign in the new task, not the old task.

By "early", I mean any fault which is handled in the context of the old
task.  As far as testing goes, I think mapping the current TSS as
read-only is about the only way I've got causing this to occur, because
all other fault conditions are checked by the processor before issuing a
TASK_SWITCH VMExit.

>
>> trap semantics, and break restartibility.
>>
>> Instead, pass the instruction length into hvm_task_switch() and write it into
>> the outgoing tss only, leaving rip in its original location.
>>
>> For now, pass 0 on the SVM side.  This highlights a separate preexisting bug
>> which will be addressed in the following patch.
>>
>> While adjusting call sites, drop the unnecessary uint16_t cast.
>>
>> Signed-off-by: Andrew Cooper 
> Code LGTM:
>
> Reviewed-by: Roger Pau Monné 

Thanks,

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] x86/vtx: Fix fault semantics for early task switch failures

[Roger Pau Monné]

On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
> The VT-x task switch handler adds inst_len to rip before calling
> hvm_task_switch().  This causes early faults to be delivered to the guest with

By early faults you mean faults injected by hvm_task_switch itself for
example?

> trap semantics, and break restartibility.
> 
> Instead, pass the instruction length into hvm_task_switch() and write it into
> the outgoing tss only, leaving rip in its original location.
> 
> For now, pass 0 on the SVM side.  This highlights a separate preexisting bug
> which will be addressed in the following patch.
> 
> While adjusting call sites, drop the unnecessary uint16_t cast.
> 
> Signed-off-by: Andrew Cooper 

Code LGTM:

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

[Xen-devel] [xen-4.11-testing test] 144240: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-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-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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  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-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-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-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  74507046dbd2c5d2991eeabd1af39af0d6b29d70
baseline version:
 xen  006b2041242129896fbd30135b3dc6f575894a07

Last test of basis   144025  2019-11-11 17:36:00 Z   10 days
Testing same since   144058  2019-11-12 18:05:56 Z9 days   16 attempts

Re: [Xen-devel] [PATCH v2 3/3] libxl: make default path to add/remove all PV devices

[Wei Liu]

On Thu, Nov 21, 2019 at 08:13:00PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Adding/removing device is handled for specific devices only: VBD, VIF,
> QDISK. This commit adds default case to handle adding/removing for all PV
> devices by default, except QDISK device, which requires special handling.
> If any other device is required a special handling it should be done by
> implementing separate case (similar to QDISK device). The default
> behaviour for adding device is to wait when the backend goes to
> XenbusStateInitWait and the default behaviour on removing device is to
> start generic device remove procedure.
> 
> Also this commit fixes removing guest function: before the guest was
> removed when all VIF and VBD devices are removed. The fix removes
> guest when all created devices are removed. This is done by checking the
> guest device list instead of checking num_vifs and num_vbds. num_vifs and
> num_vbds variables are removed as redundant in this case.
> 
> Signed-off-by: Oleksandr Grytsov 

I agree with this approach in general, but I haven't looked closely into
the implementation. FWIW:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 2/3] libxl: rename VKB backend type "linux" to "pv"

[Wei Liu]

On Fri, Nov 22, 2019 at 11:14:41AM +, Ian Jackson wrote:
> Oleksandr Grytsov writes ("[PATCH v2 2/3] libxl: rename VKB backend type 
> "linux" to "pv""):
> > From: Oleksandr Grytsov 
> > 
> > There are two kind of VKB backends: QEMU and user space PV backend.
> > For PV backend "linux" enum is used but this name is confused. Rename
> > "linux" enum to "pv" as it better matches user space PV backend.
> > 
> > Signed-off-by: Oleksandr Grytsov 
> 
> Requested-by: Ian Jackson 
> Acked-by: Ian Jackson 

The LINUX type was introduced back in 2018.

This patch should have provided at least a

  #define ...LINUX ...PV

in libxl.h for backward compatibility purpose.

Wei.


> 
> Thanks.
> 
> Ian.

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

Re: [Xen-devel] [PATCH v4 6/8] x86: switch xen guest implementation to use hypervisor framework

[Wei Liu]

On Fri, Nov 22, 2019 at 11:02:30AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Xen-devel  On Behalf Of Wei
> > Liu
> > Sent: 21 November 2019 19:51
> > To: Xen Development List 
> > Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> > ; Michael Kelley ; Jan
> > Beulich ; Roger Pau Monné 
> > Subject: [Xen-devel] [PATCH v4 6/8] x86: switch xen guest implementation
> > to use hypervisor framework
> > 
> > Signed-off-by: Wei Liu 
> [snip] 
> > diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-
> > x86/guest/xen.h
> > index 01dc3ee6f6..db90b550a7 100644
> > --- a/xen/include/asm-x86/guest/xen.h
> > +++ b/xen/include/asm-x86/guest/xen.h
> > @@ -23,6 +23,7 @@
> > 
> >  #include 
> >  #include 
> > +#include 
> > 
> >  #define XEN_shared_info ((struct shared_info
> > *)fix_to_virt(FIX_XEN_SHARED_INFO))
> > 
> > @@ -32,7 +33,7 @@ extern bool xen_guest;
> >  extern bool pv_console;
> >  extern uint32_t xen_cpuid_base;
> > 
> > -void probe_hypervisor(void);
> > +const struct hypervisor_ops *xen_probe(void);
> >  int xg_alloc_unused_page(mfn_t *mfn);
> >  int xg_free_unused_page(mfn_t mfn);
> > 
> > @@ -44,7 +45,7 @@ DECLARE_PER_CPU(struct vcpu_info *, vcpu_info);
> >  #define xen_guest 0
> >  #define pv_console 0
> 
> Nit: These should be #defined to false rather than 0. The rest LGTM so with 
> those fixed,

They were part of existing code so I didn't touch them.

Wei.

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

Re: [Xen-devel] [PATCH for-4.13 v2 0/3] Remove backend xen store entry on domain destroy

[Ian Jackson]

Oleksandr Grytsov writes ("[PATCH v2 0/3] Remove backend xen store entry on 
domain destroy"):
> From: Oleksandr Grytsov 
> 
> Changes since v1:
> 
> * add commit to rename VKB backend type "linux" to "pv";
> * add default case to handle adding/removing PV devices in add_device,
>   remove_device functions (libxl_device.c);
> * add comment about removing num_vifs, num_vbds into commit message.

Thank you for this.  As you see, I approve.  We need an ack from the
Release Manager, so I have addresed Juergen (and also added the
missing `for-4.13' tag to the subject).

Given where we are in the release cycle with this (which I stress is
not really Oleksandr's fault) I think I would like to get a 2nd review
from another libxl maintainer.  Anthony, or Wei, would you like to
take a look ?

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH] gnttab: make sure grant map operations don't skip their IOMMU part

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of Jan
> Beulich
> Sent: 21 November 2019 17:38
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Wilk ; George Dunlap
> ; Andrew Cooper ;
> Ian Jackson 
> Subject: [Xen-devel] [PATCH] gnttab: make sure grant map operations don't
> skip their IOMMU part
> 
> Two almost simultaneous mapping requests need to make sure that at the
> completion of the earlier one IOMMU mappings (established explicitly
> here in the PV case) have been put in place. Forever since the splitting
> of the grant table lock a violation of this has been possible (using
> simplified pin counts, as it doesn't matter whether we talk about read
> or write mappings here):
> 
> initial state: act->pin = 0
> 
> vCPU A: progress the operation past the dropping of the locks after the
> act->pin updates (act->pin = 1, old_pin = 0, act_pin = 1)
> 
> vCPU B: progress the operation past the dropping of the locks after the
> act->pin updates (act->pin = 2, old_pin = 1, act_pin = 2)
> 
> vCPU B: (re-)acquire both gt locks, mapkind() returns 0, but both
> iommu_legacy_map() invocations get skipped due to non-zero
> old_pin
> 
> vCPU B: return to caller without IOMMU mapping
> 
> vCPU A: (re-)acquire both gt locks, mapkind() returns 0,
> iommu_legacy_map() gets invoked
> 
> With the locks dropped intermediately, whether to invoke
> iommu_legacy_map() must depend on only the return value of mapkind()
> and of course the kind of mapping request being processed, just like
> is already the case in unmap_common().
> 
> Also fix the style of the adjacent comment, and correct a nearby one
> still referring to a prior name of what is now mapkind().
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -917,8 +917,6 @@ map_grant_ref(
>  mfn_t mfn;
>  struct page_info *pg = NULL;
>  intrc = GNTST_okay;
> -u32old_pin;
> -u32act_pin;
>  unsigned int   cache_flags, clear_flags = 0, refcnt = 0, typecnt = 0;
>  bool   host_map_created = false;
>  struct active_grant_entry *act = NULL;
> @@ -1027,7 +1025,6 @@ map_grant_ref(
>  }
>  }
> 
> -old_pin = act->pin;
>  if ( op->flags & GNTMAP_device_map )
>  act->pin += (op->flags & GNTMAP_readonly) ?
>  GNTPIN_devr_inc : GNTPIN_devw_inc;
> @@ -1036,7 +1033,6 @@ map_grant_ref(
>  GNTPIN_hstr_inc : GNTPIN_hstw_inc;
> 
>  mfn = act->mfn;
> -act_pin = act->pin;
> 
>  cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
> 
> @@ -1144,27 +1140,22 @@ map_grant_ref(
>  if ( need_iommu )
>  {
>  unsigned int kind;
> -int err = 0;
> 
>  double_gt_lock(lgt, rgt);
> 
> -/* We're not translated, so we know that gmfns and mfns are
> -   the same things, so the IOMMU entry is always 1-to-1. */
> +/*
> + * We're not translated, so we know that dfns and mfns are
> + * the same things, so the IOMMU entry is always 1-to-1.
> + */
>  kind = mapkind(lgt, rd, mfn);
> -if ( (act_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) &&
> - !(old_pin & (GNTPIN_hstw_mask|GNTPIN_devw_mask)) )
> -{
> -if ( !(kind & MAPKIND_WRITE) )
> -err = iommu_legacy_map(ld, _dfn(mfn_x(mfn)), mfn, 0,
> -   IOMMUF_readable |
> IOMMUF_writable);
> -}
> -else if ( act_pin && !old_pin )
> -{
> -if ( !kind )
> -err = iommu_legacy_map(ld, _dfn(mfn_x(mfn)), mfn, 0,
> -   IOMMUF_readable);
> -}
> -if ( err )
> +if ( !(op->flags & GNTMAP_readonly) &&
> + !(kind & MAPKIND_WRITE) )
> +kind = IOMMUF_readable | IOMMUF_writable;
> +else if ( !kind )
> +kind = IOMMUF_readable;
> +else
> +kind = 0;
> +if ( kind && iommu_legacy_map(ld, _dfn(mfn_x(mfn)), mfn, 0, kind)

Re-using 'kind' in this way slightly obfuscates things. I'm sure the compiler 
would still generate reasonable code if you used a separate 'flags' variable 
within the same scope.

  Paul

> )
>  {
>  double_gt_unlock(lgt, rgt);
>  rc = GNTST_general_error;
> @@ -1179,7 +1170,7 @@ map_grant_ref(
>   * other fields so just ensure the flags field is stored last.
>   *
>   * However, if gnttab_need_iommu_mapping() then this would race
> - * with a concurrent mapcount() call (on an unmap, for example)
> + * with a concurrent mapkind() call (on an unmap, for example)
>   * and a lock is required.
>   */
>  mt = &maptrack_entry(lgt, handle);
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> ht

Re: [Xen-devel] [PATCH v1 for 4.13] x86/microcode: refuse to load the same revision ucode

[Jan Beulich]

On 22.11.2019 11:52, Sergey Dyasli wrote:
> Currently if a user tries to live-load the same ucode revision that CPU
> already has, he will get a single message in Xen log like:
> 
> (XEN) 128 cores are to update their microcode
> 
> No actual ucode loading will happen and this situation can be quite
> confusing. Fix this by starting ucode update only when a newer ucode
> revision has been provided. This is based on an assumption that all CPUs
> in the system have the same ucode revision. If that's not the case,
> the system must be considered unstable.

Unstable or not, I did specifically convince Chao to handle such
systems, bringing them into better shape. I can only repeat that
I actually have a system where on each socket firmware loads ucode
only on the first core. I don't see why boot time loading and late
loading should differ in behavior for such a system.

Jan

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

Re: [Xen-devel] [PATCH v2 3/3] libxl: make default path to add/remove all PV devices

[Ian Jackson]

Oleksandr Grytsov writes ("[PATCH v2 3/3] libxl: make default path to 
add/remove all PV devices"):
> From: Oleksandr Grytsov 
> 
> Adding/removing device is handled for specific devices only: VBD, VIF,
> QDISK. This commit adds default case to handle adding/removing for all PV
> devices by default, except QDISK device, which requires special handling.
> If any other device is required a special handling it should be done by
> implementing separate case (similar to QDISK device). The default
> behaviour for adding device is to wait when the backend goes to
> XenbusStateInitWait and the default behaviour on removing device is to
> start generic device remove procedure.
> 
> Also this commit fixes removing guest function: before the guest was
> removed when all VIF and VBD devices are removed. The fix removes
> guest when all created devices are removed. This is done by checking the
> guest device list instead of checking num_vifs and num_vbds. num_vifs and
> num_vbds variables are removed as redundant in this case.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v2 2/3] libxl: rename VKB backend type "linux" to "pv"

[Ian Jackson]

Oleksandr Grytsov writes ("[PATCH v2 2/3] libxl: rename VKB backend type 
"linux" to "pv""):
> From: Oleksandr Grytsov 
> 
> There are two kind of VKB backends: QEMU and user space PV backend.
> For PV backend "linux" enum is used but this name is confused. Rename
> "linux" enum to "pv" as it better matches user space PV backend.
> 
> Signed-off-by: Oleksandr Grytsov 

Requested-by: Ian Jackson 
Acked-by: Ian Jackson 

Thanks.

Ian.

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

Re: [Xen-devel] [PATCH v4 8/8] x86: introduce CONFIG_HYPERV and detection code

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List 
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné 
> Subject: [Xen-devel] [PATCH v4 8/8] x86: introduce CONFIG_HYPERV and
> detection code
> 
> We use the same code structure as we did for Xen.
> 
> As starters, detect Hyper-V in probe routine. More complex
> functionalities will be added later.
> 
> Take the chance to fix XEN_GUEST in Kconfig.

Would this fix be better in your earlier renaming patch?

> 
> Signed-off-by: Wei Liu 

Either way...

Reviewed-by: Paul Durrant 

> ---
> Changes in V4:
> 1. Add comment regarding order of probe functions.
> 2. Adapt to changes in previous patches.
> ---
>  xen/arch/x86/Kconfig   | 11 --
>  xen/arch/x86/guest/Makefile|  1 +
>  xen/arch/x86/guest/hyperv/Makefile |  1 +
>  xen/arch/x86/guest/hyperv/hyperv.c | 54 ++
>  xen/arch/x86/guest/hypervisor.c|  8 +
>  xen/include/asm-x86/guest.h|  1 +
>  xen/include/asm-x86/guest/hyperv.h | 43 
>  7 files changed, 117 insertions(+), 2 deletions(-)
>  create mode 100644 xen/arch/x86/guest/hyperv/Makefile
>  create mode 100644 xen/arch/x86/guest/hyperv/hyperv.c
>  create mode 100644 xen/include/asm-x86/guest/hyperv.h
> 
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 867de857e8..0a02b6ee3f 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -164,10 +164,17 @@ endchoice
>  config GUEST
>   bool
> 
> +config HYPERV_GUEST
> + bool "Hyper-V Guest"
> + select GUEST
> + ---help---
> +   Support for Xen detecting when it is running under Hyper-V.
> +
> +   If unsure, say N.
> +
>  config XEN_GUEST
> - def_bool n
> + bool "Xen Guest"
>   select GUEST
> - prompt "Xen Guest"
>   ---help---
> Support for Xen detecting when it is running under Xen.
> 
> diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
> index f63d64bbee..f164196772 100644
> --- a/xen/arch/x86/guest/Makefile
> +++ b/xen/arch/x86/guest/Makefile
> @@ -1,3 +1,4 @@
>  obj-y += hypervisor.o
> 
> +subdir-$(CONFIG_HYPERV_GUEST) += hyperv
>  subdir-$(CONFIG_XEN_GUEST) += xen
> diff --git a/xen/arch/x86/guest/hyperv/Makefile
> b/xen/arch/x86/guest/hyperv/Makefile
> new file mode 100644
> index 00..68170109a9
> --- /dev/null
> +++ b/xen/arch/x86/guest/hyperv/Makefile
> @@ -0,0 +1 @@
> +obj-y += hyperv.o
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
> b/xen/arch/x86/guest/hyperv/hyperv.c
> new file mode 100644
> index 00..916e08ff89
> --- /dev/null
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -0,0 +1,54 @@
> +/
> **
> + * arch/x86/guest/hyperv/hyperv.c
> + *
> + * Support for detecting and running under Hyper-V.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + *
> + * Copyright (c) 2019 Microsoft.
> + */
> +#include 
> +
> +#include 
> +
> +static const struct hypervisor_ops hyperv_ops = {
> +.name = "Hyper-V",
> +};
> +
> +const struct hypervisor_ops * __init hyperv_probe(void)
> +{
> +uint32_t eax, ebx, ecx, edx;
> +
> +cpuid(0x4000, &eax, &ebx, &ecx, &edx);
> +if ( !((ebx == 0x7263694d) &&  /* "Micr" */
> +   (ecx == 0x666f736f) &&  /* "osof" */
> +   (edx == 0x76482074)) )  /* "t Hv" */
> +return NULL;
> +
> +cpuid(0x4001, &eax, &ebx, &ecx, &edx);
> +if ( eax != 0x31237648 )/* Hv#1 */
> +return NULL;
> +
> +return &hyperv_ops;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/x86/guest/hypervisor.c
> b/xen/arch/x86/guest/hypervisor.c
> index a067cacecb..c293e185cc 100644
> --- a/xen/arch/x86/guest/hypervisor.c
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -39,6 +39,14 @@ const struct hypervisor_ops *hypervisor_probe(void)
>  if ( hops )
>  goto out;
> 
> +/*
> + * Detection of Hyper-V must come after Xen to avoid false positive
> due
> + * to viridian support
> + */
> +hops = hyperv_probe();
> +if ( hops )
> +goto out;
> +
>   out:
> 

Re: [Xen-devel] [PATCH v4 7/8] x86: be more verbose when running on a hypervisor

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List 
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné 
> Subject: [Xen-devel] [PATCH v4 7/8] x86: be more verbose when running on a
> hypervisor
> 
> Also replace xen_guest with running_on_hypervisor boolean.
> 
> Signed-off-by: Wei Liu 
> ---
> Changes in v4:
> 1. Access ->name directly.
> 2. Drop Roger's review tag.
> ---
>  xen/arch/x86/setup.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 19606d909b..123436b35a 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -689,6 +689,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  int i, j, e820_warn = 0, bytes = 0;
>  bool acpi_boot_table_init_done = false, relocated = false;
>  int ret;
> +bool running_on_hypervisor;

Why not stash hops here? Then you can...

>  struct ns16550_defaults ns16550 = {
>  .data_bits = 8,
>  .parity= 'n',
> @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>   * allocing any xenheap structures wanted in lower memory. */
>  kexec_early_calculations();
> 
> -hypervisor_probe();
> +running_on_hypervisor = !!hypervisor_probe();
> 
>  parse_video_info();
> 
> @@ -788,6 +789,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  printk("Command line: %s\n", cmdline);
> 
>  printk("Xen image load base address: %#lx\n", xen_phys_start);
> +if ( running_on_hypervisor )
> +printk("Running on %s\n", hypervisor_probe()->name);

...avoid calling hypervisor_probe() again here.

  Paul

> 
>  #ifdef CONFIG_VIDEO
>  printk("Video information:\n");
> @@ -1569,7 +1572,7 @@ void __init noreturn __start_xen(unsigned long
> mbi_p)
>  max_cpus = nr_cpu_ids;
>  }
> 
> -if ( xen_guest )
> +if ( running_on_hypervisor )
>  hypervisor_setup();
> 
>  /* Low mappings were only needed for some BIOS table parsing. */
> --
> 2.20.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 6/8] x86: switch xen guest implementation to use hypervisor framework

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List 
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné 
> Subject: [Xen-devel] [PATCH v4 6/8] x86: switch xen guest implementation
> to use hypervisor framework
> 
> Signed-off-by: Wei Liu 
[snip] 
> diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-
> x86/guest/xen.h
> index 01dc3ee6f6..db90b550a7 100644
> --- a/xen/include/asm-x86/guest/xen.h
> +++ b/xen/include/asm-x86/guest/xen.h
> @@ -23,6 +23,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  #define XEN_shared_info ((struct shared_info
> *)fix_to_virt(FIX_XEN_SHARED_INFO))
> 
> @@ -32,7 +33,7 @@ extern bool xen_guest;
>  extern bool pv_console;
>  extern uint32_t xen_cpuid_base;
> 
> -void probe_hypervisor(void);
> +const struct hypervisor_ops *xen_probe(void);
>  int xg_alloc_unused_page(mfn_t *mfn);
>  int xg_free_unused_page(mfn_t mfn);
> 
> @@ -44,7 +45,7 @@ DECLARE_PER_CPU(struct vcpu_info *, vcpu_info);
>  #define xen_guest 0
>  #define pv_console 0

Nit: These should be #defined to false rather than 0. The rest LGTM so with 
those fixed,

Reviewed-by: Paul Durrant 



> 
> -static inline void probe_hypervisor(void) {}
> +static inline const struct hypervisor_ops *xen_probe(void) { return NULL;
> }
> 
>  #endif /* CONFIG_XEN_GUEST */
>  #endif /* __X86_GUEST_XEN_H__ */
> --
> 2.20.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 5/8] x86: rename hypervisor_{alloc, free}_unused_page

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List 
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné 
> Subject: [Xen-devel] [PATCH v4 5/8] x86: rename hypervisor_{alloc,
> free}_unused_page
> 
> They are used in Xen code only.
> 
> No functional change.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Paul Durrant 

> ---
> Changes in v4:
> 1. Use xg_ prefix instead.
> 2. Drop Roger's review tag.
> ---
>  xen/arch/x86/guest/xen/xen.c| 6 +++---
>  xen/arch/x86/pv/shim.c  | 4 ++--
>  xen/include/asm-x86/guest/xen.h | 4 ++--
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
> index 1e37086518..0f5b5267c5 100644
> --- a/xen/arch/x86/guest/xen/xen.c
> +++ b/xen/arch/x86/guest/xen/xen.c
> @@ -93,7 +93,7 @@ static void map_shared_info(void)
>  unsigned int i;
>  unsigned long rc;
> 
> -if ( hypervisor_alloc_unused_page(&mfn) )
> +if ( xg_alloc_unused_page(&mfn) )
>  panic("unable to reserve shared info memory page\n");
> 
>  xatp.gpfn = mfn_x(mfn);
> @@ -280,7 +280,7 @@ void hypervisor_ap_setup(void)
>  init_evtchn();
>  }
> 
> -int hypervisor_alloc_unused_page(mfn_t *mfn)
> +int xg_alloc_unused_page(mfn_t *mfn)
>  {
>  unsigned long m;
>  int rc;
> @@ -292,7 +292,7 @@ int hypervisor_alloc_unused_page(mfn_t *mfn)
>  return rc;
>  }
> 
> -int hypervisor_free_unused_page(mfn_t mfn)
> +int xg_free_unused_page(mfn_t mfn)
>  {
>  return rangeset_remove_range(mem, mfn_x(mfn), mfn_x(mfn));
>  }
> diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
> index 351da970ef..7a898fdbe5 100644
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -742,7 +742,7 @@ static long pv_shim_grant_table_op(unsigned int cmd,
>  };
>  mfn_t mfn;
> 
> -rc = hypervisor_alloc_unused_page(&mfn);
> +rc = xg_alloc_unused_page(&mfn);
>  if ( rc )
>  {
>  gprintk(XENLOG_ERR,
> @@ -754,7 +754,7 @@ static long pv_shim_grant_table_op(unsigned int cmd,
>  rc = xen_hypercall_memory_op(XENMEM_add_to_physmap,
> &xatp);
>  if ( rc )
>  {
> -hypervisor_free_unused_page(mfn);
> +xg_free_unused_page(mfn);
>  break;
>  }
> 
> diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-
> x86/guest/xen.h
> index 3145f75361..01dc3ee6f6 100644
> --- a/xen/include/asm-x86/guest/xen.h
> +++ b/xen/include/asm-x86/guest/xen.h
> @@ -33,8 +33,8 @@ extern bool pv_console;
>  extern uint32_t xen_cpuid_base;
> 
>  void probe_hypervisor(void);
> -int hypervisor_alloc_unused_page(mfn_t *mfn);
> -int hypervisor_free_unused_page(mfn_t mfn);
> +int xg_alloc_unused_page(mfn_t *mfn);
> +int xg_free_unused_page(mfn_t mfn);
> 
>  DECLARE_PER_CPU(unsigned int, vcpu_id);
>  DECLARE_PER_CPU(struct vcpu_info *, vcpu_info);
> --
> 2.20.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v1 for 4.13] x86/microcode: refuse to load the same revision ucode

[Sergey Dyasli]

Currently if a user tries to live-load the same ucode revision that CPU
already has, he will get a single message in Xen log like:

(XEN) 128 cores are to update their microcode

No actual ucode loading will happen and this situation can be quite
confusing. Fix this by starting ucode update only when a newer ucode
revision has been provided. This is based on an assumption that all CPUs
in the system have the same ucode revision. If that's not the case,
the system must be considered unstable.

Additionally, print a user friendly message if no newer ucode can be
found. This also requires ignoring -ENODATA in AMD-side code, otherwise
the message given to user is:

(XEN) Parsing microcode blob error -61

Which actually means that a ucode blob was parsed fine, but no matching
ucode was found.

Signed-off-by: Sergey Dyasli 
---
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Roger Pau Monné 
CC: Chao Gao 
CC: Juergen Gross 
---
 xen/arch/x86/microcode.c   | 2 ++
 xen/arch/x86/microcode_amd.c   | 4 ++--
 xen/arch/x86/microcode_intel.c | 2 +-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 65d1f41e7c..255613569d 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -641,6 +641,8 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) 
buf, unsigned long len)
 if ( !patch )
 {
 ret = -ENOENT;
+printk(XENLOG_WARNING "microcode: couldn't find any newer revision in "
+  "the provided blob!\n");
 goto put;
 }
 
diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
index 1e52f7f49a..dd81b5239a 100644
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -518,7 +518,7 @@ static struct microcode_patch *cpu_request_microcode(const 
void *buf,
  * If the new ucode covers current CPU, compare ucodes and store the
  * one with higher revision.
  */
-if ( (microcode_fits(mc_amd) != MIS_UCODE) &&
+if ( (microcode_fits(mc_amd) == NEW_UCODE) &&
  (!saved || (compare_header(mc_amd->mpb, saved) == NEW_UCODE)) )
 {
 xfree(saved);
@@ -576,7 +576,7 @@ static struct microcode_patch *cpu_request_microcode(const 
void *buf,
 free_patch(mc_amd);
 
   out:
-if ( error && !patch )
+if ( error && error != -ENODATA && !patch )
 patch = ERR_PTR(error);
 
 return patch;
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index 9f66057aad..a76b860226 100644
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -377,7 +377,7 @@ static struct microcode_patch *cpu_request_microcode(const 
void *buf,
  * If the new update covers current CPU, compare updates and store the
  * one with higher revision.
  */
-if ( (microcode_update_match(&mc->hdr) != MIS_UCODE) &&
+if ( (microcode_update_match(&mc->hdr) == NEW_UCODE) &&
  (!saved || (mc->hdr.rev > saved->hdr.rev)) )
 {
 xfree(saved);
-- 
2.17.1


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

Re: [Xen-devel] [PATCH v4 4/8] x86: introduce hypervisor framework

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List 
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné 
> Subject: [Xen-devel] [PATCH v4 4/8] x86: introduce hypervisor framework
> 
> We will soon implement Hyper-V support for Xen. Add a framework for
> that.
> 
> This requires moving some of the hypervisor_* functions from xen.h to
> hypervisor.h.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Paul Durrant 

> ---
> Changes in v4:
> 1. Add ASSERT_UNREACHABLE to stubs.
> 2. Move __read_mostly.
> 3. Return hops directly.
> 4. Drop Paul's review tag.
> ---
>  xen/arch/x86/guest/Makefile|  2 +
>  xen/arch/x86/guest/hypervisor.c| 42 +
>  xen/include/asm-x86/guest.h|  1 +
>  xen/include/asm-x86/guest/hypervisor.h | 62 ++
>  xen/include/asm-x86/guest/xen.h| 12 -
>  5 files changed, 107 insertions(+), 12 deletions(-)
>  create mode 100644 xen/arch/x86/guest/hypervisor.c
>  create mode 100644 xen/include/asm-x86/guest/hypervisor.h
> 
> diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
> index 6806f04947..f63d64bbee 100644
> --- a/xen/arch/x86/guest/Makefile
> +++ b/xen/arch/x86/guest/Makefile
> @@ -1 +1,3 @@
> +obj-y += hypervisor.o
> +
>  subdir-$(CONFIG_XEN_GUEST) += xen
> diff --git a/xen/arch/x86/guest/hypervisor.c
> b/xen/arch/x86/guest/hypervisor.c
> new file mode 100644
> index 00..103feba5d8
> --- /dev/null
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -0,0 +1,42 @@
> +/
> **
> + * arch/x86/guest/hypervisor.c
> + *
> + * Support for detecting and running under a hypervisor.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + *
> + * Copyright (c) 2019 Microsoft.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +static const struct hypervisor_ops __read_mostly *hops;
> +
> +const struct hypervisor_ops *hypervisor_probe(void)
> +{
> +return hops;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/include/asm-x86/guest.h b/xen/include/asm-x86/guest.h
> index a38c6b5b3f..8e167165ae 100644
> --- a/xen/include/asm-x86/guest.h
> +++ b/xen/include/asm-x86/guest.h
> @@ -20,6 +20,7 @@
>  #define __X86_GUEST_H__
> 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/include/asm-x86/guest/hypervisor.h b/xen/include/asm-
> x86/guest/hypervisor.h
> new file mode 100644
> index 00..2ab15a7108
> --- /dev/null
> +++ b/xen/include/asm-x86/guest/hypervisor.h
> @@ -0,0 +1,62 @@
> +/
> **
> + * asm-x86/guest/hypervisor.h
> + *
> + * 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 that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see
> .
> + *
> + * Copyright (c) 2019 Microsoft.
> + */
> +
> +#ifndef __X86_HYPERVISOR_H__
> +#define __X86_HYPERVISOR_H__
> +
> +struct hypervisor_ops {
> +/* Name of the hypervisor */
> +const char *name;
> +/* Main setup routine */
> +void (*setup)(void);
> +/* AP setup */
> +void (*ap_setup)(void);
> +/* Resume from suspension */
> +void (*resume)(void);
> +};
> +
> +#ifdef CONFIG_GUEST
> +
> +const struct hypervisor_ops *hypervisor_probe(void);
> +void hypervisor_setup(void);
> +void hypervisor_ap_setup(void);
> +void hypervisor_resume(void);
> +
> +#else
> +
> +#include 
> +#include 
> +
> +static inline const struct hypervisor_ops *hypervisor_probe(void) {
> return NULL; }
> +static inline void hypervisor_setup(void) { ASSERT_UNREACHABLE(); }
> +static inline void hyp

Re: [Xen-devel] [PATCH for-4.13 0/2] x86/hvm: Multiple corrections to task switch handling

[Andrew Cooper]

On 22/11/2019 10:23, Roger Pau Monné wrote:
> On Thu, Nov 21, 2019 at 10:15:49PM +, Andrew Cooper wrote:
>> These patches want backporting due to the severity of patch 2.  They should
>> therefore be considered for 4.13 at this point.
> Is there a matching XTF test to exercise this functionality?

Modification of an existing one to begin with (which is how I spotted
the problems).

I don't have a CI-ready test yet.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.13 0/2] x86/hvm: Multiple corrections to task switch handling

[Roger Pau Monné]

On Thu, Nov 21, 2019 at 10:15:49PM +, Andrew Cooper wrote:
> These patches want backporting due to the severity of patch 2.  They should
> therefore be considered for 4.13 at this point.

Is there a matching XTF test to exercise this functionality?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v1.5] x86/livepatch: Prevent patching with active waitqueues

[Jürgen Groß]

On 05.11.19 20:49, Andrew Cooper wrote:

The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true.  The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different vcpu.

This case is rare, and can be worked around by pausing the offending
domain(s), waiting for their rings to drain, then performing a livepatch.

In the case that there is an active waitqueue, fail the livepatch attempt with
-EBUSY, which is preforable to the fireworks which occur from trying to unwind
the old stack frame at a later point.

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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 144042

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 15 guest-stop   fail  like 143715
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144042
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144042
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144042
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144042
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144042
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 144042
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144042
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-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-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  7059afb202ff0d82a6fa94f7ef84e4bb3139914e
baseline version:
 xen  a458d3bd0d2585275c128556ec0cbd818c6a7b0d

Last test of basis   144042  2019-11-12 09:07:51 Z9 days
Failing since144067  2019-11-13 02:19:05 Z9 days   15 attempts
Testing same since