Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
I'd strongly recommend working these patches on qemu-devel and
lkml. I suspect Avi may disagree with me, but in order for this to
be eventually merged in either place, you're going to have
additional requirements put on you.
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
I'd strongly recommend working these patches on qemu-devel and
lkml. I suspect Avi may disagree with me, but in order for this to
be eventually merged in either place, you're going to have
additional
Anthony Liguori wrote:
I'd strongly recommend working these patches on qemu-devel and
lkml. I suspect Avi may disagree with me, but in order for this
to be eventually merged in either place, you're going to have
additional requirements put on you.
I don't disagree with the fact that there
...@vger.kernel.org] On Behalf Of
Kumar, Venkat
Sent: Tuesday, May 19, 2009 9:22 AM
To: Cam Macdonell
Cc: kvm@vger.kernel.org list
Subject: RE: [PATCH v2] Shared memory device with interrupt support
I had tried all syntaxes other than this :).
Interrupts work now.
Thx,
Venkat
-Original Message
Jayaraman, Bhaskar wrote:
Cam, is it somehow possible to generate a local APIC interrupt from one VM to
another? I guess it shouldn't be as the LAPIC interrupts generated in one VM
will go to the VCPUs of the same VM...
Regards,
Bhaskar.
The closest thing to this is the
Avi Kivity wrote:
Anthony Liguori wrote:
I'd strongly recommend working these patches on qemu-devel and lkml.
I suspect Avi may disagree with me, but in order for this to be
eventually merged in either place, you're going to have additional
requirements put on you.
I don't disagree with
Avi Kivity wrote:
Cam Macdonell wrote:
If my understanding is correct both the VM's who wants to
communicate would gives this path in the command line with one of
them specifying as server.
Exactly, the one with the server in the parameter list will wait
for a connection before booting.
Gregory Haskins wrote:
I'll just add that you could tie the irqfd to an iosignalfd to eliminate
the involvement of qemu on either side as well. I'm not sure if that
really works with the design of this particular device (e.g. perhaps
qemu is needed for other reasons besides signaling), but it
, May 16, 2009 9:01 AM
To: Kumar, Venkat
Cc: kvm@vger.kernel.org list
Subject: Re: [PATCH v2] Shared memory device with interrupt support
On 15-May-09, at 8:54 PM, Kumar, Venkat wrote:
Cam,
A questions on interrupts as well.
What is unix:path that needs to be passed in the argument list?
Can
:01 AM
To: Kumar, Venkat
Cc: kvm@vger.kernel.org list
Subject: Re: [PATCH v2] Shared memory device with interrupt support
On 15-May-09, at 8:54 PM, Kumar, Venkat wrote:
Cam,
A questions on interrupts as well.
What is unix:path that needs to be passed in the argument list?
Can it be any string
Cam Macdonell wrote:
My usual noob questions: Do I need to run Greg's tree on the host for
the necessary irqfd/eventfd suppport?
Yes (though irqfd will be merged real soon, and iosignalfd somewhat
afterwards).
Are there any examples to work from aside from Greg's unit tests?
No.
Hi Cam,
Cam Macdonell wrote:
Support an inter-vm shared memory device that maps a shared-memory object as a PCI device in the guest. This patch also supports interrupts between guest by communicating over a unix domain socket. This patch applies to the qemu-kvm repository.
This device
, May 16, 2009 9:01 AM
To: Kumar, Venkat
Cc: kvm@vger.kernel.org list
Subject: Re: [PATCH v2] Shared memory device with interrupt support
On 15-May-09, at 8:54 PM, Kumar, Venkat wrote:
Cam,
A questions on interrupts as well.
What is unix:path that needs to be passed in the argument list
Anthony Liguori wrote:
I'd strongly recommend working these patches on qemu-devel and lkml.
I suspect Avi may disagree with me, but in order for this to be
eventually merged in either place, you're going to have additional
requirements put on you.
I don't disagree with the fact that there
Cam Macdonell wrote:
I don't think so. With the mmap call, I specify MAP_FIXED which
requires that the memory in the shared memory object be mapped to the
address given in the first parameter (s-ivshmem_ptr). If MAP_FIXED
is not specified then mmap would allocate the memory and map on to
Cam Macdonell wrote:
If my understanding is correct both the VM's who wants to communicate
would gives this path in the command line with one of them specifying
as server.
Exactly, the one with the server in the parameter list will wait for
a connection before booting.
hm, we may be able
Hi Cam, I have gone through you latest shared memory patch.
I have a few questions and comments.
Comment:-
+if (ivshmem_enabled) {
+ivshmem_init(ivshmem_device);
+ram_size += ivshmem_get_size();
+}
+
In your initial patch this part of the patch is
+if
On 15-May-09, at 8:45 PM, Kumar, Venkat wrote:
Hi Cam, I have gone through you latest shared memory patch.
I have a few questions and comments.
Comment:-
+if (ivshmem_enabled) {
+ivshmem_init(ivshmem_device);
+ram_size += ivshmem_get_size();
+}
+
In your initial patch
On 15-May-09, at 8:54 PM, Kumar, Venkat wrote:
Cam,
A questions on interrupts as well.
What is unix:path that needs to be passed in the argument list?
Can it be any string?
It has to be a valid path on the host. It will create a unix domain
socket on that path.
If my understanding is
19 matches
Mail list logo
