date:20090730

On Thu, Jul 30, 2009 at 12:30:48PM +0530, Haneef Syed wrote:
 HI All,
 
 If i use kvm-17 or kvm-22, the widget name observed is 'QEMU/KVM but if i 
 use kvm-76 the widget name observed is QEMU only.
 
 Is this strings indicates something??? I want to know irrespective of 
 above strings, kvm driiver functionality is happeening or not..???
 
Type info kvm in qemu monitor.

--
Gleb.
--
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/majordomo-info.html

[ kvm-Bugs-2829519 ] extboot.bin is not built

2009-07-30 Thread SourceForge.net

Bugs item #2829519, was opened at 2009-07-30 11:13
Message generated for change (Tracker Item Submitted) made by dominikklein
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2829519group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: qemu
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominik Klein (dominikklein)
Assigned to: Nobody/Anonymous (nobody)
Summary: extboot.bin is not built

Initial Comment:
I am on openSuSE 11.1 x86_64 on a Dell machine with an Intel E5440 CPU.

I try to compile qemu 0.10.5 using
./configure --prefix=/usr
make
make install

Everything looks good but then I find that extboot.bin is neither (tried to) 
build nor installed.

Copying a version from an older qemu installation worked as suggested by a 
colleague, but I guess that's not the way it is meant to be.

I attached a file with the output of configure, make and make install. If you 
need anything else, just let me know or contact me on IRC, Nickname kleind in 
#kvm on freenode

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2829519group_id=180599
--
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/majordomo-info.html

Re: R/W HG memory mappings with kvm?


On 07/30/2009 02:52 AM, Cam Macdonell wrote:
You need a variant of qemu_ram_alloc() that accepts an fd and offset 
and mmaps that.  A less intrusive, but uglier, alternative is to call 
qemu_ram_alloc() and them mmap(MAP_FIXED) on top of that.



Hi Avi,

I noticed that the region of memory being allocated for shared memory 
using qemu_ram_alloc gets added to the total RAM of the system 
(according to /proc/meminfo).  I'm wondering if this is normal/OK 
since memory for the shared memory device (and similarly VGA RAM) is 
not intended to be used as regular RAM.


qemu_ram_alloc() and the guets /proc/meminfo are totally disconnected.  
I don't understand how that happened.




Should memory of devices be reported as part of MemTotal or is 
something wrong in my use of qemu_ram_alloc()?


You can call qemu_ram_alloc() all you like.  Guest memory is determined 
by the e820 map, which is in turn determined by the -m parameter.


--
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 to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state


On 07/29/2009 05:07 PM, Marcelo Tosatti wrote:

The downside is that we're moving a vmx specific hack to common code.

I think this could be simplified if interrupt injection happened outside
the critical section.  This is needed anyway because emulated interrupt
injection needs to access guest memory (IVT and the stack).
 


Why can't it happen now (outside of the critical section), other than
the kvm_vcpu_kick thing?
   


I think there's little reason now.  One thing we need to do is make it 
possible to call the injection code twice without entering the guest.  I 
think right now it assumes nothing has been injected.


We need either to cancel a previous injection (a variant of 
vmx_complete_interrupts()), or avoid reinjecting  if we already did.


--
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 to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state

On Thu, Jul 30, 2009 at 02:16:30PM +0300, Avi Kivity wrote:
 On 07/29/2009 05:07 PM, Marcelo Tosatti wrote:
 The downside is that we're moving a vmx specific hack to common code.

 I think this could be simplified if interrupt injection happened outside
 the critical section.  This is needed anyway because emulated interrupt
 injection needs to access guest memory (IVT and the stack).
  

 Why can't it happen now (outside of the critical section), other than
 the kvm_vcpu_kick thing?


 I think there's little reason now.  One thing we need to do is make it  
 possible to call the injection code twice without entering the guest.  I  
 think right now it assumes nothing has been injected.

I Looked at this and it seems the current code handle this case.
Injection puts an event on a queue and if we haven't entered a guest
after this point on the next entry event is injected from the queue,
just like if injection failed due to IDT access.

What may happen is that at the time of irq injection there will be irq
with higher irr pending in APIC, But it looks like this already may
happen if injection failed on IDT access, but this is rare.

 We need either to cancel a previous injection (a variant of  
 vmx_complete_interrupts()), or avoid reinjecting  if we already did.

 -- 
 error compiling committee.c: too many arguments to function

--
Gleb.
--
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/majordomo-info.html

