>From Documentation/virtual/kvm/api.txt, all ARCHs should support
ioeventfd.
Also ARM VM has supported PCI bus already, and ARM64 will do too,
ioeventfd is required for some popular devices, like virtio-blk
and virtio-scsi dataplane in QEMU.
Without this patch, virtio-blk-pci dataplane can't work
On Tue, Nov 18, 2014 at 11:24 PM, Ming Lei wrote:
> From Documentation/virtual/kvm/api.txt, all ARCHs should support
> ioeventfd.
>
> Also ARM VM has supported PCI bus already, and ARM64 will do too,
> ioeventfd is required for some popular devices, like virtio-blk
> and virtio-scsi dataplane in Q
On 11/18/2014 07:05 PM, Michael S. Tsirkin wrote:
> On Tue, Nov 18, 2014 at 11:37:03AM +0800, Jason Wang wrote:
>> > On 11/17/2014 07:58 PM, Michael S. Tsirkin wrote:
>>> > > On Mon, Nov 17, 2014 at 01:22:07PM +0200, Gleb Natapov wrote:
> > >> > On Mon, Nov 17, 2014 at 12:38:16PM +0200, Michael
On Wed, 2014-11-19 at 09:56 +0800, Zhang Haoyu wrote:
> Hi all,
>
> Does the combination of qemu-2.0.1 and linux-3.10 fully support
> direct-assign vga adapters to vm?
No, at best I'd call it experimental
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
Hi all,
Does the combination of qemu-2.0.1 and linux-3.10 fully support direct-assign
vga adapters to vm?
Thanks,
Zhang Haoyu
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
Actually MMIO_MAX_GEN is same as MMIO_GEN_MASK.
Signed-off-by: Tiejun Chen
---
v2:
* Instead, we'd like to keep MMIO_GEN_MASK.
arch/x86/kvm/mmu.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index ac1c4de..4ea0dcb 100644
---
2014-11-18 20:51+0100, Paolo Bonzini:
> On 16/11/2014 22:49, Nadav Amit wrote:
> > @@ -374,13 +378,15 @@ static inline void apic_clear_irr(int vec, struct
> > kvm_lapic *apic)
> > + apic->irr_pending = false;
> > + apic_clear_vector(vec, apic->regs + APIC_IRR);
> > +
On 16/11/2014 22:49, Nadav Amit wrote:
> @@ -374,13 +378,15 @@ static inline void apic_clear_irr(int vec, struct
> kvm_lapic *apic)
>
> vcpu = apic->vcpu;
>
> - apic_clear_vector(vec, apic->regs + APIC_IRR);
> - if (unlikely(kvm_apic_vid_enabled(vcpu->kvm)))
> + if (unlikel
>From Documentation/virtual/kvm/api.txt, all ARCHs should support
ioeventfd.
Also ARM VM has supported PCI bus already, and ARM64 will do too,
ioeventfd is required for some popular devices, like virtio-blk
and virtio-scsi dataplane in QEMU.
Without this patch, virtio-blk-pci dataplane can't work
2014-11-16 23:49+0200, Nadav Amit:
> apic_find_highest_irr assumes irr_pending is set if any vector in APIC_IRR is
> set. If this assumption is broken and apicv is disabled, the injection of
> interrupts may be deferred until another interrupt is delivered to the guest.
> Ultimately, if no other i
On 11/18/2014 8:53 AM, Hans de Goede wrote:
kvm's usb pass-through should be able to handle this without any issues
(other then some latency), it uses special buffering for isochronous
usb packets, which should take care of usb audio working.
I've never tested audio recording, but audio playbac
On 11/18/2014 8:50 AM, Paolo Bonzini wrote:
I'm adding two people who might know.
Do you have any idea what the "magic to pipe data back to the Linux
host" should look like? Does a normal serial port (COM1 for Windows,
/dev/ttyS0 for Linux) work?
The fine magic comes in three forms. Keystr
Hi,
On 11/18/2014 02:50 PM, Paolo Bonzini wrote:
>
>
> On 18/11/2014 07:48, Eric S. Johansson wrote:
>> I'm trying to figure out ways of making it possible to drive Linux from
>> Windows speech recognition (NaturallySpeaking). The goal is a system
>> where Windows runs in a virtual machine (Lin
On 18/11/2014 07:48, Eric S. Johansson wrote:
> I'm trying to figure out ways of making it possible to drive Linux from
> Windows speech recognition (NaturallySpeaking). The goal is a system
> where Windows runs in a virtual machine (Linux host), audio is passed
> through from a USB headset to t
On Tue, Nov 18, 2014 at 11:37:03AM +0800, Jason Wang wrote:
> On 11/17/2014 07:58 PM, Michael S. Tsirkin wrote:
> > On Mon, Nov 17, 2014 at 01:22:07PM +0200, Gleb Natapov wrote:
> >> > On Mon, Nov 17, 2014 at 12:38:16PM +0200, Michael S. Tsirkin wrote:
> >>> > > On Mon, Nov 17, 2014 at 09:44:23AM +
On 18/11/2014 10:14, Tiejun Chen wrote:
> Actually MMIO_MAX_GEN is same as MMIO_GEN_MASK, and
> especially in all cases we already AND this so its
> also unnecessary to generate such a WARN_ON().
>
> Signed-off-by: Tiejun Chen
Good idea, but I actually prefer keeping MMIO_GEN_MASK since it is
On 18/11/2014 10:12, Tiejun Chen wrote:
> Instead, just use PFERR_{FETCH, PRESENT, WRITE}_MASK
> inside handle_ept_violation() for slightly better code.
>
> Signed-off-by: Tiejun Chen
> ---
> arch/x86/kvm/vmx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arc
On 18/11/2014 10:23, Chen, Tiejun wrote:
>> On 32-bit PAE hosts, PTEs have bit 62 reserved, as in your patch:
>
> Do you mean just one reserved bit is fine enough in this case?
Yes.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vg
On 2014/11/17 19:40, Paolo Bonzini wrote:
On 17/11/2014 12:31, Tiejun Chen wrote:
In non-ept 64-bit of PAE case maxphyaddr may be 52bit as well,
There is no such thing as 64-bit PAE.
Definitely.
On 32-bit PAE hosts, PTEs have bit 62 reserved, as in your patch:
Do you mean just one re
Actually MMIO_MAX_GEN is same as MMIO_GEN_MASK, and
especially in all cases we already AND this so its
also unnecessary to generate such a WARN_ON().
Signed-off-by: Tiejun Chen
---
arch/x86/kvm/mmu.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arc
Instead, just use PFERR_{FETCH, PRESENT, WRITE}_MASK
inside handle_ept_violation() for slightly better code.
Signed-off-by: Tiejun Chen
---
arch/x86/kvm/vmx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 284f5c2..22dc60d
21 matches
Mail list logo
