On 4 April 2011 15:29, Jes Sorensen <jes.soren...@redhat.com> wrote: > On 03/30/11 16:07, Peter Maydell wrote: >> On 30 March 2011 14:56, Anthony Liguori <anth...@codemonkey.ws> 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?
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. As far as I know Anthony is suggesting that some boards might in theory have stricter memory size requirements. I agree that this is a possibility, but if you have a rare board which has an idiosyncratic requirement then the correct way to handle that is to add extra checks in the board init functions. I don't see a huge queue of people with patches to add complex checks to board init functions that would indicate that we need a generic mechanism for handling this. What we do have is simple ram_size limit checks (in sun4m and we need them for the arm devboards) -- which is a demonstrated need that justifies the common code framework. > 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. -- PMM
