On Thu, Dec 29, 2011 at 4:17 PM, Andreas Färber wrote:
> Am 29.12.2011 08:55, schrieb Khansa Butt:
>> On Fri, Dec 9, 2011 at 5:04 AM, Andreas Färber
>> wrote:
+ /* if cpu has FPU, MIPS_HFLAG_F64 must be included in env->hflags
+ so that floating point operations can be emulate
>> >There are two main things we can do:
>> >1. Make the 64 bit device only use the low 32 bit
>> It was my first implementation. Unfortunately older versions of
>> Linux (Like 2.6.18) hang during startup with this.
>> As far as I remember it was qemu-0.15 so may be 1.0 have no such an
>> issue.
On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
> On 29/12/11 00:43, Michael S. Tsirkin wrote:
> >On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
> >>All devices behind a bridge need to have all their regions consecutive and
> >>not overlapping with all the normal me
On Fri, Dec 30, 2011 at 06:10:13PM +1300, Alexey Korolev wrote:
> On 30/12/11 05:21, Michael S. Tsirkin wrote:
> >On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
> >>>Can't figure this out. What does this do?
> >>Bios will panic if it founds prefmem BARs in both 32bit and 64bit area
On Thu, Dec 29, 2011 at 06:00:04PM +1300, Alexey Korolev wrote:
> On 29/12/11 15:56, Kevin O'Connor wrote:
> >On Wed, Dec 28, 2011 at 06:26:05PM +1300, Alexey Korolev wrote:
> >>--- a/src/pciinit.c
> >>+++ b/src/pciinit.c
> >>@@ -22,6 +22,7 @@ enum pci_region_type {
> >> PCI_REGION_TYPE_IO,
>
On 30/12/11 05:21, Michael S. Tsirkin wrote:
On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
Can't figure this out. What does this do?
Bios will panic if it founds prefmem BARs in both 32bit and 64bit areas.
That's not good, it's a legal configuration.
To be more complete : Bi
On 30/12/11 05:21, Michael S. Tsirkin wrote:
On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
Can't figure this out. What does this do?
Bios will panic if it founds prefmem BARs in both 32bit and 64bit areas.
That's not good, it's a legal configuration.
To be more complete : Bi
On Wed, Dec 28, 2011 at 01:43:02PM +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
> > All devices behind a bridge need to have all their regions consecutive and
> > not overlapping with all the normal memory ranges.
> > Since prefetchable memory i
On 30/12/11 05:18, Michael S. Tsirkin wrote:
On Thu, Dec 29, 2011 at 06:40:26PM +1300, Alexey Korolev wrote:
On 29/12/11 00:43, Michael S. Tsirkin wrote:
On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
All devices behind a bridge need to have all their regions consecutive and
n
Hi, kemari is a good job but I wonder why you chose "event-driven"? The
interval between synchronization maybe out of control, maybe very long if there
is a CPU-intensive task without any IO or maybe too frequent if there is a net
pressure test.
Why not synchronize periodically? Thanks!
DANIEL CATALIN COROZEL
C/ Arzobispo Carrillo,Nº3 ,4ºB
28803 Alcala de Henares (Madrid)
Telefonos: 697 524 592
Correo electronico:tucumineimpre...@yahoo.com
NIE: X-06862287-F
FORMACION ACADEMICA
1999-2002
Curso de CONSTRUCTION (Pintura ,alicatado, solado y albañile
On 12/29/2011 10:20 PM, Lucas Meneghel Rodrigues wrote:
On 12/29/2011 10:33 PM, Anthony Liguori wrote:
So I decided to do some snooping. Here are some stats:
anthony@titi:~/git/autotest/client/tests/kvm/tests$ wc -l *.py
150 balloon_check.py
68 boot_savevm.py
190 cdrom.py
1875 cgroup.py
111 cpu
On 12/29/2011 10:33 PM, Anthony Liguori wrote:
So I decided to do some snooping. Here are some stats:
anthony@titi:~/git/autotest/client/tests/kvm/tests$ wc -l *.py
150 balloon_check.py
68 boot_savevm.py
190 cdrom.py
1875 cgroup.py
111 cpu_hotplug.py
170 enospc.py
71 floppy.py
72 getfd.py
89 hdp
On 12/29/2011 05:17 PM, Lucas Meneghel Rodrigues wrote:
On 12/29/2011 03:02 PM, Anthony Liguori wrote:
On 12/29/2011 10:53 AM, Avi Kivity wrote:
On 12/29/2011 06:39 PM, Anthony Liguori wrote:
It might have made sense to split the kvm-testing functionality of
autotest, and have autotest drive t
On 12/29/2011 03:02 PM, Anthony Liguori wrote:
On 12/29/2011 10:53 AM, Avi Kivity wrote:
On 12/29/2011 06:39 PM, Anthony Liguori wrote:
It might have made sense to split the kvm-testing functionality of
autotest, and have autotest drive that. We could even have called it
qemu-test.
I specific
On 12/29/2011 12:38 PM, Dor Laor wrote:
From the recent threads it looks to me that the 2 advantages of
qemu-test over kvm-autotest are:
1. python is not used within the guest
^ Just a (relatively small) subset of KVM autotest tests do require
python in the guest (the ones that execute the a
On 12/28/2011 07:25 PM, Isaku Yamahata wrote:
Intro
=
This patch series implements postcopy live migration.[1]
As discussed at KVM forum 2011, dedicated character device is used for
distributed shared memory between migration source and destination.
Now we can discuss/benchmark/compare with p
On 12/29/2011 04:10 PM, Peter Maydell wrote:
On 29 December 2011 21:46, Anthony Liguori wrote:
But 0% test coverage is absolutely not enough. So the first step is to get
an infrastructure together that we can all live with and start writing
tests.
Agreed.
How does your framework deal with n
On 30/12/11 05:21, Michael S. Tsirkin wrote:
On Thu, Dec 29, 2011 at 09:20:00AM +, Alexey Korolev wrote:
Patches have been tested on several configurations which includes
linux 2.6.18 - 3.0&
windows 2008. Everything works quite well.
Which qemu version did you use?
I tried both 0.15 and 1
On 12/29/2011 05:04 PM, Peter Maydell wrote:
On 29 December 2011 18:35, Anthony Liguori wrote:
On 12/29/2011 11:49 AM, Peter Maydell wrote:
The next obvious question is: are we going to make a serious attempt?
(For instance, in a hypothetical tests-required world, would we
tell those nice folk
On 29 December 2011 21:46, Anthony Liguori wrote:
> But 0% test coverage is absolutely not enough. So the first step is to get
> an infrastructure together that we can all live with and start writing
> tests.
Agreed.
How does your framework deal with non-x86 targets? Finding and
installing a wo
On 12/29/2011 01:04 PM, Peter Maydell wrote:
On 29 December 2011 18:35, Anthony Liguori wrote:
On 12/29/2011 11:49 AM, Peter Maydell wrote:
The next obvious question is: are we going to make a serious attempt?
(For instance, in a hypothetical tests-required world, would we
tell those nice folk
On 29 December 2011 17:56, Avi Kivity wrote:
> On 12/29/2011 07:49 PM, Peter Maydell wrote:
>> I suspect that if we set the bar for new board and device models
>> that high then the result will largely be that we don't in fact
>> get new board or device models.)
>
> If just doubles the effort, I d
I've been dealing with this bug for some time on Fedora. Until
recently, I was using the VirtIO drivers from RHEV 2.2, which don't
suffer from this problem. As of Fedora 16, however, that isn't an
option, because they cause the guest to blue-screen early in the boot
process.
So ... I've been doi
On Thu, Dec 29, 2011 at 19:04, Peter Maydell wrote:
> On 29 December 2011 18:35, Anthony Liguori wrote:
>> On 12/29/2011 11:49 AM, Peter Maydell wrote:
>>> The next obvious question is: are we going to make a serious attempt?
>>> (For instance, in a hypothetical tests-required world, would we
>>>
On 29 December 2011 18:35, Anthony Liguori wrote:
> On 12/29/2011 11:49 AM, Peter Maydell wrote:
>> The next obvious question is: are we going to make a serious attempt?
>> (For instance, in a hypothetical tests-required world, would we
>> tell those nice folks from Samsung "no you can't land your
On 12/29/2011 11:40 AM, Peter Maydell wrote:
On 1 December 2011 18:43, Anthony Liguori wrote:
This involves forcing the CPU into the halted state if qtest is enabled and
replacing the local APIC with the qtest interrupt controller.
It should be pretty straight forward to do the same for other
Jan Kiszka wrote:
> On 2011-12-28 18:35, Liu, Jinsong wrote:
diff --git a/qemu-kvm.h b/qemu-kvm.h
index 2bd5602..8c6c2ea 100644
--- a/qemu-kvm.h
+++ b/qemu-kvm.h
@@ -260,6 +260,7 @@ extern int kvm_irqchip;
extern int kvm_pit;
extern int kvm_pit_reinject;
e
On 12/29/2011 11:49 AM, Peter Maydell wrote:
On 29 December 2011 17:26, Avi Kivity wrote:
On 12/29/2011 07:22 PM, Peter Maydell wrote:
My guess is that a serious attempt at tests covering all the
functionality of a device is probably approximately doubling
the effort required for a device mode
On 12/29/2011 11:22 AM, 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).
Actually IME Linux is pretty conservative about how
On 12/29/2011 11:22 AM, Avi Kivity wrote:
On 12/29/2011 07:14 PM, Anthony Liguori wrote:
On 12/29/2011 11:08 AM, Avi Kivity wrote:
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
I firmly
On 12/29/2011 07:49 PM, Peter Maydell wrote:
> On 29 December 2011 17:26, Avi Kivity wrote:
> > On 12/29/2011 07:22 PM, Peter Maydell wrote:
> >> My guess is that a serious attempt at tests covering all the
> >> functionality of a device is probably approximately doubling
> >> the effort required
On 29 December 2011 17:26, Avi Kivity wrote:
> On 12/29/2011 07:22 PM, Peter Maydell wrote:
>> My guess is that a serious attempt at tests covering all the
>> functionality of a device is probably approximately doubling
>> the effort required for a device model, incidentally. A
>> half-hearted att
On 1 December 2011 18:43, Anthony Liguori wrote:
> This involves forcing the CPU into the halted state if qtest is enabled and
> replacing the local APIC with the qtest interrupt controller.
>
> It should be pretty straight forward to do the same for other machine types on
> other architectures.
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 register
> >> level, which gen
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 register
>> level, which generates an image which you can run on the real
>> hardwa
Git commit 8d3bc51 crashes on win32 on startup because qemu_tcg_init_vcpu
calls:
qemu_thread_create(th, qemu_tcg_cpu_thread_fn, ...
...
qemu_thread_get_handle(th)
which locks th->data->cs, a CRITICAL_SECTION which is initialized only in
the thread_fn, so it finds garbage.
Attached patch initiali
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).
>
> Actually IME Linux is pretty conservat
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 07:14 PM, Anthony Liguori wrote:
> On 12/29/2011 11:08 AM, Avi Kivity wrote:
>> On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
>>>
>>>
>>> I firmly believe that with qtes
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).
Actually IME Linux is pretty conservative about how it uses devices.
A lot of the ARM device m
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 static tables in memory which are
picked
sa_flags is uint32_t for mips{,n32,64}, so don't use tswapal().
Reported-by: Khansa Butt
Suggested-by: Richard Henderson
Signed-off-by: Andreas Färber
Cc: Ehsan Ul Haq
---
linux-user/signal.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/linux-user/signal.c b
On 12/29/2011 11:08 AM, Avi Kivity wrote:
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
I firmly believe that with qtest we'll end up eventually building a
libOS to make it easier to writ
Hello,
Here's a suggestion for moving forward with mipsn32 and mips64.
For testing add the following to your --target-list:
mips-linux-user
mipsel-linux-user
mipsn32-linux-user
mipsn32el-linux-user
mips64-linux-user
mips64el-linux-user
Patches 1-4 are trivial and hopefully uncontroversial prepara
Signed-off-by: Andreas Färber
---
linux-user/signal.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index bd13f9b..b33f8cb 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2678,7 +2678,7 @@ long do_rt_sigreturn(
Mostly adapted from o32.
Linux no longer seems to have sf_code/rs_code for any of the ABIs.
It's u32 {sf,rt}_pad[2] /* Was: signal trampoline */ now...
Signed-off-by: Andreas Färber
Cc: Richard Henderson
Cc: Khansa Butt
---
linux-user/signal.c | 104 ++
On Thu, Dec 29, 2011 at 09:20:00AM +, Alexey Korolev wrote:
> >>
> > Patches have been tested on several configurations which includes
> >> linux 2.6.18 - 3.0 &
> >> windows 2008. Everything works quite well.
>
> >Which qemu version did you use?
> I tried both 0.15 and 1.0
qemu or qemu-kcm?
On 12/29/2011 11:08 AM, Avi Kivity wrote:
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?
I firmly believe that with qtest we'll end up eventually building a
libOS to make it easier to writ
On 12/29/2011 11:06 AM, Avi Kivity wrote:
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?
The diff
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 static tables in memory which are picked
up using a signature. So all we need to do is boot an empty gue
On 12/29/2011 06:53 PM, Anthony Liguori wrote:
>> In what way is your specifically configured kernel's TCP stack better
>> than the random distro's kernel's?
>
>
> I firmly believe that with qtest we'll end up eventually building a
> libOS to make it easier to write qtest tests.
>
> Overtime, that
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 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 by now, you hit the limits of this type of testing
> pre
On 12/29/2011 10:53 AM, Avi Kivity wrote:
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 forwar
This adds very basic support for XG-mac ethernet core from Synopsis and
others. Missing things include:
- statistics counters
- WoL support
- rx checksum offload
- chained descriptors (only linear descriptor ring)
- broadcast and multicast handling
Signed-off-by: Rob Herring
Signed-off-by: Mark
Increase the maximum number of GIC interrupts for a9mp and a11mp to 256,
and create a configurable property for each defaulting to 96 and 64
(respectively) so that device modelers can set the value appropriately
for their SoC. Other ARM processors also set their maximum number of
used IRQs appropri
From: Rob Herring
Add power control register to a9mpcore
Signed-off-by: Rob Herring
Signed-off-by: Mark Langsdorf
Reviewed-by: Peter Maydell
---
Changes from v3, v4
None
Changes from v2:
Better handling of byte and halfword writes to the power register
Correct handling
This is a collection of fixes and additions to the models for various
ARM devices. These changes are needed to support the forthcoming
Calxeda Highbank SoC model.
Makefile.target |2 +
hw/a9mpcore.c | 43 +-
hw/arm11mpcore.c| 14 +-
hw/arm_gic.c| 63 +---
Add a cp15 config_base_register that currently defaults to 0.
After the QOM CPU support is added, the value will be properly
set to the periphal base value.
Signed-off-by: Mark Langsdorf
Reviewed-by: Peter Maydell
---
Changes from v3, v4
None
Changes from v2
Added test against op
Signed-off-by: Andreas Färber
Cc: Richard Henderson
---
linux-user/signal.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index a713cb2..bd13f9b 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2487,6 +2487,9
From: Rob Herring
This is just a dummy device for ARM L2 cache controllers, based on the
pl310. The cache type parameter can be defined by a property value
and has a meaningful default.
Signed-off-by: Rob Herring
Signed-off-by: Mark Langsdorf
---
Changes from v4
Handling cache_type bit
On 12/29/2011 10:46 AM, Avi Kivity wrote:
On 12/29/2011 06:26 PM, Anthony Liguori wrote:
I don't want to write a TCP/IP stack. We aren't just grabbing a
random distro kernel. We're building one from scratch configured in a
specific way.
How does that help?
Not sure I understand the questio
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
Shared for n32/n64 in arch/mips/kernel/signal.c;
o32 version in arch/mips/kernel/signal32.c.
Signed-off-by: Andreas Färber
Cc: Richard Henderson
Cc: Khansa Butt
---
linux-user/signal.c | 204 +-
1 files changed, 102 insertions(+), 102 deletions(
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 by now, you hit the limits of this type of testing
pretty quickly.
Can you describe those limits?
I started writing
Prepares for mips64[el]-linux-user targets.
Signed-off-by: Khansa Butt
Signed-off-by: Andreas Färber
---
default-configs/mips64-linux-user.mak |1 +
default-configs/mips64el-linux-user.mak |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 default-configs/mips6
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's fixed, you'll eventually miss functionality and
n
On 12/29/2011 08:38 AM, Dor Laor wrote:
On 12/28/2011 07:21 PM, Avi Kivity wrote:
Would you add live migration testing to qemu-test? If yes, you're
duplicating some more. If not, you're not doing functional or coverage
tests for that functionality.
From the recent threads it looks to me that
Use qdev properties to allow board modelers to set the frequencies
for the sp804 timer. Each of the sp804's timers can have an
individual frequency. The timers default to 1MHz.
Signed-off-by: Mark Langsdorf
Reviewed-by: Peter Maydell
Reviewed-by: Andreas Färber
---
Changes from v3, v4
N
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
From: Rob Herring
Implement handling for the RAZ/WI gic security registers.
Signed-off-by: Rob Herring
Signed-off-by: Mark Langsdorf
Reviewed-by: Peter Maydell
---
Changes from v2, v3, v4
None
Changes from v1
Moved handling back inside the 0-0x100 block
Added more clar
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's fixed, you'll eventually miss functionality and need to
migrate. If it keeps changing, so does your test, and it will
Copied from mips/syscall.h.
Signed-off-by: Ulrich Hecht
Signed-off-by: Andreas Färber
---
linux-user/mipsn32/syscall.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/linux-user/mipsn32/syscall.h b/linux-user/mipsn32/syscall.h
index 4ec506c..ebe98f2 100644
--- a/linux
On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
> >Can't figure this out. What does this do?
> Bios will panic if it founds prefmem BARs in both 32bit and 64bit areas.
That's not good, it's a legal configuration.
> Otherwise we will pick one which exists or 32bit one if both are n
On Thu, Dec 29, 2011 at 06:32:37PM +1300, Alexey Korolev wrote:
>
> >>@@ -69,6 +72,8 @@ static enum pci_region_type pci_addr_to_type(u32 addr)
> >> {
> >> if (addr& PCI_BASE_ADDRESS_SPACE_IO)
> >> return PCI_REGION_TYPE_IO;
> >>+if (addr& PCI_BASE_ADDRESS_MEM_TYPE_64)
> >>+
On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
> On 29/12/11 00:43, Michael S. Tsirkin wrote:
> >On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
> >>All devices behind a bridge need to have all their regions consecutive and
> >>not overlapping with all the normal me
On Thu, Dec 29, 2011 at 06:40:26PM +1300, Alexey Korolev wrote:
> On 29/12/11 00:43, Michael S. Tsirkin wrote:
> >On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
> >>All devices behind a bridge need to have all their regions consecutive and
> >>not overlapping with all the normal me
On 12/29/2011 10:07 AM, 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().
In the host?
In the host, for the guest:
qemu -cpu ...,+x2apic
Based on arch/mips/include/asm/sigcontext.h.
Signed-off-by: Andreas Färber
Cc: Richard Henderson
Cc: Khansa Butt
---
linux-user/signal.c | 64 ++
1 files changed, 43 insertions(+), 21 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/
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().
>>> In the host?
>>>
>>
>> In the host, for the
On 12/28/2011 11:26 AM, Avi Kivity wrote:
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 pokes v
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().
In the host?
In the host, for the guest:
qemu -cpu ...,+x2apic
It seems to me that we should impro
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 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.
--
error compiling c
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 needs reconsideration.)
> > > >
> > > > I gue
As suggested by Richard.
Signed-off-by: Andreas Färber
Cc: Richard Henderson
Cc: Khansa Butt
---
linux-user/signal.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index bafbc57..394984d 100644
--- a/linux-user/signal.c
+++
Prepares for mipsn32[el]-linux-user targets.
Signed-off-by: Ulricht Hecht
Signed-off-by: Andreas Färber
---
default-configs/mipsn32-linux-user.mak |1 +
default-configs/mipsn32el-linux-user.mak |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 default-configs/
Copied from mips/syscall.h.
Signed-off-by: Khansa Butt
Signed-off-by: Andreas Färber
---
linux-user/mips64/syscall.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/linux-user/mips64/syscall.h b/linux-user/mips64/syscall.h
index 668a2b9..e436ea5 100644
--- a/linux-use
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 needs reconsideration.)
> > >
> > > I guess we miscommunicated. Why is reattach needed? If you ha
On 29/12/11 15:56, Amit Shah wrote:
> On (Thu) 29 Dec 2011 [15:32:14], Christian Borntraeger wrote:
>>> port->throttled never becomes true for qemu.
>>
>> Huh? What did I miss below?
>>
>> if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
>> virtio_serial_throttle_
On (Thu) 29 Dec 2011 [15:32:14], Christian Borntraeger wrote:
> > port->throttled never becomes true for qemu.
>
> Huh? What did I miss below?
>
> if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
> virtio_serial_throttle_port(port, true);
Ah; I see what's happe
On (Thu) 29 Dec 2011 [15:32:14], Christian Borntraeger wrote:
> > port->throttled never becomes true for qemu.
>
> Huh? What did I miss below?
>
> if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
> virtio_serial_throttle_port(port, true);
'ret' here is the retu
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 Thu, Dec 29, 2011 at 04:35:36PM +0200, Avi Kivity wrote:
> On 12/29/2011 04:18 PM, Isaku Yamahata wrote:
> > > >
> > > > The issue is how to solve the page fault, not whether
> > > > TASK_INTERRUPTIBLE or
> > > > TASK_UNINTERRUPTIBLE.
> > > > I can think of several options.
> > > > - When daemo
On 12/28/2011 07:21 PM, Avi Kivity wrote:
I think you're advocating for qtest. This is another important part
> of my testing strategy. I haven't received a lot of input on that RFC...
>
> http://mid.gmane.org/1322765012-3164-1-git-send-email-aligu...@us.ibm.com
>
> But there's certain thing
On 12/29/2011 04:18 PM, Isaku Yamahata wrote:
> > >
> > > The issue is how to solve the page fault, not whether TASK_INTERRUPTIBLE
> > > or
> > > TASK_UNINTERRUPTIBLE.
> > > I can think of several options.
> > > - When daemon X is dead, all page faults are served by zero pages.
> > > - When daemon
> port->throttled never becomes true for qemu.
Huh? What did I miss below?
if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
virtio_serial_throttle_port(port, true);
|
On (Thu) 29 Dec 2011 [15:16:55], Christian Borntraeger wrote:
> >> +++ b/hw/virtio-serial-bus.c
> >> @@ -163,7 +163,19 @@ static void do_flush_queued_data(VirtIOS
> >> abort();
> >> }
> >> if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
> >> -
1 - 100 of 123 matches
Mail list logo
