From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Hanweidong <hanweidong@huawei.com>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH] libxl, hvmloader: Don't relocate memory for MMIO hole
Date: Tue, 18 Jun 2013 10:50:15 +0100 [thread overview]
Message-ID: <51C02D57.4060601@eu.citrix.com> (raw)
In-Reply-To: <20927.17485.615792.812108@mariner.uk.xensource.com>
On 06/17/2013 06:15 PM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH] libxl,hvmloader: Don't relocate memory for MMIO hole"):
>> At the moment, qemu-xen can't handle memory being relocated by
>> hvmloader. This may happen if a device with a large enough memory
>> region is passed through to the guest. At the moment, if this
>> happens, then at some point in the future qemu will crash and the
>> domain will hang. (qemu-traditional is fine.)
>
> I think the approach is good. Arguably the two things should be in
> two patches.
You mean one in libxl to set allow_memory_relocate, one to do something
about it?
>
>> + const char *s;
>> + uint8_t allow_memory_relocate=1;
>> +
>> + s = xenstore_read(HVM_XS_ALLOW_MEMORY_RELOCATE, NULL);
>> + if (s)
>> + allow_memory_relocate=(uint8_t)strtoll(s, NULL, 0);
>
> Use strtoul, surely, and bool_t (or _Bool). Then there is no need for
> the cast. (Also, spaces round `='.)
Remember that hvmloader doesn't actually have a libc; this is a locally
implemented function, and AFAICT the only one implemented is strtoll.
>
>> + printf("allow_memory_relocate %u\n",
>> + __func__, allow_memory_relocate);
>
> Missing %s argument. This shows that -Wformat isn't working.
No, my bad -- I had a script which I thought was compiling all the
tools, but in fact was *only* compiling libxl/xl. -Wformat is indeed
working.
>
>> - while ( (mmio_total > (pci_mem_end - pci_mem_start)) &&
>> - ((pci_mem_start << 1) != 0) )
>> + /*
>> + * At the moment qemu-xen can't deal with relocated memory regions.
>> + * It's too close to the release to make a proper fix; for now,
>> + * if we're using qemu-xen, just crash and tell people to switch
>> + * to qemu-traditional.
>> + */
>> + while ((mmio_total > (pci_mem_end - pci_mem_start))
>> + && ((pci_mem_start << 1) != 0)
>> + && ( allow_memory_relocate
>
> I think this is an unnecessarily confusing way of writing it.
> allow_memory_relocate does not change. I would lift it out of the
> loop into an if. That would also mean that "git-diff -b" can show
> more clearly whether the change is truly what you intend.
But the behavior we want is this:
* If allow_memory_relocate, increase the size of the memory hole until
it's big enough, or it reaches 2GiB
* If !allow_memory_relocate, increase the size of the memory hole until
it's big enough, or it reaches 2GiB, or it overlaps guest memory.
If we pulled "allow_memory_relocate" out, we'd have to make two separate
while() loops. That might make it more clear what was going on, but
would risk introducing errors between the two copies for the other
conditions.
>
>> + || (((pci_mem_start << 1)>>PAGE_SHIFT )<hvm_info->low_mem_pgend))
>> pci_mem_start <<= 1;
>>
>> - if ( (pci_mem_start << 1) != 0 )
>> + if (mmio_total > (pci_mem_end - pci_mem_start))
>> bar64_relocate = 1;
>
> Missing spaces.
>
>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index ac1f90e..5167ee0 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -1154,6 +1154,13 @@ void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
>> libxl__xs_write(gc, XBT_NULL,
>> libxl__sprintf(gc, "%s/hvmloader/bios", path),
>> "%s", libxl_bios_type_to_string(b_info->u.hvm.bios));
>> + /* Disable relocating memory to make the MMIO hole larger unless we'
> re
>> + * running qemu-traditional */
>
> This whole hunk could do with more aggressive wrapping. See what it
> looks like in my MUA. Can you keep it down to 70-75 columns ?
Sure.
>
>> + libxl__xs_write(gc, XBT_NULL,
>> + libxl__sprintf(gc, "%s/hvmloader/allow-memory-reloca
> te", path),
>> + "%s",
>> + (b_info->device_model_version==LIBXL_DEVICE_MODEL_VE
> RSION_QEMU_XEN_TRADITIONAL)?
>> + "1":"0");
>> free(path);
>
> Use GCSPRINTF not libxl_sprintf. Lacks error check (check return
> value from libxl__xs_write).
Once again, I disagree with mixing different code styles in the same
function. Using GCSPRINTF and doing an error check here will make it
seem like it's doing something different than the line immediately above
it (which is what I copied to get here), which will confuse people.
In theory the "fix it up as we go along" sounds good, but in practice
it's awful. How many times have you had to say exactly this kind of
thing, when all I did was copy some bit of code that was nearby and do
exactly the same thing? It just annoys you and frustrates me.
I shouldn't have to keep in my head, "This is the new way of doing
things". It's a total waste of mental energy; I have better things to
spend my brain capacity on. If you want things to change, I think we're
going to have to have a "flag day" where we go through and change all
the code, at least file-by-file. I'd be willing to help with this
cleanup once the 4.4 development window opens.
> Instead of "%s", blah?"1":"0" use "%d" and the == expression itself.
That's a good idea.
-George
next prev parent reply other threads:[~2013-06-18 9:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 16:43 [PATCH] libxl, hvmloader: Don't relocate memory for MMIO hole George Dunlap
2013-06-17 16:48 ` George Dunlap
2013-06-18 12:18 ` Hanweidong
2013-06-18 12:20 ` George Dunlap
2013-06-18 12:46 ` Hanweidong
2013-06-18 12:51 ` George Dunlap
2013-06-18 12:44 ` George Dunlap
2013-06-18 12:54 ` Hanweidong
2013-06-17 17:02 ` George Dunlap
2013-06-17 17:09 ` Wei Liu
2013-06-17 17:15 ` Ian Jackson
2013-06-18 9:50 ` George Dunlap [this message]
2013-06-18 9:57 ` George Dunlap
2013-06-18 10:53 ` Ian Jackson
2013-06-18 11:43 ` George Dunlap
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=51C02D57.4060601@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=hanweidong@huawei.com \
--cc=ian.campbell@citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=xen-devel@lists.xen.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.