public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Nolan <nolan@sigbus.net>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] fix extboot from boot with cache=off
Date: Thu, 19 Mar 2009 12:03:12 +0200	[thread overview]
Message-ID: <49C21860.50302@redhat.com> (raw)
In-Reply-To: <1237258333.15350.62.camel@voxel>

Nolan wrote:
> Extboot submits requests with whatever buffer alignment the guest gave
> to the BIOS.  This breaks with O_DIRECT disks, as they require 512 byte
> alignment.
>
> Most guest bootloaders sector align their requests out of paranoia, but
> the OpenBSD bootloader does not.
>
> This patch always copies.  Since extboot is only used at boot time to
> load limited amounts of data, the overhead is not problematic.  I also
> switched to using cpu_physical_memory_* instead of groveling around with
> phys_ram_base directly.
>
> Signed-off-by: Nolan Leake <nolan <at> sigbus.net>
>
> ---
>
>  qemu/hw/extboot.c |   35 ++++++++++++++++++++++++-----------
>  1 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/qemu/hw/extboot.c b/qemu/hw/extboot.c
> index ada0fdd..ea16b3e 100644
> --- a/qemu/hw/extboot.c
> +++ b/qemu/hw/extboot.c
> @@ -77,19 +77,29 @@ static void extboot_write_cmd(void *opaque, uint32_t addr, uint32_t value)
>      BlockDriverState *bs = opaque;
>      int cylinders, heads, sectors, err;
>      uint64_t nb_sectors;
> -
> -    get_translated_chs(bs, &cylinders, &heads, &sectors);
> +    target_phys_addr_t pa;
> +    int blen;
> +    void *buf = NULL;
>  
>      if (cmd->type == 0x01 || cmd->type == 0x02) {
> -	target_ulong pa = cmd->xfer.segment * 16 + cmd->xfer.segment;
> +	pa = cmd->xfer.segment * 16 + cmd->xfer.offset;
> +        blen = cmd->xfer.nb_sectors * 512;
> +        buf = qemu_memalign(512, blen);
> +        if (!buf) {
> +            printf("qemu_memalign failed\n");
> +            return;
> +        }
>   

Don't check for allocation failures.  qemu_malloc() terminates 
gracefully on failure, qemu_memalign() does not, but should.

>  
>  	/* possible buffer overflow */
> -	if ((pa + cmd->xfer.nb_sectors * 512) > phys_ram_size)
> +	if ((pa + blen) > phys_ram_size) {
> +            qemu_free(buf);
>  	    return;
> +        }
>   

cpu_physical_memory_rw() will check these for you.

All in all, a nice improvement in addition to the bug fix.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2009-03-19 10:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17  2:52 [PATCH] fix extboot from boot with cache=off Nolan
2009-03-19 10:03 ` Avi Kivity [this message]
2009-03-20  0:02   ` Nolan
2009-03-22  9:14     ` Avi Kivity

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=49C21860.50302@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=nolan@sigbus.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox