From: Jordan Justen <jljusten@gmail.com>
To: Kevin Wolf <kwolf@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Anthony Liguori <aliguori@us.ibm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>,
qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v9 3/3] pc: Support system flash memory with pflash
Date: Sat, 28 Jan 2012 15:13:14 -0800 [thread overview]
Message-ID: <CAFe8ug9G1sdnzRLivedeonyjEjsibDVQhLa55sW_tZAFNh5Mzg@mail.gmail.com> (raw)
In-Reply-To: <4F0AB32B.7090608@redhat.com>
On Mon, Jan 9, 2012 at 01:28, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 19.12.2011 23:19, schrieb Anthony Liguori:
>> On 12/19/2011 03:25 PM, Jordan Justen wrote:
>>> On Mon, Dec 19, 2011 at 11:41, Anthony Liguori<aliguori@us.ibm.com> wrote:
>>>> On 12/15/2011 02:51 PM, Jordan Justen wrote:
>>>>> +static void pc_system_rom_init(MemoryRegion *rom_memory,
>>>>> + DriveInfo *pflash_drv)
>>>>> +{
>>>>> + BlockDriverState *bdrv;
>>>>> + int64_t size;
>>>>> + target_phys_addr_t phys_addr;
>>>>> + int sector_bits, sector_size;
>>>>> + MemoryRegion *sys_rom;
>>>>> + void *buffer;
>>>>> + int ret;
>>>>> +
>>>>> + bdrv = pflash_drv->bdrv;
>>>>> + size = bdrv_getlength(pflash_drv->bdrv);
>>>>> + sector_bits = 9;
>>>>> + sector_size = 1<< sector_bits;
>>>>> +
>>>>> + if ((size % sector_size) != 0) {
>>>>> + fprintf(stderr,
>>>>> + "qemu: PC system rom (pflash) must be a multiple of
>>>>> 0x%x\n",
>>>>> + sector_size);
>>>>> + exit(1);
>>>>> + }
>>>>> +
>>>>> + phys_addr = 0x100000000ULL - size;
>>>>> + sys_rom = g_malloc(sizeof(*sys_rom));
>>>>> + memory_region_init_ram(sys_rom, NULL, "system.rom", size);
>>>>> + buffer = memory_region_get_ram_ptr(sys_rom);
>>>>> + memory_region_add_subregion(rom_memory, phys_addr, sys_rom);
>>>>> +
>>>>> + /* read the rom content */
>>>>> + ret = bdrv_read(bdrv, 0, buffer, size>> sector_bits);
>>>>
>>>>
>>>> I think we're trying to get rid of synchronous block I/O in machine
>>>> initialization for a number of reasons.
>>>>
>>>> Kevin/Stefan, care to comment? Will this be problematic in the future?
>>>
>>> I was hoping pc-1.1 with and without kvm could be as close as
>>> possible, but I guess I can make pc-1.1 with kvm behave the same as
>>> pc-1.0. Then I can delete pc_system_rom_init.
>>
>> I think your general approach is right, I'm just not sure what we're going to do
>> short term about synchronous I/O in the machine init routines. It may just be a
>> matter of structuring this in such a way that you can use an async interface.
>
> I don't think there is a problem with using the synchronous interface
> here. But I'm not sure if having any I/O in the machine init is a good
> idea with respect to migration. Didn't we already have to move some code
> there to a later stage to make sure that the destination doesn't use
> outdated data?
The pc_system_rom_init function is only used when kvm is enabled.
Since kvm cannot currently execute code from device memory, we have to
create a ram region, and transfer the pflash contents into the ram
region.
Instead of bdrv_read, should I get the pflash memory region buffer,
and use memcpy? Or, would still suffer from the same issue of getting
outdated data?
Thanks,
-Jordan
next prev parent reply other threads:[~2012-01-28 23:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 20:51 [Qemu-devel] [PATCH v9 0/3] PC system flash support Jordan Justen
2011-12-15 20:51 ` [Qemu-devel] [PATCH v9 1/3] pc: Add pc-1.1 machine type Jordan Justen
2011-12-15 20:51 ` [Qemu-devel] [PATCH v9 2/3] pflash: Support read-only mode Jordan Justen
2011-12-15 20:51 ` [Qemu-devel] [PATCH v9 3/3] pc: Support system flash memory with pflash Jordan Justen
2011-12-19 19:41 ` Anthony Liguori
2011-12-19 21:25 ` Jordan Justen
2011-12-19 22:19 ` Anthony Liguori
2012-01-09 9:28 ` Kevin Wolf
2012-01-28 23:13 ` Jordan Justen [this message]
2012-02-20 0:39 ` Jordan Justen
2011-12-20 8:11 ` Stefan Hajnoczi
2011-12-15 21:02 ` [Qemu-devel] [PATCH v9 0/3] PC system flash support Jordan Justen
2011-12-18 10:04 ` Avi Kivity
2011-12-19 18:27 ` Jordan Justen
2011-12-20 10:53 ` 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=CAFe8ug9G1sdnzRLivedeonyjEjsibDVQhLa55sW_tZAFNh5Mzg@mail.gmail.com \
--to=jljusten@gmail.com \
--cc=aliguori@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=jordan.l.justen@intel.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).