Re: [Xen-devel] x86 Community Call - Wed Aug 15, 14:00 - 15:00 UTC - Minutes

["Zhang, Yu C" <yu.c.zhang@xxxxxxxxx>]

Thanks Lars for the summary, and sorry for the late update.

My question is about the cpuid policy for MAXPHYSADDR in Xen. 

It seems Xen is exposing the host MAXPHYSADDR value to HVM as the default 
choice. And I am wondering, what if a VM is created on a hardware platform with 
address width A, and later migrated to another platform with address width B? 
Should this be allowed in Xen?  

B.R.
Yu

> -----Original Message-----
> From: Lars Kurth [mailto:lars.kurth@xxxxxxxxxx]
> Sent: Thursday, August 16, 2018 5:12 PM
> To: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>; JBeulich@xxxxxxxx; Andrew
> Cooper <Andrew.Cooper3@xxxxxxxxxx>
> Cc: robin.randhawa@xxxxxxx; julien.grall@xxxxxxx;
> davorin.mista@xxxxxxxxxx; tamas.k.lengyel@xxxxxxxxx; jnataraj@xxxxxxx;
> brian.woods@xxxxxxx; sstabellini@xxxxxxxxxx; Matt.Spencer@xxxxxxx;
> daniel.kiper@xxxxxxxxxx; intel-xen <intel-xen@xxxxxxxxx>; jgross@xxxxxxxx;
> Stewart.Hildebrand@xxxxxxxxxxxxxxx; Jarvis.Roach@xxxxxxxxxxxxxxx; Paul
> Durrant <Paul.Durrant@xxxxxxxxxx>; Ji, John <john.ji@xxxxxxxxx>;
> volodymyr_babchuk@xxxxxxxx; Roger Pau Monne <roger.pau@xxxxxxxxxx>;
> mirela.simonovic@xxxxxxxxxx; committers@xxxxxxxxxxxxxx;
> artem_mygaiev@xxxxxxxx; christopher.w.clark@xxxxxxxxx;
> persaur@xxxxxxxxx; vfachin@xxxxxxxxxxxxxx; edgar.iglesias@xxxxxxxxxx;
> anastassios.nanos@xxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] x86 Community Call - Wed Aug 15, 14:00 - 15:00 UTC -
> Minutes
> 
> Live minutes are at
> https://docs.google.com/document/d/1zf9saqOvxAsIDvHPIFpzy56zsUdhu4LcHo
> uQ0Uf2RGw/edit?usp=sharing and a snapshot is attached as PDF Also for
> convenience in markdown Regards Lars
> 
> # Agenda and Minutes: x86 Community Call August
> 
> # 2018
> 
> _No new items were added to the agenda._ ​ _Minutes are added in blue._ 
> _Closed ACTIONS in green._
> 
> ## Attendees
> 
> Artem Mygaiev
> Juergen Gross
> Brian Woods
> Christopher Clark
> Jan Beulich
> Wei, Sergey, Andrew
> Julien Grall
> Rich Persaud
> Zhang, Yu C
> 
> ## 4.10+ changes to Xen's memory scrubbing: Christopher
> 
> Discussion of the changes that made to it in recent versions of Xen (4.10+) -
> Christopher
> 
> Christopher: Asking on behalf of Star Lab who has a use case for ensuring
> scrubbing occurs on shutdown of VMs. Memory scrubbing is also of interest for
> OpenXT. Inspection of code shows it has changes done during 4.10: to defer
> scrubbing of pages to idle loop rather than synchronously during VM shutdown.
> Idle scrubbing may take indefinite amount of time to complete on a busy
> machine.
> 
> Checking: Is scrub only done if VM is explicitly killed?
> What are the right expectations for us re former-VM memory content?
> 
> Andrew: What is in tree is only the 1st half of what was proposed Boris didn’t
> have time to do the second half of the series => XenServer has similar issues
> 
> Should never have a case where we don't scrub incoming RAM (leaving side
> channels aside). Everything handed to a guest is set to 0
> 
> Christopher: with the new code, when you shut down from a VM you have no
> longer been evacuated from the host + speculative side-channel vulnerabilities
> are a concern
> 
> Andrew: we would fix this if we permanently removed directmap => fixes the
> speculative angle => better in the long run
> 
> For very large VMs it can take up to 15 minutes to shut down very large VMs
> 
> Only case when scrubbing does not occur is if a VM releases a page. Citrix has
> removed even that exception in XenServer. Should do that upstream.
> Performance impact will be negligible.
> 
> Christopher: would code to re-introduce optional synchronous scrubbing be
> accepted in upstream?
> 
> Andrew doesn’t think so: but also doesn’t think that eagerly scrubbing will
> actually help as memory can be accessed through side channel ways.
> 
> Jan + Andrew: [discussion of vCPU use]
> 
> Christopher: Important issue is that once the decision is taken to evacuate by
> shutting down the VM, need to have a bounded amount of time for the memory
> to be erased and a verifiable indicator that it is complete. Previous version 
> was
> indicated by the domain no longer being present.
> 
> Andrew: needs some kind of auditable point when memory is not available (and
> some bounded and verifiable point in time). Could put some kind of sync flag 
> in
> kill domain to reinstate previous behaviour in domain destroy or use another
> approach (Jan had some ideas).
> 
> Christopher: agrees that this could be what he is looking for
> 
> **ACTION:** ​ Christopher will follow up on IRC/xen-devel@
> 
> ## Unblocking Series - Jan
> 
> I think we need to talk about how we mean to unblock large chunks of work
> * VMX MSRs policy for Nested Virt: part 1 (I've looked over this, and I think 
> it's
> okay, but I also think that in particular nested stuff wants both maintainers 
> and
> Andrew to look over)
> * vpci: add support for SR-IOV capability
> * paravirtual IOMMU interface
> * x86/domctl: Save info for one vcpu instance
> * SSBD AMD via LS CFG Enablement and not to speak of "add vIOMMU support
> with irq remapping function of virtual VT-d". I'm however myself as well in an
> increasingly awkward position to do / post further work, due to there being
> patch series stalled in part from long before the 4.11 freeze (listing only 
> series
> here, there are also individual stalled patches):
> * x86: improve PDX <-> PFN and alike translations
> * x86: assorted assembly related cleanup
> * x86: indirect call overhead reduction
> * x86/HVM: implement memory read caching
> * x86: more power-efficient CPU parking_
> 
> Series is just a set of examples. Jan feels increasingly blocked by the 
> number of
> series and volume of series. How do we get out of that huge backlog of patches
> that various people have to look at. Jan has not been able to reduce the
> backlog ...
> 
> Andrew: This has been made worse by security work: Andrew is trying to pick up
> rather more review. It would be a useful thing to track the outstanding 
> series -
> some series dont have outstanding actions (or are blocked on others).
> 
> We had issues where: patch is fine, but then has been deferred because XYZ has
> not yet done => but then XYZ had not materialized. ​Jan has some examples: 
> 1st -
> where Jan fixed some boundary cases of error handling.
> 
> Another general problem: affects mostly individual patches when they have
> dependencies to do with rebase.
> 
> General workload: most of x86 series by Jan and Andrew need to be acked by
> each other.
> There has been improvements looking at x86 patches in some areas, but there
> are some areas such as AVX where where others can't help out.
> 
> Andrew also raises the issue of lack of comments from Intel, for serieus that
> cover vendor specific series.
> 
> ACTION: Lars to bring up at AB call
> 
> ## L1 Terminal Fault - Andrew
> 
> Sent out an update mail to xen-devel@: see
> https://lists.xenproject.org/archives/html/xen-devel/2018-08/threads.html#
> 
> We still have a lot of work to do in this area: we could not do these during 
> the
> embargo
> 
> Cannot remove all the cache load gadgets in the Hypervisor Properly undertake
> work such as removing directmap, ...
> 
> Need to start tracking issues related to this in JIRA: may need to sort this 
> into
> different buckets
> 
> **ACTION:** ​ Andrew will have a poke at these => classify correctly or close
> Juergen is OK with using Jira
> 
> David Woodhouse from AWS has some proposal, which he will put out publicly
> 
> There same issues with page table writable in Linux: stop requesting to use it
> from Linux. It is nobbling one of the L feature flags
> 
> **Andrew, Jan, Juergen:** ​ Question of 32 bit Xen support in the kernel: 32 
> bit
> PV guests will get increasingly crippled. If we drop 32 bit support from 
> Linux, we
> should also do this for the hypervisor
> 
> **ACTION:** ​ Juergen will set up an official email to see whether anyone is 
> still
> using 32 bit PV guests. Need to check: netbsd - still have that linear page 
> table
> issues (only reproducible with 32 bit guests) => Other options:
> 1) Declare it security unsupported
> 2) Limit to run inside a shim (need to keep it in the hypervisor), have a 
> config pv
> 32, ...
> 3) Deprecate before removal, then remove
> 
> Pose the question for Linux and others: important aspect is to reach out to 
> users,
> developers are the wrong audience. ​ **Lars to help out**
> 
> ## Project Management stuff to keep the Momentum going
> 
> Did not get to this section
> Zhang: not sure about his colleagues - looking at some other issues and seek
> help.
> 
> This is something where Andrew and and Zhang should talk:
> 
> **ACTION:** ​ Zhang to send a mail explaining the issue, possible set up
> 
> We have made significant progress on design related questions at the developer
> summit.
> Although not all the notes for these have been published (SGX and NVDIMM are
> missing, the former are on my plate). The series, which have been discussed at
> the summit and where I believe that good progress has been made were.
> 
> In other words, we should expect new versions of these series
> 
> ```
> Series Stakeholders
> ```
> ```
> Add vNVDIMM support to HVM domains
> ```
> ```
> As far as I understand a simple and clean way to implement this has been 
> found,
> but the design session notes are still missing ``` ``` We spent almost two 
> days on
> NVDIMM related discussions: we have something that should be fairly simple
> and easy to implement. Dan Williams is happy to take changes into upstream as
> long as they are sensible.
> ```
> ```
> George: the key behind the discussion was to be able to deliver a functional
> solution soon. We can make it nicer incrementally.
> ```
> ```
> Zhang Yi, Intel
> Zhang Yu, Intel
> George Dunlap, Citrix
> ```
> 
> ### ACTION: George will update and re-submit the ​ NVDIMM doc
> 
> _(he didn’t take any notes during the discussion - we are going to have to
> reconstruct some of the discussion)_
> 
> _Andrew: Yi & Yu were taking notes in the meeting_
> 
> _ACTION: Lars to reach out to Yi & Yu and see what they have See
> https://lists.xenproject.org/archives/html/xen-devel/2018-07/thre
> ads.html#_
> 
> Intel Processor Trace virtualization enabling
> 
> _See
> https://www.slideshare.net/xen_com_mgr/xpdds18-intel-proces
> sor-trace-for-xen-hypervisor-luwei-kang-intel_
> 
> _Partly blocked on CPUID & MSR_
> 
> _Discussed the corner cases - these are in a PPT from Intel which Lars is 
> waiting
> for. There was an open question re nested virt and a recognition that both
> cannot co-exist._
> 
> _See
> https://lists.xenproject.org/archives/html/xen-devel/2018-07/thre
> ads.html#_
> 
> ```
> Luwei Kang, Intel
> ```
> Extend resources to support more vcpus in single VM
> 
> _Also depends on the topology work
> IOREQ work needs another iteration
> Virtual IOMMU needs to be done_
> 
> _See
> https://lists.xenproject.org/archives/html/xen-devel/2018-07/thre
> ads.html#_
> 
> ```
> Chao Gao, Intel
> ```
> EPT-Based Sub-page Write Protection Support
> 
> See
> https://www.slideshare.net/xen_com_mgr/xpdds18-eptbased-su
> bpage-write-protection-on-xenc-yi-zhang-intel
> 
> _Intel posted series and doesn’t know what to do next due to lack of feedback.
> We were also lacking a plausible use-case:
> Intel and BitDefender are talking together to clarify the_
> 
> ```
> Zhang Yi, Intel
> ```
> 
> ```
> use-case. Still largely blocked on reviews.
> ```
> ```
> Also see
> https://lists.xenproject.org/archives/html/xen-devel/2018-07/thre
> ads.html#
> ```
> ```
> SGX Virtualization design and draft patches ``` ### Kai sent Lars some notes,
> which are published ​ here ​.
> 
> ```
> Partly blocked on CPUID & MSR
> ```
> ```
> Kai Huang, Intel
> ```
> ```
> 5 Level Paging
> ```
> ```
> XPTI would become very problematic with 5 level paging.
> Currently Intel’s lowest priority.
> ```
> Then there were series which were blocked on CPUID and related work
> 
> ```
> Series Stakeholders
> ```
> ### Add guest CPU topology support
> 
> ```
> [PATCH 00/13] x86: CPUID and MSR policy marshalling ``` ### support ​has been
> posted on which this series depends on, but it
> 
> ```
> is only covering ⅓ of the needed patches and requires some fixes. Sergey is
> working on the libxc side and Andrew on the hypervisor auditing/checking.
> Roger is working on topology support, which depends on the other three pieces.
> ```
> ```
> Zhang Yi, Intel
> ```
> ```
> Andrew Cooper, Citrix
> Sergey Dyasli, Citrix
> Roger Pau Monne,
> Citrix
> ```
> And other series, which are moving forward
> 
> ```
> Series Stakeholders
> ```
> ### paravirtual IOMMU interface
> ### v2 posted recently
> 
> ```
> Paul Durrant, Citrix
> ```
> ### x86/cpuid: enable new cpu features
> 
> ### Waiting for v
> 
> ```
> Yang Zhong, Intel
> ```
> 
> ### add vIOMMU support with irq remapping function of virtual
> 
> ### VT-d
> 
> ### Waiting for v
> 
> ```
> Chao Gao, Intel
> ```
> ### AMD Avic Series
> 
> ### Waiting for v
> 
> ```
> Janakarajan Natarajan,
> AMD
> ```
> ### MSR Spec Support for AMD speculative store bypass
> 
> ### mitigations
> 
> _Work has just started_
> 
> ```
> Brian Woods, AMD
> ```
> ### Dom B
> 
> _Waiting for Christopher’s reply_
> 
> ```
> Christopher Clark,
> OpenXT
> ```
> ### XSM
> 
> Daniel De Graf on sabbatical - not sure for how long
> 
> ACTION: Rich to follow up with committers@xxxxxxxxxxxxxx
> 
> 
> 
> 
> 
> 

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