Shin-ichiro KAWASAKI | 1 Jan 07:59 2010
Picon

[PATCH] sh: sm501: Add hardware cursor feature

This patch adds hardware cursor feature to SM501 graphics chip emulation,
to make the graphic console more useful for QEMU SH4 users.

Signed-off-by: Shin-ichiro KAWASAKI <kawasaki <at> juno.dti.ne.jp>

 hw/sm501.c          |  154 +++++++++++++++++++++++++++++++++++++++++++++++----
 hw/sm501_template.h |   42 ++++++++++++++
 2 files changed, 185 insertions(+), 11 deletions(-)

diff --git a/hw/sm501.c b/hw/sm501.c
index 612a8e5..cd1f595 100644
--- a/hw/sm501.c
+++ b/hw/sm501.c
 <at>  <at>  -434,6 +434,8  <at>  <at> 

 /* end of register definitions */

+#define SM501_HWC_WIDTH                       (64)
+#define SM501_HWC_HEIGHT                      (64)

 /* SM501 local memory size taken from "linux/drivers/mfd/sm501.c" */
 static const uint32_t sm501_mem_local_size[] = {
 <at>  <at>  -526,6 +528,95  <at>  <at>  static uint32_t get_local_mem_size_index(uint32_t size)
     return index;
 }

+/**
+ * Check the availability of hardware cursor.
+ *  <at> param crt  0 for PANEL, 1 for CRT.
+ */
(Continue reading)

Gleb Natapov | 1 Jan 11:23 2010
Picon

Re: [PATCH] add "info ioapic" monitor command

On Thu, Dec 31, 2009 at 12:57:44PM -0600, Anthony Liguori wrote:
> On 12/31/2009 09:33 AM, Gleb Natapov wrote:
> >On Thu, Dec 31, 2009 at 08:15:29AM -0600, Anthony Liguori wrote:
> >>On 12/30/2009 06:16 PM, Gleb Natapov wrote:
> >>>It helps debug problems and it is not intrusive. Since 0.12 will be used
> >>>for a long time I want to add it there for convenience.
> >>
> >>stable is for bug fixes only.
> >>
> >This is to close minded. Not able to debug hard to reproduce problems when they appear
> >at the environment you can't replicate is a bug.
> 
> 
> Every feature is important to someone and there is at least someone
> who wants just about every feature backported to stable.
> 
Agree and that is why practical judgment is needed. Humans, not binary
algorithm decides what to port and what not too.

> Looking at this patch, it adds a new monitor command which
> potentially means that the QMP protocol is changing (as there is now
> a new command).  This is definitely not something we want to do in
> stable.
> 
Does QMP expose list of available command through QMP protocol? Because if
it is not, there is no such issues as you describe at all, but event if it
is isn't the goal of QMP to make handling of such cases transparent for
management software. There will be one more element returned in command
list that is all.

(Continue reading)

Gleb Natapov | 1 Jan 11:27 2010
Picon

Re: [PATCHv2] add "info ioapic" monitor command

On Thu, Dec 31, 2009 at 01:05:18PM -0600, Anthony Liguori wrote:
> On 12/31/2009 09:42 AM, Gleb Natapov wrote:
> >On Thu, Dec 31, 2009 at 08:20:06AM -0600, Anthony Liguori wrote:
> >>On 12/30/2009 06:20 PM, Gleb Natapov wrote:
> >>>I included only the state I need for debugging. I don't what to see
> >>>complete state. It will just clatter important info.
> >>
> >>Someone may find that full state useful though.  There's no good
> >>reason to not show the entire device's state.
> >>
> >There is no good reason to not show the entire device's state in
> >addition to nicely formated most useful part of it. Here I fixed it for
> >you.
> 
> 
> Have you even attempted to look at what the generic implementation
> would be? ioapic has three vmstate fields.  If you decode ioredtbl
> into six subfields, then you're only adding two addition fields to
> be printed.
> 
I you seriously suggesting that we should tie the way device state is
migrated to the way device information is printed? 

> I can't believe that having those two extra fields is really going
> to make it any more difficult to debug.
> 
Can't parse that.

> And being able to dump any device state is certainly going to be
> useful in the future.
(Continue reading)

Gleb Natapov | 1 Jan 11:37 2010
Picon

Re: [PATCH] add "info ioapic" monitor command

