qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	qemu-devel@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
	seabios@seabios.org, "László Érsek" <lersek@redhat.com>
Subject: Re: [Qemu-devel] Minimum RAM size for PC machines?
Date: Thu, 23 Mar 2017 09:19:05 +0100	[thread overview]
Message-ID: <1490257145.463.24.camel@redhat.com> (raw)
In-Reply-To: <da2bfbb8-c000-eaff-826f-904582f6e98a@redhat.com>

On Mi, 2017-03-22 at 11:19 +0100, David Hildenbrand wrote:
> On 22.03.2017 11:03, Thomas Huth wrote:
> > On 22.03.2017 10:08, Markus Armbruster wrote:
> > [...]
> >> Are we now ready to accept a simple & stupid patch that actually helps
> >> users, say letting boards that care declare minimum and maximum RAM
> >> size?  And make PC reject RAM size less than 1MiB, even though "someone"
> >> might conceivably have firmware that works with less?
> > 
> > I'd say enforce a minimum RAM size on the normal "pc" and "q35" machine,
> > but still allow smaller sizes on the "isapc" machine. So if "someone"
> > comes around and claims to have a legacy firmware that wants less memory
> > than 1MiB, just point them to the isapc machine.
> > Just my 0.02 €.
> > 
> >  Thomas
> 
> Or maybe simply warn the user that things may go wrong instead of
> enforcing it.

Why bother?  I have my doubts physical i440fx works with less than 1M
either, given that this memory is needed to shadow the roms.  Possibly
you can't even find dimms that are small to plug them into such a system
to try ...

I'd say just add a hard limit and be done with it.

Maybe exclude isapc.  That one hasn't shadow support so things have at
least a chance to work with less than 1M of memory.  But honestly I'd
rather drop isapc, together with ia64 and sparc.  I mean, what is the
use case?  'pc' machine type is compatible enough with vga and ide ports
being on the standard isa locations so even msdos which has no pci
support at all boots happily.

cheers,
  Gerd

  reply	other threads:[~2017-03-23  8:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-22  9:08 [Qemu-devel] Minimum RAM size for PC machines? Markus Armbruster
2017-03-22 10:03 ` Thomas Huth
2017-03-22 10:19   ` David Hildenbrand
2017-03-23  8:19     ` Gerd Hoffmann [this message]
2017-03-23  9:18       ` David Hildenbrand
2017-03-22 12:25   ` Igor Mammedov
2017-03-22 15:18     ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor

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=1490257145.463.24.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=armbru@redhat.com \
    --cc=david@redhat.com \
    --cc=lersek@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    --cc=thuth@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).