qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in Q


From: Jes Sorensen
Subject: Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
Date: Mon, 04 Apr 2011 16:29:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9

On 03/30/11 16:07, Peter Maydell wrote:
> On 30 March 2011 14:56, Anthony Liguori <address@hidden> wrote:
>> On 03/30/2011 08:22 AM, Peter Maydell wrote:
>>> Not really, typically they're just filled up in some particular
>>> order (main RAM in one place and expansion RAM elsewhere).
>>> Since the board init function is only passed a single "ram_size"
>>> parameter that's all you can do anyhow.
>>
>> FWIW, I don't think any static data is going to be perfect here.  A lot of
>> boards have strict requirements on ram_size based on plausible combinations
>> of DIMMs.  Arbitrary values up to ram_size is not good enough.
>>
>> ram_size ought to be viewed as a hint, not a mechanism to allow common code
>> to completely validate the passed in ram size parameter.  It's still up to
>> the board to validate that the given ram size makes sense.
> 
> Yes, I agree, so we shouldn't try to specify some complicated
> set of static data that still won't be good enough.
> 
> I'm trying to make it easy for boards to avoid crashing horribly
> when the user passes a bad value; that's all.

If you don't validate properly, is there really a point in introducing
that value anyway? From what you write, it sounds like it can still fail
for some limits of the memory valid if the config is wrong?

It still seems to me it would be better to have the boards present a
table of valid memory ranges so we can do a proper validation of the valud?

Cheers,
Jes



reply via email to

[Prev in Thread] Current Thread [Next in Thread]