or when encountering an unsupported option.
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
ve now isn't working.
I'm with you. I think at this point we should try to make the qemu-kvm
code use the upstream QEMU code where ever possible and then refactor
the qemu-kvm into a mergable state.
A good second step would be getting rid of libkvm entirely.
Regards,
Anthony Liguo
t things back into shape?
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
amp; Regards,
> Nitin
>
It may make sense to expose this as a CAP down to userspace.
We could possibly make better error messages in userspace when we get an
unknown vmexit failure on pre-wsm hardware.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe
Bike & Snow wrote:
Hello
Is anyone using OCFS2 on a SAN based setup (in my case iSCSI) for a
shared storage setup for KVM?
I've got a really nice setup that works really well and gives very
good performance.
What version of KVM? What command line are you using?
Regards,
Anthon
true root cause of VMware VGA not working correctly under KVM and
likely also an issue with some of the std-vga black screen issues too.
Cirrus does not enable VBE so it would not be a problem when using Cirrus.
Signed-off-by: Anthony Liguori
---
hw/vga.c| 35
This is needed for VMware VGA to work properly under KVM.
Signed-off-by: Anthony Liguori
---
hw/vmware_vga.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index bb17698..246011b 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
Anthony Liguori wrote:
This is needed for VMware VGA to work properly under KVM.
Signed-off-by: Anthony Liguori
---
hw/vmware_vga.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index bb17698..246011b 100644
--- a/hw/vmware_vga.c
hopefully not too far away), no user of
that header will remain and we will be able to drop it again.
I'm fine with whatever anthony wants.
I'm fine with either solution as they are both temporary measures...
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the l
g and add it, rather than just generate an entirely new
config
What's the problem with parsing the device config and modifying it? Is
it just complexity?
If we provided a mechanism to simplify manipulating a device config,
would that eliminate the concern here?
Regards,
Antho
file
How is compat hints different from a device tree?
In my mind, that's what compat hints is. I don't see another sane way
to implement it.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@
Mark McLoughlin wrote:
On Fri, 2009-06-12 at 09:51 -0500, Anthony Liguori wrote:
Mark McLoughlin wrote:
On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
Michael S. Tsirkin wrote:
I think the right long term answer to all this is a way to get QEMU to
dump
Mark McLoughlin wrote:
On Fri, 2009-06-12 at 09:55 -0500, Anthony Liguori wrote:
Mark McLoughlin wrote:
On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
= Solution - Separate configuration from compat hints =
As I suggested before:
- Allow the VM manager to dump compat
ition would contain some sort of symbolic node name. A
separate mechanism (either command line or host config file) would then
link a image file to the symbolic name.
libvirt should really never worry about the machine config file for
normal things unless it needs to change what devices ar
ecall seeing a patch...
I think it's a perfectly fine idea.
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
lah
-drive file=foo.img,controller=blah,index=0
-drive file=bar.img,controller=blah,index=1
Drives to not have pci addresses.
Drivers don't have indexes and buses but we specify it on the -drive
line. -drive is convenient syntax. It stops being convenient when you
force it to be two option
sts. I don't think games with configuration files can hide
that.
-M pc1
-M pc2
etc.
This is pretty easy to maintain with config files.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...
-rotten patches for pci_addr=, and I can unrot them if they're
wanted.
Yes, would be good to have patches on the list to discuss. In
principle, I have no objection to this.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the bo
, then query it to see what slot it
assigned and remember that.
It's not a good idea to have management applications attempt to do PCI
slot allocation. For instance, one day we may decide to make virtio
devices multi-function.
Regards,
Anthony Liguori
--
To unsubscribe from this list:
Avi Kivity wrote:
On 06/15/2009 03:45 PM, Anthony Liguori wrote:
This last option makes sense to me: in a real world the user has
control over where he places the device on the bus, so why
not with qemu?
Yes, the user build the machine using the command line and monitor
(or, in 2017, the
Avi Kivity wrote:
On 06/15/2009 03:52 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote:
We should just tell the user which slots are open.
This might be tricky if the config is passed in with the command
line
flags.
qemu -show-available-pci
s
of whether that's a few months from now or a decade :-)
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
Avi Kivity wrote:
On 06/15/2009 04:20 PM, Anthony Liguori wrote:
It's not at all that simple. SCSI has a hierarchical address
mechanism with 0-7 targets but then potentially multiple LUNs per
target. Today, we always emulate a single LUN per target but if we
ever wanted to support
Avi Kivity wrote:
On 06/15/2009 04:23 PM, Anthony Liguori wrote:
How would qemu know which slots to optimize for?
In practice, I don't see that as a real problem. We should (a) add an
ioapic and four more pci links (b) recommend that slots be assigned in
ascending order, and every
Mark McLoughlin wrote:
On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
Eventually the
default configuration becomes increasingly unusable and you need a new
baseline. You must still be able to fall back to the old baseline for
older guests. I don't think games
it with respect to the "genesis" use-case where libvirt has
no specific reason to choose one PCI slot over another. In that case,
I'm merely advocating that we want to let QEMU make the decision.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "
we want to let QEMU make the decision.
The allocation code could be moved out into a library, and libvirt could
link with it (ducks).
Why does libvirt want to do allocation?
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm"
easier to implement. Basically, when adding a device to
it's parent, you hand the parent the "addr" field and that lets you say
where you want to sit on the bus.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a m
hat it
simplifies things for management tools as they don't have to keep track
of "capabilities" that we're adding. Heck, you could even do:
pc-0034
Where "pc-%08x" % (capabilities) :-)
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the li
the
discussion.
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
and error-prone. Some
sanity could be added by using addressing prefixes like addr=pci:00:01.0
or addr=scsi:0.3 but I'll leave that up to whoever takes this on.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a me
est-visible way,
introduce a new machine type
- Use explicit versions in name: pc-v1, pc-v2 or use more descriptive
names pc-with-usb
- Easily transitions to device config files
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the bod
Avi Kivity wrote:
On 06/15/2009 09:12 PM, Anthony Liguori wrote:
2) Whenever the default machine type changes in a guest-visible way,
introduce a new machine type
s/whenever/qemu stable release/
- Use explicit versions in name: pc-v1, pc-v2
pc-qemu-0.10?
This is similar to a hardware
ration.
Is anyone working on fixing this? Does anyone have a clever idea how to
fix this without just waiting for all IO requests to complete?
---
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger
oken due to the qdev changes?
--
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
have to call a callback and pass
an opaque with the results. The callback/opaque cannot be saved in the
block layer in a meaningful way.
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.o
warning (virtio_load decl/def does not match).
--
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
stake to gate the release on qdev.
--
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
information.
I've already begun using this bug tracker so you can look through it
today to get a feeling for what it's like.
https://bugs.launchpad.net/qemu
https://bugs.launchpad.net/qemu/+bugs
https://dev.launchpad.net/OpenSourcing
--
Regards,
Anthony Liguori
--
To unsubscribe from this
it by default. One can disable it by using: -cpu qemu64,-hypervisor
Fix some whitespace damage on the way.
Signed-off-by: Andre Przywara
Please also resend 2/2.
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
Blue Swirl wrote:
On 6/23/09, Anthony Liguori wrote:
Hi,
It's getting to be about the time to start thinking about the 0.11.0
release. 0.10.0 was released on March 2nd so following with the 6 month
release cycle, that would put 0.11.0 at September 2nd.
Based on the experiences wit
This introduces some #ifdefs in pcspk to fix the build when KVM isn't enabled.
Signed-off-by: Anthony Liguori
---
hw/pcspk.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/hw/pcspk.c b/hw/pcspk.c
index 9e1b59a..236995a 100644
--- a/hw/pcspk.c
+++
This gets ppc-softmmu building when KVM is not enabled. It may be enough to get
it working with KVM enabled but I haven't checked.
Signed-off-by: Anthony Liguori
---
hw/ppc440.c|1 +
hw/ppc440_bamboo.c |1 +
hw/ppce500_mpc8544ds.c |1 +
qemu-kvm.h |
ppcemb-softmmu uses upstream KVM support so put an appropriate guard around it.
This fixes the non-KVM ppcemb-softmmu build.
Signed-off-by: Anthony Liguori
---
configure |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 420e101..4bad3c3 100755
I don't know why this is disabled for qemu-kvm.git.
Signed-off-by: Anthony Liguori
---
configure |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 4bad3c3..1b73eaf 100755
--- a/configure
+++ b/configure
@@ -2117,13 +2117,12 @@ configur
Dustin Kirkland wrote:
On Wed, 2009-06-24 at 17:40 -0500, Anthony Liguori wrote:
I don't know why this is disabled for qemu-kvm.git.
Signed-off-by: Anthony Liguori
---
configure |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
I don't know why this is disabled for qemu-kvm.git.
Signed-off-by: Anthony Liguori
--
v1 -> v2 Fix typo
---
configure |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 4bad3c3..0e65edb 100755
--- a/configure
+++ b/configure
@@
7;s already changed in staging.
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
isk image onto /dev/mapper/my-multipathed-iscsi-disk?
You need to create a partition table and setup grub in order to be able
to use something as -hda. You don't get that automatically with
debootstrap.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kv
ve qcow is broken? Is it
only broken for writes and not reads?
If we're printing a warning, does that mean we want to deprecate qcow
and eventually remove it (or remove write support, at least)?
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe k
y concerned that there is data corruption in the
write path, we should disable it to keep a user from shooting themselves
in the foot.
Regards,
Anthony Liguori
Paul
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kern
running qemu
without DISPLAY set.
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
process received the signal.
Are you testing the patches via something like that?
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
at refactoring -drive and
completely splitting this stuff. I think we ought to come up with a
syntax where we can pass file names as independent arguments so that no
special escaping is required.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm&q
int13 functions for LILO.
If you have the option, switching to an IDE disk may be a work around.
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
Mark McLoughlin wrote:
Hi Anthony,
On Mon, 2009-06-22 at 18:57 -0500, Anthony Liguori wrote:
Hi,
It's getting to be about the time to start thinking about the 0.11.0
release. 0.10.0 was released on March 2nd so following with the 6 month
release cycle, that would put 0.11.0 at Sept
mp;dev->lock)
I know it's not strictly needed for PCI pass through, but it would be
useful to register the IO regions via UIO. The userspace implementation
would then use UIO strictly instead of poking the sysfs pci info
directly. I think that ends up being cleaner.
Regards,
ed yet?
Spent some time bisecting this just to find out it's already
fixed. I'm unable to migrate w/o this one.
It was just posted on Sunday, give a chance for people to review it and
apply.
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "uns
Michael S. Tsirkin wrote:
On Thu, Jul 09, 2009 at 09:54:43AM -0500, Anthony Liguori wrote:
I know it's not strictly needed for PCI pass through, but it would be
useful to register the IO regions via UIO. The userspace implementation
would then use UIO strictly instead of poking the
his needs rebasing and I'd like to see a few folks ack it first 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
Markus Armbruster wrote:
Anthony Liguori writes:
Any hope that -device can make the cut?
I've got most of the outstanding patches in staging now. The only thing
missing is the PIIX refactoring from Isaku which I suspect is going to
fuzz badly. -device is there.
I'll be te
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the
ating
vcpus as threads vs. treating them as processes. I'm not qualified to
appreciate the difference so I'm inclined to side with Paul. Am I
missing something there?
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm"
Kevin Wolf wrote:
Anthony Liguori schrieb:
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
If I'm no
7;m inclined to side with Paul. Am I
missing something there?
I interpreted [1] as that the rest is OK for Paul.
Paul, can you clarify?
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.ke
Kevin Wolf wrote:
Anthony Liguori schrieb:
Jan Kiszka wrote:
Hmm, I must have missed this: Where is your staging tree hosted?
Right now it's at http://repo.or.cz/w/qemu/aliguori-queue.git but I plan
to move it to git.qemu.org in the next few days.
If I'm no
Christoph Hellwig wrote:
On Fri, Jul 10, 2009 at 11:59:25AM -0500, Anthony Liguori wrote:
If I'm not mistaken, the patch "qemu-io: Implement
bdrv_get_buffer/bdrv_put_buffer" is missing from the queue.
I just did a pull a few hours ago from Christoph's qemu-io t
appy pulling in the patches
from the mailing list.
Christoph, would you be so kind to push the patch to your queue and fill
the pull request form for Anthony in three copies, signed and with
official stamp...?
Don't forget to get it notarized after committee approval.
Regards,
Ant
or objection to vCont.
The thread bits are the wrong way to do things, but are probably relatively
harmless for now. Expect me to remove them at the first available opportunity.
I'll queue 1-3 then and we'll leave 4 for post-0.11 debate.
Regards,
Anthony Liguori
--
To unsubscribe
Christoph Hellwig wrote:
On Fri, Jul 10, 2009 at 12:29:25PM -0500, Anthony Liguori wrote:
Sorry, I'm not able to follow you here. What is currently queued and
what do you think should be queued? Can you provide links/commit hashes?
Currenly queued:
http://repo.or.cz/w
ct the MCE.
This patch (now in the qemu tree) breaks compilation for me on i386:
/home/hch/work/qemu/target-i386/helper.c: In function
'cpu_inject_x86_mce':
/home/hch/work/qemu/target-i386/helper.c:1510: error: left shift count >= width
of type
I pushed a fix to master.
Regards,
let).
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
te -f raw
file.raw 1024` you would see a file of 1024 bytes.
Not sure if the docs is wrong or this behavior changed. Patch either
way would be appreciated/accepted.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to ma
ing to do is to make the filename an
independent argument.
--
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
Kevin Wolf wrote:
Anthony Liguori schrieb:
Blue Swirl wrote:
I bet this won't compile on win32.
Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg
. How about:
-drive name=vda,if=virtio -drive.vda.file filename.img
What's nice about this syntax is it generalizes well. You could have:
-drive.vda.if virtio -drive.vda.file filename.img
-net nic,model=rtl8139,name=foo -net.foo.macaddr 00:11:43:55:44:22
--
Regards,
Anthony Liguori
know this goes against the current momentum in qemu, but overloading
one option with a bunch of parameters seems absolutely silly to me.
IMHO, -drive file=foo.img,if=virtio,cache=off should have always been at
least three parameters.
--
Regards,
Anthony Liguori
--
To unsubscribe from this list
Jamie Lokier wrote:
Anthony Liguori wrote:
Jan Kiszka wrote:
We would still have to deal with the fact that so far '\' had no special
meaning on Windows - except that is was the well-known path separator.
So redefining its meaning would break a bit...
That's th
uch a change.
Or you have to quote differently on Windows which means you throw
consistency out the Window.
I certainly like consistency but I don't see a viable proposal that
offers that.
Regards,
Anthony Liguori
-- Jamie
--
To unsubscribe from this list: send the line "unsubscr
Markus Armbruster wrote:
Anthony Liguori writes:
Blue Swirl wrote:
Then how about something like:
-drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
-drive name=vda,if=virtio,cache=writeback,file_comes_next -patharg foo.img
-drive name=sdb,if=scsi,unit=1,fnarg -fnarg
.release = xinterface_release,
+};
How do you deal with locking?
The mappings (gpa_to_page) are not fixed. They can and do change very
often. The interface doesn't seem to attempt to cope with this.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line &qu
tion
Regards,
-Greg
--
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
nux.c:464: error: 'struct usbdevfs_urb' has no member named 'buffer'
usb-linux.c:465: error: 'struct usbdevfs_urb' has no member named
'buffer_length'
usb-linux.c:471: error: 'struct usbdevfs_urb' has no member named
'number_of_packets'
usb-lin
Avi on holiday, it may take a little
unless Marcelo cherry picks or does a qemu merge. It's
commit 7ed208c433a2ec9bb2fda3d3bfb17b512ea0a796
Author: Juan Quintela
Date: Thu Jul 16 17:57:00 2009 +0200
fix XEN Build
thanks,
J
--
Regards,
Anthony Liguori
--
To unsubscribe
Costa
Date: Mon Jul 6 16:12:52 2009 -0400
This guy is certainly stupid, and deserves punishment. It means I'll
be writting code using emacs for the next week.
Marcelo, please apply
Signed-off-by: Glauber Costa
Does this mean the goofy MMIO thing isn't strictly needed?
Regards
complicated and requires functioning networking or some
paravirt channel.
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
plan isn't working. How do we
address it? How do we test it?
f13 is ancient, no?
I'm not sure what this particular issue is, but is this doing -M pc-0.12?
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
On 06/20/2011 02:42 AM, Juan Quintela wrote:
Please send in any agenda items you are interested in covering.
State of image streaming/block copy.
Regards,
Anthony Liguori
thanks,
-juan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
On 06/21/2011 08:56 AM, Avi Kivity wrote:
On 06/21/2011 04:50 PM, Anthony Liguori wrote:
We can have a script that runs lspci -vvv, x86info, and
other interesting stuff and compare the results, and also system tests
that boot a guest on multiple qemus (with the same -M and
-kvm.git uq/master
Pulled. Thanks.
Regards,
Anthony Liguori
Andre Przywara (1):
KVM: Fix XSAVE feature bit enumeration
Jan Kiszka (13):
kvm: x86: Save/restore FPU OP, IP and DP
Add kernel header update script
Import kernel headers
Switch build system to
;mem, offset, another_size);
memory_region_register_subregion(...,&alias);
What's the rationale for explicit aliasing verses registering the same
region to two different address spaces?
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe
we can't model
hardware exactly without true hierarchical dispatch.
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
On 06/27/2011 09:32 AM, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
FYI, I'm in an all-day meeting so I can't attend.
Regards,
Anthony Liguori
Later, Juan.
--
To unsubscribe from this list: send the line "unsubscribe kvm&qu
On 06/28/2011 08:48 AM, Avi Kivity wrote:
On 06/28/2011 04:43 PM, Anthony Liguori wrote:
FYI, I'm in an all-day meeting so I can't attend.
Did you do something really bad?
I named some variables with a leading underscore and now have to be
re-educated.
Regards,
Anthony Liguo
make networking Just Work?
We've explored various things in the past like using a fscap based
helper to open tap devices which can help with the Just Works parts.
Usermode TCP/IP can be quite cumbersome for users as things like ping
and ip6 won't work properly.
Regards,
t_ops;
CPUReadMemoryFunc *readfn[3];
CPUWriteMemoryFunc *writefn[3];
void *opaque;
} OldMemoryRegionOps;
That should allow old-style implementations to be converted without
introducing trampoline functions everywhere.
Regards,
Anthony Liguori
[..snip..]
--
To unsubscribe from
On 07/11/2011 08:14 AM, Alexander Graf wrote:
Am 11.07.2011 um 13:46 schrieb Juan Quintela:
Hi
Please send in any agenda items you are interested in covering.
Device passthrough on non-PCI (take 2)
Can we defer this to next week? I won't be able to attend today.
Regards,
An
o compress/write() to the fd. The migration thread
can then push sent regions onto a separate queue for the I/O thread to
mark as dirty.
Regards,
Anthony Liguori
Even just reading memory is not thread safe. You either have to copy it
into a buffer under lock, or convert the memory
On 07/14/2011 07:32 AM, Avi Kivity wrote:
On 07/14/2011 03:30 PM, Anthony Liguori wrote:
Does this mean that the following code is sometimes executed without
qemu_mutex? I don't think any of it is thread safe.
That was my reaction too.
I think the most rational thing to do is h
m?
In an ideal world, you would only create the backends on the destination
node and all of the devices would be created through the migration process.
Regards,
Anthony Liguori
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
1 - 100 of 2347 matches
Mail list logo
