install rules to install kvmtrace and kvmtrace_format, but it
would be interesting to add such rules later. They could replace the PREFIX
definition with the prefix set by ./configure.
Signed-off-by: Eduardo Habkost
---
kvm/user/kvmtrace_format | 13 +
1 files changed, 9 insertions
On Tue, Jul 10, 2012 at 11:39:57AM +0300, Dor Laor wrote:
> On 07/01/2012 06:08 PM, Michael S. Tsirkin wrote:
> >Support the new PV EOI flag in kvm - it recently got merged
> >into kvm.git. Set by default with -cpu kvm.
> >Set for -cpu qemu by adding +kvm_pv_eoi.
> >Clear by adding -kvm_pv_eoi to -
ID 255 (0xFF) is reserved for broadcast).
That means that depending on core/thread topology, we may have an even
smaller limit.
(But that will be a problem only after we fix the APIC-ID CPU topology
bug we have)
>
>
[...]
> Signed-off-by: Chegu Vinod , Jim Hull ,
> Craig Hada
&g
On Fri, Jul 13, 2012 at 03:03:46AM +0300, Michael S. Tsirkin wrote:
> On Tue, Jul 10, 2012 at 09:55:08AM -0300, Eduardo Habkost wrote:
> > On Tue, Jul 10, 2012 at 11:39:57AM +0300, Dor Laor wrote:
> > > On 07/01/2012 06:08 PM, Michael S. Tsirkin wrote:
> > > >Supp
On Mon, Jul 16, 2012 at 09:31:30PM -0700, Chegu Vinod wrote:
> Changes since v3:
>- using bitmap_set() instead of set_bit() in numa_add() routine.
>- removed call to bitmak_zero() since bitmap_new() also zeros' the bitmap.
>- Rebased to the latest qemu.
Tested-by
On Mon, Jul 30, 2012 at 09:34:05AM +0200, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.
- 1.2 plans for CPU model versioning/compatibility
(global properties vs QOM vs qdev)
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscr
upstream (or)
> suggest who I should talk to get these changes in ?
>
> Thanks!
> Vinod
>
> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Wednesday, July 18, 2012 10:15 AM
> To: Vinod, Chegu
> Cc: qemu-de...@nongnu.org; aligu...
On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
> - 1.2 plans for CPU model versioning/compatibility (eduardo)
> (global properties vs QOM vs qdev)
> how to do it ? configuration file? moving back to the code?
> different external interface from internal one
(CCing libvir-li
On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
> - 1.2 plans for CPU model versioning/compatibility (eduardo)
> (global properties vs QOM vs qdev)
> how to do it ? configuration file? moving back to the code?
> different external interface from internal one
Another question
On Tue, Aug 28, 2012 at 12:54:54AM +0200, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.
- *-user and qdev (recent RFCs didn't get many comments in the list, and
I don't see a conclusion);
- 1.2 branching, or creation of a "cpu-next" tree where
On Tue, Aug 28, 2012 at 03:43:17PM +0200, Juan Quintela wrote:
> Eduardo Habkost wrote:
> > On Tue, Aug 28, 2012 at 12:54:54AM +0200, Juan Quintela wrote:
> >>
> >> Hi
> >>
> >> Please send in any agenda items you are interested in covering.
>
On Tue, Aug 28, 2012 at 02:55:56PM +0100, Peter Maydell wrote:
> On 28 August 2012 14:30, Eduardo Habkost wrote:
> > - 1.2 branching, or creation of a "cpu-next" tree where "good to be
> > merged" patches can live until 1.2 is done;
>
> With 1.3 due
On Tue, Aug 28, 2012 at 07:59:47PM +0200, Andreas Färber wrote:
> Am 28.08.2012 16:27, schrieb Eduardo Habkost:
> > On Tue, Aug 28, 2012 at 02:55:56PM +0100, Peter Maydell wrote:
> >> On 28 August 2012 14:30, Eduardo Habkost wrote:
> >>> - 1.2 branching, or creat
On Tue, Aug 28, 2012 at 08:43:52PM +0300, Michael S. Tsirkin wrote:
> In preparation for adding PV EOI support, disable PV EOI by default for
> 1.1 and older machine types, to avoid CPUID changing during migration.
>
> PV EOI can still be enabled/disabled by specifying it explicitly.
> Enable
On Tue, Aug 28, 2012 at 02:15:30PM -0500, Anthony Liguori wrote:
> Eduardo Habkost writes:
>
> > On Tue, Aug 28, 2012 at 07:59:47PM +0200, Andreas Färber wrote:
> >> Am 28.08.2012 16:27, schrieb Eduardo Habkost:
> >> > On Tue, Aug 28, 2012 at 02:55:56PM +0100, P
On Tue, Aug 28, 2012 at 02:13:18PM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
> > In preparation for adding PV EOI support, disable PV EOI by default for
> > 1.1 and older machine types, to avoid CPUID changing during migration.
> >
> > PV EOI can still be enabled/disabled by
On Wed, Aug 29, 2012 at 12:35:28AM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 28, 2012 at 04:13:38PM -0300, Eduardo Habkost wrote:
> > On Tue, Aug 28, 2012 at 08:43:52PM +0300, Michael S. Tsirkin wrote:
> > > In preparation for adding PV EOI support, disable PV EOI by default
On Wed, Aug 29, 2012 at 01:25:35AM +0300, Michael S. Tsirkin wrote:
> On Wed, Aug 29, 2012 at 01:21:13AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Aug 28, 2012 at 07:02:42PM -0300, Eduardo Habkost wrote:
> > > On Wed, Aug 29, 2012 at 12:35:28AM +0300, Michael S. Tsirkin wro
On Wed, Aug 29, 2012 at 01:06:32PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 28, 2012 at 08:50:09PM -0300, Eduardo Habkost wrote:
> > On Wed, Aug 29, 2012 at 01:25:35AM +0300, Michael S. Tsirkin wrote:
> > > On Wed, Aug 29, 2012 at 01:21:13AM +0300, Michael S. Tsirkin wro
On Wed, Aug 29, 2012 at 04:18:12PM +0300, Michael S. Tsirkin wrote:
> On Wed, Aug 29, 2012 at 09:56:12AM -0300, Eduardo Habkost wrote:
> > On Wed, Aug 29, 2012 at 01:06:32PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Aug 28, 2012 at 08:50:09PM -0300, Eduardo Habkost wrote:
&
On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" writes:
>
> > In preparation for adding PV EOI support, disable PV EOI by default for
> > 1.1 and older machine types, to avoid CPUID changing during migration.
> >
> > PV EOI can still be enabled/disabled by
On Wed, Aug 29, 2012 at 05:11:12PM +0300, Michael S. Tsirkin wrote:
> On Wed, Aug 29, 2012 at 10:49:04AM -0300, Eduardo Habkost wrote:
> > > Normally CPUID will tell you if such important MSR is available.
> > > So we can check that at destination.
> >
> > How ca
On Wed, Aug 29, 2012 at 09:09:16AM -0500, Anthony Liguori wrote:
> Gleb Natapov writes:
>
> > On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > In preparation for adding PV EOI support, disable PV EOI by default for
> >> > 1.1 and old
#x27;t support them.
Signed-off-by: Eduardo Habkost
---
target-i386/cpu.c | 18 +-
target-i386/cpu.h | 10 ++
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 120a2e3..52042f0 100644
--- a/target-i386/cpu.c
+++ b/
On Thu, Sep 15, 2011 at 05:53:02PM +0300, Sasha Levin wrote:
[...]
> The 'random xid' suggestion is listed merely as an example.
>
> The way I see it using a xid based on MAC instead of a random number is
> safer since the odds for same MAC on the same network are pretty slim
> since it would caus
On Wed, Feb 09, 2011 at 10:06:03AM -0600, Ryan Harper wrote:
> >
> > Instead of regular expressions in the filters, the following syntax is used:
> >
> > , means OR
> > .. means AND
> > . means IMMEDIATELY-FOLLOWED-BY
>
> Is there any reason we can't use | for or, and & for AND? I know this
> i
On Thu, Feb 10, 2011 at 01:03:53PM +0200, Avi Kivity wrote:
> On 02/10/2011 12:57 PM, Michael Goldish wrote:
> >>
> >> I can't easily think of a case where this might cause confusion. The
> >> purpose of this is to allow people to write:
> >>
> >> only qcow2..raw..rtl8139
> >>
> >> without hav
(CCing Andre Przywara, in case he can help to clarify what's the
expected meaning of "-cpu host")
On Tue, Apr 24, 2012 at 06:06:55PM +0200, Jan Kiszka wrote:
> On 2012-04-23 22:02, Eduardo Habkost wrote:
> > On Mon, Apr 23, 2012 at 06:31:25PM +0200, Jan Kiszka wrote:
>
equirements, to know _which_ changes will be needed.
On Tue, Apr 24, 2012 at 02:19:25PM -0300, Eduardo Habkost wrote:
> (CCing Andre Przywara, in case he can help to clarify what's the
> expected meaning of "-cpu host")
>
[...]
> I am not sure I understand what you are
On Tue, May 08, 2012 at 02:58:11AM +0200, Alexander Graf wrote:
> On 07.05.2012, at 20:21, Eduardo Habkost wrote:
>
> >
> > Andre? Are you able to help to answer the question below?
> >
> > I would like to clarify what's the expected behavior of "-cpu hos
>>
> > >>
> > >> On 09.05.2012, at 10:14, Gleb Natapov wrote:
> > >>
> > >>> On Wed, May 09, 2012 at 12:07:04AM +0200, Alexander Graf wrote:
> > >>>>
> > >>>> On 08.05.2012, at 22:14, Eduardo Habk
On Thu, May 10, 2012 at 04:39:45PM +0300, Gleb Natapov wrote:
> On Thu, May 10, 2012 at 03:21:41PM +0200, Alexander Graf wrote:
> > On 05/10/2012 02:53 PM, Gleb Natapov wrote:
> > >On Wed, May 09, 2012 at 04:38:02PM -0300, Eduardo Habkost wrote:
> > >>On Wed, May 09,
ready broken (they can't live-migrate to hosts with
older CPUs or older kernels, already), I don't see how to avoid this
problem.
Signed-off-by: Eduardo Habkost
---
target-i386/cpu.c | 24 +---
target-i386/cpu.h |2 ++
2 files changed, 19 insertions(+), 7 de
On Wed, May 16, 2012 at 09:32:44PM -0500, Anthony Liguori wrote:
> On 05/16/2012 03:58 PM, Eduardo Habkost wrote:
> >Description of the bug:
> >
> >Since QEMU 0.15, the CPUID information on CPUID[EAX=7,ECX=0] is being
> >returned unfiltered to the guest, directly f
On Wed, May 16, 2012 at 05:58:05PM -0300, Eduardo Habkost wrote:
[...]
> @@ -521,6 +523,13 @@ static int cpu_x86_fill_host(x86_def_t *x86_cpu_def)
> x86_cpu_def->ext_features = ecx;
> x86_cpu_def->features = edx;
>
> +if (x86_cpu_def->level >= 7) {
&
ive-migration is already broken (they can't live-migrate to hosts with
older CPUs or older kernels, already), I don't see how to avoid this
problem.
Signed-off-by: Eduardo Habkost
---
target-i386/cpu.c | 22 +++---
target-i386/cpu.h |2 ++
2 files changed, 17 i
On Thu, May 17, 2012 at 10:56:36AM -0600, Eric Blake wrote:
> On 05/17/2012 10:26 AM, Eduardo Habkost wrote:
>
> > The problem is that this makes the resulting CPU feature flags
> > unpredictable and dependent on the host CPU and kernel version. This
> > breaks live-migr
On Thu, May 17, 2012 at 01:26:55PM -0300, Eduardo Habkost wrote:
[...]
> @@ -521,6 +523,12 @@ static int cpu_x86_fill_host(x86_def_t *x86_cpu_def)
> x86_cpu_def->ext_features = ecx;
> x86_cpu_def->features = edx;
>
> +if (x86_cpu_def->level >=
res on CPUID leaf 7
won't be able to live-migrate to QEMU 1.1. But for these users
live-migration is already broken (they can't live-migrate to hosts with
older CPUs or older kernels, already), I don't see how to avoid this
problem.
Signed-off-by: Eduardo Habkost
---
target-i386/c
7; and
- Running on a CPU that supports some features on CPUID leaf 7
won't be able to live-migrate to QEMU 1.1. But for these users
live-migration is already broken (they can't live-migrate to hosts with
older CPUs or older kernels, already), I don't see how to avoid this
at supports the features on CPUID leaf 7; and
- Running on a CPU that supports some features on CPUID leaf 7
won't be able to live-migrate to QEMU 1.1. But for these users
live-migration is already broken (they can't live-migrate to hosts with
older CPUs or older kernels, already),
On Fri, May 25, 2012 at 11:42:00AM -0300, Jan Kiszka wrote:
> On 2012-05-25 11:12, Eduardo Habkost wrote:
> > diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> > index 65d9af6..91a657a 100644
> > --- a/target-i386/cpu.c
> > +++ b/target-i386/cpu.c
> > @
n't think there's a final agreement, but I was convinced later that
it's probably better to _not_ have TSC-deadline on GET_SUPPORTED_CPUID,
at least not by default.
Even if this is changed in the future, it's a good idea to make qemu
support the KVM_CAP_TSC_DEADLINE_TIMER method i
uma option has only support for upto 64VCPUs
>per guest.
>
> This patch addresses these two issues. [ Note: This
> patch has been verified by Eduardo Habkost ].
I was going to add a Tested-by line, but this patch breaks the automatic
round-robin assignment when no CPU is added to a
ndvalue >= max_cpus.
> - Fix to address the round-robbing assignment (for the case
>when cpu's are not explicitly specified)
Tested-by: Eduardo Habkost
It works as expected, now.
>
> Note: Continuing to use a new constant for
> allocation of the cpumask (max_
Just found another issue:
On Wed, Jun 20, 2012 at 05:33:29PM -0300, Eduardo Habkost wrote:
[...]
> > @@ -970,27 +974,24 @@ static void numa_add(const char *optarg)
> > }
> > node_mem[nodenr] = sval;
> > }
> > -if (get_
considering that even if we change the GET_SUPPORTED_CPUID
behavior eventually, there are existing kernels that use
KVM_CAP_TSC_DEADLINE_TIMER to report TSC-deadline support. So:
Reviewed-by: Eduardo Habkost
>
> Thanks,
> Jinsong
>
>
> From 8b5b003f6f8834d2d5d71
Cc: Blue Swirl
Signed-off-by: Eduardo Habkost
---
exec.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 8244d54..c8bfd27 100644
--- a/exec.c
+++ b/exec.c
@@ -2392,7 +2392,7 @@ static void *file_ram_alloc(RAMBlock *block,
unlink(filename
yle changes
- Do not initialize static variable to false
- Use g_strdup_printf() instead of asprintf()
Signed-off-by: Eduardo Habkost
---
cpu-all.h |1 +
exec.c | 26 +-
qemu-options.hx | 12
vl.c|5 +
4 files chan
Cc: Blue Swirl
Signed-off-by: Eduardo Habkost
---
exec.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/exec.c b/exec.c
index c8bfd27..d856325 100644
--- a/exec.c
+++ b/exec.c
@@ -24,6 +24,9 @@
#include
#endif
+#include
+#include
+
#include "
/mnt/hugetlbfs/FOO/pc.ram
Eduardo Habkost (6):
file_ram_alloc(): coding style fixes
file_ram_alloc(): use g_strdup_printf() instead of asprintf()
vl.c: change mem_prealloc to bool (v2)
file_ram_alloc: change length argument to size_t (v2)
file_ram_alloc(): extract temporary-file
While we are at it, rename it to "length", as "memory" doesn't mean
anything.
Changes v1 -> v2:
- Rebase after coding style changes
Signed-off-by: Eduardo Habkost
---
exec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/e
Changes v1 -> v2:
- Do not initialize variable to false, to make checkpatch.pl happy
Signed-off-by: Eduardo Habkost
---
cpu-all.h |2 +-
vl.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 9dc249a..2beed5a 100644
--- a/cpu-al
Changes v1 -> v2:
- Fix trailing space issue
- Rebase against new code using g_strdup_printf()
Signed-off-by: Eduardo Habkost
---
exec.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/exec.c b/exec.c
index 1e98244..456ac73 100644
--
On Mon, Jul 02, 2012 at 07:56:58PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 02, 2012 at 03:06:32PM -0300, Eduardo Habkost wrote:
> > Resending series, after fixing some coding style issues. Does anybody has
> > any
> > feedback about this proposal?
> >
> >
On Fri, Mar 09, 2012 at 09:52:29PM +0100, Jan Kiszka wrote:
> On 2012-03-09 20:09, Liu, Jinsong wrote:
> > Jan Kiszka wrote:
> >> On 2012-03-09 19:27, Liu, Jinsong wrote:
> >>> Jan Kiszka wrote:
> On 2012-03-06 08:49, Liu, Jinsong wrote:
> > Jan,
> >
> > Any comments? I feel some c
On Tue, Mar 13, 2012 at 01:22:42AM +0100, Andreas Färber wrote:
> Am 12.03.2012 13:40, schrieb Juan Quintela:
> > Please send in any agenda items you are interested in covering.
>
> * QEMU 1.1 roadmap
>
> If we're still aiming for a release in early May that would mean a
> feature freeze in about
On Tue, Mar 20, 2012 at 12:53:57PM +, Liu, Jinsong wrote:
> Rik van Riel wrote:
> > On 03/09/2012 01:27 PM, Liu, Jinsong wrote:
> >
> >> As for 'tsc deadline' feature exposing, my patch (as attached) just
> >> obey qemu general cpuid exposing method, and also satisfied your
> >> target I think
On Fri, Mar 23, 2012 at 03:49:27AM +, Liu, Jinsong wrote:
> Eduardo Habkost wrote:
> > [1] From Documentation/virtual/kvm/api.txt:
> >
> > "KVM_GET_SUPPORTED_CPUID
> > [...]
> > This ioctl returns x86 cpuid features which are supported by both the
> &
, Liu, Jinsong wrote:
> Eduardo Habkost wrote:
> > On Fri, Mar 23, 2012 at 03:49:27AM +, Liu, Jinsong wrote:
> >> Eduardo Habkost wrote:
> >>> [1] From Documentation/virtual/kvm/api.txt:
> >>>
> >>> "KVM_GET_SUPPORTED_CPUID
> &
On Fri, Apr 20, 2012 at 12:12:38PM +0200, Jan Kiszka wrote:
> On 2012-04-19 22:03, Eduardo Habkost wrote:
> > Jan/Avi: ping?
> >
> > I would like to get this ABI detail clarified so it can be implemented
> > the right way on Qemu and KVM.
> >
> > My propos
On Fri, Apr 20, 2012 at 05:19:17PM +0200, Jan Kiszka wrote:
> On 2012-04-20 17:00, Eduardo Habkost wrote:
> > On Fri, Apr 20, 2012 at 12:12:38PM +0200, Jan Kiszka wrote:
> >> On 2012-04-19 22:03, Eduardo Habkost wrote:
> >>> Jan/Avi: ping?
> >>>
> >
On Sat, Apr 21, 2012 at 09:23:50AM +0200, Jan Kiszka wrote:
> On 2012-04-20 17:36, Eduardo Habkost wrote:
> > On Fri, Apr 20, 2012 at 05:19:17PM +0200, Jan Kiszka wrote:
> >> On 2012-04-20 17:00, Eduardo Habkost wrote:
> >>> On Fri, Apr 20, 2012 at 12:12:38PM +020
On Mon, Apr 23, 2012 at 06:31:25PM +0200, Jan Kiszka wrote:
> On 2012-04-23 16:48, Eduardo Habkost wrote:
> > Trying to summarize the points above:
> >
> > Groups (A) and (B) are:
> >
> > A) a feature that KVM supports and emulate by itself and can be enabled
>
On Mon, Jan 03, 2011 at 08:34:07PM +0200, Michael Goldish wrote:
> +# Exception context information:
> +# --
> +# Every function can have some context string associated with it.
> +# The context string can be changed by calling context(str) and cleared by
> +# calling co
On Mon, Jan 03, 2011 at 05:26:20PM -0200, Eduardo Habkost wrote:
> On Mon, Jan 03, 2011 at 08:34:07PM +0200, Michael Goldish wrote:
> > +# Exception context information:
> > +# --
> > +# Every function can have some context string associated with i
On Mon, Jan 03, 2011 at 09:48:02PM +0200, Michael Goldish wrote:
> On 01/03/2011 09:26 PM, Eduardo Habkost wrote:
> > On Mon, Jan 03, 2011 at 08:34:07PM +0200, Michael Goldish wrote:
> >> +# Exception context information:
> >> +# --
> >
On Mon, Jan 03, 2011 at 08:34:07PM +0200, Michael Goldish wrote:
> +
> +context_data = threading.local()
> +context_data.contexts = {}
Won't this create a single dictionary, only for one single thread,
leaving all other threads with 'context_data.contexts' undefined?
--
Eduardo
--
To unsubscribe
On Mon, Jan 03, 2011 at 11:07:53PM +0200, Michael Goldish wrote:
>
> If I understand your suggestion correctly, then:
>
> - The purpose of contexts is to add information to exceptions. If an
> exception is raised and you call clear_context() in a finally clause,
> you remove the context of the c
On Mon, Jan 03, 2011 at 07:22:17PM -0200, Eduardo Habkost wrote:
> On Mon, Jan 03, 2011 at 11:07:53PM +0200, Michael Goldish wrote:
> >
> > If I understand your suggestion correctly, then:
> >
> > - The purpose of contexts is to add information to exceptions. If an
On Tue, Jan 04, 2011 at 12:56:16AM +0200, Michael Goldish wrote:
> On 01/04/2011 12:06 AM, Eduardo Habkost wrote:
> > On Mon, Jan 03, 2011 at 07:22:17PM -0200, Eduardo Habkost wrote:
[...]
> > If you want to be extra careful, you can keep an index of contexts for
> > each exc
On Tue, Jan 04, 2011 at 12:56:16AM +0200, Michael Goldish wrote:
> I think that's risky:
>
> try:
> vm.create() # context aware, raises an exception
> except:
> try:
> vm.destroy() # context aware, raises an exception
> except:
> pass
> raise
Heh, did you try th
embedded in it. (The actual
> embedding is done in the next patch in the series.)
>
> Signed-off-by: Michael Goldish
> Signed-off-by: Eduardo Habkost
> ---
> client/common_lib/error.py | 97
> +++-
> 1 files changed, 95 insertion
On Wed, Jan 05, 2011 at 06:12:05PM +0200, Avi Kivity wrote:
> It would be nice to make the error context a stack, and to use the
> with statement to manage the stack:
>
>
>with error.context("main test"):
>foo()
>with error.context("before reboot"):
>bar()
>
> If
On Wed, Jan 05, 2011 at 06:21:35PM +0200, Avi Kivity wrote:
> btw, you can have a decorator for enclosing an entire function in an
> error context:
>
>@function_error_context('migration test')
>def migration_test(...):
>...
@context_aware does that, but it doesn't let you set the
On Wed, Jan 05, 2011 at 08:55:44PM +0200, Michael Goldish wrote:
> On 01/05/2011 06:21 PM, Eduardo Habkost wrote:
> > By the way, I think we could make _new_context() and _pop_context() part
> > of the public interface (i.e. remove the "_" from their names). I see
>
From: Eduardo Habkost
If the whole purpose of running kvm_config.py directly is to print the
dictionary contents, it is better to simply dump the information to
stdout instead of adding the logginging info and timestamp clutter to
every single line.
Signed-off-by: Eduardo Habkost
---
client
From: Eduardo Habkost
Useful to test and debug cases where config settings are concatenated together,
without the need to change the base .cfg file.
Signed-off-by: Eduardo Habkost
---
client/tests/kvm/kvm_config.py |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git
From: Eduardo Habkost
Include the filename and line number on the "Using variants in this
context is not allowed" exception error message.
Signed-off-by: Eduardo Habkost
---
client/tests/kvm/kvm_config.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cl
From: Eduardo Habkost
This series introduce some changes on kvm_config.py to make it more usable when
running it directly from the command-line.
Eduardo Habkost (5):
kvm_config: accept multiple filenames as argument
kvm_config: print directly to stdout instead of using logging
kvm_config
From: Eduardo Habkost
It will be useful to generate better error messages.
Signed-off-by: Eduardo Habkost
---
client/tests/kvm/kvm_config.py |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/client/tests/kvm/kvm_config.py b/client/tests/kvm/kvm_config.py
index
From: Eduardo Habkost
Useful for syntax or other errors on the config file. We want to tell
the user on which file:line the error is located.
Signed-off-by: Eduardo Habkost
---
client/tests/kvm/kvm_config.py | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff
ate the change.
Signed-off-by: Eduardo Habkost
---
client/tests/kvm/kvm_config.py | 46 ---
1 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/client/tests/kvm/kvm_config.py b/client/tests/kvm/kvm_config.py
index c4d9a01..f7c1e9f 100755
--- a/
Oops. I guess it was not intended to ignore the exception, but just do
cleanup in case of errors.
Signed-off-by: Eduardo Habkost
---
client/tests/kvm/scripts/unattended.py |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/client/tests/kvm/scripts/unattended.py
b/client
On Tue, Jan 11, 2011 at 01:48:22AM -0200, Lucas Meneghel Rodrigues wrote:
> On Thu, 2011-01-06 at 14:12 -0200, Eduardo Habkost wrote:
> > +for num,line in enumerate(str.splitlines(), 1):
>
> ^ enumerate in py 2.4 takes exactly 1 argument, so it's not possible to
>
On Tue, Apr 12, 2011 at 07:28:15PM -0300, Lucas Meneghel Rodrigues wrote:
> During unattended install, right after we receive the ACK from the guest
> the test is deemed to be finished, and as shutdown_vm = yes, it'll try
> to end the vm issuing a shutdown command to it. However, on virtually
> all
(CCing Marcelo, Avi, and kvm mailing list, so they can help answering
the uq/master patch flow question)
On Fri, Jun 03, 2011 at 12:51:42AM +0200, Jan Kiszka wrote:
> On 2011-06-02 21:34, Eduardo Habkost wrote:
> > Ouch, the subject prefix is completely wrong because of broken
> >
On Wed, Jun 08, 2011 at 04:11:05PM +0200, Jan Kiszka wrote:
> kvm_arch_get_supported_cpuid checks for global cpuid restrictions, it
> does not require any CPUState reference. Changing its interface allows
> to call it before any VCPU is initialized.
I'm wondering if it wouldn't be simpler to keep
On Thu, Jun 09, 2011 at 07:41:03PM +0200, Jan Kiszka wrote:
> > I'm wondering if it wouldn't be simpler to keep the existing interface
> > but just initialize CPUState->kvm_state earlier (today it is initialized
> > only on kvm_init_vcpu(), although the kvm_state global is initialized
> > much ear
On Wed, Jun 08, 2011 at 04:11:03PM +0200, Jan Kiszka wrote:
> @@ -217,7 +209,6 @@ int kvm_arch_get_registers(CPUState *env)
> return ret;
> }
>
> -#ifdef KVM_CAP_PPC_BOOKE_SREGS
> if (sregs.u.e.features & KVM_SREGS_E_BASE) {
> env->spr[SPR_BOOKE_CSRR0]
Hi,
While checking the cpu model code, I don't think I understand fully what
is supposed to be the right semantics for '-cpu host' on qemu-kvm, and
what exactly we are aiming to.
Maybe this was already discussed before, but I failed to find any
additional information except for the original '-cpu
On Wed, Jan 30, 2013 at 11:58:56AM +0100, Andreas Färber wrote:
> Am 15.01.2013 17:16, schrieb Juan Quintela:
> >
> > * cpu hot plug
> > - use qdev propierties conected to a set of socket objects (anthony)
> > - cpusets are the wrong interface (anthony)
> > - make a link between cpu <-> sock
On Fri, Feb 08, 2013 at 01:58:42PM +0100, Igor Mammedov wrote:
> On Fri, 08 Feb 2013 12:16:17 +0100
> Andreas Färber wrote:
>
> > Am 08.02.2013 10:03, schrieb Igor Mammedov:
> > > On Thu, 7 Feb 2013 13:08:19 -0200
> > > Eduardo Habkost wrote:
> > >
On Fri, Feb 08, 2013 at 12:52:31PM -0200, Eduardo Habkost wrote:
> On Fri, Feb 08, 2013 at 01:58:42PM +0100, Igor Mammedov wrote:
[...]
> > Continuing on theoretical issue:
> > > We could add an inited field to X86CPUClass that gets checked at initfn
> > > time (only
On Fri, Feb 08, 2013 at 05:54:50PM +0100, Andreas Färber wrote:
> Am 08.02.2013 15:52, schrieb Eduardo Habkost:
> > On Fri, Feb 08, 2013 at 01:58:42PM +0100, Igor Mammedov wrote:
> >> On Fri, 08 Feb 2013 12:16:17 +0100
> >> Andreas Färber wrote:
> >>> Am
On Mon, Feb 11, 2013 at 02:52:49AM +0100, Igor Mammedov wrote:
> On Fri, 8 Feb 2013 16:13:02 -0200
> Eduardo Habkost wrote:
>
> > On Fri, Feb 08, 2013 at 05:54:50PM +0100, Andreas Färber wrote:
> > > Am 08.02.2013 15:52, schrieb Eduardo Habkost:
> > > > On F
TL;DR: I still disagree about some points, but those points aren't so
relevant anymore because I am starting to like having
KVM-specific/TCG-specific subclasses (because of other problems that
would be solved by them).
On Wed, Feb 13, 2013 at 04:20:43PM +0100, Igor Mammedov wrote:
[...]
> > > >
specific
feature word supported by "-cpu host" before we make each bit
configurable individually in the command-line.
On the other hand, requiring feat_names to be always set would help
making the table more explicit. If we really want it (which I doubt), we
can have the same effect of feat
On Tue, Feb 26, 2013 at 10:57:56PM +0100, Igor Mammedov wrote:
> On Sat, 23 Feb 2013 16:45:00 +0100
> Jan Kiszka wrote:
>
> > From: Jan Kiszka
> >
> > Several issues fixed:
> > - We were missing a bunch of feature lists. Fix this by simply dumping
> >the meta list feature_word_info.
> > -
I will start by reviewing the test code, so we can agree on expected
syntax/behavior, before reviewing the implementation:
On Fri, Mar 29, 2013 at 06:14:08PM +0100, Jiří Župka wrote:
> Signed-off-by: Jiří Župka
> ---
> virttest/cartesian_config_unittest.py | 79
> +++
1 - 100 of 627 matches
Mail list logo
