From: Iris Johnson <iris@modwiz.com>
To: QEMU Arm <qemu-arm@nongnu.org>
Cc: QEMU devel <qemu-devel@nongnu.org>
Subject: Question: Adding emulated machine support for Apple M1 mac
Date: Sat, 30 Jan 2021 13:04:28 -0600 [thread overview]
Message-ID: <CAN6Exg2Kz9yu-9Ftx4V5QL31duVdNCvR3_Pn-4PG39_zRm+pzw@mail.gmail.com> (raw)
Hi all,
In light of attempts to get Linux bootstrapped on the new M1 macs I've
been working on supporting them in QEMU as a new machine type, I think
this has benefits for testing and potentially there is desire for an
M1 Mac running QEMU to natively support emulating an M1 Mac and
potentially booting OS X under such a setup (although this is not
something I can personally test).
Adding a new machine type is hardly a straightforward process though
and there's a lot of paths the existing code takes that aren't ideal.
Constructing the memory map and how to handle initialization of the
hardware before jumping into code that would expect to be loaded from
firmware bootloaders are two examples of cases that are handled in a
multitude of different ways.
I'm looking for some feedback on the possible approaches, you can find
the current progress of my work on what might (eventually) turn into a
potential patch adding support here:
https://github.com/modwizcode/qemu/tree/add_M1_test.
Currently I'm focused on booting m1n1
(https://github.com/AsahiLinux/m1n1/), a sort of linux loader, with
the goal to have enough support to not need any qemu specific m1n1
patches to handle qemu differences. This goal has been achieved well
enough to start work on basic framebuffer and interrupt controller
implementation.
The most objectionable area at the moment is that I currently just
modify the cortex-a72 to stub out a few Apple M1 specific MSRs,
obviously a real coretype for the M1 should be added (probably two to
account for differences between the two types of cores it has).
Currently I have an "AppleM1SoC" object that will hold all the
peripherals, and then I add a simple machine definition called
"apple-m1" that (once more information is available) should simulate
the hardware environment of an M1 based mac mini.
Feedback would be appreciated on desire for this, implementation
suggestions, critiques (although there's some cleanup I'm saving for
later once I've decided on a more correct approach)
Thanks
Iris Johnson
reply other threads:[~2021-01-30 19:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CAN6Exg2Kz9yu-9Ftx4V5QL31duVdNCvR3_Pn-4PG39_zRm+pzw@mail.gmail.com \
--to=iris@modwiz.com \
--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).