[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |