qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Thomas Schneider <74cmonty@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Andrew Baumann" <Andrew.Baumann@microsoft.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	"Paul Zimmerman" <pauldzim@gmail.com>
Subject: Re: Emulate Rpi with QEMU fails
Date: Wed, 07 Oct 2020 12:00:50 +0100	[thread overview]
Message-ID: <87blhe1esd.fsf@linaro.org> (raw)
In-Reply-To: <4da67d13-a774-f62e-ad89-de062cbe81da@gmail.com>


Thomas Schneider <74cmonty@gmail.com> writes:

> Hi,
>
> I already considered the host CPU power.
> However I have this 
> <https://ark.intel.com/content/www/us/en/ark/products/33924/intel-core-2-quad-processor-q9550-12m-cache-2-83-ghz-1333-mhz-fsb.html> 
> CPU
> Intel Core 2 Quad Q9550 2,83 GHz
> and assumed this should be powerful enough for RPi emulation.

For each emulated instruction you can be running between 6-10 host
instructions on average. We have certainly improved the performance of
the emulation over time and take advantage of multiple threads but in
the end system emulation will always be fairly expensive.

> But maybe my assumption was too optimistic.

You can use perf to record your boot and analyse where QEMU is spending
it's time. Unless there is a major outlier though it's unlikely to be
easy to optimise.

>
>
> Am 07.10.2020 um 08:50 schrieb Paul Zimmerman:
>> On Tue, Oct 6, 2020 at 11:28 PM Thomas <74cmonty@gmail.com> wrote:
>>> Hello!
>>>
>>> Many thanks for your support.
>>>
>>> I managed to get emulated RPi starting.
>>>
>>> However there's one question I want to ask:
>>> How can I accelerate the startup sequence?
>>> I mean booting the emulated RPi takes more than 3 minutes.
>>>
>>> Regards
>>> Thomas
>> Get a faster computer? ;)
>>
>> On my Intel i7 desktop it takes about 40 seconds to boot to the login:
>> prompt on the serial console, and about 1 min 8 seconds before the
>> GUI is up. On my 5 year old laptop it's probably twice that. I don't know
>> of any way to make it go faster.
>>
>> - Paul
>>
>>> Am 06.10.20 um 11:58 schrieb Alex Bennée:
>>>> Thomas Schneider <74cmonty@gmail.com> writes:
>>>>
>>>>> Hello Paul,
>>>>>
>>>>> many thanks for sharing this info.
>>>>>
>>>>> Can you confirm that the emulated RPi with your command will use
>>>>> "internal QEMU" network, means the client cannot be accessed from any
>>>>> other device in LAN?
>>>> The support for user-mode and TAP networking is orthogonal to the
>>>> emulated device. However if you only want a few ports it's quite easy to
>>>> use port forwarding, e.g:
>>>>
>>>>    -netdev user,id=unet,hostfwd=tcp::2222-:22
>>>>
>>>> which forwards 2222 to port 22 on the device. I have an alias in
>>>> .ssh/config for accessing my QEMU devices.
>>>>
>>>>> If yes, what is required to setup a TAP connected to host's network
>>>>> bridge?
>>>> I'll defer to others for this but generally when I want proper bridged
>>>> networking for a VM I use virt-manager/libvirt to configure it because
>>>> it can be quite fiddly to do by hand.
>>>>


-- 
Alex Bennée


  reply	other threads:[~2020-10-07 11:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-03 11:45 Emulate Rpi with QEMU fails Thomas
2020-10-04 17:44 ` Alex Bennée
2020-10-04 18:40   ` Peter Maydell
2020-10-05  9:40     ` Alex Bennée
2020-10-05 10:51       ` Thomas Schneider
2020-10-05 22:08         ` Paul Zimmerman
2020-10-06  6:58           ` Thomas Schneider
2020-10-06  7:42             ` Paul Zimmerman
2020-10-06  9:58             ` Alex Bennée
2020-10-07  6:28               ` Thomas
2020-10-07  6:50                 ` Paul Zimmerman
2020-10-07  7:27                   ` Thomas Schneider
2020-10-07 11:00                     ` Alex Bennée [this message]
2020-10-07 11:36                       ` Thomas Schneider
2020-10-07 12:02                         ` Alex Bennée
2020-10-08  7:00                           ` Thomas
2020-10-08 21:07                             ` Paul Zimmerman
2020-10-09  2:21                               ` Paul Zimmerman
2020-10-09  6:20                             ` Alex Bennée

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=87blhe1esd.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=74cmonty@gmail.com \
    --cc=Andrew.Baumann@microsoft.com \
    --cc=f4bug@amsat.org \
    --cc=pauldzim@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).