[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [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@xxxxxxxxxx > [mailto:qemu-devel-bounces+xudong.hao=intel.com@xxxxxxxxxx] On Behalf > Of Ian Campbell > Sent: Wednesday, February 27, 2013 7:07 PM > To: Zhang, Xiantao > Cc: aliguori@xxxxxxxxxx; mst@xxxxxxxxxx; Stefano Stabellini; Hao, Xudong; > qemu-devel@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx; JBeulich@xxxxxxxx; > afaerber@xxxxxxx > 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |