Hollis Blanchard wrote:
You lost me with this mail, but after hitting the problem myself, I
think I can summarize:
% ./configure
KVM support no
% cd kernel; make sync LINUX=/home/hollisb/source/kvm.git; cd ..
% ./configure
KVM support yes
This is building x86 kvm-userspace.git on an
Hi All,
This is our Weekly KVM Testing Report against lastest kvm.git
387f7ca1b989fbde0e43d1e6aa4cbcf52dc5b730 and kvm-userspace.git
9f149d4c381b3e77dc35b22040cc18fe484c57eb.
PAE Vista guest fail to boot against latest commit.
One New issue:
1. Vis
Anthony Liguori wrote:
Anthony Liguori wrote:
This could correspond to a:
void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t
size, int is_write);
void cpu_physical_memory_unmap(target_physical_addr_t addr,
ram_addr_t size, void *mapping, int is_dirty);
A really nice touch
Anthony Liguori wrote:
There are N users of this code, all of which would need to cope with the
failure. Or there could be one user (dma.c) which handles the failure
and the bouncing.
N should be small long term. It should only be for places that would
interact directly with CPU memory.
Dor Laor wrote:
Passera, Pablo R wrote:
Hi all,
I am trying to communicate two VMs using a virtio driver.
Once a data is moved to the driver I want to notify the other Qemu
process that there is new data available in the buffer. I was
thinking about using linux signals to synchronize
Anthony Liguori wrote:
This could correspond to a:
void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t
size, int is_write);
void cpu_physical_memory_unmap(target_physical_addr_t addr, ram_addr_t
size, void *mapping, int is_dirty);
A really nice touch here, and note this is o
Passera, Pablo R wrote:
Hi all,
I am trying to communicate two VMs using a virtio driver. Once a data
is moved to the driver I want to notify the other Qemu process that there is
new data available in the buffer. I was thinking about using linux signals to
synchronize both processes bu
Andrea Arcangeli wrote:
On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote:
Not sure why you think I'm suggesting you to use size_t. I'm just
trying to tell you that if you insist in this
64bit-guest-on-32bit-host-is-dead-and-obsolete-to-support (i.e. if you
pass a ram_addr_t siz
Avi Kivity wrote:
Anthony Liguori wrote:
- DMA into mmio regions; this requires bouncing
The map() API I proposed above should do bouncing to MMIO regions. To
deal with unbounded allocation, you can simply fail when the mapping
allocation has reached some high limit. Calling code ne
Anthony Liguori wrote:
>>
>> - DMA into mmio regions; this requires bouncing
>
> The map() API I proposed above should do bouncing to MMIO regions. To
> deal with unbounded allocation, you can simply fail when the mapping
> allocation has reached some high limit. Calling code needs to cope
> with
On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote:
> Andrea Arcangeli wrote:
>> On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote:
>>
>>> void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size,
>>> int is_write);
>>>
>>
>> Just a side note (doesn
Andrea Arcangeli wrote:
On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote:
void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size, int
is_write);
Just a side note (doesn't mean I agree with the above), it doesn't
make sense to use an ram_addr_t size when y
Avi Kivity wrote:
Anthony Liguori wrote:
I think any API based on a can_dma abstraction is wrong. The
write_post_dma thing is equally wrong.
The concept of "dma" that you're introducing is not correct.
The DMA API should have the following properties:
1) You attempt to map a physical addr
On Fri, Dec 12, 2008 at 01:15:13PM -0600, Anthony Liguori wrote:
> void *cpu_physical_memory_map(target_phys_addr_t addr, ram_addr_t size, int
> is_write);
Just a side note (doesn't mean I agree with the above), it doesn't
make sense to use an ram_addr_t size when you return a 32bit address
on 32
Anthony Liguori wrote:
I think any API based on a can_dma abstraction is wrong. The
write_post_dma thing is equally wrong.
The concept of "dma" that you're introducing is not correct.
The DMA API should have the following properties:
1) You attempt to map a physical address. This effectiv
Christian Ehrhardt wrote:
> Hollis Blanchard wrote:
>> On Thu, 2008-12-11 at 17:05 +0100, Jan Kiszka wrote:
>>
>>> Hollis Blanchard wrote:
>>>
On Thu, 2008-12-11 at 13:53 +0100, Christian Ehrhardt wrote:
> This is v2 as version one had a type in it occured when splitting
>
Christian Ehrhardt wrote:
> # HG changeset patch
> # User Christian Ehrhardt
> # Date 1229085659 -3600
> # Node ID 37967a80a2757505488685aac135681945e6da91
> # Parent f0ed33f14658fe91a14ec02501cb42d26e32f01f
> [PATCH] kvm-userspace: gdb: fix new gdb function types
>
> From: Christian Ehrhardt
>
17 matches
Mail list logo
