All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Pau Monne <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 11/14] xen/x86: parse Dom0 kernel for PVHv2
Date: Tue, 20 Dec 2016 17:34:24 +0000	[thread overview]
Message-ID: <20161220173424.2rjktjci3vsizptj@dhcp-3-221.uk.xensource.com> (raw)
In-Reply-To: <584AF25E02000078001277B6@prv-mh.provo.novell.com>

On Fri, Dec 09, 2016 at 10:05:18AM -0700, Jan Beulich wrote:
> >>> On 30.11.16 at 17:49, <roger.pau@citrix.com> wrote:
> > @@ -1930,12 +1931,148 @@ static int __init hvm_setup_p2m(struct domain *d)
> >  #undef MB1_PAGES
> >  }
> >  
> > +static int __init hvm_copy_to_phys(struct domain *d, paddr_t paddr, void *buf,
> > +                                   int size)
> 
> I guess you made size plain int because hvm_copy_to_guest_phys()
> has it that way, but please let's not spread such bogus things - sizes
> can't possibly be negative.
> 
> > +{
> > +    struct vcpu *saved_current;
> > +    int rc;
> > +
> > +    saved_current = current;
> > +    set_current(d->vcpu[0]);
> > +    rc = hvm_copy_to_guest_phys(paddr, buf, size);
> > +    set_current(saved_current);
> 
> I continue to be uncertain about the behavior of this if something
> inside hvm_copy_to_guest_phys() goes wrong: Did you either
> statically analyze the code or try in practice out whether the
> playing with current makes understanding the crash output any
> harder?

If you managed to somehow call hvm_copy_to_guest_phys with the idle vcpu as
current you would get this kind of error, which I admin is maybe not that
obvious (apart from the IDLEv0 prefix).

(XEN) IDLEv0 Error pfn 21bd: rd=32767 od=32756 caf=180000000000000 taf=0000000000000000

See below.

> While there's going to be some work involved with it, I do think
> that the use here might be a reason for the whole hvm_copy()
> machinery to gain a struct vcpu* parameter.

I've gone that route and added a new param to __hvm_copy, and also introduced
hvm_copy_to_guest_phys_vcpu which takes an additional vcpu parameter. While
there I've also added an assert to __hvm_copy in order to make sure the
vcpu parameter is always a hvm/pvh vcpu.

> > +static int __init hvm_load_kernel(struct domain *d, const module_t *image,
> > +                                  unsigned long image_headroom,
> > +                                  module_t *initrd, char *image_base,
> > +                                  char *cmdline, paddr_t *entry,
> > +                                  paddr_t *start_info_addr)
> > +{
> > +    char *image_start = image_base + image_headroom;
> > +    unsigned long image_len = image->mod_end;
> > +    struct elf_binary elf;
> > +    struct elf_dom_parms parms;
> > +    paddr_t last_addr;
> > +    struct hvm_start_info start_info;
> > +    struct hvm_modlist_entry mod;
> > +    struct vcpu *saved_current, *v = d->vcpu[0];
> > +    int rc;
> > +
> > +    if ( (rc = bzimage_parse(image_base, &image_start, &image_len)) != 0 )
> > +    {
> > +        printk("Error trying to detect bz compressed kernel\n");
> > +        return rc;
> > +    }
> > +
> > +    if ( (rc = elf_init(&elf, image_start, image_len)) != 0 )
> > +    {
> > +        printk("Unable to init ELF\n");
> > +        return rc;
> > +    }
> > +#ifdef VERBOSE
> > +    elf_set_verbose(&elf);
> > +#endif
> > +    elf_parse_binary(&elf);
> > +    if ( (rc = elf_xen_parse(&elf, &parms)) != 0 )
> > +    {
> > +        printk("Unable to parse kernel for ELFNOTES\n");
> > +        return rc;
> > +    }
> > +
> > +    if ( parms.phys_entry == UNSET_ADDR32 ) {
> > +        printk("Unable to find XEN_ELFNOTE_PHYS32_ENTRY address\n");
> > +        return -EINVAL;
> > +    }
> > +
> > +    printk("OS: %s version: %s loader: %s bitness: %s\n", parms.guest_os,
> > +           parms.guest_ver, parms.loader,
> > +           elf_64bit(&elf) ? "64-bit" : "32-bit");
> > +
> > +    /* Copy the OS image and free temporary buffer. */
> > +    elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
> > +    elf.dest_size = parms.virt_kend - parms.virt_kstart;
> > +
> > +    saved_current = current;
> > +    set_current(v);
> > +    rc = elf_load_binary(&elf);
> > +    set_current(saved_current);
> 
> Same reservations as above.

Right, this one however is more tricky to fix since elf_load_binary is shared
with libxc, so adding a vcpu/domain parameter here is problematic for the
toolstack side. That's quite similar to what happens on classic PV Dom0
creation, we need to switch to Dom0 page tables. I'm not trying to use that to
justify that this is the best way, but everything else seems quite convoluted
(either adding a new param to elf_load_binary or a new field to struct
elf_binary in order to store the domain/vcpu).

> > +    if ( rc < 0 )
> > +    {
> > +        printk("Failed to load kernel: %d\n", rc);
> > +        printk("Xen dom0 kernel broken ELF: %s\n", elf_check_broken(&elf));
> > +        return rc;
> > +    }
> > +
> > +    last_addr = ROUNDUP(parms.virt_kend - parms.virt_base, PAGE_SIZE);
> > +
> > +    if ( initrd != NULL )
> > +    {
> > +        rc = hvm_copy_to_phys(d, last_addr, mfn_to_virt(initrd->mod_start),
> > +                              initrd->mod_end);
> > +        if ( rc )
> > +        {
> > +            printk("Unable to copy initrd to guest\n");
> > +            return rc;
> > +        }
> > +
> > +        mod.paddr = last_addr;
> > +        mod.size = initrd->mod_end;
> > +        last_addr += ROUNDUP(initrd->mod_end, PAGE_SIZE);
> > +    }
> 
> mod is left uninitialized in the else case afaict - I don't think all
> compilers we support (plus Coverity) can spot the common
> dependency on initrd != NULL.

Clang doesn't seem to complain, but I will add an initialized to be sure.

Thanks, Roger.

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

  reply	other threads:[~2016-12-20 17:34 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30 16:49 [PATCH v4 00/14] Initial PVHv2 Dom0 support Roger Pau Monne
2016-11-30 16:49 ` [PATCH v4 01/14] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests Roger Pau Monne
2016-12-08 16:21   ` Jan Beulich
2016-12-16 11:24     ` Roger Pau Monne
2016-11-30 16:49 ` [PATCH v4 02/14] xen/x86: fix return value of *_set_allocation functions Roger Pau Monne
2016-11-30 16:49 ` [PATCH v4 03/14] xen/x86: allow calling {shadow/hap}_set_allocation with the idle domain Roger Pau Monne
2016-12-01 11:25   ` Tim Deegan
2016-11-30 16:49 ` [PATCH v4 04/14] x86/paging: introduce paging_set_allocation Roger Pau Monne
2016-11-30 16:49 ` [PATCH v4 05/14] xen/x86: split the setup of Dom0 permissions to a function Roger Pau Monne
2016-11-30 16:49 ` [PATCH v4 06/14] x86/vtd: refuse to enable IOMMU if the PCI scan fails Roger Pau Monne
2016-12-01  0:29   ` Tian, Kevin
2016-11-30 16:49 ` [PATCH v4 07/14] x86/iommu: add IOMMU entries for p2m_mmio_direct pages Roger Pau Monne
2016-12-08 16:24   ` Jan Beulich
2016-12-16 14:01     ` Roger Pau Monne
2016-11-30 16:49 ` [PATCH v4 08/14] xen/x86: allow the emulated APICs to be enabled for the hardware domain Roger Pau Monne
2016-12-08 16:29   ` Jan Beulich
2016-11-30 16:49 ` [PATCH v4 09/14] xen/x86: split Dom0 build into PV and PVHv2 Roger Pau Monne
2016-12-09 16:07   ` Jan Beulich
2016-12-16 14:28     ` Roger Pau Monne
2016-12-16 14:45       ` Roger Pau Monne
2016-12-16 16:17         ` Jan Beulich
2016-12-16 17:57           ` Roger Pau Monne
2016-12-19  7:42             ` Jan Beulich
2016-12-16 15:28       ` Roger Pau Monne
2016-12-16 16:15         ` Jan Beulich
2016-12-16 16:18       ` Jan Beulich
2016-12-16 17:42         ` Roger Pau Monne
2016-12-19  7:41           ` Jan Beulich
2016-11-30 16:49 ` [PATCH v4 10/14] xen/x86: populate PVHv2 Dom0 physical memory map Roger Pau Monne
2016-12-09 16:48   ` Jan Beulich
2016-12-16 17:38     ` Roger Pau Monne
2016-12-19  7:48       ` Jan Beulich
2016-11-30 16:49 ` [PATCH v4 11/14] xen/x86: parse Dom0 kernel for PVHv2 Roger Pau Monne
2016-12-09 17:05   ` Jan Beulich
2016-12-20 17:34     ` Roger Pau Monne [this message]
2016-11-30 16:49 ` [PATCH v4 12/14] x86/PVHv2: fix dom0_max_vcpus so it's capped to 128 for PVHv2 Dom0 Roger Pau Monne
2016-12-09 17:09   ` Jan Beulich
2016-11-30 16:49 ` [PATCH v4 13/14] xen/x86: hack to setup PVHv2 Dom0 CPUs Roger Pau Monne
2016-11-30 16:49 ` [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables Roger Pau Monne
2016-12-12 13:56   ` Jan Beulich
2016-12-21 16:32     ` Roger Pau Monne
2016-12-21 17:04       ` Jan Beulich
2016-12-22 10:43         ` Roger Pau Monne
2016-12-22 11:03           ` Jan Beulich
2016-12-22 12:17             ` Roger Pau Monne
2016-12-22 16:17               ` Boris Ostrovsky
2016-12-22 16:24                 ` Jan Beulich
2016-12-22 16:44                   ` Roger Pau Monne
2016-12-22 18:19                     ` Boris Ostrovsky
2016-12-23 10:27                       ` Roger Pau Monne
2016-12-23 15:13                         ` Boris Ostrovsky
2016-12-23 15:31                           ` Konrad Rzeszutek Wilk
2016-12-23 15:35                             ` Boris Ostrovsky
2016-12-23 16:02                               ` Konrad Rzeszutek Wilk
2016-12-23 17:13                                 ` Boris Ostrovsky
2017-01-03 15:55                                   ` Roger Pau Monne
2017-01-03 19:13                                     ` Boris Ostrovsky
2016-12-23 15:21                         ` Konrad Rzeszutek Wilk
2017-01-03  7:53                       ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161220173424.2rjktjci3vsizptj@dhcp-3-221.uk.xensource.com \
    --to=roger.pau@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.