On 10/29/2012 01:48 AM, 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 should get the copy of terminal mr to survive
> fr
On 10/29/2012 09:54 AM, Aurelien Jarno wrote:
> On Thu, Oct 25, 2012 at 06:12:06PM +0200, Avi Kivity wrote:
>> 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 w
On 10/25/2012 07:13 PM, Peter Maydell wrote:
> On 25 October 2012 18:07, Avi Kivity wrote:
>> On 10/25/2012 04:04 PM, Peter Maydell wrote:
>>> Is there a clear up to date description somewhere of the design and
>>> locking strategy here somewhere? I'd rather not ha
On 10/29/2012 05:36 PM, Michael Roth wrote:
> 2be0e25f added an assertion that memory_region_destroy() is not called
> during a transaction. pci_bridge_update_mappings() wants to do this so
> that it can remove existing subregions and add new ones in their
> place as an atomic operation.
>
> Work
es).
Tested-by: Aurelien Jarno
Signed-off-by: Avi Kivity
---
memory.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/memory.c b/memory.c
index 36bb9a5..243cb23 100644
--- a/memory.c
+++ b/memory.c
@@ -539,12 +539,12 @@ static void render_memory_region
On 10/27/2012 06:12 AM, Edgar E. Iglesias wrote:
>
> Hi,
>
> If well designed, most hw has a well designed symtery between regs
> that makes things simpler if you can just opencode the decding.
> IMO, an mr per reg would just add a massive overhead for no win.
> And also, hw implemented decoders
On 10/29/2012 01:37 AM, John Williams wrote:
>> IMO, an mr per reg would just add a massive overhead for no win.
>
> I tend to agree with Edgar here - QEMU has a careful line to walk between
> being an emulator and an RTL simulator.
>
> Any WAG on the runtime overhead of a mem region per regist
On 10/29/2012 10:32 AM, Peter Maydell wrote:
> On 29 October 2012 06:35, Peter Crosthwaite
> wrote:
>> Device model for Primecell PL330 dma controller.
>
> A general question -- this is a DMA controller so should it be using
> the DMAContext APIs now? Avi?
IOMMU functionality will be folded into
Changes from RFC:
- change ->translate to return read/write permissions in IOTLBEntry (was:
->translate received is_write parameter)
- add support for iommu fault reporting
Avi Kivity (7):
memory: fix address space initialization/destruction
memory: limit sections in the radix t
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
Use the new iommu support in the memory core for iommu support.
The only user, spapr, is also converted.
Signed-off-by: Avi Kivity
---
hw/pci.c | 59 +-
hw/pci.h | 7 +--
hw/pci_internals.h | 5 +++--
hw/spapr.h
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 | 77
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
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 0473ae8..bd7a075 100644
--- a/hw/vfio_pci.c
+++
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 | 106
Accesses which do not translate will hit the fault region, which
can then log the access.
Signed-off-by: Avi Kivity
---
memory.c | 9 ++---
memory.h | 4
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/memory.c b/memory.c
index ba2d4a0..d6b46fd 100644
--- a/memory.c
On 10/30/2012 02:16 PM, Paolo Bonzini wrote:
> The LAPIC is loaded separately from the rest of the VCPU state. Thus,
> when restoring the CPU the dummy post-reset state is passed to the
> in-kernel APIC.
>
> This can cause MSI injection to fail if attempted during the restore of
> another device,
On 10/30/2012 03:42 PM, Peter Crosthwaite wrote:
> On Tue, Oct 30, 2012 at 7:51 PM, Avi Kivity wrote:
>> On 10/29/2012 10:32 AM, Peter Maydell wrote:
>>> On 29 October 2012 06:35, Peter Crosthwaite
>>> wrote:
>>>> Device model for Primecell PL330 dma
On 06/18/2012 08:35 PM, Stefan Hajnoczi wrote:
> On Mon, Jun 11, 2012 at 3:21 PM, Bharata B Rao
> wrote:
>> +#include "block_int.h"
>> +#include "gluster-helpers.h"
>> +
>> +typedef void *gluster_file_t;
>
> This typedef is already in gluster-helpers.h. It's ugly BTW, "typedef
> struct gluster_f
On 06/16/2012 09:46 AM, Blue Swirl wrote:
> On Fri, Jun 15, 2012 at 9:36 PM, Paul Moore wrote:
>> On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote:
>>> On Fri, Jun 15, 2012 at 9:02 PM, Paul Moore wrote:
>>> > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote:
>>> >> I think allowing exec
On 06/19/2012 09:58 PM, Blue Swirl wrote:
>>> At least qemu-ifup/down scripts, migration exec and smbd have been
>>> mentioned. Only the system calls made by smbd (for some version of it)
>>> can be known. The user could specify arbitrary commands for the
>>> others, those could be assumed to use s
On 06/23/2012 02:45 PM, Jan Kiszka wrote:
>
> Hmm, we may need the iothread lock around cpu_set_apic_tpr for
> !kvm_irqchip_in_kernel(). And as we are at it, apic_base manipulation
> can be but there as well.
>
> With in-kernel irqchip, there is no such need. Also, no one accesses
> eflags outsid
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
> On 2012-06-24 10:49, Avi Kivity wrote:
>> On 06/23/2012 02:45 PM, Jan Kiszka wrote:
>>>
>>> Hmm, we may need the iothread lock around cpu_set_apic_tpr for
>>> !kvm_irqchip_in_kernel(). And as we are at it, apic_base
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
> As a first step, I will post a series later that gets rid of
> kvm_flush_coalesced_mmio_buffer in the common vmexit path.
If you defer this, I can think of two places that need to flush:
- anything that accesses those memory areas (such as DMA to the
fra
On 06/24/2012 05:40 PM, Jan Kiszka wrote:
> On 2012-06-24 16:35, Avi Kivity wrote:
>> On 06/24/2012 05:08 PM, Jan Kiszka wrote:
>>> As a first step, I will post a series later that gets rid of
>>> kvm_flush_coalesced_mmio_buffer in the common vmexit path.
>>
>
On 06/24/2012 05:51 PM, Jan Kiszka wrote:
> On 2012-06-24 16:46, Avi Kivity wrote:
>> On 06/24/2012 05:40 PM, Jan Kiszka wrote:
>>> On 2012-06-24 16:35, Avi Kivity wrote:
>>>> On 06/24/2012 05:08 PM, Jan Kiszka wrote:
>>>>> As a first step
On 06/24/2012 05:58 PM, Jan Kiszka wrote:
>>> Are there really cases where the framebuffer is accessible both via MMIO
>>> and RAM-like mappings at the same time? If so, the current flushing on
>>> vmexit would help either as the direct mappings would not trigger exits.
>>> Or what do you mean?
>>
On 06/25/2012 10:00 AM, Jan Kiszka wrote:
> Instead of flushing pending coalesced MMIO requests on every vmexit,
> this provides a mechanism to selectively flush when memory regions
> related to the coalesced one are accessed. This first of all includes
> the coalesced region itself but can also ap
On 06/25/2012 10:01 AM, Jan Kiszka wrote:
> Flush pending coalesced MMIO before performing mapping or state changes
> that could affect the event orderings or route the buffered requests to
> a wrong region.
>
> Signed-off-by: Jan Kiszka
>
> In addition, we also have to
Yes, we do.
>
> void
On 06/25/2012 01:26 PM, Jan Kiszka wrote:
> On 2012-06-25 12:15, Jan Kiszka wrote:
>> On 2012-06-25 10:57, Avi Kivity wrote:
>>> The repetitiveness of this code suggests a different way of doing this:
>>> make every API call be its own subtransacti
On 06/25/2012 11:26 PM, Jan Kiszka wrote:
> On 2012-06-25 18:55, Luiz Capitulino wrote:
>> Allow for disabling memory merge support (KSM on Linux), which is
>> enabled by default otherwise.
>
> -machine mem_merge=on|off?
It's a host property, not a guest property.
For devices we have a pretty go
On 06/26/2012 10:34 PM, Marcelo Tosatti wrote:
>
> 1. read_lock(memmap_lock)
> 2. MemoryRegionSection mrs = lookup(addr)
> 3. qom_ref(mrs.mr->dev)
> 4. read_unlock(memmap_lock)
>
> 5. mutex_lock(dev->lock)
> 6. dispatch(&mrs, addr, data, size)
> 7. mutex_unlock(dev->lock)
>
> 8. qom_unre
On 06/04/2012 03:28 PM, Anthony Liguori wrote:
>> Michael has some concern on this patch, so I post another patch of
>> validating
>> the rx buf instead of checking the opmode, please see
>> http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg02385.html. So
>> maybe we
>> can apply that or I n
On 06/27/2012 01:29 PM, Peter Maydell wrote:
> Add field32() and field64() functions which extract a particular
> bit field from a word and return it. Based on an idea by Jia Liu.
>
>
> +/**
> + * field64 - return a specified bit field from a uint64_t value
> + * @value: The value to extract the
On 06/27/2012 04:15 PM, Avi Kivity wrote:
> On 06/27/2012 01:29 PM, Peter Maydell wrote:
>> Add field32() and field64() functions which extract a particular
>> bit field from a word and return it. Based on an idea by Jia Liu.
>>
>>
>> +/**
>> + * field6
On 06/27/2012 04:22 PM, Peter Maydell wrote:
> On 27 June 2012 14:15, Avi Kivity wrote:
>> I suggest adding the analogous functions for writing. I believe the
>> common naming is extract/deposit.
>>
>> static inline uint64_t deposit64(uint6
to
> guest, we can forbid packet receiving when rx ring address is zero.
>
Tested-by: Avi Kivity
This unbreaks kvm-autotest.
--
error compiling committee.c: too many arguments to function
On 06/27/2012 04:28 PM, Eric Blake wrote:
> On 06/27/2012 07:15 AM, Avi Kivity wrote:
>> On 06/27/2012 01:29 PM, Peter Maydell wrote:
>>> Add field32() and field64() functions which extract a particular
>>> bit field from a word and return it. Based on an idea by Jia Liu
On 06/27/2012 05:24 PM, Markus Armbruster wrote:
> Avi Kivity writes:
>
>> On 06/27/2012 04:28 PM, Eric Blake wrote:
> [...]
>>> You marked this function signature as returning uint64_t, but didn't
>>> return anything. I think the logical return is the
On 06/28/2012 05:10 PM, Anthony Liguori wrote:
>>
>> 1. read_lock(memmap_lock)
>> 2. MemoryRegionSection mrs = lookup(addr)
>> 3. qom_ref(mrs.mr->dev)
>> 4. read_unlock(memmap_lock)
>>
>> 5. mutex_lock(dev->lock)
>> 6. dispatch(&mrs, addr, data, size)
>> 7. mutex_unlock(dev->lock)
>
> Just
On 06/27/2012 07:27 PM, Jan Kiszka wrote:
> Instead of flushing pending coalesced MMIO requests on every vmexit,
> this provides a mechanism to selectively flush when memory regions
> related to the coalesced one are accessed. This first of all includes
> the coalesced region itself but can also ap
On 06/27/2012 07:27 PM, Jan Kiszka wrote:
> Changes in v2:
> - added memory_region_clear_flush_coalesced
> - call memory_region_clear_flush_coalesced from
>memory_region_clear_coalescing
> - wrap all region manipulations via memory_region_transaction_begin/
>commit internally
> - flush
On 06/28/2012 07:29 PM, Peter Lieven wrote:
>> Yes. A signal is sent, and KVM returns from the guest to userspace on
>> pending signals.
> is there a description available how this process exactly works?
The kernel part is in vcpu_enter_guest(), see the check for
signal_pending(). But this hasn'
On 06/28/2012 10:27 PM, Peter Lieven wrote:
>
> Am 28.06.2012 um 18:32 schrieb Avi Kivity:
>
>> On 06/28/2012 07:29 PM, Peter Lieven wrote:
>>>> Yes. A signal is sent, and KVM returns from the guest to userspace on
>>>> pending signals.
>>
>>
but can also applied to other regions, e.g.
> of the same device, by calling memory_region_set_flush_coalesced.
Looks fine.
I have a hard time deciding whether this should go through the kvm tree
or memory tree. Anthony, perhaps you can commit it directly to avoid
the livelock?
Reviewed
On 07/02/2012 12:07 PM, Avi Kivity wrote:
>
> Reviewed-by: Avi Kivity
(for the entire patchset)
--
error compiling committee.c: too many arguments to function
On 07/02/2012 12:18 PM, Michael S. Tsirkin wrote:
> I've been thinking hard about Jan's patches for device
> assignment. Basically while I thought it makes sense
> to make all devices: assignment and not - behave the
> same and use same APIs for injecting irqs, Anthony thinks there is huge
> value
On 07/02/2012 12:30 PM, Jan Kiszka wrote:
> On 2012-07-02 11:18, Michael S. Tsirkin wrote:
>> I've been thinking hard about Jan's patches for device
>> assignment. Basically while I thought it makes sense
>> to make all devices: assignment and not - behave the
>> same and use same APIs for injectin
On 06/26/2012 07:39 PM, Alexander Graf wrote:
> During discussions on whether to make -cpu host the default in SLE, I found
> myself disagreeing to the thought, because it potentially opens a big can
> of worms for potential bugs. But if I already am so opposed to it for SLE, how
> can it possibly
On 06/26/2012 07:39 PM, Alexander Graf wrote:
> When running QEMU without -cpu parameter, the user usually wants a sane
> default. So far, we're using the qemu64/qemu32 CPU type, which basically
> means "the maximum TCG can emulate".
>
> That's a really good default when using TCG, but when runnin
On 06/28/2012 12:38 PM, Peter Lieven wrote:
> does anyone know whats that here in handle_mmio?
>
> /* hack: Red Hat 7.1 generates these weird accesses. */
> if ((addr > 0xa-4 && addr <= 0xa) && kvm_run->mmio.len == 3)
> return 0;
>
Just what it says. There is a 4-byte ac
On 07/03/2012 04:01 PM, Peter Lieven wrote:
> Further output from my testing.
>
> Working:
> Linux 2.6.38 with included kvm module
> Linux 3.0.0 with included kvm module
>
> Not-Working:
> Linux 3.2.0 with included kvm module
> Linux 2.6.28 with kvm-kmod 3.4
> Linux 3.0.0 with kvm-kmod 3.4
> Linu
On 07/03/2012 04:15 PM, Peter Lieven wrote:
> On 03.07.2012 15:13, Avi Kivity wrote:
>> On 07/03/2012 04:01 PM, Peter Lieven wrote:
>>> Further output from my testing.
>>>
>>> Working:
>>> Linux 2.6.38 with included kvm module
>>> Linux 3.0.0 w
On 07/03/2012 10:06 PM, Blue Swirl wrote:
> On Mon, Jul 2, 2012 at 9:43 AM, Avi Kivity wrote:
>> On 07/02/2012 12:30 PM, Jan Kiszka wrote:
>>> On 2012-07-02 11:18, Michael S. Tsirkin wrote:
>>>> I've been thinking hard about Jan's patches for device
>&
On 07/04/2012 01:42 PM, Michael S. Tsirkin wrote:
> On Mon, Jul 02, 2012 at 12:43:48PM +0300, Avi Kivity wrote:
>> On 07/02/2012 12:30 PM, Jan Kiszka wrote:
>> > On 2012-07-02 11:18, Michael S. Tsirkin wrote:
>> >> I've been thinking hard about Jan's patche
On 07/06/2012 09:06 PM, Jan Kiszka wrote:
> On 2012-07-06 19:16, Jan Kiszka wrote:
>> On 2012-06-24 16:08, Jan Kiszka wrote:
>>> On 2012-06-24 10:49, Avi Kivity wrote:
>>>> On 06/23/2012 02:45 PM, Jan Kiszka wrote:
>>>>>
>>>>> Hm
On 06/28/2012 08:58 AM, Markus Armbruster wrote:
>>>
>>> Better code is an argument only if the effect can be demonstrated.
>>
>> I don't know even for which compilers or CPUs this is true so it's
>> unlikely I could demonstrate it. However, googling finds a few
>> articles in defense of this.
>
>
On 07/09/2012 05:42 PM, Jan Kiszka wrote:
> As Avi noted recently, there is a problem in way we inject interrupts
> into the userspace APIC under KVM: The TRP check over the iothread may
> race with the VCPU raising the TPR value while in KVM mode. Patch 3
> addresses this issue.
>
> The other two
Current qemu-kvm master merged with latest upstream fails on startup:
(gdb) bt
#0 0x7fdcd4a047a0 in kvm_vcpu_ioctl (env=0x0, type=-1071075694) at
/home/tlv/akivity/qemu/kvm-all.c:1602
#1 0x7fdcd49c9fda in kvm_apic_enable_tpr_reporting
(s=0x7fdcd75af6c0, enable=false) at
/home/tlv/akivity
On 07/11/2012 02:59 PM, Jan Kiszka wrote:
>>>
>>> I will try to reproduce. Is there a tree of the merge available?
>>
>> I just merged upstream into qemu-kvm master. For some reason there were
>> no conflicts.
>
> A rare moment, I guess. ;)
I'll put it down to random chance until we can figure
On 07/11/2012 03:04 PM, Avi Kivity wrote:
>>>> specific command line or guest?
>>>
>>> qemu-system-x86_64
>>
>> Just did the same, but it's all fine here.
>
> Ok, I'll debug it. Probably something stupid like a miscompile.
Indee
On 07/11/2012 02:55 PM, Jan Kiszka wrote:
> On 2012-07-11 13:46, Avi Kivity wrote:
>> Current qemu-kvm master merged with latest upstream fails on startup:
>>
>> (gdb) bt
>> #0 0x7fdcd4a047a0 in kvm_vcpu_ioctl (env=0x0, type=-1071075694) at
>> /home/tlv/
On 07/06/2012 08:11 AM, Markus Armbruster wrote:
>
> It seems there could be more knobs to control than just "dump guest
> state yes/no". Therefore, extensible command line syntax like
> "--core-dump guest-ram=off" seems to be advisable. We have too many
> -dont-do-FOO options already.
-m 2T,du
On 07/11/2012 01:32 PM, Vasilis Liaskovitis wrote:
> Implement batch dimm creation command line options. These could be useful for
> not bloating the command line with a large number of dimms.
IMO this is unneeded. With a management tool there is no problem
generating a long command line; from th
On 07/05/2012 06:16 PM, Paolo Bonzini wrote:
> This is broken; since the eventfd is used in nonblocking mode there
> is a race between reading and writing.
>
> diff --git a/event_notifier.c b/event_notifier.c
> index 2b210f4..c339bfe 100644
> --- a/event_notifier.c
> +++ b/event_notifier.c
> @@ -
On 07/05/2012 06:16 PM, Paolo Bonzini wrote:
>
> struct EventNotifier {
> - int fd;
> +int fd;
> };
>
If you're fixing whitespace, might as well fix it correctly.
--
error compiling committee.c: too many arguments to function
On 07/05/2012 06:16 PM, Paolo Bonzini wrote:
> This is part 1 of a three-part series that expands usage of EventNotifier
> in QEMU (including AIO and the main loop). I started working on this when
> playing with the threaded block layer; the part of that work that I hope
> will be in 1.2 is genera
On 07/12/2012 01:30 PM, Paolo Bonzini wrote:
> Il 12/07/2012 11:10, Avi Kivity ha scritto:
>> On 07/05/2012 06:16 PM, Paolo Bonzini wrote:
>>> This is broken; since the eventfd is used in nonblocking mode there
>>> is a race between reading and writing.
>>>
>
On Thu, Jan 31, 2013 at 4:30 PM, Gleb Natapov wrote:
>> >
>> > Avi/Michael do you remember why mincore can't be used to check if a guest
>> page is unmapped?
>>
>> A page may be not in core, but also nonzero (for example swap).
> Yes, mincore() should not be used as zero page check, but it can be
On Jan 31, 2013 4:03 PM, "Peter Lieven" wrote:
>
>
> Am 31.01.2013 um 14:59 schrieb Avi Kivity :
>
>>
>> On Jan 31, 2013 12:29 PM, "Orit Wasserman" wrote:
>> >
>> > On 01/31/2013 11:48 AM, Gleb Natapov wrote:
>> > > On Thu
On Thu, Jan 31, 2013 at 4:42 PM, Gleb Natapov wrote:
> On Thu, Jan 31, 2013 at 04:36:25PM +0200, Avi Kivity wrote:
>> On Thu, Jan 31, 2013 at 4:30 PM, Gleb Natapov wrote:
>> >> >
>> >> > Avi/Michael do you remember why mincore can't be used to chec
On Jan 31, 2013 12:29 PM, "Orit Wasserman" wrote:
>
> On 01/31/2013 11:48 AM, Gleb Natapov wrote:
> > On Thu, Jan 31, 2013 at 09:47:24AM +0200, Orit Wasserman wrote:
> >> On 01/31/2013 08:57 AM, Peter Lieven wrote:
> >>> Hi,
> >>>
> >>> I just came across an idea and would like to have feedback if
On Jan 31, 2013 11:14 PM, "Michael S. Tsirkin" wrote:
>
> On Thu, Jan 31, 2013 at 05:20:02PM +0200, Avi Kivity wrote:
> > On Thu, Jan 31, 2013 at 4:42 PM, Gleb Natapov wrote:
> > > On Thu, Jan 31, 2013 at 04:36:25PM +0200, Avi Kivity wrote:
> > >> On
On Thu, Feb 14, 2013 at 3:09 PM, Michael S. Tsirkin wrote:
> On Thu, Feb 14, 2013 at 12:56:02PM +, Peter Maydell wrote:
>> On 14 February 2013 12:45, Michael S. Tsirkin wrote:
>> > overlap flag in the region is currently unused, most devices have no
>> > idea whether their region overlaps wit
On Thu, Feb 14, 2013 at 4:02 PM, Michael S. Tsirkin wrote:
> On Thu, Feb 14, 2013 at 01:22:18PM +, Peter Maydell wrote:
>> On 14 February 2013 13:09, Michael S. Tsirkin wrote:
>> > On Thu, Feb 14, 2013 at 12:56:02PM +, Peter Maydell wrote:
>> >> Up to the parent which controls the region
On Thu, Feb 14, 2013 at 4:40 PM, Michael S. Tsirkin wrote:
> On Thu, Feb 14, 2013 at 04:14:39PM +0200, Avi Kivity wrote:
>
> But some parents are system created and shared by many devices so children for
> such have no idea who their siblings are.
>
> Please take a look at the t
On Thu, Feb 14, 2013 at 6:50 PM, Michael S. Tsirkin wrote:
>> > As you see, ioapic at 0xfec0 overlaps pci-hole.
>> > ioapic is guest programmable in theory - should use _overlap?
>> > pci-hole is not but can overlap with ioapic.
>> > So also _overlap?
>>
>> It's a bug. The ioapic is in the pc
On Thu, Feb 14, 2013 at 8:12 PM, Michael S. Tsirkin wrote:
>>
>> Is there an actual real problem that needs fixing?
>
> Yes. Guests sometimes cause device BARs to temporary overlap
> the APIC range during BAR sizing. It works fine on a physical
> system but fails on KVM since pci has same priority
On Tue, Feb 19, 2013 at 4:41 PM, Michael S. Tsirkin wrote:
> On Thu, Feb 14, 2013 at 08:23:04PM +0200, Avi Kivity wrote:
>> On Thu, Feb 14, 2013 at 8:12 PM, Michael S. Tsirkin wrote:
>> >>
>> >> Is there an actual real problem that needs fixing?
>> >
&g
On Tue, Feb 19, 2013 at 6:08 PM, Michael S. Tsirkin wrote:
>>
>> The IOAPIC is actually closer to ISA, but again it's sufficient to
>> move it to the PCI address space. I doubt its priority matters.
>
> Well moving IOAPIC to PCI seems strange, it's not a PCI thing,
> and I think it can be moved o
On 09/20/2012 10:51 AM, liu ping fan wrote:
> On Wed, Sep 19, 2012 at 5:23 PM, Avi Kivity wrote:
>> On 09/19/2012 12:19 PM, liu ping fan wrote:
>>> On Wed, Sep 19, 2012 at 5:14 PM, Paolo Bonzini wrote:
>>>> Il 19/09/2012 11:11, liu ping fan ha scritto:
>>>
On 09/20/2012 10:51 AM, liu ping fan wrote:
> On Wed, Sep 19, 2012 at 5:05 PM, Avi Kivity wrote:
>> On 09/19/2012 11:36 AM, liu ping fan wrote:
>>>>
>>>> It basically means you can't hold contents of device state in local
>>>> variables. You ne
On 09/20/2012 10:19 AM, Gleb Natapov wrote:
>> Again: If you think the feature is non-invasive, send patches against
>> the kernel and QEMU.
>>
> And explain why it is better than what modern HW provides.
If it's non-invasive (and easily maintainable), it doesn't have to be
better.
--
error co
On 09/20/2012 02:12 PM, Anthony PERARD wrote:
> This new helper/hook is used in the next patch to add an extra call in a
> single
> place.
>
Reviewed-by: Avi Kivity
--
error compiling committee.c: too many arguments to function
On 09/19/2012 10:57 PM, Blue Swirl wrote:
> On Wed, Sep 19, 2012 at 12:54 PM, Avi Kivity wrote:
>> On 09/14/2012 10:51 PM, Blue Swirl wrote:
>>>>
>>>> exec:
>>>
>>> These files need cleanup so that TCG code gets into tcg/. Maybe also
>>>
er of anyone using them.
Signed-off-by: Avi Kivity
---
cputlb.c | 3 +--
exec.c | 3 +--
exec-obsolete.h => memory-internal.h | 8 ++--
memory.c | 3 +--
4 files changed, 5 insertions(+), 12 deletions(-)
On 09/22/2012 04:15 PM, Blue Swirl wrote:
> >
> >> This could have nice cleanup effects though and for example enable
> >> generic 'info vmtree' to discover VA->PA mappings for any target
> >> instead of current MMU table walkers.
> >
> > How? That's in a hardware defined format that's completely
On 09/21/2012 09:20 PM, Eric Blake wrote:
> On 09/21/2012 12:18 PM, Eric Blake wrote:
> >> Any better ideas?
> >
> > Maybe s/hex/number/, as in:
> >
> > JSON: 'number':0x20
> >
> > C code: keylist->value->number = number;
> >
> > that is, you are passing the value either as a keycode name, or a
On 09/24/2012 08:33 AM, liu ping fan wrote:
> On Wed, Sep 19, 2012 at 5:50 PM, Avi Kivity wrote:
> > On 09/19/2012 12:34 PM, Jan Kiszka wrote:
> >>
> >> What about the following:
> >>
> >> What we really need to support in practice is MMIO ac
On 09/24/2012 10:32 AM, liu ping fan wrote:
> On Mon, Sep 24, 2012 at 3:44 PM, Avi Kivity wrote:
>> On 09/24/2012 08:33 AM, liu ping fan wrote:
>>> On Wed, Sep 19, 2012 at 5:50 PM, Avi Kivity wrote:
>>> > On 09/19/2012 12:34 PM, Jan Kiszka wrote:
>>
On 09/23/2012 06:07 PM, Blue Swirl wrote:
> On Sun, Sep 23, 2012 at 8:25 AM, Avi Kivity wrote:
>> On 09/22/2012 04:15 PM, Blue Swirl wrote:
>>> >
>>> >> This could have nice cleanup effects though and for example enable
>>> >> generic '
On 09/24/2012 01:11 PM, Paolo Bonzini wrote:
>
> A better plan would be to incorporate this code into glib, completing
> the extremely sparse URI support that is already there. However, we
> would not be able to use it anyway, because we support compiling on old
> glib versions.
If the same (or
On 09/27/2012 05:13 AM, liu ping fan wrote:
> On Mon, Sep 24, 2012 at 5:42 PM, Avi Kivity wrote:
>> On 09/24/2012 10:32 AM, liu ping fan wrote:
>>> On Mon, Sep 24, 2012 at 3:44 PM, Avi Kivity wrote:
>>>> On 09/24/2012 08:33 AM, liu ping fan wrote:
>>>
On 09/26/2012 10:25 PM, Luiz Capitulino wrote:
> o v3
>
> - doc & log fixups
> - rename KeyCode.hex to KeyCode.number
>
> This actually fixes a regression introduced by the qapi conversion,
> please refer to patch 2/3 for details.
>
> It's also important to note that this series changes the QM
On 09/27/2012 11:29 AM, Paolo Bonzini wrote:
> virtio-net is per-spec not going through the iommu.
What's that smell? A feature bit?
--
error compiling committee.c: too many arguments to function
On 09/27/2012 11:36 AM, Paolo Bonzini wrote:
> Il 27/09/2012 11:34, Avi Kivity ha scritto:
>>> > virtio-net is per-spec not going through the iommu.
>> What's that smell? A feature bit?
>
> Why is it a bad thing that it does not go through the iommu?
You can'
On 09/27/2012 12:22 PM, Paolo Bonzini wrote:
> Il 27/09/2012 12:08, Avi Kivity ha scritto:
>>>>>> virtio-net is per-spec not going through the iommu.
>>>> >> What's that smell? A feature bit?
>>> >
>>> > Why is it a bad thing t
On 09/27/2012 04:29 PM, Benoît Canet wrote:
> This patchset introduce a partial implementation of a deduplication mechanism
> for QCow2.
> This patchset layout the disk format changes in the qcow2 spec and
> provide a partial implementation of the write mechanisms.
>
> Albeit being partial this is
On 09/29/2012 11:20 AM, liu ping fan wrote:
>
> Do we have iommus in qemu now,
We do, but they're hacked into the scsi layer, see hw/sun4m_iommu.c. I
don't know if it's a standalone iommu on real hardware or whether it is
part of the HBA.
> since there are no separate phys_maps
> for real addr
On 09/30/2012 01:04 PM, Blue Swirl wrote:
> On Sun, Sep 30, 2012 at 8:13 AM, Avi Kivity wrote:
>> On 09/29/2012 11:20 AM, liu ping fan wrote:
>>>
>>> Do we have iommus in qemu now,
>>
>> We do, but they're hacked into the scsi layer, see hw/sun4m_io
301 - 400 of 4803 matches
Mail list logo
