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, §ors);
> + 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
next prev parent 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