On Thu, Dec 31, 2009 at 01:01:50PM -0600, Anthony Liguori wrote:
> On 12/31/2009 09:39 AM, Gleb Natapov wrote:
> >>The common case is where you just want to see the state of the
> >>device. We support hundreds of devices.  We can have one code path
> >>that displays 95% of them with a couple devices that have exceptions
> >>or we could have hundreds of these commands that aren't consistent
> >>because they're all open-coded.
> >I am not against having common code path that prints out state of all
> >devices. It just different from what I am trying to achieve with my patch.
> >My patch adds parsing and pretty-printing of device state and that's the
> >part that is not addressed with your common code scenario.
> 
> A common device printing mechanism is probably no more code than
> your current patch.
> 
Have you looked at my patch at all? What part of it can be made generic
in your opinion? All it does is transforms ioapic state to human
readable way (and that requires device internals kwoulage) and pot it
into QObject form.

> My position is that if that generic mechanism is not good enough for
> you, then we should look at fixing that problem instead of
> introducing a completely redundant mechanism.
> 
Generic mechanism is by definition cannot decode device state with
knowledge of device specific details.

> Heck, even if you had a generic mechanism and then a big if in the
> middle of it that treated ioapic better than other devices, it would
> be 100x better than introducing a 1-off command.
(Continue reading)

Sébastien Bourdeauducq | 1 Jan 13:30 2010
Picon

LatticeMico32/Milkymist support

Hi,

Would anyone be interested in adding the support of the LatticeMico32 [1] 
microprocessor and the Milkymist System-on-Chip [2] to QEMU?

This would help the open source hardware movement by easing software 
development on free platforms. Currently, QEMU only supports proprietary 
systems.

Adding this support should be straightforward for anyone who has experience 
with the QEMU source code. LatticeMico32 is a fairly ordinary RISC processor 
(very similar to ARM or MIPS) and the Milkymist system-on-chip peripherals are 
made as simple as possible.

Sébastien

[1] http://www.milkymist.org/doc/lm32_archman.pdf
[2] http://www.milkymist.org/doc/paper_overview.pdf

Alexander Graf | 1 Jan 16:41 2010
Picon

[PATCH] PPC: Add wrapper for target long DCR operations

The recent transition to always have the DCR helper functions take 32 bit
values broke the PPC64 target, as tlong became 64 bits there.

This patch moves all translate.c callers to a _tl function that simply
calls the uint32_t functions. That way we don't need to mess with TCG
trying to pass registers as uint32_t variables to functions.

Fixes PPC64 build with --enable-debug-tcg

Signed-off-by: Alexander Graf <agraf <at> suse.de>
Reported-by: Stefan Weil <weil <at> mail.berlios.de>
---
 target-ppc/cpu.h       |    2 ++
 target-ppc/helper.h    |    4 ++--
 target-ppc/op_helper.c |   10 ++++++++++
 target-ppc/translate.c |   12 ++++++------
 4 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index d15bba1..60a8b68 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
 <at>  <at>  -733,6 +733,8  <at>  <at>  void ppc_store_slb (CPUPPCState *env, target_ulong rb, target_ulong rs);
 void ppc_store_sr (CPUPPCState *env, int srnum, target_ulong value);
 #endif /* !defined(CONFIG_USER_ONLY) */
 void ppc_store_msr (CPUPPCState *env, target_ulong value);
+void helper_store_dcr (uint32_t dcrn, uint32_t val);
+uint32_t helper_load_dcr (uint32_t dcrn);

 void ppc_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt, ...));
(Continue reading)

Kirill A. Shutemov | 2 Jan 03:06 2010

Re: [PATCH 14/14] Add -fstack-protector-all to CFLAGS

