Commit 17180032 authored by Masanari Iida's avatar Masanari Iida Committed by Marcelo Tosatti

KVM: doc: Fix typo in doc/virtual/kvm

Correct spelling typo in Documentations/virtual/kvm
Signed-off-by: default avatarMasanari Iida <standby24x7@gmail.com>
Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
parent da91747c
...@@ -2104,7 +2104,7 @@ Returns: 0 on success, -1 on error ...@@ -2104,7 +2104,7 @@ Returns: 0 on success, -1 on error
Allows setting an eventfd to directly trigger a guest interrupt. Allows setting an eventfd to directly trigger a guest interrupt.
kvm_irqfd.fd specifies the file descriptor to use as the eventfd and kvm_irqfd.fd specifies the file descriptor to use as the eventfd and
kvm_irqfd.gsi specifies the irqchip pin toggled by this event. When kvm_irqfd.gsi specifies the irqchip pin toggled by this event. When
an event is tiggered on the eventfd, an interrupt is injected into an event is triggered on the eventfd, an interrupt is injected into
the guest using the specified gsi pin. The irqfd is removed using the guest using the specified gsi pin. The irqfd is removed using
the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
and kvm_irqfd.gsi. and kvm_irqfd.gsi.
...@@ -2115,7 +2115,7 @@ interrupts. When KVM_IRQFD_FLAG_RESAMPLE is set the user must pass an ...@@ -2115,7 +2115,7 @@ interrupts. When KVM_IRQFD_FLAG_RESAMPLE is set the user must pass an
additional eventfd in the kvm_irqfd.resamplefd field. When operating additional eventfd in the kvm_irqfd.resamplefd field. When operating
in resample mode, posting of an interrupt through kvm_irq.fd asserts in resample mode, posting of an interrupt through kvm_irq.fd asserts
the specified gsi in the irqchip. When the irqchip is resampled, such the specified gsi in the irqchip. When the irqchip is resampled, such
as from an EOI, the gsi is de-asserted and the user is notifed via as from an EOI, the gsi is de-asserted and the user is notified via
kvm_irqfd.resamplefd. It is the user's responsibility to re-queue kvm_irqfd.resamplefd. It is the user's responsibility to re-queue
the interrupt if the device making use of it still requires service. the interrupt if the device making use of it still requires service.
Note that closing the resamplefd is not sufficient to disable the Note that closing the resamplefd is not sufficient to disable the
......
...@@ -77,7 +77,7 @@ Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest ...@@ -77,7 +77,7 @@ Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
kernel mode for an event to occur (ex: a spinlock to become available) can kernel mode for an event to occur (ex: a spinlock to become available) can
execute HLT instruction once it has busy-waited for more than a threshold execute HLT instruction once it has busy-waited for more than a threshold
time-interval. Execution of HLT instruction would cause the hypervisor to put time-interval. Execution of HLT instruction would cause the hypervisor to put
the vcpu to sleep until occurence of an appropriate event. Another vcpu of the the vcpu to sleep until occurrence of an appropriate event. Another vcpu of the
same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall, same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0) specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0)
is used in the hypercall for future use. is used in the hypercall for future use.
...@@ -112,7 +112,7 @@ The Dirty bit is lost in this case. ...@@ -112,7 +112,7 @@ The Dirty bit is lost in this case.
In order to avoid this kind of issue, we always treat the spte as "volatile" In order to avoid this kind of issue, we always treat the spte as "volatile"
if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means, if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means,
the spte is always atomicly updated in this case. the spte is always atomically updated in this case.
3): flush tlbs due to spte updated 3): flush tlbs due to spte updated
If the spte is updated from writable to readonly, we should flush all TLBs, If the spte is updated from writable to readonly, we should flush all TLBs,
...@@ -125,7 +125,7 @@ be flushed caused by this reason in mmu_spte_update() since this is a common ...@@ -125,7 +125,7 @@ be flushed caused by this reason in mmu_spte_update() since this is a common
function to update spte (present -> present). function to update spte (present -> present).
Since the spte is "volatile" if it can be updated out of mmu-lock, we always Since the spte is "volatile" if it can be updated out of mmu-lock, we always
atomicly update the spte, the race caused by fast page fault can be avoided, atomically update the spte, the race caused by fast page fault can be avoided,
See the comments in spte_has_volatile_bits() and mmu_spte_update(). See the comments in spte_has_volatile_bits() and mmu_spte_update().
3. Reference 3. Reference
......
...@@ -115,7 +115,7 @@ If any other bit changes in the MSR, please still use mtmsr(d). ...@@ -115,7 +115,7 @@ If any other bit changes in the MSR, please still use mtmsr(d).
Patched instructions Patched instructions
==================== ====================
The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions The "ld" and "std" instructions are transformed to "lwz" and "stw" instructions
respectively on 32 bit systems with an added offset of 4 to accommodate for big respectively on 32 bit systems with an added offset of 4 to accommodate for big
endianness. endianness.
......
...@@ -467,7 +467,7 @@ at any time. This causes problems as the passage of real time, the injection ...@@ -467,7 +467,7 @@ at any time. This causes problems as the passage of real time, the injection
of machine interrupts and the associated clock sources are no longer completely of machine interrupts and the associated clock sources are no longer completely
synchronized with real time. synchronized with real time.
This same problem can occur on native harware to a degree, as SMM mode may This same problem can occur on native hardware to a degree, as SMM mode may
steal cycles from the naturally on X86 systems when SMM mode is used by the steal cycles from the naturally on X86 systems when SMM mode is used by the
BIOS, but not in such an extreme fashion. However, the fact that SMM mode may BIOS, but not in such an extreme fashion. However, the fact that SMM mode may
cause similar problems to virtualization makes it a good justification for cause similar problems to virtualization makes it a good justification for
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment