mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-02 07:13:54 -06:00
Typo, spelling and grammatical fixes
Minor fixes to documentation and code comments. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This commit is contained in:
parent
5947c697ce
commit
e03ba13637
9 changed files with 18 additions and 18 deletions
|
@ -9,7 +9,7 @@ still be bootable.
|
|||
|
||||
== Example ==
|
||||
|
||||
Lets assume we have QEMU machine with two NICs (virtio, e1000) and two
|
||||
Let's assume we have a QEMU machine with two NICs (virtio, e1000) and two
|
||||
disks (IDE, virtio):
|
||||
|
||||
qemu -drive file=disk1.img,if=none,id=disk1
|
||||
|
@ -20,7 +20,7 @@ qemu -drive file=disk1.img,if=none,id=disk1
|
|||
-netdev type=user,id=net1 -device e1000,netdev=net1,bootindex=1
|
||||
|
||||
Given the command above, firmware should try to boot from the e1000 NIC
|
||||
first. If this fails, it should try the virtio NIC next, if this fails
|
||||
first. If this fails, it should try the virtio NIC next; if this fails
|
||||
too, it should try the virtio disk, and then the IDE disk.
|
||||
|
||||
== Limitations ==
|
||||
|
@ -28,7 +28,7 @@ too, it should try the virtio disk, and then the IDE disk.
|
|||
1. Some firmware has limitations on which devices can be considered for
|
||||
booting. For instance, the PC BIOS boot specification allows only one
|
||||
disk to be bootable. If boot from disk fails for some reason, the BIOS
|
||||
won't retry booting from other disk. It still can try to boot from
|
||||
won't retry booting from other disk. It can still try to boot from
|
||||
floppy or net, though.
|
||||
|
||||
2. Sometimes, firmware cannot map the device path QEMU wants firmware to
|
||||
|
@ -36,8 +36,8 @@ boot from to a boot method. It doesn't happen for devices the firmware
|
|||
can natively boot from, but if firmware relies on an option ROM for
|
||||
booting, and the same option ROM is used for booting from more then one
|
||||
device, the firmware may not be able to ask the option ROM to boot from
|
||||
a particular device reliably. For instance with PC BIOS, if a SCSI HBA
|
||||
a particular device reliably. For instance with the PC BIOS, if a SCSI HBA
|
||||
has three bootable devices target1, target3, target5 connected to it,
|
||||
the option ROM will have a boot method for each of them, but it is not
|
||||
possible to map from boot method back to a specific target. This is a
|
||||
shortcoming of PC BIOS boot specification.
|
||||
shortcoming of the PC BIOS boot specification.
|
||||
|
|
|
@ -24,7 +24,7 @@ information see the specification:
|
|||
Revision 1.1
|
||||
April 22rd, 2005
|
||||
|
||||
Smartcard are used for authentication, single sign on, decryption in
|
||||
Smartcards are used for authentication, single sign on, decryption in
|
||||
public/private schemes and digital signatures. A smartcard reader on the client
|
||||
cannot be used on a guest with simple usb passthrough since it will then not be
|
||||
available on the client, possibly locking the computer when it is "removed". On
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue