All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.