On Thu, May 19, 2011 at 08:00:53AM +0200, Andreas Färber wrote:
> Am 19.05.2011 um 07:39 schrieb David Gibson:
>
> >On Thu, May 19, 2011 at 07:35:30AM +0200, Andreas Färber wrote:
> >>Am 25.03.2011 um 04:21 schrieb David Gibson:
> >>
> >>>Currently the SLB information when emulating a PowerPC 970
On 2011-05-18 21:10, Anthony Liguori wrote:
> On 05/18/2011 10:30 AM, Jan Kiszka wrote:
>> On 2011-05-18 17:17, Peter Maydell wrote:
>>> On 18 May 2011 16:11, Jan Kiszka wrote:
On 2011-05-18 16:36, Avi Kivity wrote:
> There is nothing we can do with a return code. You can't fail an mmio
On Thu, May 19, 2011 at 07:35:30AM +0200, Andreas Färber wrote:
> Am 25.03.2011 um 04:21 schrieb David Gibson:
>
> >Currently the SLB information when emulating a PowerPC 970 is
> >storeed in a structure with the unhelpfully named fields 'tmp'
> >and 'tmp64'. While the layout in these fields does
On Wed, May 18, 2011 at 7:42 PM, Venkateswararao Jujjuri
wrote:
> On 05/18/2011 02:43 AM, Stefan Hajnoczi wrote:
>>
>> On Tue, May 17, 2011 at 8:43 PM, Venkateswararao Jujjuri (JV)
>> wrote:
>>>
>>> Signed-off-by: Venkateswararao Jujjuri "
>>> ---
>>> Makefile.objs | 2 +-
>>> hw/
Am 25.03.2011 um 04:21 schrieb David Gibson:
Currently the SLB information when emulating a PowerPC 970 is
storeed in a structure with the unhelpfully named fields 'tmp'
and 'tmp64'. While the layout in these fields does match the
description of the SLB in the architecture document, it is not
c
Public bug reported:
I have a Vmware image, so I have files like 'Ubuntu.vmdk', want to
convert to VirtualBox .vdi format using qemu, the first stage of
extracting the image with 'qemu-img convert Ubuntu.vmdk output.bin' just
generates a 512byte file:
{quote}
# Disk DescriptorFile
version=1
CID=3
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 26 +++---
1 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 8dd6f7d..1e860c6 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -2580,2
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/cofs.c | 21 +
hw/9pfs/virtio-9p-coth.h |2 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/hw/9pfs/cofs.c b/hw/9pfs/cofs.c
index 2a
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 198 ---
1 files changed, 63 insertions(+), 135 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 0
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/codir.c | 19 +++
hw/9pfs/virtio-9p-coth.h |1 +
hw/9pfs/virtio-9p.c | 28 ++--
3 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/hw/9pfs/codir.c b/hw/9pfs/codir.c
inde
Rearrange the code so that we can avoid V9fsRemoveState
and additional malloc()s.
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 25 ++---
hw/9pfs/virtio-9p.h |6 --
2 files changed, 10 insertions(+), 21 deletions(-)
diff --git a/hw/9pfs/virtio-9
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 88 +-
1 files changed, 30 insertions(+), 58 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 112
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 163 +--
hw/9pfs/virtio-9p.h |8 ---
2 files changed, 54 insertions(+), 117 deletions(-)
diff --git a/hw/9pfs/virtio-9p
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 53 +--
hw/9pfs/virtio-9p.h | 11 --
2 files changed, 26 insertions(+), 38 deletions(-)
diff --git a/hw/9pfs/vir
From: Aneesh Kumar K.V
This include llistxattr and lgetxattr.
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
Makefile.objs|1 +
hw/9pfs/coxattr.c| 50 ++
hw/9pfs/virtio-9p-coth.h |3 ++
3 fi
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 92 --
hw/9pfs/virtio-9p.h | 22
2 files changed, 44 insertions(+), 70 deletions(-)
diff --git a/hw/9pfs/vi
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
Makefile.objs|2 +-
hw/9pfs/cofile.c | 32
hw/9pfs/virtio-9p-coth.h |1 +
3 files changed, 34 insertions(+), 1 deletions(-)
create
Rearrange the code so that we can avoid V9fsMkState and additional malloc()s.
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 38 +-
1 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 57 +--
hw/9pfs/virtio-9p.h |8 ---
2 files changed, 19 insertions(+), 46 deletions(-)
diff --git a/hw/9pfs/virtio
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/cofs.c | 14 ++
hw/9pfs/virtio-9p-coth.h |1 +
hw/9pfs/virtio-9p.c | 11 ++-
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/hw/9pfs/cofs.c b/hw/9pfs/cofs.c
index 293e377..70d1273 100644
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 173 +--
1 files changed, 72 insertions(+), 101 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 5
From: Aneesh Kumar K.V
This include chmod, utimensat, chown and truncate.
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/cofs.c | 64 ++
hw/9pfs/virtio-9p-coth.h |4 +++
2 files changed, 68 insert
From: Aneesh Kumar K.V
This include readdir, telldir, seekdir, rewinddir.
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
Makefile.objs|2 +-
hw/9pfs/codir.c | 66 ++
hw/9pfs/virtio-9p-coth.h |
This patch is originally made by Arun Bharadwaj for glib support.
Later Harsh Prateek Bora added coroutines support.
This version implemented with suggestions from
Stefan Hajnoczi .
Signed-off-by: Arun R Bharadwaj
Signed-off-by: Harsh Prateek Bora
Signed-off-by: Venkateswararao Jujjuri "
---
Ma
Signed-off-by: Venkateswararao Jujjuri "
---
Makefile.objs|2 +-
hw/9pfs/cofs.c | 43 +++
hw/9pfs/virtio-9p-coth.h |1 +
hw/9pfs/virtio-9p.c | 27 ---
hw/9pfs/virtio-9p.h |2 +-
5 files
Rearrange the code so that we can avoid V9fsReadLinkState.
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 25 ++---
hw/9pfs/virtio-9p.h |7 ---
2 files changed, 10 insertions(+), 22 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9
This patch changes the top level handlers to coroutines and sets the base.
It will be followed up with series of patches to convert all filesystem
calls to threaded coroutines pushing all blocking clals in VirtFS out
of vcpu threads.
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p-
From: Aneesh Kumar K.V
Signed-off-by: Aneesh Kumar K.V
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/cofs.c | 14 ++
hw/9pfs/virtio-9p-coth.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/hw/9pfs/cofs.c b/hw/9pfs/cofs.c
index 3e5f4c7..b
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 52 --
1 files changed, 13 insertions(+), 39 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 3e0d933..f2794d4 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9p
Anthony's " Add hard build dependency on glib" patch and
Kevin/Stefan's coroutine effort is a prerequisite.
Changes from V2
--
o Addressed all minor review comments.
o Merged two patches to avoid confusion with readlink argument.
Changes from V1
---
o Redesigned to use bh
In the process of preparation for coroutine threads, remove all post functions
and make the function more readable.
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 29 +
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/hw/9pfs/virtio
On Wed, May 18, 2011 at 06:53:40PM +0100, stefano.stabell...@eu.citrix.com
wrote:
> From: Stefano Stabellini
>
> Match the routing informations built by seabios:
>
> - remove i440fx_write_config_xen
> we don't need to intercept pci config writes to i440FX;
>
> - introduce piix3_write_config_xe
On Wed, May 18, 2011 at 03:49:25PM -0400, Stefan Berger wrote:
> On 04/12/2011 09:32 AM, Stefan Berger wrote:
> >+
> >+static u32 add_tpm_device(void **tpm_addr, void **tcpa_addr)
> >+{
> >+struct tcpa_descriptor_rev2 *tcpa;
> >+
> >+*tpm_addr = NULL;
> >+*tcpa_addr = NULL;
> >+
> >+
On 05/18/2011 07:52 PM, stefano.stabell...@eu.citrix.com wrote:
From: Stefano Stabellini
Introduce qemu_ram_ptr_length that takes an address and a size as
parameters rather than just an address.
Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
once rather than calling q
On Sun, May 1, 2011 at 6:35 PM, Stefan Hajnoczi wrote:
> On Thu, Apr 28, 2011 at 3:11 PM, Arun Thomas wrote:
>> The multiboot info struct's 'boot_device' field has 'part1' set to 0x01,
>> which
>> maps to the second primary partition. To specify the first primary partition,
>> 'part1' should be
On 05/18/2011 03:07 PM, Jan Kiszka wrote:
On 2011-05-18 21:34, Anthony Liguori wrote:
On 05/18/2011 02:27 PM, Jan Kiszka wrote:
On 2011-05-18 21:10, Anthony Liguori wrote:
On 05/18/2011 10:30 AM, Jan Kiszka wrote:
You really don't need to register 90% of the time. In the case of a PC
with i44
On Wed, 2011-05-18 at 22:11 +0200, Jan Kiszka wrote:
> On 2011-05-18 22:02, Alex Williamson wrote:
> > On Wed, 2011-05-18 at 14:34 -0500, Anthony Liguori wrote:
> >> On 05/18/2011 02:27 PM, Jan Kiszka wrote:
> >>> On 2011-05-18 21:10, Anthony Liguori wrote:
> On 05/18/2011 10:30 AM, Jan Kiszka
On 05/18/2011 09:47 AM, Avi Kivity wrote:
> Yes. We'd change pci_register_bar() to accept a MemoryRegion.
Surely this detail would be hidden on the pci_dev->bus?
>> However, we are yet in troubles if we want to change that because
>> devices can only be on one bus - at least so far.
>
> Nothing
On 2011-05-18 22:02, Alex Williamson wrote:
> On Wed, 2011-05-18 at 14:34 -0500, Anthony Liguori wrote:
>> On 05/18/2011 02:27 PM, Jan Kiszka wrote:
>>> On 2011-05-18 21:10, Anthony Liguori wrote:
On 05/18/2011 10:30 AM, Jan Kiszka wrote:
You really don't need to register 90% of the time.
On 2011-05-18 21:34, Anthony Liguori wrote:
> On 05/18/2011 02:27 PM, Jan Kiszka wrote:
>> On 2011-05-18 21:10, Anthony Liguori wrote:
>>> On 05/18/2011 10:30 AM, Jan Kiszka wrote:
>>> You really don't need to register 90% of the time. In the case of a PC
>>> with i440fx, it's really quite simple:
On Wed, 2011-05-18 at 14:34 -0500, Anthony Liguori wrote:
> On 05/18/2011 02:27 PM, Jan Kiszka wrote:
> > On 2011-05-18 21:10, Anthony Liguori wrote:
> >> On 05/18/2011 10:30 AM, Jan Kiszka wrote:
> >> You really don't need to register 90% of the time. In the case of a PC
> >> with i440fx, it's re
On 04/12/2011 09:32 AM, Stefan Berger wrote:
+
+static u32 add_tpm_device(void **tpm_addr, void **tcpa_addr)
+{
+struct tcpa_descriptor_rev2 *tcpa;
+
+*tpm_addr = NULL;
+*tcpa_addr = NULL;
+
+if (has_working_tpm()) {
+u32 laml = 64 * 1024;
Kevin,
the above line prepare
On 2011-05-18 15:12, Avi Kivity wrote:
> void cpu_register_memory_region(MemoryRegion *mr, target_phys_addr_t addr);
OK, let's allow overlapping, but make it explicit:
void cpu_register_memory_region_overlap(MemoryRegion *mr,
target_phys_addr_t addr,
On 18.05.2011, at 21:16, Jan Kiszka wrote:
> On 2011-05-18 14:48, Alexander Graf wrote:
>> AHCI provides two ways of reading/writing data:
>>
>> 1) NCQ
>> 2) ATA commands with the LBA in the command FIS
>>
>> In the second code path, we didn't handle any LBAs that were bigger than
>> 16 bits, s
On 2011-05-18 17:37, Avi Kivity wrote:
>>> void memory_region_init_ram(MemoryRegion *mr,
>>> target_phys_addr_t size);
>>> void memory_region_init_ram_ptr(MemoryRegion *mr,
>>> target_phys_addr_t size,
>>> void *ptr);
>>> void memory_region_destroy(MemoryRegion *mr);
>>> void memory_region_set_offs
On 05/18/2011 02:27 PM, Jan Kiszka wrote:
On 2011-05-18 21:10, Anthony Liguori wrote:
On 05/18/2011 10:30 AM, Jan Kiszka wrote:
You really don't need to register 90% of the time. In the case of a PC
with i440fx, it's really quite simple:
if an I/O is to the APIC page,
it's handled by the A
On 2011-05-18 21:10, Anthony Liguori wrote:
> On 05/18/2011 10:30 AM, Jan Kiszka wrote:
>> On 2011-05-18 17:17, Peter Maydell wrote:
>>> On 18 May 2011 16:11, Jan Kiszka wrote:
On 2011-05-18 16:36, Avi Kivity wrote:
> There is nothing we can do with a return code. You can't fail an mmio
On 2011-05-18 14:48, Alexander Graf wrote:
> AHCI provides two ways of reading/writing data:
>
> 1) NCQ
> 2) ATA commands with the LBA in the command FIS
>
> In the second code path, we didn't handle any LBAs that were bigger than
> 16 bits, so whenever a guest that used high LBA numbers wanted
On 2011-05-18 20:58, Stefan Weil wrote:
> Am 18.05.2011 20:02, schrieb Jan Kiszka:
>> On 2011-05-18 19:40, Stefan Weil wrote:
>>> The current implementation used stubs for systems without XEN.
>>> This is unusual for QEMU and adds unneeded dependencies.
>>>
>>> MinGW32 for example does not provide
On 05/18/2011 10:30 AM, Jan Kiszka wrote:
On 2011-05-18 17:17, Peter Maydell wrote:
On 18 May 2011 16:11, Jan Kiszka wrote:
On 2011-05-18 16:36, Avi Kivity wrote:
There is nothing we can do with a return code. You can't fail an mmio
that causes overlapping physical memory map.
We must fail
Am 18.05.2011 20:02, schrieb Jan Kiszka:
On 2011-05-18 19:40, Stefan Weil wrote:
The current implementation used stubs for systems without XEN.
This is unusual for QEMU and adds unneeded dependencies.
MinGW32 for example does not provide munmap(), so the XEN
code creates compiler warnings (miss
On 05/18/2011 03:39 AM, Stefan Hajnoczi wrote:
On Tue, May 17, 2011 at 8:43 PM, Venkateswararao Jujjuri (JV)
wrote:
I sent comments on individual patches. This is turning out nice, many
of the PDU handlers are now straight-line code that can be followed
easily.
Thanks. Yeah it is coming out
On 05/18/2011 02:43 AM, Stefan Hajnoczi wrote:
On Tue, May 17, 2011 at 8:43 PM, Venkateswararao Jujjuri (JV)
wrote:
Signed-off-by: Venkateswararao Jujjuri "
---
Makefile.objs|2 +-
hw/9pfs/cofs.c | 42 ++
hw/9pfs/virtio-9p
On 05/18/2011 02:31 AM, Stefan Hajnoczi wrote:
On Tue, May 17, 2011 at 8:43 PM, Venkateswararao Jujjuri (JV)
wrote:
Signed-off-by: Venkateswararao Jujjuri "
---
hw/9pfs/virtio-9p.c | 32
1 files changed, 16 insertions(+), 16 deletions(-)
Please see my com
On Wed, 18 May 2011, Stefan Weil wrote:
> The current implementation used stubs for systems without XEN.
> This is unusual for QEMU and adds unneeded dependencies.
>
> MinGW32 for example does not provide munmap(), so the XEN
> code creates compiler warnings (missing prototype).
> Compilations wit
On 2011-05-18 17:13, Alon Levy wrote:
> Hi,
>
> Anyone interested? Anyone submitted such a request already? I'm mainly
> interested in remoting 3d with spice, and I know there is existing
> out-of-tree patches for passthrough (not to mention other implementations out
> there). I guess the idea
Stefan,
I was getting only the problem with audio(only Warning and error log)
when I checking the logs
{snip}
LC_ALL=C
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/root USER=root LOGNAME=root TMPDIR=/tmp/root-tmp.2af1b17/files
/usr/bin/kvm -S -M pc -m 512 -smp 4 -nam
On 2011-05-18 19:40, Stefan Weil wrote:
> The current implementation used stubs for systems without XEN.
> This is unusual for QEMU and adds unneeded dependencies.
>
> MinGW32 for example does not provide munmap(), so the XEN
> code creates compiler warnings (missing prototype).
> Compilations wit
From: Stefano Stabellini
Use qemu_invalidate_entry in cpu_physical_memory_unmap.
Do not lock mapcache entries in qemu_get_ram_ptr if the address falls in
the ramblock with offset == 0. We don't need to do that because the
callers of qemu_get_ram_ptr either try to map an entire block, other
from
From: Stefano Stabellini
Match the routing informations built by seabios:
- remove i440fx_write_config_xen
we don't need to intercept pci config writes to i440FX;
- introduce piix3_write_config_xen
we do need to intercept pci config write to the PCI-ISA bridge to update
the PCI link routing;
-
From: Stefano Stabellini
Introduce qemu_ram_ptr_length that takes an address and a size as
parameters rather than just an address.
Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
once rather than calling qemu_get_ram_ptr one time per page.
This is not only more efficien
From: Stefano Stabellini
Replace xen_map_block with qemu_map_cache with the appropriate locking
and size parameters.
Replace xen_unmap_block with qemu_invalidate_entry.
Signed-off-by: Stefano Stabellini
---
exec.c | 18 +++---
xen-mapcache-stub.c |4
xen-map
From: Stefano Stabellini
Fix the implementation of qemu_map_cache: correctly support size
arguments different from 0 or MCACHE_BUCKET_SIZE.
The new implementation supports locked mapcache entries with size
multiple of MCACHE_BUCKET_SIZE. qemu_invalidate_entry can correctly
find and unmap these "l
From: Stefano Stabellini
There is no need for qemu_map_cache_unlock, just use
qemu_invalidate_entry instead.
Signed-off-by: Stefano Stabellini
---
exec.c |2 +-
xen-mapcache-stub.c |4
xen-mapcache.c | 33 -
xen-mapcache.h |
Hi all,
this patch series introduces a series of fixes and improvements to the
xen mapcache in qemu.
The list of patches with a diffstat follows:
Stefano Stabellini (5):
xen: fix qemu_map_cache with size != MCACHE_BUCKET_SIZE
xen: remove qemu_map_cache_unlock
xen: remove xen_map_
On Wed, 18 May 2011 11:33:20 -0500
Michael Roth wrote:
> On 05/18/2011 10:10 AM, Luiz Capitulino wrote:
> > On Wed, 18 May 2011 09:43:37 -0500
> > Michael Roth wrote:
> >
> >> On 05/18/2011 08:46 AM, Luiz Capitulino wrote:
> >>> On Tue, 17 May 2011 19:51:47 -0500
> >>> Michael Roth wrote:
> >>
On 18 May 2011 11:00, Alex Zuepke wrote:
> Peter Maydell schrieb:
>> On 25 March 2011 10:54, Alex Zuepke wrote:
>>> while digging through some problems with BKPT exceptions on ARM, I
>>> discovered that QEMU does not update IFSR on prefetch aborts. This
>>> should be done since ARMv6 according to
The current implementation used stubs for systems without XEN.
This is unusual for QEMU and adds unneeded dependencies.
MinGW32 for example does not provide munmap(), so the XEN
code creates compiler warnings (missing prototype).
Compilations without optimisation even result in linker
errors (miss
On 2011-05-18 19:15, Avi Kivity wrote:
> On 05/18/2011 08:07 PM, Jan Kiszka wrote:
>> On 2011-05-18 18:47, Avi Kivity wrote:
>> I'm specifically thinking of fully trackable slot updates. The clients
>> should not have to maintain the flat layout. They should just receive
>> update
On 2011-05-18 19:11, Anthony Liguori wrote:
> On 05/18/2011 11:49 AM, Avi Kivity wrote:
>> On 05/18/2011 07:42 PM, Jan Kiszka wrote:
>>> On 2011-05-18 18:21, Avi Kivity wrote:
On 05/18/2011 06:26 PM, Avi Kivity wrote:
>> This is about registration. Right now you can only register IO
>>
Copying kvm@.
On 05/18/2011 04:12 PM, Avi Kivity wrote:
The current memory APIs (cpu_register_io_memory,
cpu_register_physical_memory) suffer from a number of drawbacks:
- lack of centralized bookkeeping
- a cpu_register_physical_memory() that overlaps an existing region
will overwrite the
On 05/18/2011 08:07 PM, Jan Kiszka wrote:
On 2011-05-18 18:47, Avi Kivity wrote:
I'm specifically thinking of fully trackable slot updates. The clients
should not have to maintain the flat layout. They should just receive
updates in the form of slot X added/modified/removed.
On 05/18/2011 08:04 PM, Anthony Liguori wrote:
The TLBs map a virtual address to a ram_addr_t.
It actually maps virtual address to host virtual addresses. Virtual
addresses that map to I/O memory never get stored in the TLB.
They are stored. Look at glue(io_read, SUFFIX) and its caller fo
On 05/18/2011 11:49 AM, Avi Kivity wrote:
On 05/18/2011 07:42 PM, Jan Kiszka wrote:
On 2011-05-18 18:21, Avi Kivity wrote:
> On 05/18/2011 06:26 PM, Avi Kivity wrote:
>>> This is about registration. Right now you can only register IO
>>> intercepts in the chipset, not on a per-CPU basis. We coul
On 2011-05-18 18:47, Avi Kivity wrote:
I'm specifically thinking of fully trackable slot updates. The clients
should not have to maintain the flat layout. They should just receive
updates in the form of slot X added/modified/removed. For now, this
magic happens multiple time
On 05/18/2011 07:42 PM, Jan Kiszka wrote:
>
> You cannot do this properly with a single dispatch table because the
> behavior depends on where in the hierarchy the I/O is being handled.
Ah, now I remember why I did not follow that path: Not invasiveness, but
performance concerns. I assume TLB
On 05/18/2011 11:41 AM, Avi Kivity wrote:
On 05/18/2011 07:33 PM, Anthony Liguori wrote:
On 05/18/2011 10:23 AM, Avi Kivity wrote:
The tricky part is wiring this up efficiently for TCG, ie. in QEMU's
softmmu. I played with passing the issuing CPUState (or NULL for
devices) down the MMIO handler
On 05/18/2011 09:53 AM, Avi Kivity wrote:
> I plan to centralize this logic in the memory API. You'll just declare how
> your device behaves.
Excellent. Those were my only two concerns then.
r~
On Wed, May 18, 2011 at 5:18 PM, wrote:
> Hello Stefan,
>
>
>
> Thank you very much for considering my issue...
>
>
>
> Here is My problem...
>
>
>
> 1) I have 4 VM`s Running on Base server.
>
> 2) Base server is having 15GB RAM.
>
> 3) I can start all VM`s apart from my file server.
>
> 4) File
On 05/18/2011 07:51 PM, Richard Henderson wrote:
>
> I prefer having size as an argument.
The one thing that makes having these function pointers split apart nice
is that it makes it easy to set policy for what different sized reads do.
E.g. for devices for which only 4 byte reads are defined,
On 05/18/2011 09:06 AM, Avi Kivity wrote:
>> If we keep per-access type function pointers, they should use individual
>> prototypes
>> for the different access types:
>>
>> typedef uint8_t (*MemoryReadbFunc)(MemoryRegion *mr, target_phys_addr_t
>> addr);
>> typedef uint16_t (*MemoryReadwFunc)(Me
On 05/18/2011 07:42 PM, Jan Kiszka wrote:
On 2011-05-18 18:21, Avi Kivity wrote:
> On 05/18/2011 06:26 PM, Avi Kivity wrote:
>>> This is about registration. Right now you can only register IO
>>> intercepts in the chipset, not on a per-CPU basis. We could just as
>>> easily have:
>>>
>>> C
On 05/18/2011 07:39 PM, Jan Kiszka wrote:
>>
>> That's fine, but also requires a change how, or better where devices
>> register their regions.
>
> Lost you - please elaborate.
Devices currently register against the core, that's nothing your API
automatically changes (though it lays the found
On 2011-05-18 18:21, Avi Kivity wrote:
> On 05/18/2011 06:26 PM, Avi Kivity wrote:
>>> This is about registration. Right now you can only register IO
>>> intercepts in the chipset, not on a per-CPU basis. We could just as
>>> easily have:
>>>
>>> CPUState {
>>> MemoryRegion apic_region;
>>>
On 2011-05-18 18:33, Anthony Liguori wrote:
> On 05/18/2011 10:23 AM, Avi Kivity wrote:
>>> The tricky part is wiring this up efficiently for TCG, ie. in QEMU's
>>> softmmu. I played with passing the issuing CPUState (or NULL for
>>> devices) down the MMIO handler chain. Not totally beautiful as
>>
On 05/18/2011 07:33 PM, Anthony Liguori wrote:
On 05/18/2011 10:23 AM, Avi Kivity wrote:
The tricky part is wiring this up efficiently for TCG, ie. in QEMU's
softmmu. I played with passing the issuing CPUState (or NULL for
devices) down the MMIO handler chain. Not totally beautiful as
decentrali
On 2011-05-18 18:14, Avi Kivity wrote:
> On 05/18/2011 07:00 PM, Jan Kiszka wrote:
>> On 2011-05-18 17:42, Avi Kivity wrote:
>>> On 05/18/2011 06:36 PM, Jan Kiszka wrote:
>
> We need to head for the more hardware-like approach. What happens when
> you program overlapping BARs? I
On 05/18/2011 07:26 PM, Richard Henderson wrote:
On 05/18/2011 06:12 AM, Avi Kivity wrote:
> struct MemoryRegionOps {
> MemoryReadFunc readb, readw, readl;
> MemoryWriteFunc writeb, writew, writel;
> };
Look back to last May for a discussion between myself and Paul Brook
on this subj
On 05/18/2011 10:10 AM, Luiz Capitulino wrote:
On Wed, 18 May 2011 09:43:37 -0500
Michael Roth wrote:
On 05/18/2011 08:46 AM, Luiz Capitulino wrote:
On Tue, 17 May 2011 19:51:47 -0500
Michael Roth wrote:
These apply on top of master, and can also be obtained from:
git://repo.or.cz/qemu/md
On 05/18/2011 10:23 AM, Avi Kivity wrote:
The tricky part is wiring this up efficiently for TCG, ie. in QEMU's
softmmu. I played with passing the issuing CPUState (or NULL for
devices) down the MMIO handler chain. Not totally beautiful as
decentralized dispatching was still required, but at least
ide-hd has to suppress the default CD-ROM, or else you can't put one
on secondary master without -nodefaults.
Unlike legacy scsi-disk, scsi-cd suppresses default CD-ROM.
Signed-off-by: Markus Armbruster
---
vl.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/vl.c b/v
Kevin Wolf writes:
> Am 16.05.2011 15:04, schrieb Markus Armbruster:
>> ide-hd does *not* suppress the default CD-ROM, unlike legacy
>> ide-drive.
>>
>> scsi-cd *does* suppress it, unlike legacy scsi-disk.
>>
>> Signed-off-by: Markus Armbruster
>> ---
>> vl.c |2 ++
>> 1 files changed, 2
On 05/18/2011 06:12 AM, Avi Kivity wrote:
> struct MemoryRegionOps {
> MemoryReadFunc readb, readw, readl;
> MemoryWriteFunc writeb, writew, writel;
> };
Look back to last May for a discussion between myself and Paul Brook
on this subject. That started with me merely wanting to expand the
On 05/18/2011 06:26 PM, Avi Kivity wrote:
This is about registration. Right now you can only register IO
intercepts in the chipset, not on a per-CPU basis. We could just as
easily have:
CPUState {
MemoryRegion apic_region;
};
per_cpu_register_memory(env, &env->apic_region);
Right.
On 18.05.2011, at 17:13, Alon Levy wrote:
> Hi,
>
> Anyone interested? Anyone submitted such a request already? I'm mainly
> interested in remoting 3d with spice, and I know there is existing
> out-of-tree patches for passthrough (not to mention other implementations out
> there). I guess the
On 05/18/2011 07:00 PM, Jan Kiszka wrote:
On 2011-05-18 17:42, Avi Kivity wrote:
> On 05/18/2011 06:36 PM, Jan Kiszka wrote:
>>>
>>> We need to head for the more hardware-like approach. What happens when
>>> you program overlapping BARs? I imagine the result is
>>> implementation-defined
On 05/17/2011 11:46 AM, Aurelien Jarno wrote:
>> -tcg_set_frame(s, TCG_AREG0, offsetof(CPUState, temp_buf),
>> - CPU_TEMP_BUF_NLONGS * sizeof(long));
>> }
>
> Note that this patch is likely to break calls to helpers which need
> parameters on the stack, by judging at the curr
On 05/18/2011 06:47 PM, Stefan Weil wrote:
I'm not a fan of having per-access type function pointers.
Do you think of something like these declaration:
typedef uint64_t (*MemoryReadFunc)(MemoryRegion *mr,
target_phys_addr_t addr, size_t size);
typedef void (*MemoryWriteFunc)(MemoryRegion *mr
On 2011-05-18 17:42, Avi Kivity wrote:
> On 05/18/2011 06:36 PM, Jan Kiszka wrote:
>>>
>>> We need to head for the more hardware-like approach. What happens when
>>> you program overlapping BARs? I imagine the result is
>>> implementation-defined, but ends up with one region decoded in
>>> pr
On 05/18/2011 04:12 PM, Avi Kivity wrote:
void cpu_register_memory_region(MemoryRegion *mr, target_phys_addr_t
addr);
void cpu_unregister_memory_region(MemoryRegion *mr);
These two can probably implemented as:
extern MemoryRegion memory_map;
void cpu_register_memory_region(MemoryRe
1 - 100 of 192 matches
Mail list logo
