Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device
(missed some cc's) On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
From: "Gabriel L. Somlo" <somlo@cmu.edu>
Hi Gabriel,
Several different architectures supported by QEMU are set up with a "firmware configuration" (fw_cfg) device, used to pass configuration "blobs" into the guest by the host running QEMU.
Historically, these config blobs were mostly of interest to the guest BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via the command line, which makes them potentially interesting to userspace (e.g. for passing early boot environment variables, etc.).
Does 'potentially interesting' mean you have a use case? Could you elaborate?
In addition to cc-ing the people and lists indicated by get-maintainer.pl, I've added a few extra lists suggested by Matt Fleming on the qemu-devel list, as well as the qemu-devel list itself.
Also cc-ing kernelnewbies, as this is my very first kenel contribution, so please go easy on me for whatever silly n00b mistakes I might have still missed, in spite of trying hard to do all my homework properly... :)
The series consists of three patches:
1/3 - probes for the qemu fw_cfg device in locations known to work on the supported architectures, in decreasing order of "likelihood".
While it *may* be possible to detect the presence of fw_cfg via acpi or dtb (on x86 and arm, respectively), there's no way I know of attempting that on sun4 and ppc/mac, so I've stuck with simply probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function) in fw_cfg.c. I could use some advice on how else that could be done more elegantly, if needed.
Sorry, but this is really out of the question, at least on ARM, but surely on other architectures as well. You can't just go around and probe random memory addresses. Perhaps QEMU tolerates it, but on anything that resembles a real system, this will immediately blow up. Also, what happens if the QEMU memory map changes? Add more probes addresses?
It is not /that/ difficult to simply wire it up to the DT and ACPI infrastructures, there are plenty of examples in the kernel tree how to accomplish that. As a bonus, it removes all the arch specific knowledge from your code, which means that if QEMU grows support for another DT or ACPI based architecture, it will just work.
I am not sure how relevant sun4 and ppc/mac are for what you are trying to accomplish, but perhaps it would be best to focus on x86 and ARM for now and do it correctly. If the probing is actually needed, you can always add it later.
-- Ard.
Hi Ard, On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
(missed some cc's)
On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
From: "Gabriel L. Somlo" <somlo@cmu.edu>
Several different architectures supported by QEMU are set up with a "firmware configuration" (fw_cfg) device, used to pass configuration "blobs" into the guest by the host running QEMU.
Historically, these config blobs were mostly of interest to the guest BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via the command line, which makes them potentially interesting to userspace (e.g. for passing early boot environment variables, etc.).
Does 'potentially interesting' mean you have a use case? Could you elaborate?
My personal one would be something like: cat > guestinfo.txt << EOT KEY1="val1" KEY2="val2" ... EOT qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ... Then, from inside the guest: . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw do_something_with $KEY1 $KEY2 ... But I'm thinking this is only one of the many positive things one could do with the ability to access random host-supplied blobs from guest userspace :)
1/3 - probes for the qemu fw_cfg device in locations known to work on the supported architectures, in decreasing order of "likelihood".
While it *may* be possible to detect the presence of fw_cfg via acpi or dtb (on x86 and arm, respectively), there's no way I know of attempting that on sun4 and ppc/mac, so I've stuck with simply probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function) in fw_cfg.c. I could use some advice on how else that could be done more elegantly, if needed.
Sorry, but this is really out of the question, at least on ARM, but surely on other architectures as well. You can't just go around and probe random memory addresses. Perhaps QEMU tolerates it, but on anything that resembles a real system, this will immediately blow up. Also, what happens if the QEMU memory map changes? Add more probes addresses?
It is not /that/ difficult to simply wire it up to the DT and ACPI infrastructures, there are plenty of examples in the kernel tree how to accomplish that. As a bonus, it removes all the arch specific knowledge from your code, which means that if QEMU grows support for another DT or ACPI based architecture, it will just work.
I was *hoping* a successful call to request_[mem_]region() will be enough in the way of asking for permission before probing for the fw_cfg registers, but I realize that might still not be polite enough :) DT on ARM is fine, and I'm certainly happy to learn how to do it (even though my main focus is, for now, x86). The unfortunate thing though is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into first adding it in on the host side, before I can rewrite the guest side driver to look it up in there :)
I am not sure how relevant sun4 and ppc/mac are for what you are trying to accomplish, but perhaps it would be best to focus on x86 and ARM for now and do it correctly. If the probing is actually needed, you can always add it later.
I guess that's the direction things seem to be headed, although it would make me a bit sad to leave out sun and ppc right from the very beginning :) Thanks, --Gabriel PS. If you have one .c file in the kernel which does any of the DT-on-arm boilerplate I'm supposed to immitate, I'd appreciate the shortcut :) PS2. Do you happen to be in Seattle right now ? :)
On Wed, Aug 19, 2015 at 04:49:15PM -0400, Gabriel L. Somlo wrote:
Hi Ard,
On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
(missed some cc's)
On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
From: "Gabriel L. Somlo" <somlo@cmu.edu>
Several different architectures supported by QEMU are set up with a "firmware configuration" (fw_cfg) device, used to pass configuration "blobs" into the guest by the host running QEMU.
Historically, these config blobs were mostly of interest to the guest BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via the command line, which makes them potentially interesting to userspace (e.g. for passing early boot environment variables, etc.).
Does 'potentially interesting' mean you have a use case? Could you elaborate?
My personal one would be something like:
cat > guestinfo.txt << EOT KEY1="val1" KEY2="val2" ... EOT
qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
Then, from inside the guest:
. /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
do_something_with $KEY1 $KEY2 ...
But I'm thinking this is only one of the many positive things one could do with the ability to access random host-supplied blobs from guest userspace :)
1/3 - probes for the qemu fw_cfg device in locations known to work on the supported architectures, in decreasing order of "likelihood".
While it *may* be possible to detect the presence of fw_cfg via acpi or dtb (on x86 and arm, respectively), there's no way I know of attempting that on sun4 and ppc/mac, so I've stuck with simply probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function) in fw_cfg.c. I could use some advice on how else that could be done more elegantly, if needed.
Sorry, but this is really out of the question, at least on ARM, but surely on other architectures as well. You can't just go around and probe random memory addresses. Perhaps QEMU tolerates it, but on anything that resembles a real system, this will immediately blow up. Also, what happens if the QEMU memory map changes? Add more probes addresses?
It is not /that/ difficult to simply wire it up to the DT and ACPI infrastructures, there are plenty of examples in the kernel tree how to accomplish that. As a bonus, it removes all the arch specific knowledge from your code, which means that if QEMU grows support for another DT or ACPI based architecture, it will just work.
I was *hoping* a successful call to request_[mem_]region() will be enough in the way of asking for permission before probing for the fw_cfg registers, but I realize that might still not be polite enough :)
Either way, it would make sense to not probe in locations that couldn't possibly work on the current platform. The cleanest way would probably be a per-architecture probe function (or structure). But even then, it needs to only probe when it is safe to do so.
DT on ARM is fine, and I'm certainly happy to learn how to do it (even though my main focus is, for now, x86). The unfortunate thing though is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into first adding it in on the host side, before I can rewrite the guest side driver to look it up in there :)
It is probaly the only non-hackish way to do it for arm*.
I am not sure how relevant sun4 and ppc/mac are for what you are trying to accomplish, but perhaps it would be best to focus on x86 and ARM for now and do it correctly. If the probing is actually needed, you can always add it later.
I guess that's the direction things seem to be headed, although it would make me a bit sad to leave out sun and ppc right from the very beginning :)
PS. If you have one .c file in the kernel which does any of the DT-on-arm boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)
PS2. Do you happen to be in Seattle right now ? :)
Unfortunately, neither Ard nor myself is there. But Mark Rutland should be around and someone useful to talk to about this. / Leif
On 19 August 2015 at 22:49, Gabriel L. Somlo <somlo@cmu.edu> wrote:
Hi Ard,
On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote:
(missed some cc's)
On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
From: "Gabriel L. Somlo" <somlo@cmu.edu>
Several different architectures supported by QEMU are set up with a "firmware configuration" (fw_cfg) device, used to pass configuration "blobs" into the guest by the host running QEMU.
Historically, these config blobs were mostly of interest to the guest BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via the command line, which makes them potentially interesting to userspace (e.g. for passing early boot environment variables, etc.).
Does 'potentially interesting' mean you have a use case? Could you elaborate?
My personal one would be something like:
cat > guestinfo.txt << EOT KEY1="val1" KEY2="val2" ... EOT
qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
Then, from inside the guest:
. /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
do_something_with $KEY1 $KEY2 ...
But I'm thinking this is only one of the many positive things one could do with the ability to access random host-supplied blobs from guest userspace :)
'random host-supplied blobs' sounds awfully like files in a file system to me, and that is already supported by QEMU and works with any guest OS unmodified. If you are in control of the command line, surely you can add a -drive xxx,fat:path/to/blobs -device xxx pair that simply turns up as a volume.
1/3 - probes for the qemu fw_cfg device in locations known to work on the supported architectures, in decreasing order of "likelihood".
While it *may* be possible to detect the presence of fw_cfg via acpi or dtb (on x86 and arm, respectively), there's no way I know of attempting that on sun4 and ppc/mac, so I've stuck with simply probing (the fw_cfg_modes[] structure and fw_cfg_io_probe() function) in fw_cfg.c. I could use some advice on how else that could be done more elegantly, if needed.
Sorry, but this is really out of the question, at least on ARM, but surely on other architectures as well. You can't just go around and probe random memory addresses. Perhaps QEMU tolerates it, but on anything that resembles a real system, this will immediately blow up. Also, what happens if the QEMU memory map changes? Add more probes addresses?
It is not /that/ difficult to simply wire it up to the DT and ACPI infrastructures, there are plenty of examples in the kernel tree how to accomplish that. As a bonus, it removes all the arch specific knowledge from your code, which means that if QEMU grows support for another DT or ACPI based architecture, it will just work.
I was *hoping* a successful call to request_[mem_]region() will be enough in the way of asking for permission before probing for the fw_cfg registers, but I realize that might still not be polite enough :)
No, all request_mem_region() does is check whether the region in question is not occupied yet by another driver. So your probing could access unpopulated memory space, or MMIO space owned by a peripheral whose driver is not loaded. Neither are allowable, I'm afraid.
DT on ARM is fine, and I'm certainly happy to learn how to do it (even though my main focus is, for now, x86). The unfortunate thing though is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into first adding it in on the host side, before I can rewrite the guest side driver to look it up in there :)
I am not sure how relevant sun4 and ppc/mac are for what you are trying to accomplish, but perhaps it would be best to focus on x86 and ARM for now and do it correctly. If the probing is actually needed, you can always add it later.
I guess that's the direction things seem to be headed, although it would make me a bit sad to leave out sun and ppc right from the very beginning :)
Sorry to be blunt, but I am not convinced there is a need for this driver anyway.
PS. If you have one .c file in the kernel which does any of the DT-on-arm boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)
Check out drivers/tty/serial/amba-pl011.c
PS2. Do you happen to be in Seattle right now ? :)
Nope :-)
On Thu, Aug 20, 2015 at 07:21:48AM +0200, Ard Biesheuvel wrote:
On 19 August 2015 at 22:49, Gabriel L. Somlo <somlo@cmu.edu> wrote:
From: "Gabriel L. Somlo" <somlo@cmu.edu>
Several different architectures supported by QEMU are set up with a "firmware configuration" (fw_cfg) device, used to pass configuration "blobs" into the guest by the host running QEMU.
Historically, these config blobs were mostly of interest to the guest BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via the command line, which makes them potentially interesting to userspace (e.g. for passing early boot environment variables, etc.).
Does 'potentially interesting' mean you have a use case? Could you elaborate?
My personal one would be something like:
cat > guestinfo.txt << EOT KEY1="val1" KEY2="val2" ... EOT
qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ...
Then, from inside the guest:
. /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw
do_something_with $KEY1 $KEY2 ...
But I'm thinking this is only one of the many positive things one could do with the ability to access random host-supplied blobs from guest userspace :)
'random host-supplied blobs' sounds awfully like files in a file system to me, and that is already supported by QEMU and works with any guest OS unmodified. If you are in control of the command line, surely you can add a -drive xxx,fat:path/to/blobs -device xxx pair that simply turns up as a volume.
That did come up, here's the start of original thread on the qemu mailing list from a while back: https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg00371.html To recap, the main advantages to transfering data this way are: 1. Asynchronous The host can simply pass data via the qemu command line, and not have to care if/when the guest is ready to accept the data (i.e. has made it far enough to e.g. start a guest agent) 2. Out-of-band I don't have to take over a user-visible element such as a disk drive. Same reason VSOCK (or VMWare VMCI for that matter) exist and are NOT actual Ethernet/TCP-IP network interfaces :)
DT on ARM is fine, and I'm certainly happy to learn how to do it (even though my main focus is, for now, x86). The unfortunate thing though is that on x86, fw_cfg is *not* AFAICT in ACPI, so I'd have to detour into first adding it in on the host side, before I can rewrite the guest side driver to look it up in there :)
I am not sure how relevant sun4 and ppc/mac are for what you are trying to accomplish, but perhaps it would be best to focus on x86 and ARM for now and do it correctly. If the probing is actually needed, you can always add it later.
I guess that's the direction things seem to be headed, although it would make me a bit sad to leave out sun and ppc right from the very beginning :)
Sorry to be blunt, but I am not convinced there is a need for this driver anyway.
See above (hopefully I'm being sufficiently persuasive :) ) In VMWare one would fetch similar "guestinfo" variables via something like FOO=$(vmware-tools --getinfo "FOO") but I thought exposing fw_cfg in /sys/firmware/... would make access to *any* blobs (including, but not limited to my particular use case) even easier and more generic than that.
PS. If you have one .c file in the kernel which does any of the DT-on-arm boilerplate I'm supposed to immitate, I'd appreciate the shortcut :)
Check out drivers/tty/serial/amba-pl011.c
I'll check it out. Thanks much! --Gabriel
participants (3)
-
Ard Biesheuvel -
Gabriel L. Somlo -
Leif Lindholm