Re: [Qemu-devel] [PATCH 08/13] be-hci: use backend functions
On 26 May 2017 at 14:20, Marc-André Lureau wrote:
> On Tue, May 9, 2017 at 3:42 PM Marc-André Lureau <
> marcandre.lur...@redhat.com> wrote:
>> Avoid accessing CharBackend directly, use qemu_chr_be_* methods instead.
>>
>> be->chr_read should exists if qemu_chr_be_can_write() is true.
>>
>> (use qemu_chr_be_write(), _impl() bypasses replay)
>>
>> Signed-off-by: Marc-André Lureau
>> ---
>> hw/bt/hci-csr.c | 9 +++--
>>
>
> No maintainer for this file. Andrzej, as author of the file, can you
> review?
This looks correct.
Reviewed-by: Andrzej Zaborowski
>
>
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/bt/hci-csr.c b/hw/bt/hci-csr.c
>> index 0f2021086d..d13192b9b5 100644
>> --- a/hw/bt/hci-csr.c
>> +++ b/hw/bt/hci-csr.c
>> @@ -82,17 +82,14 @@ enum {
>>
>> static inline void csrhci_fifo_wake(struct csrhci_s *s)
>> {
>> -Chardev *chr = (Chardev *)s;
>> -CharBackend *be = chr->be;
>> +Chardev *chr = CHARDEV(s);
>>
>> if (!s->enable || !s->out_len)
>> return;
>>
>> /* XXX: Should wait for s->modem_state & CHR_TIOCM_RTS? */
>> -if (be && be->chr_can_read && be->chr_can_read(be->opaque) &&
>> -be->chr_read) {
>> -be->chr_read(be->opaque,
>> - s->outfifo + s->out_start++, 1);
>> +if (qemu_chr_be_can_write(chr)) {
>> +qemu_chr_be_write(chr, s->outfifo + s->out_start++, 1);
>> s->out_len--;
>> if (s->out_start >= s->out_size) {
>> s->out_start = 0;
>> --
>> 2.13.0.rc1.16.gd80b50c3f
>>
>>
>> --
> Marc-André Lureau
Re: [Qemu-devel] Fw: Max7310: confused about the method of reading output port register
Hi Yang,
On 26 August 2013 03:47, Yang Ning wrote:
>
> Dear All:
>
> Firstly,I'm writing to express my thanks to Zaborowski for the source code
> of Max7310 which have helped me so much.
> But I'm still confused about the method of reading output port register.
> code:
>>
>>case 0x01: /* Output port */
>>return s->level & ~s->direction;
>>break;
>
>
> I found some instruction of output port register in the datasheet.
>>
>> " Reads from the output port register reflect the value that is in the
>> flip-flop
>> controlling the output selection, not the actual I/O value, which may
>> differ if
>> the out-put is overloaded."
>
>
> So,in my opinion,in the defination of MAX7310State,whether the property of
> outputport_reg should be added?
> And does the method of reading/writing output port should be modified as
> follows.
>
> [reading]
> case 0x01: /* Output port */
> return s->outputport_reg;
> break;
> [writing]
> case 0x01: /* Output port */
>>
>>for (diff = (data ^ s->level) & ~s->direction; diff;
>>diff &= ~(1 << line)) {
>> line = ffs(diff) - 1;
>>if (s->handler[line])
>>qemu_set_irq(s->handler[line], (data >> line) & 1);
>>}
>>s->level = (s->level & s->direction) | (data & ~s->direction);
>
> s->outputport_reg = data;
> break;
Yes, if by "overload" they mean change direction to "input", then yes,
I think you are correct.
Personally I'd call it s->output. I'm wondering if we may need to
update the output levels when the Configuration (0x03) is written and
on reset. This would be best done by adding a short function
max7310_update() that does the "for (diff = ...)" loop and calls
qemu_set_irq.
Best regards
Re: [Qemu-devel] Usage of Temperature Sensor (TMP105)
Hi Alex, On 1 December 2012 20:39, Alex Horn wrote: > Hello all, > > As I have been browsing through QEMU's source code, I've noticed a > hardware model for a temperature sensor called TMP105. This model > implements the function tmp105_set(I2CSlave *i2c, int temp) declared > in i2c.h [0, 1]. > > Surprisingly, however, I cannot find any code which calls this setter > function despite the fact that "CONFIG_TMP105=y" in at least one > target (e.g. [2]). > > I am keen to learn who uses this virtual device, i.e. who calls > tmp105_set(). This may answer my question if there exists a > "third-party" model which could simulate temperature changes in the > chip. Most likely the function has never been in use. It is there for completeness of the API. I was considering using it as a qemu monitor command if there is ever need to test the guest under changing temperature (e.g. some UI elements showing temperature changes). Cheers
[Qemu-devel] [PATCH] bt: HCI Reset returns a Cmd Complete event.
HCI Reset command returns a Command Complete event, not a Command Status event. We need to avoid resetting the stored last command code for the response to be fully correct. Signed-off-by: Andrzej Zaborowski --- hw/bt-hci.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/hw/bt-hci.c b/hw/bt-hci.c index a3a7fb4..8c717f9 100644 --- a/hw/bt-hci.c +++ b/hw/bt-hci.c @@ -1783,7 +1783,8 @@ static void bt_submit_hci(struct HCIInfo *info, case cmd_opcode_pack(OGF_HOST_CTL, OCF_RESET): bt_hci_reset(hci); -bt_hci_event_status(hci, HCI_SUCCESS); +hci->last_cmd = cpu_to_le16(cmd); +bt_hci_event_complete_status(hci, HCI_SUCCESS); break; case cmd_opcode_pack(OGF_HOST_CTL, OCF_SET_EVENT_FLT): -- 1.7.4.4
[Qemu-devel] [PATCH] bt: Fix the bitmask in event masked check.
Signed-off-by: Andrzej Zaborowski --- hw/bt-hci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/bt-hci.c b/hw/bt-hci.c index 8c717f9..48cbbb5 100644 --- a/hw/bt-hci.c +++ b/hw/bt-hci.c @@ -442,7 +442,7 @@ static inline uint8_t *bt_hci_event_start(struct bt_hci_s *hci, } mask_byte = (evt - 1) >> 3; -mask = 1 << ((evt - 1) & 3); +mask = 1 << ((evt - 1) & 7); if (mask & bt_event_reserved_mask[mask_byte] & ~hci->event_mask[mask_byte]) return NULL; -- 1.7.4.4
Re: [Qemu-devel] [PATCH next v2 33/74] pxa2xx: Use cpu_arm_init() and store ARMCPU
On 11 May 2012 13:16, Peter Maydell wrote: > On 10 May 2012 01:14, Andreas Färber wrote: >> Also use cpu_reset() in place of cpu_state_reset(). >> >> Signed-off-by: Andreas Färber > > The pxa2xx stuff is probably going to clash with the cp15 > rework, but I guess we'll sort that out when one or the > other of these series hits master. > > Acked-by: Peter Maydell Also looks good to me. > > (The stuff pxa2xx.c is doing to CPUARMState is a really > gross layering violation, incidentally.) The code reflects what the hardware is doing though. One could argue that if a hardware emulator divides things into layers where the real hardware violates those layers then the division is not fully correct. Cheers
Re: [Qemu-devel] SD card subsystem synchronous I/O
On 20 April 2012 11:50, Stefan Hajnoczi wrote: > On Fri, Apr 20, 2012 at 12:21 AM, andrzej zaborowski > wrote: >> Yes, controllers would be affected, but there are various ways to go >> about it. Some could be simple to implement (looking at >> pxa2xx_mmci.c). First of all the SD specification pretty much assumes >> the storage medium is flash and data is available "immediately" after >> it is requested. The host drives the clock and there's a fixed number >> of cycles that pass between a command and the response. There's a >> mechanism for the card to indicate it is busy programming after data >> is written, but it doesn't apply to some types of writes. >> >> However the number of cycles between command and response can be >> different between card manufacturers, so it looks like the card can >> pull either the CMD and the DAT line high before starting to send the >> command response or the data. In qemu you could either make the data >> transfers async, or the response transfers async, there's no need to >> do both. >> >> If the image is on a network filesystem then there could be problems >> caused by the synchronous IO. Anything else, I'd guess that the >> caches, readahead and what not make sync IO the same or unnoticeably >> faster overall. pxa2xx_mmci.c would be easy to convert to async, but >> some host controllers that are more software than hardware might >> theoretically give up if the card doesn't respond in N cycles. > > Even in a case where the bus specification is strict about timing it's > possible that the controllers that guest drivers talk to hide those > details and instead work on an interrupt-driven basis. Yep. > > In other words, maybe most of the work will be converting controllers > to implement the busy state while we do actual block I/O. Is this > possible or do SD controllers expose the real low-level timing aspects > of the bus to the guest drivers? The PXA270 one does not and it would be quite easy to convert, as mentioned. It's probably true for most SoCs' controllers. Many devices (not necessarily emulated in Qemu) just have the SD card's pads wired to GPIOs and driven in software or other solutions between fully software and fully hardware. Linux doesn't have any generic "bit banging" driver for them as far as I can see. Cheers
Re: [Qemu-devel] SD card subsystem synchronous I/O
On 18 April 2012 14:35, Stefan Hajnoczi wrote: > Recently there have been new SD card emulation patches so I want to > raise the issue of synchronous I/O while there is focus on the SD > subsystem. Maybe some of the people who are improving the SD > subsystem will be able to help. > > sd_blk_read() and sd_blk_write() use the synchronous block I/O > functions to read/write data on behalf of the guest. Device emulation > runs in the vcpu thread with the QEMU global mutex held, and therefore > both the guest vcpu and QEMU's own monitor and VNC server are > unresponsive while bdrv_read()/bdrv_write() is blocked. > > This makes bdrv_read()/bdrv_write() in device emulation code a > performance problem - the guest becomes unresponsive and laggy under > heavy I/O. In extreme cases, like image files on NFS with a network > connectivity issue, it can affect the reliability of QEMU as a whole > because the monitor and VNC are unavailable until the I/O operation > completes. > > Device emulation should use the bdrv_aio_readv()/bdrv_aio_writev() > functions so that control can return to the guest. When the I/O > operation completes a callback function is invoked and the device > emulation can signal completion to the guest - usually by setting bits > in hardware registers and raising an interrupt. The result is good > responsiveness and the monitor/VNC remain available even under heavy > I/O. > > The challenge is how to convert hw/sd.c and possibly update emulated > SD controllers. We need to stop assuming that a read/write operation > can be performed instantly and need to use a > bdrv_aio_readv()/bdrv_aio_writev() callback function to complete the > I/O. > > Since I am not familiar with the SD specification or the hw/sd.c code > very well I want to check: > > * Is anyone willing to convert the SD subsystem? > > * Will it be possible to convert just hw/sd.c without affecting > emulated SD controllers? > * If we're going to need to fix all controllers in addition to > hw/sd.c, then adding more controllers grows the problem. Yes, controllers would be affected, but there are various ways to go about it. Some could be simple to implement (looking at pxa2xx_mmci.c). First of all the SD specification pretty much assumes the storage medium is flash and data is available "immediately" after it is requested. The host drives the clock and there's a fixed number of cycles that pass between a command and the response. There's a mechanism for the card to indicate it is busy programming after data is written, but it doesn't apply to some types of writes. However the number of cycles between command and response can be different between card manufacturers, so it looks like the card can pull either the CMD and the DAT line high before starting to send the command response or the data. In qemu you could either make the data transfers async, or the response transfers async, there's no need to do both. If the image is on a network filesystem then there could be problems caused by the synchronous IO. Anything else, I'd guess that the caches, readahead and what not make sync IO the same or unnoticeably faster overall. pxa2xx_mmci.c would be easy to convert to async, but some host controllers that are more software than hardware might theoretically give up if the card doesn't respond in N cycles. Cheers
[Qemu-devel] [PATCH 6/6 v2] gl: -enable-gl switch to enable the OpenGL virtio port.
Signed-off-by: Andrzej Zaborowski
---
qemu-options.hx | 24
vl.c| 36
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index b129996..8a5784c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1114,6 +1114,30 @@ spec but is traditional qemu behavior.
@end table
ETEXI
+DEF("enable-gl", 0, QEMU_OPTION_enable_gl, \
+"-enable-gl enable OpenGL passthrough support\n", QEMU_ARCH_ALL)
+STEXI
+@item -enable-gl
+@findex -enable-gl
+Enable OpenGL passthrough support in QEMU. Requires corresponding client
+software in the guest OS. Requires hardware graphics acceleration
+on host system. Only virtio-capable target machines supported. Does
+not support vmsave/vmload or migration.
+
+@strong{NOTE}: this feature has not been security reviewed and assumes that
+the emulator runs a trusted guest system. Enabling this option may allow
+rogue software in the emulator to crash or control QEMU. Do not use this
+option if unsure.
+
+This option allows the emulated system to take advantage of hardware-
+accelerated OpenGL support of the host machine to speed up applications
+that make heavy use of OpenGL graphics (3D or otherwise) - useful during
+the development of such applications. For Linux guests running X.org, the
+client software can be installed from
+@url{http://meego.gitorious.org/meego-developer-tools/meego-emulator-libgl-x86}
+or distribution packages if available.
+ETEXI
+
STEXI
@end table
ETEXI
diff --git a/vl.c b/vl.c
index 37f2f96..a2f1c84 100644
--- a/vl.c
+++ b/vl.c
@@ -228,6 +228,7 @@ int ctrl_grab = 0;
unsigned int nb_prom_envs = 0;
const char *prom_envs[MAX_PROM_ENVS];
int boot_menu;
+int enable_gl;
uint8_t *boot_splash_filedata;
int boot_splash_filedata_size;
uint8_t qemu_extra_params_fw[2];
@@ -312,6 +313,21 @@ static int default_driver_check(QemuOpts *opts, void
*opaque)
return 0;
}
+typedef struct {
+const char *device_name;
+int found;
+} device_opt_search_t;
+
+static int find_device_opt(QemuOpts *opts, void *opaque)
+{
+device_opt_search_t *devp = (device_opt_search_t *) opaque;
+
+devp->found = devp->found ||
+!strcmp(qemu_opt_get(opts, "driver"), devp->device_name);
+
+return 0;
+}
+
/***/
/* QEMU state */
@@ -2896,6 +2912,11 @@ int main(int argc, char **argv, char **envp)
machine = machine_parse(optarg);
}
break;
+#ifdef CONFIG_GL
+case QEMU_OPTION_enable_gl:
+enable_gl = 1;
+break;
+#endif
case QEMU_OPTION_usb:
usb_enabled = 1;
break;
@@ -3133,6 +3154,21 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+if (enable_gl) {
+QemuOptsList *device = qemu_find_opts("device");
+QemuOpts *bus_opts, *dev_opts;
+device_opt_search_t devp = { "virtio-serial", 0 };
+
+qemu_opts_foreach(device, find_device_opt, &devp, 0);
+if (devp.found == 0) {
+bus_opts = qemu_opts_create(device, NULL, 0);
+qemu_opt_set(bus_opts, "driver", "virtio-serial");
+}
+
+dev_opts = qemu_opts_create(device, NULL, 0);
+qemu_opt_set(dev_opts, "driver", "virtio-gl-port");
+}
+
/* If no data_dir is specified then try to find it relative to the
executable path. */
if (!data_dir) {
--
1.7.4.4
[Qemu-devel] [PATCH 5/6 v2] gl: virtio-serial port driver for OpenGL passthrough.
This is a relatively simple to use OpenGL passthrough transport
because it doesn't need any guest kernel changes, but it's not
blazing fast. Still faster than software rendering.
The main problems are:
* transfers are split in very small chunks by virtio queues, some
OpenGL calls (think textures etc.) will take thousands of context
switches, vmenters/vmexits, sysenters/sysexits and buffer copying.
This should really be a single big zerocopy transfer.
* Linux virtio-serial allows only one process to have the port opened,
so applications on the guest have to fight over the port access
and open/close the device at every command buffer.
* host cannot know for sure when a guest process has died unexpectedly.
Signed-off-by: Andrzej Zaborowski
---
v2: rebase after QOM.
---
Makefile.target |3 +-
hw/virtio-gl-port.c | 220 +++
2 files changed, 222 insertions(+), 1 deletions(-)
create mode 100644 hw/virtio-gl-port.c
diff --git a/Makefile.target b/Makefile.target
index 90e2739..3fae6ec 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -199,7 +199,8 @@ obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o
balloon.o ioport.o
# virtio has to be here due to weird dependency between PCI and virtio-net.
# need to fix this properly
obj-$(CONFIG_NO_PCI) += pci-stub.o
-obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o
virtio-serial-bus.o
+obj-virtio-$(CONFIG_GL) += virtio-gl-port.o
+obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o
virtio-serial-bus.o $(obj-virtio-y)
obj-y += vhost_net.o
obj-$(CONFIG_VHOST_NET) += vhost.o
obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/virtio-9p-device.o
diff --git a/hw/virtio-gl-port.c b/hw/virtio-gl-port.c
new file mode 100644
index 000..dbeaa2e
--- /dev/null
+++ b/hw/virtio-gl-port.c
@@ -0,0 +1,220 @@
+/*
+ * GL passthrough virtio-serial-based transport
+ *
+ * Copyright (c) 2011 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) any later version of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "hw.h"
+#include "qemu-error.h"
+#include "virtio-serial.h"
+
+#include "gl/vmgl.h"
+
+#define CMD_HEADER_SIZE 12
+
+static uint8_t *cmd_buffer;
+static size_t cmd_buffer_bytes;
+static size_t cmd_buffer_size;
+static const uint8_t *ret_buffer;
+static size_t ret_buffer_bytes;
+
+static size_t virtio_gl_get_cmd_size(const uint8_t *buf)
+{
+#ifdef TARGET_WORDS_BIGENDIAN
+return be32_to_cpup((const uint32_t *) buf);
+#else
+return le32_to_cpup((const uint32_t *) buf);
+#endif
+}
+
+static size_t virtio_gl_get_buffer_size(const uint8_t *buf)
+{
+return virtio_gl_get_cmd_size(buf + 4);
+}
+
+static void virtio_gl_guest_ready(VirtIOSerialPort *port)
+{
+ssize_t ret;
+
+if (!ret_buffer_bytes) {
+return;
+}
+
+ret = virtio_serial_write(port, ret_buffer, ret_buffer_bytes);
+if (ret < 0) {
+error_report("%s: virtio_serial_write: error %i\n", __func__,
+(int) -ret);
+return;
+}
+ret_buffer += ret;
+ret_buffer_bytes -= ret;
+}
+
+static void virtio_gl_handle_cmd(VirtIOSerialPort *port, const uint8_t *cmd)
+{
+int pid = le32_to_cpup((const uint32_t *) cmd);
+int in_size = virtio_gl_get_cmd_size(cmd + 4);
+int ret;
+ProcessStruct *process = vmgl_get_process(pid);
+
+ret_buffer_bytes = virtio_gl_get_cmd_size(cmd + 8);
+if (cmd_buffer_size < ret_buffer_bytes) {
+cmd_buffer_size = ret_buffer_bytes;
+cmd_buffer = g_realloc(cmd_buffer, cmd_buffer_size);
+}
+ret_buffer = cmd_buffer;
+
+ret = vmgl_decode_call(process, cmd + CMD_HEADER_SIZE,
+in_size - CMD_HEADER_SIZE, cmd_buffer + 4);
+if (!ret) {
+vmgl_disconnect(process);
+return;
+}
+
+#ifdef TARGET_WORDS_BIGENDIAN
+cpu_to_be32wu((uint32_t *) ret_buffer, ret);
+#else
+cpu_to_le32wu((uint32_t *) ret_buffer, ret);
+#endif
+/* FIXME: passing the buffer to decode_call_int and calling
+ * virtio_serial_write precludes zero-copy, figure out something
+ * better. */
+virtio_gl_guest_ready(port);
+}
+
+static void virtio_gl_guest_close(VirtIOSerialPort *port)
+{
+cmd_buffer_bytes = 0;
+ret_buffer_bytes = 0;
+}
+
+/* Callback function that's called when the gues
[Qemu-devel] [PATCH 4/6 v2] virtio-serial: Call .guest_ready when new space is available in the queue.
Without that it's impossible to write a virtio-serial port driver that
sends any buffers bigger than a couple kilobytes, other than by
polling to check when space in the queue becomes available.
Signed-off-by: Andrzej Zaborowski
---
v2: rebase after QOM.
---
hw/virtio-serial-bus.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index e22940e..fe350a1 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -498,6 +498,14 @@ static void handle_output(VirtIODevice *vdev, VirtQueue
*vq)
static void handle_input(VirtIODevice *vdev, VirtQueue *vq)
{
+VirtIOSerial *vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+VirtIOSerialPort *port = find_port_by_vq(vser, vq);
+VirtIOSerialPortClass *info =
+port ? VIRTIO_SERIAL_PORT_GET_CLASS(port) : NULL;
+
+if (info && info->guest_ready) {
+info->guest_ready(port);
+}
}
static uint32_t get_features(VirtIODevice *vdev, uint32_t features)
--
1.7.4.4
Re: [Qemu-devel] "qemu -device ?" segfaults
On 23 February 2012 09:48, Markus Armbruster wrote: > andrzej zaborowski writes: > >> On 23 February 2012 09:20, Gerd Hoffmann wrote: >>> $subject says all, which pretty much breaks libvirt-managed qemu ... >> >> Also "device_add nonexistent-device" in the monitor gives a rather >> unhelpful message: >> >> Parameter 'driver' expects device type > > "-device foo" is really shorthand for "-device driver=foo". And deep > down in the bowels of qdev, where the error get reported, the value of > parameter "driver" gets treated like any other parameter's value: if > it's not within ACCEPTABLE-SET, complain "Parameter 'NAME' expected > ACCEPTABLE-SET". Yeah, I looked at this code, perhaps "'INPUT' is not a valid 'ACCEPTABLE-SET'" would be more helpful. In my message I was talking about the monitor command though. Something like "you typoed in the device name" should be reported by the human readable monitor. Cheers
Re: [Qemu-devel] "qemu -device ?" segfaults
On 23 February 2012 09:20, Gerd Hoffmann wrote: > $subject says all, which pretty much breaks libvirt-managed qemu ... Also "device_add nonexistent-device" in the monitor gives a rather unhelpful message: Parameter 'driver' expects device type Cheers
Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage
On 22 February 2012 13:48, Peter Maydell wrote: > On 22 February 2012 12:13, andrzej zaborowski wrote: >> On 22 February 2012 13:00, Peter Maydell wrote: >>> On 22 February 2012 11:36, andrzej zaborowski wrote: >>>> On 22 February 2012 11:15, Igor Mitsyanko wrote: >>>>> Convert three variables in DMAChannel state from type target_phys_addr_t >>>>> to uint32_t, >>>>> use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables. >>>>> We can do it safely because: >>>>> 1) pxa2xx has 32-bit physical address; >>>>> 2) rest of the code in this file treats these variables as uint32_t; >>>> >>>> Why's uint32_t more correct though? The purpose of using a named type >>>> across qemu is to mark fields as memory addresses (similar to size_t >>>> being used for sizes, etc.), uint32_t conveys less information -- only >>>> the size. >>>> >>>> It's a safe hack, but I don't see the rationale. >>> >>> Because we might change target_phys_addr_t to 64 bits globally >>> some day (it's certainly been mooted) and that shouldn't suddenly >>> change the register width and certainly shouldn't change the >>> migration state. >>> >>> Basically VMSTATE_UINTTL in hw/ is always a bug, because its >>> behaviour depends on the size of target_ulong, which is a >>> property of the CPU, which is a completely separate device. >> >> I'm not really discussing that, my question is unrelated to >> migration/savevm because the patch touches parts that shouldn't be >> concerned with migration. If a particular function (like migration) >> needs the type converted to something then that's why C has type >> conversions. A type conversion that compiles to no code is still a >> type conversion. > > Well, target_phys_addr_t is the wrong type here because it's > really "at least as large as the widest address type in the > system" (cf proposals to make it 64 bits), so using it for > a register that must be exactly 32 bits wide is wrong. So we > need to change it to something, and customarily what we use > for "I am modelling a physical register which is 32 bits wide" > is uint32_t. Introducing extra device-specific typedefs to > try to label the semantics of device registers seems a bit > unnecessary to me. If we treat the struct as a representation of the register values rather than state of the emulated device then I guess you're right. The reason it rings an alarm is that the change is not an improvement (other than for migration, but again the change is in code that is not related to savevm) Cheers
Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage
On 22 February 2012 13:26, Mitsyanko Igor wrote: > On 02/22/2012 03:36 PM, andrzej zaborowski wrote: >> Why's uint32_t more correct though? The purpose of using a named type >> across qemu is to mark fields as memory addresses (similar to size_t >> being used for sizes, etc.), uint32_t conveys less information -- only >> the size. > > It's obviously more informative, but I thought it's main purpose is to be > used with code that could be executed for a different targets (with > different address bus width). In some case for sure, but I believe not in most cases. > > > >> It's a safe hack, but I don't see the rationale. > > > I don't consider this a hack, we are trying to emulate real hardware, and > pxa lcd and dma controllers are intended to work with 32-bit bus. We should > not have a possibility to use them with 64-bit targets. > > >> If it's because VMSTATE_UINT32 requires that specific type than a less >> ugly hack would be to make a pxa specific memory address type. >> > > Introducing new type doesn't look pretty to me, Why? > maybe just rename variables > to source_addr, dest_addr e.t.c? Wouldn't it be analogous to changing pointer typed variables to void * and adding the actual type in their names? The result is that at language level they'll all be the same type even though they are not. (or changing le32 and be32 to uint32 in Linux) Cheers
Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage
On 22 February 2012 13:00, Peter Maydell wrote: > On 22 February 2012 11:36, andrzej zaborowski wrote: >> On 22 February 2012 11:15, Igor Mitsyanko wrote: >>> Convert three variables in DMAChannel state from type target_phys_addr_t to >>> uint32_t, >>> use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables. >>> We can do it safely because: >>> 1) pxa2xx has 32-bit physical address; >>> 2) rest of the code in this file treats these variables as uint32_t; >> >> Why's uint32_t more correct though? The purpose of using a named type >> across qemu is to mark fields as memory addresses (similar to size_t >> being used for sizes, etc.), uint32_t conveys less information -- only >> the size. >> >> It's a safe hack, but I don't see the rationale. > > Because we might change target_phys_addr_t to 64 bits globally > some day (it's certainly been mooted) and that shouldn't suddenly > change the register width and certainly shouldn't change the > migration state. > > Basically VMSTATE_UINTTL in hw/ is always a bug, because its > behaviour depends on the size of target_ulong, which is a > property of the CPU, which is a completely separate device. I'm not really discussing that, my question is unrelated to migration/savevm because the patch touches parts that shouldn't be concerned with migration. If a particular function (like migration) needs the type converted to something then that's why C has type conversions. A type conversion that compiles to no code is still a type conversion. > >> If it's because VMSTATE_UINT32 requires that specific type than a less >> ugly hack would be to make a pxa specific memory address type. > > Yuck. Or a general 32-bit memory address type, but as I said uint32_t conveys less information. Do you disagree? Cheers
Re: [Qemu-devel] [PATCH 3/5] hw/pxa2xx_lcd.c: drop VMSTATE_UINTTL usage
On 22 February 2012 11:15, Igor Mitsyanko wrote: > Convert three variables in DMAChannel state from type target_phys_addr_t to > uint32_t, > use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables. > We can do it safely because: > 1) pxa2xx has 32-bit physical address; > 2) rest of the code in this file treats these variables as uint32_t; Why's uint32_t more correct though? The purpose of using a named type across qemu is to mark fields as memory addresses (similar to size_t being used for sizes, etc.), uint32_t conveys less information -- only the size. It's a safe hack, but I don't see the rationale. If it's because VMSTATE_UINT32 requires that specific type than a less ugly hack would be to make a pxa specific memory address type. Cheers
[Qemu-devel] [PATCH v3] Add tab-completion for device_add.
From: Andrzej Zaborowski
Signed-off-by: Andrzej Zaborowski
---
v2: pass only char *prop_name as qdev_driver_prop_foreach_func parameter,
Anthony noted Property was soon going away.
v3: use QOM.
---
monitor.c | 58 ++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index aadbdcb..28f5b9a 100644
--- a/monitor.c
+++ b/monitor.c
@@ -3917,6 +3917,27 @@ static void block_completion_it(void *opaque,
BlockDriverState *bs)
}
}
+static void class_completion_it(ObjectClass *klass, void *opaque)
+{
+const char *input = opaque;
+const char *name = object_class_get_name(klass);
+
+if (input[0] == '\0' || !strncmp(name, input, strlen(input))) {
+readline_add_completion(cur_mon->rs, name);
+}
+}
+
+static int driver_prop_completion_it(Property *info, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(info->name, input, strlen(input))) {
+readline_add_completion(cur_mon->rs, info->name);
+}
+
+return 0;
+}
+
/* NOTE: this parser is an approximate form of the real command parser */
static void parse_cmdline(const char *cmdline,
int *pnb_args, char **args)
@@ -3957,6 +3978,7 @@ static void monitor_find_completion(const char *cmdline)
const char *ptype, *str;
const mon_cmd_t *cmd;
const KeyDef *key;
+char *pkey;
parse_cmdline(cmdline, &nb_args, args);
#ifdef DEBUG_COMPLETION
@@ -3995,6 +4017,7 @@ static void monitor_find_completion(const char *cmdline)
goto cleanup;
}
+key_get_info(cmd->args_type, &pkey);
ptype = next_arg_type(cmd->args_type);
for(i = 0; i < nb_args - 2; i++) {
if (*ptype != '\0') {
@@ -4040,9 +4063,44 @@ static void monitor_find_completion(const char *cmdline)
}
}
break;
+case 'O':
+if (!strcmp(pkey, "device")) {
+char *sep = strrchr(str, ',');
+
+readline_set_completion_index(cur_mon->rs,
+strlen(sep ? sep + 1 : str));
+if (sep) {
+char *driver = g_strndup(str, strchr(str, ',') - str);
+ObjectClass *klass = object_class_by_name(driver);
+DeviceClass *info;
+Property *prop;
+
+g_free(driver);
+if (!klass) {
+break;
+}
+
+info = DEVICE_CLASS(klass);
+for (prop = info->props; prop && prop->name; prop++) {
+driver_prop_completion_it(prop, sep + 1);
+}
+if (info->bus_info) {
+for (prop = info->bus_info->props;
+prop && prop->name; prop++) {
+driver_prop_completion_it(prop, sep + 1);
+}
+}
+break;
+}
+
+object_class_foreach(class_completion_it, TYPE_DEVICE, 0,
+(void *) str);
+}
+break;
default:
break;
}
+g_free(pkey);
}
cleanup:
--
1.7.4.4
-
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk
Sad Rejonowy Gdansk Polnoc w Gdansku,
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego,
numer KRS 101882
NIP 957-07-52-316
Kapital zakladowy 200.000 zl
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Re: [Qemu-devel] omap_i2c: distinction between OMAP2_INTR_REV and OMAP2_GC_REV?
On 20 February 2012 13:12, andrzej zaborowski wrote: > I have neither of the TRMs at hand but I downloaded the TRM for > omap35x which features i2c module 3.1 and it looks like the current Sorry, the revision is not given in the TRM, 3.1 is an example. Cheers
Re: [Qemu-devel] omap_i2c: distinction between OMAP2_INTR_REV and OMAP2_GC_REV?
Hi, On 17 February 2012 19:21, Peter Maydell wrote: > I'm looking at cleaning up some more omap3 patches, and have > been working on the omap_i2c related ones. At the moment in > omap_i2c.c there are the following #defines for the I2C module > revision (as exposed via the revision register): > > #define OMAP2_INTR_REV 0x34 > #define OMAP2_GC_REV 0x34 > > (plus a hardcoded 0x11 used by omap_i2c_init for omap1.) > and it then uses both #defines apparently interchangeably > when doing tests against the s->revision field. > > Does anybody know what the distinction between these two constants > is supposed to be? They were introduced by commit 29885477 > back in 2008... (Also, why "INTR" and "GC"?) Apparently the intent was for the revision to be used to enable/disable different features of the I2C module. OMAP2_GC_REV should be the minimum revision where the omap2 Global Call interrupt is available. INTR seems to be the feature that enables the interrupt status to be read resetting some interrupt flags. There's an assumption that every revision is backwards compatible and features never go away. I think another assumption was that between the I2C module revision 1.1 and 3.4 other features were introduced gradually, so omap1/omap2/omap3 resolution would not be enough. I have neither of the TRMs at hand but I downloaded the TRM for omap35x which features i2c module 3.1 and it looks like the current code is not even handling the masking of all the interrupts of that version correctly (there are 14 in 3.1) > > The patchset I'm trying to clean up goes for: > #define OMAP1_INTR_REV 0x11 > #define OMAP2_INTR_REV 0x34 > #define OMAP3_INTR_REV 0x3c > #define OMAP3630_INTR_REV 0x40 > > although I'm not sure whether 'INTR' makes much sense rather > than 'I2C' or something. I'll stick with these constants if nobody > has a better idea, but I was wondering if anybody could remember > the history behind the current constant names... I guess it would be a change of semantics rather than clean-up, but it may a good idea. On the other hand I don't see much benefit from using those defines instead of hardcoding the revision values in the init functions. Cheers
Re: [Qemu-devel] [PATCH RFC v3 14/21] target-arm: Move the PXA270's iwMMXt reset to pxa270_reset()
On 17 February 2012 13:03, Andreas Färber wrote: > Am 17.02.2012 10:59, schrieb andrzej zaborowski: >> On 3 February 2012 03:59, Andreas Färber wrote: >>> No other emulated CPU uses this at this time. >> >> But why does this code better fit in hw/ than target-arm? The iwMMXt >> registers are core registers after all. > > It seems you've misread something here. This is all in target-arm. :) Yes, I did, sorry. I had looked at the whole series previously, forgotten it, then looked at this patch that was still in my inbox without any of the context. ... > The final plan for rnpn is to have two QOM properties and to request a > "pxa270" CPU, then set the revision since there are no functional > dependencies on the revision at all. (cc'ing Paul) > I've actually compile-tested and grep'ed this. > Sounds reasonable. > > Please note also the following v4 that came out of an IRC discussion: > http://repo.or.cz/w/qemu/afaerber.git/commitdiff/1262acf06308cf2bde46520d0238548cb73c79fe > If you need the JTAG_ID somewhere please let us know soon. No, it's not used anywhere (obviously otherwise it wouldn't be a comment) Cheers
Re: [Qemu-devel] [PATCH RFC v3 14/21] target-arm: Move the PXA270's iwMMXt reset to pxa270_reset()
On 3 February 2012 03:59, Andreas Färber wrote: > No other emulated CPU uses this at this time. But why does this code better fit in hw/ than target-arm? The iwMMXt registers are core registers after all. Also the defines let the board code request a cpu revision by name instead of using a magic number, so I think they're useful. Cheers
Re: [Qemu-devel] [PATCH 2/4] arm: switch real-time clocks to rtc_clock
On 17 February 2012 09:05, Paolo Bonzini wrote: > On 02/17/2012 08:09 AM, andrzej zaborowski wrote: >>> > This lets the user specify the desired semantics. By default, the RTC >>> > will follow adjustments from the host's NTP client. "-rtc clock=vm" will >>> > improve determinism with both icount and qtest. Finally, the previous >>> > behavior is available with "-rtc clock=rt". >> Generally this makes sense except for the omap1 "lpg" module where the >> clock state is not visible to the guest, only to the host. It >> emulates a blinking led. > > Ok, then I think it's better to switch that one to vm_clock (so that you > could use it as a deterministic debugging aid with -icount, for > example). What do you think? I was thinking about potential visual effects. But perhaps you were right with the first approach, i.e. debugging -> deterministic (which in this case would ideally also use the frequency derived from the system clock passed to omap_lpg_init), normal work -> realtime. I'll just push the original patch then, if you're ok with that. Cheers
Re: [Qemu-devel] [PATCH 2/4] Make -machine/-enable-kvm options merge into a single list
On 8 February 2012 06:41, Peter Maydell wrote: > Make the "machine" option list use list merging, so that multiple > -machine arguments (and the -enable-kvm argument) all merge together > into a single list. Drop the calls to qemu_opts_reset() which meant > that only the last -machine or -enable-kvm option had any effect. > > This fixes the bug where "-enable-kvm -machine foo" would ignore > the '-enable-kvm' option, and "-machine foo -enable-kvm" would > ignore the '-machine foo' option. Applied this patch and the first one as a bug fix, thank you. Cheers
Re: [Qemu-devel] [PATCH] target-arm/helper.c: tb_flush() on CPU reset
On 1 February 2012 18:23, Peter Maydell wrote: > Since target-arm has some CPUState fields for which we take the approach > of baking assumptions about them into translated code and then calling > tb_flush() when the fields change, we must also tb_flush on CPU reset, > because reset is a change of those fields. Thanks, applied this patch. Cheers
Re: [Qemu-devel] [PATCH] hw/arm: Remove redundant arguments from set_kernel_args*
On 29 January 2012 08:52, Stefan Weil wrote: > The parameters initrd_size and base are already included > in the info parameter, so there is no need to pass them > separately. Thanks, applied. Cheers
Re: [Qemu-devel] [PATCH v2] pxa2xx_lcd: SRAM is valid location for the framebuffer
On 24 January 2012 20:32, Vasily Khoruzhick wrote: > Signed-off-by: Vasily Khoruzhick Thanks, applied this patch. Cheers
Re: [Qemu-devel] [PATCH] target-arm/helper.c: Correct FPSID value for Cortex-A9
On 7 February 2012 18:56, Peter Maydell wrote: > The correct FPSID for the Cortex-A9 (according to the TRM) is > 0x41033090 for the r0p0 that we claim to model. Thanks, applied this patch. Cheers
Re: [Qemu-devel] [PATCH 2/4] arm: switch real-time clocks to rtc_clock
On 20 January 2012 13:06, Paolo Bonzini wrote: > This lets the user specify the desired semantics. By default, the RTC > will follow adjustments from the host's NTP client. "-rtc clock=vm" will > improve determinism with both icount and qtest. Finally, the previous > behavior is available with "-rtc clock=rt". Generally this makes sense except for the omap1 "lpg" module where the clock state is not visible to the guest, only to the host. It emulates a blinking led. Cheers
Re: [Qemu-devel] [PATCH] nseries: attach monitor powerdown request to menelaus
On 20 January 2012 12:10, Paolo Bonzini wrote: > I noticed some unused code in the twl92230, probably from before > qdev-ification. This patch makes the machine use the chip's pwrbtn > signal. Thanks, applied this patch. Cheers
Re: [Qemu-devel] [PATCH 3/3] configure: add '--disable-cocoa' switch
On 17 January 2012 12:06, Andreas Färber wrote: > Am 17.01.2012 00:46, schrieb Andrzej Zaborowski: >> On 14 January 2012 01:42, Andreas Färber wrote: >>> Am 08.12.2011 01:41, schrieb Andreas Färber: >>>> Am 10.11.2011 19:40, schrieb Pavel Borzenkov: >>>>> When SDL support is disabled, there is no way to build QEMU without >>>>> Cocoa support on MacOS X. This patch adds '--disable-cocoa' switch and >>>>> allows to build QEMU without both SDL and Cocoa frontends. >>>>> >>>>> Signed-off-by: Pavel Borzenkov >>>>> --- >>>>> configure | 7 ++- >>>>> 1 files changed, 6 insertions(+), 1 deletions(-) >>>>> >>>>> diff --git a/configure b/configure >>>>> index 401d9a6..4720bb2 100755 >>>>> --- a/configure >>>>> +++ b/configure >>>>> @@ -670,6 +670,8 @@ for opt do >>>>> ;; >>>>> --enable-profiler) profiler="yes" >>>>> ;; >>>>> + --disable-cocoa) cocoa="no" >>>>> + ;; >>>>> --enable-cocoa) >>>>> cocoa="yes" ; >>>>> sdl="no" ; >>>> >>>> Tested-by: Andreas Färber >>>> >>>>> @@ -980,7 +982,10 @@ echo " --disable-sdl disable SDL" >>>>> echo " --enable-sdl enable SDL" >>>>> echo " --disable-vnc disable VNC" >>>>> echo " --enable-vnc enable VNC" >>>>> -echo " --enable-cocoa enable COCOA (Mac OS X only)" >>>>> +if test "$darwin" = "yes" ; then >>>>> + echo " --disable-cocoa disable COCOA" >>>>> + echo " --enable-cocoa enable COCOA (default)" >>>>> +fi >>>>> echo " --audio-drv-list=LIST set audio drivers list:" >>>>> echo " Available drivers: >>>>> $audio_possible_drivers" >>>>> echo " --audio-card-list=LIST set list of emulated audio cards >>>>> [$audio_card_list]" >>>> >>>> I see no prior art of any conditional help output in configure. Anthony? >>>> Andrzej? >>> >>> Ping? Should we keep command line options a flat list with comments on >>> applicability or start introducing tests like above? >>> >>> Me, I'd prefer not doing this since the switch cases above don't check. >> >> Perhaps --diable-cocoa should be allowed on any platform. You're >> right we don't have such checks now, but then it's hard to see >> downsides of doing them, so I'm quite ambivalent. >> >> I still don't see the purpose of the following test in configure though: >> if test "$cocoa" = "no" ; then >> sdl=yes >> fi > > The reason is that SDL and Cocoa must not both be detected due to the > way it is handled in vl.c. Given that Cocoa is enabled by default, SDL > must not be detected in that case. If Cocoa is disabled, then detecting > SDL is fine of course. > > The alternative would be to check for SDL and, if present, disable > Cocoa. Still collides with Pavel's patch though - we need to sort out > how to merge them. > >> With it in place and no --disable-cocoa there's no way to compile SDL. > >> --enable-cocoa is also broken as fas as I can tell. > > I've been using it for historic reasons without noticeable problems. The problem I see is that the handler touches the sdl variable, which is also touched by --enable/disable-sdl. So the order of the options on the command line starts to matter. I think the options should be treated orthogonally, and then after parsing the command line the script should bail out if two incompatible options are enabled. Cheers
[Qemu-devel] [PATCH v2] Add tab-completion for device_add.
From: Andrzej Zaborowski
Signed-off-by: Andrzej Zaborowski
---
v2: pass only char *prop_name as qdev_driver_prop_foreach_func parameter,
Anthony noted Property was soon going away.
---
hw/qdev.c | 38 ++
hw/qdev.h |7 +++
monitor.c | 41 +
3 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index e59f345..d36be35 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1568,3 +1568,41 @@ void qdev_machine_init(void)
qdev_get_peripheral_anon();
qdev_get_peripheral();
}
+
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque)
+{
+DeviceInfo *info;
+int ret = 0;
+
+for (info = device_info_list; info != NULL; info = info->next) {
+ret |= (*func)(info, opaque);
+}
+
+return ret;
+}
+
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque)
+{
+DeviceInfo *info;
+Property *prop;
+int ret = 0;
+
+info = qdev_find_info(NULL, driver);
+if (!info) {
+return -1;
+}
+
+for (prop = info->props; prop && prop->name; prop++) {
+/*
+ * TODO Properties without a parser are just for dirty hacks.
+ * See comment in qdev_device_help.
+ */
+if (!prop->info->parse) {
+continue; /* no way to set it, don't show */
+}
+ret |= (*func)(prop->name, opaque);
+}
+
+return ret;
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index 2abb767..aa2455b 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -624,4 +624,11 @@ char *qdev_get_type(DeviceState *dev, Error **errp);
*/
void qdev_machine_init(void);
+/* Driver querying */
+typedef int (*qdev_driver_foreach_func)(DeviceInfo *info, void *opaque);
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque);
+typedef int (*qdev_driver_prop_foreach_func)(const char *prop, void *opaque);
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque);
+
#endif
diff --git a/monitor.c b/monitor.c
index 7334401..9a9beb5 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4069,6 +4069,28 @@ static void block_completion_it(void *opaque,
BlockDriverState *bs)
}
}
+static int driver_completion_it(DeviceInfo *info, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(info->name, input, strlen(input))) {
+readline_add_completion(cur_mon->rs, info->name);
+}
+
+return 0;
+}
+
+static int driver_prop_completion_it(const char *prop_name, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(prop_name, input, strlen(input))) {
+readline_add_completion(cur_mon->rs, prop_name);
+}
+
+return 0;
+}
+
/* NOTE: this parser is an approximate form of the real command parser */
static void parse_cmdline(const char *cmdline,
int *pnb_args, char **args)
@@ -4109,6 +4131,7 @@ static void monitor_find_completion(const char *cmdline)
const char *ptype, *str;
const mon_cmd_t *cmd;
const KeyDef *key;
+char *pkey;
parse_cmdline(cmdline, &nb_args, args);
#ifdef DEBUG_COMPLETION
@@ -4147,6 +4170,7 @@ static void monitor_find_completion(const char *cmdline)
goto cleanup;
}
+key_get_info(cmd->args_type, &pkey);
ptype = next_arg_type(cmd->args_type);
for(i = 0; i < nb_args - 2; i++) {
if (*ptype != '\0') {
@@ -4192,9 +4216,26 @@ static void monitor_find_completion(const char *cmdline)
}
}
break;
+case 'O':
+if (!strcmp(pkey, "device")) {
+char *sep = strrchr(str, ',');
+
+readline_set_completion_index(cur_mon->rs,
+strlen(sep ? sep + 1 : str));
+if (sep) {
+char *driver = g_strndup(str, strchr(str, ',') - str);
+qdev_driver_prop_foreach(driver_prop_completion_it,
+driver, (void *) (sep + 1));
+g_free(driver);
+} else {
+qdev_driver_foreach(driver_completion_it, (void *) str);
+}
+}
+break;
default:
break;
}
+g_free(pkey);
}
cleanup:
--
1.7.4.4
Re: [Qemu-devel] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
On 13 January 2012 21:52, Peter Maydell wrote: > From: Evgeny Voevodin > > The secondary CPU bootloader in arm_boot.c holds secondary CPUs in a > pen until the primary CPU releases them. Make boards specify the > address to be polled to determine whether to leave the pen (it was > previously hardcoded to 0x1030, which is a Versatile Express/ > Realview specific system register address). I applied this patch out of the series to reduce cross dependency, thanks. Cheers
Re: [Qemu-devel] [PATCH v7 01/10] hw/sysbus.h: Increase maximum number of device IRQs.
On 16 January 2012 07:48, Evgeny Voevodin wrote: > Samsung exynos4210 Interrupt Combiner needs 512 IRQ sources. Thanks, I applied this patch and the second one reviewed by Peter Maydell. I haven't look at the other patches but on quick glance the code formatting is still a little off in places. Cheers
Re: [Qemu-devel] [PATCH 1/2] pxa2xx_keypad: make single automatic scans work
On 12 January 2012 20:30, Vasily Khoruzhick wrote: > u-boot uses single automatic scans and polling in > pxa2xx_keypad driver, so clear KPC_AS bit immediately > and update keys state even if KPC_AS and KPC_ASACT are > cleared. Thanks, applied. Cheers
Re: [Qemu-devel] [PATCH 2/2] pxa2xx_lcd: fix palette parser
On 12 January 2012 20:30, Vasily Khoruzhick wrote: > Pallete entry size for 16bpp format is 2 bytes, not 4 > > Signed-off-by: Vasily Khoruzhick Thanks, applied, (with a style consistency change). Cheers
Re: [Qemu-devel] [PATCH 3/3] configure: add '--disable-cocoa' switch
On 14 January 2012 01:42, Andreas Färber wrote: > Am 08.12.2011 01:41, schrieb Andreas Färber: >> Am 10.11.2011 19:40, schrieb Pavel Borzenkov: >>> When SDL support is disabled, there is no way to build QEMU without >>> Cocoa support on MacOS X. This patch adds '--disable-cocoa' switch and >>> allows to build QEMU without both SDL and Cocoa frontends. >>> >>> Signed-off-by: Pavel Borzenkov >>> --- >>> configure | 7 ++- >>> 1 files changed, 6 insertions(+), 1 deletions(-) >>> >>> diff --git a/configure b/configure >>> index 401d9a6..4720bb2 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -670,6 +670,8 @@ for opt do >>> ;; >>> --enable-profiler) profiler="yes" >>> ;; >>> + --disable-cocoa) cocoa="no" >>> + ;; >>> --enable-cocoa) >>> cocoa="yes" ; >>> sdl="no" ; >> >> Tested-by: Andreas Färber >> >>> @@ -980,7 +982,10 @@ echo " --disable-sdl disable SDL" >>> echo " --enable-sdl enable SDL" >>> echo " --disable-vnc disable VNC" >>> echo " --enable-vnc enable VNC" >>> -echo " --enable-cocoa enable COCOA (Mac OS X only)" >>> +if test "$darwin" = "yes" ; then >>> + echo " --disable-cocoa disable COCOA" >>> + echo " --enable-cocoa enable COCOA (default)" >>> +fi >>> echo " --audio-drv-list=LIST set audio drivers list:" >>> echo " Available drivers: >>> $audio_possible_drivers" >>> echo " --audio-card-list=LIST set list of emulated audio cards >>> [$audio_card_list]" >> >> I see no prior art of any conditional help output in configure. Anthony? >> Andrzej? > > Ping? Should we keep command line options a flat list with comments on > applicability or start introducing tests like above? > > Me, I'd prefer not doing this since the switch cases above don't check. Perhaps --diable-cocoa should be allowed on any platform. You're right we don't have such checks now, but then it's hard to see downsides of doing them, so I'm quite ambivalent. I still don't see the purpose of the following test in configure though: if test "$cocoa" = "no" ; then sdl=yes fi With it in place and no --disable-cocoa there's no way to compile SDL. --enable-cocoa is also broken as fas as I can tell. Cheers
Re: [Qemu-devel] [Android-virt] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
On 16 January 2012 09:31, Peter Maydell wrote: > On 16 January 2012 01:56, Alexander Graf wrote: >> >> On 13.01.2012, at 21:52, Peter Maydell wrote: >> >>> From: Evgeny Voevodin >>> >>> The secondary CPU bootloader in arm_boot.c holds secondary CPUs in a >>> pen until the primary CPU releases them. Make boards specify the >>> address to be polled to determine whether to leave the pen (it was >>> previously hardcoded to 0x1030, which is a Versatile Express/ >>> Realview specific system register address). >> >> Is smp_boot implementing the same logic as hw/ppce500_spin.c? It >> looks like the normal u-boot way of waiting for a magic address >> to be written with boot info. What I don't understand is the WFI. >> How can you wait for an interrupt if the trigger is a memory >> write? Or are you actually getting IPIs? > > Basically this code is implementing the boot-rom half of > what is technically a platform-specific contract[*] between > the boot rom and the Linux kernel. The kernel end has to > (a) write the secondary CPU's entry point into the register > being polled and (b) send the CPU a softirq (an IPI, in > other words). The WFI basically allows h/w to avoid running > 3 cores at 100% when we're booting a uniprocessor OS. > So the arm_boot end has to (a) enable the CPU's interrupt > controller, (b) wait for interrupt, (c) get the entry point > and jump to it. > > [*] realview, vexpress, highbank and exynos4 all do something > that's sufficiently similar that we can handle them all by > parameterising the secondary boot code a bit. omap is kinda > different but then we don't support -kernel with omap anyway. In the last sentence you mean the SMP case, right? Cheers
Re: [Qemu-devel] [PATCH] (dont commit) virtio-gl-fixes for build on F17
On 12 January 2012 11:42, Alon Levy wrote: > Don't mind at all! But for some reason this email and the other one I > send before it to you and to the qemu-devel list didn't reach the list. > If you saw this email is it too much to assume you saw the other one as > well? Thanks. http://lists.nongnu.org/archive/html/qemu-devel/2012-01/msg01441.html shows the three of your emails that I got too. Cheers
Re: [Qemu-devel] [Qemu-trivial] [PATCH] Add 'fall through' comments to case statements without break
On 10 January 2012 09:35, Stefan Hajnoczi wrote:
> On Mon, Jan 09, 2012 at 06:29:51PM +0100, Stefan Weil wrote:
>> These comments are used by static code analysis tools and in code reviews
>> to avoid false warnings because of missing break statements.
>>
>> The case statements handled here were reported by coverity.
>>
>> Signed-off-by: Stefan Weil
>> ---
>> hw/pcnet.c | 1 +
>> json-lexer.c | 1 +
>> qemu-option.c | 4
>> 3 files changed, 6 insertions(+), 0 deletions(-)
>
> This reminds me of another questionable fall-through:
>
> bt-host.c:bt_host_read():
>
> while (s->len --)
> switch (*pkt ++) {
> ...
> case HCI_SCODATA_PKT:
> if (s->len < 3)
> goto bad_pkt;
>
> pktlen = MIN(pkt[2] + 3, s->len);
> s->len -= pktlen;
> pkt += pktlen;
> <--- fall-through or not?
> default:
> bad_pkt:
> fprintf(stderr, "qemu: bad HCI packet type %02x\n", pkt[-1]);
> }
>
> It seems the code will skip HCI_SCODATA_PKT and report a warning (although
> type
> pkt[-1] will be incorrect). Any thoughts?
Yes, definitely there's a break missing. Bluetooth SCO links are like
USB Isochronous, so not really tested because they're only used by
streaming devices.
Cheers
Re: [Qemu-devel] [PATCH] (dont commit) virtio-gl-fixes for build on F17
On 10 January 2012 09:44, Alon Levy wrote:
> All but the last are assigned but unused variables,
> and an always true comparison, but the last looks like a logic
> error - decode not returning the actual return value for the last call
> in the buffer (vmgl-exec.c).
> ---
> gl/gloffscreen-xcomposite.c | 4 +---
> gl/vmgl-exec.c | 10 +-
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/gl/gloffscreen-xcomposite.c b/gl/gloffscreen-xcomposite.c
> index 5c63ed4..00a419b 100644
> --- a/gl/gloffscreen-xcomposite.c
> +++ b/gl/gloffscreen-xcomposite.c
> @@ -186,8 +186,6 @@ static void glo_test_readback_methods(void)
> /* Initialise gloffscreen */
> int glo_init(void)
> {
> - XErrorHandler old_handler;
> -
> if (glo_inited) {
> return 0;
> }
> @@ -204,7 +202,7 @@ int glo_init(void)
> /* Safe because we are single threaded. Otherwise we cause recursion
> * on the next call. Set the X error handler. */
> glo_inited = 1;
> - old_handler = XSetErrorHandler(x_errhandler);
> + (void)XSetErrorHandler(x_errhandler);
> glo_test_readback_methods();
>
> return 0;
> diff --git a/gl/vmgl-exec.c b/gl/vmgl-exec.c
> index e538ff4..3cf5eba 100644
> --- a/gl/vmgl-exec.c
> +++ b/gl/vmgl-exec.c
> @@ -668,7 +668,7 @@ static int glXGetConfigFunc(uint32_t visualid, uint32_t
> attrib, uint32_t *value)
> {
> const VmglGLXFBConfig *config = &fbconfigs[0];
>
> - if (visualid >= 0 && visualid < ARRAY_SIZE(fbconfigs)) {
> + if (visualid < ARRAY_SIZE(fbconfigs)) {
> config = &fbconfigs[visualid];
> } else {
> DEBUGF("Unknown visual ID %d\n", visualid);
> @@ -3072,11 +3072,12 @@ static inline int do_decode_call(ProcessStruct *p,
> const uint8_t *args_in,
> int args_len, uint8_t *r_buffer)
> {
> Signature *signature;
> - int i, ret;
> - const uint8_t *arg_ptr, *tmp;
> + int i;
> + const uint8_t *arg_ptr;
> static arg_t args[50];
> int func_number;
> ProcessState *process = DO_UPCAST(ProcessState, p, p);
> + int ret = 1;
>
> if (!args_len) {
> return 0;
> @@ -3099,7 +3100,6 @@ static inline int do_decode_call(ProcessStruct *p,
> const uint8_t *args_in,
> #endif
>
> signature = (Signature *) tab_opengl_calls[func_number];
> - tmp = arg_ptr;
>
> for (i = 0; i < signature->nb_args; i++) {
> int args_size = *(const uint32_t *) arg_ptr;
> @@ -3220,7 +3220,7 @@ static inline int do_decode_call(ProcessStruct *p,
> const uint8_t *args_in,
> }
> #endif
>
> - return 1;
> + return ret;
Thanks for the compile test. I think I was meaning to check ret after
every do_function_call call and return immediately if 0. I'll fix it
in a future iteration and add your other fixes if you don't mind.
Cheers
Re: [Qemu-devel] [PATCH 0/6] OpenGL passthrough support once again
Hi, On 10 January 2012 09:29, Alon Levy wrote: > On Mon, Jan 09, 2012 at 08:57:50AM +0100, Andrzej Zaborowski wrote: >> This is the host part of an OpenGL passthrough framework to make apps >> run faster. It has initially lived on nongnu.org as a separate project >> by Even Rouault, later was picked up by me to use in the Poky >> meta-distribution and later was picked up by various platform SDKs >> for application developers. It's still evolving but it would be good >> to reduce maintaining cost and parallel evolution in different trees >> by having it upstream. >> >> In 2010 Ian Molton started a discussion about it [1] and got some >> feedback which I tried to address in these patches. The code has gone >> through major refactoring but I may have missed some things not having >> the distance when looking at the code. Suggestions welcome. >> >> Some discussion points: >> >> One of Anthony's comments in the old thread was that this could be a >> temporary solution but where we really should be heading is towards a >> paravirtual VGA (like the vmware-svga or the Spice one) that will be >> OpenGL independent and secure. While having such a thing would be >> good, it's less likely to achieve near 1:1 performace and performance >> is the whole point of the passhtrough. Also it's apparently quite >> difficult to do, but seems that VMWare have managed it, so it's >> possible. I'd personally prefer to put effort in the emulation of >> one of the real moden GPUs instead. > > I think you are right to push a passthrough implementation into qemu, > for one it gives something working now. Not sure the performance will be > any different then a paravirtual approach (just talking about server > side rendering here), since it's basically doing the same thing, but it > would certainly be simpler. You're right, in the end there's no specific reason the paravirtual approach should be slower, I guess it might work just as well. > > Do you have further thoughts about real GPU emulation? would you target > an ATI (AMD) GPU, since they released specs? I haven't looked at the specs, but it's worth to choose the simplest one since these tend to be very complicated devices. intellinuxgraphics.org has some documentation about Intel GPUs but if I remember correctly things like the instruction set were not in those specs. > >> >> I think instead of going towards a paravirtual vga, this should be >> going in the direction of a generic, almost-no-overhead virtio-based >> RPC mechanism. From what I read qmp provides a json based RPC >> mechanism, this is totally not what we want here. What I'd want is >> a very simple binary RPC where, optimally, big buffers can be passed >> as parameters to remote function calls with no single memcpy. This >> could be done by having a guest kernel driver allocate continuous >> physical memory chunks on requests and pass physical addresses to host. > > qmp is not suitable for this, sure. Something like the qxl/svga device > would work fine - you have a BAR for the continuous allocations. You > could also do a device like that based on virtio queues. (Just a note I forgot to add, http://meego.gitorious.org/meego-developer-tools/meego-emulator-qemugl-x86/blobs/qemugl-on-0.14/hw/virtio-gl.c is a custom virtio based transport for Qemugl but it's not included here because it requires a bigger effort from the user to start using, and the merging would have to be coordinated with other projects) > ... >> 1. http://thread.gmane.org/gmane.linux.kernel/1045340 >> >> (Actual authors of each file are listed in the file headers, not >> in the Signed-off-by) > > You can change the author of the patches with git commit --amend --author __, > seems a little nicer. I meant the authors of the source files and not patches. I'm not in contact with any of them. > > Running scripts/check-patch.pl on these I get multiple errors, but I > guess you are waiting for some input before fixing those.. It didn't occur to me, but there are some good catches in the output so yes, I'll correct before next iteration. There's a lot of false positives resulting from tricky preprocessor use and patch 2 contains headers from an external project (Mesa). Cheers
Re: [Qemu-devel] [PATCH] wm8750: Fix calculation of number of array elements
On 9 January 2012 19:32, Stefan Weil wrote: > Coverity says that the division by sizeof(*s->rate) might be wrong. > I think that coverity is right. Thanks, applied. Cheers
Re: [Qemu-devel] [PATCH] tcg/arm: Use r6 as TCG_AREG0 to avoid clash with Thumb framepointer
On 9 January 2012 12:24, Peter Maydell wrote: > Ping? > > (either I forgot to cc you, Andrzej, or the mailing list manager helpfully > dropped you off the cc list again. Sorry.) Thank you, now applied. I've been in CC but my patch queue was moving slow, sorry. Cheers
Re: [Qemu-devel] [PATCH v4 1/2] hw/integratorcp: Fix sense of REMAP bit
On 6 January 2012 19:58, Peter Maydell wrote: > Fix the sense of the REMAP bit: 0 should mean "map flash", > 1 should mean "map RAM". Thanks, applied both patches. Cheers
Re: [Qemu-devel] [PATCH] omap_dss: correct chip[1] index in RFBI_READ/RFBI_STATUS
On 7 January 2012 12:59, Stefan Hajnoczi wrote: > The RFBI_READ/RFBI_STATUS code incorrectly uses chip[0] when it should > be using chip[1]. Andrzej Zaborowski confirmed this > bug since I don't know this code well. > > Reported-by: Dr David Alan Gilbert > Signed-off-by: Stefan Hajnoczi Reviewed-by: Andrzej Zaborowski Cheers
Re: [Qemu-devel] [PATCH] elf: Improve symbol lookup (optimize, fix for bsd-user)
On 5 January 2012 15:39, Stefan Weil wrote: > Coverity complained about local variable key which was only partially > initiated. Only key.st_value was set. As this was also the only part > of key which was used in function symfind, the code could be optimized > by directly passing a pointer to orig_addr. > > In bsd-user/elfload.c, fix ec822001a2f26eef8701194714f6482b6d852de2 > was missing. This was a simple replacement of > by >= in symfind, so > I fixed it here without creating an additional patch. Thanks, applied. Cheers
[Qemu-devel] [PATCH 6/6] gl: -enable-gl switch to enable the GL virtio port.
Signed-off-by: Andrzej Zaborowski
---
qemu-options.hx | 24
vl.c| 36
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 7903e5c..f00bb6d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1093,6 +1093,30 @@ like Tight.
@end table
ETEXI
+DEF("enable-gl", 0, QEMU_OPTION_enable_gl, \
+"-enable-gl enable OpenGL passthrough support\n", QEMU_ARCH_ALL)
+STEXI
+@item -enable-gl
+@findex -enable-gl
+Enable OpenGL passthrough support in QEMU. Requires corresponding client
+software in the guest OS. Requires hardware graphics acceleration
+on host system. Only virtio-capable target machines supported. Does
+not support vmsave/vmload or migration.
+
+@strong{NOTE}: this feature has not been security reviewed and assumes that
+the emulator runs a trusted guest system. Enabling this option may allow
+rogue software in the emulator to crash or control QEMU. Do not use this
+option if unsure.
+
+This option allows the emulated system to take advantage of hardware-
+accelerated OpenGL support of the host machine to speed up applications
+that make heavy use of OpenGL graphics (3D or otherwise) - useful during
+the development of such applications. For Linux guests running X.org, the
+client software can be installed from
+@url{http://meego.gitorious.org/meego-developer-tools/meego-emulator-libgl-x86}
+or distribution packages if available.
+ETEXI
+
STEXI
@end table
ETEXI
diff --git a/vl.c b/vl.c
index ba55b35..6a4fa7b 100644
--- a/vl.c
+++ b/vl.c
@@ -230,6 +230,7 @@ int ctrl_grab = 0;
unsigned int nb_prom_envs = 0;
const char *prom_envs[MAX_PROM_ENVS];
int boot_menu;
+int enable_gl = 0;
uint8_t *boot_splash_filedata;
int boot_splash_filedata_size;
uint8_t qemu_extra_params_fw[2];
@@ -320,6 +321,21 @@ static int default_driver_check(QemuOpts *opts, void
*opaque)
return 0;
}
+typedef struct {
+const char *device_name;
+int found;
+} device_opt_search_t;
+
+static int find_device_opt(QemuOpts *opts, void *opaque)
+{
+device_opt_search_t *devp = (device_opt_search_t *) opaque;
+
+devp->found = devp->found ||
+!strcmp(qemu_opt_get(opts, "driver"), devp->device_name);
+
+return 0;
+}
+
/***/
/* QEMU state */
@@ -2839,6 +2855,11 @@ int main(int argc, char **argv, char **envp)
machine = machine_parse(optarg);
}
break;
+#ifdef CONFIG_GL
+case QEMU_OPTION_enable_gl:
+enable_gl = 1;
+break;
+#endif
case QEMU_OPTION_usb:
usb_enabled = 1;
break;
@@ -3076,6 +3097,21 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+if (enable_gl) {
+QemuOptsList *device = qemu_find_opts("device");
+QemuOpts *bus_opts, *dev_opts;
+device_opt_search_t devp = { "virtio-serial", 0 };
+
+qemu_opts_foreach(device, find_device_opt, &devp, 0);
+if (devp.found == 0) {
+bus_opts = qemu_opts_create(device, NULL, 0);
+qemu_opt_set(bus_opts, "driver", "virtio-serial");
+}
+
+dev_opts = qemu_opts_create(device, NULL, 0);
+qemu_opt_set(dev_opts, "driver", "virtio-gl-port");
+}
+
/* If no data_dir is specified then try to find it relative to the
executable path. */
if (!data_dir) {
--
1.7.4.4
[Qemu-devel] [PATCH 5/6] gl: virtio-serial port driver for OpenGL passthrough.
This is a relatively simple to use OpenGL passthrough transport
because it doesn't need any guest kernel changes, but it's not
blazing fast. Still faster than software rendering.
The main problems are:
* transfers are split in very small chunks by virtio queues, some
OpenGL calls (think textures etc.) will take thousands of context
switches, vmenters/vmexits, sysenters/sysexits and buffer copying.
This should really be a single big zerocopy transfer.
* Linux virtio-serial allows only one process to have the port opened,
so applications on the guest have to fight over the port access
and open/close the device at every command buffer.
* host cannot know for sure when a guest process has died unexpectedly.
Signed-off-by: Andrzej Zaborowski
---
Makefile.target |3 +-
hw/virtio-gl-port.c | 241 +++
2 files changed, 243 insertions(+), 1 deletions(-)
create mode 100644 hw/virtio-gl-port.c
diff --git a/Makefile.target b/Makefile.target
index 21e9927..3d52c71 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -190,7 +190,8 @@ obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o
balloon.o ioport.o
# virtio has to be here due to weird dependency between PCI and virtio-net.
# need to fix this properly
obj-$(CONFIG_NO_PCI) += pci-stub.o
-obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o
virtio-serial-bus.o
+obj-virtio-$(CONFIG_GL) += virtio-gl-port.o
+obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o
virtio-serial-bus.o $(obj-virtio-y)
obj-y += vhost_net.o
obj-$(CONFIG_VHOST_NET) += vhost.o
obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/virtio-9p-device.o
diff --git a/hw/virtio-gl-port.c b/hw/virtio-gl-port.c
new file mode 100644
index 000..c75f7aa
--- /dev/null
+++ b/hw/virtio-gl-port.c
@@ -0,0 +1,222 @@
+/*
+ * GL passthrough virtio-serial-based transport
+ *
+ * Copyright (c) 2011 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) any later version of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "hw.h"
+#include "qemu-error.h"
+#include "virtio-serial.h"
+
+#include "gl/vmgl.h"
+
+#define CMD_HEADER_SIZE 12
+
+static uint8_t *cmd_buffer = NULL;
+static size_t cmd_buffer_bytes = 0;
+static size_t cmd_buffer_size = 0;
+static const uint8_t *ret_buffer = NULL;
+static size_t ret_buffer_bytes = 0;
+
+static size_t virtio_gl_get_cmd_size(const uint8_t *buf)
+{
+#ifdef TARGET_WORDS_BIGENDIAN
+return be32_to_cpup((const uint32_t *) buf);
+#else
+return le32_to_cpup((const uint32_t *) buf);
+#endif
+}
+
+static size_t virtio_gl_get_buffer_size(const uint8_t *buf)
+{
+return virtio_gl_get_cmd_size(buf + 4);
+}
+
+static void virtio_gl_guest_ready(VirtIOSerialPort *port)
+{
+ssize_t ret;
+
+if (!ret_buffer_bytes) {
+return;
+}
+
+ret = virtio_serial_write(port, ret_buffer, ret_buffer_bytes);
+if (ret < 0) {
+error_report("%s: virtio_serial_write: error %i\n", __func__,
+(int) -ret);
+return;
+}
+ret_buffer += ret;
+ret_buffer_bytes -= ret;
+}
+
+static void virtio_gl_handle_cmd(VirtIOSerialPort *port, const uint8_t *cmd)
+{
+int pid = le32_to_cpup((const uint32_t *) cmd);
+int in_size = virtio_gl_get_cmd_size(cmd + 4);
+int ret;
+ProcessStruct *process = vmgl_get_process(pid);
+
+ret_buffer_bytes = virtio_gl_get_cmd_size(cmd + 8);
+if (cmd_buffer_size < ret_buffer_bytes) {
+cmd_buffer_size = ret_buffer_bytes;
+cmd_buffer = g_realloc(cmd_buffer, cmd_buffer_size);
+}
+ret_buffer = cmd_buffer;
+
+ret = vmgl_decode_call(process, cmd + CMD_HEADER_SIZE,
+in_size - CMD_HEADER_SIZE, cmd_buffer + 4);
+if (!ret) {
+vmgl_disconnect(process);
+return;
+}
+
+#ifdef TARGET_WORDS_BIGENDIAN
+cpu_to_be32wu((uint32_t *) ret_buffer, ret);
+#else
+cpu_to_le32wu((uint32_t *) ret_buffer, ret);
+#endif
+/* FIXME: passing the buffer to decode_call_int and calling
+ * virtio_serial_write precludes zero-copy, figure out something
+ * better. */
+virtio_gl_guest_ready(port);
+}
+
+static void virtio_gl_guest_close(VirtIOSerialPort *port)
+{
+cmd_buffer_bytes = 0;
+ret_buffer_bytes = 0;
+}
+
+/* Callback function that's called when the gues
[Qemu-devel] [PATCH 4/6] virtio-serial: Call .guest_ready when new space is available in the queue.
Without that it's impossible to write a virtio-serial port driver that
sends any buffers bigger than a couple kilobytes, other than by
polling to check when space in the queue becomes available.
Signed-off-by: Andrzej Zaborowski
---
hw/virtio-serial-bus.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 3a9004a..72bbe78 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -495,6 +495,14 @@ static void handle_output(VirtIODevice *vdev, VirtQueue
*vq)
static void handle_input(VirtIODevice *vdev, VirtQueue *vq)
{
+VirtIOSerial *vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+VirtIOSerialPort *port = find_port_by_vq(vser, vq);
+VirtIOSerialPortInfo *info =
+port ? DO_UPCAST(VirtIOSerialPortInfo, qdev, port->dev.info) : NULL;
+
+if (info && info->guest_ready) {
+info->guest_ready(port);
+}
}
static uint32_t get_features(VirtIODevice *vdev, uint32_t features)
--
1.7.4.4
[Qemu-devel] [PATCH 0/6] OpenGL passthrough support once again
This is the host part of an OpenGL passthrough framework to make apps run faster. It has initially lived on nongnu.org as a separate project by Even Rouault, later was picked up by me to use in the Poky meta-distribution and later was picked up by various platform SDKs for application developers. It's still evolving but it would be good to reduce maintaining cost and parallel evolution in different trees by having it upstream. In 2010 Ian Molton started a discussion about it [1] and got some feedback which I tried to address in these patches. The code has gone through major refactoring but I may have missed some things not having the distance when looking at the code. Suggestions welcome. Some discussion points: One of Anthony's comments in the old thread was that this could be a temporary solution but where we really should be heading is towards a paravirtual VGA (like the vmware-svga or the Spice one) that will be OpenGL independent and secure. While having such a thing would be good, it's less likely to achieve near 1:1 performace and performance is the whole point of the passhtrough. Also it's apparently quite difficult to do, but seems that VMWare have managed it, so it's possible. I'd personally prefer to put effort in the emulation of one of the real moden GPUs instead. I think instead of going towards a paravirtual vga, this should be going in the direction of a generic, almost-no-overhead virtio-based RPC mechanism. From what I read qmp provides a json based RPC mechanism, this is totally not what we want here. What I'd want is a very simple binary RPC where, optimally, big buffers can be passed as parameters to remote function calls with no single memcpy. This could be done by having a guest kernel driver allocate continuous physical memory chunks on requests and pass physical addresses to host. In any case, Anthony suggested that instead of using a separate virtio protocol we use virtio-serial transport as a first stab and this is what I do in this series. It has a couple of disadvantages, but it works. The "serial-transport" branch of https://meego.gitorious.org/meego-developer-tools/meego-emulator-libgl-x86 should be used on the guest. As has been mentioned in the old thread, the passthrough code does not attempt to be secure at this point, the guest software needs to be fully trusted. This is similar to the problems Web GL is supposedly having with security, but I find that the OpenGL API actually lends itself to buffer size checks etc., so it can be done and I'm probably going to work on it. Hopefully without compromising performance. It has been tested with some Nvidia, Intel and ATI cards on the host at different points in time, and usually this didn't make much difference. I've done my testing with MacOS and Linux as hosts, Windows is also supported but I haven't really had a chance to ever test it, hopefully my refactoring has not broken it too badly. In the Meego SDK this same code was being used to accelerate GL ES applications by using libdgles2 on the guest to translate GL ES into OpenGL. I imagine the same thing could be done for Direct X support using some Wine libraries. 1. http://thread.gmane.org/gmane.linux.kernel/1045340 (Actual authors of each file are listed in the file headers, not in the Signed-off-by) Andrzej Zaborowski (6): gl: Add an OpenGL offscreen rendering API and backends. gl: Add mesa OpenGL headers. gl: OpenGL passthrough implementation. virtio-serial: Call .guest_ready when new space is available in the queue. gl: virtio-serial port driver for OpenGL passthrough. gl: -enable-gl run time switch to enable the GL virtio port. Makefile.target | 17 +- configure | 42 + gl/beginend_funcs.sh| 41 + gl/gloffscreen-common.c | 579 gl/gloffscreen-wgl.c| 832 + gl/gloffscreen-xcomposite.c | 518 +++ gl/gloffscreen.h| 138 + gl/mesa_gl.h| 2251 + gl/mesa_glext.h | 7279 +++ gl/mesa_glu.h | 354 +++ gl/mesa_mipmap.c| 826 + gl/mesa_mipmap.h| 27 + gl/parse-gl-h.c | 1480 + gl/range_alloc.h| 195 ++ gl/vmgl-exec.c | 3300 gl/vmgl-func-perso.h| 120 + gl/vmgl-func.h | 611 gl/vmgl-process.h | 32 + gl/vmgl.h | 34 + hw/virtio-gl-port.c | 241 ++ hw/virtio-serial-bus.c |8 + qemu-options.hx | 24 + vl.c| 36 + 23 files changed, 18984 insertions(+), 1 deletions(-) create mode 100644 gl/beginend_funcs.sh create mode 100644 gl/gloffscreen-common.c create mode 100644 gl/gloffscreen-wgl.c create mode 100644 gl/gloffscreen-xcomposite.c create mode 100644 gl/gloffscreen.h create mode 100
[Qemu-devel] [PATCH] Add tab-completion for device_add.
Signed-off-by: Andrzej Zaborowski
---
There are other ways to do this, but adding an API for querying
available qdev drivers was the one that made most sense to me.
---
hw/qdev.c | 38 ++
hw/qdev.h |7 +++
monitor.c | 41 +
3 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index d0cf66d..ba97312 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1535,3 +1535,41 @@ void qdev_machine_init(void)
qdev_get_peripheral_anon();
qdev_get_peripheral();
}
+
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque)
+{
+DeviceInfo *info;
+int ret = 0;
+
+for (info = device_info_list; info != NULL; info = info->next) {
+ret |= (*func)(info, opaque);
+}
+
+return ret;
+}
+
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque)
+{
+DeviceInfo *info;
+Property *prop;
+int ret = 0;
+
+info = qdev_find_info(NULL, driver);
+if (!info) {
+return -1;
+}
+
+for (prop = info->props; prop && prop->name; prop++) {
+/*
+ * TODO Properties without a parser are just for dirty hacks.
+ * See comment in qdev_device_help.
+ */
+if (!prop->info->parse) {
+continue; /* no way to set it, don't show */
+}
+ret |= (*func)(prop, opaque);
+}
+
+return ret;
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index 2abb767..b72a31a 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -624,4 +624,11 @@ char *qdev_get_type(DeviceState *dev, Error **errp);
*/
void qdev_machine_init(void);
+/* Driver querying */
+typedef int (*qdev_driver_foreach_func)(DeviceInfo *info, void *opaque);
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque);
+typedef int (*qdev_driver_prop_foreach_func)(Property *info, void *opaque);
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque);
+
#endif
diff --git a/monitor.c b/monitor.c
index 7334401..3eab307 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4069,6 +4069,28 @@ static void block_completion_it(void *opaque,
BlockDriverState *bs)
}
}
+static int driver_completion_it(DeviceInfo *info, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(info->name, input, strlen(input))) {
+readline_add_completion(cur_mon->rs, info->name);
+}
+
+return 0;
+}
+
+static int driver_prop_completion_it(Property *prop, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(prop->name, input, strlen(input))) {
+readline_add_completion(cur_mon->rs, prop->name);
+}
+
+return 0;
+}
+
/* NOTE: this parser is an approximate form of the real command parser */
static void parse_cmdline(const char *cmdline,
int *pnb_args, char **args)
@@ -4109,6 +4131,7 @@ static void monitor_find_completion(const char *cmdline)
const char *ptype, *str;
const mon_cmd_t *cmd;
const KeyDef *key;
+char *pkey;
parse_cmdline(cmdline, &nb_args, args);
#ifdef DEBUG_COMPLETION
@@ -4147,6 +4170,7 @@ static void monitor_find_completion(const char *cmdline)
goto cleanup;
}
+key_get_info(cmd->args_type, &pkey);
ptype = next_arg_type(cmd->args_type);
for(i = 0; i < nb_args - 2; i++) {
if (*ptype != '\0') {
@@ -4192,9 +4216,26 @@ static void monitor_find_completion(const char *cmdline)
}
}
break;
+case 'O':
+if (!strcmp(pkey, "device")) {
+char *sep = strrchr(str, ',');
+
+readline_set_completion_index(cur_mon->rs,
+strlen(sep ? sep + 1 : str));
+if (sep) {
+char *driver = g_strndup(str, strchr(str, ',') - str);
+qdev_driver_prop_foreach(driver_prop_completion_it,
+driver, (void *) (sep + 1));
+g_free(driver);
+} else {
+qdev_driver_foreach(driver_completion_it, (void *) str);
+}
+}
+break;
default:
break;
}
+g_free(pkey);
}
cleanup:
--
1.7.4.4
Re: [Qemu-devel] [PATCH] Add tab-completion for device_add.
On 8 January 2012 16:14, Andrzej Zaborowski wrote: > Signed-off-by: Andrzej Zaborowski > --- > There are other ways to do this, but adding an API for querying > available qdev drivers was the one that made most sense to me. > --- > hw/qdev.c | 38 ++ > hw/qdev.h | 7 +++ > monitor.c | 41 + > 3 files changed, 86 insertions(+), 0 deletions(-) Sorry, sent the old version of the patch, please look at the one I'll send in a minute instead. Cheers
[Qemu-devel] [PATCH] Add tab-completion for device_add.
Signed-off-by: Andrzej Zaborowski
---
There are other ways to do this, but adding an API for querying
available qdev drivers was the one that made most sense to me.
---
hw/qdev.c | 38 ++
hw/qdev.h |7 +++
monitor.c | 41 +
3 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index d0cf66d..ba97312 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1535,3 +1535,41 @@ void qdev_machine_init(void)
qdev_get_peripheral_anon();
qdev_get_peripheral();
}
+
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque)
+{
+DeviceInfo *info;
+int ret = 0;
+
+for (info = device_info_list; info != NULL; info = info->next) {
+ret |= (*func)(info, opaque);
+}
+
+return ret;
+}
+
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque)
+{
+DeviceInfo *info;
+Property *prop;
+int ret = 0;
+
+info = qdev_find_info(NULL, driver);
+if (!info) {
+return -1;
+}
+
+for (prop = info->props; prop && prop->name; prop++) {
+/*
+ * TODO Properties without a parser are just for dirty hacks.
+ * See comment in qdev_device_help.
+ */
+if (!prop->info->parse) {
+continue; /* no way to set it, don't show */
+}
+ret |= (*func)(prop, opaque);
+}
+
+return ret;
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index 2abb767..b72a31a 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -624,4 +624,11 @@ char *qdev_get_type(DeviceState *dev, Error **errp);
*/
void qdev_machine_init(void);
+/* Driver querying */
+typedef int (*qdev_driver_foreach_func)(DeviceInfo *info, void *opaque);
+int qdev_driver_foreach(qdev_driver_foreach_func func, void *opaque);
+typedef int (*qdev_driver_prop_foreach_func)(Property *info, void *opaque);
+int qdev_driver_prop_foreach(qdev_driver_prop_foreach_func func,
+const char *driver, void *opaque);
+
#endif
diff --git a/monitor.c b/monitor.c
index 7334401..3eab307 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4069,6 +4069,28 @@ static void block_completion_it(void *opaque,
BlockDriverState *bs)
}
}
+static int driver_completion_it(DeviceInfo *info, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(info->name, input, strlen(input))) {
+readline_add_completion(cur_mon->rs, info->name);
+}
+
+return 0;
+}
+
+static int driver_prop_completion_it(Property *prop, void *opaque)
+{
+const char *input = opaque;
+
+if (input[0] == '\0' || !strncmp(prop->name, input, strlen(input))) {
+readline_add_completion(cur_mon->rs, prop->name);
+}
+
+return 0;
+}
+
/* NOTE: this parser is an approximate form of the real command parser */
static void parse_cmdline(const char *cmdline,
int *pnb_args, char **args)
@@ -4109,6 +4131,7 @@ static void monitor_find_completion(const char *cmdline)
const char *ptype, *str;
const mon_cmd_t *cmd;
const KeyDef *key;
+char *pkey;
parse_cmdline(cmdline, &nb_args, args);
#ifdef DEBUG_COMPLETION
@@ -4147,6 +4170,7 @@ static void monitor_find_completion(const char *cmdline)
goto cleanup;
}
+key_get_info(cmd->args_type, &pkey);
ptype = next_arg_type(cmd->args_type);
for(i = 0; i < nb_args - 2; i++) {
if (*ptype != '\0') {
@@ -4192,9 +4216,26 @@ static void monitor_find_completion(const char *cmdline)
}
}
break;
+case 'O':
+if (!strcmp(pkey, "device")) {
+char *sep = strrchr(str, ',');
+
+readline_set_completion_index(cur_mon->rs,
+strlen(sep ? sep + 1 : str));
+if (sep) {
+char *driver = qemu_strndup(str, strchr(str, ',') - str);
+qdev_driver_prop_foreach(driver_prop_completion_it,
+driver, (void *) (sep + 1));
+qemu_free(driver);
+} else {
+qdev_driver_foreach(driver_completion_it, (void *) str);
+}
+}
+break;
default:
break;
}
+qemu_free(pkey);
}
cleanup:
--
1.7.4.4
[Qemu-devel] [PATCH] Add a comment to autogenerated .texi files noting that fact.
Signed-off-by: Andrzej Zaborowski
---
scripts/hxtool |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/scripts/hxtool b/scripts/hxtool
index 995bb7f..a985f5c 100644
--- a/scripts/hxtool
+++ b/scripts/hxtool
@@ -20,6 +20,8 @@ hxtotexi()
{
flag=0
line=1
+echo "@c This file is autogenerated from a .hx file by $0, \
+changes will be lost."
while read -r str; do
case "$str" in
HXCOMM*)
--
1.7.4.4
Re: [Qemu-devel] Incorrect hw/omap_dss.c:chip[] index for RFBI_READ and RFBI_STATUS?
Hi, On 6 January 2012 17:55, Stefan Hajnoczi wrote: > Is the following code correct in hw/omap_dss.c: > > case 0x58: /* RFBI_READ */ > if ((s->rfbi.control & (1 << 2)) && s->rfbi.chip[0]) > s->rfbi.rxbuf = s->rfbi.chip[0]->read(s->rfbi.chip[0]->opaque, 1); > else if ((s->rfbi.control & (1 << 3)) && s->rfbi.chip[1]) > s->rfbi.rxbuf = s->rfbi.chip[0]->read(s->rfbi.chip[0]->opaque, 1); > if (!-- s->rfbi.pixels) > omap_rfbi_transfer_stop(s); > break; > > case 0x5c: /* RFBI_STATUS */ > if ((s->rfbi.control & (1 << 2)) && s->rfbi.chip[0]) > s->rfbi.rxbuf = s->rfbi.chip[0]->read(s->rfbi.chip[0]->opaque, 0); > else if ((s->rfbi.control & (1 << 3)) && s->rfbi.chip[1]) > s->rfbi.rxbuf = s->rfbi.chip[0]->read(s->rfbi.chip[0]->opaque, 0); > if (!-- s->rfbi.pixels) > omap_rfbi_transfer_stop(s); > break; > > It checks chip[1] in the "else if" statement. But notice it actually > operates on chip[0]. > > Is this intentional or should it use chip[1]? Right, it should use chip[1], it's a bug. If a machine only had a rfbi chip attached at 1, it might even cause a segfault, but the N900 uses only rfbi 0. Cheers
Re: [Qemu-devel] [PATCH 00/10] hw/sd.c: Fix various status related bugs
Hi Peter, On 18 December 2011 21:37, Peter Maydell wrote: > This patchset fixes a number of bugs in our SD card emulation, mostly > in the status bit handling. In particular, it fixes the issues raised > in https://bugs.launchpad.net/qemu/+bug/597641 . The others are things > I noticed while I was poking around in the code. > > Patches 01-04, 07 are pretty straightforward. 05, 06 are refactoring for > the benefit of later patches. 08 and 09 are more interesting. 10 makes > sense to me although the spec is rather vague on the point. > Thanks, I pushed the series. Some good catches here. Also thanks to bug reporter. > Peter Maydell (10): > hw/sd.c: Fix the set of commands which are failed when card is locked I replaced "card" with "command" in the commit message. > hw/sd.c: Add comment regarding CARD_STATUS_* defines > hw/sd.c: On CRC error, set CRC error status bit rather than clearing it > hw/sd.c: When setting ADDRESS_ERROR bit, don't clear everything else > hw/sd.c: Handle illegal commands in sd_do_command > hw/sd.c: Handle CRC and locked-card errors in normal code path > hw/sd.c: Set ILLEGAL_COMMAND for ACMDs in invalid state > hw/sd.c: Correct handling of type B SD status bits > hw/sd.c: Correct handling of APP_CMD status bit I added resetting of .expecting_acmd in a separate patch. > hw/sd.c: Clear status bits when read via response r6 I thought it might be possible to test what bits real cards reset in those cases, but then it would be problematic getting the card to set each error bit. Cheers
Re: [Qemu-devel] [RFC][PATCH 8/8 v3] introduce a new monitor command 'dump' to dump guest's memory
On 20 December 2011 17:25, Eric Blake wrote:
> On 12/20/2011 02:15 AM, Wen Congyang wrote:
>> Signed-off-by: Wen Congyang
>> ---
>> Makefile.target | 8 +-
>> dump.c | 452
>> +++
>> dump.h | 4 +
>> hmp-commands.hx | 16 ++
>> monitor.c | 3 +
>> qmp-commands.hx | 24 +++
>> 6 files changed, 503 insertions(+), 4 deletions(-)
>> create mode 100644 dump.c
>>
>> +++ b/qmp-commands.hx
>> @@ -469,6 +469,30 @@ Notes:
>> EQMP
>>
>> {
>> + .name = "dump",
>> + .args_type = "file:s",
>> + .params = "file",
>> + .help = "dump to file",
>> + .user_print = monitor_user_noop,
>> + .mhandler.cmd_new = do_dump,
>> + },
>
> From a libvirt perspective, we would like the option to be able to pass
> in an already-open fd rather than just a file name. This is possible if
> the 'file' argument is required to start with '/' for an absolute path,
> vs. 'file:name' for an fd previously passed in via the getfd monitor
> command.
>
> Also, does this command block? It sounds like it is long-running, which
> means it probably needs to be asynchronous, as well as issue an event
> upon completion, so that other monitor commands can be issued in the
> meantime.
Note that it needs to stop the VM and it'd need to prevent other
commands from resuming if this command becomes asynchronous, like
during migration.
Cheers
Re: [Qemu-devel] [PATCH 5/6] hw/omap1.c: Separate clkm from omap_mpu_state
On 20 December 2011 19:11, Peter Maydell wrote:
> From: Juha Riihimäki
>
> Signed-off-by: Juha Riihimäki
> [Riku Voipio: Fixes and restructuring patchset]
> Signed-off-by: Riku Voipio
> [Peter Maydell: More fixes and cleanups for upstream submission]
> Signed-off-by: Peter Maydell
> ---
> hw/omap.h | 16 +---
> hw/omap1.c | 127
> ++--
> 2 files changed, 73 insertions(+), 70 deletions(-)
>
> diff --git a/hw/omap.h b/hw/omap.h
> index 60fa34c..17b4312 100644
> --- a/hw/omap.h
> +++ b/hw/omap.h
> @@ -907,21 +907,7 @@ struct omap_mpu_state_s {
> struct dpll_ctl_s *dpll[3];
>
> omap_clk clks;
> - struct {
> - int cold_start;
> - int clocking_scheme;
> - uint16_t arm_ckctl;
> - uint16_t arm_idlect1;
> - uint16_t arm_idlect2;
> - uint16_t arm_ewupct;
> - uint16_t arm_rstct1;
> - uint16_t arm_rstct2;
> - uint16_t arm_ckout1;
> - int dpll1_mode;
> - uint16_t dsp_idlect1;
> - uint16_t dsp_idlect2;
> - uint16_t dsp_rstct2;
> - } clkm;
> + struct omap_clkm_s *clkm;
>
> /* OMAP2-only peripherals */
> struct omap_l4_s *l4;
> diff --git a/hw/omap1.c b/hw/omap1.c
> index 6ab9192..5fc67e9 100644
> --- a/hw/omap1.c
> +++ b/hw/omap1.c
> @@ -1429,6 +1429,22 @@ static struct dpll_ctl_s *omap_dpll_init(MemoryRegion
> *memory,
> }
>
> /* MPU Clock/Reset/Power Mode Control */
> +struct omap_clkm_s {
> + int cold_start;
> + int clocking_scheme;
> + uint16_t arm_ckctl;
> + uint16_t arm_idlect1;
> + uint16_t arm_idlect2;
> + uint16_t arm_ewupct;
> + uint16_t arm_rstct1;
> + uint16_t arm_rstct2;
> + uint16_t arm_ckout1;
> + int dpll1_mode;
> + uint16_t dsp_idlect1;
> + uint16_t dsp_idlect2;
> + uint16_t dsp_rstct2;
> +};
> +
> static uint64_t omap_clkm_read(void *opaque, target_phys_addr_t addr,
> unsigned size)
> {
> @@ -1440,28 +1456,28 @@ static uint64_t omap_clkm_read(void *opaque,
> target_phys_addr_t addr,
>
> switch (addr) {
> case 0x00: /* ARM_CKCTL */
> - return s->clkm.arm_ckctl;
> + return s->clkm->arm_ckctl;
>
> case 0x04: /* ARM_IDLECT1 */
> - return s->clkm.arm_idlect1;
> + return s->clkm->arm_idlect1;
>
> case 0x08: /* ARM_IDLECT2 */
> - return s->clkm.arm_idlect2;
> + return s->clkm->arm_idlect2;
>
> case 0x0c: /* ARM_EWUPCT */
> - return s->clkm.arm_ewupct;
> + return s->clkm->arm_ewupct;
>
> case 0x10: /* ARM_RSTCT1 */
> - return s->clkm.arm_rstct1;
> + return s->clkm->arm_rstct1;
>
> case 0x14: /* ARM_RSTCT2 */
> - return s->clkm.arm_rstct2;
> + return s->clkm->arm_rstct2;
>
> case 0x18: /* ARM_SYSST */
> - return (s->clkm.clocking_scheme << 11) | s->clkm.cold_start;
> + return (s->clkm->clocking_scheme << 11) | s->clkm->cold_start;
>
> case 0x1c: /* ARM_CKOUT1 */
> - return s->clkm.arm_ckout1;
> + return s->clkm->arm_ckout1;
>
> case 0x20: /* ARM_CKOUT2 */
> break;
> @@ -1647,33 +1663,33 @@ static void omap_clkm_write(void *opaque,
> target_phys_addr_t addr,
>
> switch (addr) {
> case 0x00: /* ARM_CKCTL */
> - diff = s->clkm.arm_ckctl ^ value;
> - s->clkm.arm_ckctl = value & 0x7fff;
> + diff = s->clkm->arm_ckctl ^ value;
> + s->clkm->arm_ckctl = value & 0x7fff;
> omap_clkm_ckctl_update(s, diff, value);
> return;
>
> case 0x04: /* ARM_IDLECT1 */
> - diff = s->clkm.arm_idlect1 ^ value;
> - s->clkm.arm_idlect1 = value & 0x0fff;
> + diff = s->clkm->arm_idlect1 ^ value;
> + s->clkm->arm_idlect1 = value & 0x0fff;
> omap_clkm_idlect1_update(s, diff, value);
> return;
>
> case 0x08: /* ARM_IDLECT2 */
> - diff = s->clkm.arm_idlect2 ^ value;
> - s->clkm.arm_idlect2 = value & 0x07ff;
> + diff = s->clkm->arm_idlect2 ^ value;
> + s->clkm->arm_idlect2 = value & 0x07ff;
> omap_clkm_idlect2_update(s, diff, value);
> return;
>
> case 0x0c: /* ARM_EWUPCT */
> - s->clkm.arm_ewupct = value & 0x003f;
> + s->clkm->arm_ewupct = value & 0x003f;
> return;
>
> case 0x10: /* ARM_RSTCT1 */
> - diff = s->clkm.arm_rstct1 ^ value;
> - s->clkm.arm_rstct1 = value & 0x0007;
> + diff = s->clkm->arm_rstct1 ^ value;
> + s->clkm->arm_rstct1 = value & 0x0007;
> if (value & 9) {
> qemu_system_reset_request();
> - s->clkm.cold_start = 0xa;
> + s->clkm->cold_start = 0xa;
> }
> if (diff & ~value & 4) { /* DSP_RST */
> omap_mpui_reset(s);
> @@ -1687,21 +1703,21 @@ static void omap_clkm_write(void *opaque,
> target_phys_addr_t addr,
> return;
>
> case 0x14: /* ARM_RSTCT2 */
> - s->clkm.arm_rstct2 = value & 0x0001;
> +
Re: [Qemu-devel] [PATCH] configure: don't try to compile against known broken curses.
On 7 December 2011 20:06, andrzej zaborowski wrote:
> On 7 December 2011 19:57, Stefan Weil wrote:
>> Am 07.12.2011 08:47, schrieb Andrzej Zaborowski:
>>> +#ifdef NCURSES_VERSION
>>> +# if NCURSES_VERSION_PATCH < 20040117
>>> +# error Old ncurses contain dangerous typedefs, break qemu build (and are
>>> old)
>>> +# endif
>>> +#endif
>>> int main(void) { resize_term(0, 0); return curses_version(); }
>>> EOF
>>> for curses_lib in $curses_list; do
>>
>>
>> Is NCURSES_VERSION_PATCH always defined when NCURSES_VERSION is?
>
> I'm not sure, will try to find out. If it isn't then we should check
> that NCURSES_VERSION_MINOR < 4 perhaps.
At least since 4.2 (19980211) both are defined, I'll apply a version
of the patch similar to what you proposed.
Cheers
Re: [Qemu-devel] [PULL 00/10] target-arm queue
On 13 December 2011 19:30, Peter Maydell wrote: > Current target-arm pending patches; mostly these are Andreas' > inference series, plus one from Jean-Christophe that's been > waiting since before the 1.0 release. > > Please pull. Thanks, pulled (and pushed) Cheers
Re: [Qemu-devel] [PATCH] ARM - Remove fixed map code buffer restriction
On 12 December 2011 16:37, Dr. David Alan Gilbert wrote: > On ARM, don't map the code buffer at a fixed location, and fix up the > call/goto tcg routines to let it do long jumps. > > Mapping the code buffer at a fixed address could sometimes result in it being > mapped over the top of the heap with pretty random results. > > This diff is against v1.0. > > Signed-off-by: Dr. David Alan Gilbert > --- > exec.c | 4 +--- > tcg/arm/tcg-target.c | 31 --- > 2 files changed, 13 insertions(+), 22 deletions(-) Thanks, I applied this patch. Cheers
Re: [Qemu-devel] [PATCH] ARM - Remove fixed map code buffer restriction
On 12 December 2011 19:03, Peter Maydell wrote: > On 12 December 2011 17:24, andrzej zaborowski wrote: >> BTW: I think we can also use the "ld" branch when we see the goto >> target is in Thumb mode. > > The target of a goto is currently never Thumb (because gotos are > always to other TCG generated code and we only generate ARM insns). I'm aware of that, I just like functions that can do what their name says well. :) Cheers
Re: [Qemu-devel] [PATCH] ARM - Remove fixed map code buffer restriction
Hi,
On 12 December 2011 16:55, Peter Maydell wrote:
> On 12 December 2011 15:37, Dr. David Alan Gilbert
> wrote:
>> On ARM, don't map the code buffer at a fixed location, and fix up the
>> call/goto tcg routines to let it do long jumps.
>>
>> Mapping the code buffer at a fixed address could sometimes result in it being
>> mapped over the top of the heap with pretty random results.
>>
>> This diff is against v1.0.
>
> Patches should always be against master, although we're still
> close enough to 1.0 that this will probably apply anyway.
>
> Comments like "This diff is against v1.0." go below the '---' so they
> don't appear in the final commit log.
>
> Code generally looks OK to me.
To me as well, I'll apply if there are no objections. I remember
Peter asked about MAP_FIXED on other hosts, has there been a
resolution?
>
>> Signed-off-by: Dr. David Alan Gilbert
>> ---
>> exec.c | 4 +---
>> tcg/arm/tcg-target.c | 31 ---
>> 2 files changed, 13 insertions(+), 22 deletions(-)
>>
>> diff --git a/exec.c b/exec.c
>> index 6b92198..ef83da1 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -497,9 +497,7 @@ static void code_gen_alloc(unsigned long tb_size)
>> if (code_gen_buffer_size > (512 * 1024 * 1024))
>> code_gen_buffer_size = (512 * 1024 * 1024);
>> #elif defined(__arm__)
>> - /* Map the buffer below 32M, so we can use direct calls and
>> branches */
>> - flags |= MAP_FIXED;
>> - start = (void *) 0x0100UL;
>> + /* Keep the buffer no bigger than 16GB to branch between blocks */
>> if (code_gen_buffer_size > 16 * 1024 * 1024)
>> code_gen_buffer_size = 16 * 1024 * 1024;
>> #elif defined(__s390x__)
>> diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
>> index e05a64f..730d913 100644
>> --- a/tcg/arm/tcg-target.c
>> +++ b/tcg/arm/tcg-target.c
>> @@ -842,6 +842,12 @@ static inline void tcg_out_st8(TCGContext *s, int cond,
>> tcg_out_st8_12(s, cond, rd, rn, offset);
>> }
>>
>> +/* The _goto case is normally between TBs within the same code buffer,
>> + and with the code buffer limited to 16GB we shouldn't need the long
>> + case.
>> +
>> + except to the prologue that is in its own buffer.
>> + */
>> static inline void tcg_out_goto(TCGContext *s, int cond, uint32_t addr)
>> {
>> int32_t val;
>> @@ -855,22 +861,20 @@ static inline void tcg_out_goto(TCGContext *s, int
>> cond, uint32_t addr)
>> if (val - 8 < 0x01fd && val - 8 > -0x01fd)
>> tcg_out_b(s, cond, val);
>> else {
>> -#if 1
>> - tcg_abort();
>> -#else
>> if (cond == COND_AL) {
>> tcg_out_ld32_12(s, COND_AL, TCG_REG_PC, TCG_REG_PC, -4);
>> - tcg_out32(s, addr); /* XXX: This is l->u.value, can we use it?
>> */
>> + tcg_out32(s, addr);
>
> I see these XXXs have been there since the ARM tcg target was
> introduced. Does anybody know what they were referring to? Andrzej?
David asked me about them, but I couldn't figure it out. (the part in
tcg_out_call apparently is just copy&pasted from tcg_ouy_goto)
BTW: I think we can also use the "ld" branch when we see the goto
target is in Thumb mode.
Cheers
Re: [Qemu-devel] [PATCH 2/2] configure: remove --enable-cocoa (default), add --disable-cocoa.
On 9 December 2011 02:25, andrzej zaborowski wrote: >>> Cocoa support seems to be broken at the moment, at least on some >>> MacOS X versions. But qemu builds and runs with SDL. >> >> Many times have I asked how to actually use SDL with QEMU on Mac OS X. >> If you've figured it out, please share that knowledge! What SDL download >> do you use, what parameters do you pass to configure, etc.? > > I installed SDL through "fink", the package manager. It's sdl_1.2.4-8 > and the configure line apparently is nothing more than ./configure > --prefix=/sw --mandir=/sw/share/man Fink applies the following patch, too: http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/games/sdl.patch?revision=1.2&view=markup Cheers
Re: [Qemu-devel] [PATCH 2/2] configure: remove --enable-cocoa (default), add --disable-cocoa.
On 7 December 2011 22:12, Andreas Färber wrote: > Am 07.12.2011 08:47, schrieb Andrzej Zaborowski: >> Cocoa can only be enabled on Darwin, and is enabled by default too, >> making --enable-cocoa redundant, with no way to disable Cocoa. It >> also interfered with SDL support in a way that was dependent on >> the order of commandline switches. >> >> Signed-off-by: Andrzej Zaborowski > > Nack. This not only conflicts with Pavel's patch series but like many > previous patches only does half the job (misses the block layer). Depends which job you're talking about :) Sorry, I wasn't aware Cocoa was used by anything other than the UI or aware of Pavel's patches. > Could you please review his last series instead and rebase onto that if > necessary? > > http://patchwork.ozlabs.org/patch/124980/ > http://patchwork.ozlabs.org/patch/124979/ > http://patchwork.ozlabs.org/patch/124981/ They look fine to me but I know very little about MacOS X and its libraries. > >> --- >> Cocoa support seems to be broken at the moment, at least on some >> MacOS X versions. But qemu builds and runs with SDL. > > Many times have I asked how to actually use SDL with QEMU on Mac OS X. > If you've figured it out, please share that knowledge! What SDL download > do you use, what parameters do you pass to configure, etc.? I installed SDL through "fink", the package manager. It's sdl_1.2.4-8 and the configure line apparently is nothing more than ./configure --prefix=/sw --mandir=/sw/share/man Last time I was using it with 0.14 with no issues, now that I rebuilt HEAD with SDL, I see two issues which may be related to SDL or not: * blue component is 0, so stuff is yellowish on the screen. * ctrl-alt- doesn't work, while ctr-alt does. Cheers
Re: [Qemu-devel] [PATCH 2/2] configure: remove --enable-cocoa (default), add --disable-cocoa.
On 7 December 2011 19:56, Peter Maydell wrote: > On 7 December 2011 07:47, Andrzej Zaborowski wrote: >> Cocoa can only be enabled on Darwin, and is enabled by default too, >> making --enable-cocoa redundant, with no way to disable Cocoa. It >> also interfered with SDL support in a way that was dependent on >> the order of commandline switches. > > For these --enable/disable pairs I quite like the pattern where > * default is "probe and use if available" > * --enable-foo is "use foo, fail configure if not available" > * --disable-foo is "don't use foo" > > (--enable-sdl/--disable-sdl work like this, for instance). Yep, the difference here is that there's no probing, so --enable is a little redundant, but maybe for consistency it's better to have anyway. One of the issues with current --enable-cocoa though is that it has a different effect than if Cocoa is enabled by default. > > [cf the comment in configure at line 100.] > > Incidentally, is it "Cocoa" or "COCOA" ? It appears as Cocoa in the system libraries, but don't take my word. Cheers
Re: [Qemu-devel] [PATCH] configure: don't try to compile against known broken curses.
On 7 December 2011 19:57, Stefan Weil wrote:
> Am 07.12.2011 08:47, schrieb Andrzej Zaborowski:
>> +#ifdef NCURSES_VERSION
>> +# if NCURSES_VERSION_PATCH < 20040117
>> +# error Old ncurses contain dangerous typedefs, break qemu build (and are
>> old)
>> +# endif
>> +#endif
>> int main(void) { resize_term(0, 0); return curses_version(); }
>> EOF
>> for curses_lib in $curses_list; do
>
>
> Is NCURSES_VERSION_PATCH always defined when NCURSES_VERSION is?
I'm not sure, will try to find out. If it isn't then we should check
that NCURSES_VERSION_MINOR < 4 perhaps.
The intent of checking defined(NCURSES_VERSION) is to detect ncurses
because qemu should also build with other implementations of curses
(in theory).
Cheers
[Qemu-devel] [PATCH 2/2] configure: remove --enable-cocoa (default), add --disable-cocoa.
Cocoa can only be enabled on Darwin, and is enabled by default too, making --enable-cocoa redundant, with no way to disable Cocoa. It also interfered with SDL support in a way that was dependent on the order of commandline switches. Signed-off-by: Andrzej Zaborowski --- Cocoa support seems to be broken at the moment, at least on some MacOS X versions. But qemu builds and runs with SDL. configure |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/configure b/configure index fb15bc6..c5d07af 100755 --- a/configure +++ b/configure @@ -674,10 +674,7 @@ for opt do ;; --enable-profiler) profiler="yes" ;; - --enable-cocoa) - cocoa="yes" ; - sdl="no" ; - audio_drv_list="coreaudio `echo $audio_drv_list | sed s,coreaudio,,g`" + --disable-cocoa) cocoa="no" ;; --disable-system) softmmu="no" ;; @@ -986,7 +983,7 @@ echo " --disable-sdldisable SDL" echo " --enable-sdl enable SDL" echo " --disable-vncdisable VNC" echo " --enable-vnc enable VNC" -echo " --enable-cocoa enable COCOA (Mac OS X only)" +echo " --disable-cocoa disable COCOA (Mac OS X only)" echo " --audio-drv-list=LISTset audio drivers list:" echo " Available drivers: $audio_possible_drivers" echo " --audio-card-list=LIST set list of emulated audio cards [$audio_card_list]" -- 1.7.4.4
[Qemu-devel] [PATCH 1/2] configure: don't check for Cocoa when detecting SDL.
The SDL check is supposed to set $sdl to "yes" or "no", but with that check it leaves $sdl unset on darwin, unless --enable-cocoa was specified (which is not needed to enable cocoa anyway). Signed-off-by: Andrzej Zaborowski --- configure |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/configure b/configure index 678b982..fb15bc6 100755 --- a/configure +++ b/configure @@ -1492,9 +1492,7 @@ EOF if test "$_sdlversion" -lt 121 ; then sdl_too_old=yes else - if test "$cocoa" = "no" ; then -sdl=yes - fi + sdl=yes fi # static link with sdl ? (note: sdl.pc's --static --libs is broken) -- 1.7.4.4
[Qemu-devel] [PATCH] configure: don't try to compile against known broken curses.
This should resolve a problem noted by Caraman Mihai Claudiu.
Signed-off-by: Andrzej Zaborowski
---
configure |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 61c43b9..678b982 100755
--- a/configure
+++ b/configure
@@ -1846,6 +1846,11 @@ if test "$curses" != "no" ; then
#ifdef __OpenBSD__
#define resize_term resizeterm
#endif
+#ifdef NCURSES_VERSION
+# if NCURSES_VERSION_PATCH < 20040117
+# error Old ncurses contain dangerous typedefs, break qemu build (and are old)
+# endif
+#endif
int main(void) { resize_term(0, 0); return curses_version(); }
EOF
for curses_lib in $curses_list; do
--
1.7.4.4
Re: [Qemu-devel] ncurses 5.3 conflicts with latest qemu
On 5 December 2011 22:44, Stefan Weil wrote: > Am 05.12.2011 20:13, schrieb andrzej zaborowski: > >> Hi, >> >> On 17 November 2011 10:06, Caraman Mihai Claudiu-B02008 >> wrote: >>> >>> A recent patch in qemu conflicts with old ncurses libraries (version >>> 5.3). You will see this error cause by bool type redefinition in curses.h >>> (with CONFIG_CURSES configured by default): >>> >>> console.c: In function 'text_console_init': >>> console.c:1550:23: error: assignment from incompatible pointer type >>> >>> the qemu patch exposing this problem is: >>> >>> curses: fix garbling when chtype != long >>> author Devin J. Pohly >>> Wed, 7 Sep 2011 19:44:36 + (15:44 -0400) >>> committer Anthony Liguori >>> Fri, 9 Sep 2011 17:58:16 + (12:58 -0500) >>> commit df00bed0fa30a6f5712456e7add783e470c534c9 >>> >>> The problem seems to be fixed in newer versions of ncurses (5.7 and >>> above). I just looked over the sources, so better if someone can confirm >>> this. >>> Here is a qemu patch that solve the conflict with old ncurses: >>> >>> >>> Signed-off-by: Mihai Caraman >>> --- >>> Fix compile errors with old ncurses libraries (version 5.3) caused by >>> bool type redefinition. >>> >>> qemu-common.h | 3 +++ >>> console.h | 1 - >>> >>> 2 files changed, 3 insertions(+), 1 deletions(-) >>> >>> diff --git a/qemu-common.h b/qemu-common.h index 5e87bdf..9ac15ba 100644 >>> --- a/qemu-common.h >>> +++ b/qemu-common.h >>> @@ -23,6 +23,9 @@ typedef struct Monitor Monitor; #include >>> #include #include >>> +#ifdef CONFIG_CURSES >>> +#include >>> +#endif >>> #include >>> #include >>> #include >>> diff --git a/console.h b/console.h >>> index 9c1487e..3327c43 100644 >>> --- a/console.h >>> +++ b/console.h >>> @@ -329,7 +329,6 @@ static inline int ds_get_bytes_per_pixel(DisplayState >>> *ds) } >>> >>> #ifdef CONFIG_CURSES >>> -#include >>> typedef chtype console_ch_t; >>> #else >>> typedef unsigned long console_ch_t; >> >> >> While very fragile it looks like the easiest fix, so I'd like to push >> this if there's no objection. It builds fine for me. >> >> The solution would probably be to include only from inside >> ui/curses.c, and define chtype at configure time, or guess it. >> >> Cheers > > > Even Debian Lenny already has ncurses 5.7 and does not > need this patch. > > Is there a good reason why very old buggy versions of ncurses > should be supported? Redefining bool is a bug! > > When I had the same problem some time ago, I fixed my local > installation... Makes sense. Turns out that 5.3 was released in 2002 and from the changelog it looks like the problem was fixed on 2004-01-17 or earlier. I'll send a patch for configure to refuse ncurses versions older than that. Cheers
Re: [Qemu-devel] [PATCH] hw/arm_gic.c: Ignore attempts to complete nonexistent IRQs
On 1 December 2011 19:37, Peter Maydell wrote: > Ignore attempts to complete non-existent IRQs; this fixes a buffer > overrun if the guest writes a bad value to the GICC_EOIR register. > (This case is UNPREDICTABLE so ignoring it is a valid choice.) > Note that doing nothing if the guest writes 1023 to this register > is not in fact a change in behaviour: the old code would also > always do nothing in this case but in a non-obvious way. > (The buffer overrun was noted by Coverity, see bug 887883.) Thanks, applied this patch also. Cheers
Re: [Qemu-devel] [PATCH] configure: Drop armv4l/armv4b distinction in $cpu
On 30 November 2011 10:57, Peter Maydell wrote: > Drop the distinction between armv4l/armv4b in the $cpu variable > (ie host cpu type) in favour of calling everything 'arm'. This > makes it the same as the ARCH setting and removes some special > casing. The only thing we were using the distinction for was to > decide which endianness to use in cross compilation; do a cpp > define check there instead. Thanks, applied this patch. Cheers
Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Fix array overrun bug in PCI code
On 29 November 2011 08:41, David Gibson wrote: > On Tue, Nov 29, 2011 at 05:21:39PM +1100, David Gibson wrote: >> spapr_populate_pci_devices() containd a loop with PCI_NUM_REGIONS (7) >> iterations. However this overruns the 'bars' global array, which only has >> 6 elements. In fact we only want to run this loop for things listed in the >> bars array, so this patch corrects the loop bounds to reflect that. >> >> Signed-off-by: David Gibson > > As a bugfix for a bad memory access, this is definitely for 1.0 Now applied. Indeed it would probably have been better done before the release. Cheers
Re: [Qemu-devel] [PATCH] target-arm/helper.c: Don't allocate TCG resources unless TCG enabled
On 25 November 2011 19:25, Peter Maydell wrote: > Don't call arm_translate_init() (which allocates TCG resources) > unless TCG is enabled. Thanks, applied this patch. Cheers
Re: [Qemu-devel] [PATCH] target-arm/translate.c: Fix slightly misleading comment in Thumb decoder
On 24 November 2011 19:33, Peter Maydell wrote: > Clarify some slightly misleading comments in the Thumb decoder's > handling of the memory hint space -- in particular one code path > marked as 'UNPREDICTABLE or unallocated hint' also includes some > legitimate preload instructions. Thanks, applied this patch. Cheers
Re: [Qemu-devel] [PATCH] [ARM] Fix hw_error messages from arm_timer.c
On 22 November 2011 04:20, Peter Chubb wrote: > Two of the calls to hw_error() in arm_timer.c contain the wrong function name. > > As suggested by Andreas Färber, use the C99 standard __func__ macro to > get the correct name, instead of putting the name directly into the code. Thanks, applied. Cheers
Re: [Qemu-devel] ncurses 5.3 conflicts with latest qemu
Hi, On 17 November 2011 10:06, Caraman Mihai Claudiu-B02008 wrote: > A recent patch in qemu conflicts with old ncurses libraries (version 5.3). > You will see this error cause by bool type redefinition in curses.h (with > CONFIG_CURSES configured by default): > > console.c: In function 'text_console_init': > console.c:1550:23: error: assignment from incompatible pointer type > > the qemu patch exposing this problem is: > > curses: fix garbling when chtype != long > author Devin J. Pohly > Wed, 7 Sep 2011 19:44:36 + (15:44 -0400) > committer Anthony Liguori > Fri, 9 Sep 2011 17:58:16 + (12:58 -0500) > commit df00bed0fa30a6f5712456e7add783e470c534c9 > > The problem seems to be fixed in newer versions of ncurses (5.7 and above). I > just looked over the sources, so better if someone can confirm this. > Here is a qemu patch that solve the conflict with old ncurses: > > > Signed-off-by: Mihai Caraman > --- > Fix compile errors with old ncurses libraries (version 5.3) caused by bool > type redefinition. > > qemu-common.h | 3 +++ > console.h | 1 - > > 2 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/qemu-common.h b/qemu-common.h index 5e87bdf..9ac15ba 100644 > --- a/qemu-common.h > +++ b/qemu-common.h > @@ -23,6 +23,9 @@ typedef struct Monitor Monitor; #include > #include #include > +#ifdef CONFIG_CURSES > +#include > +#endif > #include > #include > #include > diff --git a/console.h b/console.h > index 9c1487e..3327c43 100644 > --- a/console.h > +++ b/console.h > @@ -329,7 +329,6 @@ static inline int ds_get_bytes_per_pixel(DisplayState > *ds) } > > #ifdef CONFIG_CURSES > -#include > typedef chtype console_ch_t; > #else > typedef unsigned long console_ch_t; While very fragile it looks like the easiest fix, so I'd like to push this if there's no objection. It builds fine for me. The solution would probably be to include only from inside ui/curses.c, and define chtype at configure time, or guess it. Cheers
Re: [Qemu-devel] [PATCH 3/3] omap_l4: add memory API variant of omap_l4_attach()
On 24 November 2011 16:57, Avi Kivity wrote:
> Also add omap_l4_region_size(), since memory API functions need
> the size during initialization.
Logically it should be one of the omap_l4_* functions that set the
size for the region instead of the target agents because this is where
all the memory map is hardcoded. However with the current memory api
I see that it's more straight forward to go this way.
Cheers
>
> Signed-off-by: Avi Kivity
> ---
> hw/omap.h | 7 ++-
> hw/omap2.c | 2 +-
> hw/omap_l4.c | 29 -
> 3 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/hw/omap.h b/hw/omap.h
> index d12f402..367ba11 100644
> --- a/hw/omap.h
> +++ b/hw/omap.h
> @@ -84,7 +84,8 @@ struct omap_target_agent_s {
> uint32_t control;
> uint32_t status;
> };
> -struct omap_l4_s *omap_l4_init(target_phys_addr_t base, int ta_num);
> +struct omap_l4_s *omap_l4_init(MemoryRegion *address_space,
> + target_phys_addr_t base, int ta_num);
>
> struct omap_target_agent_s;
> struct omap_target_agent_s *omap_l4ta_get(
> @@ -94,8 +95,12 @@ struct omap_target_agent_s *omap_l4ta_get(
> int cs);
> target_phys_addr_t omap_l4_attach(struct omap_target_agent_s *ta, int region,
> int iotype);
> +target_phys_addr_t omap_l4_attach_region(struct omap_target_agent_s *ta,
> + int region, MemoryRegion *mr);
> target_phys_addr_t omap_l4_region_base(struct omap_target_agent_s *ta,
> int region);
> +target_phys_addr_t omap_l4_region_size(struct omap_target_agent_s *ta,
> + int region);
>
> /* OMAP2 SDRAM controller */
> struct omap_sdrc_s;
> diff --git a/hw/omap2.c b/hw/omap2.c
> index 8a0fa73..5fc3fcf 100644
> --- a/hw/omap2.c
> +++ b/hw/omap2.c
> @@ -2260,7 +2260,7 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion
> *sysmem,
> (sram_base = qemu_ram_alloc(NULL, "omap2.sram",
> s->sram_size)) | IO_MEM_RAM);
>
> - s->l4 = omap_l4_init(OMAP2_L4_BASE, 54);
> + s->l4 = omap_l4_init(sysmem, OMAP2_L4_BASE, 54);
>
> /* Actually mapped at any 2K boundary in the ARM11 private-peripheral if
> */
> cpu_irq = arm_pic_init_cpu(s->env);
> diff --git a/hw/omap_l4.c b/hw/omap_l4.c
> index a19ea70..a0bed5c 100644
> --- a/hw/omap_l4.c
> +++ b/hw/omap_l4.c
> @@ -21,16 +21,19 @@
> #include "omap.h"
>
> struct omap_l4_s {
> + MemoryRegion *address_space;
> target_phys_addr_t base;
> int ta_num;
> struct omap_target_agent_s ta[0];
> };
>
> -struct omap_l4_s *omap_l4_init(target_phys_addr_t base, int ta_num)
> +struct omap_l4_s *omap_l4_init(MemoryRegion *address_space,
> + target_phys_addr_t base, int ta_num)
> {
> struct omap_l4_s *bus = g_malloc0(
> sizeof(*bus) + ta_num * sizeof(*bus->ta));
>
> + bus->address_space = address_space;
> bus->ta_num = ta_num;
> bus->base = base;
>
> @@ -43,6 +46,12 @@ target_phys_addr_t omap_l4_region_base(struct
> omap_target_agent_s *ta,
> return ta->bus->base + ta->start[region].offset;
> }
>
> +target_phys_addr_t omap_l4_region_size(struct omap_target_agent_s *ta,
> + int region)
> +{
> + return ta->start[region].size;
> +}
> +
> static uint32_t omap_l4ta_read(void *opaque, target_phys_addr_t addr)
> {
> struct omap_target_agent_s *s = (struct omap_target_agent_s *) opaque;
> @@ -150,3 +159,21 @@ target_phys_addr_t omap_l4_attach(struct
> omap_target_agent_s *ta, int region,
>
> return base;
> }
> +
> +target_phys_addr_t omap_l4_attach_region(struct omap_target_agent_s *ta,
> + int region, MemoryRegion *mr)
> +{
> + target_phys_addr_t base;
> +
> + if (region < 0 || region >= ta->regions) {
> + fprintf(stderr, "%s: bad io region (%i)\n", __FUNCTION__, region);
> + exit(-1);
> + }
> +
> + base = ta->bus->base + ta->start[region].offset;
> + if (mr) {
> + memory_region_add_subregion(ta->bus->address_space, base, mr);
> + }
> +
> + return base;
> +}
> --
> 1.7.7.1
>
>
>
Re: [Qemu-devel] [PATCH 1/3] omap: remove L4_MUX_HACK
On 24 November 2011 16:57, Avi Kivity wrote: > This was introduced apparently to overcome a limitation on the number of > cpu_register_io_memory() calls. 477b24ef91175 (July 2008) removed use > of the hack, but retained the code. This patch removes the code as well. > > Signed-off-by: Avi Kivity Reviewed-by: Andrzej Zaborowski
Re: [Qemu-devel] [PATCH] hw/usb-net.c: Fix precedence bug when checking rndis_state
On 14 November 2011 09:08, Peter Maydell wrote: > I'm happy that non-rndis works, I tested that. What I don't know > is whether the patch breaks rndis Sorry, I misread what you said assuming that you tested a branch affected by this patch. I'm unable to find a guest to test the rndis mode so I reverted the patch until after release. Applying is probably the best way to get someone to test a change like this. Cheers
Re: [Qemu-devel] [PATCH v2 0/2] nand/onenand: reject read-only drives
On 20 October 2011 14:53, wrote: > From: Juha Riihimäki > > Make NAND and OneNAND device models reject read-only drives. > Test for example by running > > $ qemu-system-arm -drive if=none,file=/dev/zero,readonly,id=foo -device > nand,drive=foo,chip_id=0x59 -kernel /dev/null > > or > > $ qemu-system-arm -drive if=none,file=/dev/zero,readonly,id=foo -device > onenand,drive=foo -kernel /dev/null > > Changes v1->v2: > + fix bug introduced in pagesize calculation for NAND devices without a drive > image > + revise commit message in hw/nand patch Thanks, applied. Cheers
Re: [Qemu-devel] [PATCH v3] hw/arm_sysctl: Fix RESETCTL for realview-pb-a8 and -pbx-a9
On 6 November 2011 20:14, Jean-Christophe DUBOIS wrote: > Depending on the considered baseboard the bit used to > reset the platform is different. > > Here is the list of considered Realview/Versatile platforms: > > Realview/Versatile AB for ARM926EJ-S: BOARD_ID = 0x100 = BOARD_ID_PB926 > http://infocenter.arm.com/help/topic/com.arm.doc.dui0225d/CACCIFGI.html > > RealView Emulation Baseboard: BOARD_ID = 0x140 = BOARD_ID_EB > No reset register > > RealView PB for Cortex-A8: BOARD_ID = 0x178 = BOARD_ID_PBA8 > http://infocenter.arm.com/help/topic/com.arm.doc.dui0417d/BBACIGAD.html > > RealView PB for Cortex-A9: BOARD_ID = 0x182 = BOARD_ID_PBX > http://infocenter.arm.com/help/topic/com.arm.doc.dui0440b/CACCHBFB.html > > Motherboard Express µATX: BOARD_ID = 0x190 = BOARD_ID_VEXPRESS > No reset register > > Signed-off-by: Jean-Christophe DUBOIS Thanks, I applied this fix. Cheers
Re: [Qemu-devel] [PATCH] hw/usb-net.c: Fix precedence bug when checking rndis_state
On 9 November 2011 22:09, Peter Maydell wrote: > "!X == 2" is always false (spotted by Coverity), so the checks > for whether rndis is in the correct state would never fire. I pushed this patch because it's a bugfix and the check is guarded by is_rndis() so there should be no risk of affecting non-rndis. Cheers
Re: [Qemu-devel] [PATCH] hw/pxa2xx.c: Fix handling of RW bits in PMCR
On 13 November 2011 15:18, Peter Maydell wrote: > Fix an error in commit afd4a6522 which meant that writing a zero > to the RW bits in the PMCR wouldn't actually clear them. (Error > spotted by Andrzej Zaborowski.) > > Signed-off-by: Peter Maydell Thanks, pushed. Cheers
Re: [Qemu-devel] [PATCH] hw/pxa2xx.c: Fix handling of R/WC bits in PMCR
Hi,
On 11 November 2011 20:45, Anthony Liguori wrote:
> On 11/09/2011 02:46 PM, Peter Maydell wrote:
>>
>> Fix a bug in handling the write-one-to-clear bits in the PMCR
>> which meant that we would always clear the bit even if the
>> value written was a zero. Spotted by Coverity (see bug 887883).
>>
>> Signed-off-by: Peter Maydell
>
> Applied. Thanks.
>
> Regards,
>
> Anthony Liguori
>
>> ---
>> hw/pxa2xx.c | 4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
>> index bfc28a9..d38b922 100644
>> --- a/hw/pxa2xx.c
>> +++ b/hw/pxa2xx.c
>> @@ -114,7 +114,9 @@ static void pxa2xx_pm_write(void *opaque,
>> target_phys_addr_t addr,
>>
>> switch (addr) {
>> case PMCR:
>> - s->pm_regs[addr>> 2]&= 0x15& ~(value& 0x2a);
>> + /* Clear the write-one-to-clear bits... */
>> + s->pm_regs[addr>> 2]&= ~(value& 0x2a);
>> + /* ...and set the plain r/w bits */
>> s->pm_regs[addr>> 2] |= value& 0x15;
As I was about to push these patches also, I noticed this isn't
exactly setting the r/w bits. But it would work if the first line was
(~value) & 0x2a instead, should I fix it this way, am I looking at it
right?
Cheers
Re: [Qemu-devel] [RFC] vmstate: Add copyrights for all cpus
On 7 November 2011 18:38, Juan Quintela wrote: > This patch adds copyrights to all the machine description files for > all architectures supported. (this is done on top of my vmstate-cpus > series patches) The problem? > > - What should we put as "copyirght" owners. > > Althought I modified almost every line of the files, mostly of the > changes are a conversion, so claiming myself as the only "copyright" > owner sounds at least pretentious, and more than probably false. > > I tried to "dig" into the git logs and tried to came with "whoever" > commit the initial cpu_save/load foar each architecture. I have put > them as: > > * Based on qemu-file support done by: > * Richard Henderson > > But I would preffer that the persons involved state what copyright > notice they want, name, address, year(s), etc. (Some architectures > already have a propper copyright notice, I didn't touch them), and > others had an empty file (I put mine there on the previosu series). > > Several of the logs are from the svn days, and then I don't know if > the person was the committer, or the author. If anyone contributed > to the functionality and want to add its copyright, please told me. > > To make things more complicated, when machine.c files were split from > vl.c, they didn't carry any copyright notice at all, should we copy > back everything from vl.c? > > To make things more complicated, it looks like Thiemo Seufer did the > original mips support, and he passed away. So he can't obviously > comment. > > Anthony asked me to send a patch to the list, asking form comments. Acked-by: Andrzej Zaborowski Cheers
Re: [Qemu-devel] [PATCH v6 1/2] Add AACI audio playback support to the ARM Versatile/PB platform
On 28 October 2011 11:55, Peter Maydell wrote: > From: Mathieu Sonet > > This driver emulates the ARM AACI interface (PL041) connected to a LM4549 > codec. > It enables audio playback for the Versatile/PB platform. Thanks, pushed both changes. Cheers
Re: [Qemu-devel] [PULL v2 0/8] target-arm queue
On 20 October 2011 16:36, Peter Maydell wrote: > Hi; these are the pending target-arm patches I'd like to get in for 1.0; > a couple of minor ones plus the A15 insn work. Please pull. > > V2 of this pullreq just adds Andreas' trivial patch as 8/8, > so I haven't bothered re-emailing the identical 1-7, just this > cover letter and 8/8. I pulled all the patches, thanks. I haven't fully verified the softfloat code added, but I thought the fixes were important enough. Cheers
Re: [Qemu-devel] [PATCH V5] Add AACI audio playback support to the ARM Versatile/PB platform
Hi Mathieu,
On 18 October 2011 23:45, Mathieu Sonet wrote:
> This driver emulates the ARM AACI interface (PL041) connected to a LM4549
> codec.
> It enables audio playback for the Versatile/PB platform.
>
> Limitations:
> - Supports only a playback on one channel (Versatile/Vexpress)
> - Supports only one TX FIFO in compact-mode or non-compact mode.
> - Supports playback of 12, 16, 18 and 20 bits samples.
> - Record is not supported.
> - The PL041 is hardwired to a LM4549 codec.
>
> Versatile/PB test build:
> linux-2.6.38.5
> buildroot-2010.11
> alsa-lib-1.0.22
> alsa-utils-1.0.22
> mpg123-0.66
>
> Qemu host: Ubuntu 10.04 in Vmware/OS X
>
> Playback tested successfully with speaker-test/aplay/mpg123.
>
> Signed-off-by: Mathieu Sonet
> ---
> v4->v5
>
> * Move the lm4549 post_load hook in lm4549.c
> * Fix naked debug printf in lm4549.c
> * Clarify the size of the lm4549 audio buffer
>
> Makefile.target | 1 +
> hw/lm4549.c | 336
> hw/lm4549.h | 43
> hw/pl041.c | 636
> ++
> hw/pl041.h | 135
> hw/pl041.hx | 81 +++
> hw/versatilepb.c | 8 +
> 7 files changed, 1240 insertions(+), 0 deletions(-)
> create mode 100644 hw/lm4549.c
> create mode 100644 hw/lm4549.h
> create mode 100644 hw/pl041.c
> create mode 100644 hw/pl041.h
> create mode 100644 hw/pl041.hx
>
> diff --git a/Makefile.target b/Makefile.target
> index 417f23e..25b9fc1 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -355,6 +355,7 @@ obj-arm-y += syborg_virtio.o
> obj-arm-y += vexpress.o
> obj-arm-y += strongarm.o
> obj-arm-y += collie.o
> +obj-arm-y += pl041.o lm4549.o
>
> obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
> obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
> diff --git a/hw/lm4549.c b/hw/lm4549.c
> new file mode 100644
> index 000..4d5b831
> --- /dev/null
> +++ b/hw/lm4549.c
> @@ -0,0 +1,336 @@
> +/*
> + * LM4549 Audio Codec Interface
> + *
> + * Copyright (c) 2011
> + * Written by Mathieu Sonet - www.elasticsheep.com
> + *
> + * This code is licenced under the GPL.
> + *
> + * *
> + *
> + * This driver emulates the LM4549 codec.
> + *
> + * It supports only one playback voice and no record voice.
> + */
> +
> +#include "hw.h"
> +#include "audio/audio.h"
> +#include "lm4549.h"
> +
> +#if 0
> +#define LM4549_DEBUG 1
> +#endif
> +
> +#if 0
> +#define LM4549_DUMP_DAC_INPUT 1
> +#endif
> +
> +#ifdef LM4549_DEBUG
> +#define DPRINTF(fmt, ...) \
> +do { printf("lm4549: " fmt , ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) do {} while (0)
> +#endif
> +
> +#if defined(LM4549_DUMP_DAC_INPUT)
> +#include
> +static FILE *fp_dac_input;
> +#endif
> +
> +/* LM4549 register list */
> +enum {
> + LM4549_Reset = 0x00,
> + LM4549_Master_Volume = 0x02,
> + LM4549_Line_Out_Volume = 0x04,
> + LM4549_Master_Volume_Mono = 0x06,
> + LM4549_PC_Beep_Volume = 0x0A,
> + LM4549_Phone_Volume = 0x0C,
> + LM4549_Mic_Volume = 0x0E,
> + LM4549_Line_In_Volume = 0x10,
> + LM4549_CD_Volume = 0x12,
> + LM4549_Video_Volume = 0x14,
> + LM4549_Aux_Volume = 0x16,
> + LM4549_PCM_Out_Volume = 0x18,
> + LM4549_Record_Select = 0x1A,
> + LM4549_Record_Gain = 0x1C,
> + LM4549_General_Purpose = 0x20,
> + LM4549_3D_Control = 0x22,
> + LM4549_Powerdown_Ctrl_Stat = 0x26,
> + LM4549_Ext_Audio_ID = 0x28,
> + LM4549_Ext_Audio_Stat_Ctrl = 0x2A,
> + LM4549_PCM_Front_DAC_Rate = 0x2C,
> + LM4549_PCM_ADC_Rate = 0x32,
> + LM4549_Vendor_ID1 = 0x7C,
> + LM4549_Vendor_ID2 = 0x7E
> +};
> +
> +static void lm4549_reset(lm4549_state *s)
> +{
> + uint16_t *regfile = s->regfile;
> +
> + regfile[LM4549_Reset] = 0x0d50;
> + regfile[LM4549_Master_Volume] = 0x8008;
> + regfile[LM4549_Line_Out_Volume] = 0x8000;
> + regfile[LM4549_Master_Volume_Mono] = 0x8000;
> + regfile[LM4549_PC_Beep_Volume] = 0x;
> + regfile[LM4549_Phone_Volume] = 0x8008;
> + regfile[LM4549_Mic_Volume] = 0x8008;
> + regfile[LM4549_Line_In_Volume] = 0x8808;
> + regfile[LM4549_CD_Volume] = 0x8808;
> + regfile[LM4549_Video_Volume] = 0x8808;
> + regfile[LM4549_Aux_Volume] = 0x8808;
> + regfile[LM4549_PCM_Out_Volume] = 0x8808;
> + regfile[LM4549_Record_Select] = 0x;
> + regfile[LM4549_Record_Gain] = 0x8000;
> + regfile[LM4549_General_Purpose] = 0x;
> + regfile[LM4549_3D_Control] = 0x0101;
> + regfile[LM4549_Powerdown_Ctrl_Stat] = 0x000f;
> + regfile[LM4549_Ext_Audio
Re: [Qemu-devel] [PATCH] compatfd.c: Don't pass NULL pointer to SYS_signalfd
On 13 October 2011 19:45, Peter Maydell wrote: > Don't pass a NULL pointer in to SYS_signalfd in qemu_signalfd_available(): > this isn't valid and Valgrind complains about it. Also pushed this patch. Cheers
Re: [Qemu-devel] [PATCH] linux-user: Fix broken "-version" option
On 29 September 2011 16:48, Peter Maydell wrote: > Fix the "-version" option, which was accidentally broken in commit > fc9c541: > * exit after printing version information rather than proceeding > blithely onward (and likely printing the full usage message) > * correct the cut-n-paste error in the usage message for it > * don't insist on the presence of a following argument for > options which don't take an argument (this was preventing > 'qemu-arm -version' from working) > * remove a spurious argc check from the beginning of main() which > meant 'QEMU_VERSION=1 qemu-arm' didn't work. Thanks, I pushed this patch. Cheers
Re: [Qemu-devel] [PATCH] hw/omap2: Wire up the IRQ for the 2430's fifth GPIO module
On 18 October 2011 17:12, Peter Maydell wrote: > The OMAP2430 version of the omap-gpio device has five GPIO modules, > not four like the other OMAP2 versions; wire up the fifth module's > IRQ line correctly. Thanks, pushed this patch. Cheers
Re: [Qemu-devel] [PATCH] [v3] hw/arm_gic.c: Fix save/load of irq_target array
On 20 October 2011 12:48, Dmitry Koshelev wrote: > irq_target array saving/loading is in the wrong loop. > Version bump. > > Signed-off-by: Dmitry Koshelev Thanks, pushed this patch. Cheers
Re: [Qemu-devel] GPLv3 troubles
On 18 October 2011 15:03, Anthony Liguori wrote: > Okay, let's get serious about it. I set up the following wiki page for > coordination: > > http://wiki.qemu.org/Relicensing The bottom section with "some SVN authors" has a bunch of files by me that are "GPLv2". Most of them were probably meant to be GPLv2+ but the header had been copy&pasted. Where I'm the copyright owner I agree for them to be put under any later GPL version. Other SVN contributors need to be looked up in the svn commit messages. (that section's heading is missing a "not"?) Cheers
Re: [Qemu-devel] [PATCH 1/2] hw/omap_gpmc: Add comment about FIFOTHRESHOLDSTATUS bit
On 17 September 2011 20:51, Peter Maydell wrote: > Promote the remark about why we handle FIFOTHRESHOLDSTATUS the > way we do from the commit message of de8af7fe0 to a comment in > the code. Thanks, I applied both patches. Looks like any other related patches are waiting for other events. Cheers
Re: [Qemu-devel] [PATCH v2 09/18] omap_gpmc: Fix handling of FIFOTHRESHOLDSTATUS bit
On 28 August 2011 18:56, Peter Maydell wrote: > The OMAP3 TRM is inconsistent about whether the GPMC FIFOTHRESHOLDSTATUS > bit should be set when FIFOPOINTER > FIFOTHRESHOLD or when it is >= > FIFOTHRESHOLD. Apparently the underlying functional spec from which > the TRM was created states that the behaviour is ">=", and this also > makes more conceptual sense. It would be good to have a comment about this in the code. Cheers
Re: [Qemu-devel] [PATCH v2 07/18] omap_gpmc: GPMC_IRQSTATUS is write-one-to-clear
On 28 August 2011 18:56, Peter Maydell wrote: > Fix a bug in the handling of writes to GPMC_IRQSTATUS: > it behaves as "write one to clear, writing zero is ignored". > > Signed-off-by: Peter Maydell > --- > hw/omap_gpmc.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/hw/omap_gpmc.c b/hw/omap_gpmc.c > index d16b28b..ff4d485 100644 > --- a/hw/omap_gpmc.c > +++ b/hw/omap_gpmc.c > @@ -284,7 +284,7 @@ static void omap_gpmc_write(void *opaque, > target_phys_addr_t addr, > break; > > case 0x018: /* GPMC_IRQSTATUS */ > - s->irqen = ~value; > + s->irqen &= ~value; Should we be clearing s->irqst here instead of irqen? Good catch though. Cheers
Re: [Qemu-devel] [PATCH 1/2] omap_intc: Use MemoryRegion API
On 31 August 2011 17:55, Peter Maydell wrote:
> Convert omap_intc to use the MemoryRegion API
>
> Signed-off-by: Peter Maydell
> ---
> hw/omap_intc.c | 64 ++-
> 1 files changed, 30 insertions(+), 34 deletions(-)
>
> diff --git a/hw/omap_intc.c b/hw/omap_intc.c
> index f1f570e..38637c6 100644
> --- a/hw/omap_intc.c
> +++ b/hw/omap_intc.c
> @@ -19,6 +19,7 @@
> */
> #include "hw.h"
> #include "omap.h"
> +#include "exec-memory.h"
>
> /* Interrupt Handlers */
> struct omap_intr_handler_bank_s {
> @@ -34,6 +35,7 @@ struct omap_intr_handler_bank_s {
> struct omap_intr_handler_s {
> qemu_irq *pins;
> qemu_irq parent_intr[2];
> + MemoryRegion mmio;
> unsigned char nbanks;
> int level_only;
>
> @@ -142,7 +144,8 @@ static void omap_set_intr_noedge(void *opaque, int irq,
> int req)
> bank->irqs = (bank->inputs &= ~(1 << n)) | bank->swi;
> }
>
> -static uint32_t omap_inth_read(void *opaque, target_phys_addr_t addr)
> +static uint64_t omap_inth_read(void *opaque, target_phys_addr_t addr,
> + unsigned size)
> {
> struct omap_intr_handler_s *s = (struct omap_intr_handler_s *) opaque;
> int i, offset = addr;
> @@ -220,7 +223,7 @@ static uint32_t omap_inth_read(void *opaque,
> target_phys_addr_t addr)
> }
>
> static void omap_inth_write(void *opaque, target_phys_addr_t addr,
> - uint32_t value)
> + uint64_t value, unsigned size)
> {
> struct omap_intr_handler_s *s = (struct omap_intr_handler_s *) opaque;
> int i, offset = addr;
> @@ -312,16 +315,14 @@ static void omap_inth_write(void *opaque,
> target_phys_addr_t addr,
> OMAP_BAD_REG(addr);
> }
>
> -static CPUReadMemoryFunc * const omap_inth_readfn[] = {
> - omap_badwidth_read32,
> - omap_badwidth_read32,
> - omap_inth_read,
> -};
> -
> -static CPUWriteMemoryFunc * const omap_inth_writefn[] = {
> - omap_inth_write,
> - omap_inth_write,
> - omap_inth_write,
> +static const MemoryRegionOps omap_inth_mem_ops = {
> + .read = omap_inth_read,
> + .write = omap_inth_write,
> + .endianness = DEVICE_NATIVE_ENDIAN,
> + .valid = {
> + .min_access_size = 4,
> + .max_access_size = 4,
> + },
> };
>
> void omap_inth_reset(struct omap_intr_handler_s *s)
> @@ -356,7 +357,6 @@ struct omap_intr_handler_s
> *omap_inth_init(target_phys_addr_t base,
> unsigned long size, unsigned char nbanks, qemu_irq **pins,
> qemu_irq parent_irq, qemu_irq parent_fiq, omap_clk clk)
> {
> - int iomemtype;
> struct omap_intr_handler_s *s = (struct omap_intr_handler_s *)
> g_malloc0(sizeof(struct omap_intr_handler_s) +
> sizeof(struct omap_intr_handler_bank_s) * nbanks);
> @@ -368,16 +368,16 @@ struct omap_intr_handler_s
> *omap_inth_init(target_phys_addr_t base,
> if (pins)
> *pins = s->pins;
>
> - omap_inth_reset(s);
> + memory_region_init_io(&s->mmio, &omap_inth_mem_ops, s, "omap-intc",
> size);
> + memory_region_add_subregion(get_system_memory(), base, &s->mmio);
>
> - iomemtype = cpu_register_io_memory(omap_inth_readfn,
> - omap_inth_writefn, s, DEVICE_NATIVE_ENDIAN);
> - cpu_register_physical_memory(base, size, iomemtype);
> + omap_inth_reset(s);
>
> return s;
> }
>
> -static uint32_t omap2_inth_read(void *opaque, target_phys_addr_t addr)
> +static uint64_t omap2_inth_read(void *opaque, target_phys_addr_t addr,
> + unsigned size)
> {
> struct omap_intr_handler_s *s = (struct omap_intr_handler_s *) opaque;
> int offset = addr;
> @@ -455,7 +455,7 @@ static uint32_t omap2_inth_read(void *opaque,
> target_phys_addr_t addr)
> }
>
> static void omap2_inth_write(void *opaque, target_phys_addr_t addr,
> - uint32_t value)
> + uint64_t value, unsigned size)
> {
> struct omap_intr_handler_s *s = (struct omap_intr_handler_s *) opaque;
> int offset = addr;
> @@ -558,16 +558,14 @@ static void omap2_inth_write(void *opaque,
> target_phys_addr_t addr,
> OMAP_BAD_REG(addr);
> }
>
> -static CPUReadMemoryFunc * const omap2_inth_readfn[] = {
> - omap_badwidth_read32,
> - omap_badwidth_read32,
> - omap2_inth_read,
> -};
> -
> -static CPUWriteMemoryFunc * const omap2_inth_writefn[] = {
> - omap2_inth_write,
> - omap2_inth_write,
> - omap2_inth_write,
> +static const MemoryRegionOps omap2_inth_mem_ops = {
> + .read = omap2_inth_read,
> + .write = omap2_inth_write,
> + .endianness = DEVICE_NATIVE_ENDIAN,
> + .valid = {
> + .min_access_size = 4,
> + .max_access_size = 4,
> + },
> };
>
> struct omap_intr_handler_s *omap2_inth_init(target_phys_addr_t base,
> @@ -575,7 +573,6 @@ struct omap_intr_handler_s
> *omap2_inth_init(target_phys_addr_t base,
> qemu_irq parent_irq, qemu_irq parent_fiq,
>
