Kernel pio emulation return value is mistakenly checked, fortuantely it is not
hit yet for normal OS bootup :(
Signed-off-by: Eddie Dong eddie.d...@linux.intel.com
commit 98d3dc8b67ba0bc7f494de3ade8f2b5cfcadaeb4
Author: root r...@eddie-wb.localdomain
Date: Thu Mar 19 15:44:39 2009 +0800
On Fri, Mar 13, 2009 at 10:15:22AM +0800, Zhang, Xiantao wrote:
We also hacked the source like the patch. But the issue is not caused by it.
We are still trying to figure the reason out. Thanks!
Xiantao
With the patch below I am able to compile kvm-userspace on IA64 and run linux
guest.
Gleb Natapov wrote:
On Fri, Mar 13, 2009 at 10:15:22AM +0800, Zhang, Xiantao wrote:
We also hacked the source like the patch. But the issue is not
caused by it. We are still trying to figure the reason out. Thanks!
Xiantao
With the patch below I am able to compile kvm-userspace on IA64
David S. Ahern schrieb:
David S. Ahern wrote:
Rusty Russell wrote:
On Wednesday 18 March 2009 16:59:36 Avi Kivity wrote:
Tomasz Chmielewski wrote:
virtio_net virtio0: id 64 is not a head!
This means that qemu said I've finished with buffer 64 and the guest didn't
know anything about buffer
On Thu, Mar 19, 2009 at 03:56:07PM +0800, Zhang, Xiantao wrote:
Gleb Natapov wrote:
On Fri, Mar 13, 2009 at 10:15:22AM +0800, Zhang, Xiantao wrote:
We also hacked the source like the patch. But the issue is not
caused by it. We are still trying to figure the reason out. Thanks!
Xiantao
Dong, Eddie wrote:
Kernel pio emulation return value is mistakenly checked, fortuantely it is not
hit yet for normal OS bootup :(
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index ca91749..0edd2e7 100644
--- a/arch/x86/kvm/x86_emulate.c
+++
Benjamin Gilbert wrote:
Code: ec 81 e1 01 08 00 00 31 db 89 f2 09 ca 89 55 e0 89 f8 09 d8 89
45 e4 be 80 00 00 c0 8b 55 e0 8b 4d e4 89 ca 31 c9 89 f1 8b 45 e0 0f
30 8b 5d e8 ff 83 ec 00 00 00 83 c4 1c 5b 5e 5f 5d c3 55 89
Well, that's certainly the wrmsr instruction. But I don't see how
Sheng Yang wrote:
For if assign_irq() is called before capability init, it don't know device
support MSI or not for the first time calling. So it won't enable MSI2INTx...
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send
free_mmu_pages() should only undo what alloc_mmu_pages() does.
Free mmu pages from generic VM destruction function.
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2a36f7f..b625ed4 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@
Andrea Arcangeli wrote:
static int kvm_sync_page(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp)
{
+ bool need_flush;
+
if (sp-role.glevels != vcpu-arch.mmu.root_level) {
kvm_mmu_zap_page(vcpu-kvm, sp);
return 1;
}
- if
Avi Kivity wrote:
I think we no longer need remote_tlbs_dirty. I'll send a new version.
Oh, we do, for the main use case on mmu notifiers.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
Amit Shah wrote:
What action should the kernel take, though? If lm is advertised and we
don't let the guest enter long mode -- exit to userspace and close the
VM?
Since it should never happen, it doesn't really matter. #GP will be the
natural action (setting reserved bit); userspace lied
On (Thu) Mar 19 2009 [11:55:57], Avi Kivity wrote:
Amit Shah wrote:
On (Tue) Mar 17 2009 [19:24:44], Benjamin Gilbert wrote:
I accidentally tried to run a 64-bit guest on a 32-bit host. Even
though this isn't supported, it shouldn't crash my kernel. :-)
Glauber had a patch
Andreas Tanz wrote:
Hi!
The guest starts up showing the Bochs BIOS POST and stucks giving thousands of lines :
[15013.656923] returning from kvm_handle_exit, cause 3, retval = 1
What was the value of exit_reason?
kernel/x86/vmx.c:
3211 static int kvm_handle_exit(struct
Tomasz Chmielewski schrieb:
Note how _time_ is different (similar timings are to other unaffected
guests):
This is also pretty interesting:
# ping -c 10 unaffected guest
PING 192.168.4.4 (192.168.4.4) 56(84) bytes of data.
64 bytes from 192.168.4.4: icmp_seq=1 ttl=64 time=1.25 ms
64 bytes
KVM currently flushes the tlbs on all cpus when emulating invlpg. This
is because at the time of invlpg we lose track of the page, and leaving
stale tlb entries could cause the guest to access the page when it is
later freed (say after being swapped out).
However we have a second change to flush
Avi Kivity wrote:
KVM currently flushes the tlbs on all cpus when emulating invlpg. This
is because at the time of invlpg we lose track of the page, and leaving
stale tlb entries could cause the guest to access the page when it is
later freed (say after being swapped out).
However we have a
Andrew Theurer wrote:
Avi Kivity wrote:
KVM currently flushes the tlbs on all cpus when emulating invlpg. This
is because at the time of invlpg we lose track of the page, and leaving
stale tlb entries could cause the guest to access the page when it is
later freed (say after being swapped
Gleb Natapov wrote:
free_mmu_pages() should only undo what alloc_mmu_pages() does.
Free mmu pages from generic VM destruction function.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
Tomasz Chmielewski wrote:
David S. Ahern schrieb:
David S. Ahern wrote:
Rusty Russell wrote:
On Wednesday 18 March 2009 16:59:36 Avi Kivity wrote:
Tomasz Chmielewski wrote:
virtio_net virtio0: id 64 is not a head!
This means that qemu said I've finished with buffer 64 and the
guest
-- dmesg :
[79116.175571] returning from kvm_handle_exit, cause 3, retval = 1,
exit_reason = 0
That's an exception or nmi. Next step is to instrument
handle_exception() and see what happens there. Please print out
vect_info, intr_info, and kvm_rip_read(vcpu) (all as hex).
The
Andreas Tanz wrote:
-- dmesg :
[79116.175571] returning from kvm_handle_exit, cause 3, retval = 1, exit_reason = 0
That's an exception or nmi. Next step is to instrument
handle_exception() and see what happens there. Please print out
vect_info, intr_info, and kvm_rip_read(vcpu) (all
i modded handle_exception as you said :
vmx.c:
...
2637 static int handle_exception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
2638 {
2639 struct vcpu_vmx *vmx = to_vmx(vcpu);
2640 u32 intr_info, ex_no, error_code;
2641 unsigned long cr2, rip, dr6;
2642 u32
Andreas Tanz wrote:
i modded handle_exception as you said :
2711 printk(KERN_ERR vmx-handle_exception 0f : vcpu-arch.rmode.active:
0x%x\n,vcpu-arch.rmode.active);
2712 int debug_handle_rmode_exception = handle_rmode_exception(vcpu,
intr_info INTR_INFO_VECTOR_MASK,
There may be cases where the guest does not want the avail queue
interrupt, even when it's empty. For the virtio-net case, the
guest may use a different buffering scheme or decide polling for
used buffers is more efficient. This can be accomplished by simply
checking for whether the guest has
Am 19.03.2009 schrieb Avi Kivity:
This bit is broken. The original code:
if (vcpu-arch.rmode.active
handle_rmode_exception(vcpu, intr_info INTR_INFO_VECTOR_MASK,
error_code)) {
Only executes handle_rmode_exception() if rmode.active is true.
Andreas Tanz wrote:
Am 19.03.2009 schrieb Avi Kivity:
This bit is broken. The original code:
if (vcpu-arch.rmode.active
handle_rmode_exception(vcpu, intr_info INTR_INFO_VECTOR_MASK,
error_code)) {
Only executes handle_rmode_exception() if
Hi,
I'm also interested in this possibilty of graphic card passthrough to a
client. As it seems impossible to share the graphic card between
multiple systems, does it work with high performance if using a second
graphic card for the host system? I've read that Xen can handle the
passthrough
On Wed, Mar 11, 2009 at 03:25:42PM +0800, Yu Zhao wrote:
+config PCI_IOV
+ bool PCI IOV support
+ depends on PCI
+ help
+ PCI-SIG I/O Virtualization (IOV) Specifications support.
+ Single Root IOV: allows the creation of virtual PCI devices
+ that share the
Avi Kivity wrote:
Well, that's certainly the wrmsr instruction. But I don't see how this
can happen.
Can you patch set_efer() in x86.c to print the value of the efer
argument and of efer_reserved_bits?
Yes, but apparently set_efer() is never called. To verify, I patched
On Mon, 23 Feb 2009 21:52:23 -0800
Chris Wright chr...@sous-sol.org wrote:
This adds a remove_id sysfs entry to allow users of new_id to later
remove the added dynid. One use case is management tools that want to
dynamically bind/unbind devices to pci-stub driver while devices are
assigned
On Thu, 19 Mar 2009 13:53:12 -0600
Matthew Wilcox matt...@wil.cx wrote:
On Wed, Mar 11, 2009 at 03:25:42PM +0800, Yu Zhao wrote:
+config PCI_IOV
+ bool PCI IOV support
+ depends on PCI
+ help
+ PCI-SIG I/O Virtualization (IOV) Specifications support.
+ Single Root IOV:
On Thu, Mar 19, 2009 at 06:20:16PM -0700, Jesse Barnes wrote:
Ok Yu, I'm ready to apply this set, can you send an updated one with
the fixes Matthew mentioned?
And please add Reviewed-by: Matthew Wilcox wi...@linux.intel.com
to each of the patches.
--
Matthew Wilcox
On Fri, Mar 20, 2009 at 03:53:12AM +0800, Matthew Wilcox wrote:
On Wed, Mar 11, 2009 at 03:25:42PM +0800, Yu Zhao wrote:
+config PCI_IOV
+ bool PCI IOV support
+ depends on PCI
+ help
+ PCI-SIG I/O Virtualization (IOV) Specifications support.
+ Single Root IOV: allows
On Thu, 12 Feb 2009 20:50:32 +0800
Yu Zhao yu.z...@intel.com wrote:
This patch series implements Address Translation Service support for
the Intel IOMMU. ATS makes the PCI Endpoint be able to request the
DMA address translation from the IOMMU and cache the translation in
the Endpoint, thus
On Thu, 12 Feb 2009 20:50:32 +0800
Yu Zhao yu.z...@intel.com wrote:
This patch series implements Address Translation Service support for
the Intel IOMMU. ATS makes the PCI Endpoint be able to request the
DMA address translation from the IOMMU and cache the translation in
the Endpoint, thus
Jesse Barnes wrote:
On Thu, 12 Feb 2009 20:50:32 +0800
Yu Zhao yu.z...@intel.com wrote:
This patch series implements Address Translation Service support for
the Intel IOMMU. ATS makes the PCI Endpoint be able to request the
DMA address translation from the IOMMU and cache the translation in
Greetings,
Following patches are intended to support SR-IOV capability in the
Linux kernel. With these patches, people can turn a PCI device with
the capability into multiple ones from software perspective, which
will benefit KVM and achieve other purposes such as QoS, security,
and etc.
SR-IOV
If a device has the SR-IOV capability, initialize it (set the ARI
Capable Hierarchy in the lowest numbered PF if necessary; calculate
the System Page Size for the VF MMIO, probe the VF Offset, Stride
and BARs). A lock for the VF bus allocation is also initialized if
a PF is the lowest numbered PF.
Reviewed-by: Randy Dunlap rdun...@xenotime.net
Reviewed-by: Matthew Wilcox wi...@linux.intel.com
Signed-off-by: Yu Zhao yu.z...@intel.com
---
Documentation/DocBook/kernel-api.tmpl |1 +
Documentation/PCI/pci-iov-howto.txt | 99 +
2 files changed, 100
40 matches
Mail list logo
