Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/77] ppc: Add "native" POWER8 platform
On Fri, 2015-11-27 at 11:21 +0100, Alexander Graf wrote: > > How does real hardware store petitboot? If it's flash, you could pass it > in using -pflash and thus model things even more closely and allow users > to just take the ROM image as is. It is a flash image, we could use an Open Power machine flash image "as-is" provided we taught qemu to extract skiboot (aka OPAL) from it. Cheers, Ben.
[Qemu-devel] [Bug 1520730] [NEW] 32-bit editors vim/rhide broken keyboard handling in freedos 1.1 and ms-dos 6.22
Public bug reported: This bug is present as of the latest commit: 714487515dbe0c65d5904251e796cd3a5b3579fb I also saw it in 2.4.1, but that was a distro package. You can see the bug simply using the following line: qemu-system-i386 -hda freedos.disk Simply type vim (or rhide) and start entering in some text. You'll notice repeating characters, and also eventually the key mode will change as if you're holding down the shift button. Not capslock. "a" will become "A", but "\" will also become "|". I don't think this is a bug in freedos because I get the same behavior with dos 6.22. Not dosbox, though. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "freedos.tar.xz" https://bugs.launchpad.net/bugs/1520730/+attachment/4526531/+files/freedos.tar.xz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1520730 Title: 32-bit editors vim/rhide broken keyboard handling in freedos 1.1 and ms-dos 6.22 Status in QEMU: New Bug description: This bug is present as of the latest commit: 714487515dbe0c65d5904251e796cd3a5b3579fb I also saw it in 2.4.1, but that was a distro package. You can see the bug simply using the following line: qemu-system-i386 -hda freedos.disk Simply type vim (or rhide) and start entering in some text. You'll notice repeating characters, and also eventually the key mode will change as if you're holding down the shift button. Not capslock. "a" will become "A", but "\" will also become "|". I don't think this is a bug in freedos because I get the same behavior with dos 6.22. Not dosbox, though. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1520730/+subscriptions
[Qemu-devel] [Bug 1492649] Re: QEMU soundhw HDA huge microphone lag
I can reproduce this on Windows 10 (64bit) with hda device. Host kernel is 4.1.13-rt15-1-rt, also tried with non-realtime kernel with same results. Output works without delay, given it is choppy from time to time. Using the following env vars when starting QEMU: QEMU_AUDIO_DRV: pa QEMU_PA_SAMPLE: 32 # also tried with 128, 256, 512 and 1024. Same results for input, output got less choppy but with notable latency QEMU_PA_SERVER: unix:/run/user/1000/pulse/native # where user with uid is the user with Xorg and PA session, of course. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1492649 Title: QEMU soundhw HDA huge microphone lag Status in QEMU: New Bug description: I use a Windows 7 x86_64 guest with VGA passthrough and -soundhw hda. The audio plays fine, but the microphone input is delayed by more than 20 seconds. -soundhw ac97 does not have this delay but it has choppy sound playback and input. System: Arch linux Kernel: 4.1.6-1-ARCH Audio hardware: 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller Audio system: Pulseaudio 6.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1492649/+subscriptions
Re: [Qemu-devel] [PATCH 12/15] nbd: implement TLS support in the protocol negotiation
Minor nitpick:
On Fri, Nov 27, 2015 at 12:20:50PM +, Daniel P. Berrange wrote:
[...]
> @@ -563,6 +659,14 @@ static int nbd_receive_options(NBDClient *client)
> case NBD_OPT_EXPORT_NAME:
> return nbd_handle_export_name(client, length);
>
> +case NBD_OPT_STARTTLS:
> +if (client->tlscreds) {
> +TRACE("TLS already enabled");
> +} else {
> +TRACE("TLS not configured");
> +}
> +nbd_send_rep(client->ioc, NBD_REP_ERR_UNSUP, clientflags);
NBD_REP_ERR_UNSUP is supposed to be reserved as the default reply for
replies unknown to a server implementation (i.e., it's "this request is
not supported by this server"). Trying to negotiate TLS in a TLS channel
would be NBD_REP_ERR_INVALID ("invalid request"). Trying to negotiate
TLS when no TLS configuration is available server-side would be
NBD_REP_ERR_POLICY ("request not allowed by server-side policy").
Keeping to these error codes would allow a client to provide more useful
information to a user beyond "haha it fail"; but I suppose there can be
arguments for not doing so, too.
Beyond this and the default export that I talked about earlier, no
comments.
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/77] ppc: Add "native" POWER8 platform
> Am 28.11.2015 um 08:59 schrieb Benjamin Herrenschmidt > : > >> On Fri, 2015-11-27 at 11:21 +0100, Alexander Graf wrote: >> >> How does real hardware store petitboot? If it's flash, you could pass it >> in using -pflash and thus model things even more closely and allow users >> to just take the ROM image as is. > > It is a flash image, we could use an Open Power machine flash image "as-is" > provided we taught qemu to extract skiboot (aka OPAL) from it. That's probably the best way. If it's memory mapped, you might not even have to extract anything - just jump to its location ;). The -kernel syntax is useful to have, but should really be something "on top" of the normal system boot rather than its primary boot interface. Alex
Re: [Qemu-devel] [PATCH 1/2] hw/ppc/spapr: Create pseries-2.6 machine
On Fri, Nov 27, 2015 at 11:15:10PM +0100, Thomas Huth wrote:
> On 27/11/15 18:56, Eduardo Habkost wrote:
> > On Fri, Nov 27, 2015 at 06:18:30PM +0100, Thomas Huth wrote:
> >> On 27/11/15 10:55, Alexander Graf wrote:
> >>>
> >>> On 27.11.15 10:32, Thomas Huth wrote:
> Add a new pseries-2.6 machine class version to make sure we can
> keep the old types compatible to previous versions of QEMU in
> later patches.
>
> Signed-off-by: Thomas Huth
> ---
> hw/ppc/spapr.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 6bfb908..10b7c35 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -2450,6 +2448,24 @@ static const TypeInfo spapr_machine_2_5_info = {
> .class_init= spapr_machine_2_5_class_init,
> };
>
> +static void spapr_machine_2_6_class_init(ObjectClass *oc, void *data)
> +{
> +MachineClass *mc = MACHINE_CLASS(oc);
> +sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(oc);
> +
> +mc->name = "pseries-2.6";
> +mc->desc = "pSeries Logical Partition (PAPR compliant) v2.6";
> +mc->alias = "pseries";
> +mc->is_default = 1;
> +smc->dr_lmb_enabled = true;
> >>>
> >>> We should probably start to follow a scheme similar to x86 where the new
> >>> machine initialization calls its predecessor (2.5 in this case) to
> >>> ensure we don't forget feature flags and quirks.
> >>>
> >>> So you can either directly call spapr_machine_2_5_class_init() from
> >>> spapr_machine_2_6_class_init() or extract the quirk part
> >>> (dr_lmb_enabled) into a function that gets marked as "from 2.5 on" in
> >>> its function name and call it from 2_5_class_init and from a "from 2.6
> >>> on" function that gets called from 2_6_class_init.
> >>
> >> I like the idea of calling the functions in a chain. However, the i386
> >> people seem to do it the other way round, for example
> >> pc_i440fx_2_4_machine_options() calls pc_i440fx_2_5_machine_options().
> >> That of course works, too, but it sounds a little bit cumbersome to me,
> >> since when introducing a new machine class version, you do not only have
> >> to introduce a function for the new class anymore, but also you have to
> >> update the previous version to change the behavior that has been
> >> introduced by the new function (see commit 87e896abe6d926 for example).
> >
> > The alias/is_default changes are only needed because we don't
> > have a generic class alias system (yet), that would allow us to
> > declare the "pc" alias and a default machine outside the
> > machine_options() function. I agree it's cumbersome.
> >
> > commit 87e896abe6d926 has the extra broken_reserved_end change
> > because for some reason we decided to add the broken_reserved_end
> > quirk to pc-2.4 before we even introduced pc-2.5. That was an
> > exception. The common case is to add the pc-2.4 quirks only after
> > we added a pc-2.5 machine.
> >
> > The patch that adds pc-1.6, for example, looks like this:
> >
> > -static void pc_i440fx_2_5_machine_options(MachineClass *m)
> > +static void pc_i440fx_2_6_machine_options(MachineClass *m)
> >{
> >pc_i440fx_machine_options(m);
> >m->alias = "pc";
> >m->is_default = 1;
> >}
> >
> > +DEFINE_I440FX_MACHINE(v2_6, "pc-i440fx-2.6", NULL,
> > + pc_i440fx_2_6_machine_options);
> > +
> > +static void pc_i440fx_2_5_machine_options(MachineClass *m)
> > +{
> > +pc_i440fx_2_6_machine_options(m);
> > +m->alias = NULL;
> > +m->is_default = 0;
> > +SET_MACHINE_COMPAT(m, PC_COMPAT_2_5);
> > +}
> >
> > Except for the alias/is_default stuff, it looks very simple to
> > me.
> >
> > That said, I don't understand what you would suggest as
> > alternative. Let's use pc-1.7 and pc-1.6 as examples:
> >
> > static void pc_compat_1_7(MachineState *machine)
> > {
> > pc_compat_2_0(machine);
> > smbios_defaults = false;
> > gigabyte_align = false;
> > option_rom_has_mr = true;
> > legacy_acpi_table_size = 6414;
> > x86_cpu_change_kvm_default("x2apic", NULL);
> > }
> >
> > static void pc_compat_1_6(MachineState *machine)
> > {
> > pc_compat_1_7(machine);
> > rom_file_has_mr = false;
> > has_acpi_build = false;
> > }
> >
> > pc-1.7 and older need the smbios_defaults/gigabyte_align/
> > option_rom_has_mr/legacy_acpi_table_size/x2apic quirks. pc-2.0
> > and later don't need those quirks. How exactly would you make
> > pc-1.6 and older inherit the quirks from pc-1.7, if not by
> > reusing pc_compat_1_7() inside pc_compat_1_6()?
> >
> > (I am showing pc_compat_*() instead of *_machine_options(),
> > because we're still moving compat stuff from pc_compat_*() to
> > *_machine_options() functions. But the same questions apply once
> > we move the compat code above to *_machine_options() functions).
> >
Re: [Qemu-devel] [PATCH v2] bt: check struct sizes
On 27/11/2015 18:57, Paolo Bonzini wrote:
> See http://permalink.gmane.org/gmane.linux.bluez.kernel/36505. For historical
> reasons these do not use sizeof, and Coverity caught a mistake in
> EVT_ENCRYPT_CHANGE_SIZE.
>
> Note other sizes that seem wrong or inconsistent with the kernel header.
>
> Signed-off-by: Paolo Bonzini
Hmm, can do better...
Paolo
> ---
> include/hw/bt.h | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/include/hw/bt.h b/include/hw/bt.h
> index cb2a7e6..bc32807 100644
> --- a/include/hw/bt.h
> +++ b/include/hw/bt.h
> @@ -507,6 +507,7 @@ typedef struct {
> uint8_t status;
> bdaddr_t bdaddr;
> } QEMU_PACKED create_conn_cancel_cp;
> +/* FIXME: 6 or 7? Kernel doesn't have status?? */
> #define CREATE_CONN_CANCEL_CP_SIZE 6
>
> typedef struct {
> @@ -1266,12 +1267,13 @@ typedef struct {
> uint8_t status;
> uint16_t handle;
> } QEMU_PACKED reset_failed_contact_counter_rp;
> -#define RESET_FAILED_CONTACT_COUNTER_RP_SIZE 4
> +#define RESET_FAILED_CONTACT_COUNTER_RP_SIZE 3
>
> #define OCF_READ_LINK_QUALITY0x0003
> typedef struct {
> uint16_t handle;
> } QEMU_PACKED read_link_quality_cp;
> +/* FIXME: 2 or 4?? */
> #define READ_LINK_QUALITY_CP_SIZE 4
>
> typedef struct {
> @@ -1332,6 +1334,7 @@ typedef struct {
> uint8_t dev_class[3];
> uint16_t clock_offset;
> } QEMU_PACKED inquiry_info;
> +/* FIXME: 15 or 14?? Kernel doesn't have num_responses. */
> #define INQUIRY_INFO_SIZE 14
>
> #define EVT_CONN_COMPLETE0x03
> @@ -1381,7 +1384,7 @@ typedef struct {
> uint16_t handle;
> uint8_t encrypt;
> } QEMU_PACKED evt_encrypt_change;
> -#define EVT_ENCRYPT_CHANGE_SIZE 5
> +#define EVT_ENCRYPT_CHANGE_SIZE 4
>
> #define EVT_CHANGE_CONN_LINK_KEY_COMPLETE0x09
> typedef struct {
> @@ -1570,6 +1573,7 @@ typedef struct {
> uint16_t clock_offset;
> int8_t rssi;
> } QEMU_PACKED inquiry_info_with_rssi;
> +/* FIXME: 15 or 14?? Kernel doesn't have num_responses. */
> #define INQUIRY_INFO_WITH_RSSI_SIZE 15
> typedef struct {
> uint8_t num_responses;
> @@ -1581,6 +1585,7 @@ typedef struct {
> uint16_t clock_offset;
> int8_t rssi;
> } QEMU_PACKED inquiry_info_with_rssi_and_pscan_mode;
> +/* FIXME: 16 or 15?? Kernel doesn't have num_responses. */
> #define INQUIRY_INFO_WITH_RSSI_AND_PSCAN_MODE_SIZE 16
>
> #define EVT_READ_REMOTE_EXT_FEATURES_COMPLETE0x23
> @@ -1639,6 +1644,7 @@ typedef struct {
> int8_t rssi;
> uint8_t data[240];
> } QEMU_PACKED extended_inquiry_info;
> +/* FIXME: 254 or 255?? Should there be num_responses here too? */
> #define EXTENDED_INQUIRY_INFO_SIZE 254
>
> #define EVT_TESTING 0xFE
>
Re: [Qemu-devel] [PATCH v6 3/3] target-i386: add support to migrate vcpu's TSC rate
On Fri, Nov 27, 2015 at 08:16:42AM +0800, Haozhong Zhang wrote: > On 11/26/15 12:19, Eduardo Habkost wrote: > > On Tue, Nov 24, 2015 at 11:33:57AM +0800, Haozhong Zhang wrote: > > > This patch enables migrating vcpu's TSC rate. If KVM on the destination > > > machine supports TSC scaling, guest programs will observe a consistent > > > TSC rate across the migration. > > > > > > If TSC scaling is not supported on the destination machine, the > > > migration will not be aborted and QEMU on the destination will not set > > > vcpu's TSC rate to the migrated value. > > > > > > If vcpu's TSC rate specified by CPU option 'tsc-freq' on the destination > > > machine is inconsistent with the migrated TSC rate, the migration will > > > be aborted. > > > > > > For backwards compatibility, the migration of vcpu's TSC rate is > > > disabled on pc-*-2.4 and older machine types. > > > > > > Signed-off-by: Haozhong Zhang > > > > Assuming the PC compat code will be moved to > > pc_*_2_5_machine_options(), because the patch will be included > > after QEMU 2.5.0: > > > > Reviewed-by: Eduardo Habkost > > > > One comment below: > > Hi Eduardo, > > Thank you for reviewing! > > Besides the comment, should I submit a new version which updates the > compat code after pc-*-2.6 machine types are added? There's no need to resubmit. I have queued the patches for 2.6, in the branch at: git://github.com/ehabkost/qemu.git x86-next The pc-2.6 series is in that queue because it is a dependency. But I plan to rebase and submit a pull request containing only the x86-specific patches, after the pc-2.6 series is merged through Michael's tree. -- Eduardo
[Qemu-devel] [PATCH] m25p80.c Added support for N25Q256 and N25Q512
It is my first patch, so any comment are really welcome.
Changes:
* Removed unused variable
* Added support for n25q256a and n25q512a
* Added support for 4bytes address mode
* Added support for banked read mode
* Added support for sw reset flash commands
* Added Read Flag Status register command support
Signed-off-by: Marcin Krzeminski
---
hw/block/m25p80.c | 94 +++
1 file changed, 88 insertions(+), 6 deletions(-)
diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index efc43dd..c8b92d8 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -47,6 +47,9 @@
*/
#define WR_1 0x100
+/* 16 MiB max in 3 byte address mode */
+#define MAX_3BYTES_SIZE 0x100
+
typedef struct FlashPartInfo {
const char *part_name;
/* jedec code. (jedec >> 16) & 0xff is the 1st byte, >> 8 the 2nd etc */
@@ -206,6 +209,8 @@ static const FlashPartInfo known_devices[] = {
/* Numonyx -- n25q128 */
{ INFO("n25q128", 0x20ba18, 0, 64 << 10, 256, 0) },
+{ INFO("n25q256a", 0x20ba19, 0, 64 << 10, 512, ER_4K) },
+{ INFO("n25q512a", 0x20ba20, 0, 64 << 10, 1024, ER_4K) },
};
typedef enum {
@@ -216,6 +221,7 @@ typedef enum {
WREN = 0x6,
JEDEC_READ = 0x9f,
BULK_ERASE = 0xc7,
+READ_FSL = 0x70,
READ = 0x3,
FAST_READ = 0xb,
@@ -231,6 +237,15 @@ typedef enum {
ERASE_4K = 0x20,
ERASE_32K = 0x52,
ERASE_SECTOR = 0xd8,
+
+ENTER_4BYTE_ADDR_MODE = 0xB7,
+LEAVE_4BYTE_ADDR_MODE = 0xE9,
+
+EXTEND_ADDR_READ = 0xC8,
+EXTEND_ADDR_WRITE = 0xC5,
+
+RESET_ENABLE = 0x66,
+RESET_MEMORY = 0x99,
} FlashCMD;
typedef enum {
@@ -244,8 +259,6 @@ typedef enum {
typedef struct Flash {
SSISlave parent_obj;
-uint32_t r;
-
BlockBackend *blk;
uint8_t *storage;
@@ -260,6 +273,9 @@ typedef struct Flash {
uint8_t cmd_in_progress;
uint64_t cur_addr;
bool write_enable;
+bool four_bytes_address_mode;
+bool reset_enable;
+uint8_t extended_addr_reg;
int64_t dirty_page;
@@ -397,9 +413,17 @@ void flash_write8(Flash *s, uint64_t addr, uint8_t data)
static void complete_collecting_data(Flash *s)
{
-s->cur_addr = s->data[0] << 16;
-s->cur_addr |= s->data[1] << 8;
-s->cur_addr |= s->data[2];
+if (s->four_bytes_address_mode) {
+s->cur_addr = s->data[0] << 24;
+s->cur_addr |= s->data[1] << 16;
+s->cur_addr |= s->data[2] << 8;
+s->cur_addr |= s->data[3];
+} else {
+s->cur_addr = s->data[0] << 16;
+s->cur_addr |= s->data[1] << 8;
+s->cur_addr |= s->data[2];
+s->cur_addr += (s->extended_addr_reg&0x3)*MAX_3BYTES_SIZE;
+}
s->state = STATE_IDLE;
@@ -427,11 +452,28 @@ static void complete_collecting_data(Flash *s)
s->write_enable = false;
}
break;
+case EXTEND_ADDR_WRITE:
+s->extended_addr_reg = s->data[0];
+break;
default:
break;
}
}
+static void reset_memory(Flash *s)
+{
+s->cmd_in_progress = NOP;
+s->cur_addr = 0;
+s->extended_addr_reg = 0;
+s->four_bytes_address_mode = false;
+s->len = 0;
+s->needed_bytes = 0;
+s->pos = 0;
+s->state = STATE_IDLE;
+s->write_enable = false;
+s->reset_enable = false;
+}
+
static void decode_new_cmd(Flash *s, uint32_t value)
{
s->cmd_in_progress = value;
@@ -446,7 +488,7 @@ static void decode_new_cmd(Flash *s, uint32_t value)
case DPP:
case QPP:
case PP:
-s->needed_bytes = 3;
+s->needed_bytes = s->four_bytes_address_mode ? 4 : 3;
s->pos = 0;
s->len = 0;
s->state = STATE_COLLECTING_DATA;
@@ -514,6 +556,13 @@ static void decode_new_cmd(Flash *s, uint32_t value)
s->state = STATE_READING_DATA;
break;
+case READ_FSL:
+s->data[0] = (1<<7); /*Indicates flash is ready */
+s->pos = 0;
+s->len = 1;
+s->state = STATE_READING_DATA;
+break;
+
case JEDEC_READ:
DB_PRINT_L(0, "populated jedec code\n");
s->data[0] = (s->pi->jedec >> 16) & 0xff;
@@ -541,6 +590,34 @@ static void decode_new_cmd(Flash *s, uint32_t value)
break;
case NOP:
break;
+case ENTER_4BYTE_ADDR_MODE:
+s->four_bytes_address_mode = true;
+break;
+case LEAVE_4BYTE_ADDR_MODE:
+s->four_bytes_address_mode = false;
+break;
+case EXTEND_ADDR_READ:
+s->data[0] = s->extended_addr_reg;
+s->pos = 0;
+s->len = 1;
+s->state = STATE_READING_DATA;
+break;
+case EXTEND_ADDR_WRITE:
+if (s->write_enable) {
+s->needed_bytes = 1;
+s->pos = 0;
+s->len = 0;
+s->state = STATE_COLLECTING_DATA;
+}
+break;
+case RESET_ENABLE:
+s->reset_enable = true;
+break;
+case RESET_MEMORY:
+if (s->reset_enable) {
+
Re: [Qemu-devel] [PATCH] m25p80.c Added support for N25Q256 and N25Q512
These features are also available in Xilinx QEMU if you want to
compare implementation:
https://github.com/Xilinx/qemu/blob/pub/2015.2.plnx/hw/block/m25p80.c
That work also handles the larger and newer Spansion flash parts, as
well as the quad and dual mode commands for QSPI (also features of
n25qXXX).
On Sat, Nov 28, 2015 at 9:06 AM, Krzeminski, Marcin (Nokia -
PL/Wroclaw) wrote:
> It is my first patch, so any comment are really welcome.
>
Check MAINTAINERS file for relevant people to CC.
To make informal comments on your patches, you but them below the line ...
> Changes:
> * Removed unused variable
> * Added support for n25q256a and n25q512a
> * Added support for 4bytes address mode
4 byte addressing is a feature common to more than just n25qXXX. It
should be done as a separate prepended patch.
> * Added support for banked read mode
> * Added support for sw reset flash commands
> * Added Read Flag Status register command support
>
Basically these bullets should indicate separate patches to ease review.
> Signed-off-by: Marcin Krzeminski
> ---
... here. So when the maintainers apply the patch they are not
committed to the git logs.
> hw/block/m25p80.c | 94
> +++
> 1 file changed, 88 insertions(+), 6 deletions(-)
>
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index efc43dd..c8b92d8 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -47,6 +47,9 @@
> */
> #define WR_1 0x100
>
> +/* 16 MiB max in 3 byte address mode */
> +#define MAX_3BYTES_SIZE 0x100
> +
> typedef struct FlashPartInfo {
> const char *part_name;
> /* jedec code. (jedec >> 16) & 0xff is the 1st byte, >> 8 the 2nd etc */
> @@ -206,6 +209,8 @@ static const FlashPartInfo known_devices[] = {
>
> /* Numonyx -- n25q128 */
> { INFO("n25q128", 0x20ba18, 0, 64 << 10, 256, 0) },
> +{ INFO("n25q256a", 0x20ba19, 0, 64 << 10, 512, ER_4K) },
> +{ INFO("n25q512a", 0x20ba20, 0, 64 << 10, 1024, ER_4K) },
> };
>
> typedef enum {
> @@ -216,6 +221,7 @@ typedef enum {
> WREN = 0x6,
> JEDEC_READ = 0x9f,
> BULK_ERASE = 0xc7,
> +READ_FSL = 0x70,
Where does "FSL" come from? I am looking at an n25q256 datasheet here
that has this is "RFSR".
http://datasheet.octopart.com/N25Q256A13E1241F-Micron-datasheet-11552757.pdf
Admittedly, the vendors do tend to rename this stuff from
part-to-part. To keep consistent with surrounding code, this would be
READ_FSR.
>
> READ = 0x3,
> FAST_READ = 0xb,
> @@ -231,6 +237,15 @@ typedef enum {
> ERASE_4K = 0x20,
> ERASE_32K = 0x52,
> ERASE_SECTOR = 0xd8,
> +
> +ENTER_4BYTE_ADDR_MODE = 0xB7,
> +LEAVE_4BYTE_ADDR_MODE = 0xE9,
> +
> +EXTEND_ADDR_READ = 0xC8,
> +EXTEND_ADDR_WRITE = 0xC5,
> +
Same data sheet has: WREAR, RDEAR, EN4BYTEADDR ... but Xilinx code has
something different again. In both cases, it is shorter, so I think
this should just be something shorter.
> +RESET_ENABLE = 0x66,
> +RESET_MEMORY = 0x99,
> } FlashCMD;
>
> typedef enum {
> @@ -244,8 +259,6 @@ typedef enum {
> typedef struct Flash {
> SSISlave parent_obj;
>
> -uint32_t r;
> -
Even the trivial cleanup can be a separate patch.
> BlockBackend *blk;
>
> uint8_t *storage;
> @@ -260,6 +273,9 @@ typedef struct Flash {
> uint8_t cmd_in_progress;
> uint64_t cur_addr;
> bool write_enable;
> +bool four_bytes_address_mode;
> +bool reset_enable;
> +uint8_t extended_addr_reg;
The datasheets abbreviate this to "EAR" so I think the same should be
done in code.
>
> int64_t dirty_page;
>
> @@ -397,9 +413,17 @@ void flash_write8(Flash *s, uint64_t addr, uint8_t data)
>
> static void complete_collecting_data(Flash *s)
> {
> -s->cur_addr = s->data[0] << 16;
> -s->cur_addr |= s->data[1] << 8;
> -s->cur_addr |= s->data[2];
> +if (s->four_bytes_address_mode) {
> +s->cur_addr = s->data[0] << 24;
> +s->cur_addr |= s->data[1] << 16;
> +s->cur_addr |= s->data[2] << 8;
> +s->cur_addr |= s->data[3];
> +} else {
> +s->cur_addr = s->data[0] << 16;
> +s->cur_addr |= s->data[1] << 8;
> +s->cur_addr |= s->data[2];
> +s->cur_addr += (s->extended_addr_reg&0x3)*MAX_3BYTES_SIZE;
> +}
This can share implementation between 3 byte and 4 byte mode. From the
Xilinx work:
static inline void do_4_byte_address(Flash *s)
{
s->cur_addr <<= 8;
s->cur_addr |= s->data[3];
}
#define BAR_7_4_BYTE_ADDR(1<<7)
static inline void check_4_byte_address(Flash *s)
{
/* Allow 4byte address if MSB of bar register is set to 1
* Or if 4byte addressing is allowed.
*/
if ((s->bar & BAR_7_4_BYTE_ADDR) || s->addr_4b) {
do_4_byte_address(s);
} else {
s->cur_addr |= s->bar << 24;
}
}
Which also handles case instructions where the 4 byte addresses comes
as data on the wire. For your feature set it would be mo
[Qemu-devel] [for-2.6 PATCH 3/3] target-i386: kvm: Use X86XSaveArea struct for xsave save/load
Instead of using offset macros and bit operations in a uint32_t
array, use the X86XSaveArea struct to perform the loading/saving
operations in kvm_put_xsave() and kvm_get_xsave().
Signed-off-by: Eduardo Habkost
---
target-i386/kvm.c | 144 --
1 file changed, 52 insertions(+), 92 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index ee6c213..5e7ec70 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1203,50 +1203,11 @@ static int kvm_put_fpu(X86CPU *cpu)
return kvm_vcpu_ioctl(CPU(cpu), KVM_SET_FPU, &fpu);
}
-#define XSAVE_FCW_FSW 0
-#define XSAVE_FTW_FOP 1
-#define XSAVE_CWD_RIP 2
-#define XSAVE_CWD_RDP 4
-#define XSAVE_MXCSR 6
-#define XSAVE_ST_SPACE8
-#define XSAVE_XMM_SPACE 40
-#define XSAVE_XSTATE_BV 128
-#define XSAVE_YMMH_SPACE 144
-#define XSAVE_BNDREGS 240
-#define XSAVE_BNDCSR 256
-#define XSAVE_OPMASK 272
-#define XSAVE_ZMM_Hi256 288
-#define XSAVE_Hi16_ZMM416
-
-#define XSAVE_BYTE_OFFSET(word_offset) \
-((word_offset)*sizeof(((struct kvm_xsave*)0)->region[0]))
-
-#define ASSERT_OFFSET(word_offset, field) \
-QEMU_BUILD_BUG_ON(XSAVE_BYTE_OFFSET(word_offset) != \
- offsetof(X86XSaveArea, field))
-
-ASSERT_OFFSET(XSAVE_FCW_FSW, legacy.fcw);
-ASSERT_OFFSET(XSAVE_FTW_FOP, legacy.ftw);
-ASSERT_OFFSET(XSAVE_CWD_RIP, legacy.fpip);
-ASSERT_OFFSET(XSAVE_CWD_RDP, legacy.fpdp);
-ASSERT_OFFSET(XSAVE_MXCSR, legacy.mxcsr);
-ASSERT_OFFSET(XSAVE_ST_SPACE, legacy.fpregs);
-ASSERT_OFFSET(XSAVE_XMM_SPACE, legacy.xmm_regs);
-ASSERT_OFFSET(XSAVE_XSTATE_BV, header.xstate_bv);
-ASSERT_OFFSET(XSAVE_YMMH_SPACE, avx_state);
-ASSERT_OFFSET(XSAVE_BNDREGS, bndreg_state);
-ASSERT_OFFSET(XSAVE_BNDCSR, bndcsr_state);
-ASSERT_OFFSET(XSAVE_OPMASK, opmask_state);
-ASSERT_OFFSET(XSAVE_ZMM_Hi256, zmm_hi256_state);
-ASSERT_OFFSET(XSAVE_Hi16_ZMM, hi16_zmm_state);
-
-
static int kvm_put_xsave(X86CPU *cpu)
{
CPUX86State *env = &cpu->env;
-struct kvm_xsave* xsave = env->kvm_xsave_buf;
+X86XSaveArea *xsave = env->kvm_xsave_buf;
uint16_t cwd, swd, twd;
-uint8_t *xmm, *ymmh, *zmmh;
int i, r;
if (!has_xsave) {
@@ -1261,37 +1222,38 @@ static int kvm_put_xsave(X86CPU *cpu)
for (i = 0; i < 8; ++i) {
twd |= (!env->fptags[i]) << i;
}
-xsave->region[XSAVE_FCW_FSW] = (uint32_t)(swd << 16) + cwd;
-xsave->region[XSAVE_FTW_FOP] = (uint32_t)(env->fpop << 16) + twd;
-memcpy(&xsave->region[XSAVE_CWD_RIP], &env->fpip, sizeof(env->fpip));
-memcpy(&xsave->region[XSAVE_CWD_RDP], &env->fpdp, sizeof(env->fpdp));
-memcpy(&xsave->region[XSAVE_ST_SPACE], env->fpregs,
+xsave->legacy.fcw = cwd;
+xsave->legacy.fsw = swd;
+xsave->legacy.ftw = twd;
+xsave->legacy.fpop = env->fpop;
+xsave->legacy.fpip = env->fpip;
+xsave->legacy.fpdp = env->fpdp;
+memcpy(&xsave->legacy.fpregs, env->fpregs,
sizeof env->fpregs);
-xsave->region[XSAVE_MXCSR] = env->mxcsr;
-*(uint64_t *)&xsave->region[XSAVE_XSTATE_BV] = env->xstate_bv;
-memcpy(&xsave->region[XSAVE_BNDREGS], env->bnd_regs,
+xsave->legacy.mxcsr = env->mxcsr;
+xsave->header.xstate_bv = env->xstate_bv;
+memcpy(&xsave->bndreg_state.bnd_regs, env->bnd_regs,
sizeof env->bnd_regs);
-memcpy(&xsave->region[XSAVE_BNDCSR], &env->bndcs_regs,
-sizeof(env->bndcs_regs));
-memcpy(&xsave->region[XSAVE_OPMASK], env->opmask_regs,
+xsave->bndcsr_state.bndcsr = env->bndcs_regs;
+memcpy(&xsave->opmask_state.opmask_regs, env->opmask_regs,
sizeof env->opmask_regs);
-xmm = (uint8_t *)&xsave->region[XSAVE_XMM_SPACE];
-ymmh = (uint8_t *)&xsave->region[XSAVE_YMMH_SPACE];
-zmmh = (uint8_t *)&xsave->region[XSAVE_ZMM_Hi256];
-for (i = 0; i < CPU_NB_REGS; i++, xmm += 16, ymmh += 16, zmmh += 32) {
-stq_p(xmm, env->xmm_regs[i].XMM_Q(0));
-stq_p(xmm+8, env->xmm_regs[i].XMM_Q(1));
-stq_p(ymmh,env->xmm_regs[i].XMM_Q(2));
-stq_p(ymmh+8, env->xmm_regs[i].XMM_Q(3));
-stq_p(zmmh,env->xmm_regs[i].XMM_Q(4));
-stq_p(zmmh+8, env->xmm_regs[i].XMM_Q(5));
-stq_p(zmmh+16, env->xmm_regs[i].XMM_Q(6));
-stq_p(zmmh+24, env->xmm_regs[i].XMM_Q(7));
+for (i = 0; i < CPU_NB_REGS; i++) {
+X86LegacyXSaveArea *legacy = &xsave->legacy;
+XSaveAVX *avx = &xsave->avx_state;
+XSaveZMM_Hi256 *zmm_hi256 = &xsave->zmm_hi256_state;
+stq_p(&legacy->xmm_regs[i][0], env->xmm_regs[i].XMM_Q(0));
+stq_p(&legacy->xmm_regs[i][1], env->xmm_regs[i].XMM_Q(1));
+stq_p(&avx->ymmh[i][0],env->xmm_regs[i].XMM_Q(2));
+stq_p(&avx->ymmh[i][1],env->xmm_regs[i].XMM_Q(3));
+stq_p(&zmm_hi256->zmm_hi256[i][0], env->xmm_regs[i].XMM_Q(4));
+stq_p(&zmm_hi256->zmm_hi256[i][1], env->xmm_regs[i].XMM_Q(5));
+stq_p(&zmm_hi256->zmm_hi256[i][2], env->xmm_regs[i].
[Qemu-devel] [for-2.6 PATCH 1/3] target-i386: Define structs for layout of xsave area
Add structs that define the layout of the xsave areas used by
Intel processors. Add some QEMU_BUILD_BUG_ON lines to ensure the
structs match the XSAVE_* macros in target-i386/kvm.c and the
offsets and sizes at target-i386/cpu.c:ext_save_areas.
Signed-off-by: Eduardo Habkost
---
target-i386/cpu.h | 85 +++
target-i386/kvm.c | 23 +++
2 files changed, 108 insertions(+)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 84edfd0..3d1d01e 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -806,6 +806,91 @@ typedef struct {
#define NB_OPMASK_REGS 8
+typedef union X86LegacyXSaveArea {
+struct {
+uint16_t fcw;
+uint16_t fsw;
+uint8_t ftw;
+uint8_t reserved;
+uint16_t fpop;
+uint64_t fpip;
+uint64_t fpdp;
+uint32_t mxcsr;
+uint32_t mxcsr_mask;
+FPReg fpregs[8];
+uint64_t xmm_regs[16][2];
+};
+uint8_t data[512];
+} X86LegacyXSaveArea;
+
+typedef struct X86XSaveHeader {
+uint64_t xstate_bv;
+uint64_t xcomp_bv;
+uint8_t reserved[48];
+} X86XSaveHeader;
+
+/* Ext. save area 2: AVX State */
+typedef struct XSaveAVX {
+uint64_t ymmh[16][2];
+} XSaveAVX;
+
+/* Ext. save area 3: BNDREG */
+typedef struct XSaveBNDREG {
+BNDReg bnd_regs[4];
+} XSaveBNDREG;
+
+/* Ext. save area 4: BNDCSR */
+typedef union XSaveBNDCSR {
+BNDCSReg bndcsr;
+uint8_t data[64];
+} XSaveBNDCSR;
+
+/* Ext. save area 5: Opmask */
+typedef struct XSaveOpmask {
+uint64_t opmask_regs[NB_OPMASK_REGS];
+} XSaveOpmask;
+
+/* Ext. save area 6: ZMM_Hi256 */
+typedef struct XSaveZMM_Hi256 {
+uint64_t zmm_hi256[16][4];
+} XSaveZMM_Hi256;
+
+/* Ext. save area 7: Hi16_ZMM */
+typedef struct XSaveHi16_ZMM {
+XMMReg hi16_zmm[16];
+} XSaveHi16_ZMM;
+
+typedef struct X86XSaveArea {
+X86LegacyXSaveArea legacy;
+X86XSaveHeader header;
+
+/* Extended save areas: */
+
+/* AVX State: */
+XSaveAVX avx_state;
+uint8_t padding[960-576-sizeof(XSaveAVX)];
+/* MPX State: */
+XSaveBNDREG bndreg_state;
+XSaveBNDCSR bndcsr_state;
+/* AVX-512 State: */
+XSaveOpmask opmask_state;
+XSaveZMM_Hi256 zmm_hi256_state;
+XSaveHi16_ZMM hi16_zmm_state;
+} X86XSaveArea;
+
+QEMU_BUILD_BUG_ON(offsetof(X86XSaveArea, avx_state) != 0x240);
+QEMU_BUILD_BUG_ON(sizeof(XSaveAVX) != 0x100);
+QEMU_BUILD_BUG_ON(offsetof(X86XSaveArea, bndreg_state) != 0x3c0);
+QEMU_BUILD_BUG_ON(sizeof(XSaveBNDREG) != 0x40);
+QEMU_BUILD_BUG_ON(offsetof(X86XSaveArea, bndcsr_state) != 0x400);
+QEMU_BUILD_BUG_ON(sizeof(XSaveBNDCSR) != 0x40);
+QEMU_BUILD_BUG_ON(offsetof(X86XSaveArea, opmask_state) != 0x440);
+QEMU_BUILD_BUG_ON(sizeof(XSaveOpmask) != 0x40);
+QEMU_BUILD_BUG_ON(offsetof(X86XSaveArea, zmm_hi256_state) != 0x480);
+QEMU_BUILD_BUG_ON(sizeof(XSaveZMM_Hi256) != 0x200);
+QEMU_BUILD_BUG_ON(offsetof(X86XSaveArea, hi16_zmm_state) != 0x680);
+QEMU_BUILD_BUG_ON(sizeof(XSaveHi16_ZMM) != 0x400);
+
typedef enum TPRAccess {
TPR_ACCESS_READ,
TPR_ACCESS_WRITE,
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 6dc9846..ee6c213 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1218,6 +1218,29 @@ static int kvm_put_fpu(X86CPU *cpu)
#define XSAVE_ZMM_Hi256 288
#define XSAVE_Hi16_ZMM416
+#define XSAVE_BYTE_OFFSET(word_offset) \
+((word_offset)*sizeof(((struct kvm_xsave*)0)->region[0]))
+
+#define ASSERT_OFFSET(word_offset, field) \
+QEMU_BUILD_BUG_ON(XSAVE_BYTE_OFFSET(word_offset) != \
+ offsetof(X86XSaveArea, field))
+
+ASSERT_OFFSET(XSAVE_FCW_FSW, legacy.fcw);
+ASSERT_OFFSET(XSAVE_FTW_FOP, legacy.ftw);
+ASSERT_OFFSET(XSAVE_CWD_RIP, legacy.fpip);
+ASSERT_OFFSET(XSAVE_CWD_RDP, legacy.fpdp);
+ASSERT_OFFSET(XSAVE_MXCSR, legacy.mxcsr);
+ASSERT_OFFSET(XSAVE_ST_SPACE, legacy.fpregs);
+ASSERT_OFFSET(XSAVE_XMM_SPACE, legacy.xmm_regs);
+ASSERT_OFFSET(XSAVE_XSTATE_BV, header.xstate_bv);
+ASSERT_OFFSET(XSAVE_YMMH_SPACE, avx_state);
+ASSERT_OFFSET(XSAVE_BNDREGS, bndreg_state);
+ASSERT_OFFSET(XSAVE_BNDCSR, bndcsr_state);
+ASSERT_OFFSET(XSAVE_OPMASK, opmask_state);
+ASSERT_OFFSET(XSAVE_ZMM_Hi256, zmm_hi256_state);
+ASSERT_OFFSET(XSAVE_Hi16_ZMM, hi16_zmm_state);
+
+
static int kvm_put_xsave(X86CPU *cpu)
{
CPUX86State *env = &cpu->env;
--
2.1.0
[Qemu-devel] [for-2.6 PATCH 0/3] target-i386: Use C struct for xsave area layout, offsets & sizes
target-i386/cpu.c:ext_save_area uses magic numbers for the xsave
area offets and sizes, and target-i386/kvm.c:kvm_{put,get}_xsave()
uses offset macros and bit manipulation to access the xsave area.
This series changes both to use C structs for the same
operations.
I still need to figure out a way to write unit tests for the new
code. Maybe I will just copy and paste the new and old functions,
and test them locally (checking if they give the same results
when translating blobs of random bytes).
Eduardo Habkost (3):
target-i386: Define structs for layout of xsave area
target-i386: Use xsave structs for ext_save_area
target-i386: kvm: Use X86XSaveArea struct for xsave save/load
target-i386/cpu.c | 18 +---
target-i386/cpu.h | 85 ++
target-i386/kvm.c | 121 +++---
3 files changed, 149 insertions(+), 75 deletions(-)
--
2.1.0
[Qemu-devel] [for-2.6 PATCH 2/3] target-i386: Use xsave structs for ext_save_area
This doesn't introduce any change in the code, as the offsets and
struct sizes match what was present in the table. This can be
validated by the QEMU_BUILD_BUG_ON lines on target-i386/cpu.h,
which ensures the struct sizes and offsets match the existing
values in ext_save_area.
Signed-off-by: Eduardo Habkost
---
target-i386/cpu.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 11e5e39..bc95437 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -458,17 +458,23 @@ typedef struct ExtSaveArea {
static const ExtSaveArea ext_save_areas[] = {
[2] = { .feature = FEAT_1_ECX, .bits = CPUID_EXT_AVX,
-.offset = 0x240, .size = 0x100 },
+.offset = offsetof(X86XSaveArea, avx_state),
+.size = sizeof(XSaveAVX) },
[3] = { .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_MPX,
-.offset = 0x3c0, .size = 0x40 },
+.offset = offsetof(X86XSaveArea, bndreg_state),
+.size = sizeof(XSaveBNDREG) },
[4] = { .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_MPX,
-.offset = 0x400, .size = 0x40 },
+.offset = offsetof(X86XSaveArea, bndcsr_state),
+.size = sizeof(XSaveBNDCSR) },
[5] = { .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_AVX512F,
-.offset = 0x440, .size = 0x40 },
+.offset = offsetof(X86XSaveArea, opmask_state),
+.size = sizeof(XSaveOpmask) },
[6] = { .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_AVX512F,
-.offset = 0x480, .size = 0x200 },
+.offset = offsetof(X86XSaveArea, zmm_hi256_state),
+.size = sizeof(XSaveZMM_Hi256) },
[7] = { .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_AVX512F,
-.offset = 0x680, .size = 0x400 },
+.offset = offsetof(X86XSaveArea, hi16_zmm_state),
+.size = sizeof(XSaveHi16_ZMM) },
};
const char *get_register_name_32(unsigned int reg)
--
2.1.0
[Qemu-devel] [PATCH v1 1/2] sd: sdhci: Delete over-zealous power check
This check was conditionalising SD card operation on the card being
powered by the SDHCI host controller. It is however possible
(particularly in embedded systems) for the power control of the SD card
to be managed outside of SDHCI. This can be as trivial as hard-wiring
the SD slot VCC to a constant power-rail.
This means the guest SDHCI can validly opt-out of the SDHCI power
control feature while still using the card. So delete this check to
allow operation of the card with SDHCI power control.
This is needed for at least Xilinx Zynq and also makes Freescale i.MX25
work for me. The digilent Zybo board has a public schematic
which shows SD VCC hardwiring:
http://digilentinc.com/Data/Products/ZYBO/ZYBO_sch_VB.3.pdf
bottom of page 3.
Signed-off-by: Peter Crosthwaite
---
hw/sd/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index d70d1a6..ed536ee 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -831,7 +831,7 @@ static void sdhci_data_transfer(void *opaque)
static bool sdhci_can_issue_command(SDHCIState *s)
{
-if (!SDHC_CLOCK_IS_ON(s->clkcon) || !(s->pwrcon & SDHC_POWER_ON) ||
+if (!SDHC_CLOCK_IS_ON(s->clkcon) ||
(((s->prnsts & SDHC_DATA_INHIBIT) || s->stopped_state) &&
((s->cmdreg & SDHC_CMD_DATA_PRESENT) ||
((s->cmdreg & SDHC_CMD_RESPONSE) == SDHC_CMD_RSP_WITH_BUSY &&
--
1.9.1
[Qemu-devel] [PATCH v1 0/2] i.MX25 SD support
Hi Jean Christophe, This patch series adds support for SD on i.MX25. This is usable for the PDK board. P1 is a bugfix in SD that is needed. P2 adds the SD controller to the SoC. Regards, Peter Peter Crosthwaite (2): sd: sdhci: Delete over-zealous power check arm: fsl-imx25: Add SD support hw/arm/fsl-imx25.c | 26 ++ hw/sd/sdhci.c | 2 +- include/hw/arm/fsl-imx25.h | 9 + 3 files changed, 36 insertions(+), 1 deletion(-) -- 1.9.1
[Qemu-devel] [PATCH 5/5] audio/coreaudio.c: Avoid deprecated AudioDeviceAdd/RemoveIOProc APIs
The AudioDeviceAddIOProc() and AudioDeviceRemoveIOProc() functions were
deprecated in OSX 10.5. Since we don't support any earlier versions of
OSX, we can simply replace them with the new APIs
AudioDeviceCreateIOProcID() and AudioDeviceRemoveIOProcID().
Signed-off-by: Peter Maydell
---
audio/coreaudio.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 32a997b..7150604 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -49,6 +49,7 @@ typedef struct coreaudioVoiceOut {
AudioDeviceID outputDeviceID;
UInt32 audioDevicePropertyBufferFrameSize;
AudioStreamBasicDescription outputStreamBasicDescription;
+AudioDeviceIOProcID ioprocid;
int live;
int decr;
int rpos;
@@ -598,8 +599,12 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct
audsettings *as,
}
/* set Callback */
-status = AudioDeviceAddIOProc(core->outputDeviceID, audioDeviceIOProc, hw);
-if (status != kAudioHardwareNoError) {
+core->ioprocid = NULL;
+status = AudioDeviceCreateIOProcID(core->outputDeviceID,
+ audioDeviceIOProc,
+ hw,
+ &core->ioprocid);
+if (status != kAudioHardwareNoError || core->ioprocid == NULL) {
coreaudio_logerr2 (status, typ, "Could not set IOProc\n");
core->outputDeviceID = kAudioDeviceUnknown;
return -1;
@@ -607,10 +612,10 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct
audsettings *as,
/* start Playback */
if (!isPlaying(core->outputDeviceID)) {
-status = AudioDeviceStart(core->outputDeviceID, audioDeviceIOProc);
+status = AudioDeviceStart(core->outputDeviceID, core->ioprocid);
if (status != kAudioHardwareNoError) {
coreaudio_logerr2 (status, typ, "Could not start playback\n");
-AudioDeviceRemoveIOProc(core->outputDeviceID, audioDeviceIOProc);
+AudioDeviceDestroyIOProcID(core->outputDeviceID, core->ioprocid);
core->outputDeviceID = kAudioDeviceUnknown;
return -1;
}
@@ -628,15 +633,15 @@ static void coreaudio_fini_out (HWVoiceOut *hw)
if (!isAtexit) {
/* stop playback */
if (isPlaying(core->outputDeviceID)) {
-status = AudioDeviceStop(core->outputDeviceID, audioDeviceIOProc);
+status = AudioDeviceStop(core->outputDeviceID, core->ioprocid);
if (status != kAudioHardwareNoError) {
coreaudio_logerr (status, "Could not stop playback\n");
}
}
/* remove callback */
-status = AudioDeviceRemoveIOProc(core->outputDeviceID,
- audioDeviceIOProc);
+status = AudioDeviceDestroyIOProcID(core->outputDeviceID,
+core->ioprocid);
if (status != kAudioHardwareNoError) {
coreaudio_logerr (status, "Could not remove IOProc\n");
}
@@ -659,7 +664,7 @@ static int coreaudio_ctl_out (HWVoiceOut *hw, int cmd, ...)
case VOICE_ENABLE:
/* start playback */
if (!isPlaying(core->outputDeviceID)) {
-status = AudioDeviceStart(core->outputDeviceID, audioDeviceIOProc);
+status = AudioDeviceStart(core->outputDeviceID, core->ioprocid);
if (status != kAudioHardwareNoError) {
coreaudio_logerr (status, "Could not resume playback\n");
}
@@ -670,7 +675,8 @@ static int coreaudio_ctl_out (HWVoiceOut *hw, int cmd, ...)
/* stop playback */
if (!isAtexit) {
if (isPlaying(core->outputDeviceID)) {
-status = AudioDeviceStop(core->outputDeviceID,
audioDeviceIOProc);
+status = AudioDeviceStop(core->outputDeviceID,
+ core->ioprocid);
if (status != kAudioHardwareNoError) {
coreaudio_logerr (status, "Could not pause playback\n");
}
--
2.6.2
[Qemu-devel] [PATCH 2/5] audio/coreaudio.c: Use new-in-OSX-10.6 API for getting default voice
If we're building for OSX 10.6 or better, use the new API
AudioObjectGetPropertyData for getting the default voice.
Signed-off-by: Peter Maydell
---
audio/coreaudio.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 433e009..2211e17 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -32,6 +32,10 @@
#define AUDIO_CAP "coreaudio"
#include "audio_int.h"
+#ifndef MAC_OS_X_VERSION_10_6
+#define MAC_OS_X_VERSION_10_6 1060
+#endif
+
static int isAtexit;
typedef struct {
@@ -50,6 +54,28 @@ typedef struct coreaudioVoiceOut {
int rpos;
} coreaudioVoiceOut;
+#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6
+/* The APIs used here only become available from 10.6 */
+
+static OSStatus coreaudio_get_voice(AudioDeviceID *id)
+{
+UInt32 size = sizeof(*id);
+AudioObjectPropertyAddress addr = {
+kAudioHardwarePropertyDefaultOutputDevice,
+kAudioObjectPropertyScopeGlobal,
+kAudioObjectPropertyElementMaster
+};
+
+return AudioObjectGetPropertyData(kAudioObjectSystemObject,
+ &addr,
+ 0,
+ NULL,
+ &size,
+ id);
+}
+#else
+/* Legacy versions of functions using deprecated APIs */
+
static OSStatus coreaudio_get_voice(AudioDeviceID *id)
{
UInt32 size = sizeof(*id);
@@ -59,6 +85,7 @@ static OSStatus coreaudio_get_voice(AudioDeviceID *id)
&size,
id);
}
+#endif
static void coreaudio_logstatus (OSStatus status)
{
--
2.6.2
[Qemu-devel] [PATCH 0/5] audio/coreaudio.c: Fix deprecation warnings
The coreaudio.c code has for some years now produced compilation warnings about our use of various APIs that were deprecated starting with OSX 10.6. This patchset updates our code to use their replacements. I have been a bit conservative with the approach to moving away from AudioDeviceGetProperty/AudioDeviceSetProperty, because different sources on the web suggest either 10.6 or 10.5 was the point at which you could move to AudioObjectGetProperty/AudioObjectSetProperty, but I don't have a 10.5 system to test with. So I've left the old code in for when building on 10.5 (removing it would be a trivial matter of dropping a lot of ifdeffed code). Incidentally, on the subject of OSX 10.5, I think we should finally drop support for it unless anybody would like to volunteer to actually test building on it. I'll send a separate email about that. (This patch set is intended for 2.6, not 2.5.) Peter Maydell (5): audio/coreaudio.c: Factor out use of AudioHardwareGetProperty audio/coreaudio.c: Use new-in-OSX-10.6 API for getting default voice audio/coreaudio.c: Factor out uses of AudioDeviceGet/SetProperty audio/coreaudio.c: Use new-in-OSX-10.6 APIs when available audio/coreaudio.c: Avoid deprecated AudioDeviceAdd/RemoveIOProc APIs audio/coreaudio.c | 314 +++--- 1 file changed, 252 insertions(+), 62 deletions(-) -- 2.6.2
[Qemu-devel] [PATCH 4/5] audio/coreaudio.c: Use new-in-OSX-10.6 APIs when available
Use the new-in-OSX 10.6 API AudioObjectGetPropertyData() instead
of the deprecated AudioDeviceGetProperty() and AudioDeviceSetProperty()
functions when possible.
Signed-off-by: Peter Maydell
---
audio/coreaudio.c | 107 +-
1 file changed, 106 insertions(+), 1 deletion(-)
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index c7e31ea..32a997b 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -73,6 +73,111 @@ static OSStatus coreaudio_get_voice(AudioDeviceID *id)
&size,
id);
}
+
+static OSStatus coreaudio_get_framesizerange(AudioDeviceID id,
+ AudioValueRange *framerange)
+{
+UInt32 size = sizeof(*framerange);
+AudioObjectPropertyAddress addr = {
+kAudioDevicePropertyBufferFrameSizeRange,
+kAudioDevicePropertyScopeOutput,
+kAudioObjectPropertyElementMaster
+};
+
+return AudioObjectGetPropertyData(id,
+ &addr,
+ 0,
+ NULL,
+ &size,
+ framerange);
+}
+
+static OSStatus coreaudio_get_framesize(AudioDeviceID id, UInt32 *framesize)
+{
+UInt32 size = sizeof(*framesize);
+AudioObjectPropertyAddress addr = {
+kAudioDevicePropertyBufferFrameSize,
+kAudioDevicePropertyScopeOutput,
+kAudioObjectPropertyElementMaster
+};
+
+return AudioObjectGetPropertyData(id,
+ &addr,
+ 0,
+ NULL,
+ &size,
+ framesize);
+}
+
+static OSStatus coreaudio_set_framesize(AudioDeviceID id, UInt32 *framesize)
+{
+UInt32 size = sizeof(*framesize);
+AudioObjectPropertyAddress addr = {
+kAudioDevicePropertyBufferFrameSize,
+kAudioDevicePropertyScopeOutput,
+kAudioObjectPropertyElementMaster
+};
+
+return AudioObjectSetPropertyData(id,
+ &addr,
+ 0,
+ NULL,
+ size,
+ framesize);
+}
+
+static OSStatus coreaudio_get_streamformat(AudioDeviceID id,
+ AudioStreamBasicDescription *d)
+{
+UInt32 size = sizeof(*d);
+AudioObjectPropertyAddress addr = {
+kAudioDevicePropertyStreamFormat,
+kAudioDevicePropertyScopeOutput,
+kAudioObjectPropertyElementMaster
+};
+
+return AudioObjectGetPropertyData(id,
+ &addr,
+ 0,
+ NULL,
+ &size,
+ d);
+}
+
+static OSStatus coreaudio_set_streamformat(AudioDeviceID id,
+ AudioStreamBasicDescription *d)
+{
+UInt32 size = sizeof(*d);
+AudioObjectPropertyAddress addr = {
+kAudioDevicePropertyStreamFormat,
+kAudioDevicePropertyScopeOutput,
+kAudioObjectPropertyElementMaster
+};
+
+return AudioObjectSetPropertyData(id,
+ &addr,
+ 0,
+ NULL,
+ size,
+ d);
+}
+
+static OSStatus coreaudio_get_isrunning(AudioDeviceID id, UInt32 *result)
+{
+UInt32 size = sizeof(*result);
+AudioObjectPropertyAddress addr = {
+kAudioDevicePropertyDeviceIsRunning,
+kAudioDevicePropertyScopeOutput,
+kAudioObjectPropertyElementMaster
+};
+
+return AudioObjectGetPropertyData(id,
+ &addr,
+ 0,
+ NULL,
+ &size,
+ result);
+}
#else
/* Legacy versions of functions using deprecated APIs */
@@ -85,7 +190,6 @@ static OSStatus coreaudio_get_voice(AudioDeviceID *id)
&size,
id);
}
-#endif
static OSStatus coreaudio_get_framesizerange(AudioDeviceID id,
AudioValueRange *framerange)
@@ -169,6 +273,7 @@ static OSStatus coreaudio_get_isrunning(AudioDeviceID id,
UInt32 *result)
&size,
result);
}
+#endif
static void coreaudio_logstatus (OSStatus status)
{
--
2.6.2
[Qemu-devel] [PATCH 1/5] audio/coreaudio.c: Factor out use of AudioHardwareGetProperty
The CoreAudio function AudioHardwareGetProperty has been deprecated
starting with OSX 10.6, so factor out our call to it so we can
provide an equivalent with the new APIs when they exist.
Signed-off-by: Peter Maydell
---
audio/coreaudio.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 6dfd63e..433e009 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -50,6 +50,16 @@ typedef struct coreaudioVoiceOut {
int rpos;
} coreaudioVoiceOut;
+static OSStatus coreaudio_get_voice(AudioDeviceID *id)
+{
+UInt32 size = sizeof(*id);
+
+return AudioHardwareGetProperty(
+kAudioHardwarePropertyDefaultOutputDevice,
+&size,
+id);
+}
+
static void coreaudio_logstatus (OSStatus status)
{
const char *str = "BUG";
@@ -303,12 +313,7 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct
audsettings *as,
audio_pcm_init_info (&hw->info, as);
-/* open default output device */
-propertySize = sizeof(core->outputDeviceID);
-status = AudioHardwareGetProperty(
-kAudioHardwarePropertyDefaultOutputDevice,
-&propertySize,
-&core->outputDeviceID);
+status = coreaudio_get_voice(&core->outputDeviceID);
if (status != kAudioHardwareNoError) {
coreaudio_logerr2 (status, typ,
"Could not get default output Device\n");
--
2.6.2
[Qemu-devel] [PATCH 3/5] audio/coreaudio.c: Factor out uses of AudioDeviceGet/SetProperty
The CoreAudio APIs AudioDeviceGetProperty and AudioDeviceSetProperty are
deprecated from OSX 10.6, so factor out our calls to them so we can
provide versions which use the replacement APIs on OSX newer than 10.5.
Signed-off-by: Peter Maydell
---
audio/coreaudio.c | 141 --
1 file changed, 94 insertions(+), 47 deletions(-)
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 2211e17..c7e31ea 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -87,6 +87,89 @@ static OSStatus coreaudio_get_voice(AudioDeviceID *id)
}
#endif
+static OSStatus coreaudio_get_framesizerange(AudioDeviceID id,
+ AudioValueRange *framerange)
+{
+UInt32 size = sizeof(*framerange);
+
+return AudioDeviceGetProperty(
+id,
+0,
+0,
+kAudioDevicePropertyBufferFrameSizeRange,
+&size,
+framerange);
+}
+
+static OSStatus coreaudio_get_framesize(AudioDeviceID id, UInt32 *framesize)
+{
+UInt32 size = sizeof(*framesize);
+
+return AudioDeviceGetProperty(
+id,
+0,
+false,
+kAudioDevicePropertyBufferFrameSize,
+&size,
+framesize);
+}
+
+static OSStatus coreaudio_set_framesize(AudioDeviceID id, UInt32 *framesize)
+{
+UInt32 size = sizeof(*framesize);
+
+return AudioDeviceSetProperty(
+id,
+NULL,
+0,
+false,
+kAudioDevicePropertyBufferFrameSize,
+size,
+framesize);
+}
+
+static OSStatus coreaudio_get_streamformat(AudioDeviceID id,
+ AudioStreamBasicDescription *d)
+{
+UInt32 size = sizeof(*d);
+
+return AudioDeviceGetProperty(
+id,
+0,
+false,
+kAudioDevicePropertyStreamFormat,
+&size,
+d);
+}
+
+static OSStatus coreaudio_set_streamformat(AudioDeviceID id,
+ AudioStreamBasicDescription *d)
+{
+UInt32 size = sizeof(*d);
+
+return AudioDeviceSetProperty(
+id,
+0,
+0,
+0,
+kAudioDevicePropertyStreamFormat,
+size,
+d);
+}
+
+static OSStatus coreaudio_get_isrunning(AudioDeviceID id, UInt32 *result)
+{
+UInt32 size = sizeof(*result);
+
+return AudioDeviceGetProperty(
+id,
+0,
+0,
+kAudioDevicePropertyDeviceIsRunning,
+&size,
+result);
+}
+
static void coreaudio_logstatus (OSStatus status)
{
const char *str = "BUG";
@@ -181,10 +264,7 @@ static inline UInt32 isPlaying (AudioDeviceID
outputDeviceID)
{
OSStatus status;
UInt32 result = 0;
-UInt32 propertySize = sizeof(outputDeviceID);
-status = AudioDeviceGetProperty(
-outputDeviceID, 0, 0,
-kAudioDevicePropertyDeviceIsRunning, &propertySize, &result);
+status = coreaudio_get_isrunning(outputDeviceID, &result);
if (status != kAudioHardwareNoError) {
coreaudio_logerr(status,
"Could not determine whether Device is playing\n");
@@ -325,7 +405,6 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct
audsettings *as,
{
OSStatus status;
coreaudioVoiceOut *core = (coreaudioVoiceOut *) hw;
-UInt32 propertySize;
int err;
const char *typ = "playback";
AudioValueRange frameRange;
@@ -352,14 +431,8 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct
audsettings *as,
}
/* get minimum and maximum buffer frame sizes */
-propertySize = sizeof(frameRange);
-status = AudioDeviceGetProperty(
-core->outputDeviceID,
-0,
-0,
-kAudioDevicePropertyBufferFrameSizeRange,
-&propertySize,
-&frameRange);
+status = coreaudio_get_framesizerange(core->outputDeviceID,
+ &frameRange);
if (status != kAudioHardwareNoError) {
coreaudio_logerr2 (status, typ,
"Could not get device buffer frame range\n");
@@ -379,15 +452,8 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct
audsettings *as,
}
/* set Buffer Frame Size */
-propertySize = sizeof(core->audioDevicePropertyBufferFrameSize);
-status = AudioDeviceSetProperty(
-core->outputDeviceID,
-NULL,
-0,
-false,
-kAudioDevicePropertyBufferFrameSize,
-propertySize,
-&core->audioDevicePropertyBufferFrameSize);
+status = coreaudio_set_framesize(core->outputDeviceID,
+
&core->audioDevicePropertyBufferFrameSize);
if (status != kAudioHardwareNoError) {
coreaudio_logerr2 (status, typ,
"Could not set device buffer frame size %" PRIu32
"\n",
@@ -396,14 +462,8 @@ static int coreaudio_init_out(HWVoiceOut *hw, struct
audsettings *as,
}
/* get Buffer Frame Size */
-propertySize = sizeof(core->audioDevicePropertyBufferFrameSiz
[Qemu-devel] proposal: drop support for OSX 10.5 hosts from QEMU 2.6
Hi. I'd like to propose that QEMU drops support for OSX 10.5 hosts (and by extension for PPC OSX hosts) starting with QEMU 2.6. The rationale here is basically that it's not tested at all as far as I know -- I have been carefully retaining "only if 10.5" ifdefs in the cocoa UI and audio code as I update it, but since I have no 10.5 system to compile against it this support is only theoretical and I wouldn't be terribly surprised to find that it's actually broken. Dropping 10.5 would also allow us to drop some ifdeffed code paths, but I wouldn't mind carrying them around if we people were actually using them -- which I suspect nobody is! OSX 10.5 is now over 8 years old; I think we'd have dropped it some time ago if it wasn't the last PPC version. My suggested plan would be: * in the 2.5 release notes, announce that support for OSX 10.5 and PPC hosts is deprecated and will be removed from QEMU 2.6 unless somebody steps forward to help with testing * at some point probably a little before 2.6 softfreeze, remove the now unnecessary ifdeffery Any disagreements? Am I wrong about nobody testing QEMU on 10.5? thanks -- PMM
Re: [Qemu-devel] proposal: drop support for OSX 10.5 hosts from QEMU 2.6
> Am 28.11.2015 um 23:10 schrieb Peter Maydell : > > Hi. I'd like to propose that QEMU drops support for OSX 10.5 hosts > (and by extension for PPC OSX hosts) starting with QEMU 2.6. > > The rationale here is basically that it's not tested at all as > far as I know -- I have been carefully retaining "only if 10.5" > ifdefs in the cocoa UI and audio code as I update it, but since > I have no 10.5 system to compile against it this support is > only theoretical and I wouldn't be terribly surprised to find > that it's actually broken. Dropping 10.5 would also allow us to drop > some ifdeffed code paths, but I wouldn't mind carrying them around if > we people were actually using them -- which I suspect nobody is! > OSX 10.5 is now over 8 years old; I think we'd have dropped it > some time ago if it wasn't the last PPC version. > > My suggested plan would be: > * in the 2.5 release notes, announce that support for OSX 10.5 and PPC > hosts is deprecated and will be removed from QEMU 2.6 unless somebody > steps forward to help with testing > * at some point probably a little before 2.6 softfreeze, remove the > now unnecessary ifdeffery > > Any disagreements? Am I wrong about nobody testing QEMU on 10.5? I think that sounds reasonable :) Alex
Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/77] ppc: Add "native" POWER8 platform
On Sat, 2015-11-28 at 11:53 +0100, Alexander Graf wrote: > > > Am 28.11.2015 um 08:59 schrieb Benjamin Herrenschmidt > crashing.org>: > > > > > On Fri, 2015-11-27 at 11:21 +0100, Alexander Graf wrote: > > > > > > How does real hardware store petitboot? If it's flash, you could > > > pass it > > > in using -pflash and thus model things even more closely and > > > allow users > > > to just take the ROM image as is. > > > > It is a flash image, we could use an Open Power machine flash image > > "as-is" > > provided we taught qemu to extract skiboot (aka OPAL) from it. > > That's probably the best way. If it's memory mapped, you might not > even have to extract anything - just jump to its location ;). It's not memory mapped sadly (well not on P8...) The way a real P8 boots is first a little internal uC executes code from a i2c seeprom to initialize a core and some cache. It then copies a payload from flash into that cache. That payload is HostBoot, which is a huge thing that initializes a pile of stuff such as the internal busses, SMP links, links to memory buffers, trains memory etc... it then constructs an embryo device-tree and loads & run OPAL (aka skiboot). The model I chose for powernv is to simulate a boot at the hostboot -> skiboot transition point. > The -kernel syntax is useful to have, but should really be something > "on top" of the normal system boot rather than its primary boot > interface. I know, I'm just not keen on committing a 16M "BIOS" to qemu tree ;-) In any case, this is easy to change / fix. There's a lot more work on the rest of the series first. Cheers, Ben.
