Ignore any regions not belonging to a specified address space.
Signed-off-by: Avi Kivity
---
exec.c |2 +-
hw/vhost.c |2 +-
kvm-all.c |2 +-
memory.c | 45 +++--
memory.h |4 +++-
xen-all.c |2 +-
6 files changed, 46
If the first subpage installed in a page is RAM, then we install it as
a full page, instead of a subpage. Fix by not special casing RAM.
The issue dates to commit db7b5426a4b4242, which introduced subpages.
Signed-off-by: Avi Kivity
---
exec.c | 22 ++
1 files changed
On 02/07/2012 04:39 PM, Alexander Graf wrote:
> >
> > Syscalls are orthogonal to that - they're to avoid the fget_light() and to
> > tighten the vcpu/thread and vm/process relationship.
>
> How about keeping the ioctl interface but moving vcpu_run to a syscall then?
I dislike half-and-half inter
On 02/15/2012 01:57 PM, Alexander Graf wrote:
> >
> > Is an extra syscall for copying TLB entries to user space prohibitively
> > expensive?
>
> The copying can be very expensive, yes. We want to have the possibility of
> exposing a very large TLB to the guest, in the order of multiple kentries.
On 02/12/2012 09:10 AM, Takuya Yoshikawa wrote:
> Avi Kivity wrote:
>
> > > > Slot searching is quite fast since there's a small number of slots,
> > > > and we sort the larger ones to be in the front, so positive lookups are
> > > > fast. We c
On 02/07/2012 05:23 PM, Anthony Liguori wrote:
> On 02/07/2012 07:40 AM, Alexander Graf wrote:
>>
>> Why? For the HPET timer register for example, we could have a simple
>> MMIO hook that says
>>
>>on_read:
>> return read_current_time() - shared_page.offset;
>>on_write:
>> handle_
On 02/07/2012 08:12 PM, Rusty Russell wrote:
> > I would really love to have this, but the problem is that we'd need a
> > general purpose bytecode VM with binding to some kernel APIs. The
> > bytecode VM, if made general enough to host more complicated devices,
> > would likely be much larger tha
On 02/07/2012 06:29 PM, Jan Kiszka wrote:
> >>>
> >>
> >> Isn't there another level in between just scheduling and full syscall
> >> return if the user return notifier has some real work to do?
> >
> > Depends on whether you're scheduling a kthread or a userspace process, no?
> > If
>
> Kthread
On 02/07/2012 06:19 PM, Anthony Liguori wrote:
>> Ah. But then ioeventfd has that as well, unless the other end is in
>> the kernel too.
>
>
> Yes, that was my point exactly :-)
>
> ioeventfd/mmio-over-socketpair to adifferent thread is not faster than
> a synchronous KVM_RUN + writing to an eventf
On 02/15/2012 03:37 PM, Alexander Graf wrote:
> On 15.02.2012, at 14:29, Avi Kivity wrote:
>
> > On 02/15/2012 01:57 PM, Alexander Graf wrote:
> >>>
> >>> Is an extra syscall for copying TLB entries to user space prohibitively
> >>> expensive?
>
On 02/16/2012 12:21 AM, Arnd Bergmann wrote:
> ioctl is good for hardware devices and stuff that you want to enumerate
> and/or control permissions on. For something like KVM that is really a
> core kernel service, a syscall makes much more sense.
>
> I would certainly never mix the two concepts: I
On 02/14/2012 05:13 PM, Jan Kiszka wrote:
> Note that KVM without in-kernel irqchip will report the address after
> the instruction that triggered a write access. In contrast, read
> accesses will return the precise information.
>
Well this is wierd. We could retro-doc one or the other behaviour,
On 02/14/2012 05:13 PM, Jan Kiszka wrote:
> This enables acceleration for MMIO-based TPR registers accesses of
> 32-bit Windows guest systems. It is mostly useful with KVM enabled,
> either on older Intel CPUs (without flexpriority feature, can also be
> manually disabled for testing) or any curren
kvm-unit-tests.git x86/apic.flat is failing ioapic tests with
qemu-system-x86_64 -vnc :99 -device testdev,chardev=x -chardev null,id=x
-smp 2 -kernel ./x86/apic.flat -serial stdio
...
ioapic interrupt: FAIL
ioapic simultaneous interrupt: FAIL
This happens because the test is invoking gsi 16, whi
On 02/15/2012 04:08 PM, Alexander Graf wrote:
> >
> > Well, the scatter/gather registers I proposed will give you just one
> > register or all of them.
>
> One register is hardly any use. We either need all ways of a respective
> address to do a full fledged lookup or all of them.
I should have
On 02/16/2012 03:04 AM, Michael Ellerman wrote:
> >
> > ioctl is good for hardware devices and stuff that you want to enumerate
> > and/or control permissions on. For something like KVM that is really a
> > core kernel service, a syscall makes much more sense.
>
> Yeah maybe. That distinction is a
On 02/16/2012 04:46 PM, Anthony Liguori wrote:
>> What will it buy us? Surely not speed. Entering a guest is not much
>> (if at all) faster than exiting to userspace and any non trivial
>> operation will require exit to userspace anyway,
>
>
> You can emulate the PIT/RTC entirely within the guest u
On 02/16/2012 09:34 PM, Alexander Graf wrote:
> On 16.02.2012, at 20:24, Avi Kivity wrote:
>
> > On 02/15/2012 04:08 PM, Alexander Graf wrote:
> >>>
> >>> Well, the scatter/gather registers I proposed will give you just one
> >>> register or all of
On 10/11/2012 05:38 AM, liu ping fan wrote:
>>
>> +void address_space_init_dispatch(AddressSpace *as)
>> +{
>> +AddressSpaceDispatch *d = g_new(AddressSpaceDispatch, 1);
>> +
>> +d->phys_map = (PhysPageEntry) { .ptr = PHYS_MAP_NODE_NIL, .is_leaf = 0
>> };
>> +d->listener = (MemoryList
On 10/11/2012 05:38 AM, liu ping fan wrote:
> On Wed, Oct 10, 2012 at 12:32 AM, Avi Kivity wrote:
>> Currently we ignore PCI_COMMAND_MASTER completely: DMA succeeds even when
>> the bit is clear.
>>
>> Honor PCI_COMMAND_MASTER by inserting a memory region into the dev
On 10/11/2012 10:45 AM, liu ping fan wrote:
> On Thu, Oct 11, 2012 at 4:31 PM, Avi Kivity wrote:
>> On 10/11/2012 05:38 AM, liu ping fan wrote:
>>>>
>>>> +void address_space_init_dispatch(AddressSpace *as)
>>>> +{
>>>> +
On 10/11/2012 10:49 AM, liu ping fan wrote:
> On Thu, Oct 11, 2012 at 4:34 PM, Avi Kivity wrote:
>> On 10/11/2012 05:38 AM, liu ping fan wrote:
>>> On Wed, Oct 10, 2012 at 12:32 AM, Avi Kivity wrote:
>>>> Currently we ignore PCI_COMMAND_MASTER completely: DMA succ
These patches add IOMMU support to the memory core. IOMMUs can be added
anywhere in
the memory hierarchy, and may be arranged in series.
Avi Kivity (7):
memory: fix address space initialization/destruction
memory: limit sections in the radix tree to the actual address space
size
memory
eliminated by the memory core, leaving only device regions
which have reasonable sizes. An IOMMU however cannot be eliminated by the
memory core, and may have an artificial size.
Signed-off-by: Avi Kivity
---
exec.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a
different iommu region for every device.
Signed-off-by: Avi Kivity
---
hw/pci.c | 59 +-
hw/pci.h | 7 +--
hw/pci_internals.h | 5 +++--
hw/spapr.h | 2 ++
hw/spapr_iommu.c | 35
This iommu encrypts addresses on the device bus to avoid divuling information
to hackers equipped with bus analyzers. Following 3DES, addresses are encrypted
multiple times. A XOR cypher is employed for efficiency.
Signed-off-by: Avi Kivity
---
hw/piix_pci.c | 74
On 10/11/2012 03:31 PM, Paolo Bonzini wrote:
> Il 11/10/2012 15:26, Avi Kivity ha scritto:
>> A couple of fields were left uninitialized. This was not observed earlier
>> because all address spaces were statically allocated. Also free allocation
>> for those fields.
>
On 10/11/2012 03:31 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 11, 2012 at 03:27:03PM +0200, Avi Kivity wrote:
>> vhost doesn't support guest iommus yet, indicate it to the user
>> by gently depositing a core on their disk.
>>
>> Signed-off-by: Avi Kivity
&
A couple of fields were left uninitialized. This was not observed earlier
because all address spaces were statically allocated. Also free allocation
for those fields.
Signed-off-by: Avi Kivity
---
memory.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/memory.c b/memory.c
index
On 10/11/2012 03:44 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 11, 2012 at 03:34:54PM +0200, Avi Kivity wrote:
>> On 10/11/2012 03:31 PM, Michael S. Tsirkin wrote:
>> > On Thu, Oct 11, 2012 at 03:27:03PM +0200, Avi Kivity wrote:
>> >> vhost doesn't support g
On 10/11/2012 03:42 PM, Paolo Bonzini wrote:
> Il 11/10/2012 15:26, Avi Kivity ha scritto:
>> +struct MemoryRegionIOMMUOps {
>> +/* Returns a TLB entry that contains a given address. */
>> +IOMMUTLBEntry (*translate)(MemoryRegion *iommu, ta
vhost doesn't support guest iommus yet, indicate it to the user
by gently depositing a core on their disk.
Signed-off-by: Avi Kivity
---
hw/vhost.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/vhost.c b/hw/vhost.c
index 0b4ac3f..cd5d9f5 100644
--- a/hw/vhost.c
+++ b/hw/vh
implementation uses an AddressSpace mapping the target region to
avoid hierarchical dispatch all the way to the resolved region; only
iommu regions are looked up dynamically.
Signed-off-by: Avi Kivity
---
exec.c | 28 ++---
memory.c | 107
On 10/11/2012 03:53 PM, Paolo Bonzini wrote:
> Il 11/10/2012 15:27, Avi Kivity ha scritto:
>> -static int spapr_tce_translate(DMAContext *dma,
>> - dma_addr_t addr,
>> - targ
On 10/11/2012 03:54 PM, Paolo Bonzini wrote:
> Il 11/10/2012 15:45, Avi Kivity ha scritto:
>>>> >> +struct MemoryRegionIOMMUOps {
>>>> >> +/* Returns a TLB entry that contains a given address. */
>>>> >> +IOMMUTLBEntry (*transla
vfio doesn't support guest iommus yet, indicate it to the user
by gently depositing a core on their disk.
Signed-off-by: Avi Kivity
---
hw/vfio_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
index e9399a1..f935d00 100644
--- a/hw/vfio_pci.c
+++
On 10/11/2012 04:35 PM, Michael S. Tsirkin wrote:
>> No, qemu should configure virtio devices to bypass the iommu, even if it
>> is on.
>
> Okay so there will be some API that virtio devices should call
> to achieve this?
The iommu should probably call pci_device_bypasses_iommu() to check for
su
On 10/11/2012 03:26 PM, Avi Kivity wrote:
> Add a new memory region type that translates addresses it is given,
> then forwards them to a target address space. This is similar to
> an alias, except that the mapping is more flexible than a linear
> translation and trucation, a
On 10/11/2012 05:34 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 11, 2012 at 04:35:23PM +0200, Avi Kivity wrote:
>> On 10/11/2012 04:35 PM, Michael S. Tsirkin wrote:
>>
>> >> No, qemu should configure virtio devices to bypass the iommu, even if it
>> >> is on
On 10/11/2012 09:38 PM, Alex Williamson wrote:
> On Thu, 2012-10-11 at 17:48 +0200, Avi Kivity wrote:
>> On 10/11/2012 05:34 PM, Michael S. Tsirkin wrote:
>> > On Thu, Oct 11, 2012 at 04:35:23PM +0200, Avi Kivity wrote:
>> >> On 10/11/2012 04:35 PM, Michael S. Tsi
On 10/13/2012 11:13 AM, Blue Swirl wrote:
>> struct PCIBus {
>> BusState qbus;
>> -PCIDMAContextFunc dma_context_fn;
>> -void *dma_context_opaque;
>> +PCIIOMMUFunc iommu_fn;
>> +PCIIOMMUDestructorFunc iommu_dtor_fn;
>> +void *iommu_opaque;
>
> Maybe the opaque could be av
On 10/15/2012 10:44 AM, liu ping fan wrote:
> On Thu, Oct 11, 2012 at 11:48 PM, Avi Kivity wrote:
>> On 10/11/2012 05:34 PM, Michael S. Tsirkin wrote:
>>> On Thu, Oct 11, 2012 at 04:35:23PM +0200, Avi Kivity wrote:
>>>> On 10/11/2012 04:35 PM, Michael S. Tsirki
On 10/12/2012 04:36 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-10-11 at 15:26 +0200, Avi Kivity wrote:
>> These patches add IOMMU support to the memory core. IOMMUs can be added
>> anywhere in
>> the memory hierarchy, and may be arranged in series.
>
> I haven&
On 10/11/2012 11:01 PM, Anthony Liguori wrote:
> This conflicts with a recent pull from Stefano in xen-all.c. The
> difference doesn't look that awful but since I don't have a xen test
> setup, I'm not confident in resolving it myself.
>
> Can you rebase and fixup?
>
Rebased tree in the same pl
On 10/12/2012 04:51 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-10-11 at 15:57 +0200, Avi Kivity wrote:
>> >> Map/unmap is supported via address_space_map(), which calls
>> >> ->translate(). I don't see how a lower-level map/unmap helps,
>> unless
&g
On 10/16/2012 08:53 AM, Hu, Xuekun wrote:
> Setting the same PLE parameter arbitrarily for different
> workloads is not a good solution.
True.
> The solution enables
> per domain PLE which gives user ability to set PLE parameter
> for different domain for better performance.
The problem with th
On 10/15/2012 09:52 PM, Benjamin Herrenschmidt wrote:
>>
>> I do have an is_write parameter to translate, in fact I added it in
>> order to implement the spapr iommu. Or do you mean something else?
>
> Hrm, sort of. "is_write" means you can only express RO vs RW. Two
> parameter for read and wri
On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
>>
>> I don't think so, but probably there's a limit of DIMMs that real
>> controllers have, something like 8 max.
>
> In the case of i440fx specifically, do you mean that we should model the DRB
> (Dram row boundary registers in section 3.2.19 o
On 10/17/2012 10:02 AM, Hu, Xuekun wrote:
>>
>> The problem with this is that it requires an administrator to understand the
>> workload, not only of the guest, but also of other guests on the machine.
>> With low overcommit, a high PLE window reduces unneeded exits, but with
>> high overcommit we
On 10/17/2012 03:09 AM, Richard Henderson wrote:
> On 2012-10-17 09:25, Aurelien Jarno wrote:
>>> > +gen_opc_buf[op_index] = op = INDEX_op_mul_i32;
>> Very minor nitpick: you probably don't need to set op there.
>>
>
> Perhaps not, but I prefer to keep the variables in sync as we
On 10/15/2012 08:30 PM, Alexander Graf wrote:
> Our memory API MMIO regions know the concept of device endianness. This
> is used to automatically swap endianness between devices and host CPU,
> depending on whether buses in between would swizzle the bits.
>
> The ioeventfd value comparison does n
memory_region_destroy() in a transaction is illegal, for reasons which are best
disclosed
in the actual patches. This patchset fixes one violation and adds prevention
for the
next.
Avi Kivity (2):
i440fx: avoid destroying memory regions within a transaction
memory: abort if a memory region
Destroying a memory region is illegal within a transaction, as until
the transaction is committed, the memory core may hold references to
the region. Add an assert to check for violations of this rule.
Signed-off-by: Avi Kivity
---
memory.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
tends to throw anyway), and since we don't do concurrent dispatch yet,
but instead of relying on that, tighten ship ahead of the coming concurrency
storm.
Fix by having a predefined set of regions, of which one will be enabled at
any time.
Signed-off-by: Avi Kivity
---
hw/piix_pci.c
On 10/17/2012 06:00 PM, Benoît Canet wrote:
> This patchset is a not yet working draft starting to implement deduplication
> in QCOW2.
>
> The Kernel red black trees are indented in kernel style.
> I'll be happy to know what is the policy regarding this kind of inclusion
> and what tools can be us
On 10/18/2012 11:27 AM, Vasilis Liaskovitis wrote:
> On Wed, Oct 17, 2012 at 12:03:51PM +0200, Avi Kivity wrote:
>> On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
>> >>
>> >> I don't think so, but probably there's a limit of DIMMs that real
&
On 10/17/2012 08:31 PM, Dmitry Fleytman wrote:
> E1000State::check_rxov field must be preserved on live migration.
It looks like its value is usually 1. Is this true?
If so, we can use subsections to only migrate it if it is zero. This
allows migration to keep working from a new version to an o
On 10/15/2012 03:16 PM, Avi Kivity wrote:
> On 10/11/2012 11:01 PM, Anthony Liguori wrote:
>> This conflicts with a recent pull from Stefano in xen-all.c. The
>> difference doesn't look that awful but since I don't have a xen test
>> setup, I'm not confident in
On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
> This pair of interface help to decide when dispatching, whether
> we can pin mr without big lock or not.
>
> Signed-off-by: Liu Ping Fan
> ---
> memory.h |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/memory.h b/memo
).
Alexander Graf (1):
memory: Make eventfd adhere to device endianness
Avi Kivity (2):
i440fx: avoid destroying memory regions within a transaction
memory: abort if a memory region is destroyed during a transaction
hw/piix_pci.c | 69
On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
> Rejecting the nested mmio request which does not aim at RAM, so we
> can avoid the potential deadlock caused by the random lock sequence
> of two device's local lock.
I can't say I like this but it's better than anything else we have.
> }
>
> +int
On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
> This can help memory core to use mr's fine lock to mmio dispatch.
>
> diff --git a/memory.c b/memory.c
> index d528d1f..86d5623 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -1505,13 +1505,27 @@ void set_system_io_map(MemoryRegion *mr)
>
> uint64_t
On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
> Signed-off-by: Liu Ping Fan
> ---
> kvm-all.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/kvm-all.c b/kvm-all.c
> index b3fa597..3d7ae18 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1562,12 +1562,15 @@ int kvm_
On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
> Use local lock to protect e1000. When calling the system function,
> dropping the fine lock before acquiring the big lock. This will
> introduce broken device state, which need extra effort to fix.
>
> Signed-off-by: Liu Ping Fan
> ---
> hw/e1000.c |
On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
> The broken device state is caused by releasing local lock before acquiring
> big lock. To fix this issue, we have two choice:
> 1.use busy flag to protect the state
> The drawback is that we will introduce independent busy flag for each
> inde
On 10/19/2012 07:48 PM, Blue Swirl wrote:
>>>
>>> DIMMs would be allowed to be hotplugged in the generic mem-controller
>>> scheme only
>>> (unless it makes sense to allow hotplug in the remaining pmc DRBs and
>>> start using the generic scheme once we run out of emulated DRBs)
>>>
>>
>> 440fx see
On 10/22/2012 09:04 AM, Philipp Hahn wrote:
> Hello Doug,
>
> On Saturday 20 October 2012 00:46:43 Doug Goldstein wrote:
>> I'm using libvirt 0.10.2 and I had qemu-kvm 1.1.1 running all my VMs.
> ...
>> I had upgraded to qemu-kvm 1.1.2
> ...
>> qemu: warning: error while loading state for instanc
On 10/22/2012 02:57 PM, Peter Maydell wrote:
> On 9 October 2012 17:32, Avi Kivity wrote:
>> Instead of calling a global function on coalesced mmio changes, which
>> routes the call to kvm if enabled, add coalesced mmio hooks to
>> MemoryListener and make kvm use tha
On 10/23/2012 07:52 AM, liu ping fan wrote:
> On Mon, Oct 22, 2012 at 6:40 PM, Avi Kivity wrote:
>> On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
>>> The broken device state is caused by releasing local lock before acquiring
>>> big lock. To fix this issue, we have two ch
On 10/23/2012 11:32 AM, liu ping fan wrote:
> On Tue, Oct 23, 2012 at 5:07 PM, Jan Kiszka wrote:
>> On 2012-10-23 07:52, liu ping fan wrote:
>>> On Mon, Oct 22, 2012 at 6:40 PM, Avi Kivity wrote:
>>>> On 10/22/2012 11:23 AM, Liu Ping Fan wrote:
>>>
On 10/23/2012 01:51 PM, Paolo Bonzini wrote:
> Il 22/10/2012 11:38, Avi Kivity ha scritto:
>>> >
>>> > typedef struct MemoryRegionOps MemoryRegionOps;
>>> > typedef struct MemoryRegion MemoryRegion;
>>> > @@ -66,6 +67,8 @@ struct MemoryRegi
On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
> Il 23/10/2012 13:55, Avi Kivity ha scritto:
>>> > So the stop_machine idea is thrown away?
>> IIRC I convinced myself that it's just as bad.
>
> It may be just as bad, but it is less code (and less pervasive), wh
On 10/23/2012 02:06 PM, Paolo Bonzini wrote:
> Il 23/10/2012 14:02, Avi Kivity ha scritto:
>> On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
>>> Il 23/10/2012 13:55, Avi Kivity ha scritto:
>>>>>> So the stop_machine idea is thrown away?
>>>&g
On 10/23/2012 02:16 PM, Jan Kiszka wrote:
> On 2012-10-23 14:12, Paolo Bonzini wrote:
>> Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>>>
>>> So the stop_machine idea is thrown away?
>
> IIRC I convinced myself that it's just as bad.
>>> One tricky part with stop machine is that le
On 10/23/2012 02:12 PM, Jan Kiszka wrote:
> On 2012-10-22 11:23, Liu Ping Fan wrote:
>> Without biglock, we try to protect the mr by increase refcnt.
>> If we can inc refcnt, go backward and resort to biglock.
>>
>> Another point is memory radix-tree can be flushed by another
>> thread, so we shou
On 10/23/2012 02:40 PM, Jan Kiszka wrote:
> On 2012-10-23 14:28, Avi Kivity wrote:
>> On 10/23/2012 02:16 PM, Jan Kiszka wrote:
>>> On 2012-10-23 14:12, Paolo Bonzini wrote:
>>>> Il 23/10/2012 14:04, Jan Kiszka ha scritto:
>>>>>>>&
On 10/23/2012 02:32 PM, Paolo Bonzini wrote:
> Il 23/10/2012 14:15, Avi Kivity ha scritto:
>> On 10/23/2012 02:06 PM, Paolo Bonzini wrote:
>>> Il 23/10/2012 14:02, Avi Kivity ha scritto:
>>>> On 10/23/2012 01:57 PM, Paolo Bonzini wrote:
>>>>> Il 23/10/2
On 10/23/2012 03:04 PM, Peter Maydell wrote:
> On 23 October 2012 11:30, Avi Kivity wrote:
>> target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
>> reserved) and its purpose doesn't match the name (most target_phys_addr_t
>> addresses are not tar
On 10/23/2012 02:55 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
>> reserved) and its purpose doesn't match the name (most target_phys_addr_t
>> addresses are not target specifi
On 10/23/2012 05:26 PM, Paolo Bonzini wrote:
>>> Yes, that's the point of doing things asynchronously---you do not need
>>> to do everything within stop_machine, you can start canceling AIO as
>>> soon as the OS sends the hot-unplug request. Then you only proceed with
>>> stop_machine and freeing
On 10/23/2012 06:00 PM, Peter Maydell wrote:
> (found while trying to rebase the qemu-linaro OMAP3 patches;
> dunno if it's reproducable in plain mainline easily)
>
> Commit 9ac6a217 makes ohci_init_pxa() set up the OHCI code
> with a NULL DMAContext*, and asserts in the commit message:
>
> "in t
On 10/24/2012 08:36 AM, liu ping fan wrote:
> On Tue, Oct 23, 2012 at 5:37 PM, Avi Kivity wrote:
>> On 10/23/2012 11:32 AM, liu ping fan wrote:
>>> On Tue, Oct 23, 2012 at 5:07 PM, Jan Kiszka wrote:
>>>> On 2012-10-23 07:52, liu ping fan wrote:
>>>>>
On 10/24/2012 08:56 AM, liu ping fan wrote:
>>>
>> Oh, here is a bug, need unref. As to unbalanced refcount, it will be
>> adopted for virtio-blk listener (not implement in this patchset)
>>
> It is like cpu_physical_memory_map/unmap, the map will hold the
> unbalanced ref, and unmap release it.
On 10/24/2012 09:17 AM, Jan Kiszka wrote:
>>>
>>> This is ugly for many reasons. First of all, it is racy as the register
>>> content may change while dropping the device lock, no? Then you would
>>> raise or clear an IRQ spuriously.
>>>
>> Device state's intact is protected by busy flag, and will
On 10/25/2012 11:00 AM, Peter Maydell wrote:
> On 23 October 2012 10:37, Avi Kivity wrote:
>> On 10/23/2012 11:32 AM, liu ping fan wrote:
>>> On Tue, Oct 23, 2012 at 5:07 PM, Jan Kiszka wrote:
>>>> On 2012-10-23 07:52, liu ping fan wrote:
>>>>> On Mo
-off-by: Avi Kivity
---
Please review, and check if this patch fixes things for you.
hw/pci_bridge.c| 50 --
hw/pci_internals.h | 24
2 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/hw/pci_bridge.c b/hw
On 10/25/2012 11:55 AM, Peter Maydell wrote:
> On 25 October 2012 10:47, Peter Crosthwaite
> wrote:
>> +static int usb_ehci_sysbus_initfn(SysBusDevice *dev)
>> +{
>> +EHCIItfState *i = FROM_SYSBUS(EHCIItfState, dev);
>> +EHCIState *s = &i->ehci;
>> +
>> +s->dma = g_new(DMAContext, 1);
On 10/25/2012 03:03 PM, Peter Crosthwaite wrote:
> On Thu, Oct 25, 2012 at 10:19 PM, Gerd Hoffmann wrote:
>> On 10/25/12 11:47, Peter Crosthwaite wrote:
>>> Just put RAM regions in the unimplemented spaces in the MMIO region. These
>>> regions have undefined behaviour, but this at least stops QEMU
On 10/25/2012 03:12 PM, Peter Maydell wrote:
> (2) what should the memory system do for accesses where there is
> no memory region? This is really system specific as it depends
> what the bus fabric does. For ARM the usual thing would be to
> generate a decode error response which will result i
On 10/25/2012 03:28 PM, Peter Maydell wrote:
> On 25 October 2012 14:21, Avi Kivity wrote:
>> On 10/25/2012 03:12 PM, Peter Maydell wrote:
>>> (2) what should the memory system do for accesses where there is
>>> no memory region? This is really system specific as i
patch fix it for you?
From: Avi Kivity
Date: Thu, 11 Oct 2012 12:40:24 +0200
Subject: [PATCH] memory: limit sections in the radix tree to the actual
address space size
The radix tree is statically sized to fit TARGET_PHYS_ADDR_SPACE_BITS.
If a larger memory region is registered, it will overflow.
On 10/25/2012 03:50 PM, Peter Maydell wrote:
> On 25 October 2012 14:41, Avi Kivity wrote:
>> On 10/25/2012 03:28 PM, Peter Maydell wrote:
>>> On 25 October 2012 14:21, Avi Kivity wrote:
>>>> You could easily have the top-level container have ->ops that gener
On 10/25/2012 04:39 PM, Aurelien Jarno wrote:
> On Thu, Oct 25, 2012 at 03:47:34PM +0200, Avi Kivity wrote:
>> On 10/24/2012 04:00 PM, Aurelien Jarno wrote:
>> >
>> > mips is also broken but by commit 1c380f9460522f32c8dd2577b2a53d518ec91c6d:
>> >
>> &g
On 10/25/2012 11:31 AM, Jan Kiszka wrote:
> On 2012-10-25 11:01, Avi Kivity wrote:
>> On 10/24/2012 09:17 AM, Jan Kiszka wrote:
>>>>>
>>>>> This is ugly for many reasons. First of all, it is racy as the register
>>>>> content may cha
On 10/25/2012 03:34 PM, Jan Kiszka wrote:
>>> Second, it clearly shows that we need to address lock-less IRQ delivery.
>>> Almost nothing is won if we have to take the global lock again to push
>>> an IRQ event to the guest. I'm repeating myself, but the problem to be
>>> solved here is almost ide
On 10/24/2012 09:29 AM, Paolo Bonzini wrote:
> Il 23/10/2012 18:09, Avi Kivity ha scritto:
>>> But our interfaces had better support asynchronicity, and indeed they
>>> do: after you write to the "eject" register, the "up" will show the
>>> device
On 10/25/2012 06:39 PM, Jan Kiszka wrote:
>>
>> That doesn't work cross-thread.
>>
>> vcpu A: write to device X, dma-ing to device Y
>> vcpu B: write to device Y, dma-ing to device X
>
> We will deny DMA-ing from device X on behalf of a VCPU, ie. in dispatch
> context, to Y.
>
> What we do not
On 10/25/2012 06:41 PM, Jan Kiszka wrote:
> On 2012-10-25 18:23, Avi Kivity wrote:
>> On 10/25/2012 03:34 PM, Jan Kiszka wrote:
>>
>>>>> Second, it clearly shows that we need to address lock-less IRQ delivery.
>>>>> Almost nothing is won if we have t
On 10/25/2012 04:04 PM, Peter Maydell wrote:
> On 22 October 2012 10:23, Liu Ping Fan wrote:
>> v1:
>> https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg03312.html
>>
>> v2:
>> http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01275.html
>>
>> v3:
>> http://lists.nongnu.org/archive/ht
On 10/29/2012 01:48 AM, Liu Ping Fan wrote:
> For those address spaces which want to be able out of big lock, they
> will be protected by their own local.
>
> Signed-off-by: Liu Ping Fan
> ---
> memory.c | 11 ++-
> memory.h |5 -
> 2 files changed, 14 insertions(+), 2 deletion
201 - 300 of 4803 matches
Mail list logo