Re: [PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state


On 07/30/2009 02:16 PM, Gleb Natapov wrote:

I think there's little reason now.  One thing we need to do is make it
possible to call the injection code twice without entering the guest.  I
think right now it assumes nothing has been injected.

 

I Looked at this and it seems the current code handle this case.
Injection puts an event on a queue and if we haven't entered a guest
after this point on the next entry event is injected from the queue,
just like if injection failed due to IDT access.

   


Good (it was one of the goals of the original interrupt rework, ~2 years 
ago)



What may happen is that at the time of irq injection there will be irq
with higher irr pending in APIC, But it looks like this already may
happen if injection failed on IDT access, but this is rare.
   


Right, we don't guarantee the precise time the APIC selects the vector 
to inject, as long as it's after the last vmexit.


--
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 to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state

On Thu, Jul 30, 2009 at 02:26:24PM +0300, Avi Kivity wrote:
 On 07/30/2009 02:16 PM, Gleb Natapov wrote:
 I think there's little reason now.  One thing we need to do is make it
 possible to call the injection code twice without entering the guest.  I
 think right now it assumes nothing has been injected.

  
 I Looked at this and it seems the current code handle this case.
 Injection puts an event on a queue and if we haven't entered a guest
 after this point on the next entry event is injected from the queue,
 just like if injection failed due to IDT access.



 Good (it was one of the goals of the original interrupt rework, ~2 years  
 ago)

But if we emulate an injection by playing with guest memory and
registers we have to be sure we do it only once.

--
Gleb.
--
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/majordomo-info.html

Re: [PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state


On 07/30/2009 02:24 PM, Gleb Natapov wrote:

Good (it was one of the goals of the original interrupt rework, ~2 years
ago)

 

But if we emulate an injection by playing with guest memory and
registers we have to be sure we do it only once.
   


Once we've successfully updated the stack, inject is complete and we can 
remove the interrupt from the queue.


--
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 to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state

On Thu, Jul 30, 2009 at 02:46:59PM +0300, Avi Kivity wrote:
 On 07/30/2009 02:24 PM, Gleb Natapov wrote:
 Good (it was one of the goals of the original interrupt rework, ~2 years
 ago)

  
 But if we emulate an injection by playing with guest memory and
 registers we have to be sure we do it only once.


 Once we've successfully updated the stack, inject is complete and we can  
 remove the interrupt from the queue.

Then, it we skip actual guest entry for some reason, we will not be
able to tell if we can inject next irq or not.

--
Gleb.
--
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/majordomo-info.html

Re: [PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state

On Thu, Jul 30, 2009 at 02:47:30PM +0300, Gleb Natapov wrote:
 On Thu, Jul 30, 2009 at 02:46:59PM +0300, Avi Kivity wrote:
  On 07/30/2009 02:24 PM, Gleb Natapov wrote:
  Good (it was one of the goals of the original interrupt rework, ~2 years
  ago)
 
   
  But if we emulate an injection by playing with guest memory and
  registers we have to be sure we do it only once.
 
 
  Once we've successfully updated the stack, inject is complete and we can  
  remove the interrupt from the queue.
 
 Then, it we skip actual guest entry for some reason, we will not be
 able to tell if we can inject next irq or not.
 
Actually thinking about it when first irq is injected we should clear IF
flag, so the second one will not happen.

--
Gleb.
--
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/majordomo-info.html

Re: NMI Injection to Guest

2009-07-30 Thread Jiaqing Du

Hi Gleb,

My code works by setting vcpu-arch.nmi_pending = 1; inside
vcpu_enter_guest().


Thanks,
Jiaqing

2009/7/27 Gleb Natapov g...@redhat.com:
 On Sun, Jul 26, 2009 at 09:25:34PM +0200, Jiaqing Du wrote:
 Hi Gleb,

 Thanks for your reply.

 2009/7/26 Gleb Natapov g...@redhat.com:
  On Sat, Jul 25, 2009 at 10:46:39PM +0200, Jiaqing Du wrote:
  Hi list,
 
  I'm trying to extend OProfile to support guest profiling. One step of
  my work is to push an NMI to the guest(s) when a performance counter
  overflows. Please correct me if the following is not correct:
 
  counter overflow -- NMI to host -- VM exit -- int $2 to handle
  NMI on host -- ...   -- VM entry -- NMI to guest
 
  Correct except the last step (-- NMI to guest). Host nmi is not
  propagated to guests.

 Yes. I need to add some code to propagate host NMI to guests.
 
  On the path between VM-exit and VM-entry, I want to push an NMI to the
  guest. I tried to put the following code on the path, but never
  succeeded. Various wired things happened, such as KVM hangs, guest
  kernel oops, and host hangs. I tried both code with Linux 2.6.30 and
  version 88.
 
  if (vmx_nmi_allowed())  { vmx_inject_nmi(); }
 
  Any suggestions? Where is the right place to push an NMI and what are
  the necessary checks?
  Call kvm_inject_nmi(vcpu). And don't forget to vcpu_load(vcpu) before
  doing it. See kvm_vcpu_ioctl_nmi().

 Based on the code with Linux 2.6.30, what kvm_inject_nmi(vcpu) does is
 just set vcpu-arch.nmi_pending to 1. kvm_vcpu_ioctl_nmi() puts
 vcpu_load() before the setting and vcpu_put() after it.

 I need to push host NMI to guests between a VM-exit and a VM-entry
 after that. The VM-exit is due to an NMI caused by performance counter
 overflow. The following code with vcpu_enter_guest(), which is
 surrounded by a vcpu_load() and vcpu_put(), checks this
 vcpu-arch.nmi_pending and other related flags to decide whether an
 NMI should be pushed to guests.

       if (vcpu-arch.exception.pending)
               __queue_exception(vcpu);
       else if (irqchip_in_kernel(vcpu-kvm))
               kvm_x86_ops-inject_pending_irq(vcpu);
       else
               kvm_x86_ops-inject_pending_vectors(vcpu, kvm_run);

 What I did is given below:

 3097 static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct kvm_run 
 *kvm_run)
 3098 {
                ... ...

 3156         if (kvm_vm_exit_on_cnt_overflow) {
 3157                 vcpu-arch.nmi_pending = 1;
 3158         }
 3159
 3160         if (vcpu-arch.exception.pending)
 3161                 __queue_exception(vcpu);
 3162         else if (irqchip_in_kernel(vcpu-kvm))
 3163                 kvm_x86_ops-inject_pending_irq(vcpu);
 3164         else
 3165                 kvm_x86_ops-inject_pending_vectors(vcpu, kvm_run);

               ... 
 3236 }

 In vcpu_enter_guest(), before this part of code is reached,
 vcpu-arch.nmi_pending is set to 1 if the VM-exit is due to
 performance counter overflow. Still, no NMIs are seen by the guests. I
 also tried to put this vcpu-arch.nmi_pending = 1; somewhere else on
 the path between a VM-exit and VM-entry, it does not seem to work
 neither. Only vmx_inject_nmi() manages to push NMIs to guests, but
 without right sanity checks, it causes various wired host and guest
 behaviors.

 To inject NMIs on the path between a VM-exit and VM-entry, what's to try 
 next?

 If you set vcpu-arch.nmi_pending here there vmx_inject_nmi() will be
 called inside kvm_x86_ops-inject_pending_irq(vcpu) (if there is not
 pending exceptions or interrupt at that moment), so if NMI is not
 injected either you have a bug somewhere (why kvm_vm_exit_on_cnt_overflow
 is global?) or you guest ignores NMIs. Does your guest react to NMI if
 you send it via qemu monitor (type nmi 0 in qemu monitor).

 Post you code here, may be I'll see something.

 --
                        Gleb.

--
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/majordomo-info.html

Virtualizing RedHat 6.1

2009-07-30 Thread Davide Bologna


I am installing this old rh release to virtualize some Oracle8i database i need 
to consolidate and mantain until 2011.

The guest installation goes fine, no problem at all. But network is not 
functional. The guest configure eth0 correctly, all drivers are in place, 
routing table is correct, but the guest cannot communicate with any other 
device on the network.

I tried both user network and bridge/tap networking, neither works. I am sure 
my network configuration is correct, i have tested it with other guests that 
works fine, even xp, so i suspect this problem depends from ye old rh, maybe 
some network kernel option; still not analyzed this.

The host is Debian testing (kvm-72).

Does someone on the list as already tried this ? The more I try, less clues I 
get.

Regards

Davide


  
--
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/majordomo-info.html

Re: Virtualizing RedHat 6.1


On 07/30/2009 06:27 PM, Davide Bologna wrote:

I am installing this old rh release to virtualize some Oracle8i database i need 
to consolidate and mantain until 2011.

The guest installation goes fine, no problem at all. But network is not 
functional. The guest configure eth0 correctly, all drivers are in place, 
routing table is correct, but the guest cannot communicate with any other 
device on the network.

I tried both user network and bridge/tap networking, neither works. I am sure 
my network configuration is correct, i have tested it with other guests that 
works fine, even xp, so i suspect this problem depends from ye old rh, maybe 
some network kernel option; still not analyzed this.

The host is Debian testing (kvm-72).

Does someone on the list as already tried this ? The more I try, less clues I 
get.

   


Try changing the guest network driver (there are two rtl8139 drivers 
IIRC) or switching to ne2000.


--
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 to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 1/2] Allow recvmsg for qemu char devices

This patch allows switching from the standard recv to recvmsg for a qemu char
device.  Switching allows file descriptors to be passed with SCM_RIGHTS to a
qemu process.  Instead of receiving a buffer of data the recvmsg call back is
passed a 'struct msghdr'.

The patch also adds a function to add an eventfd as qemu char device.  Perhaps
this should be a separate patch.

This is not an elegant solution to supporting recvmsg so suggestions are
especially welcome.

---
 qemu-char.c |   72 +++
 qemu-char.h |8 ++
 2 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index 287e0cd..c1620c2 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -168,6 +168,11 @@ void qemu_chr_read(CharDriverState *s, uint8_t *buf, int 
len)
 s-chr_read(s-handler_opaque, buf, len);
 }
 
