the right thing to do since release
artifacts should never change.
Regards,
Anthony Liguori
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTV8NqAAoJEBqtxxBWguX/j9oH/3eVb+PgcXhEHICRXNoPyNy8
instructions privately and between stefanha and I we can
get your permissions sorted out.
Regards,
Anthony Liguori
thanks
-- PMM
--
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
supportive.
Regards,
Anthony Liguori
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
soon.
Regards,
Anthony Liguori
Paolo
--
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
--
To unsubscribe from this list: send the line unsubscribe kvm
and
that the next version will be 2.0!
Speaking of sending out e-mail: did I miss the promised followup to the
key signing party?
I need to find the papers from KVM Forum which are somewhere among the
stacks of boxes here :-/
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line
...@redhat.com wrote on 26/11/2013 11:11:57 PM:
From: Michael S. Tsirkin m...@redhat.com
To: Abel Gordon/Haifa/IBM@IBMIL,
Cc: Anthony Liguori anth...@codemonkey.ws, abel.gor...@gmail.com,
as...@redhat.com, digitale...@google.com, Eran Raichstein/Haifa/
IBM@IBMIL, g...@redhat.com, jasow
polling mode to vhost
Have the vhost thread poll the virtqueues with high I/O rate for new
buffers , and avoid asking the guest to kick us.
https://github.com/abelg/virtual_io_acceleration/commit/26616133fafb7855cc80fac070b0572fd1aaf5d0
Ack on this.
Regards,
Anthony Liguori
4. vhost
you actually
tried -O1 under a debugger with clang? Is it noticably worse than
-O0?
I find QEMU extremely difficult to use an interactive debugger on
anyway. I doubt the difference between -O0 and -O1 is even close to
the breaking point between usability under a debugger...
Regards,
Anthony
it's not getting that much testing.
We really need to figure out how we're going to do CI.
FWIW, I'd rather just add -O1 for debug builds than add more stub functions.
Regards,
Anthony Liguori
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
comments, I think this needs a v2.
Regards,
Anthony Liguori
vfio-pci updates include:
- Forgotten MSI affinity patch posted several months ago
- Lazy option ROM loading to delay load until after device/bus resets
- Error reporting cleanups
- PCI hot reset support introduced with Linux v3.12
it's a bad idea to mix and match the
two.
Regards,
Anthony Liguori
any question about the detail of vhost_net on Xen is welcome。
Thanks
--
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
, creating an external disk
snapshot, then resuming the guest.
Regards,
Anthony Liguori
in my mind, Snapshots can not occupy additional too much memory, So when the
memory needs to be changed, the old memory page is needed to flush to the
file first. But flushing to file is too slower than
releases at:
http://wiki.qemu.org/Download
Regards,
Anthony Liguori
Adam Rauf
Software Engineering Institute
CERT Vulnerability Analysis Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iQEVAwUBUe2DstXCAanP4MNyAQI8nwf/eTb1Qox5lmgMHifDKRjj69E37FW+o5Jp
KMIP6
who will attend
the event.
I will also be attending LinuxCon/CloudOpen/Plumbers North America if
anyone wants to have another key signing party at that event and cannot
attend KVM Forum.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
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
be generating the SMBIOS
tables.
Regards,
Anthony Liguori
--
MST
--
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
Hi Rusty,
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori aligu...@us.ibm.com writes:
4) Do virtio-pcie, make it PCI-e friendly (drop the IO BAR completely), give
it a new device/vendor ID. Continue to use virtio-pci for existing
devices potentially adding virtio-{net
Gleb Natapov g...@redhat.com writes:
On Wed, Jun 05, 2013 at 07:41:17PM -0500, Anthony Liguori wrote:
H. Peter Anvin h...@zytor.com writes:
On 06/05/2013 03:08 PM, Anthony Liguori wrote:
Definitely an option. However, we want to be able to boot from native
devices, too, so having
if the only benefit is
claiming spec compliance.
Regards,
Anthony Liguori
--
MST
--
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
--
To unsubscribe from
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 07:59:33AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Jun 04, 2013 at 03:01:50PM +0930, Rusty Russell wrote:
You mean make BAR0 an MMIO BAR?
Yes, it would break current windows
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 10:08:37AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 07:59:33AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Jun 04, 2013
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 10:46:15AM -0500, Anthony Liguori wrote:
Look, it's very simple.
We only need to do it if we do a change that breaks guests.
Please find a guest that is broken by the patches. You won't find any.
I think the problem
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 01:57:16PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 10:46:15AM -0500, Anthony Liguori wrote:
Look, it's very simple.
We only need to do it if we do a change
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 10:43:17PM +0300, Michael S. Tsirkin wrote:
On Wed, Jun 05, 2013 at 01:57:16PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 10:46:15AM -0500, Anthony Liguori wrote
correct -- it is compatible with a legacy interface.
Do legacy endpoints also use 4k for BARs?
If not, can't we use a new device id for native endpoints and call it a
day? Legacy endpoints would continue using the existing BAR layout.
Regards,
Anthony Liguori
-hpa
--
To unsubscribe
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jun 05, 2013 at 03:42:57PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
Can you explain? I thought the whole trick with separating out the
virtqueue notification register was to regain the performance?
Yes
H. Peter Anvin h...@zytor.com writes:
On 06/05/2013 02:50 PM, Anthony Liguori wrote:
H. Peter Anvin h...@zytor.com writes:
On 06/05/2013 09:20 AM, Michael S. Tsirkin wrote:
Spec says IO and memory can be enabled/disabled, separately.
PCI Express spec says devices should work without IO
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
On Wed, 2013-06-05 at 16:53 -0500, Anthony Liguori wrote:
A smart BIOS can also use MMIO to program virtio.
Indeed :-)
I see no reason why not providing both access path though. Have the PIO
BAR there for compatibility/legacy/BIOS
H. Peter Anvin h...@zytor.com writes:
On 06/05/2013 03:08 PM, Anthony Liguori wrote:
Definitely an option. However, we want to be able to boot from native
devices, too, so having an I/O BAR (which would not be used by the OS
driver) should still at the very least be an option.
What makes
build
tree and then having a way to point the SeaBIOS makefiles to our copy of
it.
Then the logic is maintained stays in firmware but the churn happens in
the QEMU tree instead of the SeaBIOS tree.
Regards,
Anthony Liguori
With both the hardware implementation and acpi descriptions
of everything is silly. Every other
vendor that uses TianoCore has a proprietary fork. Maintaining a GPL
fork seems just as reasonable.
/soapbox
Regards,
Anthony Liguori
(and I never have without explicit permission), so it's been a lot of
back and forth with acpidump / iasl -d in guests (massage OVMF
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 15:04, Anthony Liguori wrote:
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to
OVMF
soapbox
:)
Fork OVMF, drop the fat module
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open
Source. So
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 16:38, Anthony Liguori wrote:
It's either Open Source or it's not. It's currently not.
I disagree with this binary representation of Open Source or Not. If it
weren't (mostly) Open Source, how could we fork (most of) it as you're
Paolo Bonzini pbonz...@redhat.com writes:
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source
Jordan Justen jljus...@gmail.com writes:
On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori anth...@codemonkey.ws
wrote:
In terms of creating a FAT module, the most likely source would seem to
be the kernel code and since that's GPL, I don't think it's terribly
avoidable to end up
Jordan Justen jljus...@gmail.com writes:
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori anth...@codemonkey.ws
wrote:
As I think more about it, I think forking edk2 is inevitable. We need a
clean repo that doesn't include the proprietary binaries. I doubt
upstream edk2 is willing
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori anth...@codemonkey.ws writes:
Rusty Russell ru...@rustcorp.com.au writes:
On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
FWIW, I think what's more interesting is using vhost-net as a networking
backend with virtio
Stefan Hajnoczi stefa...@gmail.com writes:
On Thu, May 30, 2013 at 7:23 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Anthony Liguori anth...@codemonkey.ws writes:
Rusty Russell ru...@rustcorp.com.au writes:
On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
FWIW, I think
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori aligu...@us.ibm.com writes:
Forcing a guest driver change is a really big
deal and I see no reason to do that unless there's a compelling reason
to.
So we're stuck with the 1.0 config layout for a very long time.
We definitely
Michael S. Tsirkin m...@redhat.com writes:
On Thu, May 30, 2013 at 08:40:47AM -0500, Anthony Liguori wrote:
Stefan Hajnoczi stefa...@gmail.com writes:
On Thu, May 30, 2013 at 7:23 AM, Rusty Russell ru...@rustcorp.com.au
wrote:
Anthony Liguori anth...@codemonkey.ws writes:
Rusty
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori aligu...@us.ibm.com writes:
Michael S. Tsirkin m...@redhat.com writes:
+case offsetof(struct virtio_pci_common_cfg, device_feature_select):
+return proxy-device_feature_select;
Oh dear no... Please use defines like
Rusty Russell ru...@rustcorp.com.au writes:
Michael S. Tsirkin m...@redhat.com writes:
On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Fri, May 24, 2013 at 05:41:11PM +0800, Jason Wang wrote:
On 05/23/2013 04:50 PM, Michael S
Michael S. Tsirkin m...@redhat.com writes:
On Wed, May 29, 2013 at 07:52:37AM -0500, Anthony Liguori wrote:
1) C makes no guarantees about structure layout beyond the first
member. Yes, if it's naturally aligned or has a packed attribute,
GCC does the right thing. But this isn't
.
Not that these structures are actually used for something.
We store the config in these structures so they are actually used for
something.
The proposed structures only serve as a way to express offsets. You
would never actually have a variable of this type.
Regards,
Anthony Liguori
For this reason I prefer
Michael S. Tsirkin m...@redhat.com writes:
On Wed, May 29, 2013 at 09:16:39AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
I'm guessing any compiler that decides to waste memory in this way
will quickly get dropped by users and then we won't worry
about
of memory the guest has across reboots? That's equivalent to adding
another DIMM after power off.
Not generating tables on reset does limit what we can do in a pretty
fundamental way. Even if you can argue it in the short term, I don't
think it's viable in the long term.
Regards,
Anthony Liguori
besides OVMF and SeaBIOS?
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
/01ba80a23cf2eb1e15056f82b44b94ec381565cb
Which lets virtio-pci be subclassable and then remaps the config space to
BAR2.
Haven't looked at the proposed new ring layout yet.
Regards,
Anthony Liguori
+case offsetof(struct virtio_pci_common_cfg, device_feature):
+/* TODO: 64-bit features */
+ return
Michael S. Tsirkin m...@redhat.com writes:
On Tue, May 28, 2013 at 12:15:16PM -0500, Anthony Liguori wrote:
@@ -455,6 +462,226 @@ static void virtio_pci_config_write(void *opaque,
hwaddr addr,
}
}
+static uint64_t virtio_pci_config_common_read(void *opaque, hwaddr addr
of
virtio-net in qemu.
100% agreed.
Regards,
Anthony Liguori
I've put up a wiki page with a kvm networking todo list,
mainly to avoid effort duplication, but also in the hope
to draw attention to what I think we should try addressing
in KVM:
http://www.linux-kvm.org/page
...
Regards,
Anthony Liguori
Kevin - could you join on Tuesday? There appears a disconnect
between the seabios and qemu that a conf call
might help resolve.
--
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo
Michael S. Tsirkin m...@redhat.com writes:
On Tue, May 21, 2013 at 07:18:58AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, May 20, 2013 at 12:57:47PM +0200, Juan Quintela wrote:
Hi
Please, send any topic that you are interested in covering
Michael S. Tsirkin m...@redhat.com writes:
On Tue, May 21, 2013 at 09:29:07AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, May 21, 2013 at 07:18:58AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, May 20, 2013
to probe for the former feature, it will result in
a false positive.
That's why a more direct feature negotiation mechanism is better IMHO.
Regards,
Anthony Liguori
if we change a command, how we change the interface without
changing the c-api?
c-api is not yet a strong consideration
.
Changes in Patch-v2:
- Move -get_features() assignment to virtio_scsi_init() instead of
virtio_scsi_init_common()
Any reason we're not doing this as a QOM base class?
Similiar to how the in-kernel PIT/PIC work using a common base class...
Regards,
Anthony Liguori
Signed-off-by: Paolo
Juan Quintela quint...@redhat.com writes:
Hi
Please send in any agenda topics you are interested in.
FYI, I have a conflict for today so I won't be able to attend.
Regards,
Anthony Liguori
Later, Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
Applied. Thanks.
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
Applied. Thanks.
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
.
Likewise, with legacy IDE ports are routed to the first device with an
IDE class. That's the only reason you can have these legacy devices not
behind the ISA bridge.
Regards,
Anthony Liguori
At the bus level, transaction happens on a bus and an appropriate device
will claim it.
My naive
PIO that devices can use to register on.
We probably need to do something like change the PCI VGA devices to
export a MemoryRegion and allow the PCI controller to device how to
register that as a subregion.
Regards,
Anthony Liguori
Concerns:
* PCI devices (VGA, QXL) register I/O ports as well
Markus Armbruster arm...@redhat.com writes:
Peter Maydell peter.mayd...@linaro.org writes:
On 30 January 2013 07:02, Markus Armbruster arm...@redhat.com wrote:
Anthony Liguori aligu...@us.ibm.com writes:
[...]
The problems I ran into were (1) this is a lot of work (2) it basically
a tree based on the 'T:' fields in MAINTAINERS. So if you
want your tree to be part of buildbot, please make sure that you have a
correct entry in MAINTAINERS.
Regards,
Anthony Liguori
This would make the buildbot setup *alot* easier. We can go for a
AnyBranchScheduler then with BuildFactory
evolution will be when sysbus is completely removed.
Regards,
Anthony Liguori
I'd expect an ISA PC's sysbus - ISA bridge to map both directly.
I'd expect an ISA bridge for a sysbus without a separate I/O address
space to map the ISA I/O address space into the sysbus's normal address
space
be possible with priorities, but I think it's wrong. There
aren't two VGA devices. QXL is-a VGA device and the best way to
override behavior of base VGA device is through polymorphism.
This isn't really a memory API issue, it's a modeling issue.
Regards,
Anthony Liguori
Anyone has clues / suggestions
Andreas Färber afaer...@suse.de writes:
Am 30.01.2013 17:33, schrieb Anthony Liguori:
Gerd Hoffmann kra...@redhat.com writes:
hw/qxl.c:portio_list_add(qxl_vga_port_list,
pci_address_space_io(dev), 0x3b0);
hw/vga.c:portio_list_add(vga_port_list, address_space_io, 0x3b0
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
On Wed, 2013-01-30 at 07:59 -0600, Anthony Liguori wrote:
An x86 CPU has a MMIO capability that's essentially 65 bits. Whether
the top bit is set determines whether it's a PIO transaction or an
MMIO transaction. A large chunk
the functional object expects. In most cases, this is just a
straight forward proxy of a MemoryRegion. Sometimes this involves
address shifting, etc.
Regards,
Anthony Liguori
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
revents
iohandler.c can simply store the index into struct IOHandlerRecord, and
use it later. slirp can do the same for struct socket.
The select code can be kept for Windows after POSIX switches to poll.
Doesn't g_poll already do this under the covers for Windows?
Regards,
Anthony Liguori
,
Anthony Liguori
Alex
--
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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message
.
That would be nice, likewise for the assert(0).
OK so let's go ahead with this patchset as is,
and a cleanup patch will be send after 1.4 then.
Why? I'd prefer that we didn't rush things into 1.4 just because.
There's still ample time to respin a corrected series.
Regards,
Anthony Liguori
reasonable to merge
over the next week.
Regards,
Anthony Liguori
Later, Juan.
--
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
--
To unsubscribe from
the linker ever
sees them.
Regards,
Anthony Liguori
/*/
/* PowerPC Hypercall emulation */
@@ -777,7 +777,7 @@ void ppc_hw_interrupt(CPUPPCState *env)
}
#endif /* !CONFIG_USER_ONLY */
-#if defined
CHECKPATCH in MAINTAINERS.
Subject: s390: Add channel I/O instructions.
Subject: s390: I/O interrupt and machine check injection.
Subject: s390: Channel I/O basic definitions.
Subject: s390: Add mapping helper functions.
Subject: s390: Lowcore mapping helper.
Regards,
Anthony Liguori
--
To unsubscribe
the release windows shouldn't have a major impact on merging...
Regards,
Anthony Liguori
--nab
--
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
--
To unsubscribe
Jason Wang jasow...@redhat.com writes:
On 01/15/2013 03:44 AM, Anthony Liguori wrote:
Jason Wang jasow...@redhat.com writes:
Hello all:
This seires is an update of last version of multiqueue virtio-net support.
Recently, linux tap gets multiqueue support. This series implements basic
Michael S. Tsirkin m...@redhat.com writes:
On Wed, Jan 16, 2013 at 09:09:49AM -0600, Anthony Liguori wrote:
Jason Wang jasow...@redhat.com writes:
On 01/15/2013 03:44 AM, Anthony Liguori wrote:
Jason Wang jasow...@redhat.com writes:
Hello all:
This seires is an update of last
shouldn't be
allowed to have two values for the same property. Better to have a
syntax like fd[0]=X,fd[1]=Y or something along those lines.
Regards,
Anthony Liguori
You can fetch and try the code from:
git://github.com/jasowang/qemu.git
Patch 1 adds a generic method of creating multiqueue taps
Pulled, thanks.
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
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
/qemu-kvm.git uq/master
for you to fetch changes up to 0a2a59d35cbabf63c91340a1c62038e3e60538c1:
qemu-kvm/pci-assign: 64 bits bar emulation (2012-12-25 14:37:52 +0200)
Pulled. Thanks.
Regards,
Anthony Liguori
Will Auld (1
Juan Quintela quint...@redhat.com writes:
Hi
Please send in any agenda topics that you have.
I have a conflicting call today so I can't attend.
Regards,
Anthony Liguori
Thanks, Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
Kevin Wolf kw...@redhat.com writes:
Am 10.12.2012 14:59, schrieb Juan Quintela:
Hi
Please send in any agenda topics you are interested in.
Can probably be answered on the list, but what is the status of
libqos?
Still on my TODO list.
Regards,
Anthony Liguori
Kevin
incredibly subtle that I have a hard time believing
anyone actually understands what it means today.
Regards,
Anthony Liguori
---
Michael Wolf (5):
Alter the amount of steal time reported by the guest.
Expand the steal time msr to also contain the consigned time.
Add
-kvm.git uq/master
Bruce Rogers (1):
Legacy qemu-kvm options have no argument
Pulled. Thanks.
Regards,
Anthony Liguori
qemu-options.hx |8
1 files changed, 4 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
Alex Williamson alex.william...@redhat.com writes:
Hi Anthony,
Please pull the tag below. I posted the linux-headers update
separately on Oct-15; since it hasn't been applied and should be
non-controversial, I include it again here. Thanks,
Alex
Pulled. Thanks.
Regards,
Anthony
the patches and
sending them out.
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
--
To unsubscribe from this list: send
.
This is what distros that are shipping ROMs outside of QEMU ought to
do. It's a bug to unconditionally change the ROMs (in a guest visible
way) without adding compatibility support.
Regards,
Anthony Liguori
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from
Tosatti (1):
cirrus_vga: allow configurable vram size
Peter Maydell (1):
update-linux-headers.sh: Handle new kernel uapi/ directories
Pulled. Thanks.
Regards,
Anthony Liguori
blockdev.c |6 ++
hw/cirrus_vga.c | 21 --
kvm.h
that do a lot of fork, exit, mmap,
exec, etc. have a high rate of HPT updates.
If the rate is high enough, then there's no point in a live update.
Do we have practical data here?
Regards,
Anthony Liguori
Suppose new hardware arrives that supports nesting HPTs, so that kvm is
no longer
that do a lot of fork, exit, mmap,
exec, etc. have a high rate of HPT updates.
If the rate is high enough, then there's no point in a live update.
Do we have practical data here?
Regards,
Anthony Liguori
Suppose new hardware arrives that supports nesting HPTs, so that kvm is
no longer
Alex Williamson alex.william...@redhat.com writes:
Based on v3.7-rc1-3-g29bb4cc
Normally this would go through qemu-kvm/uq/master but since this is from
Linus' tree, it's less of a concern.
Nonetheless, I'd prefer we did it from v3.7-rc1 instead of a random git
snapshot.
Regards,
Anthony
in PCI
2.3.
2.3 was standardized in 2002. Are we confident that vendor extensions
play nice with pre-2.3 OSes like Win2k, WinXP, etc?
I still think it's a bad idea to rely on something so new in something
as fundamental as virtio-pci unless we have to.
Regards,
Anthony Liguori
So let's return
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori aligu...@us.ibm.com writes:
We'll never remove legacy so we shouldn't plan on it. There are
literally hundreds of thousands of VMs out there with the current virtio
drivers installed in them. We'll be supporting them for a very
Avi Kivity a...@redhat.com writes:
On 10/09/2012 05:16 AM, Rusty Russell wrote:
Anthony Liguori aligu...@us.ibm.com writes:
We'll never remove legacy so we shouldn't plan on it. There are
literally hundreds of thousands of VMs out there with the current virtio
drivers installed in them
affected.
Regards,
Anthony Liguori
[ Not that I want veto a feature bit, but I don't see the need yet ]
cheers,
Gerd
--
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
Rusty Russell ru...@rustcorp.com.au writes:
(Topic updated, cc's trimmed).
Anthony Liguori aligu...@us.ibm.com writes:
Rusty Russell ru...@rustcorp.com.au writes:
4) The only significant change to the spec is that we use PCI
capabilities, so we can have infinite feature bits.
(see
,
Anthony Liguori
cheers,
Gerd
--
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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
to not
expose a legacy layout PIO bar.
I think having BAR1 be an MMIO mirror of the registers + a BAR2 for
virtio configuration space is probably not that bad of a solution.
Regards,
Anthony Liguori
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
1 - 100 of 2144 matches
Mail list logo
