Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
Hi, And please remember to update the changelog. It's already a pretty featureful release, but I have no idea about what's happening in VNC land (LED extension and WebSockets?) Yea, those two, I'm not aware of anything else. and what are the visible effects of Gerd's console refactorings. Not much, for the most part it's internal cleanups, 1.6 will most likely bring some user-visible changes building on top of the cleanups. Most visible effect is probably that all the hops screendumping used to go through are gone. So taking a screendump doesn't switch consoles any more (you'll see that when typing the screendump command into a vc terminal with sdl). Also screendumpimg doesn't need special support from the gfx card emulation any more (which wasn't implemented by all gfx emulation). So screendumping works with all display hardware now. Also the screendump commands now properly throws an error in case there is no gfx hardware installed instead of silently doing nothing. Oh, and the threaded vnc server should finally be rock solid. display resize used to race with the vnc threads, leading to qemu crashing on mode switches now and then. The refactoring fixed that one too. cheers, Gerd
[Qemu-devel] Last Call for 1.5 before Hard Freeze
Hi, I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Regards, Anthony Liguori
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
Il 06/05/2013 16:42, Anthony Liguori ha scritto: Hi, I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Thanks Anthony! And please remember to update the changelog. It's already a pretty featureful release, but I have no idea about what's happening in VNC land (LED extension and WebSockets?) and what are the visible effects of Gerd's console refactorings. BTW, so far we have 10% more commits than 1.3.0: $ git log --pretty=oneline v1.2.0..v1.3.0-rc0|wc 1608 11447 141561 $ git log --pretty=oneline v1.3.0..v1.4.0-rc0|wc 12999086 114069 $ git log --pretty=oneline v1.4.0..HEAD|wc 1837 13002 161841 Paolo
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
Paolo Bonzini pbonz...@redhat.com writes: Il 06/05/2013 16:42, Anthony Liguori ha scritto: Hi, I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Thanks Anthony! And please remember to update the changelog. It's already a pretty featureful release, but I have no idea about what's happening in VNC land (LED extension and WebSockets?) and what are the visible effects of Gerd's console refactorings. Ack. BTW, so far we have 10% more commits than 1.3.0: $ git log --pretty=oneline v1.2.0..v1.3.0-rc0|wc 1608 11447 141561 $ git log --pretty=oneline v1.3.0..v1.4.0-rc0|wc 12999086 114069 $ git log --pretty=oneline v1.4.0..HEAD|wc 1837 13002 161841 We are averaging 22.66 commits a day for this release. The 1.4 release was 18.86. So we're looking at almost a 20% increase. Here's a graph of QEMU's full history. This is by far the most active release. http://www.codemonkey.ws/files/qemu-commits.svg Regards, Anthony Liguori Paolo
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
06.05.2013 18:42, Anthony Liguori wrote:
Hi,
I believe I have processed all of the outstanding pull requests and
patches tagged for 1.5. If there are any other patches or pull requests
you would like to be considered, please respond to this note with a
pointer to the patch or make sure you send it out tagged with 'for-1.5'
no later than 5pm US/Eastern.
There's one more trivial pull request (3 changes) pending for 1.5.
Thanks,
/mjt
The following changes since commit 8e515b125d5f7849167dbee6cbe6ef61636607d4:
configure: Check that libtool is not the MacOSX one (2013-05-06 06:52:03
-0500)
are available in the git repository at:
git://git.corpit.ru/qemu.git trivial-patches
for you to fetch changes up to ce08a537bdb758fa0583127e21bc9ae7842d0216:
audio: update documentation after removing --audio-card-list option
(2013-05-06 22:04:45 +0400)
Ed Maste (2):
bsd-user: OS-agnostic 64-bit SYSCTL types
m25p80.c: Sync Flash chip list with Linux
Hervé Poussineau (1):
audio: update documentation after removing --audio-card-list option
bsd-user/syscall.c |7 ---
hw/block/m25p80.c | 31 ++-
qemu-doc.texi |4
3 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index 69e3466..a4d1583 100644
--- a/bsd-user/syscall.c
+++ b/bsd-user/syscall.c
@@ -211,10 +211,11 @@ static int sysctl_oldcvt(void *holdp, size_t holdlen,
uint32_t kind)
*(uint64_t *)holdp = tswap64(*(unsigned long *)holdp);
break;
#endif
-#if !defined(__FreeBSD_version) || __FreeBSD_version 900031
-case CTLTYPE_QUAD:
-#else
+#ifdef CTLTYPE_U64
+case CTLTYPE_S64:
case CTLTYPE_U64:
+#else
+case CTLTYPE_QUAD:
#endif
*(uint64_t *)holdp = tswap64(*(uint64_t *)holdp);
break;
diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index b3ca19a..759c84d 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -91,18 +91,27 @@ static const FlashPartInfo known_devices[] = {
{ INFO(at26df161a, 0x1f4601, 0, 64 10, 32, ER_4K) },
{ INFO(at26df321, 0x1f4700, 0, 64 10, 64, ER_4K) },
+{ INFO(at45db081d, 0x1f2500, 0, 64 10, 16, ER_4K) },
+
/* EON -- en25xxx */
{ INFO(en25f32, 0x1c3116, 0, 64 10, 64, ER_4K) },
{ INFO(en25p32, 0x1c2016, 0, 64 10, 64, 0) },
{ INFO(en25q32b,0x1c3016, 0, 64 10, 64, 0) },
{ INFO(en25p64, 0x1c2017, 0, 64 10, 128, 0) },
+{ INFO(en25q64, 0x1c3017, 0, 64 10, 128, ER_4K) },
+
+/* GigaDevice */
+{ INFO(gd25q32, 0xc84016, 0, 64 10, 64, ER_4K) },
+{ INFO(gd25q64, 0xc84017, 0, 64 10, 128, ER_4K) },
/* Intel/Numonyx -- xxxs33b */
{ INFO(160s33b, 0x898911, 0, 64 10, 32, 0) },
{ INFO(320s33b, 0x898912, 0, 64 10, 64, 0) },
{ INFO(640s33b, 0x898913, 0, 64 10, 128, 0) },
+{ INFO(n25q064, 0x20ba17, 0, 64 10, 128, 0) },
/* Macronix */
+{ INFO(mx25l2005a, 0xc22012, 0, 64 10, 4, ER_4K) },
{ INFO(mx25l4005a, 0xc22013, 0, 64 10, 8, ER_4K) },
{ INFO(mx25l8005, 0xc22014, 0, 64 10, 16, 0) },
{ INFO(mx25l1606e, 0xc22015, 0, 64 10, 32, ER_4K) },
@@ -113,15 +122,16 @@ static const FlashPartInfo known_devices[] = {
{ INFO(mx25l25635e, 0xc22019, 0, 64 10, 512, 0) },
{ INFO(mx25l25655e, 0xc22619, 0, 64 10, 512, 0) },
+/* Micron */
+{ INFO(n25q128a11, 0x20bb18, 0, 64 10, 256, 0) },
+{ INFO(n25q128a13, 0x20ba18, 0, 64 10, 256, 0) },
+{ INFO(n25q256a,0x20ba19, 0, 64 10, 512, ER_4K) },
+
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
-{ INFO(s25sl004a, 0x010212, 0, 64 10, 8, 0) },
-{ INFO(s25sl008a, 0x010213, 0, 64 10, 16, 0) },
-{ INFO(s25sl016a, 0x010214, 0, 64 10, 32, 0) },
-{ INFO(s25sl032a, 0x010215, 0, 64 10, 64, 0) },
{ INFO(s25sl032p, 0x010215, 0x4d00, 64 10, 64, ER_4K) },
-{ INFO(s25sl064a, 0x010216, 0, 64 10, 128, 0) },
+{ INFO(s25sl064p, 0x010216, 0x4d00, 64 10, 128, ER_4K) },
{ INFO(s25fl256s0, 0x010219, 0x4d00, 256 10, 128, 0) },
{ INFO(s25fl256s1, 0x010219, 0x4d01, 64 10, 512, 0) },
{ INFO(s25fl512s, 0x010220, 0x4d00, 256 10, 256, 0) },
@@ -130,6 +140,11 @@ static const FlashPartInfo known_devices[] = {
{ INFO(s25sl12801, 0x012018, 0x0301, 64 10, 256, 0) },
{ INFO(s25fl129p0, 0x012018, 0x4d00, 256 10, 64, 0) },
{ INFO(s25fl129p1, 0x012018, 0x4d01, 64 10, 256, 0) },
+{ INFO(s25sl004a, 0x010212, 0, 64 10, 8, 0) },
+{ INFO(s25sl008a, 0x010213, 0, 64 10, 16, 0) },
+{ INFO(s25sl016a, 0x010214, 0,
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori aligu...@us.ibm.com wrote: I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Is there a chance of including the KVM PC flash series in 1.5? Unfortunately, I'm assuming no given the timing. It does seem less than ideal to have -pflash go from working on qemu 1.2-1.4, to silently being ignored in 1.5, and then working again in 1.6... -Jordan
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
Jordan Justen jljus...@gmail.com writes: On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori aligu...@us.ibm.com wrote: I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Is there a chance of including the KVM PC flash series in 1.5? Unfortunately, I'm assuming no given the timing. I think we're going to need to delay it. Did we ever come to a consensus about what to do on older kernels? Regards, Anthony Liguori It does seem less than ideal to have -pflash go from working on qemu 1.2-1.4, to silently being ignored in 1.5, and then working again in 1.6... -Jordan
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
Il 06/05/2013 22:31, Anthony Liguori ha scritto: Jordan Justen jljus...@gmail.com writes: On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori aligu...@us.ibm.com wrote: I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Is there a chance of including the KVM PC flash series in 1.5? Unfortunately, I'm assuming no given the timing. I think we're going to need to delay it. Did we ever come to a consensus about what to do on older kernels? Yes, the patches only use the new feature is -pflash is given on the command line. memory_region_set_readonly is only used in a few places, so I think this series could go in; it is a fix for a TCG-mode regression. I'm curious however if it causes -M isapc to regress, because in 1.4 it works only in KVM mode, not in TCG mode. Paolo
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
Hi, Am 06.05.2013 16:42, schrieb Anthony Liguori: I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Final qom-cpu pull for-1.5 is on the list. 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
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
On Mon, May 6, 2013 at 1:41 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 06/05/2013 22:31, Anthony Liguori ha scritto: Jordan Justen jljus...@gmail.com writes: On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori aligu...@us.ibm.com wrote: I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Is there a chance of including the KVM PC flash series in 1.5? Unfortunately, I'm assuming no given the timing. I think we're going to need to delay it. Did we ever come to a consensus about what to do on older kernels? Yes, the patches only use the new feature is -pflash is given on the command line. memory_region_set_readonly is only used in a few places, so I think this series could go in; it is a fix for a TCG-mode regression. I'm curious however if it causes -M isapc to regress, because in 1.4 it works only in KVM mode, not in TCG mode. It looks like isapc has always set rom_only to 1, meaning it never should have supported PC flash. So, I hope isapc didn't ever have any noticeable behavior change due to the PC flash feature. -Jordan
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
On Mon, May 6, 2013 at 1:31 PM, Anthony Liguori aligu...@us.ibm.com wrote: Jordan Justen jljus...@gmail.com writes: On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori aligu...@us.ibm.com wrote: I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Is there a chance of including the KVM PC flash series in 1.5? Unfortunately, I'm assuming no given the timing. I think we're going to need to delay it. Did we ever come to a consensus about what to do on older kernels? The feedback was to only use flash mode only when -pflash is used, and to bail if pflash+kvm is used with an old kernel. If -pflash is not specified, then rom-mode is used, and qemu will behave as in = pc-1.1. This was implemented in v2 and carried forward to the current v3: git://github.com/jljusten/qemu.git kvm-flash-v3 -Jordan
Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze
Il 06/05/2013 23:07, Jordan Justen ha scritto: On Mon, May 6, 2013 at 1:41 PM, Paolo Bonzini pbonz...@redhat.com wrote: Il 06/05/2013 22:31, Anthony Liguori ha scritto: Jordan Justen jljus...@gmail.com writes: On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori aligu...@us.ibm.com wrote: I believe I have processed all of the outstanding pull requests and patches tagged for 1.5. If there are any other patches or pull requests you would like to be considered, please respond to this note with a pointer to the patch or make sure you send it out tagged with 'for-1.5' no later than 5pm US/Eastern. Is there a chance of including the KVM PC flash series in 1.5? Unfortunately, I'm assuming no given the timing. I think we're going to need to delay it. Did we ever come to a consensus about what to do on older kernels? Yes, the patches only use the new feature is -pflash is given on the command line. memory_region_set_readonly is only used in a few places, so I think this series could go in; it is a fix for a TCG-mode regression. I'm curious however if it causes -M isapc to regress, because in 1.4 it works only in KVM mode, not in TCG mode. It looks like isapc has always set rom_only to 1, meaning it never should have supported PC flash. So, I hope isapc didn't ever have any noticeable behavior change due to the PC flash feature. The change would be because you now implement memory_region_set_readonly. That's the dangerous part of the series. Paolo
