Xen devel - Mar 2013 - Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the base of PCI

> -----Original Message-----
> From: qemu-devel-bounces+xudong.hao=intel.com@nongnu.org
> [mailto:qemu-devel-bounces+xudong.hao=intel.com@nongnu.org] On Behalf
> Of Ian Campbell
> Sent: Wednesday, February 27, 2013 7:07 PM
> To: Zhang, Xiantao
> Cc: aliguori@us.ibm.com; mst@redhat.com; Stefano Stabellini; Hao, Xudong;
> qemu-devel@nongnu.org; xen-devel@lists.xen.org; JBeulich@suse.com;
> afaerber@suse.de
> Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report
the
> base of PCI
> 
> I''m not sure about qemu-devel but on xen-devel the policy is not
to top
> post so please could you avoid doping so.
> 
> On Wed, 2013-02-27 at 09:49 +0000, Zhang, Xiantao wrote:
> > > Given that Xen has at least two other mechanisms (xenstore and
> > > hvmparams) for passing this sort of information around
I''m not sure why
> > > hacking the emulated i440fx device should be the preferred
option.
> >
> > Actually, even in hardware,  I believe there are many registers which
> > are implemented with write-once attributes, and they are only used by
> > firmware and reserved for OS.
> 
> The i440fx does not have this register (be it write once or otherwise),
> which is my actual point -- you are adding a magic property to the
> emulation of this device which the real hardware doesn''t have. 
Sorry to response later.
But why faking a register that the real hardware doesn''t have is not
acceptant? I440fx device don''t need this register for native
environment, but for virtualization, adding such a register can simplify things.
> It isn''t
> really relevant that other hardware could implement write once
> registers, that''s obviously the case.
> 
> > In addition,  with this change,  it can benefit all VMMs (not just
> > Xen) which use Qemu as device model.  If adopt xenstore way, perhaps
> > other VMMs also have to write similar and duplicate logic for the same
> > purpose.
> 
> Which other VMM? AIUI qemu/kvm doesn''t have a requirement to
> communicate
> this information from the VMM to qemu because qemu is the VMM and
> controls all of the hardware resources.
> 
I think our changes have better compatibility, we can''t predict qemu
will not be used for other VMMs, although changes only benefit xen till now.