Re: [RFC PATCH 00/15] RFC: SGX virtualization design and draft patches

[Wei Liu <wei.liu2@citrix.com>]

On Tue, Jul 18, 2017 at 08:22:55PM +1200, Huang, Kai wrote:
> Hi Wei,
> 
> Thank you very much for comments. Please see my reply below.
> 
> On 7/17/2017 9:16 PM, Wei Liu wrote:
> > Hi Kai
> > 
> > Thanks for this nice write-up.
> > 
> > Some comments and questions below.
> > 
> > On Sun, Jul 09, 2017 at 08:03:10PM +1200, Kai Huang wrote:
> > > Hi all,
> > > 
> > [...]
> > > 2. SGX Virtualization Design
> > > 
> > > 2.1 High Level Toolstack Changes:
> > > 
> > > 2.1.1 New 'epc' parameter
> > > 
> > > EPC is limited resource. In order to use EPC efficiently among all domains,
> > > when creating guest, administrator should be able to specify domain's virtual
> > > EPC size. And admin
> > > alao should be able to get all domain's virtual EPC size.
> > > 
> > > For this purpose, a new 'epc = <size>' parameter is added to XL configuration
> > > file. This parameter specifies guest's virtual EPC size. The EPC base address
> > > will be calculated by toolstack internally, according to guest's memory size,
> > > MMIO size, etc. 'epc' is MB in unit and any 1MB aligned value will be accepted.
> > > 
> > > 2.1.2 New XL commands (?)
> > > 
> > > Administrator should be able to get physical EPC size, and all domain's virtual
> > > EPC size. For this purpose, we can introduce 2 additional commands:
> > > 
> > >      # xl sgxinfo
> > > 
> > > Which will print out physical EPC size, and other SGX info (such as SGX1, SGX2,
> > > etc) if necessary.
> > > 
> > >      # xl sgxlist <did>
> > > 
> > > Which will print out particular domain's virtual EPC size, or list all virtual
> > > EPC sizes for all supported domains.
> > > 
> > > Alternatively, we can also extend existing XL commands by adding new option
> > > 
> > >      # xl info -sgx
> > > 
> > > Which will print out physical EPC size along with other physinfo. And
> > > 
> > >      # xl list <did> -sgx
> > > 
> > > Which will print out domain's virtual EPC size.
> > > 
> > > Comments?
> > > 
> > 
> > Can a guest have multiple EPC? If so, the proposed parameter is not good
> > enough.
> 
> According to SDM a machine may have multiple EPC, but it may have doesn't
> mean it must have. EPC is typically reserved by BIOS as Processor Reserved
> Memory (PRM), and in my understanding, client machine  doesn't need to have
> multiple EPC. Currently, I don't see why we need to expose multiple EPC to
> guest. Even physical machine reports multiple EPC, exposing one EPC to guest
> is enough. Currently SGX should not be supported with virtual NUMA
> simultaneously for a single domain.
> 

When you say "is enough", do you mean Intel doesn't recommend users to
use more than one? I don't think from reading this doc precludes using
more then one technically.

> > 
> > Can a guest with EPC enabled be migrated? The answer to this question
> > can lead to multiple other questions.
> 
> See the last section of my design. I saw you've already seen it. :)
> 
> > 
> > Another question, is EPC going to be backed by normal memory? This is
> > related to memory accounting of the guest.
> 
> Although SDM says typically EPC is allocated by BIOS as PRM, but I think we
> can just treat EPC as PRM, so I believe yes, physically EPC is backed by
> normal memory. But EPC is reported as reserved memory in e820 table.
> 
> > 
> > Is EPC going to be modeled as a device or another type of memory? This
> > is related to how we manage it in the toolstack.
> 
> I think we'd better to treat EPC as another type of memory. I am not sure
> whether it should be modeled as device, as on real machine, EPC is also
> exposed in ACPI table via "INT0E0C" device under \_SB (however it is not
> modeled as PCIE device for sure).
> 
> > 
> > Finally why do you not allow the users to specify the base address?
> 
> I don't see any reason why user needs to specify base address. If we do,
> then specify what address? On real machine, BIOS set the base address, and
> for VM, I think toolstack/Xen should do this.

We can expose an option for user to control that if they want to and at
the same time provide the logic to calculate the base address
internally. I'm not sure if that's going to be very useful, but I'm not
convinced it is entirely useless either.

Thinking a bit more we can always extend the syntax and API to support
that if need be, so I'm fine with not providing such mechanism at early
stage.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel