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
|
Home