[Qemu-devel] Last Call for 1.5 before Hard Freeze

[Qemu-devel] Last Call for 1.5 before Hard Freeze

[Anthony Liguori]

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

[Paolo Bonzini]

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
   1299    9086  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

[Anthony Liguori]

Paolo Bonzini <pbonzini@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
>    1299    9086  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

[Gerd Hoffmann]

  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

Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze

[Michael Tokarev]

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,  64 << 10,  32, 0) },
+    { INFO("s25sl032a",   0x010215,      0,  64 << 10,  64, 0) },
+    { INFO("s25sl064a",   0x010216,      0,  64 << 10, 128, 0) },
     { INFO("s25fl016k",   0xef4015,      0,  64 << 10,  32, ER_4K | ER_32K) },
     { INFO("s25fl064k",   0xef4017,      0,  64 << 10, 128, ER_4K | ER_32K) },

@@ -153,11 +168,13 @@ static const FlashPartInfo known_devices[] = {
     { INFO("m25p32",      0x202016,      0,  64 << 10,  64, 0) },
     { INFO("m25p64",      0x202017,      0,  64 << 10, 128, 0) },
     { INFO("m25p128",     0x202018,      0, 256 << 10,  64, 0) },
+    { INFO("n25q032",     0x20ba16,      0,  64 << 10,  64, 0) },

     { INFO("m45pe10",     0x204011,      0,  64 << 10,   2, 0) },
     { INFO("m45pe80",     0x204014,      0,  64 << 10,  16, 0) },
     { INFO("m45pe16",     0x204015,      0,  64 << 10,  32, 0) },

+    { INFO("m25pe20",     0x208012,      0,  64 << 10,   4, 0) },
     { INFO("m25pe80",     0x208014,      0,  64 << 10,  16, 0) },
     { INFO("m25pe16",     0x208015,      0,  64 << 10,  32, ER_4K) },

@@ -174,8 +191,12 @@ static const FlashPartInfo known_devices[] = {
     { INFO("w25x16",      0xef3015,      0,  64 << 10,  32, ER_4K) },
     { INFO("w25x32",      0xef3016,      0,  64 << 10,  64, ER_4K) },
     { INFO("w25q32",      0xef4016,      0,  64 << 10,  64, ER_4K) },
+    { INFO("w25q32dw",    0xef6016,      0,  64 << 10,  64, ER_4K) },
     { INFO("w25x64",      0xef3017,      0,  64 << 10, 128, ER_4K) },
     { INFO("w25q64",      0xef4017,      0,  64 << 10, 128, ER_4K) },
+    { INFO("w25q80",      0xef5014,      0,  64 << 10,  16, ER_4K) },
+    { INFO("w25q80bl",    0xef4014,      0,  64 << 10,  16, ER_4K) },
+    { INFO("w25q256",     0xef4019,      0,  64 << 10, 512, ER_4K) },

     /* Numonyx -- n25q128 */
     { INFO("n25q128",      0x20ba18,      0,  64 << 10, 256, 0) },
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 64493eb..5fc0eae 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -214,10 +214,6 @@ PCI UHCI USB controller and a virtual USB hub.

 SMP is supported with up to 255 CPUs.

-Note that adlib, gus and cs4231a are only available when QEMU was
-configured with --audio-card-list option containing the name(s) of
-required card(s).
-
 QEMU uses the PC BIOS from the Bochs project and the Plex86/Bochs LGPL
 VGA BIOS.

Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze

[Jordan Justen]

On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori <aliguori@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

[Anthony Liguori]

Jordan Justen <jljusten@gmail.com> writes:

> On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori <aliguori@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

[Paolo Bonzini]

Il 06/05/2013 22:31, Anthony Liguori ha scritto:
> Jordan Justen <jljusten@gmail.com> writes:
> 
>> On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori <aliguori@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

[Jordan Justen]

On Mon, May 6, 2013 at 1:41 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 06/05/2013 22:31, Anthony Liguori ha scritto:
>> Jordan Justen <jljusten@gmail.com> writes:
>>
>>> On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori <aliguori@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

[Paolo Bonzini]

Il 06/05/2013 23:07, Jordan Justen ha scritto:
> On Mon, May 6, 2013 at 1:41 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 06/05/2013 22:31, Anthony Liguori ha scritto:
>>> Jordan Justen <jljusten@gmail.com> writes:
>>>
>>>> On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori <aliguori@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

Re: [Qemu-devel] Last Call for 1.5 before Hard Freeze

[Jordan Justen]

On Mon, May 6, 2013 at 1:31 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> Jordan Justen <jljusten@gmail.com> writes:
>
>> On Mon, May 6, 2013 at 7:42 AM, Anthony Liguori <aliguori@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

[Andreas Färber]

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