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

Re: [Xen-devel] [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver




> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> Sent: Thursday, November 06, 2014 11:42 PM
> To: Xu, Quan
> Cc: Stefano Stabellini; qemu-devel@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> Subject: RE: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> frontend driver
> 
> On Thu, 6 Nov 2014, Xu, Quan wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@xxxxxxxxxxxxx]
> > > Sent: Monday, November 03, 2014 7:54 PM
> > > To: Xu, Quan
> > > Cc: qemu-devel@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx;
> > > stefano.stabellini@xxxxxxxxxxxxx
> > > Subject: Re: [PATCH 2/4] Qemu-Xen-vTPM: Register Xen stubdom vTPM
> > > frontend driver
> > >
> > > On Sun, 2 Nov 2014, Quan Xu wrote:
> > > > This drvier transfers any request/repond between TPM xenstubdoms
> > > > driver and Xen vTPM stubdom, and facilitates communications
> > > > between Xen vTPM stubdom domain and vTPM xenstubdoms driver
> > > >
> > > > Signed-off-by: Quan Xu <quan.xu@xxxxxxxxx>
> > >
> > > Please describe what changes did make to xen_backend.c and why.
> > > The commit message should contains info on all the changes made by
> > > the patch below.
> > >
> >
> > The following is code process when Qemu is running with Xen.
> > ##code process
> > [...]
> >  xen_hvm_init()
> >     -->xen_be_register()
> >         -->xenstore_scan()
> >             -->xen_be_check_state()
> >
> >     -->xen_vtpm_register()
> >
> > ideally, I can register 'vtpm' via xen_vtpm_register() as
> >
> > + xen_be_register("console", &xen_console_ops);
> > + xen_be_register("vkbd", &xen_kbdmouse_ops); xen_be_register("qdisk",
> > + &xen_blkdev_ops);
> >
> > but there are 2 reasons why I add xen_vtpm_register(), instead of
> > xen_be_register().
> >
> > 1. The backend of TPM is runing in a Xen stubDom, not Domain 0.
> > some functions are not working, for example 'setup watch' and 'look
> > for backend' in xenstore_scan()
> >
> > 2. there is a thread runing in Xen stubDom [event_thread()], it will
> > handle backend status when the frontend is initialized. It is not
> > compatible with xen_be_check_state(). xen_be_check_state() always
> > tries to modify the status of backend.
> >
> > as there is always a tradeoff, if I force to integrate this case into
> > xen_be_register(), there are maybe a lot of 'if ... else.. '. It will
> > break the code architecture. Also I should leverage existing source
> > code with minimum modifcation. i add 'DEVOPS_FLAG_STUBDOM_BE' flag
> in
> > include/hw/xen/xen_backend.h to indicate that device backend is Xen
> > stubDom.
> 
> Given that xen_vtpm_register is actually registering a frontend, not a
> backend, you cannot use xen_be_register for it.
> 
> However instead of introducing xen_vtpm_register, I think you should be
> adding a generic xen_fe_register function that handle any Xen PV frontend
> registration. It should also be able to handle backends not in Dom0. Then you
> can call:
> 
> xen_fe_register("console", &xen_vtpm_ops);

  xen_fe_register("vtpm", &xen_vtpm_ops); ?

A good solution, I will try to add a generic xen_fe_register function that 
handle any Xen PV frontend in v2.


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


 


Rackspace

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