[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Wei,

Thanks for your comments. Please see my reply below.

On 7/29/2017 1:40 AM, Wei Liu wrote:
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.


Can a guest have multiple EPC? If so, the proposed parameter is not good

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.

No I don't think Intel would make such recommendation. For real hardware yes it's possible there are multiple EPC sections, but for client or single socket server machine, typically there will be only one EPC. In case of VM, I don't see there's any benefit of exposing multiple EPCs to guest, except the vNUMA case. My thinking is although SDM doesn't preclude using more than one EPC but for VM there's no need to use more than one.

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

Yeah I think we can extend if needed in the future. Thanks Wei.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.