qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the ba


From: Hao, Xudong
Subject: Re: [Qemu-devel] [PATCH v2] piix: define a TOM register to report the base of PCI
Date: Mon, 18 Mar 2013 15:25:37 +0000

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf
> Of Ian Campbell
> Sent: Wednesday, February 27, 2013 7:07 PM
> To: Zhang, Xiantao
> Cc: address@hidden; address@hidden; Stefano Stabellini; Hao, Xudong;
> address@hidden; address@hidden; address@hidden;
> address@hidden
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]