On Tue, Feb 11, 2014 at 8:55 AM, Andreas Färber wrote:
> Am 11.02.2014 16:58, schrieb Anthony Liguori:
>> On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost wrote:
>>> On Tue, Feb 11, 2014 at 06:31:35AM -0800, Anthony Liguori wrote:
>>>> On Fri, Feb 7, 2014 at
On Tue, Feb 11, 2014 at 7:25 AM, Eduardo Habkost 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 wrote:
>> > Il 07/02/2014 11:16, Eduardo Habkost ha scritto:
>> >
>> >> You are not
l, but at the same I think I understand the
> reasons 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
reaso
or management
> to have a chance to choose what to do about the panic? I'm suspecting
> this patch does break things.
I would be happy to apply a patch that just reverted the whole dang
mess of this device.
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/mailman/listinfo/libvir-list
bus = DO_UPCAST(VIOsPAPRBus, bus, qbus);
>>> bus->next_reg = 0x7100;
>>> +bus->next_vty_reg = 0x71000100;
>>
>> This breaks as soon as you pass in more than 0x100 devices that are non-vty
>> into the guest, no?
>
> Will we ever hav
necessarily mean a guest reboot.
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 wat
are really
> serving the same purpose. The panic notifier is an alert to a
> specific known kernel crash. A watchdog is merely a timeout,
> which is inferred to mean /something/ went wrong. Both have
> their uses IMHO & we should not conflate the two.
Even if you ignore the watchdog as
On Thu, Aug 22, 2013 at 3:36 PM, Laszlo Ersek 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.
&
derfully.
Neither of which actually work with modern versions of Windows FWIW.
Plus emulated watchdogs do not take into account steal time or
overcommit in general. I've seen multiple cases where a naive watchdog
has a problem in the field when the system is under heavy load.
A PV watchdo
sh" is present:
> - for 1.{5.0,5.1,5.2,5.3,6.0}, do nothing,
> - for other versions, pass -device pvpanic
> (knowledge of 0x505 is unneeded)
Just to further complicate things...
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
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Laszlo Ersek 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
&
rowing around nacks just lowers the
overall tone.
If you can't think of anything better to say 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 th
I think
removing is our best option at this point.
Regards,
Anthony Liguori
>
>
> == Support in libvirt for current functionality ==
>
> libvirt will add a element, and possibly a capability
> for it accessible via "virsh capabilities". There are two possibiliti
it.
Even if we had an algorithm for calculating memory overhead (we don't),
glibc will still introduce uncertainty since malloc(size) doesn't
translate to allocating size bytes from the kernel. When you throw in
fragmentation too it becomes extremely 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/archives/libvir-list/2013-August/msg00437.html
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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 I
Peter Maydell writes:
> On 22 May 2013 14:15, Anthony Liguori wrote:
>> Paolo Bonzini 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
>>
m the end user.
So either it's libvirt's problem to solve, or you should expose the
ability to set 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
the same boiler plate bits. I think a lot of configurations
would benefit from being able to set global domain options.
Regards,
Anthony Liguori
>
>
> Daniel
> --
> |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org
fo QEMU currently provides us.
We've talked in the past about having an accelerator specific machine
default. I think this is a perfectly reasonable thing to do and would
solve the problem for ARM and for PPC.
That said, why is mac99 the default? It doesn't seem to work at all for
me.
"Daniel P. Berrange" writes:
> On Thu, May 02, 2013 at 10:40:06AM -0500, Anthony Liguori wrote:
>> Kevin Wolf writes:
>> >> >> +
>> >> >> +if (strcmp(type, "ide-cd") == 0) {
>> >> >> +
Kevin Wolf writes:
> Am 02.05.2013 um 15:41 hat Anthony Liguori geschrieben:
>> Kevin Wolf 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 dev
Applied. Thanks.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Paolo Bonzini writes:
> Il 18/03/2013 15:24, Anthony Liguori ha scritto:
>> "Michael S. Tsirkin" writes:
>>
>>> We need to know the original path since unparenting loses this state.
>>>
>>> Signed-off-by: Michael S. Tsirkin
>>> ---
flow start with the subclass and move up to the base
class.
This avoids needing a hack like this because the object is still in a
reasonable state when unparent is called.
Paolo, do you see anything wrong with this? I looked at the commit you
added this in and it doesn't look like it
"Michael S. Tsirkin" writes:
> On Fri, Mar 08, 2013 at 07:36:28AM -0600, Anthony Liguori wrote:
>> Markus Armbruster writes:
>>
>> > "Michael S. Tsirkin" writes:
>> >
>> >> On Thu, Mar 07, 2013 at 08:57:52PM +0
o address my review comments in a separate patch, go right
> ahead. Please post both together as a series, for coherent review and
> to simplify patch tracking.
>
> I'm asking for two things:
>
> 1. Event member path. Fair to call this "more functionality". I agr
s is *v4*. I think you 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 cou
sense. Additionally, 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
Regards,
Anthony Liguori
>
> [
Eric Blake writes:
> [adding libvirt]
>
> On 03/03/2013 02:05 PM, Anthony Liguori wrote:
>> Paolo Bonzini 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.
>&
s whether
this is a range specification or a disjoint specification but it's more
clear than the previous syntax.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Markus Armbruster writes:
> Anthony Liguori writes:
>
>> Paolo Bonzini writes:
>>
>> What about:
>>
>> [numa]
>> node=1
>> cpus=2
>> cpus=3
>>
>> qemu -readconfig numa.cfg -numa
o this with QOM. The chipset could have a set of link
properties for the integrated devices. For instance:
Q35Chipset
Link integrated_nic;
Link integrated_vga;
...
We should prevent PCI bus plugging for slots "owned" by integrated
devices. libvirt has a way to probe for links that it
Paolo Bonzini 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. L
Eduardo Habkost 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 e
Markus Armbruster writes:
> Anthony Liguori 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 QemuOp
Paolo Bonzini 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 deta
Paolo Bonzini 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
>>
rop this patch by now. I am starting to be convinced that
> "cpus=A,cpus=B,cpus=C" is the best approach. It is not pretty, but at
> least it uses generic parser code instead of yet another ad-hoc
> parser.
No, we cannot rely on this behavior. We had to do it to support
backwards 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
as easy as
> it could be (unless you use Laszlo's opt-visitor), but that could 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:
>>
>&g
Applied. Thanks.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
question. We
> already declared that for qemu 1.3 and beyond, ALL command line behavior
> must ALSO be probe-able via QMP. I think Anthony had a trick for
> testing for existence of various command line options without needing to
> add a new query-strict-boot command, but I don'
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 t
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 t
>>> fixed, so I still don't think we should complicate libvirt by dealing
>>> with it. It is trivial for QEMU maintainers to fix
>>>
>>>
>>> Daniel
>>> --
>>
>> FWIW, the raw tarball from qemu.org still contains the b
Eduardo Habkost writes:
> On Fri, Aug 10, 2012 at 11:37:30AM -0500, Anthony Liguori wrote:
>> Eduardo Habkost writes:
>> >> > - add machine-type-specific cpudef compatibility changes?
>> >>
>> >> I think we've discussed this in IRC. I don&#
Eduardo Habkost writes:
> On Fri, Aug 10, 2012 at 09:43:21AM -0500, Anthony Liguori wrote:
>> Eduardo Habkost writes:
>>
>> > On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote:
>> >> Signed-off-by: Anthony Liguori
>&
Luiz Capitulino writes:
> On Fri, 10 Aug 2012 09:41:20 -0500
> Anthony Liguori wrote:
>
>> Luiz Capitulino writes:
>>
>> > On Fri, 27 Jul 2012 08:37:15 -0500
>> > Anthony Liguori wrote:
>> >
>> >> This provides the same output
Eduardo Habkost writes:
> On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote:
>> Signed-off-by: Anthony Liguori
>> ---
>> target-i386/cpu.c | 22 ++
>> 1 files changed, 22 insertions(+), 0 deletions(-)
>>
>> diff --git
Luiz Capitulino writes:
> On Fri, 27 Jul 2012 08:37:15 -0500
> Anthony Liguori wrote:
>
>> This provides the same output as -M ? but in a structured way.
>>
>> Signed-off-by: Anthony Liguori
>> ---
>> qapi-schema.json | 28 +
Luiz Capitulino writes:
> On Fri, 27 Jul 2012 08:37:14 -0500
> Anthony Liguori 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 it
Luiz Capitulino writes:
> On Fri, 27 Jul 2012 08:37:13 -0500
> Anthony Liguori 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 Ligu
Blue Swirl writes:
> On Fri, Jul 27, 2012 at 3:31 PM, Anthony Liguori wrote:
>> Peter Maydell writes:
>>
>>> On 27 July 2012 15:27, Anthony Liguori wrote:
>>>> Peter Maydell writes:
>>>>> The GCC manual says "Weak symbols are supporte
Eric Blake 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
>> ---
>> qapi-schema.json | 28
>>
Peter Maydell writes:
> On 27 July 2012 14:37, Anthony Liguori 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__((forma
Peter Maydell writes:
> On 27 July 2012 14:37, Anthony Liguori 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 of the cpu select
Peter Maydell writes:
> On 27 July 2012 15:27, Anthony Liguori wrote:
>> Peter Maydell 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 writes:
> On 27 July 2012 14:37, Anthony Liguori 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__((forma
implement this command if it makes sense for them.
Signed-off-by: Anthony Liguori
---
qapi-schema.json | 23 +++
qmp-commands.hx |6 ++
qmp.c|6 ++
3 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qapi-schema.json b/qapi
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:
Basically I'd sum up my new idea as "just u
Signed-off-by: Anthony Liguori
---
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/translate_init.c
+++ b/target
This lets us provide a default implementation of a symbol which targets can
override.
Signed-off-by: Anthony Liguori
---
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
+++ b/compiler.h
We've had a cycle to tweak. It is time to commit to supporting them.
Signed-off-by: Anthony Liguori
---
qapi-schema.json | 19 ---
1 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 015a84a..28e9914 100644
--- a
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
---
qapi-schema.json | 28
qmp-commands.hx |7 +++
qmp.c| 50
This provides the same output as -M ? but in a structured way.
Signed-off-by: Anthony Liguori
---
qapi-schema.json | 28
qmp-commands.hx |6 ++
vl.c | 31 +++
3 files changed, 65 insertions(+), 0 deletions
Signed-off-by: Anthony Liguori
---
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 +28,7 @@
#include
e a specific set of properties you want to control? 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 syste
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
channel for handling
hooks must be responsive.
All libvirt needs 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
exe
have to assume anyway if it crashed).
I really dislike 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,
Ant
oked at the json.org 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
tly have on Qemu.
Reference to previous discussion:
- http://marc.info/?l=qemu-devel&m=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_
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:
reat. I am fully 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,
Ant
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
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 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. The
ilure. Please see the
patches for details on the protocol.
The -open-hook-fd approach allows QEMU to support file descriptor passing
without changing -drive. It also supports snapshot_blkdev and other commands
that re-open image files.
Anthony Liguori wrote most of these patches. I added a
demo
here and move this to qemu-config.h. The declaration can live
there even if the definition is in arch_init.c
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
-no-user-config 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
d=host -device isa-serial,chr=chr0 ...
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
But beyond the justification 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 h
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', &#x
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: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: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 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 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 and
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 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 s
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.
This is
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 refusi
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 f
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
e can have *some* configuration required.
The default configure should have a:
[system]
readconfig=@SYSCONFDIR@/cpu-models-x86_64.cfg
Stanza by default. If libvirt wants to reuse this, they can use -readconfig if
they use -nodefconfig.
Regards,
Anthony Liguori
We still have the bac
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
proces
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 probe
as
"qemu-1.0 -cpu Nehalem", no difference should be visible to the guest.
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 defi
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
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 reus
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 th
1 - 100 of 328 matches
Mail list logo
