From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Keir Fraser <keir@xen.org>,
Ian Campbell <ian.campbell@citrix.com>,
Hanweidong <hanweidong@huawei.com>,
xen-devel@lists.xen.org,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH v4 5/8] hvmloader: Correct bug in low mmio region accounting
Date: Fri, 21 Jun 2013 14:40:41 +0100 [thread overview]
Message-ID: <51C457D9.4080209@eu.citrix.com> (raw)
In-Reply-To: <20932.21985.450763.345419@mariner.uk.xensource.com>
On 21/06/13 14:32, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v4 5/8] hvmloader: Correct bug in low mmio region accounting"):
>> On 21.06.13 at 13:19, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>>> But for the first device I think it may be possible for resource->base
>>> not to be a multiple of the bar_sz, and in that case it might be that
>>> the precalculation thinks it will fit when the actual placement
>>> calculation doesn't.
>>>
>>> Do you think this is possible ?
>> This is possible only from an abstract perspective, not in reality:
>> PCI_MEM_START being 0x{f,e,c,8}0000000, PCI_MEM_END being
>> 0xfc000000, and allocations starting with the biggest BARs
>> (where you already correctly noted that BARs are always a power
>> of 2 in size), the current base address can be misaligned only
>> when the BAR size is too large to fit anyway. In which case it'll
>> go into the space above 4Gb, and to that range the precalculation
>> doesn't apply.
> Ah. Right. Err, OK. I'm convinced by this argument.
>
> It's not a good reflection on the clarity of this code, though.
> Perhaps, George, you could mention this issue in a comment or the
> commit message.
Yes, I think I shall. It is, as Jan says, correct at the present
moment, but it's not even clear whether that was by accident or by
design; even if it was by design, there's no guarantee it will remain so
in the future without at least a comment.
We may want to try to clean this up long-term, but I would really like
to investigate just punting this whole thing off to SeaBIOS, which is
being tested and maintained by the KVM folks.
> But anyway, this, and 6/8,
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Great, thanks.
Stefano pointed out some "development process" terminology leaking into
the comment on the last patch -- I'll clean that up, add in some
comments about the fragile accounting, and send v5. That should be it
for this series, I think.
-George
next prev parent reply other threads:[~2013-06-21 13:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-21 10:46 [PATCH 0/8] Relocate devices rather than memory for qemu-xen George Dunlap
2013-06-21 10:46 ` [PATCH v4 1/8] hvmloader: Remove all 64-bit print arguments George Dunlap
2013-06-21 10:48 ` Ian Jackson
2013-06-21 11:20 ` Keir Fraser
2013-06-21 10:55 ` Stefano Stabellini
2013-06-21 10:46 ` [PATCH v4 2/8] hvmloader: Make the printfs more informative George Dunlap
2013-06-21 10:49 ` Ian Jackson
2013-06-21 10:57 ` Stefano Stabellini
2013-06-21 10:46 ` [PATCH v4 3/8] hvmloader: Set up highmem resouce appropriately if there is no RAM above 4G George Dunlap
2013-06-21 10:50 ` Ian Jackson
2013-06-21 11:11 ` Stefano Stabellini
2013-06-21 10:46 ` [PATCH v4 4/8] hvmloader: Fix check for needing a 64-bit bar George Dunlap
2013-06-21 10:51 ` Ian Jackson
2013-06-21 10:46 ` [PATCH v4 5/8] hvmloader: Correct bug in low mmio region accounting George Dunlap
2013-06-21 11:19 ` Ian Jackson
2013-06-21 12:58 ` Jan Beulich
2013-06-21 13:32 ` Ian Jackson
2013-06-21 13:40 ` George Dunlap [this message]
2013-06-21 10:46 ` [PATCH v4 6/8] hvmloader: Load large devices into high MMIO space as needed George Dunlap
2013-06-21 11:21 ` Ian Jackson
2013-06-21 10:46 ` [PATCH v4 7/8] hvmloader: Remove minimum size for BARs to relocate to 64-bit space George Dunlap
2013-06-21 11:22 ` Ian Jackson
2013-06-21 10:46 ` [PATCH v4 8/8] libxl, hvmloader: Don't relocate memory for MMIO hole George Dunlap
2013-06-21 11:15 ` Stefano Stabellini
2013-06-21 11:25 ` Ian Jackson
2013-06-26 10:08 ` Hao, Xudong
2013-06-26 13:36 ` Stefano Stabellini
2013-06-26 14:23 ` Hao, Xudong
2013-06-26 16:21 ` Stefano Stabellini
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=51C457D9.4080209@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=hanweidong@huawei.com \
--cc=ian.campbell@citrix.com \
--cc=keir@xen.org \
--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.