On 04/04/11 19:26, Peter Maydell wrote:
On 4 April 2011 15:53, Jes Sorensen jes.soren...@redhat.com wrote:
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
On 04/04/11 18:54, Blue Swirl wrote:
On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen jes.soren...@redhat.com wrote:
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
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
On 04/04/11 16:42, Peter Maydell wrote:
On 4 April 2011 15:29, Jes Sorensen jes.soren...@redhat.com 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
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
On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen jes.soren...@redhat.com wrote:
On 04/04/11 16:42, Peter Maydell wrote:
On 4 April 2011 15:29, Jes Sorensen jes.soren...@redhat.com wrote:
Yes, I agree, so we shouldn't try to specify some complicated
set of static data that still won't be good
On 4 April 2011 15:53, Jes Sorensen jes.soren...@redhat.com wrote:
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
On 03/29/11 16:08, Peter Maydell wrote:
This primary aim of this patchset is to add a new 'max_ram' field to the
QEMUMachine structure so that a board model can specify the maximum RAM it
will accept. We can then produce a friendly diagnostic message when the
user tries to start qemu with a
On 30 March 2011 08:48, Jes Sorensen jes.soren...@redhat.com wrote:
On 03/29/11 16:08, Peter Maydell wrote:
This primary aim of this patchset is to add a new 'max_ram' field to the
QEMUMachine structure so that a board model can specify the maximum RAM it
will accept.
I am a little concerned
On 03/30/11 10:09, Peter Maydell wrote:
On 30 March 2011 08:48, Jes Sorensen jes.soren...@redhat.com wrote:
I am a little concerned about this approach. It should work for simple
embedded boards, but for larger systems, it really ought to be a mask
rather than a max address.
It's not a
On 30 March 2011 11:51, Jes Sorensen jes.soren...@redhat.com wrote:
On 03/30/11 10:09, Peter Maydell wrote:
On 30 March 2011 08:48, Jes Sorensen jes.soren...@redhat.com wrote:
I am a little concerned about this approach. It should work for simple
embedded boards, but for larger systems, it
On 03/30/2011 08:22 AM, Peter Maydell wrote:
On 30 March 2011 11:51, Jes Sorensenjes.soren...@redhat.com wrote:
On 03/30/11 10:09, Peter Maydell wrote:
On 30 March 2011 08:48, Jes Sorensenjes.soren...@redhat.com wrote:
I am a little concerned about this approach. It should work for simple
On 03/30/11 15:22, Peter Maydell wrote:
On 30 March 2011 11:51, Jes Sorensen jes.soren...@redhat.com
wrote:
Ideally I think it would be better to have a mask and then
introduce a is_valid_memory() kinda function to check it with.
I'm not sure what this mask would look like. You want
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
This primary aim of this patchset is to add a new 'max_ram' field to the
QEMUMachine structure so that a board model can specify the maximum RAM it
will accept. We can then produce a friendly diagnostic message when the
user tries to start qemu with a '-m' option asking for more RAM than that.
15 matches
Mail list logo
