Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Wed, 3 Oct 2012 12:58:22 +0100
Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:

> On Wed, 3 Oct 2012, Mukesh Rathor wrote:
> > On Tue, 2 Oct 2012 18:36:19 -0700
> > Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> > 
> > > On Wed, 26 Sep 2012 12:33:39 +0100
> 
> 
> > So for now, how about, lets go
> > with what I've got. I'll make a note, and when I do xen patch, I'll
> > figure it out, and would be a very small linux patch. I want to get
> > linux patch in soon before the window closes.
> 
> We can leave page special as it is for now with very little
> consequences, because it is not part of the interface with Xen.
> However this is part of the interface, so whatever we choose here is
> going to be hard to change later on.
> 
> I think it would be good if we could either make dom0 use a pfn or
> domU use mfn, whatever is easier for you.

Ok, finally, focussing on this, the issue with pfn in dom0 is that
I need pfn allocated in construct_dom0() and be mapped so that the
guest can just do :

HYPERVISOR_shared_info=(struct shared_info *)__va(xen_start_info->shared_info);

How about following I am experimenting with right now:

in construct_dom0():

    vstartinfo_end   = (vstartinfo_start +
                        sizeof(struct start_info) +
                        sizeof(struct dom0_vga_console_info));

    if ( is_hybrid_domain(d) ) {
        start_info_pfn_addr = round_pgup(vstartinfo_end) - v_start;
        vstartinfo_end   += PAGE_SIZE;
    }

I can then put (PFN: start_info_pfn_addr)->(MFN: virt_to_maddr(d->shared_info))
in the p2m, and dom0 just has to do __va(), like domU does now.  I wont' need
to special case dom0 then.

Do you foresee any problems with this approach?

thanks
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel