for the change of plans.
There's no real convincing. It's just a question of code. There are
no defaults in classes for dynamic properties to modify. compat_props
are a nice mechanism, making them work for all properties is a
reasonable thing to do.
Regards,
Anthony Liguori
--
libvir-list mailing list
On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost ehabk...@redhat.com wrote:
On Tue, Feb 11, 2014 at 06:31:35AM -0800, Anthony Liguori wrote:
On Fri, Feb 7, 2014 at 2:55 AM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 07/02/2014 11:16, Eduardo Habkost ha scritto:
You are not alone. I
On Tue, Feb 11, 2014 at 8:55 AM, Andreas Färber afaer...@suse.de wrote:
Am 11.02.2014 16:58, schrieb Anthony Liguori:
On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost ehabk...@redhat.com wrote:
On Tue, Feb 11, 2014 at 06:31:35AM -0800, Anthony Liguori wrote:
On Fri, Feb 7, 2014 at 2:55 AM
,
Anthony Liguori
That is the other possibility, yes. But in this case -nodefaults must not
create spapr-nvram automatically and if we do that, we'll break existing
setups.
Alex
/* hcall-vio */
spapr_register_hypercall(H_VIO_SIGNAL, h_vio_signal);
diff --git a/include/hw
the watchdog aspect of this, having a portable
panic notifier and the ability to enhance it to include more
information (like the backtrace, etc.) is pretty darn useful.
Regards,
Anthony Liguori
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http
.
Ack, but the current watchdog does not work for Windows guests and is
not aware of guest time.
That's why I think having a virtio-ilo makes sense. This is not a
solved problem today.
Regards,
Anthony Liguori
[Note what I say applies to the qemu watchdog device. The Linux
watchdog daemon
at this point.
Regards,
Anthony Liguori
== Support in libvirt for current functionality ==
libvirt will add a panic-notifier/ element, and possibly a capability
for it accessible via virsh capabilities. There are two possibilities:
1) On QEMU 1.5.4/1.6.1 and newer (and on QEMU 1.6.0 with a machine
than NACK, don't even
bother sending the email in the first place.
Regards,
Anthony Liguori
No words have been spent on NAKs yet (... since my subscription, that
is). Is this stuff formalized somewhere?
Sorry for wasting time...
Thanks,
Laszlo
--
libvir-list mailing list
libvir-list
Laszlo Ersek ler...@redhat.com writes:
On 08/22/13 18:44, Anthony Liguori wrote:
pvpanic has been a failure. It's a poorly designed device with even
worse semantics.
I disagree somewhat.
Requiring a separate ioport is not ideal, I admit. Configuration over
ACPI is good OTOH (it seems
...
pvpanic is not going to be present on S390, PPC, ARM, or MIPS because of
the fact that it's x86 specific.
That means at some point there's going to have to be another device to
support these platforms and libvirt will need to deal with that too.
Regards,
Anthony Liguori
--
libvir-list mailing list
multiple cases where a naive watchdog
has a problem in the field when the system is under heavy load.
A PV watchdog actually makes sense because it can be defined based on
guest run time instead of wall clock time.
Regards,
Anthony Liguori
Paolo
--
libvir-list mailing list
libvir-list@redhat.com
On Thu, Aug 22, 2013 at 3:36 PM, Laszlo Ersek ler...@redhat.com wrote:
On 08/22/13 22:09, Anthony Liguori wrote:
The difference is that ACPI or platform devices in general are
unexpected to be added. By definition it means that the motherboard has
most likely been changed.
You could
hard to predict.
The only practical way of doing this would be to have QEMU gracefully
handle malloc() == NULL so that you could set a limit and gracefully
degrade. We don't though so setting a limit is likely to get you in
trouble.
Regards,
Anthony Liguori
Michal
1: https://www.redhat.com
We have received numerous requests to extend the CFP deadline and so
we are happy to announce that the CFP deadline has been moved by two
weeks to August 4th.
=
KVM Forum 2013: Call For Participation
October 21-23, 2013 - Edinburgh
Peter Maydell peter.mayd...@linaro.org writes:
On 22 May 2013 14:15, Anthony Liguori aligu...@us.ibm.com wrote:
Paolo Bonzini pbonz...@redhat.com writes:
You
don't need to know what targets were supported in the version that you
compiled from. Only one target is supported in this executable
the default? It doesn't seem to work at all for
me. Even with TCG, I've had more luck with -M pseries.
While adding an accelerator specific default, if mac99 is the wrong
default for TCG, then we should change it.
Regards,
Anthony Liguori
Daniel
--
|: http://berrange.com -o-http
able to set global domain options.
Regards,
Anthony Liguori
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org
the global setting within QEMU. We can't just point our
fingers at each other and hope the problem goes away :-)
Regards,
Anthony Liguori
Creating basic
XML structure with relevant defaults pre-filled for a particular usecase
is something that the libvirt-designer library is aiming to take care
Daniel P. Berrange berra...@redhat.com writes:
On Thu, May 02, 2013 at 10:40:06AM -0500, Anthony Liguori wrote:
Kevin Wolf kw...@redhat.com writes:
+
+if (strcmp(type, ide-cd) == 0) {
+disk_type = DT_CDROM;
+} else if (strcmp(type, isa-fdc) == 0
Kevin Wolf kw...@redhat.com writes:
Am 02.05.2013 um 15:41 hat Anthony Liguori geschrieben:
Kevin Wolf kw...@redhat.com writes:
Ugh. Comparing the device name to an incomplete set of strings here and
then figuring out for each what the specific way for this device is to
create a nice
Applied. Thanks.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
be a problem.
Regards,
Anthony Liguori
object_unref(obj);
+g_free(path);
}
static void object_deinit(Object *obj, TypeImpl *type)
--
MST
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Paolo Bonzini pbonz...@redhat.com writes:
Il 18/03/2013 15:24, Anthony Liguori ha scritto:
Michael S. Tsirkin m...@redhat.com writes:
We need to know the original path since unparenting loses this state.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/qdev.c| 4
Michael S. Tsirkin m...@redhat.com writes:
On Fri, Mar 08, 2013 at 07:36:28AM -0600, Anthony Liguori wrote:
Markus Armbruster arm...@redhat.com writes:
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Mar 07, 2013 at 08:57:52PM +0100, Markus Armbruster wrote:
Michael S. Tsirkin m
to call this more functionality. I agree
that backporting it to pre-QOM versions isn't practical.
2. Sane event trigger condition: on any device deletion, not just when
the device happens to have a qdev ID. This isn't more, it's
different.
Ack.
Regards,
Anthony Liguori
--
libvir
should respin to avoid confusing Anthony's
tools.
Ack and thanks for pointing this out. Please put a space before the v3
too.
Regards,
Anthony Liguori
Recommend to delay the respin until the discussion we're having
in the v1 thread has run its course.
--
libvir-list mailing list
libvir
Eric Blake ebl...@redhat.com writes:
[adding libvirt]
On 03/03/2013 02:05 PM, Anthony Liguori wrote:
Paolo Bonzini pbonz...@redhat.com writes:
Il 02/03/2013 04:13, Anthony Liguori ha scritto:
There is no valid use-case of rng-random other than using /dev/random.
In fact, it was probably
, since qemu 1.4 does NOT support
/dev/fdset/nnn fd passthrough for the backend, limiting to just
two known names means that we don't get tempted to try fd
passthrough where it won't work.
Acked-by: Anthony Liguori aligu...@us.ibm.com
Regards,
Anthony Liguori
[1]https://lists.gnu.org/archive
Markus Armbruster arm...@redhat.com writes:
Anthony Liguori anth...@codemonkey.ws writes:
Paolo Bonzini pbonz...@redhat.com writes:
What about:
[numa]
node=1
cpus=2
cpus=3
qemu -readconfig numa.cfg -numa node=1,cpus=1
I figure you mean
the previous syntax.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Paolo Bonzini pbonz...@redhat.com writes:
Il 26/02/2013 20:35, Anthony Liguori ha scritto:
See also discussion on multi-valued keys in command line option
arguments and config files in v1 thread. Hopefully we can reach a
conclusion soon, and then we'll see whether this patch is what we
Paolo Bonzini pbonz...@redhat.com writes:
Il 27/02/2013 16:42, Anthony Liguori ha scritto:
There's such thing as list support in QemuOpts. The only way
QemuOptsVisitor was able to implement it was to expose QemuOpts publicly
via options_int.h and rely on a implementation detail
Markus Armbruster arm...@redhat.com writes:
Anthony Liguori aligu...@us.ibm.com writes:
Which is indistinguishable from a straight string property. This means
it's impossible to introspect because the type is context-sensitive.
What's more, there is no API outside of QemuOptsVisitor
Eduardo Habkost ehabk...@redhat.com writes:
On Wed, Feb 27, 2013 at 04:57:15PM +0100, Paolo Bonzini wrote:
Il 27/02/2013 16:42, Anthony Liguori ha scritto:
There's such thing as list support in QemuOpts. The only way
QemuOptsVisitor was able to implement it was to expose QemuOpts publicly
Paolo Bonzini pbonz...@redhat.com writes:
Il 27/02/2013 18:08, Anthony Liguori ha scritto:
No, no, no. This makes ':' special, which means you can't have lists of
anything containing ':'. Your cure is worse than the disease. Let go
of that syntactic high-fructose corn syrup, stick
;
LinkStdVGA integrated_vga;
...
We should prevent PCI bus plugging for slots owned by integrated
devices. libvirt has a way to probe for links that it can add including
what types are allowed for it.
Regards,
Anthony Liguori
* support some new emulated chipset devices?
-M q35 + -device
compat with netdev but it should not be used anywhere else.
Regards,
Anthony Liguori
--
Eduardo
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
be
improved.
No more of this.
-numa node,cpus=A:B:C:D
if you want to express a list.
Regards,
Anthony Liguori
Note that the following format, currently used by libvirt:
-numa nodes,cpus=A,B,C,D
will _not_ work yet, as , is the option separator for the command-line
option parser
Applied. Thanks.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
don't remember what that
trick was.
We need a generic query-config-schema command.
Regards,
Anthony Liguori
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com
Hi,
This is an automated message generated from the QEMU Patches.
Thank you for submitting this patch. This patch no longer applies to qemu.git.
This may have occurred due to:
1) Changes in mainline requiring your patch to be rebased and re-tested.
2) Sending the mail using a tool other
Hi,
This is an automated message generated from the QEMU Patches.
Thank you for submitting this patch. This patch no longer applies to qemu.git.
This may have occurred due to:
1) Changes in mainline requiring your patch to be rebased and re-tested.
2) Sending the mail using a tool other
.tar.bz2 that contained the fixed VERSION
file.
Regards,
Anthony Liguori
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Luiz Capitulino lcapitul...@redhat.com writes:
On Fri, 27 Jul 2012 08:37:13 -0500
Anthony Liguori aligu...@us.ibm.com wrote:
This can be used in conjunction with qom-list-types to determine the
supported
set of devices and their parameters.
Signed-off-by: Anthony Liguori aligu
Luiz Capitulino lcapitul...@redhat.com writes:
On Fri, 27 Jul 2012 08:37:14 -0500
Anthony Liguori aligu...@us.ibm.com wrote:
We've had a cycle to tweak. It is time to commit to supporting them.
qmp_qom_get() and qpm_qom_set() still use the legacy monitor interface, can't
we convert
Luiz Capitulino lcapitul...@redhat.com writes:
On Fri, 27 Jul 2012 08:37:15 -0500
Anthony Liguori aligu...@us.ibm.com wrote:
This provides the same output as -M ? but in a structured way.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
qapi-schema.json | 28
Eduardo Habkost ehabk...@redhat.com writes:
On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote:
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
target-i386/cpu.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/target-i386
Luiz Capitulino lcapitul...@redhat.com writes:
On Fri, 10 Aug 2012 09:41:20 -0500
Anthony Liguori aligu...@us.ibm.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
On Fri, 27 Jul 2012 08:37:15 -0500
Anthony Liguori aligu...@us.ibm.com wrote:
This provides the same output
Eduardo Habkost ehabk...@redhat.com writes:
On Fri, Aug 10, 2012 at 09:43:21AM -0500, Anthony Liguori wrote:
Eduardo Habkost ehabk...@redhat.com writes:
On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote:
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
target-i386
Eduardo Habkost ehabk...@redhat.com writes:
On Fri, Aug 10, 2012 at 11:37:30AM -0500, Anthony Liguori wrote:
Eduardo Habkost ehabk...@redhat.com writes:
- add machine-type-specific cpudef compatibility changes?
I think we've discussed this in IRC. I don't think we need to worry
about
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
target-i386/cpu.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 6b9659f..b398439 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -28,6
This provides the same output as -M ? but in a structured way.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
qapi-schema.json | 28
qmp-commands.hx |6 ++
vl.c | 31 +++
3 files changed, 65 insertions
This can be used in conjunction with qom-list-types to determine the supported
set of devices and their parameters.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
qapi-schema.json | 28
qmp-commands.hx |7 +++
qmp.c| 50
We've had a cycle to tweak. It is time to commit to supporting them.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
qapi-schema.json | 19 ---
1 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 015a84a..28e9914
This lets us provide a default implementation of a symbol which targets can
override.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
compiler.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/compiler.h b/compiler.h
index 736e770..f76921e 100644
--- a/compiler.h
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
target-ppc/translate_init.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 5742229..7e025cb 100644
--- a/target-ppc
This series implements the necessary commands to implements danpb's idea to
remove -help parsing in libvirt. We would introduce all of these commands in
1.2 and then change the -help output starting in 1.3.
Here is Dan's plan from a previous thread:
danpb
Basically I'd sum up my new idea as
and implement this command if it makes sense for them.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
qapi-schema.json | 23 +++
qmp-commands.hx |6 ++
qmp.c|6 ++
3 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qapi
Peter Maydell peter.mayd...@linaro.org writes:
On 27 July 2012 14:37, Anthony Liguori aligu...@us.ibm.com wrote:
--- a/compiler.h
+++ b/compiler.h
@@ -45,6 +45,7 @@
# define GCC_ATTR __attribute__((__unused__, format(gnu_printf, 1, 2)))
# define GCC_FMT_ATTR(n, m) __attribute__((format
Peter Maydell peter.mayd...@linaro.org writes:
On 27 July 2012 15:27, Anthony Liguori aligu...@us.ibm.com wrote:
Peter Maydell peter.mayd...@linaro.org writes:
The GCC manual says Weak symbols are supported for ELF targets,
and also for a.out targets when using the GNU assembler and linker
Peter Maydell peter.mayd...@linaro.org writes:
On 27 July 2012 14:37, Anthony Liguori aligu...@us.ibm.com wrote:
This command attempts to map to the behavior of -cpu ?. Unfortunately, the
output of this command differs wildly across targets.
I've never really understood why so much
Peter Maydell peter.mayd...@linaro.org writes:
On 27 July 2012 14:37, Anthony Liguori aligu...@us.ibm.com wrote:
--- a/compiler.h
+++ b/compiler.h
@@ -45,6 +45,7 @@
# define GCC_ATTR __attribute__((__unused__, format(gnu_printf, 1, 2)))
# define GCC_FMT_ATTR(n, m) __attribute__((format
Eric Blake ebl...@redhat.com writes:
On 07/27/2012 07:37 AM, Anthony Liguori wrote:
This provides the same output as -M ? but in a structured way.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
qapi-schema.json | 28
qmp-commands.hx |6
Blue Swirl blauwir...@gmail.com writes:
On Fri, Jul 27, 2012 at 3:31 PM, Anthony Liguori aligu...@us.ibm.com wrote:
Peter Maydell peter.mayd...@linaro.org writes:
On 27 July 2012 15:27, Anthony Liguori aligu...@us.ibm.com wrote:
Peter Maydell peter.mayd...@linaro.org writes:
The GCC manual
? As long as
it's a small number, we can start with that and get something in shape
for 1.2.
Regards,
Anthony Liguori
Eduardo Habkost (3):
vl.c: extract qemu_machine_init() function
per-machine-type CPU model alias system
x86: pc: versioned CPU model names compatibility aliases
hw
where this thread has headed with /dev/fdset. This has become
extremely complex and cumbersome.
Perhaps we should reconsider using an RPC for QEMU to request an fd as this
solves all the cited problems in a much simpler fashion.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list
to do is listen on a socket and delegate access according to a
white list. Whatever is providing fd's needs to have no knowledge of anythign
other than what the guest is allowed to access which shouldn't depend on an
executing command.
Regards,
Anthony Liguori
I'm really disliking the hook
On 07/09/2012 03:29 PM, Eric Blake wrote:
On 07/09/2012 02:00 PM, Anthony Liguori wrote:
with the fd:name approach, the sequence is:
libvirt calls getfd:name1 over normal monitor
qemu responds
libvirt calls getfd:name2 over normal monitor
qemu responds
libvirt calls transaction around
source but given the fact that
the license is moronic, I expect the implementation to be equally dumb and
wouldn't even consider it even if the license was changed at this point.
[1] http://www.ietf.org/rfc/rfc4627
Regards,
Anthony Liguori
Thoughts? Do we need to seek legal guidance from FSF
.
Reference to previous discussion:
- http://marc.info/?l=qemu-develm=133278877315665
Applied (as discussed prior to -rc0). Thanks.
Regards,
Anthony Liguori
Eduardo Habkost (6):
move code to read default config files to a separate function (v2)
eliminate arch_config_name variable
On 05/11/2012 08:34 AM, Eduardo Habkost wrote:
I just noticed it didn't get into -rc1 either. So, this is definitely
not going to be in qemu-1.1, I guess?
I've got this applied and am testing it right now for -rc2.
Regards,
Anthony Liguori
On Wed, May 02, 2012 at 01:07:24PM -0300
in support of it. But
holding practical features hostage is not reasonable.
There is nothing intrinsically cleaner about using -blockdev fd=X verses using
an RPC like this. -blockdev has a lot of nice characteristics but solving this
problem is not one of them.
Regards,
Anthony Liguori
Kevin
and let libvirt enforce whatever rules it wants.
This is not meant to be an alternative to blockdev, but even with blockdev, I
think we still want to use a mechanism like this even with blockdev.
Regards,
Anthony Liguori
Anthony Liguori (3):
block: add open() wrapper that can be hooked
On 05/01/2012 03:56 PM, Eric Blake wrote:
On 05/01/2012 02:25 PM, Anthony Liguori wrote:
Thanks for sending this out Stefan.
Indeed.
This series adds the -open-hook-fd command-line option. Whenever QEMU
needs to
open an image file it sends a request over the given UNIX domain
socket
On 05/01/2012 04:45 PM, Corey Bryant wrote:
On 05/01/2012 04:25 PM, Anthony Liguori wrote:
Thanks for sending this out Stefan.
On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux to restrict the QEMU process and
prevent
it from opening files that it should
On 05/01/2012 05:15 PM, Eric Blake wrote:
On 05/01/2012 03:53 PM, Anthony Liguori wrote:
I think (correct me if I'm wrong) libvirt should be aware of any file
that qemu
asks it to open. So from a security point of view, libvirt can prevent
opening a
file if it isn't affiliated with the guest
is in arch_init.c
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
for -nodefconfig, the fact is that it exists today,
and has a specific semantic. If we want to have a different semantic, we should
introduce a new option (-no-user-config).
Regards,
Anthony Liguori
Maybe they have a management tool that attempts to totally hide QEMU
from the end user
,chr=chr0 ...
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
and use the semantics I specified earlier in the thread.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 03/25/2012 04:49 AM, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote:
So let's avoid that and start by having a positive configuration
mechanism that the user can use to change the path and exclude it.
My suggestion eliminate the need for two future
On 03/25/2012 08:08 AM, Avi Kivity wrote:
On 03/25/2012 02:55 PM, Anthony Liguori wrote:
If cpu models are not part of configuration they should not be affected
by configuration mechanism. You are just avoiding addressing the real
question that if asked above.
I think you're just refusing
On 03/25/2012 08:14 AM, Avi Kivity wrote:
On 03/25/2012 03:12 PM, Anthony Liguori wrote:
qemu -M pc
Would effectively be short hand for -readconfig
/usr/share/qemu/machines/pc.cfg
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg
On 03/25/2012 08:21 AM, Avi Kivity wrote:
On 03/11/2012 04:12 PM, Anthony Liguori wrote:
This discussion isn't about whether QEMU should have a Westmere
processor definition. In fact, I think I already applied that patch.
It's a discussion about how we handle this up and down the stack
On 03/25/2012 08:34 AM, Avi Kivity wrote:
On 03/25/2012 03:22 PM, Anthony Liguori wrote:
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
This is not a bad suggestion, although it would make -cpu ? a bit
awkward. Do you see an advantage
On 03/25/2012 09:46 AM, Avi Kivity wrote:
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what we have today. Our configuration
file basically corresponds to command line options
On 03/25/2012 09:58 AM, Gleb Natapov wrote:
On Sun, Mar 25, 2012 at 03:14:56PM +0200, Avi Kivity wrote:
On 03/25/2012 03:12 PM, Anthony Liguori wrote:
qemu -M pc
Would effectively be short hand for -readconfig
/usr/share/qemu/machines/pc.cfg
In that case
qemu -cpu westmere
is shorthand
On 03/25/2012 10:16 AM, Avi Kivity wrote:
On 03/25/2012 04:59 PM, Anthony Liguori wrote:
On 03/25/2012 09:46 AM, Avi Kivity wrote:
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what
On 03/25/2012 10:18 AM, Avi Kivity wrote:
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
As log as qemu -nodefconfig -cpu westmere -M pc1.1
-nodefconfig is going to eventually mean that -cpu westmere and -M
pc-1.1 will not work.
This is where QEMU is going. There is no reason that a normal
On 03/25/2012 10:45 AM, Avi Kivity wrote:
On 03/25/2012 05:30 PM, Anthony Liguori wrote:
On 03/25/2012 10:18 AM, Avi Kivity wrote:
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
As log as qemu -nodefconfig -cpu westmere -M pc1.1
-nodefconfig is going to eventually mean that -cpu westmere
On 03/25/2012 10:40 AM, Avi Kivity wrote:
On 03/25/2012 05:26 PM, Anthony Liguori wrote:
Put the emphasis around *configuration*.
So how about:
1) Load ['@SYSCONFDIR@/qemu/qemu.cfg',
'@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
'@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
2
On 03/22/2012 12:14 PM, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 11:37:39AM -0500, Anthony Liguori wrote:
On 03/22/2012 04:32 AM, Gleb Natapov wrote:
On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote:
So, this problem is solved if the defaults are easily found on
/usr
On 03/11/2012 11:16 AM, Gleb Natapov wrote:
On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote:
On 03/11/2012 09:56 AM, Gleb Natapov wrote:
On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
-cpu best wouldn't solve this. You need a read/write configuration
file
.
simply make incompatible changes.
So this is easy. CPU's need to be qdev/QOM and the various cpuid settings need
to be done through qdev properties.
Then you can just add globals to the machine definition. No different than what
we do with virtio-blk.
Regards,
Anthony Liguori
Also
On 03/12/2012 01:53 PM, Itamar Heim wrote:
On 03/11/2012 05:33 PM, Anthony Liguori wrote:
On 03/11/2012 09:56 AM, Gleb Natapov wrote:
On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
-cpu best wouldn't solve this. You need a read/write configuration
file where QEMU probes
On 03/12/2012 02:12 PM, Itamar Heim wrote:
On 03/12/2012 09:01 PM, Anthony Liguori wrote:
It's a trade off. From a RAS perspective, it's helpful to have
information about the host available in the guest.
If you're already exposing a compatible family, exposing the actual
processor seems
On 03/11/2012 08:27 AM, Gleb Natapov wrote:
On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote:
Let's step back here.
Why are you writing these patches? It's probably not because you
have a desire to say -cpu Westmere when you run QEMU on your laptop.
I'd wager to say
to waste developer time.
And QEMU become even less usable from a command line. One more point to
kvm-tool I guess.
I'm not sure what your point is. We're talking about an option that humans
don't use. How is this a discussion about QEMU usability?
Regards,
Anthony Liguori
--
libvir-list
On 03/11/2012 09:56 AM, Gleb Natapov wrote:
On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
-cpu best wouldn't solve this. You need a read/write configuration
file where QEMU probes the available CPU and records it to be used
for the lifetime of the VM.
That what I thought
On 03/11/2012 10:12 AM, Gleb Natapov wrote:
On Sun, Mar 11, 2012 at 09:16:49AM -0500, Anthony Liguori wrote:
If libvirt assumes anything about what kvm actually supports it is
working only by sheer luck.
Well the simple answer for libvirt is don't use -nodefconfig and
then it can reuse
1 - 100 of 297 matches
Mail list logo
