From: Avi Kivity a...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/kernel/x86/external-module-compat.h
b/kernel/x86/external-module-compat.h
index aa95a7c..1716cad 100644
--- a/kernel/x86/external-module-compat.h
+++ b/kernel/x86/external-module-compat.h
@@ -35,12 +35,21 @@
From: Alexander Graf ag...@suse.de
AMD K10 CPUs implement the FFXSR feature that gets enabled using
EFER. Let's check if the virtual CPU description includes that
CPUID feature bit and allow enabling it then.
This is required for Windows Server 2008 in Hyper-V mode.
v2 adds CPUID capability
From: Alexander Graf ag...@suse.de
AMD k10 includes support for the FFXSR feature, which leaves out
XMM registers on FXSAVE/FXSAVE when the EFER_FFXSR bit is set in
EFER.
The CPUID feature bit exists already, but the EFER bit is missing
currently, so this patch adds it to the list of known EFER
Marcelo Tosatti wrote:
On Tue, Feb 03, 2009 at 08:41:14AM +, Mark Marshall wrote:
[]
Right. I don't understand the point of converting to an internal
representation of TIOCM control bits.
fun mode
Well, the same goes for the IOCTL values themselves too -- like
this
On Wed, Feb 04, 2009 at 11:37:14AM +0300, Michael Tokarev wrote:
Marcelo Tosatti wrote:
On Tue, Feb 03, 2009 at 08:41:14AM +, Mark Marshall wrote:
[]
Right. I don't understand the point of converting to an internal
representation of TIOCM control bits.
fun mode
Well, the same goes
Marcelo Tosatti wrote:
[]
Other than that, an.. excellent idea, I wanted to propose
just that when I first saw all this stuff, but was somewhat
afraid. And I *think* there's at least *some* sense. Qemu
is a CPU emulator and may work on another arch where those
bits are defined differently.
For STS register bit are cleared by writing 1 into it.
Signed-off-by: Gleb Natapov g...@redhat.com
---
qemu/hw/acpi.c | 42 ++
1 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index b998225..68513c0 100644
1) Disabled processor's _STA method should return 0 (this fixes Vista's
BSOD on resuming after hibernate problem)
2) Disabled processor's _MAT method should return disabled MADT entry
instead of 0
3) Extend bitmask of hot pluggable CPUs to be 16 bit long
4) Generate interrupt only if
Generate interrupt only if corespondent EN bit is set.
Signed-off-by: Gleb Natapov g...@redhat.com
---
qemu/hw/acpi.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index 83079fa..337432a 100644
--- a/qemu/hw/acpi.c
+++
Michael Tokarev wrote:
Other than that, an.. excellent idea, I wanted to propose
just that when I first saw all this stuff, but was somewhat
afraid. And I *think* there's at least *some* sense. Qemu
is a CPU emulator and may work on another arch where those
bits are defined differently.
Gleb Natapov wrote:
For STS register bit are cleared by writing 1 into it.
+static uint16_t gpe_write_val(uint16_t cur, int addr, uint32_t val)
+{
+if (addr 1)
+return (cur 0xff) | (val 8);
+return (cur 0xff00) | (val 0xff);
+}
+
+static uint16_t gpe_reset_val(uint16_t
On Wed, Feb 04, 2009 at 02:29:07PM +0200, Avi Kivity wrote:
Gleb Natapov wrote:
For STS register bit are cleared by writing 1 into it.
+static uint16_t gpe_write_val(uint16_t cur, int addr, uint32_t val)
+{
+if (addr 1)
+return (cur 0xff) | (val 8);
+return (cur
Gleb Natapov wrote:
1) Disabled processor's _STA method should return 0 (this fixes Vista's
BSOD on resuming after hibernate problem)
2) Disabled processor's _MAT method should return disabled MADT entry
instead of 0
3) Extend bitmask of hot pluggable CPUs to be 16 bit long
4) Generate
On Wed, Feb 04, 2009 at 02:45:12PM +0200, Avi Kivity wrote:
Gleb Natapov wrote:
1) Disabled processor's _STA method should return 0 (this fixes Vista's
BSOD on resuming after hibernate problem)
2) Disabled processor's _MAT method should return disabled MADT entry
instead of 0
3) Extend
Gleb Natapov wrote:
struct pci_status {
@@ -603,10 +603,12 @@ static uint32_t gpe_readb(void *opaque, uint32_t addr)
struct gpe_regs *g = opaque;
switch (addr) {
case PROC_BASE:
-val = g-up;
-break;
case PROC_BASE + 1:
-val =
On Wed, Feb 04, 2009 at 03:24:59PM +0200, Avi Kivity wrote:
Gleb Natapov wrote:
struct pci_status {
@@ -603,10 +603,12 @@ static uint32_t gpe_readb(void *opaque, uint32_t
addr)
struct gpe_regs *g = opaque;
switch (addr) {
case PROC_BASE:
-val = g-up;
-
Gleb Natapov wrote:
It can, just need to find a place for it. Currently our AML does not use
RAM at all.
OperationRegion(..., SystemMemory, ...) should work. It's better to
avoid introducing unnecessary virtual hardware.
But what address to chose. It needs to be reserved
On Wed, Feb 04, 2009 at 03:35:16PM +0200, Avi Kivity wrote:
Gleb Natapov wrote:
It can, just need to find a place for it. Currently our AML does not use
RAM at all.
OperationRegion(..., SystemMemory, ...) should work. It's better to
avoid introducing unnecessary virtual
Michael Tokarev wrote:
David S. Ahern wrote:
Michael Tokarev wrote:
David S. Ahern wrote:
case CHR_IOCTL_SERIAL_SET_TIOCM:
{
int sarg = *(int *)arg;
int targ = 0;
+ioctl(s-fd_in, TIOCMGET, targ);
here, one more operation is necessary:
Glauber Costa wrote:
On Tue, Feb 3, 2009 at 8:50 AM, Avi Kivity a...@redhat.com wrote:
Glauber Costa wrote:
What for? We already expose a QEMU cpu type that shows up in cpuinfo as
so.
All we'd have to do would be put the kvm information in the cpu type
too. This would work
in all
Eduardo Habkost wrote:
Make sure we get the MSR_* defines from asm/svm.h before checking
if they are defined.
This fixes the following warning:
In file included from
/home/ehabkost/code/kvm/kvm-userspace/kernel/x86/kvm_svm.h:10,
from
Alexander Graf wrote:
Alexander Graf wrote:
Due to Marcelo's APIC fix we now depend on hrtimer_expires_remaining,
which is not available on my 2.6.27 kernel.
This patch adds a backwards compatibility layer for it.
Signed-off-by: Alexander Graf ag...@suse.de
I just saw that you
Alexander Graf wrote:
AMD k10 includes support for the FFXSR feature, which leaves out
XMM registers on FXSAVE/FXSAVE when the EFER_FFXSR bit is set in
EFER.
This patchset enables support for the FFXSR feature in KVM, allowing
the VM to set the bit in EFER when the physical CPU and the guest's
IRQ injection status is either -1 (if there was no CPU found
that should except the interrupt because IRQ was masked or
ioapic was misconfigured or ...) or = 0 in that case the
number indicates to how many CPUs interrupt was injected.
If the value is 0 it means that the interrupt was coalesced
and
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/libkvm/kvm-common.h b/libkvm/kvm-common.h
index d4fffbe..de1ada2 100644
--- a/libkvm/kvm-common.h
+++ b/libkvm/kvm-common.h
@@ -55,6 +55,8 @@ struct kvm_context {
int no_irqchip_creation;
/// in-kernel irqchip status
Avi Kivity wrote:
Alexander Graf wrote:
Alexander Graf wrote:
Due to Marcelo's APIC fix we now depend on hrtimer_expires_remaining,
which is not available on my 2.6.27 kernel.
This patch adds a backwards compatibility layer for it.
Signed-off-by: Alexander Graf ag...@suse.de
I just saw
On Tue, Feb 03, 2009 at 06:02:31PM +0100, Gerd Hoffmann wrote:
Hi,
Here is a patch which fixes the kvmclock on multicore systems without
constant_tsc.
I'm not that happy with the current form as the notifier duplicates code
from tsc.c. I don't see an easy way around that though.
Gleb Natapov wrote:
It's strange that write_val() and reset_val() return a value. Won't it
be cleaner to make val a pointer?
From functional programing POV no, it is not cleaner. But I don't really
care where to do assignment.
We're not doing functional programming:
a =
Hi,
This can race if the target vcpu has tested for vcpu-requests but not
set guest_mode yet,
Right. New patch coming in a minute.
cheers,
Gerd
--
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
Hi folks,
kvmclock currently falls apart on machines without constant tsc.
This patch fixes it. Changes:
* keep tsc frequency in a per-cpu variable.
* handle kvmclock update using a new request flag, thus checking
whenever we need an update each time we enter guest context.
* use a
Alexander Graf wrote:
Avi Kivity wrote:
Alexander Graf wrote:
Alexander Graf wrote:
Due to Marcelo's APIC fix we now depend on hrtimer_expires_remaining,
which is not available on my 2.6.27 kernel.
This patch adds a backwards compatibility layer for it.
Signed-off-by:
pci_dev.msi_enabled was introduced in 2.6.18, thus building against
older kernels now fails. Fix via a compat wrapper that reads directly
from the PCI config space.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kernel/external-module-compat-comm.h | 13 +
Jan Kiszka wrote:
When disabling SMP on kernels older than 2.6.27, the compat wrapping
fails due to unresolved SMP dependencies. This patch fixes the build.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kernel/external-module-compat-comm.h |2 +-
This series adds infrastructure for a new control virtqueue and
makes use of it to support set_rx_mode, unicast and multicast address
lists, and supporting a hypervisor based VLAN filter. The goal is to
make the virtio-net device support more of the features of a physical
NIC and allow the
VLAN filtering allows the hypervisor to drop packets from VLANs
that we're not a part of, further reducing the number of extraneous
packets recieved. This makes use of the VLAN virtqueue command class.
The CTRL_VLAN feature bit tells us whether the backend supports VLAN
filtering.
Signed-off-by:
This will be used for RX mode, MAC filter table, VLAN filtering, etc...
The control transaction consists of one or more out sg entries and
one or more in sg entries. The first out entry contains a header
defining the class and command. Additional out entries may provide
data for the command.
Make use of the MAC control virtqueue class to support a MAC
filter table. The filter table is managed by the hypervisor.
We consider the table to be available if the CTRL_RX feature
bit is set. We leave it to the hypervisor to manage the table
and enable promiscuous or all-multi mode as
Many physical NICs let the OS re-program the hardware MAC
address. Virtual NICs should allow this too.
Signed-off-by: Alex Williamson alex.william...@hp.com
Acked-by: Mark McLoughlin mar...@redhat.com
---
Rusty, you've already applied this to your patch queue, but that version
won't apply
Bugs item #2556746, was opened at 2009-02-02 13:19
Message generated for change (Comment added) made by kedarius
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2556746group_id=180599
Please note that this message will contain a full copy of the comment
On Wed, Feb 04, 2009 at 04:27:47PM +0200, Avi Kivity wrote:
Eduardo Habkost wrote:
Make sure we get the MSR_* defines from asm/svm.h before checking
if they are defined.
This fixes the following warning:
In file included from
/home/ehabkost/code/kvm/kvm-userspace/kernel/x86/kvm_svm.h:10,
On Tue, 2009-02-03 at 14:56 -0600, Anthony Liguori wrote:
Alex Williamson wrote:
+ctrl = elem.out_sg[0].iov_base;
+status = elem.in_sg[elem.in_num - 1].iov_base;
This works only because we're dealing with uint8_ts but it's broken
elsewhere in virtio-net. iov_base is
On Wed, 4 Feb 2009, Alex Williamson wrote:
[..snip..]
+static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
+{
+struct virtio_net_ctrl_hdr ctrl;
+virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
+VirtQueueElement elem;
+
+while (virtqueue_pop(vq, elem)) {
Alex Williamson wrote:
On Tue, 2009-02-03 at 14:56 -0600, Anthony Liguori wrote:
Alex Williamson wrote:
+ctrl = elem.out_sg[0].iov_base;
+status = elem.in_sg[elem.in_num - 1].iov_base;
This works only because we're dealing with uint8_ts but it's broken
On Thu, 2009-02-05 at 02:09 +0300, malc wrote:
On Wed, 4 Feb 2009, Alex Williamson wrote:
[..snip..]
+static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
+{
+struct virtio_net_ctrl_hdr ctrl;
+virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
+
On Thursday 05 February 2009 05:56:06 Alex Williamson wrote:
Many physical NICs let the OS re-program the hardware MAC
address. Virtual NICs should allow this too.
Signed-off-by: Alex Williamson alex.william...@hp.com
Acked-by: Mark McLoughlin mar...@redhat.com
---
Rusty, you've already
This series adds the ability for the guest to set the virtio-net device
MAC address, a new control virtqueue for setting configuration data from
the guest, and new interfaces making use of the control virtqueue for
setting RX mode options, MAC filter table entries, and VLAN filter bits.
The end
The status register should probably be saved since its guest visible.
Also add a little bit if infrastructure for handling various save
revisions.
Signed-off-by: Alex Williamson alex.william...@hp.com
---
hw/virtio-net.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff
Allow the guest to write to the MAC address config space and update
the network info string when it does. Rename get_config for symmetry.
Signed-off-by: Alex Williamson alex.william...@hp.com
Acked-by: Mark McLoughlin mar...@redhat.com
---
hw/virtio-net.c | 18 --
1 files
Makes it much easier to search too.
Signed-off-by: Alex Williamson alex.william...@hp.com
Acked-by: Mark McLoughlin mar...@redhat.com
---
hw/virtio-net.c | 14 +++---
hw/virtio-net.h |2 ++
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/hw/virtio-net.c
This will be used for RX mode, MAC table, VLAN table control, etc...
The control transaction consists of one or more out sg entries and
one or more in sg entries. The first out entry contains a header
defining the class and command. Additional out entries may provide
data for the command. A
Add a new RX_MODE control virtqueue class with commands PROMISC and
ALLMULTI and usage documented in virtio-net.h allowing the guest to
manipulate packet receiving options. We don't export a feature for
this until we also add the MAC filter table.
Note, for compatibility with older guest drivers
Make use of the new RX_MODE control virtqueue class by dropping
packets the guest doesn't want to see.
Signed-off-by: Alex Williamson alex.william...@hp.com
---
hw/virtio-net.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-net.c
Create a filter table and allow the guest to populate it with the
MAC class control commands. We manage the size and usage of the
filter table including enabling promiscuous and all-multi modes
as necessary. The guest should therefore assume the table is
infinite. Eventually this might allow us
Use the control virtqueue to allow the guest to enable and manipulate
a VLAN filter table. This allows us to drop more packets the guest
doesn't want to see. We define a new VLAN class for the control
virtqueue with commands ADD and DEL with usage defined in virtio-net.h.
Signed-off-by: Alex
From: Rusty Russell ru...@rustcorp.com.au
Date: Thu, 5 Feb 2009 10:07:12 +1030
On Thursday 05 February 2009 05:56:06 Alex Williamson wrote:
Many physical NICs let the OS re-program the hardware MAC
address. Virtual NICs should allow this too.
Signed-off-by: Alex Williamson
There's been a number of different discussions re: getting copyless virtio
net (esp. for KVM). This is just a poke in that general direction to
stir the discussion. I'm interested to hear current thoughts?
thanks
-chris
--
To unsubscribe from this list: send the line unsubscribe kvm in
the
56 matches
Mail list logo
