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

[Eric Shelton <eshelton@xxxxxxxxx>]

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.

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