On 04/30/2012 09:39 AM, Michael S. Tsirkin wrote:
cpuid eax should return the max leaf so that
guests can find out the valid range.
This matches Xen et al.
What KVM does here predates Xen and Hyper-V.
This is an ABI breaker.
Regards,
Anthony Liguori
Tested using -cpu host.
Signed-off-by
On 04/30/2012 04:17 AM, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
FYI, I won't be able to attend as I'll be at the LF End User Summit.
Regards,
Anthony Liguori
Thanks, Juan.
--
To unsubscribe from this list: send the line &q
ated by the firmware during start up and then
populated in ACPI? Does it do something like take the largest possible DIMM
size that it supports and fill out the table?
At any rate, I think we should focus on modeling this in QOM verses adding a new
option and hacking at the existing memory
t be compressed or stored with inverted
bit ordering.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
uq/master
Pulled. Thanks.
Regards,
Anthony Liguori
Eric B Munson (1):
kvmclock: guest stop notification
Jan Kiszka (2):
kvm: Drop redundant kvm_enabled from cpu_thread_is_idle
kvm: Drop unused kvm_pit_in_kernel
Jason Baron (1):
kvm: set gsi_bits and max_gsi
way, deal w/ hotplug events.
This will be address via QOM. As we convert backends and machine types, we
should be able to dump out the full configuration and send it over the wire.
Regards,
Anthony Liguori
>
> Paolo
>
--
To unsubscribe from this list: send the line &q
1 but I don't think
we intend on using ASN.1 within the code base.
I don't think using ASN.1 to describe devices makes sense. There really aren't
very good Open Source ASN.1 compilers. I also don't think the syntax is
flexible enough to fully describe a device either.
On 03/27/2012 12:42 PM, Jan Kiszka wrote:
On 2012-03-27 18:49, Anthony Liguori wrote:
On 03/27/2012 11:46 AM, Avi Kivity wrote:
On 03/27/2012 06:39 PM, Anthony Liguori wrote:
So, since we're approaching 1.1, we should really discuss release
criteria for 1.1 with respect to live migr
On 03/29/2012 10:17 AM, Avi Kivity wrote:
On 03/29/2012 01:56 PM, Jan Kiszka wrote:
On 2012-03-27 18:39, Anthony Liguori wrote:
On 03/27/2012 11:22 AM, Jan Kiszka wrote:
On 2012-03-27 17:59, Avi Kivity wrote:
On 03/27/2012 11:55 AM, Jan Kiszka wrote:
On 2012-03-27 10:55, Vasilis Liaskovitis
On 03/27/2012 11:46 AM, Avi Kivity wrote:
On 03/27/2012 06:39 PM, Anthony Liguori wrote:
So, since we're approaching 1.1, we should really discuss release
criteria for 1.1 with respect to live migration. I'd prefer to avoid
surprises in this release.
Agree strongly.
My expe
migration works from:
qemu-1.0 -M 1.0 =>qemu-1.1 -M 1.1
qemu-1.1 -M 1.0 <=qemu-1.1 -M 1.0
I would expect that migration works from:
qemu-0.15 -M 0.15 => qemu-1.1 -M 0.15
I'm okay if this fails gracefully:
qemu-1.1 -M 0.15 <= qemu-0.15 -M 0.15
Regards,
g1
outl PORT+2 -> data reg2
outl PORT+N -> data regN
outl PORT -> qemucall of index value with arguments 1..N
Regards,
Anthony Liguori
In fact the feature can be implemented 100% host side by searching for a
panic string signature in the console logs.
--
To unsubscribe from this l
l and s/vmcall/outb/g and call it
a day.
The performance difference between vmcall and outl is so tiny compared to the
cost of dropping to userspace that it really doesn't matter which instruction is
used.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line &q
thing like this.
We have two options I think:
1) We could reserve a portion of the hypercall space to be deferred to userspace
for stuff like this.
2) We could invent a new hypercall like facility that was less bloated than
virtio-serial for stuff like this using MMIO/PIO.
Regards,
Anthony L
,block-ioerror
Likewise, we could have a:
-quit-on guest-panicked.
In the very least, we should make what we use for rerror,werror an enumeration
that's shared here.
Regards,
Anthony Liguori
pause - emit QEVENT_GUEST_PANICKED and pause VM
stop - emit QEVENT_GUEST_PANICKED and
On 03/19/2012 06:52 PM, Rusty Russell wrote:
On Mon, 19 Mar 2012 17:13:06 -0500, Anthony Liguori
wrote:
Maybe just make this a hidden option like x-miio?
x-violate-the-virtio-spec-to-trick-old-linux-drivers-into-working-on-power?
"To configure the device, we use the first I/O regi
On 03/19/2012 04:29 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 04:07:45PM -0500, Anthony Liguori wrote:
On 03/19/2012 03:49 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
Currently
On 03/19/2012 03:49 PM, Michael S. Tsirkin wrote:
On Mon, Mar 19, 2012 at 02:19:33PM -0500, Anthony Liguori wrote:
On 03/19/2012 10:56 AM, Michael S. Tsirkin wrote:
Currently virtio-pci is specified so that configuration of the device is
done through a PCI IO space (via BAR 0 of the virtual
fault but causes segfaults in memory.c
when enabled. Thus an RFC until I figure out what's wrong.
Doesn't this violate the virtio-pci spec?
Making the same vendor/device ID have different semantics depending on a magic
flag in QEMU seems like a pretty bad idea to me.
Regards,
On 03/14/2012 01:58 AM, Corentin Chary wrote:
Hi Anthony,
Please merge these two patchs from another age, they fix crash in the VNC
server (the iohandler one is only for the threaded server).
Applied. Thanks.
Regards,
Anthony Liguori
Thanks,
Corentin Chary (1):
vnc: don't me
wishlist, as done for 1.0, is probably not going to work well, but
collecting a rough list or dependency tree would be nice for planning.
The wiki isn't closed... I would hope most contributors would have an account
and/or would not have a problem asking for an account.
Regards,
Antho
create mode 100755 scripts/kvm/kvm_flightrecorder
I assume this should go through uq/master...
Thanks for sending this out.
Regards,
Anthony Liguori
diff --git a/scripts/kvm/kvm_flightrecorder b/scripts/kvm/kvm_flightrecorder
new file mode 100755
index 000..7fb1c2d
--- /dev/nu
On 03/08/2012 06:49 AM, Marcelo Tosatti wrote:
The following changes since commit e32605062cd62c2a958ad28a6ad7de4eeab12027:
xilinx_zynq: machine model initial version (2012-03-07 02:20:19 +0100)
Pulled. Thanks.
Regards,
Anthony Liguori
are available in the git repository at:
git
Hardware addresses should be independent of the target. If we wanted to use a
hw_addr_t that would be okay too.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
/virt/kvm/qemu-kvm.git memory/urgent
Pulled. Thanks.
Regards,
Anthony Liguori
Avi Kivity (1):
kvm: fix unaligned slots
kvm-all.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a
l.
Please pull from:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
Pulled. Thanks.
Regards,
Anthony Liguori
Avi Kivity (1):
pc-bios: update kvmvapic.bin
Gleb Natapov (1):
kvm: Synchronize cp
I do:
blockdev-start-transaction
stop
drive-reopen
drive-mirror
blockdev-end-transaction
What state should I expect that my guest is in (paused or running)?
Regards,
Anthony Liguori
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a me
ai
Cc: Matt Evans
Cc: Ron Minnich
Cc: Anthony Liguori
Cc: John Floren
Cc: Sasha Levin
Cc: Cyrill Gorcunov
Cc: Asias He
Cc: Ingo Molnar
Signed-off-by: Pekka Enberg
---
tools/kvm/Makefile |2 +
tools/kvm/builtin-run.c | 32 +++--
tools/kvm/incl
hael S. Tsirkin
Reviewed-by: Anthony Liguori
I think we're safe here from a compatibility perspective.
Regards,
Anthony Liguori
---
hw/pci_bridge.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
index fea3873..eee
tand as an alternative to 4K.
Regards,
Anthony Liguori
---
drivers/virtio/virtio_balloon.c | 18 +-
include/linux/virtio_balloon.h |4 +++-
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
ind
;s patches. I'll make sure to look at them this
week to try to get something merged.
Regards,
Anthony Liguori
Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PROP_PTR users)
CC: Paolo Bonzini
Applied. Thanks.
Regards,
Anthony Liguori
Jan Kiszka (7):
i8254: Do not raise IRQ level on reset
hpet: Save/restore cached RTC IRQ level
i8254: Factor out interface header
i8254: Pass alternative IRQ output object on initialization
i8254: Rework
On 02/16/2012 02:57 AM, Gleb Natapov wrote:
On Wed, Feb 15, 2012 at 03:59:33PM -0600, Anthony Liguori wrote:
On 02/15/2012 07:39 AM, Avi Kivity wrote:
On 02/07/2012 08:12 PM, Rusty Russell wrote:
I would really love to have this, but the problem is that we'd need a
general purpose byteco
Pulled. Thanks.
Regards,
Anthony Liguori
Jan Kiszka (3):
kvm: Allow to set shadow MMU size
kvm: Implement kvm_irqchip_in_kernel like kvm_enabled
apic: Fix legacy vmstate loading for KVM
hw/apic_common.c |7 ++-
hw/pc.c |4 ++--
hw/pc_piix.c
w CR3 but maybe that
wouldn't be so bad with VPIDs.
Then you could implement the PIT as guest firmware using kvmclock as the time
base.
Once you're back in the guest, you could install the old CR3. Perhaps just hide
a portion of the physical address space with the e820.
Regard
ble sizes?
Can we just use a fixed size (pre-allocated) array and then use a
VMSTATE_SUB_ARRAY?
If it's truly variable size with no upper bound, then that's actually a security
problem since it implies a guest can do unbounded memory allocation.
Regards,
Anthony Liguori
- PMM
On 02/07/2012 12:17 PM, Andreas Färber wrote:
Am 07.02.2012 19:01, schrieb Anthony Liguori:
On 02/07/2012 07:45 AM, Andreas Färber wrote:
http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html
How is the realize step (DeviceState::init) supposed to translate to
Object-derived
:
Remove the support for yield_on_hlt.
Signed-off-by: Raghavendra K T
Acked-by: Anthony Liguori
Regards,
Anthony Liguori
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d29216c..2fb3009 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -70,9 +70,6 @@ module_param
s what the time planning
for the 4th QOM series looks like. Are there things that developers of
new devices should keep in mind / start doing differently wrt SysBus?
I think I answered this elsewhere.
Regards,
ANthony Liguori
Andreas
--
To unsubscribe from this list: send the line "uns
ways change it later.
For PC-style machines I'd expect board-level stuff like the CPUs to
appear directly under /. That would roughly correspond to the
OpenFirmware device tree then.
I think devices trees are a bad example that should not be emulated.
Regards,
Anthony Liguori
--
To u
On 02/07/2012 10:27 AM, Paolo Bonzini wrote:
On 02/07/2012 05:24 PM, Anthony Liguori wrote:
I'm wary of all plans that require to go through all the code once. What about
simply /devices/default/child[...] or something like that?
The paths would be unstable, but maybe that's okay. I
On 02/07/2012 09:21 AM, Paolo Bonzini wrote:
On 02/07/2012 03:56 PM, Anthony Liguori wrote:
Another related question is, should the 4th QOM series present a full
composition tree based on the legacy qdev bus concept?
Composition, no. The legacy qbus concept doesn't model composition
be
On 02/07/2012 10:18 AM, Jan Kiszka wrote:
On 2012-02-07 17:02, Avi Kivity wrote:
On 02/07/2012 05:17 PM, Anthony Liguori wrote:
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have
t
On 02/07/2012 10:02 AM, Avi Kivity wrote:
On 02/07/2012 05:17 PM, Anthony Liguori wrote:
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have to put the
kthread to sleep while it wait
kernel since two
threads are likely going to be accessing it at the same time. That either means
an expensive sync operation or a reliance on atomic instructions.
But not all architectures offer non-word sized atomic instructions so it gets
fairly nasty in practice.
Regards,
Anthony Liguor
On 02/07/2012 06:03 AM, Avi Kivity wrote:
On 02/06/2012 09:11 PM, Anthony Liguori wrote:
I'm not so sure. ioeventfds and a future mmio-over-socketpair have to put the
kthread to sleep while it waits for the other end to process it. This is
effectively equivalent to a heavy weight exit
On 02/07/2012 07:18 AM, Avi Kivity wrote:
On 02/07/2012 02:51 PM, Anthony Liguori wrote:
On 02/07/2012 06:40 AM, Avi Kivity wrote:
On 02/07/2012 02:28 PM, Anthony Liguori wrote:
It's a potential source of exploits
(from bugs in KVM or in hardware). I can see people wanting to be
sele
ple
instances, we'll have to fix it up manually but that really shouldn't be all
that hard.
That gives us composition paths and a clear goal for removing the legacy paths
(we'd want to work toward eliminating /legacy-machine).
device_add doesn't use qdev_create() and ne
On 02/07/2012 06:40 AM, Avi Kivity wrote:
On 02/07/2012 02:28 PM, Anthony Liguori wrote:
It's a potential source of exploits
(from bugs in KVM or in hardware). I can see people wanting to be
selective with access because of that.
As is true of the rest of the kernel.
If you want
On 02/06/2012 01:46 PM, Scott Wood wrote:
On 02/03/2012 04:52 PM, Anthony Liguori wrote:
On 02/03/2012 12:07 PM, Eric Northup wrote:
On Thu, Feb 2, 2012 at 8:09 AM, Avi Kivity wrote:
[...]
Moving to syscalls avoids these problems, but introduces new ones:
- adding new syscalls is
evice model stuff in the kernel.
ioeventfd to userspace is almost certainly worse for performance. And Avi
mentioned, you can emulate this behavior yourself in userspace if so inclined.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" i
On 02/06/2012 07:54 AM, Avi Kivity wrote:
On 02/06/2012 03:33 PM, Anthony Liguori wrote:
Look at arch/x86/kvm/i8254.c:pit_ioport_read() for a counterexample.
There are also interactions with other devices (for example the
apic/ioapic interaction via the apic bus).
Hrm, maybe I'm missi
On 02/06/2012 03:34 AM, Avi Kivity wrote:
On 02/05/2012 06:36 PM, Anthony Liguori wrote:
On 02/05/2012 03:51 AM, Gleb Natapov wrote:
On Sun, Feb 05, 2012 at 11:44:43AM +0200, Avi Kivity wrote:
On 02/05/2012 11:37 AM, Gleb Natapov wrote:
On Thu, Feb 02, 2012 at 06:09:54PM +0200, Avi Kivity
as a mechanism (which would allow clearing the
notify flag before writing to an eventfd).
We could potentially just use BPF for this.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More ma
?
It's not a finite or privileged resource.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
uation,
but better for things like strace.
Look pretty interesting overall.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tps://github.com/aliguori/qemu/tree/qom-upstream.13
Regards,
Anthony Liguori
Jan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/31/2012 04:48 PM, Jan Kiszka wrote:
On 2012-01-31 23:40, Anthony Liguori wrote:
Why is what's in the tree not usable?
Just don't do pcspk_init as a static inline (which is not that nice to
do anyway) and you don't need to worry about the availability of an
accessor.
The
On 01/31/2012 04:00 PM, Jan Kiszka wrote:
On 2012-01-31 21:49, Anthony Liguori wrote:
On 01/31/2012 11:41 AM, Jan Kiszka wrote:
Convert the PC speaker device to a qdev ISA model. Move the public
interface to a dedicated header file at this chance.
Signed-off-by: Jan Kiszka
Heh, I did this
On 01/31/2012 04:05 PM, Jan Kiszka wrote:
On 2012-01-31 22:02, Anthony Liguori wrote:
On 01/31/2012 11:41 AM, Jan Kiszka wrote:
In legacy mode, the HPET suppresses the RTC interrupt delivery via IRQ
8 but keeps track of the RTC output level and applies it when legacy
mode is turned off again
On 01/31/2012 03:49 PM, Jan Kiszka wrote:
On 2012-01-31 22:40, Anthony Liguori wrote:
On 01/31/2012 12:46 PM, Jan Kiszka wrote:
Applying the concept used for the *PICs once again: establish a base
class for the i8254 that can be used both by the current user space
emulation and the upcoming
e PIT and then
overrides whatever virtual functions it needs to.
Regards,
Anthony Liguori
---
Makefile.objs |2 +-
hw/i8254.c | 277 ++---
hw/i8254_common.c | 311 +++
set. As such, we can't use a subsection here. We need to
bump the savevm state.
Regards,
Anthony Liguori
static const VMStateDescription vmstate_hpet_timer = {
.name = "hpet_timer",
.version_id = 1,
@@ -273,6 +291,14 @@ static
pcspk_ioport_write, s);
+static DeviceInfo pcspk_info = {
+.name = "isa-pcspk",
+.size = sizeof(PCSpkState),
+.no_user= 1,
+.props = (Property[]) {
+DEFINE_PROP_HEX32("iobase", PCSpkState, iobase, -1),
+DEFINE_PROP
On 01/31/2012 08:09 AM, Avi Kivity wrote:
On 01/31/2012 03:59 PM, Anthony Liguori wrote:
On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
QOM roadmap update:
* Series 3/4 is on the list
On 01/31/2012 07:15 AM, Andreas Färber wrote:
Am 31.01.2012 00:53, schrieb Anthony Liguori:
On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
VMState:
Anthony specifically said that
I ask for a hard device freeze until merged.
I.e., no new devices and no conflicting changes to DeviceInfo.
I put together a few slides to help this discussion:
http://www.codemonkey.ws/files/qom-overview.pdf
Regards,
Anthony Liguori
* Further roadmap: i440FX, CPU, MemoryRegion (whe
on the list.
Yes, I'm falling victim to perfectionism here attempting to find a clever online
voting mechanism. I'm just going to hold a vote over the mailing list. I'll
post an email tomorrow with details.
Regards,
Anthony Liguori
Andreas
--
To unsubscribe from this list:
bits? I
would expect this through uq/master.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ct that we have two different implementations of the same device.
We need to expose this information to the user in some fashion. The type is the
natural way to do it.
Regards,
Anthony Liguori
Moreover, see http://thread.gmane.org/gmane.comp.emulators.qemu/129659,
QOM will allow addre
attribute (selecting the backend). What
happened now?
They have different *type* names. They can have the same *object* name.
All user interaction with a device should be through object name. The type name
is merely an implementation detail.
Regards,
Anthony Liguori
--
To unsubscribe from
On 01/24/2012 08:03 AM, Paolo Bonzini wrote:
On 01/24/2012 02:57 PM, Anthony Liguori wrote:
Please send in any agenda items you are interested in covering.
I don't have anything pressing. I vote to cancel the call.
Nothing that cannot be discussed by email, but anyway here are a coup
On 01/23/2012 11:38 AM, Markus Armbruster wrote:
Please send in any agenda items you are interested in covering.
I don't have anything pressing. I vote to cancel the call.
Regards,
Anthony Liguori
Cheers,
Markus
--
To unsubscribe from this list: send the line "unsubscribe k
/master
Applied. Thanks.
Regards,
Anthony Liguori
Jan Kiszka (18):
msi: Generalize msix_supported to msi_supported
kvm: Move kvmclock into hw/kvm folder
apic: Stop timer on reset
apic: Inject external NMI events via LINT1
apic: Introduce
reasonable to default to -cpu host in upstream QEMU? And
what would a sane default look like?
What are the arguments against -cpu host?
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More
er", cont_type, cont_var.master, 0, false)
+
+void pic_init_common(PICCommonState *s);
+void pic_reset_common(PICCommonState *s);
+
+ISADevice *i8259_init_chip(const char *name, ISABus *bus, bool master);
Same feedback here re: i8259_qdev_register().
Regards,
Anthony Liguori
+#endif /
ister(APICCommonInfo *). Then you
can set info->qdev.vmsd = &vmstate_apic_common and avoid having to make it extern.
Regards,
Anthony Liguori
+
+#endif /* !QEMU_APIC_INTERNAL_H */
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/11/2012 02:05 PM, Alexander Graf wrote:
On 11.01.2012, at 20:59, Anthony Liguori wrote:
On 01/11/2012 01:53 PM, Alexander Graf wrote:
On 11.01.2012, at 20:52, Anthony Liguori wrote:
IIRC, we never had this problem with qemu-kvm - as the merges were
coordinated with the kernel
On 01/11/2012 01:53 PM, Alexander Graf wrote:
On 11.01.2012, at 20:52, Anthony Liguori wrote:
IIRC, we never had this problem with qemu-kvm - as the merges were
coordinated with the kernel (subsystem) tree.
Are you suggesting that kvm header updates go through uq/master? That seems
On 01/11/2012 01:48 PM, Jan Kiszka wrote:
On 2012-01-11 20:46, Alexander Graf wrote:
On 11.01.2012, at 20:41, Anthony Liguori wrote:
On 01/11/2012 01:38 PM, Jan Kiszka wrote:
I would like to see us avoiding this in the future. Headers update
patches should mention the source and should
s. I think that's a good
strategy here too. It's a little painful, but not entirely awful.
At least it makes it possible for you to (hopefully) trivial rebase a patch if
something is still in limbo.
Regards,
Anthony Liguori
Jan
--
To unsubscribe from this list: send the line &q
stuff
that's in qemu.git now hasn't managed to get upstream yet.
I don't think it's a broken process. I think you made a reasonable set of
assumptions. I think it was just an exceptional circumstance.
Regards,
Anthony Liguori
--
To unsubscribe from this list: s
wap16(val);
+#endif
I think this is the only reasonable way to do it, but I'd suggest adding
target_is_bigendian() to arch_init.c that way we wouldn't have to move the
object from libhw.
Regards,
Anthony Liguori
+return val;
}
static uint32_t virtio_pci_config_readl(void *opaque,
ll distributions gets it.
Indeed, "referring to it in our documentation" was a polite way of saying, it's
a distro problem :-)
The distro should let you choose a profile during installation or something like
that.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
If w
On 01/01/2012 04:16 AM, Dor Laor wrote:
On 12/29/2011 06:16 PM, Anthony Liguori wrote:
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
On 01/03/2012 07:57 AM, Peter Maydell wrote:
On 3 January 2012 13:37, Anthony Liguori wrote:
For what you're getting at, you actually want to model the CPUs in QOM such
that you would have an ARM926 is-a ARMCPU is-a CPUCommon.
Then you could have the beagle machine have a link. If it a
On 01/03/2012 07:52 AM, Andreas Färber wrote:
Anthony,
Am 03.01.2012 02:04, schrieb Anthony Liguori:
On 01/02/2012 07:46 AM, Andreas Färber wrote:
Am 02.01.2012 13:09, schrieb Juan Quintela:
First of all, Happy New Year to everybody (even for the people whose
calendar is different O:-)
+1
On 01/03/2012 04:26 AM, Peter Maydell wrote:
On 3 January 2012 01:14, Anthony Liguori wrote:
Let's separate out what a user *should* do from what a user *can* do.
A user *should* have a command line syntax that reflects something that
makes sense to them. For instance, qemu-syste
ne
I don't really care what the SoC or CPU in my beaglebone is. I just want to
emulate one.
But I do believe we want to make it possible for -device to create a CPU even
when it doesn't make sense.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscrib
oing to be with us for some time---at least it's not
disappearing soon enough that we should halt any development in that area.
Yeah, as I mentioned in my other note, I think it's more or less orthogonal to
QOM.
Regards,
Anthony Liguori
Paolo
--
To unsubscribe from this list: send
otic things.
There are some notes that I haven't responded to yet as I've been AFK for the
past few days, but I will most likely tomorrow.
Regards,
Anthony Liguori
Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
things to
test.
It's also not clear to me why post-copy is better. If you were going to sit
down and explain to someone building a management tool when they should use
pre-copy and when they should use post-copy, what would you tell them?
Regards,
Anthony Liguori
--
To unsubscribe from
e the optimal
settings of the host kernel (maybe similar one for the guest).
What are "appropriate host settings" and why aren't we suggesting that distros
and/or upstream just set them by default?
Regards,
Anthony Liguori
HTH,
Dor
--
To unsubscribe from th
kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
Pulled. Thanks.
Regards,
Anthony Liguori
Gleb Natapov (1):
enable architectural PMU cpuid leaf for kvm
Jan Kiszka (3):
kvm: x86: Use symbols for all xsave field
kvm: x86: Avoid runtime allocation of xsave buffer
global warming, I think I'm going to have to jump
off a bridge to end the madness...
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
On 12/20/2011 04:20 PM, Jan Kiszka wrote:
On 2011-12-20 22:55, Anthony Liguori wrote:
The components of the path are the *property* names of the parent
device. In the case of the local APIC, you would have something like:
/cpus/cpu0/apic
/cpus/cpu1/apic
Which would be links on the
On 12/20/2011 03:45 PM, Jan Kiszka wrote:
On 2011-12-20 22:38, Anthony Liguori wrote:
I'm not talking about migration here, I'm talking about qtree
addressability. That is orthogonal, at least right now.
qtree is not an ABI. The output of info qtree can (and will) change
over time
On 12/20/2011 03:23 PM, Jan Kiszka wrote:
On 2011-12-20 20:14, Anthony Liguori wrote:
On 12/20/2011 11:02 AM, Jan Kiszka wrote:
On 2011-12-20 15:07, Anthony Liguori wrote:
On 12/20/2011 07:57 AM, Paolo Bonzini wrote:
On 12/20/2011 02:54 PM, Anthony Liguori wrote:
In QOM parlance Jan
On 12/20/2011 11:02 AM, Jan Kiszka wrote:
On 2011-12-20 15:07, Anthony Liguori wrote:
On 12/20/2011 07:57 AM, Paolo Bonzini wrote:
On 12/20/2011 02:54 PM, Anthony Liguori wrote:
In QOM parlance Jan implemented this:
abstract class Object
abstract class Device
class APIC: { backend: link
On 12/20/2011 07:57 AM, Paolo Bonzini wrote:
On 12/20/2011 02:54 PM, Anthony Liguori wrote:
In QOM parlance Jan implemented this:
abstract class Object
abstract class Device
class APIC: { backend: link }
abstract class APICBackend
class QEMU_APICBackend
class KVM_APICBackend
I don&#
201 - 300 of 2347 matches
Mail list logo
