Message ID | 1486575331-14455-3-git-send-email-abologna@redhat.com |
---|---|
State | New |
Headers | show |
Thanks for the CC! On 02/08/17 18:35, Andrea Bolognani wrote: > +# Firmware configuration > +# ========================================================= > +# > +# There are two parts to the firmware: a read-only image > +# containing the executable code, which is shared between > +# guests, and a read/write variable store that is used by Apparently omitted: one specific virtual machine, exclusively, Also, I would recommend replacing "used" with "owned". > +# to record information such as the boot device. An empty s/boot device/UEFI boot order/ > +# variable store can be created by simply copying a > +# template provided as part of AAVMF. How about: For any new guest, its permanent, private variable store should initially be copied from the template file provided as part of the ArmVirtQemu firmware platform (which is occasionally distributed under the AAVMF package). > +# > +# Depending on the distribution you're using on the host, I recommend "OS distribution", "Linux distribution", or "GNU/Linux distribution", as you prefer. > +# paths to the firmware itself and variable store template s/firmware/firmware binary/ > +# will be different. Some examples: > +# > +# Fedora: > +# /usr/share/edk2/aarch64/QEMU_EFI.fd > +# /usr/share/edk2/aarch64/QEMU_VARS.fd Please annotate each as firmware binary & variable store template. Also, I can't verify the exact pathnames for Fedora. > +# RHEL: > +# /usr/share/AAVMF/AAVMF_CODE.fd > +# /usr/share/AAVMF/AAVMF_VARS.fd Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context -- no clue. Ask Drew :)) > + > +[drive "aavmf-code"] Heh, I never specify "id" for these "-drive"s, but I definitely appreciate the attention to detail. Let's call it "uefi-binary" though. > + file = "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME Please replace the comment with CHANGE ME ACCORDING TO HOST LINUX DISTRO or some such > + format = "raw" > + if = "pflash" > + unit = "0" > + readonly = "on" > + > +[drive "aavmf-vars"] Let's call this "uefi-varstore". > + file = "guest_VARS.fd" # CHANGE ME Many bonus points for providing a file name example that is *different* from (QEMU|AAVMF)_VARS.fd. It should (and thankfully, does) reflect that it's already a copy. Please expand the comment: CHANGE ME TO THE NAME OF THE FILE THAT YOU CREATED AS A COPY of THE VARSTORE TEMPLATE > + format = "raw" > + if = "pflash" > + unit = "1" Yes! I apologize for being too detailed / pedantic about this. Thanks! Laszlo
On 8 February 2017 at 17:35, Andrea Bolognani <abologna@redhat.com> wrote: > These are very much like the sample configuration files > for q35, and can be used both as documentation and as > a starting point for creating your own guest. > --- /dev/null > +++ b/docs/mach-virt-graphical.cfg > @@ -0,0 +1,245 @@ > +# mach-virt - VirtIO guest (graphical console) > +# ========================================================= > +# > +# You will probably need to tweak the lines marked as > +# CHANGE ME before being able to use this configuration! > +# > +# Usage: > +# > +# $ qemu-system-aarch64 \ > +# -nodefaults \ > +# -readconfig mach-virt-graphical.cfg \ > +# -cpu host What does nodefaults disable on the virt board? (I've never looked into exactly what nodefaults does...) There doesn't seem to be any specification of the GIC version (unless I missed it in the config file); you probably want -machine gic-version=host if you're using -cpu host. > +# Using -nodefaults is required to have full control over > +# the virtual hardware: when it's specified, QEMU will > +# create a bare machine with just the very essential > +# chipset devices being present: The theory of 'virt' is it only has the essential devices anyway. > +# 00:00.0 Host bridge I'm pretty sure -nodefaults isn't going to disable the GIC, the UART, the flash devices, etc etc that the virt board has. Not everything in the world is a PCI device :-) > +# > +# This configuration file adds a number of other useful > +# devices, more specifically: > +# > +# 00:01.0 Display controller > +# 00.1c.* PCI bridge (PCI Express Root Ports) > +# 01:00.0 SCSI storage controller > +# 02:00.0 Ethernet controller > +# 03:00.0 USB controller > +# > +# More information about these devices is available below. > + > +# Firmware configuration > +# ========================================================= > +# > +# There are two parts to the firmware: a read-only image > +# containing the executable code, which is shared between > +# guests, and a read/write variable store that is used by > +# to record information such as the boot device. An empty > +# variable store can be created by simply copying a > +# template provided as part of AAVMF. > +# > +# Depending on the distribution you're using on the host, > +# paths to the firmware itself and variable store template > +# will be different. Some examples: > +# > +# Fedora: > +# /usr/share/edk2/aarch64/QEMU_EFI.fd > +# /usr/share/edk2/aarch64/QEMU_VARS.fd > +# RHEL: > +# /usr/share/AAVMF/AAVMF_CODE.fd > +# /usr/share/AAVMF/AAVMF_VARS.fd It's a shame that we've ended up with different firmware names (even between RHEL and Fedora, without getting to Debian or SUSE). Would making UEFI a more "official" rom image in pc-bios/ help to harmonise things, or just introduce yet another possibility to the mix? > +# Communication controller (serial console) > +# ========================================================= > +# > +# We use virtconsole along with virtio-serial, and connect > +# it with the host's standard input / output channels. In > +# this configuration, the guest will behave pretty much > +# like any other Unix utility: that includes terminating > +# as soon as Ctrl-C is pressed, so caution is advised. > +# > +# If you want to use the platform's native serial console > +# instead, you should comment out this section and append > +# > +# -serial stdio > +# > +# to the QEMU command line. Doing so might be needed to be > +# able to access the GRUB menu or see the output from the > +# boot process. > + > +[chardev "hostconsole"] > + backend = "stdio" > + > +[device "serial"] > + driver = "virtio-serial-pci" > + bus = "pci.3" > + addr = "00.0" > + > +[device "console"] > + driver = "virtconsole" > + chardev = "hostconsole" Won't most guests expect serial to be the default PL011 UART ? thanks -- PMM
On Wed, 2017-02-08 at 19:11 +0100, Laszlo Ersek wrote: > How about: > > For any new guest, its permanent, private variable store should > initially be copied from the template file provided as part of the > ArmVirtQemu firmware platform (which is occasionally distributed > under the AAVMF package). The naming is confusing enough as it is, no need to drag ArmVirtQemu into this I think ;) > > +# Fedora: > > +# /usr/share/edk2/aarch64/QEMU_EFI.fd > > +# /usr/share/edk2/aarch64/QEMU_VARS.fd > > Please annotate each as firmware binary & variable store template. I had such annotations at some points, I got rid of them because they seemed a bit redundant. Added them back in. > Also, I can't verify the exact pathnames for Fedora. https://koji.fedoraproject.org/koji/rpminfo?rpmID=8491933 ;) [...] > > +# RHEL: > > +# /usr/share/AAVMF/AAVMF_CODE.fd > > +# /usr/share/AAVMF/AAVMF_VARS.fd > > Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context > -- no clue. Ask Drew :)) Yeah, you're probably right. [...] > Please expand the comment: > > CHANGE ME TO THE NAME OF THE FILE THAT YOU CREATED AS A COPY of THE > VARSTORE TEMPLATE Nope. The line would get waaay too long, and I trust the user to understand the basic idea after having gone through the paragraphs above. Here's an updated version, what do you think about it? # Firmware configuration # ========================================================= # # There are two parts to the firmware: a read-only image # containing the executable code, which is shared between # guests, and a read/write variable store that is owned # by one specific guest, exclusively, and is used to record # information such as the UEFI boot order. # # For any new guest, its permanent, private variable store # should initially be copied from the template file # provided along with the firmware binary. # # Depending on the OS distribution you're using on the # host, the name of the package containing the firmware # binary and variable store, as well as the paths to the # files themselves, will be different. Some examples: # # Fedora: # edk2-aarch64 (package) # /usr/share/edk2/aarch64/QEMU_EFI.fd (binary) # /usr/share/edk2/aarch64/QEMU_VARS.fd (template) # # RHELSA: # AAVMF (package) # /usr/share/AAVMF/AAVMF_CODE.fd (binary) # /usr/share/AAVMF/AAVMF_VARS.fd (varstore) -- Andrea Bolognani / Red Hat / Virtualization
On 02/08/17 19:32, Peter Maydell wrote: > On 8 February 2017 at 17:35, Andrea Bolognani <abologna@redhat.com> wrote: >> +# Firmware configuration >> +# ========================================================= >> +# >> +# There are two parts to the firmware: a read-only image >> +# containing the executable code, which is shared between >> +# guests, and a read/write variable store that is used by >> +# to record information such as the boot device. An empty >> +# variable store can be created by simply copying a >> +# template provided as part of AAVMF. >> +# >> +# Depending on the distribution you're using on the host, >> +# paths to the firmware itself and variable store template >> +# will be different. Some examples: >> +# >> +# Fedora: >> +# /usr/share/edk2/aarch64/QEMU_EFI.fd >> +# /usr/share/edk2/aarch64/QEMU_VARS.fd >> +# RHEL: >> +# /usr/share/AAVMF/AAVMF_CODE.fd >> +# /usr/share/AAVMF/AAVMF_VARS.fd > > It's a shame that we've ended up with different > firmware names (even between RHEL and Fedora, without > getting to Debian or SUSE). The root cause (or, well, *one* root cause) is that OVMF used to be un-distributable in Fedora (and I assume, Debian), due to the requirements that Fedora presented (and presents) for package licenses. In particular, the FAT driver in OVMF used not to be free software (no freedom #0 -- "use for any purpose"). The RHEL Supplementary channel could however accommodate OVMF (as Tech Preview). So this was a strange situation where a package first entered RHEL (even if in a "side channel"), and Fedora picked it up way later. Also, my personal workflow does not really match Fedora. I'll break my back for upstream and for RHEL (I *am* serious about "upstream first"), but community distros are not a good fit for me, either technically or socially. They are neither upstreams (with nicely bisectable git repos, sane mailing lists -- have you seen HyperKitty? -- or sane bug trackers, for example), nor real supported, stable downstreams, with necks and money on the line. In the virt team @RH, I'm responsible for upstream and RHEL, but I specifically requested to be independent of Fedora. Whenever OVMF or AAVMF bugs are reported in RHBZ, for Fedora, I do take a look, but I don't take responsibility. I'm not even a "proven packager" for Fedora. (I guess I'll be crucified for the above paragraph, but I guess I might as well speak my mind on this, for one data point.) Re: Debian, I *had* been on the lookout for OVMF-related Debian bugs (and some other community distro bugs), and I used to comment on them quite liberally, especially when it came to packaging. Example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918 I also try to respond to OVMF-related reports that people file in the QEMU LaunchPad tracker (... despite TianoCore having a real Bugzilla bug tracker, which I'm forced to say runs circles around LaunchPad.) But, packaging questions and uniformity across distros aren't my stuff. > Would making UEFI a > more "official" rom image in pc-bios/ help to > harmonise things, or just introduce yet another > possibility to the mix? On one hand, it would be the best possible solution. I believe we've been thinking on-and-off about bundling OVMF and ArmVirtQemu with QEMU, since FatPkg in edk2 became free software. (... Because Microsoft graciously liberated the license, after Intel worked with them for a looong time on that. Kudos again to both companies!) On the other hand, upstream edk2 doesn't do releases (not in the "whole community stabilization / soft freeze / hard freeze / merge window closed" sense anyway). So Gerd -- because it would fall under Gerd's maintainership I think -- would have to deal with yet another project like iPXE (no releases). It's up to him, I guess. NB: Gerd maintains a distro-independent set of RPM packages at <https://www.kraxel.org/repos/>, which provide bleeding edge upstream builds. For "wide community" purposes, I tend to view those as the "gold standard". If they run into build or functional failures, in the minimal amount of private (but still open source) patches that we carry in them, I do consider helping out with those as a priority. So I guess Gerd would have to decide which of the both (or maybe both?) streams he'd want to maintain -- the one bundled with QEMU, or the one in his "bleeding edge" repo. ... If iPXE is any example, then my guess is "both" :) Sheesh, sorry about this huge rant. Don't push my buttons, people. ;) Thanks Laszlo
On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote: > What does nodefaults disable on the virt board? > (I've never looked into exactly what nodefaults does...) When -nodefaults is missing, a default virtio-net-pci plugged into 00:01.0 is automatically added. > There doesn't seem to be any specification of the GIC > version (unless I missed it in the config file); you > probably want -machine gic-version=host if you're using > -cpu host. Very good point! I've added it. I would really, really like to be able to specify the CPU model in the configuration file as well, but I haven't found a way to do so :( On the other hand, I just realized that I can add [machine] graphics = "off" to get rid of -nographic on the command line! \o/ > > +# Using -nodefaults is required to have full control over > > +# the virtual hardware: when it's specified, QEMU will > > +# create a bare machine with just the very essential > > +# chipset devices being present: > > The theory of 'virt' is it only has the essential > devices anyway. See above ;) The use of -nodefaults is there mostly to guarantee that we always start from a clean slate, like for example add the Ethernet adapter ourselves (giving us a chance to comment on its usage) instead of using the default one. Another goal is to be consistent with the q35 sample configuration files: ideally comparing mach-virt-serial.cfg and q35-virtio-serial.cfg, for example, should yield a very minimal diff. > > +# 00:00.0 Host bridge > > I'm pretty sure -nodefaults isn't going to disable > the GIC, the UART, the flash devices, etc etc that > the virt board has. Not everything in the world is > a PCI device :-) Right. So far I've basically stuck with PCI devices: even the device listing, as you can see, is modeled after the output of lspci. That said, I'm not against documenting more devices. [...] > It's a shame that we've ended up with different > firmware names (even between RHEL and Fedora, without > getting to Debian or SUSE). Yeah, it's pretty unfortunate :( > Would making UEFI a > more "official" rom image in pc-bios/ help to > harmonise things, or just introduce yet another > possibility to the mix? Sorry, no idea. I'll let someone else comment on this one. [...] > > +[device "console"] > > + driver = "virtconsole" > > + chardev = "hostconsole" > > Won't most guests expect serial to be the default > PL011 UART ? Possibly. I'm using virtconsole here (and in q35*serial.cfg) mostly to have as much VirtIO as possible, but I also document the fact that you might want or need to use the native serial console instead. Moreover, something that I haven't been able to do on mach-virt (even though I could on q35, but again, I want the files to be as close as possible) is to configure the serial console from the configuration file. Seeing as we have an alternative, I'd rather keep it this way and minimize the number of command line arguments the user needs to specify. -- Andrea Bolognani / Red Hat / Virtualization
On 02/08/17 19:49, Andrea Bolognani wrote: > On Wed, 2017-02-08 at 19:11 +0100, Laszlo Ersek wrote: >> How about: >> >> For any new guest, its permanent, private variable store should >> initially be copied from the template file provided as part of the >> ArmVirtQemu firmware platform (which is occasionally distributed >> under the AAVMF package). > > The naming is confusing enough as it is, no need to drag > ArmVirtQemu into this I think ;) Yeah, that's the upstream platform name, and I know that Leif and Ard dislike "AAVMF". In downstream, we needed some name for the package, when -- if memory serves -- upstream was still called "ArmPlatformPkg/ArmVirtualizationPkg", and there was no Xen support, only QEMU, so QEMU wasn't even in the name, because it was implied. We agreed upon "AAVMF" (don't say anything), and of course the name percolated to the outside, via mailing lists, other projects that embedded the name (libguestfs, maybe?), and so on. > >>> +# Fedora: >>> +# /usr/share/edk2/aarch64/QEMU_EFI.fd >>> +# /usr/share/edk2/aarch64/QEMU_VARS.fd >> >> Please annotate each as firmware binary & variable store template. > > I had such annotations at some points, I got rid of them > because they seemed a bit redundant. Added them back in. > >> Also, I can't verify the exact pathnames for Fedora. > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=8491933 ;) Ahhh, it's *very* good that you provided this reference, because now I see that the file names below are incorrect. Namely, for aarch64 guests, you have to use the files that are padded to 64MB, *not* the files as they fall out of the edk2 build process. > > [...] >>> +# RHEL: >>> +# /usr/share/AAVMF/AAVMF_CODE.fd >>> +# /usr/share/AAVMF/AAVMF_VARS.fd >> >> Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context >> -- no clue. Ask Drew :)) > > Yeah, you're probably right. > > [...] >> Please expand the comment: >> >> CHANGE ME TO THE NAME OF THE FILE THAT YOU CREATED AS A COPY of THE >> VARSTORE TEMPLATE > > Nope. The line would get waaay too long, and I trust the > user Good for you :) > to understand the basic idea after having gone through > the paragraphs above. Okay ;) > > Here's an updated version, what do you think about it? > > > # Firmware configuration > # ========================================================= > # > # There are two parts to the firmware: a read-only image > # containing the executable code, which is shared between > # guests, and a read/write variable store that is owned > # by one specific guest, exclusively, and is used to record > # information such as the UEFI boot order. > # > # For any new guest, its permanent, private variable store > # should initially be copied from the template file > # provided along with the firmware binary. > # > # Depending on the OS distribution you're using on the > # host, the name of the package containing the firmware > # binary and variable store, as well as the paths to the red flag: please say "variable store *template*" > # files themselves, will be different. Some examples: > # > # Fedora: > # edk2-aarch64 (package) > # /usr/share/edk2/aarch64/QEMU_EFI.fd (binary) > # /usr/share/edk2/aarch64/QEMU_VARS.fd (template) > # > # RHELSA: > # AAVMF (package) > # /usr/share/AAVMF/AAVMF_CODE.fd (binary) > # /usr/share/AAVMF/AAVMF_VARS.fd (varstore) Two comments: - Under Fedora, you have (template), which is cool, (varstore) is bad. :) - Again, the files you note above for Fedora are 2MB and 768KB in size, respectively, which is wrong. The files you note for RHELSA are both 64MB in size, which is right. Fedora ships the according files as well, but their names are different: /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw (binary) /usr/share/edk2/aarch64/vars-template-pflash.raw (varstore template) Thanks! Laszlo > > -- > Andrea Bolognani / Red Hat / Virtualization >
On 8 February 2017 at 19:28, Andrea Bolognani <abologna@redhat.com> wrote: > On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote: >> What does nodefaults disable on the virt board? >> (I've never looked into exactly what nodefaults does...) > > When -nodefaults is missing, a default virtio-net-pci > plugged into 00:01.0 is automatically added. Ah, right, default -net commands. Is that it? > On the other hand, I just realized that I can add > > [machine] > graphics = "off" > > to get rid of -nographic on the command line! \o/ -nographic is kind of odd if you're taking the "use -nodefaults and specify everything manually" because it wraps up a whole pile of default config in one oddball legacy config switch. I would have expected -display none and whatever other options you wanted. > [...] >> > +[device "console"] >> > + driver = "virtconsole" >> > + chardev = "hostconsole" >> >> Won't most guests expect serial to be the default >> PL011 UART ? > > Possibly. I'm using virtconsole here (and in q35*serial.cfg) > mostly to have as much VirtIO as possible, but I also > document the fact that you might want or need to use the > native serial console instead. > > Moreover, something that I haven't been able to do on > mach-virt (even though I could on q35, but again, I want the > files to be as close as possible) is to configure the serial > console from the configuration file. If there's stuff we can fix in the virt board to make this work the way it does on the PC model I'm happy to make fixes to help. > Seeing as we have an alternative, I'd rather keep it this > way and minimize the number of command line arguments the > user needs to specify. The trouble with using virtconsole is that you have to get quite a long way forward (probing and setting up PCI, etc) before you can get any kind of console output. "System doesn't boot and doesn't produce any output" is a common and really annoying failure mode in the ARM world, and I think that using virtconsole is asking for that kind of thing to happen more rather than less often. (Plus having two different serial ports in the guest means that now the user has to configure where both of them are supposed to output.) thanks -- PMM
On 02/08/17 20:28, Andrea Bolognani wrote: > On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote: >> What does nodefaults disable on the virt board? >> (I've never looked into exactly what nodefaults does...) > > When -nodefaults is missing, a default virtio-net-pci > plugged into 00:01.0 is automatically added. > >> There doesn't seem to be any specification of the GIC >> version (unless I missed it in the config file); you >> probably want -machine gic-version=host if you're using >> -cpu host. > > Very good point! I've added it. > > I would really, really like to be able to specify the > CPU model in the configuration file as well, but I haven't > found a way to do so :( > > On the other hand, I just realized that I can add > > [machine] > graphics = "off" > > to get rid of -nographic on the command line! \o/ > >>> +# Using -nodefaults is required to have full control over >>> +# the virtual hardware: when it's specified, QEMU will >>> +# create a bare machine with just the very essential >>> +# chipset devices being present: >> >> The theory of 'virt' is it only has the essential >> devices anyway. > > See above ;) > > The use of -nodefaults is there mostly to guarantee that we > always start from a clean slate, like for example add the > Ethernet adapter ourselves (giving us a chance to comment > on its usage) instead of using the default one. > > Another goal is to be consistent with the q35 sample > configuration files: ideally comparing mach-virt-serial.cfg > and q35-virtio-serial.cfg, for example, should yield a > very minimal diff. > >>> +# 00:00.0 Host bridge >> >> I'm pretty sure -nodefaults isn't going to disable >> the GIC, the UART, the flash devices, etc etc that >> the virt board has. Not everything in the world is >> a PCI device :-) > > Right. So far I've basically stuck with PCI devices: even > the device listing, as you can see, is modeled after the > output of lspci. > > That said, I'm not against documenting more devices. > > [...] >> It's a shame that we've ended up with different >> firmware names (even between RHEL and Fedora, without >> getting to Debian or SUSE). > > Yeah, it's pretty unfortunate :( > >> Would making UEFI a >> more "official" rom image in pc-bios/ help to >> harmonise things, or just introduce yet another >> possibility to the mix? > > Sorry, no idea. I'll let someone else comment on this one. > > [...] >>> +[device "console"] >>> + driver = "virtconsole" >>> + chardev = "hostconsole" >> >> Won't most guests expect serial to be the default >> PL011 UART ? > > Possibly. I'm using virtconsole here (and in q35*serial.cfg) > mostly to have as much VirtIO as possible, but I also > document the fact that you might want or need to use the > native serial console instead. If you care about firmware logs, or early guest kernel logs, from aarch64 guests, you absolutely need a PL011 UART. > > Moreover, something that I haven't been able to do on > mach-virt (even though I could on q35, but again, I want the > files to be as close as possible) is to configure the serial > console from the configuration file. What do you mean by "configure the serial console"? Thanks Laszlo > > Seeing as we have an alternative, I'd rather keep it this > way and minimize the number of command line arguments the > user needs to specify. > > -- > Andrea Bolognani / Red Hat / Virtualization >
On 8 February 2017 at 19:23, Laszlo Ersek <lersek@redhat.com> wrote: > On 02/08/17 19:32, Peter Maydell wrote: >> Would making UEFI a >> more "official" rom image in pc-bios/ help to >> harmonise things, or just introduce yet another >> possibility to the mix? > > On one hand, it would be the best possible solution. I believe we've > been thinking on-and-off about bundling OVMF and ArmVirtQemu with QEMU, > since FatPkg in edk2 became free software. (... Because Microsoft > graciously liberated the license, after Intel worked with them for a > looong time on that. Kudos again to both companies!) > > On the other hand, upstream edk2 doesn't do releases (not in the "whole > community stabilization / soft freeze / hard freeze / merge window > closed" sense anyway). So Gerd -- because it would fall under Gerd's > maintainership I think -- would have to deal with yet another project > like iPXE (no releases). It's up to him, I guess. Yes, since I don't personally have the time or expertise this definitely comes down to "does whoever would be doing the work think it's a good idea or not". thanks -- PMM
On Wed, 2017-02-08 at 20:34 +0100, Laszlo Ersek wrote: > > > Also, I can't verify the exact pathnames for Fedora. > > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=8491933 ;) > > Ahhh, it's *very* good that you provided this reference, because now I > see that the file names below are incorrect. Namely, for aarch64 guests, > you have to use the files that are padded to 64MB, *not* the files as > they fall out of the edk2 build process. Go figure... Thanks for spotting that! [...] > > # Depending on the OS distribution you're using on the > > # host, the name of the package containing the firmware > > # binary and variable store, as well as the paths to the > > red flag: please say "variable store *template*" Right. Missed it, sorry. [...] > > # Fedora: > > # edk2-aarch64 (package) > > # /usr/share/edk2/aarch64/QEMU_EFI.fd (binary) > > # /usr/share/edk2/aarch64/QEMU_VARS.fd (template) > > # > > # RHELSA: > > # AAVMF (package) > > # /usr/share/AAVMF/AAVMF_CODE.fd (binary) > > # /usr/share/AAVMF/AAVMF_VARS.fd (varstore) > > Two comments: > > - Under Fedora, you have (template), which is cool, (varstore) is bad. :) That just shows that I'm getting really tired and I should step away from the keyboard for the day :/ > - Again, the files you note above for Fedora are 2MB and 768KB in size, > respectively, which is wrong. The files you note for RHELSA are both > 64MB in size, which is right. Fedora ships the according files as well, > but their names are different: > > /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw (binary) > /usr/share/edk2/aarch64/vars-template-pflash.raw (varstore template) Consider it fixed! (Those filenames, though... Ewww.) -- Andrea Bolognani / Red Hat / Virtualization
On 02/08/17 20:36, Peter Maydell wrote: > On 8 February 2017 at 19:28, Andrea Bolognani <abologna@redhat.com> wrote: >> On Wed, 2017-02-08 at 18:32 +0000, Peter Maydell wrote: >>> Won't most guests expect serial to be the default >>> PL011 UART ? >> >> Possibly. I'm using virtconsole here (and in q35*serial.cfg) >> mostly to have as much VirtIO as possible, but I also >> document the fact that you might want or need to use the >> native serial console instead. >> >> Moreover, something that I haven't been able to do on >> mach-virt (even though I could on q35, but again, I want the >> files to be as close as possible) is to configure the serial >> console from the configuration file. > > If there's stuff we can fix in the virt board to make > this work the way it does on the PC model I'm happy > to make fixes to help. > >> Seeing as we have an alternative, I'd rather keep it this >> way and minimize the number of command line arguments the >> user needs to specify. > > The trouble with using virtconsole is that you have to > get quite a long way forward (probing and setting up > PCI, etc) before you can get any kind of console output. > "System doesn't boot and doesn't produce any output" > is a common and really annoying failure mode in the > ARM world, and I think that using virtconsole is > asking for that kind of thing to happen more rather > than less often. My point exactly. Thanks Laszlo > (Plus having two different serial > ports in the guest means that now the user has to > configure where both of them are supposed to output.) > > thanks > -- PMM >
Hi Andrea, Thanks for this! I see there's already been plenty of discussion and comments (you guys work too late...). I'll try to add my own couple of cents now too. On Wed, Feb 08, 2017 at 06:35:31PM +0100, Andrea Bolognani wrote: > These are very much like the sample configuration files > for q35, and can be used both as documentation and as > a starting point for creating your own guest. > > Two sample configuration files are provided: > > * mach-virt-graphical.cfg can be used to start a > fully-featured (USB, graphical console, etc.) > guest that uses VirtIO devices; > > * mach-virt-serial.cfg is similar but has a minimal > set of devices and uses the serial console. > > All configuration files are fully commented and neatly > organized. > --- > docs/mach-virt-graphical.cfg | 245 +++++++++++++++++++++++++++++++++++++++++++ > docs/mach-virt-serial.cfg | 234 +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 479 insertions(+) > create mode 100644 docs/mach-virt-graphical.cfg > create mode 100644 docs/mach-virt-serial.cfg > > diff --git a/docs/mach-virt-graphical.cfg b/docs/mach-virt-graphical.cfg > new file mode 100644 > index 0000000..d942394 > --- /dev/null > +++ b/docs/mach-virt-graphical.cfg > @@ -0,0 +1,245 @@ > +# mach-virt - VirtIO guest (graphical console) > +# ========================================================= > +# > +# You will probably need to tweak the lines marked as > +# CHANGE ME before being able to use this configuration! > +# > +# Usage: > +# > +# $ qemu-system-aarch64 \ > +# -nodefaults \ > +# -readconfig mach-virt-graphical.cfg \ > +# -cpu host > +# > +# The guest will have a selection of VirtIO devices > +# tailored towards optimal performance with modern guests, > +# and will be accessed through a graphical console. > +# > +# --------------------------------------------------------- > +# > +# Using -nodefaults is required to have full control over > +# the virtual hardware: when it's specified, QEMU will > +# create a bare machine with just the very essential > +# chipset devices being present: > +# > +# 00:00.0 Host bridge I see Peter and you are discussing what to document here. IMO, we should simply state -nodefaults provides us a base mach-virt board with no peripherals. If we were to list all the platform devices then we add another place to maintain every time we change the board code. It would just be a matter of time before they're out of synch. > +# > +# This configuration file adds a number of other useful > +# devices, more specifically: > +# > +# 00:01.0 Display controller > +# 00.1c.* PCI bridge (PCI Express Root Ports) > +# 01:00.0 SCSI storage controller > +# 02:00.0 Ethernet controller > +# 03:00.0 USB controller > +# > +# More information about these devices is available below. > + > + > +# Machine options > +# ========================================================= > +# > +# We use the virt machine type and enable KVM acceleration > +# for better performance. > +# > +# Using less than 1 GiB of memory is probably not going to > +# yield good performance in the guest, and might even lead > +# to obscure boot issues in some cases. > +# > +# Unfortunately, there is no way to configure the CPU model > +# in this file, so it will have to be provided on the > +# command line. > + > +[machine] > + type = "virt" > + accel = "kvm" > + > +[memory] > + size = "1024" So I'm not sure about providing this, at least not in this config file. I think we should expect the user to provide ram size explicitly, as this depends on what they want to do with the guest. Even accel is debatable, as many users may want to use tcg from their x86 machines. How about focusing this config on the PCIe topology and default devices? Additional config defaults like accel and ram could be added to an additional config, if we want. > + > + > +# Firmware configuration > +# ========================================================= > +# > +# There are two parts to the firmware: a read-only image > +# containing the executable code, which is shared between > +# guests, and a read/write variable store that is used by > +# to record information such as the boot device. An empty > +# variable store can be created by simply copying a > +# template provided as part of AAVMF. > +# > +# Depending on the distribution you're using on the host, > +# paths to the firmware itself and variable store template > +# will be different. Some examples: > +# > +# Fedora: > +# /usr/share/edk2/aarch64/QEMU_EFI.fd > +# /usr/share/edk2/aarch64/QEMU_VARS.fd > +# RHEL: > +# /usr/share/AAVMF/AAVMF_CODE.fd > +# /usr/share/AAVMF/AAVMF_VARS.fd > + > +[drive "aavmf-code"] > + file = "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME > + format = "raw" > + if = "pflash" > + unit = "0" > + readonly = "on" > + > +[drive "aavmf-vars"] > + file = "guest_VARS.fd" # CHANGE ME > + format = "raw" > + if = "pflash" > + unit = "1" The fact these entries need 'CHANGE ME' comments make me think they should also be removed from this config and required explicitly, or provided by other configs. Perhaps we can create a config for each firmware path we know of? Or, is there any way for a user to override the file path from the command line? Does -readconfig config -drive id=aavmf-vars,file=new-path work? If so, then we can document how CHANGEME's can be easily changed without touching the file. > + > + > +# PCI bridge (PCI Express Root Ports) > +# ========================================================= > +# > +# We create eight PCI Express Root Ports, and we plug them > +# all into separate functions of the same slot. Some of > +# them will be used by devices, the rest will remain > +# available for hotplug. > + > +[device "pci.1"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.0" > + port = "1" > + chassis = "1" > + multifunction = "on" > + > +[device "pci.2"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.1" > + port = "2" > + chassis = "2" > + > +[device "pci.3"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.2" > + port = "3" > + chassis = "3" > + > +[device "pci.4"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.3" > + port = "4" > + chassis = "4" > + > +[device "pci.5"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.4" > + port = "5" > + chassis = "5" > + > +[device "pci.6"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.5" > + port = "6" > + chassis = "6" > + > +[device "pci.7"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.6" > + port = "7" > + chassis = "7" > + > +[device "pci.8"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.7" > + port = "8" > + chassis = "8" > + > + > +# SCSI storage controller (and storage) > +# ========================================================= > +# > +# We use virtio-scsi here so that we can (hot)plug a large > +# number of disks without running into issues; a SCSI disk, > +# backed by a qcow2 disk image on the host's filesystem, is > +# attached to it. > + > +[device "scsi"] > + driver = "virtio-scsi-pci" > + bus = "pci.1" > + addr = "00.0" > + > +[device "scsi-disk"] > + driver = "scsi-hd" > + bus = "scsi.0" > + drive = "disk" > + > +[drive "disk"] > + file = "guest.qcow2" # CHANGE ME > + format = "qcow2" > + if = "none" > + > + > +# Ethernet controller > +# ========================================================= > +# > +# We use virtio-net for improved performance over emulated > +# hardware; on the host side, we take advantage of user > +# networking so that the QEMU process doesn't require any > +# additional privileges. > + > +[netdev "hostnet"] > + type = "user" > + > +[device "net"] > + driver = "virtio-net-pci" > + netdev = "hostnet" > + bus = "pci.2" > + addr = "00.0" > + > + > +# USB controller (and input devices) > +# ========================================================= > +# > +# We add a virtualization-friendly USB 3.0 controller and > +# a USB keyboard / USB tablet combo so that graphical > +# guests can be controlled appropriately. > + > +[device "usb"] > + driver = "nec-usb-xhci" > + bus = "pci.3" > + addr = "00.0" > + > +[device "keyboard"] > + driver = "usb-kbd" > + bus = "usb.0" > + > +[device "tablet"] > + driver = "usb-tablet" > + bus = "usb.0" > + > + > +# Display controller > +# ========================================================= > +# > +# We use virtio-gpu because the legacy VGA framebuffer is > +# very troublesome on aarch64, and virtio-gpu is the only We use virtio-gpu because emulating a legacy VGA framebuffer is not possible on AArch64 KVM guests due to unavoidable stage1 / stage2 page table cache mode mismatches. Or just leave the troublesome comment... > +# video device that doesn't implement it. > +# > +# If you're running the guest on a remote, potentially > +# headless host, you will probably want to append something > +# like > +# > +# -display vnc=127.0.0.1:0 > +# > +# to the command line in order to prevent QEMU from trying > +# to display a GTK+ window on the host and enable remote > +# access instead. > + > +[device "video"] > + driver = "virtio-gpu" > + bus = "pcie.0" > + addr = "01.0" > diff --git a/docs/mach-virt-serial.cfg b/docs/mach-virt-serial.cfg > new file mode 100644 > index 0000000..6bf8cb2 > --- /dev/null > +++ b/docs/mach-virt-serial.cfg > @@ -0,0 +1,234 @@ > +# mach-virt - VirtIO guest (serial console) > +# ========================================================= > +# > +# You will probably need to tweak the lines marked as > +# CHANGE ME before being able to use this configuration! > +# > +# Usage: > +# > +# $ qemu-system-aarch64 \ > +# -nographic -nodefaults \ > +# -readconfig mach-virt-serial.cfg \ > +# -cpu host > +# > +# The guest will have a selection of VirtIO devices > +# tailored towards optimal performance with modern guests, > +# and will be accessed through the serial console. > +# > +# --------------------------------------------------------- > +# > +# We need -nographic to prevent QEMU from creating an empty > +# display window, which we're not interested in. > +# > +# Using -nodefaults is required to have full control over > +# the virtual hardware: when it's specified, QEMU will > +# create a bare machine with just the very essential > +# chipset devices being present: > +# > +# 00:00.0 Host bridge > +# > +# This configuration file adds a number of other useful > +# devices, more specifically: > +# > +# 00.1c.* PCI bridge (PCI Express Root Ports) > +# 01:00.0 SCSI storage controller > +# 02:00.0 Ethernet controller > +# 03:00.0 Communication controller (serial console) > +# > +# More information about these devices is available below. > + > + > +# Machine options > +# ========================================================= > +# > +# We use the virt machine type and enable KVM acceleration > +# for better performance. > +# > +# Using less than 1 GiB of memory is probably not going to > +# yield good performance in the guest, and might even lead > +# to obscure boot issues in some cases. > +# > +# Unfortunately, there is no way to configure the CPU model > +# in this file, so it will have to be provided on the > +# command line. > + > +[machine] > + type = "virt" > + accel = "kvm" > + > +[memory] > + size = "1024" > + > + > +# Firmware configuration > +# ========================================================= > +# > +# There are two parts to the firmware: a read-only image > +# containing the executable code, which is shared between > +# guests, and a read/write variable store that is used by > +# to record information such as the boot device. An empty > +# variable store can be created by simply copying a > +# template provided as part of AAVMF. > +# > +# Depending on the distribution you're using on the host, > +# paths to the firmware itself and variable store template > +# will be different. Some examples: > +# > +# Fedora: > +# /usr/share/edk2/aarch64/QEMU_EFI.fd > +# /usr/share/edk2/aarch64/QEMU_VARS.fd > +# RHEL: > +# /usr/share/AAVMF/AAVMF_CODE.fd > +# /usr/share/AAVMF/AAVMF_VARS.fd > + > +[drive "aavmf-code"] > + file = "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME > + format = "raw" > + if = "pflash" > + unit = "0" > + readonly = "on" > + > +[drive "aavmf-vars"] > + file = "guest_VARS.fd" # CHANGE ME > + format = "raw" > + if = "pflash" > + unit = "1" > + > + > +# PCI bridge (PCI Express Root Ports) > +# ========================================================= > +# > +# We create eight PCI Express Root Ports, and we plug them > +# all into separate functions of the same slot. Some of > +# them will be used by devices, the rest will remain > +# available for hotplug. > + > +[device "pci.1"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.0" > + port = "1" > + chassis = "1" > + multifunction = "on" > + > +[device "pci.2"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.1" > + port = "2" > + chassis = "2" > + > +[device "pci.3"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.2" > + port = "3" > + chassis = "3" > + > +[device "pci.4"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.3" > + port = "4" > + chassis = "4" > + > +[device "pci.5"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.4" > + port = "5" > + chassis = "5" > + > +[device "pci.6"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.5" > + port = "6" > + chassis = "6" > + > +[device "pci.7"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.6" > + port = "7" > + chassis = "7" > + > +[device "pci.8"] > + driver = "pcie-root-port" > + bus = "pcie.0" > + addr = "1c.7" > + port = "8" > + chassis = "8" > + > + > +# SCSI storage controller (and storage) > +# ========================================================= > +# > +# We use virtio-scsi here so that we can (hot)plug a large > +# number of disks without running into issues; a SCSI disk, > +# backed by a qcow2 disk image on the host's filesystem, is > +# attached to it. > + > +[device "scsi"] > + driver = "virtio-scsi-pci" > + bus = "pci.1" > + addr = "00.0" > + > +[device "scsi-disk"] > + driver = "scsi-hd" > + bus = "scsi.0" > + drive = "disk" > + > +[drive "disk"] > + file = "guest.qcow2" # CHANGE ME > + format = "qcow2" > + if = "none" > + > + > +# Ethernet controller > +# ========================================================= > +# > +# We use virtio-net for improved performance over emulated > +# hardware; on the host side, we take advantage of user > +# networking so that the QEMU process doesn't require any > +# additional privileges. > + > +[netdev "hostnet"] > + type = "user" > + > +[device "net"] > + driver = "virtio-net-pci" > + netdev = "hostnet" > + bus = "pci.2" > + addr = "00.0" > + > + > +# Communication controller (serial console) > +# ========================================================= > +# > +# We use virtconsole along with virtio-serial, and connect > +# it with the host's standard input / output channels. In > +# this configuration, the guest will behave pretty much > +# like any other Unix utility: that includes terminating > +# as soon as Ctrl-C is pressed, so caution is advised. > +# > +# If you want to use the platform's native serial console > +# instead, you should comment out this section and append > +# > +# -serial stdio > +# > +# to the QEMU command line. Doing so might be needed to be > +# able to access the GRUB menu or see the output from the > +# boot process. > + > +[chardev "hostconsole"] > + backend = "stdio" > + > +[device "serial"] > + driver = "virtio-serial-pci" > + bus = "pci.3" > + addr = "00.0" > + > +[device "console"] > + driver = "virtconsole" > + chardev = "hostconsole" > -- > 2.7.4 > > I agree with the comments of others that we should be using the PL011 instead. We should also set it up such that the monitor is multiplexed, so ^C won't terminate the guest and ^A will allow us to go to the monitor. Thanks, drew
On Wed, Feb 08, 2017 at 07:11:42PM +0100, Laszlo Ersek wrote: > > +# RHEL: > > +# /usr/share/AAVMF/AAVMF_CODE.fd > > +# /usr/share/AAVMF/AAVMF_VARS.fd > > Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context > -- no clue. Ask Drew :)) > The first choice "RHEL" is correct. "RHELSA" still exists today, but eventually that name should be phased out (IIUC), as AArch64 will be "just another RHEL arch", requiring no special name. Thanks, drew
On 9 February 2017 at 09:42, Andrew Jones <drjones@redhat.com> wrote: > I see Peter and you are discussing what to document here. IMO, > we should simply state -nodefaults provides us a base mach-virt > board with no peripherals. The thing about saying that is that it's not actually correct -- you get the UART, etc etc peripherals whether you say -nodefaults or not. I agree that listing them in multiple places isn't a good idea though. Maybe there's some wording that will work here. thanks -- PMM
On Thu, 2017-02-09 at 09:57 +0000, Peter Maydell wrote: > > I see Peter and you are discussing what to document here. IMO, > > we should simply state -nodefaults provides us a base mach-virt > > board with no peripherals. > > The thing about saying that is that it's not actually > correct -- you get the UART, etc etc peripherals whether > you say -nodefaults or not. I agree that listing them > in multiple places isn't a good idea though. Maybe > there's some wording that will work here. Agreed, we just have to find the right wording. Would something like Using -nodefaults is required to have full control over the virtual hardware: when it's specified, QEMU will only automatically add a small selection of core PCI devices, and leave the user in charge of adding more as they see fit. More specifically, the PCI devices that will always be present are: 00:00.0 Host bridge This configuration file adds a number of other... work for you? Please keep in mind that I want to be able to use the very same paragraph both for q35 and mach-virt. -- Andrea Bolognani / Red Hat / Virtualization
On Thu, 2017-02-09 at 10:49 +0100, Andrew Jones wrote: > > > +# RHEL: > > > +# /usr/share/AAVMF/AAVMF_CODE.fd > > > +# /usr/share/AAVMF/AAVMF_VARS.fd > > > > Looks legit. (Might want to call "RHEL" "RHELSA" though, in this context > > -- no clue. Ask Drew :)) > > The first choice "RHEL" is correct. "RHELSA" still exists today, > but eventually that name should be phased out (IIUC), as AArch64 > will be "just another RHEL arch", requiring no special name. Can't wait for that day! I'll leave it unchanged then :) -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Feb 09, 2017 at 11:51:13AM +0100, Andrea Bolognani wrote: > On Thu, 2017-02-09 at 09:57 +0000, Peter Maydell wrote: > > > I see Peter and you are discussing what to document here. IMO, > > > we should simply state -nodefaults provides us a base mach-virt > > > board with no peripherals. > > > > The thing about saying that is that it's not actually > > correct -- you get the UART, etc etc peripherals whether > > you say -nodefaults or not. I agree that listing them > > in multiple places isn't a good idea though. Maybe > > there's some wording that will work here. > > Agreed, we just have to find the right wording. Would > something like > > Using -nodefaults is required to have full control over > the virtual hardware: when it's specified, QEMU will > only automatically add a small selection of core PCI > devices, and leave the user in charge of adding more as > they see fit. More specifically, the PCI devices that > will always be present are: > > 00:00.0 Host bridge > > This configuration file adds a number of other... > > work for you? Please keep in mind that I want to be able > to use the very same paragraph both for q35 and mach-virt. I'm not sure having the exact same paragraph is a reasonable goal. Does q35 have platform devices like mach-virt? The devices we get on a 'qemu -nodefaults -machine virt' instance are MMIO driven devices on the board, rather than devices hung off the pcie host bridge. Perhaps we can list the uart as an example; I don't suppose it'll ever be removed. If we use wording such as "such as", then it allows expansion to the board without a commitment to update the list. BTW, when I stated "-nodefaults provides us a base mach-virt board with no peripherals.", I meant no _additional_ peripherals plugged into the board's virtio-mmio transports, nor hung off the host bridge. Is there a word for those? Maybe just non-builtin peripherals? Thanks, drew > > -- > Andrea Bolognani / Red Hat / Virtualization >
On Thu, 2017-02-09 at 10:42 +0100, Andrew Jones wrote: > > +[machine] > > + type = "virt" > > + accel = "kvm" > > + > > +[memory] > > + size = "1024" > > So I'm not sure about providing this, at least not in this > config file. I think we should expect the user to provide ram > size explicitly, as this depends on what they want to do with > the guest. Even accel is debatable, as many users may want to > use tcg from their x86 machines. > > How about focusing this config on the PCIe topology and default > devices? Additional config defaults like accel and ram could > be added to an additional config, if we want. Well, this is a sample configuration, not a one-size-fits-all solution. It's okay for it to be opinionated. The way I expect this file to be consumed is that people will copy it over[1] to some location, tweak it to their liking by adding and removing devices and altering settings such as memory size, then use it to start a specific guest from that moment on. When they need another guest, they can make another copy of the sample and start over. So the least parameters the user will have to specify outside of the configuration file, the better. We actually moved *away* from the idea of including multiple configuration files (one for the "common" parts such as PCIe controllers, one for other devices such as the video card as opposed to the serial console) because it's much easier to have everything in one place, for usability and for documentation purposes. It's not a framework, just a decent starting point. [...] > > +[drive "aavmf-code"] > > + file = "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME > > + format = "raw" > > + if = "pflash" > > + unit = "0" > > + readonly = "on" > > + > > +[drive "aavmf-vars"] > > + file = "guest_VARS.fd" # CHANGE ME > > + format = "raw" > > + if = "pflash" > > + unit = "1" > > The fact these entries need 'CHANGE ME' comments make me think they > should also be removed from this config and required explicitly, > or provided by other configs. Perhaps we can create a config for > each firmware path we know of? Or, is there any way for a user > to override the file path from the command line? Does > > -readconfig config -drive id=aavmf-vars,file=new-path > > work? If so, then we can document how CHANGEME's can be easily > changed without touching the file. See above. [...] > > +# Display controller > > +# ========================================================= > > +# > > +# We use virtio-gpu because the legacy VGA framebuffer is > > +# very troublesome on aarch64, and virtio-gpu is the only > > We use virtio-gpu because emulating a legacy VGA framebuffer > is not possible on AArch64 KVM guests due to unavoidable > stage1 / stage2 page table cache mode mismatches. > > Or just leave the troublesome comment... I guess that depends a lot on how low-level we want them be... Overall, I kept them fairly high-level, not least because that's pretty much as far my knowledge goes. In other words, your take on the description is certainly 100% accurate but also 100% flying way over my head ;) [...] > I agree with the comments of others that we should be using > the PL011 instead. We should also set it up such that the > monitor is multiplexed, so ^C won't terminate the guest and > ^A will allow us to go to the monitor. That sounds awesome, how do I actually make it work from the configuration file though? [1] Looks like these files are not being installed on the system by 'make install'. I'd argue having them in /usr/share/doc/qemu/examples would be nice for users. -- Andrea Bolognani / Red Hat / Virtualization
On Wed, 2017-02-08 at 19:36 +0000, Peter Maydell wrote: > > When -nodefaults is missing, a default virtio-net-pci > > plugged into 00:01.0 is automatically added. > > Ah, right, default -net commands. Is that it? I believe so, but double checking is never the wrong thing to do ;) > > On the other hand, I just realized that I can add > > > > [machine] > > graphics = "off" > > > > to get rid of -nographic on the command line! \o/ ... and after writing this, I actually tested it and realized that it doesn't quite do what I want it to :( > -nographic is kind of odd if you're taking the > "use -nodefaults and specify everything manually" > because it wraps up a whole pile of default config > in one oddball legacy config switch. I would have > expected -display none and whatever other options > you wanted. -nographic is just what libvirt uses: if there's a better way to achieve the same result then I'm all for it! Seems like '-display none' behaves the same as -nographic, at least for my purposes. Unfortunately I still can't have it inside the configuration file, it has to be on the command line :( [...] > > Moreover, something that I haven't been able to do on > > mach-virt (even though I could on q35, but again, I want the > > files to be as close as possible) is to configure the serial > > console from the configuration file. > > If there's stuff we can fix in the virt board to make > this work the way it does on the PC model I'm happy > to make fixes to help. Well, with a q35 guest I can just add [chardev "hostconsole"] backend = "stdio" [device "console"] driver = "isa-serial" chardev = "hostconsole" to the configuration file and get the same behavior I would get by adding '-serial stdio' to the command line, but I haven't been able to find any device that I can use the same way as isa-serial on mach-virt. Maybe I just missed it? [...] > The trouble with using virtconsole is that you have to > get quite a long way forward (probing and setting up > PCI, etc) before you can get any kind of console output. > "System doesn't boot and doesn't produce any output" > is a common and really annoying failure mode in the > ARM world, and I think that using virtconsole is > asking for that kind of thing to happen more rather > than less often. (Plus having two different serial > ports in the guest means that now the user has to > configure where both of them are supposed to output.) You don't get one unless you use '-serial stdio' or something like that in my experience, so if you use the sample configuration file as I posted it you will only get one serial console, the VirtIO-based one. I agree though that the lack of boot output and especially GRUB menu access in virtconsole is less then ideal, because even though the users will eventually get a login prompt, the first few seconds without any output at all might lead them to believe the guest is not working properly. I just wish there were a way to add the default serial console straight from the configuration file... -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Feb 09, 2017 at 02:27:45PM +0100, Andrea Bolognani wrote: > On Thu, 2017-02-09 at 10:42 +0100, Andrew Jones wrote: > > > +[machine] > > > + type = "virt" > > > + accel = "kvm" > > > + > > > +[memory] > > > + size = "1024" > > > > So I'm not sure about providing this, at least not in this > > config file. I think we should expect the user to provide ram > > size explicitly, as this depends on what they want to do with > > the guest. Even accel is debatable, as many users may want to > > use tcg from their x86 machines. > > > > How about focusing this config on the PCIe topology and default > > devices? Additional config defaults like accel and ram could > > be added to an additional config, if we want. > > Well, this is a sample configuration, not a one-size-fits-all > solution. It's okay for it to be opinionated. > > The way I expect this file to be consumed is that people will > copy it over[1] to some location, tweak it to their liking by > adding and removing devices and altering settings such as > memory size, then use it to start a specific guest from that > moment on. When they need another guest, they can make another > copy of the sample and start over. > > So the least parameters the user will have to specify outside > of the configuration file, the better. We actually moved *away* > from the idea of including multiple configuration files (one > for the "common" parts such as PCIe controllers, one for other > devices such as the video card as opposed to the serial > console) because it's much easier to have everything in one > place, for usability and for documentation purposes. > > It's not a framework, just a decent starting point. OK, if that's the consensus on how they should be used, then that's fine by me. I've actually never used files like these, but I was imagining they'd be great to use like this qemu -nodefaults -readconfig configfile -more -params \ -that -may -override -stuff -in -the -configfile Actually, I don't think anything is stopping me from using this file that way. I'll have to try the file name override that I suggested below, but qemu -nodefaults -readconfig configfile -m $MEM -machine accel=tcg should certainly override correctly. > > [...] > > > +[drive "aavmf-code"] > > > + file = "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME > > > + format = "raw" > > > + if = "pflash" > > > + unit = "0" > > > + readonly = "on" > > > + > > > +[drive "aavmf-vars"] > > > + file = "guest_VARS.fd" # CHANGE ME > > > + format = "raw" > > > + if = "pflash" > > > + unit = "1" > > > > The fact these entries need 'CHANGE ME' comments make me think they > > should also be removed from this config and required explicitly, > > or provided by other configs. Perhaps we can create a config for > > each firmware path we know of? Or, is there any way for a user > > to override the file path from the command line? Does > > > > -readconfig config -drive id=aavmf-vars,file=new-path > > > > work? If so, then we can document how CHANGEME's can be easily > > changed without touching the file. > > See above. > > [...] > > > +# Display controller > > > +# ========================================================= > > > +# > > > +# We use virtio-gpu because the legacy VGA framebuffer is > > > +# very troublesome on aarch64, and virtio-gpu is the only > > > > We use virtio-gpu because emulating a legacy VGA framebuffer > > is not possible on AArch64 KVM guests due to unavoidable > > stage1 / stage2 page table cache mode mismatches. > > > > Or just leave the troublesome comment... > > I guess that depends a lot on how low-level we want them > be... Overall, I kept them fairly high-level, not least > because that's pretty much as far my knowledge goes. > > In other words, your take on the description is certainly > 100% accurate but also 100% flying way over my head ;) > > [...] > > I agree with the comments of others that we should be using > > the PL011 instead. We should also set it up such that the > > monitor is multiplexed, so ^C won't terminate the guest and > > ^A will allow us to go to the monitor. > > That sounds awesome, how do I actually make it work from > the configuration file though? Sorry, dunno :-) > > > [1] Looks like these files are not being installed on the > system by 'make install'. I'd argue having them in > /usr/share/doc/qemu/examples would be nice for users. I agree. Thanks, drew
On Thu, Feb 09, 2017 at 02:53:52PM +0100, Andrea Bolognani wrote: > On Wed, 2017-02-08 at 19:36 +0000, Peter Maydell wrote: > > The trouble with using virtconsole is that you have to > > get quite a long way forward (probing and setting up > > PCI, etc) before you can get any kind of console output. > > "System doesn't boot and doesn't produce any output" > > is a common and really annoying failure mode in the > > ARM world, and I think that using virtconsole is > > asking for that kind of thing to happen more rather > > than less often. (Plus having two different serial > > ports in the guest means that now the user has to > > configure where both of them are supposed to output.) > > You don't get one unless you use '-serial stdio' or > something like that in my experience, so if you use the > sample configuration file as I posted it you will only > get one serial console, the VirtIO-based one. The emulated UART is there no matter what, it's built-in on the board. Whether it gets wired up to the console, stdio in this case, depends on the '-serial stdio'. Adding the virtio- console introduces another serial port, but OSes can still discover the PL011 and try to use that in addition. Thanks, drew
On Thu, 2017-02-09 at 15:08 +0100, Andrew Jones wrote: [...] > Actually, I don't think anything is stopping me from using this > file that way. I'll have to try the file name override that I > suggested below, but > > qemu -nodefaults -readconfig configfile -m $MEM -machine accel=tcg > > should certainly override correctly. I just tried and at least overriding the amount of memory definitely works :) > > > I agree with the comments of others that we should be using > > > the PL011 instead. We should also set it up such that the > > > monitor is multiplexed, so ^C won't terminate the guest and > > > ^A will allow us to go to the monitor. > > > > That sounds awesome, how do I actually make it work from > > the configuration file though? > > Sorry, dunno :-) I don't think there's a way to make it work without adding some parameters to the command line, I'm afraid :( But if you use '-serial mon:stdio' you can indeed switch between the serial console and the QEMU monitor at will, and as a (quite interesting) side-effect Ctrl+C will no longer kill QEMU :) By the way, switching between serial and monitor is not done with Ctrl+A but with Ctrl+A-c, which is not the most convenient shortcut if you're running your guests on a remote host due to GNU screen using the very same one ;) -- Andrea Bolognani / Red Hat / Virtualization
On Thu, 2017-02-09 at 13:28 +0100, Andrew Jones wrote: > > Please keep in mind that I want to be able > > to use the very same paragraph both for q35 and mach-virt. > > I'm not sure having the exact same paragraph is a reasonable > goal. If not the exact same, there is no reason for it not to be at least 90% shareable IMHO. > Does q35 have platform devices like mach-virt? I don't know. And I'm not sure we need to talk about them or their aarch64 counterparts at all in the sample configuration file, because AFAIK with the exception of the GIC version they are not user configurable, or at the very least not something the user will actively want to configure (correct me if I'm wrong). > The > devices we get on a 'qemu -nodefaults -machine virt' instance > are MMIO driven devices on the board, rather than devices > hung off the pcie host bridge. We want people to use PCIe instead of MMIO, though, so again why should we even mention those? It's just a sample configuration file we're talking about, not a complete reference of the aarch64 architecture, so it's entirely okay to skimp on details that don't directly impact most users and be opinionated. > Perhaps we can list the uart as an example; I don't suppose > it'll ever be removed. If we use wording such as "such as", > then it allows expansion to the board without a commitment to > update the list. > > BTW, when I stated "-nodefaults provides us a base mach-virt > board with no peripherals.", I meant no _additional_ > peripherals plugged into the board's virtio-mmio transports, > nor hung off the host bridge. Is there a word for those? > Maybe just non-builtin peripherals? Please propose the alternative wording you'd like to see so we can discuss it :) -- Andrea Bolognani / Red Hat / Virtualization
Hi, > By the way, switching between serial and monitor is not > done with Ctrl+A but with Ctrl+A-c, which is not the most > convenient shortcut if you're running your guests on a > remote host due to GNU screen using the very same one ;) And for the record: "Ctrl+a h" prints a list of hotkeys. cheers, Gerd
On Thu, Feb 09, 2017 at 04:10:43PM +0100, Andrea Bolognani wrote: > On Thu, 2017-02-09 at 13:28 +0100, Andrew Jones wrote: > > > Please keep in mind that I want to be able > > > to use the very same paragraph both for q35 and mach-virt. > > > > I'm not sure having the exact same paragraph is a reasonable > > goal. > > If not the exact same, there is no reason for it not to > be at least 90% shareable IMHO. > > > Does q35 have platform devices like mach-virt? > > I don't know. And I'm not sure we need to talk about them > or their aarch64 counterparts at all in the sample > configuration file, because AFAIK with the exception of the > GIC version they are not user configurable, or at the very > least not something the user will actively want to > configure (correct me if I'm wrong). I'm OK with not mentioning them "too much" in this file. I agree with Peter though that to be more accurate we shouldn't state that '-nodefaults' results in a machine with nothing. Therefore, some wording that states -nodefaults ensures no non-builtin peripherals are automatically added, but builtin peripherals, such as the PL011, will remain, seems like a good idea. > > > The > > devices we get on a 'qemu -nodefaults -machine virt' instance > > are MMIO driven devices on the board, rather than devices > > hung off the pcie host bridge. > > We want people to use PCIe instead of MMIO, though, so > again why should we even mention those? We want to use virtio-pci devices, as opposed to virtio-mmio devices, which means using the PCIe ports you add vs. the virtio-mmio transports. That doesn't mean we don't still want to use the MMIO devices builtin to the board though, the PL011 (UART) being a prime example. > > It's just a sample configuration file we're talking about, > not a complete reference of the aarch64 architecture, so > it's entirely okay to skimp on details that don't directly > impact most users and be opinionated. I agree with being skimpy, but we don't want to cross the line into misleading. > > > Perhaps we can list the uart as an example; I don't suppose > > it'll ever be removed. If we use wording such as "such as", > > then it allows expansion to the board without a commitment to > > update the list. > > > > BTW, when I stated "-nodefaults provides us a base mach-virt > > board with no peripherals.", I meant no _additional_ > > peripherals plugged into the board's virtio-mmio transports, > > nor hung off the host bridge. Is there a word for those? > > Maybe just non-builtin peripherals? > > Please propose the alternative wording you'd like to see > so we can discuss it :) I guess I did above with "... -nodefaults ensures no non-builtin peripherals are automatically added, but builtin peripherals, such as the PL011, will remain..." Thanks, drew
On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote: > > Please propose the alternative wording you'd like to see > > so we can discuss it :) > > I guess I did above with "... -nodefaults ensures no non-builtin > peripherals are automatically added, but builtin peripherals, > such as the PL011, will remain..." Trying to work your proposal into my most recent stab at this, I ended up with: Using -nodefaults is required to have full control over the virtual hardware: when it's specified, QEMU will populate the board with only the builtin peripherals, such as the PL011 UART, plus a small selection of core PCI devices and controllers; the user will then have to esplicitly add further devices. More specifically, the PCI devices that will always be present in the guest are: 00:00.0 Host bridge This configuration file adds a number of other... Does it look acceptable? -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Feb 09, 2017 at 05:11:38PM +0100, Andrea Bolognani wrote: > On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote: > > > Please propose the alternative wording you'd like to see > > > so we can discuss it :) > > > > I guess I did above with "... -nodefaults ensures no non-builtin > > peripherals are automatically added, but builtin peripherals, > > such as the PL011, will remain..." > > Trying to work your proposal into my most recent stab at > this, I ended up with: > > Using -nodefaults is required to have full control over > the virtual hardware: when it's specified, QEMU will > populate the board with only the builtin peripherals, > such as the PL011 UART, plus a small selection of core > PCI devices and controllers; the user will then have to Well, mach-virt doesn't currently add any pci devices with -nodefault; just the host bridge. Personally, I'd state it that way to avoid confusion, but I know you're trying to keep the paragraph similar to the q35 one, and you're not technically wrong... > esplicitly add further devices. explicitly > > More specifically, the PCI devices that will always be > present in the guest are: > > 00:00.0 Host bridge > > This configuration file adds a number of other... > > Does it look acceptable? I'm good with it. Thanks, drew
On Thu, 2017-02-09 at 17:36 +0100, Andrew Jones wrote: > On Thu, Feb 09, 2017 at 05:11:38PM +0100, Andrea Bolognani wrote: > > > > On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote: > > > > > > > > > > > Please propose the alternative wording you'd like to see > > > > so we can discuss it :) > > > > > > I guess I did above with "... -nodefaults ensures no non-builtin > > > peripherals are automatically added, but builtin peripherals, > > > such as the PL011, will remain..." > > > > Trying to work your proposal into my most recent stab at > > this, I ended up with: > > > > Using -nodefaults is required to have full control over > > the virtual hardware: when it's specified, QEMU will > > populate the board with only the builtin peripherals, > > such as the PL011 UART, plus a small selection of core > > PCI devices and controllers; the user will then have to > > Well, mach-virt doesn't currently add any pci devices with > -nodefault; just the host bridge. Personally, I'd state it that > way to avoid confusion, but I know you're trying to keep the > paragraph similar to the q35 one, and you're not technically > wrong... Okay, one more try! ;) Using -nodefaults is required to have full control over the virtual hardware: when it's specified, QEMU will populate the board with only the builtin peripherals, such as the PL011 UART, plus a PCI Express Root Bus; the user will then have to explicitly add further devices. The PCI Express Root Bus shows up in the guest as: 00:00.0 Host bridge This configuration file adds a number of... -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Feb 09, 2017 at 06:06:19PM +0100, Andrea Bolognani wrote: > On Thu, 2017-02-09 at 17:36 +0100, Andrew Jones wrote: > > On Thu, Feb 09, 2017 at 05:11:38PM +0100, Andrea Bolognani wrote: > > > > > > On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote: > > > > > > > > > > > > > > Please propose the alternative wording you'd like to see > > > > > so we can discuss it :) > > > > > > > > I guess I did above with "... -nodefaults ensures no non-builtin > > > > peripherals are automatically added, but builtin peripherals, > > > > such as the PL011, will remain..." > > > > > > Trying to work your proposal into my most recent stab at > > > this, I ended up with: > > > > > > Using -nodefaults is required to have full control over > > > the virtual hardware: when it's specified, QEMU will > > > populate the board with only the builtin peripherals, > > > such as the PL011 UART, plus a small selection of core > > > PCI devices and controllers; the user will then have to > > > > Well, mach-virt doesn't currently add any pci devices with > > -nodefault; just the host bridge. Personally, I'd state it that > > way to avoid confusion, but I know you're trying to keep the > > paragraph similar to the q35 one, and you're not technically > > wrong... > > Okay, one more try! ;) > > Using -nodefaults is required to have full control over > the virtual hardware: when it's specified, QEMU will > populate the board with only the builtin peripherals, > such as the PL011 UART, plus a PCI Express Root Bus; the > user will then have to explicitly add further devices. > > The PCI Express Root Bus shows up in the guest as: > > 00:00.0 Host bridge > > This configuration file adds a number of... > > -- > Andrea Bolognani / Red Hat / Virtualization Sounds good to me :-) Thanks, drew
diff --git a/docs/mach-virt-graphical.cfg b/docs/mach-virt-graphical.cfg new file mode 100644 index 0000000..d942394 --- /dev/null +++ b/docs/mach-virt-graphical.cfg @@ -0,0 +1,245 @@ +# mach-virt - VirtIO guest (graphical console) +# ========================================================= +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# Usage: +# +# $ qemu-system-aarch64 \ +# -nodefaults \ +# -readconfig mach-virt-graphical.cfg \ +# -cpu host +# +# The guest will have a selection of VirtIO devices +# tailored towards optimal performance with modern guests, +# and will be accessed through a graphical console. +# +# --------------------------------------------------------- +# +# Using -nodefaults is required to have full control over +# the virtual hardware: when it's specified, QEMU will +# create a bare machine with just the very essential +# chipset devices being present: +# +# 00:00.0 Host bridge +# +# This configuration file adds a number of other useful +# devices, more specifically: +# +# 00:01.0 Display controller +# 00.1c.* PCI bridge (PCI Express Root Ports) +# 01:00.0 SCSI storage controller +# 02:00.0 Ethernet controller +# 03:00.0 USB controller +# +# More information about these devices is available below. + + +# Machine options +# ========================================================= +# +# We use the virt machine type and enable KVM acceleration +# for better performance. +# +# Using less than 1 GiB of memory is probably not going to +# yield good performance in the guest, and might even lead +# to obscure boot issues in some cases. +# +# Unfortunately, there is no way to configure the CPU model +# in this file, so it will have to be provided on the +# command line. + +[machine] + type = "virt" + accel = "kvm" + +[memory] + size = "1024" + + +# Firmware configuration +# ========================================================= +# +# There are two parts to the firmware: a read-only image +# containing the executable code, which is shared between +# guests, and a read/write variable store that is used by +# to record information such as the boot device. An empty +# variable store can be created by simply copying a +# template provided as part of AAVMF. +# +# Depending on the distribution you're using on the host, +# paths to the firmware itself and variable store template +# will be different. Some examples: +# +# Fedora: +# /usr/share/edk2/aarch64/QEMU_EFI.fd +# /usr/share/edk2/aarch64/QEMU_VARS.fd +# RHEL: +# /usr/share/AAVMF/AAVMF_CODE.fd +# /usr/share/AAVMF/AAVMF_VARS.fd + +[drive "aavmf-code"] + file = "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME + format = "raw" + if = "pflash" + unit = "0" + readonly = "on" + +[drive "aavmf-vars"] + file = "guest_VARS.fd" # CHANGE ME + format = "raw" + if = "pflash" + unit = "1" + + +# PCI bridge (PCI Express Root Ports) +# ========================================================= +# +# We create eight PCI Express Root Ports, and we plug them +# all into separate functions of the same slot. Some of +# them will be used by devices, the rest will remain +# available for hotplug. + +[device "pci.1"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.0" + port = "1" + chassis = "1" + multifunction = "on" + +[device "pci.2"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.1" + port = "2" + chassis = "2" + +[device "pci.3"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.2" + port = "3" + chassis = "3" + +[device "pci.4"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.3" + port = "4" + chassis = "4" + +[device "pci.5"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.4" + port = "5" + chassis = "5" + +[device "pci.6"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.5" + port = "6" + chassis = "6" + +[device "pci.7"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.6" + port = "7" + chassis = "7" + +[device "pci.8"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.7" + port = "8" + chassis = "8" + + +# SCSI storage controller (and storage) +# ========================================================= +# +# We use virtio-scsi here so that we can (hot)plug a large +# number of disks without running into issues; a SCSI disk, +# backed by a qcow2 disk image on the host's filesystem, is +# attached to it. + +[device "scsi"] + driver = "virtio-scsi-pci" + bus = "pci.1" + addr = "00.0" + +[device "scsi-disk"] + driver = "scsi-hd" + bus = "scsi.0" + drive = "disk" + +[drive "disk"] + file = "guest.qcow2" # CHANGE ME + format = "qcow2" + if = "none" + + +# Ethernet controller +# ========================================================= +# +# We use virtio-net for improved performance over emulated +# hardware; on the host side, we take advantage of user +# networking so that the QEMU process doesn't require any +# additional privileges. + +[netdev "hostnet"] + type = "user" + +[device "net"] + driver = "virtio-net-pci" + netdev = "hostnet" + bus = "pci.2" + addr = "00.0" + + +# USB controller (and input devices) +# ========================================================= +# +# We add a virtualization-friendly USB 3.0 controller and +# a USB keyboard / USB tablet combo so that graphical +# guests can be controlled appropriately. + +[device "usb"] + driver = "nec-usb-xhci" + bus = "pci.3" + addr = "00.0" + +[device "keyboard"] + driver = "usb-kbd" + bus = "usb.0" + +[device "tablet"] + driver = "usb-tablet" + bus = "usb.0" + + +# Display controller +# ========================================================= +# +# We use virtio-gpu because the legacy VGA framebuffer is +# very troublesome on aarch64, and virtio-gpu is the only +# video device that doesn't implement it. +# +# If you're running the guest on a remote, potentially +# headless host, you will probably want to append something +# like +# +# -display vnc=127.0.0.1:0 +# +# to the command line in order to prevent QEMU from trying +# to display a GTK+ window on the host and enable remote +# access instead. + +[device "video"] + driver = "virtio-gpu" + bus = "pcie.0" + addr = "01.0" diff --git a/docs/mach-virt-serial.cfg b/docs/mach-virt-serial.cfg new file mode 100644 index 0000000..6bf8cb2 --- /dev/null +++ b/docs/mach-virt-serial.cfg @@ -0,0 +1,234 @@ +# mach-virt - VirtIO guest (serial console) +# ========================================================= +# +# You will probably need to tweak the lines marked as +# CHANGE ME before being able to use this configuration! +# +# Usage: +# +# $ qemu-system-aarch64 \ +# -nographic -nodefaults \ +# -readconfig mach-virt-serial.cfg \ +# -cpu host +# +# The guest will have a selection of VirtIO devices +# tailored towards optimal performance with modern guests, +# and will be accessed through the serial console. +# +# --------------------------------------------------------- +# +# We need -nographic to prevent QEMU from creating an empty +# display window, which we're not interested in. +# +# Using -nodefaults is required to have full control over +# the virtual hardware: when it's specified, QEMU will +# create a bare machine with just the very essential +# chipset devices being present: +# +# 00:00.0 Host bridge +# +# This configuration file adds a number of other useful +# devices, more specifically: +# +# 00.1c.* PCI bridge (PCI Express Root Ports) +# 01:00.0 SCSI storage controller +# 02:00.0 Ethernet controller +# 03:00.0 Communication controller (serial console) +# +# More information about these devices is available below. + + +# Machine options +# ========================================================= +# +# We use the virt machine type and enable KVM acceleration +# for better performance. +# +# Using less than 1 GiB of memory is probably not going to +# yield good performance in the guest, and might even lead +# to obscure boot issues in some cases. +# +# Unfortunately, there is no way to configure the CPU model +# in this file, so it will have to be provided on the +# command line. + +[machine] + type = "virt" + accel = "kvm" + +[memory] + size = "1024" + + +# Firmware configuration +# ========================================================= +# +# There are two parts to the firmware: a read-only image +# containing the executable code, which is shared between +# guests, and a read/write variable store that is used by +# to record information such as the boot device. An empty +# variable store can be created by simply copying a +# template provided as part of AAVMF. +# +# Depending on the distribution you're using on the host, +# paths to the firmware itself and variable store template +# will be different. Some examples: +# +# Fedora: +# /usr/share/edk2/aarch64/QEMU_EFI.fd +# /usr/share/edk2/aarch64/QEMU_VARS.fd +# RHEL: +# /usr/share/AAVMF/AAVMF_CODE.fd +# /usr/share/AAVMF/AAVMF_VARS.fd + +[drive "aavmf-code"] + file = "/usr/share/edk2/aarch64/QEMU_EFI.fd" # CHANGE ME + format = "raw" + if = "pflash" + unit = "0" + readonly = "on" + +[drive "aavmf-vars"] + file = "guest_VARS.fd" # CHANGE ME + format = "raw" + if = "pflash" + unit = "1" + + +# PCI bridge (PCI Express Root Ports) +# ========================================================= +# +# We create eight PCI Express Root Ports, and we plug them +# all into separate functions of the same slot. Some of +# them will be used by devices, the rest will remain +# available for hotplug. + +[device "pci.1"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.0" + port = "1" + chassis = "1" + multifunction = "on" + +[device "pci.2"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.1" + port = "2" + chassis = "2" + +[device "pci.3"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.2" + port = "3" + chassis = "3" + +[device "pci.4"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.3" + port = "4" + chassis = "4" + +[device "pci.5"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.4" + port = "5" + chassis = "5" + +[device "pci.6"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.5" + port = "6" + chassis = "6" + +[device "pci.7"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.6" + port = "7" + chassis = "7" + +[device "pci.8"] + driver = "pcie-root-port" + bus = "pcie.0" + addr = "1c.7" + port = "8" + chassis = "8" + + +# SCSI storage controller (and storage) +# ========================================================= +# +# We use virtio-scsi here so that we can (hot)plug a large +# number of disks without running into issues; a SCSI disk, +# backed by a qcow2 disk image on the host's filesystem, is +# attached to it. + +[device "scsi"] + driver = "virtio-scsi-pci" + bus = "pci.1" + addr = "00.0" + +[device "scsi-disk"] + driver = "scsi-hd" + bus = "scsi.0" + drive = "disk" + +[drive "disk"] + file = "guest.qcow2" # CHANGE ME + format = "qcow2" + if = "none" + + +# Ethernet controller +# ========================================================= +# +# We use virtio-net for improved performance over emulated +# hardware; on the host side, we take advantage of user +# networking so that the QEMU process doesn't require any +# additional privileges. + +[netdev "hostnet"] + type = "user" + +[device "net"] + driver = "virtio-net-pci" + netdev = "hostnet" + bus = "pci.2" + addr = "00.0" + + +# Communication controller (serial console) +# ========================================================= +# +# We use virtconsole along with virtio-serial, and connect +# it with the host's standard input / output channels. In +# this configuration, the guest will behave pretty much +# like any other Unix utility: that includes terminating +# as soon as Ctrl-C is pressed, so caution is advised. +# +# If you want to use the platform's native serial console +# instead, you should comment out this section and append +# +# -serial stdio +# +# to the QEMU command line. Doing so might be needed to be +# able to access the GRUB menu or see the output from the +# boot process. + +[chardev "hostconsole"] + backend = "stdio" + +[device "serial"] + driver = "virtio-serial-pci" + bus = "pci.3" + addr = "00.0" + +[device "console"] + driver = "virtconsole" + chardev = "hostconsole"