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

Re: [Xen-ia64-devel] [PATCH] fix vtlb flush



Isaku Yamahata writes:
> Could you try the attached patches?

I tried. They works well. The warning disappears.

> They suppress warnings on the console, but
> qemu-dm complains in the log file as
> 
> > xen_platform: unable to change ro/rw state of ROM memory area!
> 
> qemu-dm doesn't stop at that error, and go further normaly.
> I think this warning is surely correct and I prefer to leave it as is.

Agreed, I think this is fine.

Thanks,
Kouya


> 
> On Wed, Aug 13, 2008 at 04:56:59PM +0900, Isaku Yamahata wrote:
> > On Wed, Aug 13, 2008 at 03:44:50PM +0900, Kouya Shimura wrote:
> > > Isaku Yamahata writes:
> > > > Are you planning to send another patches
> > > > which should be included in the 3.3 release?
> > > > (of course it would depend on test resuts...)
> > > 
> > > I'm slight uneasy about the following dom0's dmesg.
> > > "xencomm_privcmd_hvm_op: unknown HVMOP 8"
> > > 
> > > Shoud we implement HVMOP_set_mem_type?
> > > There seems to be no problem without it, though.
> > 
> > I suppose there is no urgent need for it now.
> > On x86, it's used only by guest bios to protect virtual rom area
> > from guest.
> > For the 3.3 release it would be reasonable to implement
> > xencomm routine in dom0, and -ENOSYS in xen vmm.
> > (or if qemu complains, returning 0 doing nothing as work around)
> > 
> > I can think of some ia64 specific regions which should be
> > protected from guest, but not very urgent.
> > The xen/ia64 already has similar fanctionality internally,
> > ASSIGN_readonly. So I guess it's not much work to implement it.
> > 
> 
> -- 
> yamahata

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

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