[Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

2018-02-09 Thread Eric Blake 
Last July, Eric Blake wrote a nice summary for newcomers about what
QEMU has to do to emulate devices for the guests. So far, we missed
integratating this somewhere into the QEM web site or wiki, so let's
publish this now as a nice blog post for the users.

Signed-off-by: Thomas Huth 
Message-Id: <1516958370-3955-1-git-send-email-th...@redhat.com>

Incorporate editing suggestions made by others on the list,
particularly from Paolo Bonzini.

Signed-off-by: Eric Blake 
---

I finally took the time to make the edits suggested when Thomas
first proposed adding my email to the blog.

Thanks again for helping this text improve and reach a broader
audience!

 _posts/2018-02-09-understanding-qemu-devices.md | 179 
 1 file changed, 179 insertions(+)
 create mode 100644 _posts/2018-02-09-understanding-qemu-devices.md

diff --git a/_posts/2018-02-09-understanding-qemu-devices.md 
b/_posts/2018-02-09-understanding-qemu-devices.md
new file mode 100644
index 000..25130b7
--- /dev/null
+++ b/_posts/2018-02-09-understanding-qemu-devices.md
@@ -0,0 +1,179 @@
+---
+layout: post
+title:  "Understanding QEMU devices"
+date:   2018-02-09 13:30:00 -0600
+author: Eric Blake
+categories: blog
+---
+Here are some notes that may help newcomers understand what is
+actually happening with QEMU devices:
+
+With QEMU, one thing to remember is that we are trying to emulate what
+an Operating System (OS) would see on bare-metal hardware.  Most
+bare-metal machines are basically giant memory maps, where software
+poking at a particular address will have a particular side effect (the
+most common side effect is, of course, accessing memory; but other
+common regions in memory include the register banks for controlling
+particular pieces of hardware, like the hard drive or a network card,
+or even the CPU itself).  The end-goal of emulation is to allow a
+user-space program, using only normal memory accesses, to manage all
+of the side-effects that a guest OS is expecting.
+
+As an implementation detail, some hardware, like x86, actually has two
+memory spaces, where I/O space uses different assembly codes than
+normal; QEMU has to emulate these alternative accesses.  Similarly,
+many modern CPUs provide themselves a bank of CPU-local registers
+within the memory map, such as for an interrupt controller.
+
+With certain hardware, we have virtualization hooks where the CPU
+itself makes it easy to trap on just the problematic assembly
+instructions (those that access I/O space or CPU internal registers,
+and therefore require side effects different than a normal memory
+access), so that the guest just executes the same assembly sequence as
+on bare metal, but that execution then causes a trap to let user-space
+QEMU then react to the instructions using just its normal user-space
+memory accesses before returning control to the guest.  This is
+supported in QEMU through "accelerators".
+
+Virtualizing accelerators, such as KVM, can let a guest run nearly
+as fast as bare metal, where the slowdowns are caused by each trap
+from guest back to QEMU (a vmexit) to handle a difficult assembly
+instruction or memory address.  QEMU also supports other virtualizing
+accelerators (such as
+[HAXM](https://www.qemu.org/2017/11/22/haxm-usage-windows/) or macOS's
+Hypervisor.framework).
+
+QEMU also has a TCG accelerator, which takes the guest assembly
+instructions and compiles it on the fly into comparable host
+instructions or calls to host helper routines; while not as fast as
+hardware acceleration, it allows cross-hardware emulation, such as
+running ARM code on x86.
+
+The next thing to realize is what is happening when an OS is accessing
+various hardware resources.  For example, most operating systems ship
+with a driver that knows how to manage an IDE disk - the driver is
+merely software that is programmed to make specific I/O requests to a
+specific subset of the memory map (wherever the IDE bus lives, which
+is specific to the the hardware board).  When the IDE controller
+hardware receives those I/O requests it then performs the appropriate
+actions (via DMA transfers or other hardware action) to copy data from
+memory to persistent storage (writing to disk) or from persistent
+storage to memory (reading from the disk).
+
+When you first buy bare-metal hardware, your disk is uninitialized; you
+install the OS that uses the driver to make enough bare-metal accesses
+to the IDE hardware portion of the memory map to then turn the disk into
+a set of partitions and filesystems on top of those partitions.
+
+So, how does QEMU emulate this? In the big memory map it provides to
+the guest, it emulates an IDE disk at the same address as bare-metal
+would.  When the guest OS driver issues particular memory writes to
+the IDE control registers in order to copy data from memory to
+persistent storage, the QEMU accelerator traps accesses to that memory
+region, and passes the request on to

Re: [Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

2018-01-30 Thread Paolo Bonzini 
On 29/01/2018 12:27, Thomas Huth wrote:
> On 26.01.2018 15:46, Eric Blake wrote:
>> On 01/26/2018 06:40 AM, Paolo Bonzini wrote:
>>> On 26/01/2018 10:19, Thomas Huth wrote:
 Last July, Eric Blake wrote a nice summary for newcomers about what
 QEMU has to do to emulate devices for the guests. So far, we missed
 to integrate this somewhere into the QEM web site or wiki, so let's
 publish this now as a nice blog post for the users.
>>>
>>> It's very nice!  Some proofreading and corrections follow.
>>
>> Thanks for digging up my original email, and enhancing it (I guess the
>> fact that I don't blog very often, and stick to email, means that I rely
>> on others helping to polish my gems for the masses).
> 
> Sure ... Would you like to give it a try this time and continue with the
> patch, or shall I continue and send a v2?
> 
 +++ b/_posts/2018-01-26-understanding-qemu-devices.md
 @@ -0,0 +1,139 @@
 +---
 +layout: post
 +title:  "Understanding QEMU devices"
 +date:   2018-01-26 10:00:00 +0100
>>
>> That's when you're posting it online, but should it also mention when I
>> first started these thoughts in email form?
> 
> At least in the header we should have the current date, or the blog post
> will not show up at the top of the blog. Not sure whether there is an
> alternate field for the original date ... maybe we could rather add an
> "originally written in 2017 ..." sentence at the bottom of the post instead?

I don't think it's relevant, as long as it's brought up to date when we
post it to the web.

Paolo

Re: [Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

2018-01-29 Thread Thomas Huth 
On 26.01.2018 15:46, Eric Blake wrote:
> On 01/26/2018 06:40 AM, Paolo Bonzini wrote:
>> On 26/01/2018 10:19, Thomas Huth wrote:
>>> Last July, Eric Blake wrote a nice summary for newcomers about what
>>> QEMU has to do to emulate devices for the guests. So far, we missed
>>> to integrate this somewhere into the QEM web site or wiki, so let's
>>> publish this now as a nice blog post for the users.
>>
>> It's very nice!  Some proofreading and corrections follow.
> 
> Thanks for digging up my original email, and enhancing it (I guess the
> fact that I don't blog very often, and stick to email, means that I rely
> on others helping to polish my gems for the masses).

Sure ... Would you like to give it a try this time and continue with the
patch, or shall I continue and send a v2?

>>> +++ b/_posts/2018-01-26-understanding-qemu-devices.md
>>> @@ -0,0 +1,139 @@
>>> +---
>>> +layout: post
>>> +title:  "Understanding QEMU devices"
>>> +date:   2018-01-26 10:00:00 +0100
> 
> That's when you're posting it online, but should it also mention when I
> first started these thoughts in email form?

At least in the header we should have the current date, or the blog post
will not show up at the top of the blog. Not sure whether there is an
alternate field for the original date ... maybe we could rather add an
"originally written in 2017 ..." sentence at the bottom of the post instead?

 Thomas



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

2018-01-29 Thread Paolo Bonzini 
On 26/01/2018 15:46, Eric Blake wrote:
> On 01/26/2018 06:40 AM, Paolo Bonzini wrote:
>> On 26/01/2018 10:19, Thomas Huth wrote:
>>> Last July, Eric Blake wrote a nice summary for newcomers about what
>>> QEMU has to do to emulate devices for the guests. So far, we missed
>>> to integrate this somewhere into the QEM web site or wiki, so let's
>>> publish this now as a nice blog post for the users.
>>
>> It's very nice!  Some proofreading and corrections follow.
> 
> Thanks for digging up my original email, and enhancing it (I guess the
> fact that I don't blog very often, and stick to email, means that I rely
> on others helping to polish my gems for the masses).
> 
>>> +++ b/_posts/2018-01-26-understanding-qemu-devices.md
>>> @@ -0,0 +1,139 @@
>>> +---
>>> +layout: post
>>> +title:  "Understanding QEMU devices"
>>> +date:   2018-01-26 10:00:00 +0100
> 
> That's when you're posting it online, but should it also mention when I
> first started these thoughts in email form?
> 
>>> +author: Eric Blake
>>> +categories: blog
>>> +---
>>> +Here are some notes that may help newcomers understand what is actually
>>> +happening with QEMU devices:
>>> +
>>> +With QEMU, one thing to remember is that we are trying to emulate what
>>> +an OS would see on bare-metal hardware.  All bare-metal machines are
>>
>> s/All/Most/ (s390 anyone? :))
> 
> Also, s/OS/Operating System (OS)/ to make the acronym easier to follow
> in the rest of the document.
> 
>>
>>> +basically giant memory maps, where software poking at a particular
>>> +address will have a particular side effect (the most common side effect
>>> +is, of course, accessing memory; but other common regions in memory
>>> +include the register banks for controlling particular pieces of
>>> +hardware, like the hard drive or a network card, or even the CPU
>>> +itself).  The end-goal of emulation is to allow a user-space program,
>>> +using only normal memory accesses, to manage all of the side-effects
>>> +that a guest OS is expecting.
>>> +
>>> +As an implementation detail, some hardware, like x86, actually has two
>>> +memory spaces, where I/O space uses different assembly codes than
>>> +normal; QEMU has to emulate these alternative accesses.  Similarly, many
>>> +modern hardware is so complex that the CPU itself provides both
>>> +specialized assembly instructions and a bank of registers within the
>>> +memory map (a classic example being the management of the MMU, or
>>> +separation between Ring 0 kernel code and Ring 3 userspace code - if
>>> +that's not crazy enough, there's nested virtualization).
>>
>> I'd say the interrupt controllers are a better example so:
>>
>> Similarly, many modern CPUs provide themselves a bank of CPU-local
>> registers within the memory map, such as for an interrupt controller.
> 
> Is it still worth a mention of nested virtualization?

No, nested virtualization is just two layers of doing the same thing. :)

Paolo

Re: [Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

2018-01-26 Thread Paolo Bonzini 
On 26/01/2018 10:19, Thomas Huth wrote:
> Last July, Eric Blake wrote a nice summary for newcomers about what
> QEMU has to do to emulate devices for the guests. So far, we missed
> to integrate this somewhere into the QEM web site or wiki, so let's
> publish this now as a nice blog post for the users.

It's very nice!  Some proofreading and corrections follow.

> Signed-off-by: Thomas Huth 
> ---
>  _posts/2018-01-26-understanding-qemu-devices.md | 139 
> 
>  1 file changed, 139 insertions(+)
>  create mode 100644 _posts/2018-01-26-understanding-qemu-devices.md
> 
> diff --git a/_posts/2018-01-26-understanding-qemu-devices.md 
> b/_posts/2018-01-26-understanding-qemu-devices.md
> new file mode 100644
> index 000..b436ef0
> --- /dev/null
> +++ b/_posts/2018-01-26-understanding-qemu-devices.md
> @@ -0,0 +1,139 @@
> +---
> +layout: post
> +title:  "Understanding QEMU devices"
> +date:   2018-01-26 10:00:00 +0100
> +author: Eric Blake
> +categories: blog
> +---
> +Here are some notes that may help newcomers understand what is actually
> +happening with QEMU devices:
> +
> +With QEMU, one thing to remember is that we are trying to emulate what
> +an OS would see on bare-metal hardware.  All bare-metal machines are

s/All/Most/ (s390 anyone? :))

> +basically giant memory maps, where software poking at a particular
> +address will have a particular side effect (the most common side effect
> +is, of course, accessing memory; but other common regions in memory
> +include the register banks for controlling particular pieces of
> +hardware, like the hard drive or a network card, or even the CPU
> +itself).  The end-goal of emulation is to allow a user-space program,
> +using only normal memory accesses, to manage all of the side-effects
> +that a guest OS is expecting.
> +
> +As an implementation detail, some hardware, like x86, actually has two
> +memory spaces, where I/O space uses different assembly codes than
> +normal; QEMU has to emulate these alternative accesses.  Similarly, many
> +modern hardware is so complex that the CPU itself provides both
> +specialized assembly instructions and a bank of registers within the
> +memory map (a classic example being the management of the MMU, or
> +separation between Ring 0 kernel code and Ring 3 userspace code - if
> +that's not crazy enough, there's nested virtualization).

I'd say the interrupt controllers are a better example so:

Similarly, many modern CPUs provide themselves a bank of CPU-local
registers within the memory map, such as for an interrupt controller.

And then a paragraph break.

> +With certain
> +hardware, we have virtualization hooks where the CPU itself makes it
> +easy to trap on just the problematic assembly instructions (those that
> +access I/O space or CPU internal registers, and therefore require side
> +effects different than a normal memory access), so that the guest just
> +executes the same assembly sequence as on bare metal, but that execution
> +then causes a trap to let user-space QEMU then react to the instructions
> +using just its normal user-space memory accesses before returning
> +control to the guest.  This is the kvm accelerator, and can let a guest

This is supported in QEMU through "accelerators" such as KVM.

> +run nearly as fast as bare metal, where the slowdowns are caused by each
> +trap from guest back to QEMU (a vmexit) to handle a difficult assembly
> +instruction or memory address.  QEMU also supports a TCG accelerator,

QEMU also supports other virtualizing accelerators (such as
[HAXM](https://www.qemu.org/2017/11/22/haxm-usage-windows/) or macOS's
Hypervisor.framework) and also TCG,

> +which takes the guest assembly instructions and compiles it on the fly
> +into comparable host instructions or calls to host helper routines (not
> +as fast, but results in QEMU being able to do cross-hardware emulation).

While not as fast, TCG is able to do cross-hardware emulation, such as
running ARM code on x86. (Removing the parentheses)

> +The next thing to realize is what is happening when an OS is accessing
> +various hardware resources.  For example, most OS ship with a driver

most operating systems

> +that knows how to manage an IDE disk - the driver is merely software
> +that is programmed to make specific I/O requests to a specific subset of
> +the memory map (wherever the IDE bus lives, as hard-coded by the
> +hardware board designers),

(wherever the IDE bus lives, which is specific the hardware board).

 in order to make the disk drive hardware then
> +obey commands to copy data from memory to persistent storage (writing to
> +disk) or from persistent storage to memory (reading from the disk).

When the IDE controller hardware receives those I/O requests it
communicates with the disk drive hardware, ultimately resulting in data
being copied from memory...

> +When you first buy bare-metal hardware, your disk is uninitialized; you
> +install the OS that uses the

Re: [Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

2018-01-26 Thread Eric Blake 
On 01/26/2018 06:40 AM, Paolo Bonzini wrote:
> On 26/01/2018 10:19, Thomas Huth wrote:
>> Last July, Eric Blake wrote a nice summary for newcomers about what
>> QEMU has to do to emulate devices for the guests. So far, we missed
>> to integrate this somewhere into the QEM web site or wiki, so let's
>> publish this now as a nice blog post for the users.
> 
> It's very nice!  Some proofreading and corrections follow.

Thanks for digging up my original email, and enhancing it (I guess the
fact that I don't blog very often, and stick to email, means that I rely
on others helping to polish my gems for the masses).

>> +++ b/_posts/2018-01-26-understanding-qemu-devices.md
>> @@ -0,0 +1,139 @@
>> +---
>> +layout: post
>> +title:  "Understanding QEMU devices"
>> +date:   2018-01-26 10:00:00 +0100

That's when you're posting it online, but should it also mention when I
first started these thoughts in email form?

>> +author: Eric Blake
>> +categories: blog
>> +---
>> +Here are some notes that may help newcomers understand what is actually
>> +happening with QEMU devices:
>> +
>> +With QEMU, one thing to remember is that we are trying to emulate what
>> +an OS would see on bare-metal hardware.  All bare-metal machines are
> 
> s/All/Most/ (s390 anyone? :))

Also, s/OS/Operating System (OS)/ to make the acronym easier to follow
in the rest of the document.

> 
>> +basically giant memory maps, where software poking at a particular
>> +address will have a particular side effect (the most common side effect
>> +is, of course, accessing memory; but other common regions in memory
>> +include the register banks for controlling particular pieces of
>> +hardware, like the hard drive or a network card, or even the CPU
>> +itself).  The end-goal of emulation is to allow a user-space program,
>> +using only normal memory accesses, to manage all of the side-effects
>> +that a guest OS is expecting.
>> +
>> +As an implementation detail, some hardware, like x86, actually has two
>> +memory spaces, where I/O space uses different assembly codes than
>> +normal; QEMU has to emulate these alternative accesses.  Similarly, many
>> +modern hardware is so complex that the CPU itself provides both
>> +specialized assembly instructions and a bank of registers within the
>> +memory map (a classic example being the management of the MMU, or
>> +separation between Ring 0 kernel code and Ring 3 userspace code - if
>> +that's not crazy enough, there's nested virtualization).
> 
> I'd say the interrupt controllers are a better example so:
> 
> Similarly, many modern CPUs provide themselves a bank of CPU-local
> registers within the memory map, such as for an interrupt controller.

Is it still worth a mention of nested virtualization?

> 
> And then a paragraph break.
> 
>> +With certain
>> +hardware, we have virtualization hooks where the CPU itself makes it
>> +easy to trap on just the problematic assembly instructions (those that
>> +access I/O space or CPU internal registers, and therefore require side
>> +effects different than a normal memory access), so that the guest just
>> +executes the same assembly sequence as on bare metal, but that execution
>> +then causes a trap to let user-space QEMU then react to the instructions
>> +using just its normal user-space memory accesses before returning
>> +control to the guest.  This is the kvm accelerator, and can let a guest
> 
> This is supported in QEMU through "accelerators" such as KVM.

Yeah, when I first wrote the email, we didn't have as many accelerators
in qemu.git :)

> 
>> +run nearly as fast as bare metal, where the slowdowns are caused by each
>> +trap from guest back to QEMU (a vmexit) to handle a difficult assembly
>> +instruction or memory address.  QEMU also supports a TCG accelerator,
> 
> QEMU also supports other virtualizing accelerators (such as
> [HAXM](https://www.qemu.org/2017/11/22/haxm-usage-windows/) or macOS's
> Hypervisor.framework) and also TCG,
> 
>> +which takes the guest assembly instructions and compiles it on the fly
>> +into comparable host instructions or calls to host helper routines (not
>> +as fast, but results in QEMU being able to do cross-hardware emulation).
> 
> While not as fast, TCG is able to do cross-hardware emulation, such as
> running ARM code on x86. (Removing the parentheses)
> 
>> +The next thing to realize is what is happening when an OS is accessing
>> +various hardware resources.  For example, most OS ship with a driver
> 
> most operating systems
> 
>> +that knows how to manage an IDE disk - the driver is merely software
>> +that is programmed to make specific I/O requests to a specific subset of
>> +the memory map (wherever the IDE bus lives, as hard-coded by the
>> +hardware board designers),
> 
> (wherever the IDE bus lives, which is specific the hardware board).

specific to the

> 
>  in order to make the disk drive hardware then
>> +obey commands to copy data from memory to persistent storage (writing to
>> +disk) or from persistent

Re: [Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

2018-01-26 Thread Kashyap Chamarthy 
On Fri, Jan 26, 2018 at 10:19:30AM +0100, Thomas Huth wrote:
> Last July, Eric Blake wrote a nice summary for newcomers about what
> QEMU has to do to emulate devices for the guests. So far, we missed
> to integrate this somewhere into the QEM web site or wiki, so let's
> publish this now as a nice blog post for the users.

Good catch.  I had it bookmarked to do so, but forgot.

> Signed-off-by: Thomas Huth 
> ---
>  _posts/2018-01-26-understanding-qemu-devices.md | 139 
> 
>  1 file changed, 139 insertions(+)
>  create mode 100644 _posts/2018-01-26-understanding-qemu-devices.md

The core content is very helpful; but for better readability, would be
nice to break some of the large 22-line paragraphs (as they can be
overwhelming) down into slightly readable chunks.

If you don't prefer to do it, can take a stab at it, since I asked about
it.  If you think it's not worth it, I'm fine letting it go, since this
is a strict improvement as-is.

> diff --git a/_posts/2018-01-26-understanding-qemu-devices.md 
> b/_posts/2018-01-26-understanding-qemu-devices.md
> new file mode 100644
> index 000..b436ef0
> --- /dev/null
> +++ b/_posts/2018-01-26-understanding-qemu-devices.md
> @@ -0,0 +1,139 @@
> +---
> +layout: post
> +title:  "Understanding QEMU devices"
> +date:   2018-01-26 10:00:00 +0100
> +author: Eric Blake
> +categories: blog

[...]

-- 
/kashyap

[Qemu-devel] [qemu-web PATCH] Add "Understanding QEMU devices" blog post

2018-01-26 Thread Thomas Huth 
Last July, Eric Blake wrote a nice summary for newcomers about what
QEMU has to do to emulate devices for the guests. So far, we missed
to integrate this somewhere into the QEM web site or wiki, so let's
publish this now as a nice blog post for the users.

Signed-off-by: Thomas Huth 
---
 _posts/2018-01-26-understanding-qemu-devices.md | 139 
 1 file changed, 139 insertions(+)
 create mode 100644 _posts/2018-01-26-understanding-qemu-devices.md

diff --git a/_posts/2018-01-26-understanding-qemu-devices.md 
b/_posts/2018-01-26-understanding-qemu-devices.md
new file mode 100644
index 000..b436ef0
--- /dev/null
+++ b/_posts/2018-01-26-understanding-qemu-devices.md
@@ -0,0 +1,139 @@
+---
+layout: post
+title:  "Understanding QEMU devices"
+date:   2018-01-26 10:00:00 +0100
+author: Eric Blake
+categories: blog
+---
+Here are some notes that may help newcomers understand what is actually
+happening with QEMU devices:
+
+With QEMU, one thing to remember is that we are trying to emulate what
+an OS would see on bare-metal hardware.  All bare-metal machines are
+basically giant memory maps, where software poking at a particular
+address will have a particular side effect (the most common side effect
+is, of course, accessing memory; but other common regions in memory
+include the register banks for controlling particular pieces of
+hardware, like the hard drive or a network card, or even the CPU
+itself).  The end-goal of emulation is to allow a user-space program,
+using only normal memory accesses, to manage all of the side-effects
+that a guest OS is expecting.
+
+As an implementation detail, some hardware, like x86, actually has two
+memory spaces, where I/O space uses different assembly codes than
+normal; QEMU has to emulate these alternative accesses.  Similarly, many
+modern hardware is so complex that the CPU itself provides both
+specialized assembly instructions and a bank of registers within the
+memory map (a classic example being the management of the MMU, or
+separation between Ring 0 kernel code and Ring 3 userspace code - if
+that's not crazy enough, there's nested virtualization).  With certain
+hardware, we have virtualization hooks where the CPU itself makes it
+easy to trap on just the problematic assembly instructions (those that
+access I/O space or CPU internal registers, and therefore require side
+effects different than a normal memory access), so that the guest just
+executes the same assembly sequence as on bare metal, but that execution
+then causes a trap to let user-space QEMU then react to the instructions
+using just its normal user-space memory accesses before returning
+control to the guest.  This is the kvm accelerator, and can let a guest
+run nearly as fast as bare metal, where the slowdowns are caused by each
+trap from guest back to QEMU (a vmexit) to handle a difficult assembly
+instruction or memory address.  QEMU also supports a TCG accelerator,
+which takes the guest assembly instructions and compiles it on the fly
+into comparable host instructions or calls to host helper routines (not
+as fast, but results in QEMU being able to do cross-hardware emulation).
+
+The next thing to realize is what is happening when an OS is accessing
+various hardware resources.  For example, most OS ship with a driver
+that knows how to manage an IDE disk - the driver is merely software
+that is programmed to make specific I/O requests to a specific subset of
+the memory map (wherever the IDE bus lives, as hard-coded by the
+hardware board designers), in order to make the disk drive hardware then
+obey commands to copy data from memory to persistent storage (writing to
+disk) or from persistent storage to memory (reading from the disk).
+When you first buy bare-metal hardware, your disk is uninitialized; you
+install the OS that uses the driver to make enough bare-metal accesses
+to the IDE hardware portion of the memory map to then turn the disk into
+a set of partitions and filesystems on top of those partitions.
+
+So, how does QEMU emulate this? In the big memory map it provides to the
+guest, it emulates an IDE disk at the same address as bare-metal would.
+When the guest OS driver issues particular memory writes to the IDE
+control registers in order to copy data from memory to persistent
+storage, QEMU traps on those writes (whether via kvm hypervisor assist,
+or by noticing during TCG translation that the addresses being accessed
+are special), and emulates the same side effects by issuing host
+commands to copy the specified guest memory into host storage.  On the
+host side, the easiest way to emulate persistent storage is via treating
+a file in the host filesystem as raw data (a 1:1 mapping of offsets in
+the host file to disk offsets being accessed by the guest driver), but
+QEMU actually has the ability to glue together a lot of different host
+formats (raw, qcow2, qed, vhdx, ...) and protocols (file system, block
+device, NBD,