On Thu, Dec 31, 2009 at 12:58 PM, Arnaud Patard
<arnaud.patard <at> rtp-net.org> wrote:
> "Kirill A. Shutemov" <kirill <at> shutemov.name> writes:
> Hi,
>
>> -fstack-protector-all emit extra code to check for buffer overflows,
>> such as stack smashing attacks.  This is done by adding a guard
>> variable to functions with vulnerable objects.
>>
>> Signed-off-by: Kirill A. Shutemov <kirill <at> shutemov.name>
>> ---
>>  configure |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 0cdcdb3..16b70d8 100755
>> --- a/configure
>> +++ b/configure
>>  <at>  <at>  -98,6 +98,7  <at>  <at>  QEMU_CFLAGS="-Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes $
>>  QEMU_CFLAGS="-Wstrict-prototypes -Wredundant-decls $QEMU_CFLAGS"
>>  QEMU_CFLAGS="-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE $QEMU_CFLAGS"
>>  QEMU_CFLAGS="-D_FORTIFY_SOURCE=2 $QEMU_CFLAGS"
>> +QEMU_CFLAGS="-fstack-protector-all $QEMU_CFLAGS"
>
> afaik not all arches out there are supporting
> -fstack-protector-all (to be more precise, some have no stack protector
> support at all). iirc, gcc will emit a warning and still compile
> but would be nice to avoid a warning.

Thanks. Will be fixed.
(Continue reading)

Kirill A. Shutemov | 2 Jan 03:09 2010

Re: [PATCH 12/14] linux-user/mmap.c: fix warnings with _FORTIFY_SOURCE

On Thu, Dec 31, 2009 at 12:50 PM, Arnaud Patard
<arnaud.patard <at> rtp-net.org> wrote:
> "Kirill A. Shutemov" <kirill <at> shutemov.name> writes:
>
> Hi,
>
>>   CC    i386-linux-user/mmap.o
>> cc1: warnings being treated as errors
>> /usr/src/RPM/BUILD/qemu-0.11.92/linux-user/mmap.c: In function 'mmap_frag':
>> /usr/src/RPM/BUILD/qemu-0.11.92/linux-user/mmap.c:253: error: ignoring return value of
'pread', declared with attribute warn_unused_result
>> /usr/src/RPM/BUILD/qemu-0.11.92/linux-user/mmap.c: In function 'target_mmap':
>> /usr/src/RPM/BUILD/qemu-0.11.92/linux-user/mmap.c:477: error: ignoring return value of
'pread', declared with attribute warn_unused_result
>> make[1]: *** [mmap.o] Error 1
>>
>> Signed-off-by: Kirill A. Shutemov <kirill <at> shutemov.name>
>> ---
>>  linux-user/mmap.c |    6 ++++--
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/linux-user/mmap.c b/linux-user/mmap.c
>> index 144fb7c..e496c64 100644
>> --- a/linux-user/mmap.c
>> +++ b/linux-user/mmap.c
>>  <at>  <at>  -250,7 +250,8  <at>  <at>  static int mmap_frag(abi_ulong real_start,
>>              mprotect(host_start, qemu_host_page_size, prot1 | PROT_WRITE);
>>
>>          /* read the corresponding file data */
>> -        pread(fd, g2h(start), end - start, offset);
(Continue reading)

H. Peter Anvin | 2 Jan 04:01 2010

Re: [PATCH] debugcon: support for debugging consoles (e.g. Bochs port 0xe9)

On 12/30/2009 08:49 AM, Kevin O'Connor wrote:
> On Tue, Dec 29, 2009 at 01:51:36PM -0800, H. Peter Anvin wrote:
>> Add generic support for debugging consoles (simple I/O ports which
>> when written to cause debugging output to be written to a target.)
>> The current implementation matches Bochs' port 0xe9, allowing the same
>> debugging code to be used for both Bochs and Qemu.
>>
>> There is no vm state associated with the debugging port, simply
>> because it has none -- the entire interface is a single, stateless,
>> write-only port.
>>
>> Most of the code was cribbed from the serial port driver.
> 
> Hi,
> 
> SeaBIOS writes debugging info to port 0x0402.  Unfortunately, qemu has
> to be recompiled in order to display this info.  Will your patch
> enable one to get at the 0x0402 data without recompiling?
> 

Yes.

	-hpa

--

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

H. Peter Anvin | 2 Jan 04:02 2010

Re: [PATCH] debugcon: support for debugging consoles (e.g. Bochs port 0xe9)

On 12/30/2009 08:49 AM, Kevin O'Connor wrote:
> 
> Hi,
> 
> SeaBIOS writes debugging info to port 0x0402.  Unfortunately, qemu has
> to be recompiled in order to display this info.  Will your patch
> enable one to get at the 0x0402 data without recompiling?
> 
> -Kevin
> 

Incidentally, it's somewhat unusual choice of ports... port 0x80 is the
normal port for BIOSes to display debugging information on.

	-hpa

--

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


Gmane