Hi All,
I need to run ESXI as nested HV in KVM.
Do you know if this patch has been ported to any qemu release and maybe
available as RPM? ( Fedora, Redhat, Centos etc. )
https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03806.html
Regards,
Ikbal Cam
rk to get the UIO ivshmem driver into the kernel.
Sincerely,
Cam
.
Sorry for the delay in contributing to this conversation.
Cheers,
Cam
On Sat, Jun 21, 2014 at 3:34 AM, Stefan Hajnoczi wrote:
> On Wed, Jun 18, 2014 at 10:57 PM, David Marchand
> wrote:
> > On 06/18/2014 12:48 PM, Stefan Hajnoczi wrote:
> >>
> >> One
Hi Vince,
Yes, I did see the patches for the new server. I will review within the
week.
Cheers,
Cam
On Thu, Jun 26, 2014 at 9:37 AM, Vincent JARDIN
wrote:
> Hi Cam,
>
> FYI, David did implement a new server.
> http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg04978.ht
h some parameters? Does this mean I now share memory between
> guest and host? If I run multiple guest providing the same device name, can
> I make them use the same shared memory without the need of any server?
>
Yes, the server is only necessary for the interrupt behaviour.
>
> > (memnic for example works this way http://dpdk.org/browse/memnic),
>
> I'll check that out..
>
> > - the more advanced way, basically, if you want an event mechanism
> between the
> > VMs using your ivshmem device. In this case, then you will most likely
> want to
> > write a kernel driver that will handle interrupts.
>
> Ok.
>
> Let me ask you this, what about virtio?
> Can I take this shared memory implementation, and then run virtio on top
> of that, which already has primitives for communication?
>
> I understand this would restricts me to 1 vs 1 communication, while with
> the optional server in contrib/ I would have any to any communication
> available.
>
> But what about the 1 to 1 guest-to-guest communication, is in this case in
> theory possible to put virtio on top of ivshmem and use that to make the
> two guests communicate?
>
> This is just a list of questions that we came up with, but anybody please
> weigh in with your additional questions, comments, feedback. Especially I
> would like to know if the idea to have a virtio guest to guest
> communication is possible and realistic, maybe with minimal extension of
> virtio, or if I am being insane.
>
>
There was originally a virtio-based version of ivshmem. You could see the
discussion around that sometime in 2009. I think you could use virtio over
ivshmem but the 1-to-1 case is quite limiting. Virtio is well optimized
for what it does and so it was decided to keep the two separate.
HTH,
Cam
Thank you,
>
> Claudio
>
>
>
>
Hello,
The patch for this later bug has been proposed. I'm not sure why it's not
merged.
http://patchwork.ozlabs.org/patch/316785/
Cheers,
Cam
On Thu, May 1, 2014 at 10:53 AM, Gene Snider wrote:
> When I tried the same thing with git master (latest) I get a diff
Hi David,
I'm not sure which is the correct approach. You could either do what you
did or you could simply remove the qemu_chr_fe_claim_no_fail() from
ivshmem.c. I'm not sure how your change impacts other devices.
Sincerely,
Cam
On Tue, Feb 4, 2014 at 2:17 PM, David Marchand wrote
Hello,
Can you please try with the most recent version? I would suggest building
from the source code which can be found here:
http://qemu-project.org/Main_Page
Sincerely,
Cam
On Tue, Jul 2, 2013 at 7:50 PM, DAI Weibin
wrote:
> Hello Cam,
>
> I am honored that receive y
Hello Dai,
Which qemu version you are using? When you say QEMU/KVM "doesn't work", do
you mean it does not start?
Cam
On Mon, Jul 1, 2013 at 12:39 AM, DAI Weibin wrote:
> Hi all,
> When use nahanni device as following, The QEMU/KVM doesn’t work.
> I attach two ivs
On Wed, Dec 5, 2012 at 1:50 AM, Jan Kiszka wrote:
> On 2012-12-05 06:34, Cam Macdonell wrote:
>>> static void ivshmem_write_config(PCIDevice *pci_dev, uint32_t address,
>>> uint32_t val, int len)
>>> {
>>> +bool is_ena
On Sat, Nov 24, 2012 at 8:51 PM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> This logic has been integrated into pci core, so remove it.
>
> Signed-off-by: Liu Ping Fan
Signed-off-by: Cam Macdonell
> ---
> hw/ivshmem.c |1 -
> 1 files changed, 0 insertions(+),
x27;ll also have to not add the handlers as below if irqfd is present
otherwise we'll get double interrupts, so we'll have to add a check
here too.
/* if MSI is supported we need multiple interrupts */
if (!ivshmem_has_feature(s, IVSHMEM_MSI)) {
s->eventfd_table[vector].pdev = &s->dev;
s->eventfd_table[vector].vector = vector;
qemu_chr_add_handlers(chr, ivshmem_can_receive, fake_irqfd,
ivshmem_event, &s->eventfd_table[vector]);
} else {
qemu_chr_add_handlers(chr, ivshmem_can_receive, ivshmem_receive,
ivshmem_event, s);
}
Sincerely,
Cam
On Tue, Dec 4, 2012 at 4:10 AM, Andrew Jones wrote:
>
>
> - Original Message -
>> On Thu, Nov 29, 2012 at 1:34 AM, liu ping fan
>> wrote:
>> > On Thu, Nov 29, 2012 at 12:42 PM, Cam Macdonell
>> > wrote:
>> >> On Tue, Nov 27, 2012 at 7:5
On Thu, Nov 29, 2012 at 1:34 AM, liu ping fan wrote:
> On Thu, Nov 29, 2012 at 12:42 PM, Cam Macdonell wrote:
>> On Tue, Nov 27, 2012 at 7:53 PM, liu ping fan wrote:
>>> On Wed, Nov 28, 2012 at 5:48 AM, Cam Macdonell wrote:
>>>> On Sat, Nov 24, 2012 at 8:51 PM, L
On Tue, Nov 27, 2012 at 7:53 PM, liu ping fan wrote:
> On Wed, Nov 28, 2012 at 5:48 AM, Cam Macdonell wrote:
>> On Sat, Nov 24, 2012 at 8:51 PM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> Using irqfd, so we can avoid switch between kernel and use
On Sat, Nov 24, 2012 at 8:51 PM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Using irqfd, so we can avoid switch between kernel and user when
> VMs interrupts each other.
Nice work. Due to a hardware failure, there will be a small delay in
me being able to test this. I'll follow up as soon as
Can this patch be included in 1.2?
Thanks,
Cam
On Thu, Aug 23, 2012 at 6:49 AM, Gerd Hoffmann wrote:
> This patch adds a "use64" property which will make the ivshmem driver
> register a 64bit memory bar when set, so you have something to play with
> when testing 64bit pci bi
and load.
> For virtio, clear it explicitly.
> This should fix regressions reported with ivshmem - though
> I didn't test this, I verified that virtio keeps
> working like it did.
>
> Signed-off-by: Michael S. Tsirkin
Tested-by: Cam Macdonell
> ---
> hw/msix.c
Yes, will test shortly.
Cam
On Wed, Aug 29, 2012 at 10:47 AM, Michael S. Tsirkin wrote:
> On Wed, Aug 29, 2012 at 06:44:49PM +0200, Jan Kiszka wrote:
>> On 2012-08-29 18:40, Michael S. Tsirkin wrote:
>> > The facility to use/unuse vectors dynamically is helpful
>> >
setup_ioeventfds() is unnecessary and actually causes a segfault when used
ioeventfd=on is used on the command-line. Since ioeventfds are handled within
the memory API, it can be removed.
Signed-off-by: Cam Macdonell
---
hw/ivshmem.c | 15 ---
1 files changed, 0 insertions(+), 15
also unbreaks MSI-X after reset for ivshmem and megasas as device
> models can't easily mark their vectors used afterward (megasas didn't
> even try).
>
> Signed-off-by: Jan Kiszka
Tested-by: Cam Macdonell
> ---
>
> This patch has been posted some moons again, and we had
27;t ivshmem's reset (which reenables the vectors) be triggered
by the msix_reset?
Thanks,
Cam
p.s. And apologies, I should've caught this bug closer to that patch
being merged.
On Wed, Aug 22, 2012 at 6:01 AM, Paolo Bonzini wrote:
> Il 22/08/2012 06:29, Cam Macdonell ha scritto:
>> Hi Paolo,
>>
>> I've noticed an assertion error when sending interrupts via ivshmem.
>> I bisected to this patch.
>
> Does this help?
Yes, that solves i
s usage of eventfd now has a corresponding API in
EventNotifier. Simplify the code by using it, and also use the
memory API consistently to set up and tear down the ioeventfds.
Signed-off-by: Paolo Bonzini
Signed-off-by: Avi Kivity
qemu-system-x86_64: /home/cam/src/git/qemu/mem
gt; Memory at fd40 (32-bit, non-prefetchable) [disabled] [size=256]
> Memory at 804000 (64-bit, prefetchable) [size=1G]
>
> [ v3: rebase & adapt to latest master ]
> [ v2: default to on as suggested by avi,
> turn off for pc-$old using compat property
Can this patch please be merged? It fixes an important regression
with ioeventfd.
Thanks,
Cam
On Thu, Nov 24, 2011 at 3:05 AM, wrote:
> From: Hongyong Zang
>
> When a guest boots with ioeventfd, an error (by gdb) occurs:
> Program received signal SIGSEGV, Segmen
Hello,
Can this patch be merged, please?
Thanks,
Cam
On Mon, Dec 5, 2011 at 12:48 PM, Michael S. Tsirkin wrote:
> ivshmem used msix but didn't call it on either reset or
> config write paths. This used to partically work since
> guests don't use all of msi-x configuration
2011/12/2 Cam Macdonell :
> 2011/11/30 Cam Macdonell :
>> 2011/11/30 Zang Hongyong :
>>> Can this bug fix patch be applied yet?
>>
>> Sorry, for not replying yet. I'll test your patch within the next day.
>
> Have you confirmed the proper receipt of inte
On Mon, Dec 5, 2011 at 2:08 AM, Michael S. Tsirkin wrote:
> On Sun, Dec 04, 2011 at 04:47:17PM -0700, Cam Macdonell wrote:
>> On Sun, Dec 4, 2011 at 3:20 AM, Michael S. Tsirkin wrote:
>> > On Fri, Dec 02, 2011 at 04:34:21PM -0700, Cam Macdonell wrote:
>> >> Bas
On Sun, Dec 4, 2011 at 3:20 AM, Michael S. Tsirkin wrote:
> On Fri, Dec 02, 2011 at 04:34:21PM -0700, Cam Macdonell wrote:
>> Based on a git bisect, this patch breaks msi-x interrupt delivery in
>> the ivshmem device.
>
> I think the following should fix it. Compiled-only -
sked(dev)) {
> + if (dev->msix_function_masked == was_masked) {
> return;
> }
So I believe my bug is due to the fact the new logic included in this
patch requires msix_write_config() to be called to unmask the vectors.
Virtio-pci calls msix_write_config(), but ivshmem
2011/11/30 Cam Macdonell :
> 2011/11/30 Zang Hongyong :
>> Can this bug fix patch be applied yet?
>
> Sorry, for not replying yet. I'll test your patch within the next day.
Have you confirmed the proper receipt of interrupts in the receiving guests?
I can confirm the bug o
y post the new patch, just clarify that it's
dependent on this patch.
Sincerely,
Cam
>
> Thanks,
> Hongyong
>
> 于 2011/11/24,星期四 18:05, zanghongy...@huawei.com 写道:
>> From: Hongyong Zang
>>
>> When a guest boots with ioeventfd, an error (by gdb) occurs:
>
On Thu, Nov 17, 2011 at 10:50 PM, wrote:
> From: Hongyong Zang
>
> This patch, adds a PIO BAR3 for guest notifying qemu. And we find the new
> notification way of PIO BAR3 reduces 30% time in comparison with the original
> MMIO BAR0 way.
Come to think of it, should we bump the PIO to BAR4 so
Unless I
misunderstand how the two are necessarily related.
Cam
>
> Signed-off-by: Hongyong Zang
> ---
> hw/ivshmem.c | 41 ++---
> 1 files changed, 14 insertions(+), 27 deletions(-)
>
> diff --git a/hw/ivshmem.c b/hw/ivshmem.c
&
t that rate. Of course, one would expect
that a single notification should be faster based on these results,
but I'm just curious.
Do you know of any issues with mapping a PIO region to user-space with
the UIO driver framework?
Thanks,
Cam
>
> Signed-off-by: Hong
by "ways for guests to communicate"?
As for ioeventfds, they are an optional optimization to eventfds. We
use eventfds currently, but since the guest VMs only see file
descriptors (passed from the server) another mechanism could replace
eventfds if there was some reason to.
Cam
a quick sketch of the
> client-server protocol or possibly point me to something that documents
> it?
Hi Sasha,
I have something like that. I'll be in touch when I find it.
Cam
>
> --
>
> Sasha.
>
>
On Mon, Jun 20, 2011 at 3:05 AM, Jan Kiszka wrote:
> On 2011-06-19 22:46, Cam Macdonell wrote:
>> On Thu, Jun 9, 2011 at 2:39 PM, Jan Kiszka wrote:
>>> On 2011-06-09 22:00, Anthony Liguori wrote:
>>>> On 06/09/2011 11:44 AM, Jan Kiszka wrote:
>>>
'll post a patch.
>
> Jan
>
>
The migratability of ivshmem is not dynamic in that it doesn't change
at runtime, it's set when the device is created, either role=peer or
role=master is specified. So iiuc, this could work with ivshmem.
Cam
On Mon, Dec 13, 2010 at 8:00 PM, Isaku Yamahata wrote:
> On Mon, Dec 13, 2010 at 03:43:44PM -0700, Cam Macdonell wrote:
>> Do not call pci_update_mappings on the lower 32-bits of a 64-bit bar. Wait
>> for the upper 32 or else Qemu will try to map on just the lower 32 which is
&g
er
4-bits to only be MEM_TYPE_64 flag. Upper 32-bit address parts can be values
like 0xff which is tricky to test against.
Cam
---
hw/pci.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 438c0d1..3b81792 100644
--- a/hw/pci.c
+++ b/hw/pci.c
This allows 'peer' ivshmem guests to detach from shared memory before migration
and re-attach after migration is complete.
Signed-off-by: Cam Macdonell
---
hw/ivshmem.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
ind
add function to free memory from Qemu that was added via
qemu_ram_alloc_from_ptr. Name is a little weird. This is copied from
qemu_ram_unmap from qemu-kvm.
Signed-off-by: Cam Macdonell
---
cpu-common.h |1 +
exec.c | 13 +
2 files changed, 14 insertions(+), 0
We added qemu_ram_alloc_from_ptr, but we need its corresponding "free"
function. With that, we can properly remove the ivshmem memory on unplug.
Cam Macdonell (2):
add qemu_ram_free_from_ptr
Unregister shared memory on unplug.
cpu-common.h |1 +
exec.c | 13 +++
so fixes an assert on hotplug removal of coldplugged
> express devices.
>
> Reported-by: by Cam Macdonell .
> Signed-off-by: Isaku Yamahata
> Signed-off-by: Michael S. Tsirkin
Acked-by: Cam Macdonell
> ---
>
> So I think the below would be the cleanest way
> to fix t
to be unplugged the desired behaviour?
Thanks,
Cam
commit 5beb8ad503c88a76f2b8106c3b74b4ce485a60e1
Author: Isaku Yamahata
Date: Mon Sep 6 16:46:18 2010 +0900
pci: call hotplug callback even when not hotplug case for later use.
call hotplug callback even when not hotplug case for later us
On Fri, Sep 17, 2010 at 3:15 PM, Chris Wright wrote:
> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
>> On Fri, Sep 17, 2010 at 2:52 PM, Cam Macdonell wrote:
>> > On Fri, Sep 17, 2010 at 2:04 PM, Chris Wright wrote:
>> >> * Cam Macdonell (c...@cs.ualberta.ca)
On Fri, Sep 17, 2010 at 2:52 PM, Cam Macdonell wrote:
> On Fri, Sep 17, 2010 at 2:04 PM, Chris Wright wrote:
>> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
>>> After fixing the resource_size_t return value with
>>> pci_resource_alignment, I see one other strange be
On Fri, Sep 17, 2010 at 2:04 PM, Chris Wright wrote:
> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
>> After fixing the resource_size_t return value with
>> pci_resource_alignment, I see one other strange behaviour only when
>> using 4GB of RAM and a 2GB BAR. I ha
MEM: guest pci addr = 18000, guest h/w addr = 4312137728, size
= 8000
pci_read_config: (val) 0x1 <- 0x1c (addr)
Any pointers are appreciated,
Cam
tic inline resource_size_t pci_resource_alignment(struct pci_dev *dev,
struct resource *res)
{
#ifdef CONFIG_PCI_IOV
On Mon, Sep 6, 2010 at 11:24 AM, Cam Macdonell wrote:
> On Mon, Sep 6, 2010 at 10:37 AM, Cam Macdonell wrote:
>>
>>
>>
On Mon, Sep 6, 2010 at 10:37 AM, Cam Macdonell wrote:
>
>
> On Sun, Sep 5, 2010 at 10:50 AM, Avi Kivity wrote:
>>
>> On 09/04/2010 01:22 AM, Cam Macdonell wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to test 2 GB (and eventually larger) BA
On Sun, Sep 5, 2010 at 10:50 AM, Avi Kivity wrote:
> On 09/04/2010 01:22 AM, Cam Macdonell wrote:
>
>> Hi,
>>
>> I'm trying to test 2 GB (and eventually larger) BARs with ivshmem and
>> I get an error in the guest that it is able to find a mem resource for
&
00 to
'tmp.end' 9f3ff
trying 'tmp.start' a to
'tmp.end' e
trying 'tmp.start' 10 to
'tmp.end' f
trying 'tmp.start' dfffd000 to
'tmp.end' dfffcfff
pci :00:04.0: BAR 2: can't assign mem (size 0x8000)
Is there a limit to PCI BAR sizes or resources? Any pointers or
further debugging tips are greatly appreciated.
Thanks,
Cam
/Features/VirtioSerial
Cam
>
> --
> Vasiliy G Tolstov
> Selfip.Ru
>
>
On Tue, Aug 31, 2010 at 9:56 PM, Cam Macdonell wrote:
> On Tue, Aug 31, 2010 at 6:51 PM, Hao, Xudong wrote:
>> Hao, Xudong wrote:
>>> jes.soren...@redhat.com wrote:
>>>> From: Jes Sorensen
>>>>
>>>> There is no need to check for dest < 0
> cc1: warnings being treated as errors
> /home/build/gitrepo/qemu/hw/ivshmem.c: In function 'check_shm_size.
> /home/build/gitrepo/qemu/hw/ivshmem.c:357: warning: format '%ld' expects type
> 'long int', but argt 5 has type '__off64_t
> make[1]: *** [ivshmem.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make: *** [subdir-x86_64-softmmu] Error 2
Hmm, that was causing problems on 32-bit systems, not 64-bit. Is this
with gcc 4.1.2? Please the try the following patch from Avi that
should add the necessary cast.
http://www.mail-archive.com/qemu-devel@nongnu.org/msg40715.html
Cam
{
> + if (vector < s->peers[dest].nb_eventfds) {
> IVSHMEM_DPRINTF("Writing %" PRId64 " to VM %d on vector %d\n",
> write_one, dest, vector);
> if (write(s->peers[dest].eventfds[vector],
> --
> 1.7.2.2
>
>
Acked-by: Cam Macdonell
I sent a patch yesterday that addressed it, but it is probably better
to remove the tests that switched to signed 16-bit ints.
Anthony, please apply this one.
Cam
fixes gcc 4.1 warning
Signed-off-by: Cam Macdonell
---
hw/ivshmem.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index bbb5cba..fa9c684 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -181,8 +181,8 @@ static void ivshmem_io_writel(void
On Tue, Aug 24, 2010 at 8:21 PM, Isaku Yamahata wrote:
> On Tue, Aug 24, 2010 at 10:52:36AM -0600, Cam Macdonell wrote:
>> Hi, 64-bit BARs still do not seem to be working.
>>
>> When using the latest seabios the guest does not hit a "BUG:"
>> statement,
e of ivshmem is to support sharing
memory between multiple guests running on the same host. It follows
the qdev model which you will need to do.
Cam
>
> The five files I've modified from your git repository are as follows
>
> hw/pci_ids.h // Added vendor id d
On Tue, Jul 20, 2010 at 9:49 PM, Isaku Yamahata wrote:
> Added Cc: seab...@seabios.org
>
> On Wed, Jul 21, 2010 at 06:31:01AM +0300, Michael S. Tsirkin wrote:
>> On Tue, Jul 20, 2010 at 06:52:23PM +0900, Isaku Yamahata wrote:
>> > On Wed, Jul 14, 2010 at 09:10:28AM -0
)
>>>>
>>>> Paolo Bonzini (3):
>>>> move kvm_set_irqfd to kvm-stub.c
>>>
>>> This touches kvm-all.c, so should be against uq/master.
>>
>> kvm_set_irqfd is not in upstream qemu, should I add it there even though
>> it is
On Sat, Aug 14, 2010 at 11:24 AM, Andreas Färber wrote:
> Am 11.08.2010 um 20:16 schrieb Cam Macdonell:
>
>> ---
>> kvm-stub.c | 5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/kvm-stub.c b/kvm-stub.c
>> index 3378bd3..d
Signed-off-by: Cam Macdonell
---
Makefile.target |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index b791492..c8281e9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -191,7 +191,7 @@ obj-y += rtl8139.o
obj-y += e1000.o
Signed-off-by: Cam Macdonell
---
kvm-stub.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/kvm-stub.c b/kvm-stub.c
index 3378bd3..d45f9fa 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -136,3 +136,8 @@ int kvm_set_ioeventfd_pio_word(int fd, uint16_t addr,
uint16_t val
Yup, it was my patch. Sorry about that. Patches are in the list,
just need to be merged.
Cam
On Sat, Aug 14, 2010 at 4:18 PM, Stefan Weil wrote:
> Am 14.08.2010 23:35, schrieb Nigel Horne:
>>
>> I've seen some activity in this area of late, but the code still fails to
On Wed, Aug 11, 2010 at 2:28 PM, Stefan Weil wrote:
> Am 11.08.2010 20:16, schrieb Cam Macdonell:
>>
>> ---
>> kvm-stub.c | 5 +
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/kvm-stub.c b/kvm-stub.c
>> index 3378bd3..d4
---
Makefile.target |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index b791492..c8281e9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -191,7 +191,7 @@ obj-y += rtl8139.o
obj-y += e1000.o
# Inter-VM PCI shared memory
-obj-y
---
kvm-stub.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/kvm-stub.c b/kvm-stub.c
index 3378bd3..d45f9fa 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -136,3 +136,8 @@ int kvm_set_ioeventfd_pio_word(int fd, uint16_t addr,
uint16_t val, bool assign)
{
return -
On Wed, Aug 11, 2010 at 1:05 PM, Paolo Bonzini wrote:
> On 08/11/2010 03:38 AM, Stefan Weil wrote:
>>
>> kvm_set_ioeventfd_mmio_long is only available with CONFIG_KVM.
>
> We should just disable ivshmem for non-KVM
>
> diff --git a/Makefile.target b/Makefile.target
> index b791492..c8281e9 100644
On Wed, Aug 11, 2010 at 4:35 AM, Stefan Weil wrote:
> Am 27.07.2010 18:54, schrieb Cam Macdonell:
>>
>> resend for bug fix related to removal of irqfd
>>
>> Support an inter-vm shared memory device that maps a shared-memory object
>> as a
>> PCI device
server, sample programs and init scripts are in a git repo
here:
www.gitorious.org/nahanni
Signed-off-by: Cam Macdonell
---
Makefile.target |3 +
hw/ivshmem.c| 828 +++
qemu-char.c |6 +
qemu-char.h |3 +
qemu
git repo
here:
www.gitorious.org/nahanni
Signed-off-by: Cam Macdonell
---
Makefile.target |3 +
hw/ivshmem.c| 834 +++
qemu-char.c |6 +
qemu-char.h |3 +
qemu-doc.texi | 43 +++
5 files changed, 889
Signed-off-by: Cam Macdonell
---
docs/specs/ivshmem_device_spec.txt | 96
1 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 docs/specs/ivshmem_device_spec.txt
diff --git a/docs/specs/ivshmem_device_spec.txt
b/docs/specs
A non-migratable device should be removed before migration and re-added after.
Signed-off-by: Cam Macdonell
---
hw/hw.h |2 ++
savevm.c | 44 +---
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index c2de6fe
than one register per eventfd
- remove writing arbitrary values to eventfds. Only values of 1 are now
written to ensure correct usage
Cam Macdonell (5):
Provide a function to add an allocated region of memory to the qemu
RAM.
Device specification for shared memory PCI device
A
Signed-off-by: Cam Macdonell
---
kvm-all.c | 32
kvm.h |1 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 7635f2f..d9a5dd0 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1241,6 +1241,38 @@ int
Provide a function to add an allocated region of memory to the qemu RAM.
This patch is copied from Marcelo's qemu_ram_map() in qemu-kvm and given the
clearer name qemu_ram_alloc_from_ptr().
Signed-off-by: Cam Macdonell
---
cpu-common.h |2 ++
exec.c |
Yup, name is misleading. I thought it was the equivalent of
> cpu_physical_memory_map() but took a ram_addr_t instead of a target_ulong.
If I add it to my patch set, should I change the name to the suggested
qemu_ram_alloc_from_ptr() or keep it as is for consistency?
Also, the current ve
On Mon, Jul 26, 2010 at 2:11 PM, Avi Kivity wrote:
> On 07/26/2010 11:03 PM, Cam Macdonell wrote:
>>
>>> Please add qemu_ram_map() as a separate patch to avoid interdependencies.
>>> Try to keep it at the same place etc., that will reduce merge
>>> diffic
On Mon, Jul 26, 2010 at 1:51 PM, Avi Kivity wrote:
> On 07/26/2010 10:01 PM, Cam Macdonell wrote:
>>
>>> Is this against qemu.git or qemu-kvm.git? It depends on functions like
>>> qemu_ram_map() which are not present in qemu.git (and are present in
>>> qem
On Mon, Jul 26, 2010 at 7:48 AM, Anthony Liguori wrote:
> On 06/15/2010 03:23 PM, Cam Macdonell wrote:
>>
>> Latest patch for PCI shared memory device that maps a host shared memory
>> object
>> to be shared between guests
>>
>
> Is this against qemu.git or
oblem why I couldn't mount the
> v9fs?
> Thank you very much!
> BR,
> Dallas
Hi Dallas,
what does 'lspci -vv' in the guest show? Is there a device for virtio_9p?
do you have
CONFIG_NET_9P_VIRTIO=y
in your kernel's .config?
Cam
On Tue, Jul 13, 2010 at 8:52 PM, Isaku Yamahata wrote:
> On Tue, Jul 13, 2010 at 04:48:19PM -0600, Cam Macdonell wrote:
>> On Tue, Jul 13, 2010 at 2:41 PM, Isaku Yamahata
>> wrote:
>> > On Tue, Jul 13, 2010 at 02:05:51PM -0600, Cam Macdonell wrote:
>> >> &
On Tue, Jul 13, 2010 at 2:41 PM, Isaku Yamahata wrote:
> On Tue, Jul 13, 2010 at 02:05:51PM -0600, Cam Macdonell wrote:
>> >> > Seabios completely ignore the 64-bitness of the BAR. ?Looks like it also
>> >> > thinks the second half of the BAR is an I/O region
On Tue, Jun 29, 2010 at 9:29 PM, Isaku Yamahata wrote:
> On Tue, Jun 29, 2010 at 11:48:13AM -0600, Cam Macdonell wrote:
>> On Tue, Jun 29, 2010 at 12:50 AM, Avi Kivity wrote:
>> > On 06/28/2010 11:38 PM, Cam Macdonell wrote:
>> >>
>> >>>
>> &g
=,id=
The shared memory server, sample programs and init scripts are in a git repo
here:
www.gitorious.org/nahanni
Signed-off-by: Cam Macdonell
---
Makefile.target |3 +
hw/ivshmem.c| 842 +++
qemu-char.c |6 +
qemu-char.h
On Tue, Jul 6, 2010 at 8:46 AM, Juan Quintela wrote:
>
> Today was a short call as Anthony didn't attend.
>
> - Jes reminded people that Linux Plumbers deadline is July 19th
> - Qemu 0.13 (from the agenda, we didn't discuss it without Anthony).
>
> List of patches missing commit/comment/review fro
On Tue, Jun 15, 2010 at 2:23 PM, Cam Macdonell wrote:
> Latest patch for PCI shared memory device that maps a host shared memory
> object
> to be shared between guests
>
> new in this series
>
> - replace marking memory from v6 with marking device as unmigratable
> i
On Tue, Jun 29, 2010 at 12:50 AM, Avi Kivity wrote:
> On 06/28/2010 11:38 PM, Cam Macdonell wrote:
>>
>>>
>>>>> Is this really the address the guest programmed, or is qemu
>>>>> misinterpreting
>>>>> it?
>>>>>
>>&
On Sun, Jun 27, 2010 at 2:39 AM, Avi Kivity wrote:
> On 06/25/2010 12:51 AM, Cam Macdonell wrote:
>>
>> On Tue, Jun 15, 2010 at 5:04 AM, Avi Kivity wrote:
>>
>>>
>>> On 06/11/2010 08:31 PM, Cam Macdonell wrote:
>>>
>>>>
>
On Tue, Jun 15, 2010 at 5:04 AM, Avi Kivity wrote:
> On 06/11/2010 08:31 PM, Cam Macdonell wrote:
>>
>> On Mon, Apr 19, 2010 at 10:41 AM, Cam Macdonell
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> I'm trying to use a 64-bit BAR for
, sample programs and init scripts are in a git repo
here:
www.gitorious.org/nahanni
Signed-off-by: Cam Macdonell
---
Makefile.target |3 +
hw/ivshmem.c| 828 +++
qemu-char.c |6 +
qemu-char.h |3 +
qemu-doc.texi
On Wed, Jun 16, 2010 at 6:34 AM, Anthony Liguori wrote:
> On 06/16/2010 12:05 AM, Cam Macdonell wrote:
>>
>> On Tue, Jun 15, 2010 at 4:33 PM, Anthony Liguori
>> wrote:
>>
>>>
>>> On 06/15/2010 05:26 PM, Cam Macdonell wrote:
>>>
>&
On Tue, Jun 15, 2010 at 4:33 PM, Anthony Liguori wrote:
> On 06/15/2010 05:26 PM, Cam Macdonell wrote:
>>
>> On Tue, Jun 15, 2010 at 10:32 AM, Anthony Liguori
>> wrote:
>>
>>>
>>> On 06/15/2010 11:16 AM, Cam Macdonell wrote:
>>>
>
On Tue, Jun 15, 2010 at 10:32 AM, Anthony Liguori wrote:
> On 06/15/2010 11:16 AM, Cam Macdonell wrote:
>>
>> How does this look for marking the device as non-migratable? It adds a
>> field
>> 'no_migrate' to the SaveStateEntry and tests for it in vmstate_sav
Signed-off-by: Cam Macdonell
---
docs/specs/ivshmem_device_spec.txt | 96
1 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 docs/specs/ivshmem_device_spec.txt
diff --git a/docs/specs/ivshmem_device_spec.txt
b/docs/specs
repo
here:
www.gitorious.org/nahanni
Signed-off-by: Cam Macdonell
---
Makefile.target |3 +
hw/ivshmem.c| 823 +++
qemu-char.c |6 +
qemu-char.h |3 +
qemu-doc.texi | 43 +++
5 files changed, 878 insertions
1 - 100 of 190 matches
Mail list logo
