[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
Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
Mon, 04 Apr 2011 16:53:59 +0200
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
On 04/04/11 16:42, Peter Maydell wrote:
> On 4 April 2011 15:29, Jes Sorensen <address@hidden> wrote:
>>> 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?
> For the boards I care about (the ARM ones), the only validation
> requirement is that we don't allow the user to specify so much
> ram that we overlap physical RAM with I/O space. So ram_size is
> good enough. For the sun4m boards we can assume that the only
> validation they need is a ram_size check, because that's all they
> do at the moment and nobody's complaining that I know of.
I understand that what you are proposing seems to work well enough for
your problem at hand. What I am saying is that adding a mechanism like
that, can cause problems for adding a more generic mechanism that
handles more advanced boards in the future. I much prefer a generic
solution than a simple hack.
>> 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?
> If you have a concrete example of multiple boards which we currently model
> and which require this level of flexibility to avoid odd misbehaviour trying
> to run a guest, then please point them out and I'll look at expanding the
> patch to cover their requirements.
> If this is just a theoretical issue, then I think we should only add the
> extra generic framework code if and when we turn out to need it.
As I pointed out before, this is not a theoretical problem, most numa
systems have this issue, including many x86 boxes. I can see the problem
also existing with mips boards like the sb1250 ones I worked on many
Having an a table of valid ram locations for a board, will also give you
a framework to validate against if you want to be able to specify chunks
of memory at different areas of a board. This could be useful for
testing behavior that is like it would be if you have a system where
installing different DIMMs would split the RAM up differently.