On 09/13/2012 12:59 PM, liu ping fan wrote:
> On Thu, Sep 13, 2012 at 4:45 PM, Avi Kivity wrote:
>> On 09/13/2012 09:54 AM, liu ping fan wrote:
>>> On Tue, Sep 11, 2012 at 5:37 PM, Avi Kivity wrote:
>>>> On 09/11/2012 12:32 PM, liu ping fan wrote:
>>>
On 09/13/2012 05:22 PM, Gleb Natapov wrote:
>>
>> It's much easier for us to call into qemu-ga to do the time correction
>> whenever this event occurs than to try and have libvirt figure out when
>> it's necessary.
> And if guest does not have qemu-ga what is better inject interrupts like
> crazy
On 09/13/2012 05:42 PM, Eric Blake wrote:
> On 09/13/2012 08:34 AM, Avi Kivity wrote:
>> On 09/13/2012 05:22 PM, Gleb Natapov wrote:
>>>>
>>>> It's much easier for us to call into qemu-ga to do the time correction
>>>> whenever this event o
On 09/13/2012 06:50 PM, Anthony Liguori wrote:
>>>
This may not work for really old server oriented guests.
>>>
>>> S3 requires guest cooperation, period. But so does qemu-ga. It's
>>> better than nothing, and we can't get perfection without guest cooperation.
>>
>> qemu-ga requires either
On 09/13/2012 06:56 PM, Anthony Liguori wrote:
>>>
>> Hmm, true. What about hooking into suspend and doing vmstop during
>> suspend.
>
> Is suspend the only foreseeable way for this problem to happen? I don't
> think it is which is what concerns me about any approach that relies on
> "hooking s
On 09/13/2012 05:48 PM, Gleb Natapov wrote:
> On Thu, Sep 13, 2012 at 09:35:18AM -0500, Anthony Liguori wrote:
>> Gleb Natapov writes:
>>
>> > On Thu, Sep 13, 2012 at 09:06:29AM -0500, Anthony Liguori wrote:
>> >> "Daniel P. Berrange" writes:
>> >>
>> >> I think it's better for QEMU to talk to
On 09/13/2012 09:27 PM, Anthony Liguori wrote:
>>>
>>> Plus, there's a whole variety of other features enabled once we can
>>> assume qemu-ga is available. It's worth solving that problem.
>>
>> We can't assume it. Too many OSes exist, too many guests are already
>> exist and ain't broken, too m
On 09/19/2012 07:40 AM, Peter Crosthwaite wrote:
> On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
> wrote:
>> On Wed, Sep 19, 2012 at 02:25:48PM +1000, Peter Crosthwaite wrote:
>>> Ping for PMM,
>>>
>>> This is the root case of your block on the SDHCI series - this is a
>>> discussion on resol
On 09/17/2012 05:24 AM, liu ping fan wrote:
> On Thu, Sep 13, 2012 at 4:19 PM, Avi Kivity wrote:
>> On 09/13/2012 09:55 AM, liu ping fan wrote:
>>> On Tue, Sep 11, 2012 at 8:41 PM, Avi Kivity wrote:
>>>> On 09/11/2012 03:24 PM, Avi Kivity wrote:
>>>>
On 09/19/2012 06:02 AM, liu ping fan wrote:
> Currently, cpu_physical_memory_rw() can be used directly or indirectly
> by mmio-dispatcher to access other devices' memory region. This can
> cause some problem when adopting device's private lock.
>
> Back ground refer to:
> http://lists.gnu.org/arch
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 need to read everything again from the device. That
>> includes things like DMA enable bits.
>>
> I think that read everything again from the device can not work
On 09/19/2012 12:00 PM, liu ping fan wrote:
> On Wed, Sep 19, 2012 at 4:06 PM, Avi Kivity wrote:
>> On 09/19/2012 06:02 AM, liu ping fan wrote:
>>> Currently, cpu_physical_memory_rw() can be used directly or indirectly
>>> by mmio-dispatcher to access other devic
On 09/18/2012 12:51 PM, Gerd Hoffmann wrote:
> This patch adds a mmio bar to the qemu standard vga which allows to
> access the standard vga registers and bochs dispi interface registers
> via mmio.
>
> diff --git a/hw/vga-pci.c b/hw/vga-pci.c
> index 9abbada..e05e2ef 100644
> --- a/hw/vga-pci.c
>
On 09/19/2012 12:14 PM, Paolo Bonzini wrote:
> I don't know if the front-end (device) lock should come before or after
> the back-end (e.g. netdev) lock in the hierarchy, but that's another story.
I would say device -> backend. It's natural if the backend is the timer
subsystem, so extend it fro
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:
> Why not? devA will drop its local lock, devX will retake the big lock
> recursively, devB will take its local lock. In the end, we have
On 09/19/2012 12:34 PM, Jan Kiszka wrote:
>
> What about the following:
>
> What we really need to support in practice is MMIO access triggers RAM
> access of device model. Scenarios where a device access triggers another
> MMIO access could likely just be rejected without causing troubles.
>
>
On 09/19/2012 12:51 PM, Paolo Bonzini wrote:
> Il 19/09/2012 11:21, Avi Kivity ha scritto:
>>> > I don't know if the front-end (device) lock should come before or after
>>> > the back-end (e.g. netdev) lock in the hierarchy, but that's another
>>> >
On 09/04/2012 06:13 PM, Julien Grall wrote:
> This is the nineth version of patch series about ioport registration.
>
> Some part of QEMU still use register_ioport* functions to register ioport.
> These functions doesn't allow to use Memory Listener on it.
Jan't patch that dropped the debug iopor
On 09/19/2012 01:19 PM, Paolo Bonzini wrote:
> Il 19/09/2012 12:06, Avi Kivity ha scritto:
>>> > (The hunch is that ts could be deleted exactly at the moment the
>>> > callback is unlocked. This can be solved with ref/unref on the opaque
>>> > value, as you
On 09/19/2012 02:46 PM, Edgar E. Iglesias wrote:
> On Wed, Sep 19, 2012 at 10:55:30AM +0300, Avi Kivity wrote:
>> On 09/19/2012 07:40 AM, Peter Crosthwaite wrote:
>> > On Wed, Sep 19, 2012 at 2:32 PM, Edgar E. Iglesias
>> > wrote:
>> >> On Wed, Sep 19, 2012
On 09/19/2012 02:35 PM, Gerd Hoffmann wrote:
>> Looks like word writes are supported provided the memory API breaks up
>> writes in little endian order. Better to make it explicit.
>
> Like the attached incremental patch?
Very like.
--
error compiling committee.c: too many arguments to funct
On 09/14/2012 10:51 PM, Blue Swirl wrote:
>>
>> exec:
>
> These files need cleanup so that TCG code gets into tcg/. Maybe also
> TB and CPUTLB handling.
Some of that could be done by adding a separate MemoryListener for tcg.
--
error compiling committee.c: too many arguments to function
On 09/19/2012 04:01 PM, Igor Mitsyanko wrote:
>>> That would avoid the lockups and allow the device to be reset at
>>> any time. Or am I missing something?
>>>
>> Not that I can see. If real hardware can be looped, so can qemu. I'm
>> only worried about recursion and deadlocks (while real hardwar
On 09/19/2012 05:10 PM, Jan Kiszka wrote:
>> Although ELI works today, I'd be happy to
>> hear what parts of it you find "invasive" and "imperfect" (what
>> software ever is perfect?)
>
> It's imperfect as you need to dedicate a core to pure guest-mode load
> and cannot run userspace on that core
On 09/19/2012 05:47 PM, Alexander Graf wrote:
>
> On 04.09.2012, at 17:13, Cornelia Huck wrote:
>
>> Handle most support for channel I/O instructions in the kernel itself.
>>
>> Only asynchronous functions (such as the start function) need to be
>> handled by userspace.
>
> Phew. This is a lot
On 09/16/2012 05:37 PM, Anthony Liguori wrote:
> Avi Kivity writes:
>
>> On 09/13/2012 09:27 PM, Anthony Liguori wrote:
>>> If there was a better/equivalent solution that didn't depend on qemu-ga,
>>> I'd be all for it. But there isn't AFAICT.
>
On 09/19/2012 07:37 PM, Gleb Natapov wrote:
> On Wed, Sep 19, 2012 at 06:34:46PM +0300, Avi Kivity wrote:
>> On 09/16/2012 05:37 PM, Anthony Liguori wrote:
>> > Avi Kivity writes:
>> >
>> >> On 09/13/2012 09:27 PM, Anthony Liguori wrote:
>> >&
On 09/19/2012 10:44 AM, Jan Kiszka wrote:
> On 2012-09-19 09:26, Paolo Bonzini wrote:
>> Il 18/09/2012 22:37, Anthony Liguori ha scritto:
>>> Unfortunately, there's a lot of Windows code in qemu-timer.c and main-loop.c
>>> right now otherwise the refactoring would be trivial. I'll leave that for
>
On 09/19/2012 07:55 PM, Gleb Natapov wrote:
> On Wed, Sep 19, 2012 at 07:44:27PM +0300, Avi Kivity wrote:
>> On 09/19/2012 07:37 PM, Gleb Natapov wrote:
>> > On Wed, Sep 19, 2012 at 06:34:46PM +0300, Avi Kivity wrote:
>> >> On 09/16/2012 05:37 PM, Anthony Liguori wro
On 09/30/2014 12:33 PM, Michael S. Tsirkin wrote:
a single descriptor might use all of
the virtqueue. In this case we wont to be able to pass the
descriptor directly to linux as a single iov, since
You could separate maximum request scatter/gather list size from the
virtqueue size. They are
On 10/08/2014 12:15 PM, Michael S. Tsirkin wrote:
On Wed, Oct 08, 2014 at 10:43:07AM +0300, Avi Kivity wrote:
On 09/30/2014 12:33 PM, Michael S. Tsirkin wrote:
a single descriptor might use all of
the virtqueue. In this case we wont to be able to pass the
descriptor directly to linux as a
On 10/08/2014 01:14 PM, Michael S. Tsirkin wrote:
On Wed, Oct 08, 2014 at 12:51:21PM +0300, Avi Kivity wrote:
On 10/08/2014 12:15 PM, Michael S. Tsirkin wrote:
On Wed, Oct 08, 2014 at 10:43:07AM +0300, Avi Kivity wrote:
On 09/30/2014 12:33 PM, Michael S. Tsirkin wrote:
a single descriptor
On 10/08/2014 01:55 PM, Michael S. Tsirkin wrote:
Even more useful is getting rid of the desc array and instead passing descs
inline in avail and used.
You expect this to improve performance?
Quite possibly but this will have to be demonstrated.
The top vhost function in small packet workload
On 10/08/2014 01:55 PM, Michael S. Tsirkin wrote:
Inline descriptors will amortize the cache miss over 4 descriptors, and will
allow the hardware to prefetch, since the descriptors are linear in memory.
If descriptors are used in order (as they are with current qemu)
then aren't they amortize
On 10/08/2014 03:22 PM, Michael S. Tsirkin wrote:
On Wed, Oct 08, 2014 at 01:59:13PM +0300, Avi Kivity wrote:
On 10/08/2014 01:55 PM, Michael S. Tsirkin wrote:
Even more useful is getting rid of the desc array and instead passing descs
inline in avail and used.
You expect this to improve
On 10/08/2014 03:28 PM, Avi Kivity wrote:
My old presentation from 2012 or so suggested something like this.
We don't need a 64 bit cookie I think - a small 16 bit one
should be enough.
A 16 bit cookie means you need an extra table to hold the real request
pointers.
With a 64-bit c
On 12/20/2011 02:38 AM, Anthony Liguori wrote:
>> That was v1 of my patches. Avi didn't like it, I tried it like this, and
>> in the end I had to agree. So, no, I don't think we want such a model.
>
>
> Yes, we do :-)
>
> The in-kernel APIC is a different implementation of the APIC device.
> It's
On 12/20/2011 02:42 AM, Anthony Liguori wrote:
>> Look down http://thread.gmane.org/gmane.comp.emulators.kvm.devel/82598
>> for the discussion of that model.
>
>
> I have. I don't understand the rationale for jumping through hoops here.
>
> There seems to be an assertion that migrating from in-ker
On 12/20/2011 04:46 AM, Anthony Liguori wrote:
>
> I would hope that you would agree that when designing the device
> model, we should aim to do what makes sense independent of migration.
> If we cannot achieve a certain feature with migration given the
> logical modeling of devices, it probably s
On 12/20/2011 12:03 PM, Avi Kivity wrote:
> On 12/20/2011 04:46 AM, Anthony Liguori wrote:
> >
> > I would hope that you would agree that when designing the device
> > model, we should aim to do what makes sense independent of migration.
> > If we cannot achieve a cer
On 12/19/2011 08:27 PM, Jordan Justen wrote:
> On Sun, Dec 18, 2011 at 02:04, Avi Kivity wrote:
> > On 12/15/2011 11:02 PM, Jordan Justen wrote:
> >> I verified that 'info mtree' and 'info qdev' are equivalent for pc-1.0
> >> when using maste
On 12/20/2011 12:01 AM, Peter Maydell wrote:
> Add save/load support to the PL181.
>
> +VMSTATE_INT32(linux_hack, pl181_state),
>
Is this real state? Can't it be recovered somehow from other state?
--
error compiling committee.c: too many arguments to function
On 12/19/2011 06:45 PM, Peter Maydell wrote:
> Use the new memory mutator API to simplify the flash remap code;
> this allows us to drop the flash_mapped flag.
>
> This patch also fixes the sense of the REMAP bit, which was
> reversed.
>
I'm surprised the word "also" doesn't cause the maintainers'
(),
for registering a RAM block for migration. Currently the same
implementation is reused, but later it can be moved into a separate list,
and registrations can be moved to VMStateDescription blocks.
Avi Kivity (2):
memory: introduce memory_region_name()
vmstate, memory: decouple vmstate from
Trivial accessor for the name attribute.
Signed-off-by: Avi Kivity
---
memory.c |5 +
memory.h |9 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/memory.c b/memory.c
index a90eefd..93f9569 100644
--- a/memory.c
+++ b/memory.c
@@ -1108,6 +1108,11
On 12/20/2011 03:51 PM, Paolo Bonzini wrote:
> On 12/20/2011 02:41 PM, Anthony Liguori wrote:
>> On 12/20/2011 03:56 AM, Avi Kivity wrote:
>>> On 12/20/2011 02:38 AM, Anthony Liguori wrote:
>>>>> That was v1 of my patches. Avi didn't like it, I tried it like
On 12/20/2011 04:09 PM, Anthony Liguori wrote:
> On 12/20/2011 08:05 AM, Avi Kivity wrote:
>> Currently creating a memory region automatically registers it for
>> live migration. This differs from other state (which is enumerated
>> in a VMStateDescription structure) and ti
On 12/06/2011 07:25 PM, Paolo Bonzini wrote:
> is_dup_page is already proceeding in 32-bit chunks. Changing it to 16
> bytes using Altivec or SSE is easy, and provides a noticeable improvement.
> Pierre Riteau measured 30->25 seconds on a 16GB guest, I measured 4.6->3.9
> seconds on a 6GB guest (b
On 12/20/2011 05:51 PM, Peter Maydell wrote:
> On 20 December 2011 11:00, Avi Kivity wrote:
> > On 12/19/2011 06:45 PM, Peter Maydell wrote:
> >> Use the new memory mutator API to simplify the flash remap code;
> >> this allows us to drop the flash_mapped flag.
> >
On 12/20/2011 06:08 PM, Peter Maydell wrote:
> Use the new memory mutator API to simplify the flash remap code;
> this allows us to drop the flash_mapped flag.
>
>
> -static void integratorcm_do_remap(integratorcm_state *s, int flash)
> +static void integratorcm_do_remap(integratorcm_state *s)
>
On 12/21/2011 02:09 PM, Zhi Yong Wu wrote:
> HI,
>
> For memory management, i have several questions as below:
>
> 1.) Why is subpage introduced? what is its goal?
A TLB entry spans one page; a subpage is a way of dispatching accesses
through that tlb entry to various memory regions.
> 2.) How to
Version 3 ram_load depends on ram_addrs, which are not stable. Version 4
was introduced in 0.13 (and RHEL 6), so this means live migration from 0.12
and earlier to 1.1 or later will not work.
Signed-off-by: Avi Kivity
---
arch_init.c | 18 --
1 files changed, 4 insertions
Signed-off-by: Avi Kivity
---
arch_init.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 9b8a1f3..381c055 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -344,7 +344,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage,
void
These patches, on top of "vmstate, memory: decouple vmstate from memory API",
convert live migration to use the memory API.
Patch 4 is an ABI change, please review carefully.
Avi Kivity (8):
Store MemoryRegion in RAMBlock
Switch ram_save to the memory API
Sort RAMBlocks by ID for
The getter is no longer used, so it is completely removed.
Signed-off-by: Avi Kivity
---
arch_init.c |7 +++
cpu-all.h |4
exec-obsolete.h |2 ++
exec.c | 10 --
memory.c|2 ++
5 files changed, 7 insertions(+), 18 deletions(-)
diff
ram_addr is (a) unstable (b) going away. Sort by idstr instead.
Signed-off-by: Avi Kivity
---
arch_init.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 2743bfd..8a3f052 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -217,12
Avoid using ram_addr_t, instead use (MemoryRegion *, offset) pairs.
Signed-off-by: Avi Kivity
---
arch_init.c | 34 ++
1 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index ceef26e..2743bfd 100644
--- a/arch_init.c
As a step in moving live migration from RAMBlocks to MemoryRegions,
store the MemoryRegion in a RAMBlock.
Signed-off-by: Avi Kivity
---
cpu-all.h |1 +
exec.c|1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 734833a..4acaa8b 100644
Signed-off-by: Avi Kivity
---
xen-all.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index df70592..8f9db95 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -408,7 +408,6 @@ static int xen_sync_dirty_bitmap(XenIOState *state
No longer used outside memory.c and exec.c.
Signed-off-by: Avi Kivity
---
cpu-all.h | 49 -
exec-obsolete.h | 49 +
2 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/cpu
On 12/21/2011 03:55 PM, Anthony Liguori wrote:
> On 12/21/2011 07:34 AM, Avi Kivity wrote:
>> ram_addr is (a) unstable (b) going away. Sort by idstr instead.
>>
>> Signed-off-by: Avi Kivity
>
> I don't see this as a problem, per say, but this is a significant
>
On 12/21/2011 03:57 PM, Anthony Liguori wrote:
> On 12/21/2011 07:34 AM, Avi Kivity wrote:
>> Version 3 ram_load depends on ram_addrs, which are not stable.
>> Version 4
>> was introduced in 0.13 (and RHEL 6), so this means live migration
>> from 0.12
>> and earl
On 12/21/2011 11:10 PM, Peter Maydell wrote:
> On 21 December 2011 16:37, Mark Langsdorf wrote:
> > On 12/20/2011 01:48 PM, Peter Maydell wrote:
> >> This commit leaves the register with a reset value of 0, which
> >> isn't right (we only implement A9MP, not A9UP, so the reset value
> >> should be
On 12/22/2011 01:24 PM, Zhi Yong Wu wrote:
> >
> >> 2.) How to render MemoryRegion into one disjoint flatrange list? That
> >> rendering function is a bit difficult to understand. Can anyone simply
> >> explain it?
> >
> > What exactly don't you understand?
> 1.) e.g. some fields such as offset_in_
On 12/22/2011 02:37 PM, Peter Maydell wrote:
> On 22 December 2011 10:14, Avi Kivity wrote:
> > On 12/21/2011 11:10 PM, Peter Maydell wrote:
> >> Avi: is there a way for a device (sysbus device in this case) to
> >> find out for one of its memory regions where it
On 12/22/2011 02:48 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 19, 2011 at 04:13:41PM +0200, Avi Kivity wrote:
> > @@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev,
> > VirtIODevice *vdev)
> > hdev->vqs + i,
> >
On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> > +static void vhost_log_start(MemoryListener *listener,
> > +MemoryRegionSection *section)
> > +{
> > +/* FIXME: implement
On 12/22/2011 02:57 PM, Michael S. Tsirkin wrote:
> On Thu, Dec 22, 2011 at 02:50:27PM +0200, Avi Kivity wrote:
> > On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
> > > On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
> > > > +static void vhost_log_
On 12/19/2011 04:11 PM, Jan Kiszka wrote:
> >>
> >> Backwards compatibility
> >
> > If we want backwards compatibility, we need more than just a simple feature
> > check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave
> > like VMX/SVM do on real hardware - you always expose th
C99 appears to consider compound literals as non-constants, and complains
when they are used in static initializers. Switch to ordinary initializer
syntax.
Signed-off-by: Avi Kivity
---
fpu/softfloat-specialize.h |8
fpu/softfloat.h|2 ++
2 files changed, 6
On 12/27/2011 05:22 PM, Anthony Liguori wrote:
>
> The infrastructure assumes that you have a full OS available in the
> guest. The tests are written in Python and make a variety of
> assumptions. To my knowledge, it's not very practical to build a
> busybox environment with Python embedded in it
On 12/26/2011 04:58 PM, Peter Maydell wrote:
> >
> > void sd_enable(SDState *sd, int enable)
> > {
> > -sd->enable = enable;
> > +sd->enable = enable ? true : false;
>
> This kind of thing is why I don't like bool :-)
/me leaps to bool's defence:
sd->enable = enable should work just f
t
both are rather niche I think we can fix any issues in tree.
Michael did suggest making changes to vhost, but I prefer that he makes
them as he knows how to test.
Please pull from
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/page_desc
Avi Kivity (22):
s
vocation trashes a file
supposedly produced during the first, and now in use by a dependent command.
The various qapi code generators are susceptible to this; fix by making them
generate just one file per invocation.
Signed-off-by: Avi Kivity
---
Makefile
reakage in virtio_balloon.
Avi Kivity (22):
sysbus: add sysbus_address_space()
memory: add memory_region_is_ram()
memory: add memory_region_is_rom()
memory: add memory_region_is_logging()
memory: introduce memory_region_find()
framebuffer: drop use of cpu_get_physical
On 12/27/2011 11:30 PM, Peter Maydell wrote:
> On 27 December 2011 14:13, Avi Kivity wrote:
> > On 12/26/2011 04:58 PM, Peter Maydell wrote:
> >> > void sd_enable(SDState *sd, int enable)
> >> > {
> >> > -sd->enable = enable;
> >>
were hidden by a makefile bug which caused the
old behaviour (with the race) to be invoked.
Signed-off-by: Avi Kivity
---
Makefile |2 +-
scripts/qapi-commands.py | 12
scripts/qapi-types.py| 12 +---
scripts/qapi-visit.py| 12 +---
4
On 12/28/2011 01:12 AM, Xin Tong wrote:
> QEMU does not exit and handle interrupt within translation blocks. it
> only exits after the translation block is finished. Assuming a
> translation block is very long, is it possible that QEMU could have
> exceeded the interrupt's "timing window" and yield
On 12/28/2011 01:40 PM, Peter Maydell wrote:
> On 28 December 2011 10:42, Avi Kivity wrote:
> > It's possible to check for an interrupt before every instruction,
> > without any overhead:
> >
> > - when a signal arrives, check the instruction pointer. If it points
On 12/28/2011 04:27 PM, Anthony Liguori wrote:
>> Maybe I've used the wrong wording. I got the feeling that, besides
>> testing qemu
>> the way you need it, keeping qemu-test simple was really important.
>
>
> Simple is always important. In the case of qemu-test, there are some
> important trade o
On 12/28/2011 05:01 PM, Avi Kivity wrote:
> I'd say that running a ping test is a weak version of kvm-autotest's
> system tests. Running a synthetic test that pokes values into memory
> and mmio and sees a packet coming out is a unit test (the latter can in
> fact be execu
On 12/28/2011 06:42 PM, Anthony Liguori wrote:
>> In fact using linux as a guest negates that. First of all, which linux
>> version? if it's fixed, you'll eventually miss functionality and need to
>> migrate. If it keeps changing, so does your test, and it will keep
>> breaking.
>
>
> The kernel
On 12/28/2011 06:44 PM, Anthony Liguori wrote:
> On 12/28/2011 09:28 AM, Avi Kivity wrote:
>> On 12/28/2011 05:01 PM, Avi Kivity wrote:
>>> I'd say that running a ping test is a weak version of kvm-autotest's
>>> system tests. Running a synthetic test that
On 12/29/2011 06:07 PM, Dor Laor wrote:
> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>>
>>>> btw you can get an additional speedup by enabling x2apic, for
>>>> default_send_IPI_mask_logical().
>>
On 12/29/2011 07:36 PM, Peter Maydell wrote:
> On 29 December 2011 17:26, Avi Kivity wrote:
> > On 12/29/2011 07:22 PM, Peter Maydell wrote:
> >> I think for devices what would be particularly useful would be
> >> if you can write a (simple) test for something at the
On 12/29/2011 02:39 PM, Isaku Yamahata wrote:
> > > ioctl commands:
> > >
> > > UMEM_DEV_CRATE_UMEM: create umem device for qemu
> > > UMEM_DEV_LIST: list created umem devices
> > > UMEM_DEV_REATTACH: re-attach the created umem device
> > > UMEM_DEV_LIST and UMEM_DEV_REATTACH are used w
On 12/29/2011 07:16 PM, Anthony Liguori wrote:
>> Would there be device-level tests in qemu-test?
>
>
> qemu-jeos has a kernel build environment for the target so it is also
> possible to build userspace C programs and/or kernel modules so you
> could also write guest tests in C.
>
> So it may actu
On 12/29/2011 04:49 PM, Isaku Yamahata wrote:
> > > Great, then we agreed with list/reattach basically.
> > > (Maybe identity scheme needs reconsideration.)
> >
> > I guess we miscommunicated. Why is reattach needed? If you have the
> > fd, nothing else is needed.
>
> What if malicious process c
On 12/29/2011 06:26 PM, Anthony Liguori wrote:
> On 12/28/2011 11:21 AM, Avi Kivity wrote:
>> On 12/28/2011 06:42 PM, Anthony Liguori wrote:
>>>> In fact using linux as a guest negates that. First of all, which
>>>> linux
>>>> version? if it'
On 12/29/2011 06:00 PM, Avi Kivity wrote:
> The NFS client has exactly the same issue, if you mount it with the intr
> option. In fact you could use the NFS client as a trivial umem/cuse
> prototype.
Actually, NFS can return SIGBUS, it doesn't care about restarting daemons.
--
e
On 12/29/2011 07:10 PM, Anthony Liguori wrote:
> On 12/29/2011 11:03 AM, Avi Kivity wrote:
>> On 12/29/2011 06:49 PM, Anthony Liguori wrote:
>>>> However, I don't think it's even necessary. From a quick read of the
>>>> manual, SMBIOS is just a set of st
On 12/29/2011 06:49 PM, Anthony Liguori wrote:
> On 12/29/2011 10:36 AM, Avi Kivity wrote:
>> On 12/29/2011 06:12 PM, Anthony Liguori wrote:
>>>>> That's why I've also proposed qtest. But having written quite a few
>>>>> qtest unit tests b
On 12/29/2011 02:22 PM, Isaku Yamahata wrote:
> >
> > A simpler approach is the open("/dev/umem") returns an mmap()able fd.
> > You need to call an ioctl() to set the size, etc. but only you only
> > operate on that fd.
>
> So you are suggesting that /dev/umem and /dev/umemctl should be introduce
On 12/29/2011 05:53 PM, Isaku Yamahata wrote:
> On Thu, Dec 29, 2011 at 04:55:11PM +0200, Avi Kivity wrote:
> > On 12/29/2011 04:49 PM, Isaku Yamahata wrote:
> > > > > Great, then we agreed with list/reattach basically.
> > > > > (Maybe identity scheme nee
On 12/29/2011 03:26 AM, Isaku Yamahata wrote:
> This patch implements postcopy livemigration.
>
>
> +/* RAM is allocated via umem for postcopy incoming mode */
> +#define RAM_POSTCOPY_UMEM_MASK (1 << 1)
> +
> typedef struct RAMBlock {
> uint8_t *host;
> ram_addr_t offset;
> @@ -485,6
On 12/29/2011 07:22 PM, Peter Maydell wrote:
> On 29 December 2011 16:36, Avi Kivity wrote:
> > Yes; but using Linux limits you to what it exposes (of course Linux
> > exposes quite a lot, so that's mostly a non issue; but we'll have
> > counterexamples).
&
On 12/29/2011 06:12 PM, Anthony Liguori wrote:
>>> That's why I've also proposed qtest. But having written quite a few
>>> qtest unit tests by now, you hit the limits of this type of testing
>>> pretty quickly.
>>
>> Can you describe those limits?
>
>
> I started writing a finger print test. Whil
On 12/29/2011 06:39 PM, Anthony Liguori wrote:
>
> qemu-test builds a custom guest, entirely from source. This makes it
> possible to efficiently test non-native architectures. The tests are
> written for this minimal environment (which is not straight forward to
> do). This tests will never run
On 12/29/2011 07:02 PM, Anthony Liguori wrote:
>
> Those are rare occurrences and have always been a bit awkward. OTOH,
> we're talking about the critical path of essentially every single
> feature that gets merged into QEMU.
>
Won't that be qtest?
Major features are rare. Small changes are com
On 12/29/2011 03:49 PM, Isaku Yamahata wrote:
> >
> > qemu can have an extra thread that wait4()s the daemon, and relaunch
> > it. This extra thread would not be blocked by the page fault. It can
> > keep the fd so it isn't lost.
> >
> > The unkillability of process A is a security issue; it co
601 - 700 of 4803 matches
Mail list logo
