From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xu, Quan" Subject: FW: FW: [PATCH 1/6] vTPM: event channel bind interdomain with para/hvm virtual machine Date: Fri, 31 Oct 2014 02:06:46 +0000 Message-ID: <945CA011AD5F084CBEA3E851C0AB28890E81D298@SHSMSX101.ccr.corp.intel.com> References: <1414654731-32641-1-git-send-email-quan.xu@intel.com> <1414654731-32641-2-git-send-email-quan.xu@intel.com> <945CA011AD5F084CBEA3E851C0AB28890E81D119@SHSMSX101.ccr.corp.intel.com> <54528379.5080107@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54528379.5080107@tycho.nsa.gov> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel De Graaf Cc: "samuel.thibault@ens-lyon.org" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Forward to mail list. Thanks for your comment, I will read it in detail and try out some of your suggestions. Quan > -----Original Message----- > From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov] > Sent: Friday, October 31, 2014 2:29 AM > To: Xu, Quan > Cc: samuel.thibault@ens-lyon.org > Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with > para/hvm virtual machine > > On 10/30/2014 11:06 AM, Xu, Quan wrote: > [...] > >> + domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid; > > This seems to preclude the use of stub domain device models for HVM domains; > in that case, the event channel/grant page would need to be mapped to the stub > domain. I think it may be better to pass in the target domain ID in xenstore > rather than overriding it based on PV vs HVM. In any case, in order to support > HVM domains with PV drivers, an additional backend/frontend pair is required > for QEMU rather than redirecting the existing vTPM to the device model's > domain. > > I would suggest attaching the vTPM directly to domain 0, but that would cause > the vTPM to be picked up by the dom0 kernel instead of by QEMU, so that is not > helpful. If there is an existing solution for disk or network driver domains > attached to HVM, the solution used there should be mirrored here; I have not > looked to see how (or if) it is solved in those drivers. > > A solution needs to be able to handle: > > 1. Existing PV domains > 2. HVM domain using TIS MMIO and no stubdom - without special casing dom0 3. > HVM domain using TIS MMIO via a stubdom 4. Linux HVM domain with the PV > vTPM driver (talks directly to the vTPM) > > Similar to network and disk, when an OS that understands Xen devices finds a > vTPM interface, it should detach/ignore the MMIO TPM interface. > The vTPM domain is set up to handle this case: multiple connections to a single > vTPM domain are permitted and will all talk to the same TPM instance. Locality > restrictions are based on the event channel endpoint, and so will still work even > when tpmif->domid is incorrect; this is required to properly implement the DRTM > if it is to be emulated. > > -- > Daniel De Graaf > National Security Agency