Re: [Xen-devel] [RFC 2/7] linux-stubdomain: Compile Linux

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 6 Feb 2015, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 10:51 AM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Tue, 3 Feb 2015, Eric Shelton wrote:
> >> This patch adds rules to the Makefile to retrieve Linux and build a
> >> minimal kernel for the stubdomain.  Using Linux kernel 3.17.8.
> >>
> >> In order to work as a stubdomain, two patches are applied to the Linux
> >> kernel source.
> >
> > Similarly to QEMU, we should get the changes upstream in Linux.
> > Failing that we could use a Linux tree on xenbits instead of a stable
> > kernel release and apply and needed workarounds there.
> 
> Sounds good - if anything remains to be patched at all.  As you
> mentioned, one of the two patches is already upstreamed in 3.18, and
> perhaps the other is no longer needed.  I simply used the same kernel
> version I was using for dom0 (earlier I ran into unknown problems with
> 3.18 for dom0).  I will give a newer, and unpatched, kernel a try for
> stubdom.
> 
> >> +diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> >> +index 682210d..032add4 100644
> >> +--- a/drivers/tty/hvc/hvc_xen.c
> >> ++++ b/drivers/tty/hvc/hvc_xen.c
> >> +@@ -402,9 +402,6 @@ static int xencons_connect_backend(struct 
> >> xenbus_device *dev,
> >> +                         evtchn);
> >> +     if (ret)
> >> +             goto error_xenbus;
> >> +-    ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
> >> +-    if (ret)
> >> +-            goto error_xenbus;
> >> +     ret = xenbus_transaction_end(xbt, 0);
> >> +     if (ret) {
> >> +             if (ret == -EAGAIN)
> >
> > I think that this is already upstream
> 
> Indeed, you are correct, but not until 3.18.  I will have to move to a
> newer kernel.
> 
> >> +diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> >> +index 69f5857..999fc82 100644
> >> +--- a/arch/x86/xen/mmu.c
> >> ++++ b/arch/x86/xen/mmu.c
> >> +@@ -2606,7 +2606,20 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, 
> >> pgtable_t token,
> >> +                              unsigned long addr, void *data)
> >> + {
> >> +     struct remap_data *rmd = data;
> >> +-    pte_t pte = pte_mkspecial(mfn_pte(rmd->mfn++, rmd->prot));
> >> ++
> >> ++    /* Use the native_make_pte function because we are sure we don't
> >> ++     * have to do any pfn->mfn translations but at the same time we
> >> ++     * could in a stubdom so xen_initial_domain() would return false. */
> >> ++    pte_t pte = pte_mkspecial(native_make_pte(((phys_addr_t)(rmd->mfn++) 
> >> << PAGE_SHIFT)
> >> ++                                              | 
> >> massage_pgprot(rmd->prot)));
> >> ++    pteval_t val = pte_val_ma(pte);
> >> ++
> >> ++#if 0
> >> ++    if (pat_enabled && !WARN_ON(val & _PAGE_PAT)) {
> >> ++            if ((val & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
> >> ++                    val = (val & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
> >> ++    }
> >> ++#endif
> >
> > I don't think you need this change anymore with a more recent kernel.
> > In any case, a proper fix for this issue would certainly be welcome
> > upstream in Linux.
> 
> I will see how it goes.
> 
> >> +LINUX_URL=ftp://ftp.kernel.org/pub/linux/kernel/v3.x/$(LINUX_V).tar.xz
> >> +
> >> +all: $(VMLINUZ)
> >
> > I think it is best if we git clone it.
> 
> Is that still true if unpatched 3.18.6 works?  I don't know if there
> is a desire to reduce load on kernel.org, for example.

That's a good point. I think git clone would be more inline with any
other external project that we use.  However I'll let the other
maintainers decide on this.


> >> +++ b/stubdom-linux/stubdom-linux-config-64b
> >> @@ -0,0 +1,1510 @@
> >> +#
> >> +# Automatically generated file; DO NOT EDIT.
> >> +# Linux/x86 3.17.8 Kernel Configuration
> >
> > Where does it come from?
> > Is it the defconfig?
> 
> I took the 3.10 .config used in Anthony's original patches and ran a
> 'make oldconfig', and maybe tweaked one or two configs along the way.
> I imagine the config can be pared down further by more experienced
> eyes.
> 
> - Eric
> 

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