+void qemu_chr_recvmsg(CharDriverState *s, struct msghdr *msg, int flags)
+{
+s-chr_read(s-handler_opaque, msg, flags);
+}
+
 void qemu_chr_accept_input(CharDriverState *s)
 {
 if (s-chr_accept_input)
@@ -1652,6 +1657,7 @@ static CharDriverState *qemu_chr_open_win_pipe(const char 
*filename)
 WinCharState *s;
 
 chr = qemu_mallocz(sizeof(CharDriverState));
+
 s = qemu_mallocz(sizeof(WinCharState));
 chr-opaque = s;
 chr-chr_write = win_chr_write;
@@ -1937,6 +1943,72 @@ static void tcp_chr_read(void *opaque)
 }
 }
 
+/* this is a new function that will replace tcp_chr_read (which calls recv)
+ * with this one that calls recvmsg instead when we want to use recvmsg */
+static void tcp_chr_recvmsg(void *opaque)
+{
+CharDriverState *chr = opaque;
+TCPCharDriver *s = chr-opaque;
+struct msghdr msg;
+uint8_t buf[1024];
+int len, size;
+char control[CMSG_SPACE(RECVMSG_MAX)];
+struct iovec iov[8];
+
+printf(inside tcp_chr_recvmsg\n);
+msg.msg_name = 0;
+msg.msg_namelen = 0;
+msg.msg_control = control;
+msg.msg_controllen = sizeof(control);
+msg.msg_flags = 0;
+msg.msg_iov = iov;
+msg.msg_iovlen = 1;
+
+iov[0].iov_base = buf;
+iov[0].iov_len = 1024;
+
+if (!s-connected || s-max_size = 0)
+return;
+len = sizeof(control);
+if (len  s-max_size)
+len = s-max_size;
+//size = recv(s-fd, buf, len, 0);
+printf(calling recvmsg\n);
+size = recvmsg(s-fd, msg, 0);
+if (size == 0) {
+/* connection closed */
+s-connected = 0;
+if (s-listen_fd = 0) {
+qemu_set_fd_handler(s-listen_fd, tcp_chr_accept, NULL, chr);
+}
+qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+closesocket(s-fd);
+s-fd = -1;
+} else if (size  0) {
+if (s-do_telnetopt)
+tcp_chr_process_IAC_bytes(chr, s, buf, size);
+if (size  0)
+qemu_chr_recvmsg(chr, msg, 0);
+}
+
+
+}
+
+void tcp_switch_to_recvmsg_handlers(void *opaque)
+{
+CharDriverState *chr = opaque;
+TCPCharDriver *s = chr-opaque;
+
+qemu_set_fd_handler2(s-fd, tcp_chr_read_poll,
+ tcp_chr_recvmsg, NULL, chr);
+}
+
+CharDriverState *qemu_chr_open_eventfd(int eventfd){
+
+return qemu_chr_open_fd(eventfd, eventfd);
+
+}
+
 static void tcp_chr_connect(void *opaque)
 {
 CharDriverState *chr = opaque;
diff --git a/qemu-char.h b/qemu-char.h
index e1aa8db..5fe6c43 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -44,6 +44,8 @@ typedef struct {
 #define CHR_TIOCM_DTR  0x002
 #define CHR_TIOCM_RTS  0x004
 
+#define RECVMSG_MAX1024
+
 typedef void IOEventHandler(void *opaque, int event);
 
 struct CharDriverState {
@@ -84,6 +86,12 @@ void qemu_chr_read(CharDriverState *s, uint8_t *buf, int 
len);
 void qemu_chr_accept_input(CharDriverState *s);
 void qemu_chr_info(Monitor *mon);
 
+/* function to change tcp_chr_read to tcp_chr_recvmsg */
+void tcp_switch_to_recvmsg_handlers(void *opaque);
+
+/* add an eventfd to the qemu devices that are polled */
+CharDriverState *qemu_chr_open_eventfd(int eventfd);
+
 extern int term_escape_char;
 
 /* async I/O support */
-- 
1.6.0.6

--
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/majordomo-info.html

[PATCH RFC 2/2] Support shared memory with broadcast interrupts using eventfd

This patch supports shared memory between multiple VMs as well as
point-to-point and broadcast interrupts via eventfds.

This is the third version of this patch.  There is an increase in complexity
due to supporting multiple VMs, eventfds and a shared memory server.

Instead of having one VM act as a server, the VMs now access a shared memory
card server that runs on the host and passes the shared memory fd as well as
the eventfds to each VM on startup.  The server also manages updates to
existing guests when a new guest connects and notification of when VMs
disconnect.

The command-line parameter is now

-ivshmem size in MB,unix:path

where the first parameter is the size of shared memory to map into the device
and the path is the unix domain socket of the shared memory card server.

When a VM connects to the server it receives a file descriptor for the shared
memory and one eventfd for each running VM.  Already running VMs then receive
an update for the new VM's eventfd via a persistent connection to the server.
The server only handles connections and updates, so it is not in the critical
path.

Interrupts are triggered from a guest by ioctl.  Magic numbers are defined in a
enum for different interrupts.  Currently, the driver supports a semaphore and
wait event queue.  Implementation is still light at this point in how
interrupts can be used and will continue to be fleshed out.   The destination
of the VM is specified as an argument to the ioctl by global ID.  VMs can
determine their ID by ioctl.  They can also get a bit vector of active global
IDs.  Broadcast interrupts are supported by sending the magic '255' as the
destination ID.

With the added interrupts and broadcast, producer-consumer interaction and
barriers between VMs are now possible.  Using eventfds lowers overhead  
versus sockets.

There are lots of rough edges due to the added complexity.  Feedback is much
appreciated.

Cam
---
 Makefile.target |3 +
 hw/ivshmem.c|  591 +++
 hw/pc.c |6 +
 hw/pc.h |3 +
 qemu-options.hx |   12 ++
 sysemu.h|8 +
 vl.c|   14 ++
 7 files changed, 637 insertions(+), 0 deletions(-)
 create mode 100644 hw/ivshmem.c

diff --git a/Makefile.target b/Makefile.target
index df1f32b..f0d0169 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -603,6 +603,9 @@ obj-y += pcnet.o
 obj-y += rtl8139.o
 obj-y += e1000.o
 
+# Inter-VM PCI shared memory
+obj-y += ivshmem.o
+
 # Generic watchdog support and some watchdog devices
 obj-y += wdt_ib700.o wdt_i6300esb.o
 
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
new file mode 100644
index 000..aa7fe25
--- /dev/null
+++ b/hw/ivshmem.c
@@ -0,0 +1,591 @@
+/*
+ * Inter-VM Shared Memory PCI device.
+ *
+ * Author:
+ *  Cam Macdonell c...@cs.ualberta.ca
+ *
+ * Based On: cirrus_vga.c and rtl8139.c
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include hw.h
+#include console.h
+#include pc.h
+#include pci.h
+#include sysemu.h
+
+#include qemu-common.h
+#include sys/mman.h
+#include sys/socket.h
+
+#define PCI_COMMAND_IOACCESS0x0001
+#define PCI_COMMAND_MEMACCESS   0x0002
+#define PCI_COMMAND_BUSMASTER   0x0004
+
+#define DEBUG_IVSHMEM
+#define MAX_EVENT_FDS 16
+
+#ifdef DEBUG_IVSHMEM
+#define IVSHMEM_DPRINTF(fmt, args...)\
+do {printf(IVSHMEM:  fmt, ##args); } while (0)
+#else
+#define IVSHMEM_DPRINTF(fmt, args...)
+#endif
+
+#define BROADCAST_VAL ((1  8) - 1)
+
+typedef struct IVShmemState {
+uint16_t intrmask;
+uint16_t intrstatus;
+uint16_t doorbell;
+uint8_t *ivshmem_ptr;
+unsigned long ivshmem_offset;
+unsigned int ivshmem_size;
+unsigned long bios_offset;
+unsigned int bios_size;
+target_phys_addr_t base_ctrl;
+int it_shift;
+PCIDevice *pci_dev;
+CharDriverState * chr;
+CharDriverState * eventfd_chr;
+unsigned long map_addr;
+unsigned long map_end;
+int ivshmem_mmio_io_addr;
+int * eventfds;
+int eventfd_posn;
+uint16_t eventfd_bitvec;
+int num_eventfds;
+} IVShmemState;
+
+typedef struct PCI_IVShmemState {
+PCIDevice dev;
+IVShmemState ivshmem_state;
+} PCI_IVShmemState;
+
+typedef struct IVShmemDesc {
+char name[1024];
+char * chrdev;
+int size;
+} IVShmemDesc;
+
+/* registers for the Inter-VM shared memory device */
+enum ivshmem_registers {
+IntrMask = 0,
+IntrStatus = 16,
+Doorbell = 32,
+IVPosition = 48,
+IVLiveList = 64,
+MemSize = 80
+};
+
+static int num_ivshmem_devices = 0;
+static IVShmemDesc ivshmem_desc;
+
+static void ivshmem_map(PCIDevice *pci_dev, int region_num,
+uint32_t addr, uint32_t size, int type)
+{
+PCI_IVShmemState *d = (PCI_IVShmemState *)pci_dev;
+IVShmemState *s = d-ivshmem_state;
+
+IVSHMEM_DPRINTF(addr = %u size = %u\n, addr, size);
+cpu_register_physical_memory(addr, s-ivshmem_size, s-ivshmem_offset);
+
+}
+
+void

[PATCH RFC 1/2] Allow recvmsg for qemu char devices

This patch allows switching from the standard recv to recvmsg for a qemu char
device.  Switching allows file descriptors to be passed with SCM_RIGHTS to a
qemu process.  Instead of receiving a buffer of data the recvmsg call back is
passed a 'struct msghdr'.

The patch also adds a function to add an eventfd as qemu char device.  Perhaps
this should be a separate patch.

This is not an elegant solution to supporting recvmsg so suggestions are
especially welcome.

---
 qemu-char.c |   72 +++
 qemu-char.h |8 ++
 2 files changed, 80 insertions(+), 0 deletions(-)

diff --git a/qemu-char.c b/qemu-char.c
index 287e0cd..c1620c2 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -168,6 +168,11 @@ void qemu_chr_read(CharDriverState *s, uint8_t *buf, int 
len)
 s-chr_read(s-handler_opaque, buf, len);
 }
 
+void qemu_chr_recvmsg(CharDriverState *s, struct msghdr *msg, int flags)
+{
+s-chr_read(s-handler_opaque, msg, flags);
+}
+
 void qemu_chr_accept_input(CharDriverState *s)
 {
 if (s-chr_accept_input)
@@ -1652,6 +1657,7 @@ static CharDriverState *qemu_chr_open_win_pipe(const char 
*filename)
 WinCharState *s;
 
 chr = qemu_mallocz(sizeof(CharDriverState));
+
 s = qemu_mallocz(sizeof(WinCharState));
 chr-opaque = s;
 chr-chr_write = win_chr_write;
@@ -1937,6 +1943,72 @@ static void tcp_chr_read(void *opaque)
 }
 }
 
+/* this is a new function that will replace tcp_chr_read (which calls recv)
+ * with this one that calls recvmsg instead when we want to use recvmsg */
+static void tcp_chr_recvmsg(void *opaque)
+{
+CharDriverState *chr = opaque;
+TCPCharDriver *s = chr-opaque;
+struct msghdr msg;
+uint8_t buf[1024];
+int len, size;
+char control[CMSG_SPACE(RECVMSG_MAX)];
+struct iovec iov[8];
+
+printf(inside tcp_chr_recvmsg\n);
+msg.msg_name = 0;
+msg.msg_namelen = 0;
+msg.msg_control = control;
+msg.msg_controllen = sizeof(control);
+msg.msg_flags = 0;
+msg.msg_iov = iov;
+msg.msg_iovlen = 1;
+
+iov[0].iov_base = buf;
+iov[0].iov_len = 1024;
+
+if (!s-connected || s-max_size = 0)
+return;
+len = sizeof(control);
+if (len  s-max_size)
+len = s-max_size;
+//size = recv(s-fd, buf, len, 0);
+printf(calling recvmsg\n);
+size = recvmsg(s-fd, msg, 0);
+if (size == 0) {
+/* connection closed */
+s-connected = 0;
+if (s-listen_fd = 0) {
+qemu_set_fd_handler(s-listen_fd, tcp_chr_accept, NULL, chr);
+}
+qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+closesocket(s-fd);
+s-fd = -1;
+} else if (size  0) {
+if (s-do_telnetopt)
+tcp_chr_process_IAC_bytes(chr, s, buf, size);
+if (size  0)
+qemu_chr_recvmsg(chr, msg, 0);
+}
+
+
+}
+
+void tcp_switch_to_recvmsg_handlers(void *opaque)
+{
+CharDriverState *chr = opaque;
+TCPCharDriver *s = chr-opaque;
+
+qemu_set_fd_handler2(s-fd, tcp_chr_read_poll,
+ tcp_chr_recvmsg, NULL, chr);
+}
+
+CharDriverState *qemu_chr_open_eventfd(int eventfd){
+
+return qemu_chr_open_fd(eventfd, eventfd);
+
+}
+
 static void tcp_chr_connect(void *opaque)
 {
 CharDriverState *chr = opaque;
diff --git a/qemu-char.h b/qemu-char.h
index e1aa8db..5fe6c43 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -44,6 +44,8 @@ typedef struct {
 #define CHR_TIOCM_DTR  0x002
 #define CHR_TIOCM_RTS  0x004
 
+#define RECVMSG_MAX1024
+
 typedef void IOEventHandler(void *opaque, int event);
 
 struct CharDriverState {
@@ -84,6 +86,12 @@ void qemu_chr_read(CharDriverState *s, uint8_t *buf, int 
len);
 void qemu_chr_accept_input(CharDriverState *s);
 void qemu_chr_info(Monitor *mon);
 
+/* function to change tcp_chr_read to tcp_chr_recvmsg */
+void tcp_switch_to_recvmsg_handlers(void *opaque);
+
+/* add an eventfd to the qemu devices that are polled */
+CharDriverState *qemu_chr_open_eventfd(int eventfd);
+
 extern int term_escape_char;
 
 /* async I/O support */
-- 
1.6.0.6

--
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/majordomo-info.html

[PATCH RFC] Driver to support shared memory with interrupts with broadcast

This driver allows the guest VM to access shared memory between other guest
that is a POSIX shared memory object on the host.  The driver can also send
interrupts by writing to the DoorBell register.

With interrupts, the ioctl must specify the ID of the VM to receive the
interrupt or '255' for broadcast to all active VMs.  The 'arg' parameter is the
destination VM and 'cmd' is the interrupt code.  The value written to the
register is a bit messy.  32-bits are written to the register, the upper 16 are
the destination VM, and the lower 16 are the interrupt 'code' that the
destination guest will receive.  Implemented codes (see the interrupt handler)
either call up on the device's semaphore or wake up on the wait_event queue.
These codes' uses are at the discretion of the driver so they could be
customized.

For ioctls that read values from the device (such as for getting the global ID
of the guest) the arg parameter is unused.

Cam

---
 drivers/char/Kconfig   |8 +
 drivers/char/Makefile  |2 +
 drivers/char/kvm_ivshmem.c |  447 
 3 files changed, 457 insertions(+), 0 deletions(-)
 create mode 100644 drivers/char/kvm_ivshmem.c

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 6a06913..ee22531 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -1108,6 +1108,14 @@ config DEVPORT
depends on ISA || PCI
default y
 
+config KVM_IVSHMEM
+tristate Inter-VM Shared Memory Device
+depends on PCI
+default m
+help
+  This device maps a region of shared memory between the host OS and any
+  number of virtual machines.
+
 source drivers/s390/char/Kconfig
 
 endmenu
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 66f779a..bd15809 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -111,6 +111,8 @@ obj-$(CONFIG_PS3_FLASH) += ps3flash.o
 obj-$(CONFIG_JS_RTC)   += js-rtc.o
 js-rtc-y = rtc.o
 
+obj-$(CONFIG_KVM_IVSHMEM)  += kvm_ivshmem.o
+
 # Files generated that shall be removed upon make clean
 clean-files := consolemap_deftbl.c defkeymap.c
 
diff --git a/drivers/char/kvm_ivshmem.c b/drivers/char/kvm_ivshmem.c
new file mode 100644
index 000..ce5c8ad
--- /dev/null
+++ b/drivers/char/kvm_ivshmem.c
@@ -0,0 +1,447 @@
+/*
+ * drivers/char/kvm_ivshmem.c - driver for KVM Inter-VM shared memory PCI 
device
+ *
+ * Copyright 2009 Cam Macdonell c...@cs.ualberta.ca
+ *
+ * Based on cirrusfb.c and 8139cp.c:
+ * Copyright 1999-2001 Jeff Garzik
+ * Copyright 2001-2004 Jeff Garzik
+ *
+ */
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/proc_fs.h
+#include linux/smp_lock.h
+#include asm/uaccess.h
+#include linux/interrupt.h
+#include linux/mutex.h
+
+#define TRUE 1
+#define FALSE 0
+#define KVM_IVSHMEM_DEVICE_MINOR_NUM 0
+
+enum {
+/* KVM Inter-VM shared memory device register offsets */
+IntrMask= 0x00,/* Interrupt Mask */
+IntrStatus  = 0x10,/* Interrupt Status */
+Doorbell= 0x20,/* Doorbell */
+IVPosition  = 0x30,
+IVLiveList  = 0x40,
+ShmOK = 1/* Everything is OK */
+};
+
+typedef struct kvm_ivshmem_device {
+void __iomem * regs;
+
+void * base_addr;
+
+unsigned int regaddr;
+unsigned int reg_size;
+
+unsigned int ioaddr;
+unsigned int ioaddr_size;
+unsigned int irq;
+
+bool enabled;
+
+} kvm_ivshmem_device;
+
+static int event_num;
+static struct semaphore sema;
+static wait_queue_head_t wait_queue;
+
+static kvm_ivshmem_device kvm_ivshmem_dev;
+
+static int device_major_nr;
+
+static int kvm_ivshmem_ioctl(struct inode *, struct file *, unsigned int, 
unsigned long);
+static int kvm_ivshmem_mmap(struct file *, struct vm_area_struct *);
+static int kvm_ivshmem_open(struct inode *, struct file *);
+static int kvm_ivshmem_release(struct inode *, struct file *);
+static ssize_t kvm_ivshmem_read(struct file *, char *, size_t, loff_t *);
+static ssize_t kvm_ivshmem_write(struct file *, const char *, size_t, loff_t 
*);
+static loff_t kvm_ivshmem_lseek(struct file * filp, loff_t offset, int origin);
+
+enum ivshmem_ioctl { set_sema, down_sema, sema_irq, wait_event, 
wait_event_irq, read_ivposn, read_livelist };
+
+static const struct file_operations kvm_ivshmem_ops = {
+.owner   = THIS_MODULE,
+.open= kvm_ivshmem_open,
+.mmap= kvm_ivshmem_mmap,
+.read= kvm_ivshmem_read,
+.ioctl   = kvm_ivshmem_ioctl,
+.write   = kvm_ivshmem_write,
+.llseek  = kvm_ivshmem_lseek,
+.release = kvm_ivshmem_release,
+};
+
+static struct pci_device_id kvm_ivshmem_id_table[] = {
+{ 0x1af4, 0x1110, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+{ 0 },
+};
+MODULE_DEVICE_TABLE (pci, kvm_ivshmem_id_table);
+
+static void kvm_ivshmem_remove_device(struct pci_dev* pdev);
+static int kvm_ivshmem_probe_device (struct pci_dev *pdev,
+

stopping the system clock

2009-07-30 Thread Roman Steiner


hej hej,

i've a question about the virtual time implementation in kvm/qemu.  
with the monitor commands stop / continue you can stop and start the  
guest system, but the system clock is still running.


i\ve done the following experiment:
* start the guest system
* display the system time by running 'date' in the guest system
* stop via the monitor
* way for a minute or so
* continue via the monitor
* display the system time with 'date' in the guest system
result: the system clock of the guest system was running the whole time

for what i need it:
i'm working on a simulation of a wireless network with at least 100  
nodes (routers). each node should be represented by a kvm instance  
with a minimal os and some daemons (mainyl routing deamons). because  
the system gets overloaded some processes (kvm instances) are starving  
and the simulation is not working any more. so i would like to stop  
and start the guest system by the simulation program to keep them in  
order. therefore stopping and starting must be fast and it must be a  
full stop.


if i have to write a patch for qemu, that's fine for me. i just have  
no idea which parts of the source-code i have to change.


thx for your help,
roman

--
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/majordomo-info.html

Re: [PATCH RFC 1/2] Allow recvmsg for qemu char devices

2009-07-30 Thread Anthony Liguori


Cam Macdonell wrote:

This patch allows switching from the standard recv to recvmsg for a qemu char
device.  Switching allows file descriptors to be passed with SCM_RIGHTS to a
qemu process.  Instead of receiving a buffer of data the recvmsg call back is
passed a 'struct msghdr'.

The patch also adds a function to add an eventfd as qemu char device.  Perhaps
this should be a separate patch.

This is not an elegant solution to supporting recvmsg so suggestions are
especially welcome.
  


Use the sendfd/closefd commands that Mark introduced.

Regards,

Anthony Liguori
--
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/majordomo-info.html

Re: Virtualizing RedHat 6.1

2009-07-30 Thread Michael Tokarev


Davide Bologna wrote:

I am installing this old rh release to virtualize some Oracle8i database i need 
to consolidate and mantain until 2011.


Just for you information: oracle8i works fine on current linux (we use debian 
5.0).
Even on 64bit platform 32bit oracle works, but for that you need a little 
wrapper
to tell linux to use old 3Gb user/kernel memory split (I can show you more 
details
if you want).

That all to say: there's no need to run Oracle8i on old (and buggy) system, 
current
linux works.

[]

The host is Debian testing (kvm-72).


Upgrade to 0.10.5.  You can use my packages 
(http://www.corpit.ru/debian/tls/kvm) if
you want.

But better just run real system, without any virt stuff.

/mjt
--
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/majordomo-info.html

Re: [PATCH RFC] Driver to support shared memory with interrupts with broadcast

2009-07-30 Thread Anthony Liguori


Cam Macdonell wrote:

This driver allows the guest VM to access shared memory between other guest
that is a POSIX shared memory object on the host.  The driver can also send
interrupts by writing to the DoorBell register.

With interrupts, the ioctl must specify the ID of the VM to receive the
interrupt or '255' for broadcast to all active VMs.  The 'arg' parameter is the
destination VM and 'cmd' is the interrupt code.  The value written to the
register is a bit messy.  32-bits are written to the register, the upper 16 are
the destination VM, and the lower 16 are the interrupt 'code' that the
destination guest will receive.  Implemented codes (see the interrupt handler)
either call up on the device's semaphore or wake up on the wait_event queue.
These codes' uses are at the discretion of the driver so they could be
customized.

For ioctls that read values from the device (such as for getting the global ID
of the guest) the arg parameter is unused.

Cam
  


I think you should just use Michael's uio_pci driver.  I don't think we 
have a need for a new kernel interface.


Regards,

Anthony Liguori
--
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/majordomo-info.html

Re: [PATCH RFC] Driver to support shared memory with interrupts with broadcast

2009-07-30 Thread Michael S. Tsirkin

On Thu, Jul 30, 2009 at 01:29:52PM -0500, Anthony Liguori wrote:
Cam Macdonell wrote:
This driver allows the guest VM to access shared memory between other guest
that is a POSIX shared memory object on the host. The driver can also send
interrupts by writing to the DoorBell register.

With interrupts, the ioctl must specify the ID of the VM to receive the
interrupt or '255' for broadcast to all active VMs. The 'arg' parameter is
the
destination VM and 'cmd' is the interrupt code. The value written to the
register is a bit messy. 32-bits are written to the register, the upper 16
are
the destination VM, and the lower 16 are the interrupt 'code' that the
destination guest will receive. Implemented codes (see the interrupt
handler)
either call up on the device's semaphore or wake up on the wait_event queue.
These codes' uses are at the discretion of the driver so they could be
customized.

For ioctls that read values from the device (such as for getting the global
ID
of the guest) the arg parameter is unused.

Cam

I think you should just use Michael's uio_pci driver. I don't think we
have a need for a new kernel interface.

If that's what you want to do, an example device that generates
interrupts in response to config writes can be found here:
http://www.archivum.info/qemu-de...@nongnu.org/2009-07/01548/%5BQemu-devel%5D_%5BPATCH%5D_qemu:_test-irq_device

Regards,

Anthony Liguori
--
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/majordomo-info.html
--
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/majordomo-info.html

Re: [PATCH RFC] Driver to support shared memory with interrupts with broadcast