Re: [Qemu-devel] [PATCH] slirp: Mark pieces missing IPv6 support

2019-03-02 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20190303060423.29356-1-samuel.thiba...@ens-lyon.org/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20190303060423.29356-1-samuel.thiba...@ens-lyon.org
Subject: [Qemu-devel] [PATCH] slirp: Mark pieces missing IPv6 support

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
2f7f53834f slirp: Mark pieces missing IPv6 support

=== OUTPUT BEGIN ===
ERROR: suspect code indent for conditional statements (8, 10)
#106: FILE: slirp/tcp_input.c:390:
 if (so == NULL) {
+  /* TODO: IPv6 */

total: 1 errors, 0 warnings, 99 lines checked

Commit 2f7f53834f83 (slirp: Mark pieces missing IPv6 support) has style 
problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190303060423.29356-1-samuel.thiba...@ens-lyon.org/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[Qemu-devel] [PATCH] slirp: Mark pieces missing IPv6 support

2019-03-02 Thread Samuel Thibault
Signed-off-by: Samuel Thibault 
---
 net/slirp.c   | 1 +
 slirp/misc.c  | 3 +++
 slirp/slirp.c | 5 +
 slirp/socket.c| 1 +
 slirp/tcp_input.c | 2 ++
 slirp/tcp_subr.c  | 2 ++
 slirp/udp.c   | 1 +
 7 files changed, 15 insertions(+)

diff --git a/net/slirp.c b/net/slirp.c
index 4ec989b592..a8fd9e6364 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -885,6 +885,7 @@ static ssize_t guestfwd_write(const void *buf, size_t len, 
void *chr)
 
 static int slirp_guestfwd(SlirpState *s, const char *config_str, Error **errp)
 {
+/* TODO: IPv6 */
 struct in_addr server = { .s_addr = 0 };
 struct GuestFwd *fwd;
 const char *p;
diff --git a/slirp/misc.c b/slirp/misc.c
index d9fc586a24..937a418d4e 100644
--- a/slirp/misc.c
+++ b/slirp/misc.c
@@ -28,6 +28,7 @@ remque(void *a)
   element->qh_rlink = NULL;
 }
 
+/* TODO: IPv6 */
 struct gfwd_list *
 add_guestfwd(struct gfwd_list **ex_ptr,
  SlirpWriteCb write_cb, void *opaque,
@@ -254,6 +255,8 @@ char *slirp_connection_info(Slirp *slirp)
 "  Protocol[State]FD  Source Address  Port   "
 "Dest. Address  Port RecvQ SendQ\n");
 
+/* TODO: IPv6 */
+
 for (so = slirp->tcb.so_next; so != >tcb; so = so->so_next) {
 if (so->so_state & SS_HOSTFWD) {
 state = "HOST_FORWARD";
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 55591430dc..cbdf9f778d 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -729,6 +729,7 @@ static void arp_input(Slirp *slirp, const uint8_t *pkt, int 
pkt_len)
 if (ah->ar_tip == slirp->vnameserver_addr.s_addr ||
 ah->ar_tip == slirp->vhost_addr.s_addr)
 goto arp_ok;
+/* TODO: IPv6 */
 for (ex_ptr = slirp->guestfwd_list; ex_ptr; ex_ptr = 
ex_ptr->ex_next) {
 if (ex_ptr->ex_addr.s_addr == ah->ar_tip)
 goto arp_ok;
@@ -945,6 +946,7 @@ int if_encap(Slirp *slirp, struct mbuf *ifm)
 }
 
 /* Drop host forwarding rule, return 0 if found. */
+/* TODO: IPv6 */
 int slirp_remove_hostfwd(Slirp *slirp, int is_udp, struct in_addr host_addr,
  int host_port)
 {
@@ -970,6 +972,7 @@ int slirp_remove_hostfwd(Slirp *slirp, int is_udp, struct 
in_addr host_addr,
 return -1;
 }
 
+/* TODO: IPv6 */
 int slirp_add_hostfwd(Slirp *slirp, int is_udp, struct in_addr host_addr,
   int host_port, struct in_addr guest_addr, int guest_port)
 {
@@ -988,6 +991,7 @@ int slirp_add_hostfwd(Slirp *slirp, int is_udp, struct 
in_addr host_addr,
 return 0;
 }
 
+/* TODO: IPv6 */
 static bool
 check_guestfwd(Slirp *slirp, struct in_addr *guest_addr, int guest_port)
 {
@@ -1065,6 +1069,7 @@ slirp_find_ctl_socket(Slirp *slirp, struct in_addr 
guest_addr, int guest_port)
 {
 struct socket *so;
 
+/* TODO: IPv6 */
 for (so = slirp->tcb.so_next; so != >tcb; so = so->so_next) {
 if (so->so_faddr.s_addr == guest_addr.s_addr &&
 htons(so->so_fport) == guest_port) {
diff --git a/slirp/socket.c b/slirp/socket.c
index 03266128b1..76ef0774f4 100644
--- a/slirp/socket.c
+++ b/slirp/socket.c
@@ -687,6 +687,7 @@ struct socket *
 tcp_listen(Slirp *slirp, uint32_t haddr, unsigned hport, uint32_t laddr,
unsigned lport, int flags)
 {
+/* TODO: IPv6 */
struct sockaddr_in addr;
struct socket *so;
int s, opt = 1;
diff --git a/slirp/tcp_input.c b/slirp/tcp_input.c
index 6749b32f5d..b10477fc57 100644
--- a/slirp/tcp_input.c
+++ b/slirp/tcp_input.c
@@ -388,6 +388,7 @@ findso:
 * as if it was LISTENING, and continue...
 */
 if (so == NULL) {
+  /* TODO: IPv6 */
   if (slirp->restricted) {
 /* Any hostfwds will have an existing socket, so we only get here
  * for non-hostfwd connections. These should be dropped, unless it
@@ -609,6 +610,7 @@ findso:
   * If this is destined for the control address, then flag to
   * tcp_ctl once connected, otherwise connect
   */
+  /* TODO: IPv6 */
  if (af == AF_INET &&
 (so->so_faddr.s_addr & slirp->vnetwork_mask.s_addr) ==
 slirp->vnetwork_addr.s_addr) {
diff --git a/slirp/tcp_subr.c b/slirp/tcp_subr.c
index 1d7e72dca7..1db59caa89 100644
--- a/slirp/tcp_subr.c
+++ b/slirp/tcp_subr.c
@@ -626,6 +626,7 @@ tcp_emu(struct socket *so, struct mbuf *m)
switch(so->so_emu) {
int x, i;
 
+/* TODO: IPv6 */
 case EMU_IDENT:
/*
 * Identification protocol as per rfc-1413
@@ -964,6 +965,7 @@ int tcp_ctl(struct socket *so)
 DEBUG_CALL("tcp_ctl");
 DEBUG_ARG("so = %p", so);
 
+/* TODO: IPv6 */
 if (so->so_faddr.s_addr != slirp->vhost_addr.s_addr) {
 /* Check if it's pty_exec */
 for (ex_ptr = slirp->guestfwd_list; ex_ptr; ex_ptr = ex_ptr->ex_next) {
diff --git a/slirp/udp.c b/slirp/udp.c
index 3d9a19b85a..fa9f4a08bd 100644
--- a/slirp/udp.c
+++ 

[Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

2019-03-02 Thread Samuel Thibault
By default, curses will only report single ESC key event after 1s delay,
since ESC is also used for keypad escape sequences. This however makes users
believe that ESC is not working. Reducing to 0.2s provides good enough user
experience, while still allowing 200ms for keypad sequences to get in, which
should be more than enough.

Signed-off-by: Samuel Thibault 
---
 ui/curses.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ui/curses.c b/ui/curses.c
index 6e0091c3b2..700315bc09 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -231,7 +231,7 @@ static void curses_refresh(DisplayChangeListener *dcl)
 keycode = curses2keycode[chr];
 keycode_alt = 0;
 
-/* alt key */
+/* alt or esc key */
 if (keycode == 1) {
 int nextchr = getch();
 
@@ -361,6 +361,7 @@ static void curses_setup(void)
 initscr(); noecho(); intrflush(stdscr, FALSE);
 nodelay(stdscr, TRUE); nonl(); keypad(stdscr, TRUE);
 start_color(); raw(); scrollok(stdscr, FALSE);
+set_escdelay(200);
 
 /* Make color pair to match color format (3bits bg:3bits fg) */
 for (i = 0; i < 64; i++) {
-- 
2.20.1




Re: [Qemu-devel] [PATCH v4] hw/display: Add basic ATI VGA emulation

2019-03-02 Thread Philippe Mathieu-Daudé
Hi Zoltan,

On 3/3/19 12:34 AM, BALATON Zoltan wrote:
> At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
> gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
> guests running on these and the PMON2000 firmware of the fulong2e
> expect this to be available. Fortunately these are very similar chips
> so they can be mostly emulated in the same device model. This patch
> adds basic emulation of these ATI VGA chips.
> 
> While this is incomplete and currently only enough to run the MIPS
> firmware and get framebuffer output with Linux, it allows the fulong2e
> board to work more like the real hardware and having it in QEMU in
> this state provides a way to experiment with it and allows others to
> contribute to improve it. It is compiled for all archs but only the
> fulong2e (which currently has no display output at all) is set to use
> it by default (in a patch sent separately).

Patch looks good, trivial comment inlined.

> 
> Signed-off-by: BALATON Zoltan 
> ---
> v4:
> - fix mingw build (from Gerd)
> - set dev_id in realize to allow pci_patch_ids to change bios rom
> - add model aliases to select device variant by name instead of id
> - misc mode switch and 2d fixes (better but still not quite right)
> 
> v3:
> - add to default-configs/pci.mak instead of mips64el and ppc only
> - rename device_id property to x-device-id
> - use extract32/deposit32 in *_offs functions
> - add ati-vga to vl.c default_list[]
> 
> v2:
> - Extended debug logs
> - Fix mode switching and some registers
> - Fixes to 2D functions
> 
>  default-configs/pci.mak  |   1 +
>  hw/display/Makefile.objs |   2 +
>  hw/display/ati.c | 686 
> +++
>  hw/display/ati_2d.c  | 134 +
>  hw/display/ati_dbg.c | 254 ++
>  hw/display/ati_int.h |  87 ++
>  hw/display/ati_regs.h| 456 +++

Please have a look at scripts/git.orderfile :)

>  hw/display/trace-events  |   4 +
>  vl.c |   1 +
>  9 files changed, 1625 insertions(+)
>  create mode 100644 hw/display/ati.c
>  create mode 100644 hw/display/ati_2d.c
>  create mode 100644 hw/display/ati_dbg.c
>  create mode 100644 hw/display/ati_int.h
>  create mode 100644 hw/display/ati_regs.h
> 
> diff --git a/default-configs/pci.mak b/default-configs/pci.mak
> index 037636fa33..e59e2fa7b6 100644
> --- a/default-configs/pci.mak
> +++ b/default-configs/pci.mak
> @@ -49,3 +49,4 @@ CONFIG_IVSHMEM_DEVICE=$(CONFIG_IVSHMEM)
>  CONFIG_ROCKER=y
>  CONFIG_VFIO=$(CONFIG_LINUX)
>  CONFIG_VFIO_PCI=y
> +CONFIG_ATI_VGA=y
> diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
> index 7c4ae9a0fd..963c23f3c8 100644
> --- a/hw/display/Makefile.objs
> +++ b/hw/display/Makefile.objs
> @@ -53,3 +53,5 @@ virtio-gpu-3d.o-cflags := $(VIRGL_CFLAGS)
>  virtio-gpu-3d.o-libs += $(VIRGL_LIBS)
>  obj-$(CONFIG_DPCD) += dpcd.o
>  obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx_dp.o
> +
> +obj-$(CONFIG_ATI_VGA) += ati.o ati_2d.o ati_dbg.o
> diff --git a/hw/display/ati.c b/hw/display/ati.c
> new file mode 100644
> index 00..72dd9b4953
> --- /dev/null
> +++ b/hw/display/ati.c
> @@ -0,0 +1,686 @@
> +/*
> + * QEMU ATI SVGA emulation
> + *
> + * Copyright (c) 2019 BALATON Zoltan
> + *
> + * This work is licensed under the GNU GPL license version 2 or later.
> + */
> +
> +/*
> + * WARNING:
> + * This is very incomplete and only enough for Linux console and some
> + * unaccelerated X output at the moment.
> + * Currently it's little more than a frame buffer with minimal functions,
> + * other more advanced features of the hardware are yet to be implemented.
> + * We only aim for Rage 128 Pro (and some RV100) and 2D only at first,
> + * No 3D at all yet (maybe after 2D works, but feel free to improve it)
> + */
> +
> +#include "ati_int.h"
> +#include "ati_regs.h"
> +#include "vga_regs.h"
> +#include "qemu/log.h"
> +#include "qemu/error-report.h"
> +#include "qapi/error.h"
> +#include "hw/hw.h"
> +#include "ui/console.h"
> +#include "trace.h"
> +
> +static struct {

static 'const' struct {

> +const char *name;
> +uint16_t dev_id;
> +} ati_model_aliases[] = {
> +{ "rage128p", PCI_DEVICE_ID_ATI_RAGE128_PF },
> +{ "rv100", PCI_DEVICE_ID_ATI_RADEON_QY },
> +};
> +
> +enum { VGA_MODE, EXT_MODE };
> +
> +static void ati_vga_switch_mode(ATIVGAState *s)
> +{
> +DPRINTF("%d -> %d\n",
> +s->mode, !!(s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN));
> +if (s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN) {
> +/* Extended mode enabled */
> +s->mode = EXT_MODE;
> +if (s->regs.crtc_gen_cntl & CRTC2_EN) {
> +/* CRT controller enabled, use CRTC values */
> +uint32_t offs = s->regs.crtc_offset & 0x07ff;
> +int stride = (s->regs.crtc_pitch & 0x7ff) * 8;
> +int bpp = 0;
> +int h, v;
> +
> +if (s->regs.crtc_h_total_disp == 0) {
> +

Re: [Qemu-devel] [PATCH 2/2] util/error: Remove unnecessary saved_errno

2019-03-02 Thread Philippe Mathieu-Daudé
On 3/3/19 2:12 AM, Eric Blake wrote:
> On 3/2/19 4:38 PM, Philippe Mathieu-Daudé wrote:
>> Since 552375088a8, error_set_errno() calls error_setv() which
>> already protect errno for clobbering.
>> Remove the now unnecessary saved_errno.
>>
>> Suggested-by: Thomas Huth 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  util/error.c | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/util/error.c b/util/error.c
>> index 934a78e1b1..0402fa1b9d 100644
>> --- a/util/error.c
>> +++ b/util/error.c
>> @@ -101,14 +101,11 @@ void error_setg_errno_internal(Error **errp,
>> int os_errno, const char *fmt, ...)
>>  {
>>  va_list ap;
>> -int saved_errno = errno;
>>  
>>  va_start(ap, fmt);
>>  error_setv(errp, src, line, func, ERROR_CLASS_GENERIC_ERROR, fmt, ap,
>> os_errno != 0 ? strerror(os_errno) : NULL);
>>  va_end(ap);
>> -
>> -errno = saved_errno;
> 
> NACK. strerror() can clobber errno, so you still need to restore
> saved_errno, regardless of what error_setv() does internally.

Oops, I thought only strerror_r() would change errno, but checking the
man page I now see you are right:

  POSIX.1-2001 and POSIX.1-2008 require that a successful call to
  strerror() or strerror_l() shall leave errno unchanged, and note
  that, since no function return value is reserved to indicate an
  error, an application that wishes to check for errors should
  initialize errno to zero before the call, and then check errno
  after the call.

Thanks for catching that!

Phil.



Re: [Qemu-devel] [PATCH 2/2] util/error: Remove unnecessary saved_errno

2019-03-02 Thread Eric Blake
On 3/2/19 4:38 PM, Philippe Mathieu-Daudé wrote:
> Since 552375088a8, error_set_errno() calls error_setv() which
> already protect errno for clobbering.
> Remove the now unnecessary saved_errno.
> 
> Suggested-by: Thomas Huth 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  util/error.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/util/error.c b/util/error.c
> index 934a78e1b1..0402fa1b9d 100644
> --- a/util/error.c
> +++ b/util/error.c
> @@ -101,14 +101,11 @@ void error_setg_errno_internal(Error **errp,
> int os_errno, const char *fmt, ...)
>  {
>  va_list ap;
> -int saved_errno = errno;
>  
>  va_start(ap, fmt);
>  error_setv(errp, src, line, func, ERROR_CLASS_GENERIC_ERROR, fmt, ap,
> os_errno != 0 ? strerror(os_errno) : NULL);
>  va_end(ap);
> -
> -errno = saved_errno;

NACK. strerror() can clobber errno, so you still need to restore
saved_errno, regardless of what error_setv() does internally.
-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



Re: [Qemu-devel] [Qemu-ppc] Forward-porting RTC device for eppc500 ?

2019-03-02 Thread Andrew Randrianasulu
В сообщении от Sunday 03 March 2019 03:17:47 BALATON Zoltan написал(а):
> On Sun, 3 Mar 2019, Andrew Randrianasulu wrote:
> > git commit -a --author="Amit Singh Tomar "
> > git format-patch -s 20b084c4b1401b7f8fbc385649d48c67b6f43d44
> >
> > scripts/checkpatch.pl
> > 0001-Re-applying-Freescale-PPC-E500-i2c-RTC-patch.patch
> >
> > After this I created new message in Kmail and inserted 0001 file, edited
> > it a bit more (adding patchwork link and mentioning fact I actually
> > boot-tested patch), and then send out.
>
> When sending patches to list make sure your mailer sends them as plain
> text and does not try to break up lines or alter white space because that
> breaks the patch and it won't apply with git am. You can check it in
> patchew (linked from SubmitAPatch wiki page):
>
> https://patchew.org/QEMU/201903030021.22070.randrianas...@gmail.com/
>
> Not sure if Kmail can do this, maybe it has some settings for this but
> it's usually better to do all editing on the git commit and send patch
> mails with git send-email.

I see, it failed to apply. Will try to convince git send-mail to work (last 
time 
it failed for me, but it was long time ago)

>
> > Guess next time I better to add second "-s" to git format-patch, so first
> > signed-off-by-line from original will be around too?
> >
> > Or ..lets wait what actual maintainers will say.
>
> Yes, I'll let actual maintainers to comment then you can do a corrected
> version with any requested fixes or Reviewed-by tags added. I think for
> next revision you should leave original author's Signed-off-by in commit
> message and add yours with -s after that. (When sending another version of
> a patch use -v2 option of git format-patch to add v2 to the patch
> subject and so on for higher revisions if needed.)

Thanks.


>
> Regards,
> BALATON Zoltan





Re: [Qemu-devel] [Qemu-ppc] Forward-porting RTC device for eppc500 ?

2019-03-02 Thread BALATON Zoltan

On Sun, 3 Mar 2019, Andrew Randrianasulu wrote:

git commit -a --author="Amit Singh Tomar "
git format-patch -s 20b084c4b1401b7f8fbc385649d48c67b6f43d44

scripts/checkpatch.pl 0001-Re-applying-Freescale-PPC-E500-i2c-RTC-patch.patch

After this I created new message in Kmail and inserted 0001 file, edited it a
bit more (adding patchwork link and mentioning fact I actually boot-tested
patch), and then send out.


When sending patches to list make sure your mailer sends them as plain 
text and does not try to break up lines or alter white space because that 
breaks the patch and it won't apply with git am. You can check it in 
patchew (linked from SubmitAPatch wiki page):


https://patchew.org/QEMU/201903030021.22070.randrianas...@gmail.com/

Not sure if Kmail can do this, maybe it has some settings for this but 
it's usually better to do all editing on the git commit and send patch 
mails with git send-email.



Guess next time I better to add second "-s" to git format-patch, so first
signed-off-by-line from original will be around too?

Or ..lets wait what actual maintainers will say.


Yes, I'll let actual maintainers to comment then you can do a corrected 
version with any requested fixes or Reviewed-by tags added. I think for 
next revision you should leave original author's Signed-off-by in commit 
message and add yours with -s after that. (When sending another version of 
a patch use -v2 option of git format-patch to add v2 to the patch 
subject and so on for higher revisions if needed.)


Regards,
BALATON Zoltan



[Qemu-devel] [PATCH v4] hw/display: Add basic ATI VGA emulation

2019-03-02 Thread BALATON Zoltan
At least two machines, the PPC mac99 and MIPS fulong2e, have an ATI
gfx chip by default (Rage 128 Pro and M6/RV100 respectively) and
guests running on these and the PMON2000 firmware of the fulong2e
expect this to be available. Fortunately these are very similar chips
so they can be mostly emulated in the same device model. This patch
adds basic emulation of these ATI VGA chips.

While this is incomplete and currently only enough to run the MIPS
firmware and get framebuffer output with Linux, it allows the fulong2e
board to work more like the real hardware and having it in QEMU in
this state provides a way to experiment with it and allows others to
contribute to improve it. It is compiled for all archs but only the
fulong2e (which currently has no display output at all) is set to use
it by default (in a patch sent separately).

Signed-off-by: BALATON Zoltan 
---
v4:
- fix mingw build (from Gerd)
- set dev_id in realize to allow pci_patch_ids to change bios rom
- add model aliases to select device variant by name instead of id
- misc mode switch and 2d fixes (better but still not quite right)

v3:
- add to default-configs/pci.mak instead of mips64el and ppc only
- rename device_id property to x-device-id
- use extract32/deposit32 in *_offs functions
- add ati-vga to vl.c default_list[]

v2:
- Extended debug logs
- Fix mode switching and some registers
- Fixes to 2D functions

 default-configs/pci.mak  |   1 +
 hw/display/Makefile.objs |   2 +
 hw/display/ati.c | 686 +++
 hw/display/ati_2d.c  | 134 +
 hw/display/ati_dbg.c | 254 ++
 hw/display/ati_int.h |  87 ++
 hw/display/ati_regs.h| 456 +++
 hw/display/trace-events  |   4 +
 vl.c |   1 +
 9 files changed, 1625 insertions(+)
 create mode 100644 hw/display/ati.c
 create mode 100644 hw/display/ati_2d.c
 create mode 100644 hw/display/ati_dbg.c
 create mode 100644 hw/display/ati_int.h
 create mode 100644 hw/display/ati_regs.h

diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index 037636fa33..e59e2fa7b6 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -49,3 +49,4 @@ CONFIG_IVSHMEM_DEVICE=$(CONFIG_IVSHMEM)
 CONFIG_ROCKER=y
 CONFIG_VFIO=$(CONFIG_LINUX)
 CONFIG_VFIO_PCI=y
+CONFIG_ATI_VGA=y
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 7c4ae9a0fd..963c23f3c8 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -53,3 +53,5 @@ virtio-gpu-3d.o-cflags := $(VIRGL_CFLAGS)
 virtio-gpu-3d.o-libs += $(VIRGL_LIBS)
 obj-$(CONFIG_DPCD) += dpcd.o
 obj-$(CONFIG_XLNX_ZYNQMP_ARM) += xlnx_dp.o
+
+obj-$(CONFIG_ATI_VGA) += ati.o ati_2d.o ati_dbg.o
diff --git a/hw/display/ati.c b/hw/display/ati.c
new file mode 100644
index 00..72dd9b4953
--- /dev/null
+++ b/hw/display/ati.c
@@ -0,0 +1,686 @@
+/*
+ * QEMU ATI SVGA emulation
+ *
+ * Copyright (c) 2019 BALATON Zoltan
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ */
+
+/*
+ * WARNING:
+ * This is very incomplete and only enough for Linux console and some
+ * unaccelerated X output at the moment.
+ * Currently it's little more than a frame buffer with minimal functions,
+ * other more advanced features of the hardware are yet to be implemented.
+ * We only aim for Rage 128 Pro (and some RV100) and 2D only at first,
+ * No 3D at all yet (maybe after 2D works, but feel free to improve it)
+ */
+
+#include "ati_int.h"
+#include "ati_regs.h"
+#include "vga_regs.h"
+#include "qemu/log.h"
+#include "qemu/error-report.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "ui/console.h"
+#include "trace.h"
+
+static struct {
+const char *name;
+uint16_t dev_id;
+} ati_model_aliases[] = {
+{ "rage128p", PCI_DEVICE_ID_ATI_RAGE128_PF },
+{ "rv100", PCI_DEVICE_ID_ATI_RADEON_QY },
+};
+
+enum { VGA_MODE, EXT_MODE };
+
+static void ati_vga_switch_mode(ATIVGAState *s)
+{
+DPRINTF("%d -> %d\n",
+s->mode, !!(s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN));
+if (s->regs.crtc_gen_cntl & CRTC2_EXT_DISP_EN) {
+/* Extended mode enabled */
+s->mode = EXT_MODE;
+if (s->regs.crtc_gen_cntl & CRTC2_EN) {
+/* CRT controller enabled, use CRTC values */
+uint32_t offs = s->regs.crtc_offset & 0x07ff;
+int stride = (s->regs.crtc_pitch & 0x7ff) * 8;
+int bpp = 0;
+int h, v;
+
+if (s->regs.crtc_h_total_disp == 0) {
+s->regs.crtc_h_total_disp = ((640 / 8) - 1) << 16;
+}
+if (s->regs.crtc_v_total_disp == 0) {
+s->regs.crtc_v_total_disp = (480 - 1) << 16;
+}
+h = ((s->regs.crtc_h_total_disp >> 16) + 1) * 8;
+v = (s->regs.crtc_v_total_disp >> 16) + 1;
+switch (s->regs.crtc_gen_cntl & CRTC_PIX_WIDTH_MASK) {
+case CRTC_PIX_WIDTH_4BPP:
+bpp = 4;
+

Re: [Qemu-devel] [PATCH] slirp: check sscanf result when emulating ident

2019-03-02 Thread William Bowling
Hi Phil,

William: How did you notice that? Using a static analyzer?


It was while looking into a previous CVE in tcp_emu, just with a manual
code review.

We have a data leak, Cc'ing qemu-stable.
> (Adding the address I noticed you Cc'ed secal...@redhat.com, so that
> confirms my guess).


Yeah the report and patch went via the security list initially due to the
info leak.

Cheers,
Will

On Sun, Mar 3, 2019 at 4:42 AM Philippe Mathieu-Daudé 
wrote:

> Hi William, Samuel,
>
> On 3/1/19 10:45 PM, William Bowling wrote:
> > When emulating ident in tcp_emu, if the strchr checks passed but the
> > sscanf check failed, two uninitialized variables would be copied and
> > sent in the reply.
>
> William: How did you notice that? Using a static analyzer?
>
> Samuel: since this diff is not obvious without looking at the context
> (also due to the code re-indent), can you improve the commit
> description, such (or better):
>
> "Move this code inside the if(sscanf()) clause".
>
> We have a data leak, Cc'ing qemu-stable.
> (Adding the address I noticed you Cc'ed secal...@redhat.com, so that
> confirms my guess).
>
> >
> > Signed-off-by: William Bowling 
>
> Reviewed-by: Philippe Mathieu-Daudé 
>
> Thanks,
>
> Phil.
>
> > ---
> >  slirp/tcp_subr.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/slirp/tcp_subr.c b/slirp/tcp_subr.c
> > index 262a42d6c8..73a160ba16 100644
> > --- a/slirp/tcp_subr.c
> > +++ b/slirp/tcp_subr.c
> > @@ -664,12 +664,12 @@ tcp_emu(struct socket *so, struct mbuf *m)
> >   break;
> >   }
> >   }
> > - }
> > -so_rcv->sb_cc =
> snprintf(so_rcv->sb_data,
> > -
>  so_rcv->sb_datalen,
> > - "%d,%d\r\n",
> n1, n2);
> > - so_rcv->sb_rptr = so_rcv->sb_data;
> > - so_rcv->sb_wptr = so_rcv->sb_data +
> so_rcv->sb_cc;
> > +so_rcv->sb_cc = snprintf(so_rcv->sb_data,
> > + so_rcv->sb_datalen,
> > + "%d,%d\r\n", n1, n2);
> > +so_rcv->sb_rptr = so_rcv->sb_data;
> > +so_rcv->sb_wptr = so_rcv->sb_data + so_rcv->sb_cc;
> > +}
> >   }
> >   m_free(m);
> >   return 0;
> >
>


-- 

GPG Key ID: 0x980F711A

GPG Key Fingerprint: AA38 2A0E 7D22 18A9 6086  0289 41DC E04B 980F 711A


Re: [Qemu-devel] [PATCH v6 40/73] i386/kvm: convert to cpu_interrupt_request

2019-03-02 Thread Emilio G. Cota
On Fri, Feb 08, 2019 at 11:15:27 +, Alex Bennée wrote:
> 
> Emilio G. Cota  writes:
> 
> > Reviewed-by: Richard Henderson 
> > Signed-off-by: Emilio G. Cota 
> > ---
> >  target/i386/kvm.c | 54 +++
> >  1 file changed, 31 insertions(+), 23 deletions(-)
> >
> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> > index ca2629f0fe..3f3c670897 100644
> > --- a/target/i386/kvm.c
> > +++ b/target/i386/kvm.c
> 
> > @@ -3183,14 +3186,14 @@ void kvm_arch_pre_run(CPUState *cpu, struct kvm_run 
> > *run)
> >  {
> >  X86CPU *x86_cpu = X86_CPU(cpu);
> >  CPUX86State *env = _cpu->env;
> > +uint32_t interrupt_request;
> >  int ret;
> >
> > +interrupt_request = cpu_interrupt_request(cpu);
> >  /* Inject NMI */
> > -if (cpu->interrupt_request & (CPU_INTERRUPT_NMI | CPU_INTERRUPT_SMI)) {
> > -if (cpu->interrupt_request & CPU_INTERRUPT_NMI) {
> > -qemu_mutex_lock_iothread();
> > +if (interrupt_request & (CPU_INTERRUPT_NMI | CPU_INTERRUPT_SMI)) {
> > +if (interrupt_request & CPU_INTERRUPT_NMI) {
> >  cpu_reset_interrupt(cpu, CPU_INTERRUPT_NMI);
> > -qemu_mutex_unlock_iothread();
> >  DPRINTF("injected NMI\n");
> >  ret = kvm_vcpu_ioctl(cpu, KVM_NMI);
> >  if (ret < 0) {
> > @@ -3198,10 +3201,8 @@ void kvm_arch_pre_run(CPUState *cpu, struct kvm_run 
> > *run)
> >  strerror(-ret));
> >  }
> >  }
> > -if (cpu->interrupt_request & CPU_INTERRUPT_SMI) {
> > -qemu_mutex_lock_iothread();
> > +if (interrupt_request & CPU_INTERRUPT_SMI) {
> >  cpu_reset_interrupt(cpu, CPU_INTERRUPT_SMI);
> > -qemu_mutex_unlock_iothread();
> >  DPRINTF("injected SMI\n");
> >  ret = kvm_vcpu_ioctl(cpu, KVM_SMI);
> >  if (ret < 0) {
> > @@ -3215,16 +3216,18 @@ void kvm_arch_pre_run(CPUState *cpu, struct kvm_run 
> > *run)
> >  qemu_mutex_lock_iothread();
> >  }
> >
> > +interrupt_request = cpu_interrupt_request(cpu);
> > +
> 
> This seems a bit smelly as we have already read interrupt_request once
> before. So this says that something may have triggered an IRQ while we
> were dealing with the above. It requires a comment at least.

There are a few cpu_reset_interrupt() calls above, so I thought a comment
wasn't necessary. I've added the following comment:

+/*
+ * We might have cleared some bits in cpu->interrupt_request since reading
+ * it; read it again.
+ */
 interrupt_request = cpu_interrupt_request(cpu);

> Otherwise:
> 
> Reviewed-by: Alex Bennée 

Thanks,

E.



Re: [Qemu-devel] [PATCH v6 39/73] i386: convert to cpu_interrupt_request

2019-03-02 Thread Emilio G. Cota
On Fri, Feb 08, 2019 at 11:00:23 +, Alex Bennée wrote:
> 
> Emilio G. Cota  writes:
> 
> > Reviewed-by: Richard Henderson 
> > Signed-off-by: Emilio G. Cota 
> > ---
> >  target/i386/cpu.c| 2 +-
> >  target/i386/helper.c | 4 ++--
> >  target/i386/svm_helper.c | 4 ++--
> >  3 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index a37b984b61..35dea8c152 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -5678,7 +5678,7 @@ int x86_cpu_pending_interrupt(CPUState *cs, int 
> > interrupt_request)
> >
> >  static bool x86_cpu_has_work(CPUState *cs)
> >  {
> > -return x86_cpu_pending_interrupt(cs, cs->interrupt_request) != 0;
> > +return x86_cpu_pending_interrupt(cs, cpu_interrupt_request(cs))
> >  != 0;
> 
> This is fine in itself but is there a chance of a race with the
> env->eflags/hflags/hflags2 that x86_cpu_pending_interrupt deals with?
> Are they only ever self vCPU references?

AFAICT they're all self-references; I have checked this via inspection
and with helgrind.

> Anyway:
> Reviewed-by: Alex Bennée 

Thanks!

E.



[Qemu-devel] [PATCH 2/2] util/error: Remove unnecessary saved_errno

2019-03-02 Thread Philippe Mathieu-Daudé
Since 552375088a8, error_set_errno() calls error_setv() which
already protect errno for clobbering.
Remove the now unnecessary saved_errno.

Suggested-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 util/error.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/util/error.c b/util/error.c
index 934a78e1b1..0402fa1b9d 100644
--- a/util/error.c
+++ b/util/error.c
@@ -101,14 +101,11 @@ void error_setg_errno_internal(Error **errp,
int os_errno, const char *fmt, ...)
 {
 va_list ap;
-int saved_errno = errno;
 
 va_start(ap, fmt);
 error_setv(errp, src, line, func, ERROR_CLASS_GENERIC_ERROR, fmt, ap,
os_errno != 0 ? strerror(os_errno) : NULL);
 va_end(ap);
-
-errno = saved_errno;
 }
 
 void error_setg_file_open_internal(Error **errp,
-- 
2.20.1




[Qemu-devel] [PATCH 0/2] util/error: Trivial cleanup

2019-03-02 Thread Philippe Mathieu-Daudé
Trivial cleanups suggested by Daniel and Thomas.

Philippe Mathieu-Daudé (2):
  util/error: Remove an unnecessary NULL check
  util/error: Remove unnecessary saved_errno

 util/error.c | 7 ---
 1 file changed, 7 deletions(-)

-- 
2.20.1




[Qemu-devel] [PATCH 1/2] util/error: Remove an unnecessary NULL check

2019-03-02 Thread Philippe Mathieu-Daudé
This NULL check was required while introduced in 680d16dcb79f.
Later refactor added a NULL check in error_setv(), so this check
is now redundant.

Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Markus Armbruster 
Signed-off-by: Philippe Mathieu-Daudé 
---
 util/error.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/util/error.c b/util/error.c
index b5ccbd8eac..934a78e1b1 100644
--- a/util/error.c
+++ b/util/error.c
@@ -103,10 +103,6 @@ void error_setg_errno_internal(Error **errp,
 va_list ap;
 int saved_errno = errno;
 
-if (errp == NULL) {
-return;
-}
-
 va_start(ap, fmt);
 error_setv(errp, src, line, func, ERROR_CLASS_GENERIC_ERROR, fmt, ap,
os_errno != 0 ? strerror(os_errno) : NULL);
-- 
2.20.1




Re: [Qemu-devel] [Bug 1818367] [NEW] Initialization of device cfi.pflash01 failed: Block node is read-only

2019-03-02 Thread Philippe Mathieu-Daudé
Hi José,

On 3/2/19 10:35 PM, José Pekkarinen wrote:
> Public bug reported:
> 
> Hi,
> 
> I have several vms defined in libvirt using ovmf for uefi, since a later
> update of my server I'm unable to start any of the domains defined. This is

This looks more like a libvirt issue than a QEMU one.

> an example of the output given:
> 
> # virsh start os-1
> error: Failed to start domain os-1
> error: internal error: qemu unexpectedly closed the monitor: 
> 2019-03-02T21:23:51.726446Z qemu-system-x86_64: Initialization of device 
> cfi.pflash01 failed: Block node is read-only
> 
> an example of domain is like this:
> 
>
>   
>   
>  
>   os-1   
>   
>   
>  
>   34c41008-ab91-483b-959c-81a7a12ae9be   
>   
>   
>  
>   8388608 
>   
>   
>  
>   8388608   
>   
>   
>  
>
>   
>   
>  
>   
>   
>   
>  
>   
>   
>   
>  
>   4  
>   
>   
>  
>   
>   
>   
>  
> hvm   
>   
>   
>  
> /var/lib/libvirt/qemu/nvram/os-1-ovmf.fd   
>   
>   
>  

This is the copy of your OVMF_VARS pflash, I can't find where this file
load the OVMF_CODE pflash.

>  
>   
>   
>  
>   
>   
>   
>  
>  
>   
>   
>  
> 
>   
>   
>  
>
>   

[Qemu-devel] [PATCH] BootLinuxConsoleTest: Let extract_from_deb handle various compressions

2019-03-02 Thread Philippe Mathieu-Daudé
Debian binary package format supports various compressions.

Per man deb(5):

  NAME
deb - Debian binary package format

  FORMAT
...
The third, last required member is named data.tar.  It contains the
filesystem as a tar archive, either not compressed (supported since
dpkg 1.10.24), or compressed with gzip (with .gz extension),
xz (with .xz extension, supported since dpkg 1.15.6),
bzip2 (with .bz2 extension, supported since dpkg 1.10.24) or
lzma (with .lzma extension, supported since dpkg 1.13.25).

List the archive files to have the 3rd name with the correct extension.

The method avocado.utils.archive.extract() will handle the different
compression format for us.

Signed-off-by: Philippe Mathieu-Daudé 
---
Based-on: 20190221005753.27955-15-cr...@redhat.com

 tests/acceptance/boot_linux_console.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/boot_linux_console.py 
b/tests/acceptance/boot_linux_console.py
index d866886067..b62b70bbde 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -58,8 +58,9 @@ class BootLinuxConsole(Test):
 """
 cwd = os.getcwd()
 os.chdir(self.workdir)
-process.run("ar x %s data.tar.gz" % deb)
-archive.extract("data.tar.gz", self.workdir)
+file_path = process.system_output("ar t %s" % deb).split()[2].decode()
+process.run("ar x %s %s" % (deb, file_path))
+archive.extract(file_path, self.workdir)
 os.chdir(cwd)
 return self.workdir + path
 
-- 
2.20.1




Re: [Qemu-devel] [Qemu-ppc] Forward-porting RTC device for eppc500 ?

2019-03-02 Thread Andrew Randrianasulu
В сообщении от Saturday 02 March 2019 23:40:47 BALATON Zoltan написал(а):

[snip]


>
> On Sat, 2 Mar 2019, Andrew Randrianasulu wrote:
> > Should I fix those?
>
> [...]
>
> > total: 14 errors, 2 warnings, 462 lines checked
> >
> > 0001-Re-applying-of-Freescale-PPC500-i2c-RTC-patch-writte.patch has style
> > problems, please review.  If any of these errors
> > are false positives report them to the maintainer, see
> > CHECKPATCH in MAINTAINERS.
>
> Yes, patches submitted to the list should pass checkpatch otherwise they
> will be rejected by automated build tests. These are simple to fix, just
> add spaces as checkpatch suggests: (1 << 0) and so on.
>
> (It's better to keep the list cc-d on reply so others can also answer your
> questions or correct my answers if I missed something which is not
> possible if you reply to me off list.)


Posted to list, arrived as 
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg00413.html

I used (in specifically created branch)

git reset origin
git reset --hard
git apply \
/home/guest/botva/src/src/qemu/0001-Re-applying-Freescale-PPC500-i2c-RTC-patch-written-b.patch
rm hw/i2c/mpc_i2c.c (leftover from my previous attempt at commiting)
again

git apply \
/home/guest/botva/src/src/qemu/0001-Re-applying-Freescale-PPC500-i2c-RTC-patch-written-b.patch
{now it applies cleanly)

git add hw/i2c/mpc_i2c.c

make

ppc64-softmmu/qemu-system-ppc64 -M ppce500 -cpu 
e5500 -kernel 
/mnt/sdb1/PPC-img/linux-image-4.20.12-X1000_X5000/X5000_and_QEMU_e5500/uImage-4.20
 -nographic

git commit -a --author="Amit Singh Tomar "  
git format-patch -s 20b084c4b1401b7f8fbc385649d48c67b6f43d44
scripts/checkpatch.pl 0001-Re-applying-Freescale-PPC-E500-i2c-RTC-patch.patch

After this I created new message in Kmail and inserted 0001 file, edited it a 
bit more (adding patchwork link and mentioning fact I actually boot-tested 
patch), and then send out.

Guess next time I better to add second "-s" to git format-patch, so first 
signed-off-by-line from original will be around too?

Or ..lets wait what actual maintainers will say. 
>
> Regards,
> BALATON Zoltan





[Qemu-devel] [Bug 1818367] [NEW] Initialization of device cfi.pflash01 failed: Block node is read-only

2019-03-02 Thread José Pekkarinen
Public bug reported:

Hi,

I have several vms defined in libvirt using ovmf for uefi, since a later
update of my server I'm unable to start any of the domains defined. This is
an example of the output given:

# virsh start os-1
error: Failed to start domain os-1
error: internal error: qemu unexpectedly closed the monitor: 
2019-03-02T21:23:51.726446Z qemu-system-x86_64: Initialization of device 
cfi.pflash01 failed: Block node is read-only

an example of domain is like this:

 


   
  os-1 


   
  34c41008-ab91-483b-959c-81a7a12ae9be 


   
  8388608   


   
  8388608 


   
 


   



   



   
  4


   



   
hvm 


   
/var/lib/libvirt/qemu/nvram/os-1-ovmf.fd 


   
   


   



   
   


   
  


   
 


   
 

 

Re: [Qemu-devel] [PATCH v3 11/20] Boot Linux Console Test: increase timeout

2019-03-02 Thread Philippe Mathieu-Daudé
On 2/21/19 1:57 AM, Cleber Rosa wrote:
> When running on very low powered environments, some tests may time out
> causing false negatives.  As a conservative change, and for
> considering that human time (investigating false negatives) is worth
> more than some extra machine cycles (and time), let's increase the
> overall timeout.

However this is annoying when a test is stuck and you work on battery...

> 
> CC: Alex Bennée 
> Signed-off-by: Cleber Rosa 
> ---
>  tests/acceptance/boot_linux_console.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/acceptance/boot_linux_console.py 
> b/tests/acceptance/boot_linux_console.py
> index cc5dcd7373..fa721a7355 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -21,7 +21,7 @@ class BootLinuxConsole(Test):
>  :avocado: enable
>  """
>  
> -timeout = 60
> +timeout = 90
>  
>  KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
>  
> 



Re: [Qemu-devel] [PATCH v3 14/20] Boot Linux Console Test: add a test for mips + malta

2019-03-02 Thread Philippe Mathieu-Daudé
On 2/21/19 1:57 AM, Cleber Rosa wrote:
> From: Philippe Mathieu-Daudé 
> 
> Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
> board and verify the serial is working.  Also, it relies on the serial
> device set by the machine itself.
> 
> If mips is a target being built, "make check-acceptance" will
> automatically include this test by the use of the "arch:mips" tags.
> 
> Alternatively, this test can be run using:
> 
> $ avocado run -t arch:mips tests/acceptance
> $ avocado run -t machine:malta tests/acceptance
> $ avocado run -t endian:big tests/acceptance
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> Signed-off-by: Cleber Rosa 
> ---
>  .travis.yml|  2 +-
>  tests/acceptance/boot_linux_console.py | 41 ++
>  2 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 42971484ab..0a5e0613be 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -198,7 +198,7 @@ matrix:
>  
>  # Acceptance (Functional) tests
>  - env:
> -- CONFIG="--python=/usr/bin/python3 --target-list=x86_64-softmmu"
> +- CONFIG="--python=/usr/bin/python3 
> --target-list=x86_64-softmmu,mips-softmmu"
>  - TEST_CMD="make check-acceptance"
>addons:
>  apt:
> diff --git a/tests/acceptance/boot_linux_console.py 
> b/tests/acceptance/boot_linux_console.py
> index e2ef43e7ce..05e43360b8 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -8,9 +8,12 @@
>  # This work is licensed under the terms of the GNU GPL, version 2 or
>  # later.  See the COPYING file in the top-level directory.
>  
> +import os
>  import logging
>  
>  from avocado_qemu import Test
> +from avocado.utils import process
> +from avocado.utils import archive
>  
>  
>  class BootLinuxConsole(Test):
> @@ -44,6 +47,21 @@ class BootLinuxConsole(Test):
>  fail = 'Failure message found in console: %s' % 
> failure_message
>  self.fail(fail)
>  
> +def extract_from_deb(self, deb, path):
> +"""
> +Extracts a file from a deb package into the test workdir
> +
> +:param deb: path to the deb archive
> +:param file: path within the deb archive of the file to be extracted
> +:returns: path of the extracted file
> +"""
> +cwd = os.getcwd()
> +os.chdir(self.workdir)
> +process.run("ar x %s data.tar.gz" % deb)
> +archive.extract("data.tar.gz", self.workdir)
> +os.chdir(cwd)
> +return self.workdir + path

Tested-by: Philippe Mathieu-Daudé 

> +
>  def test_x86_64_pc(self):
>  """
>  :avocado: tags=arch:x86_64
> @@ -62,3 +80,26 @@ class BootLinuxConsole(Test):
>  self.vm.launch()
>  console_pattern = 'Kernel command line: %s' % kernel_command_line
>  self.wait_for_console_pattern(console_pattern)
> +
> +def test_mips_malta(self):
> +"""
> +:avocado: tags=arch:mips
> +:avocado: tags=machine:malta
> +:avocado: tags=endian:big
> +"""
> +deb_url = ('http://snapshot.debian.org/archive/debian/'
> +   '20130217T032700Z/pool/main/l/linux-2.6/'
> +   'linux-image-2.6.32-5-4kc-malta_2.6.32-48_mips.deb')
> +deb_hash = 'a8cfc28ad8f45f54811fc6cf74fc43ffcfe0ba04'
> +deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> +kernel_path = self.extract_from_deb(deb_path,
> +
> '/boot/vmlinux-2.6.32-5-4kc-malta')
> +
> +self.vm.set_machine('malta')
> +self.vm.set_console()
> +kernel_command_line = self.KERNEL_COMMON_COMMAND_LINE + 
> 'console=ttyS0'
> +self.vm.add_args('-kernel', kernel_path,
> + '-append', kernel_command_line)
> +self.vm.launch()
> +console_pattern = 'Kernel command line: %s' % kernel_command_line
> +self.wait_for_console_pattern(console_pattern)
> 



Re: [Qemu-devel] [PATCH v3 09/20] Boot Linux Console Test: update the x86_64 kernel

2019-03-02 Thread Philippe Mathieu-Daudé
On 2/21/19 1:57 AM, Cleber Rosa wrote:
> To the stock Fedora 29 kernel, from the Fedora 28.  New tests will be

[Update] to ... ?

> added using the 29 kernel, so for consistency, let's also update it
> here.
> 
> Signed-off-by: Cleber Rosa 
> Reviewed-by: Caio Carrara 

Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 

> ---
>  tests/acceptance/boot_linux_console.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/acceptance/boot_linux_console.py 
> b/tests/acceptance/boot_linux_console.py
> index 89df7f6e4f..35b31162d4 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -28,9 +28,9 @@ class BootLinuxConsole(Test):
>  :avocado: tags=arch:x86_64
>  :avocado: tags=machine:pc
>  """
> -kernel_url = ('https://mirrors.kernel.org/fedora/releases/28/'
> +kernel_url = ('https://mirrors.kernel.org/fedora/releases/29/'
>'Everything/x86_64/os/images/pxeboot/vmlinuz')
> -kernel_hash = '238e083e114c48200f80d889f7e32eeb2793e02a'
> +kernel_hash = '23bebd2680757891cf7adedb033532163a792495'
>  kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
>  
>  self.vm.set_machine('pc')
> 



Re: [Qemu-devel] [PATCH v3 15/20] Boot Linux Console Test: add a test for mips64el + malta

2019-03-02 Thread Philippe Mathieu-Daudé
On 2/21/19 1:57 AM, Cleber Rosa wrote:
> Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
> board and verify the serial is working.
> 
> If mips64el is a target being built, "make check-acceptance" will
> automatically include this test by the use of the "arch:mips64el"
> tags.
> 
> Alternatively, this test can be run using:
> 
> $ avocado run -t arch:mips64el tests/acceptance
> $ avocado run -t machine:malta tests/acceptance
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> Signed-off-by: Cleber Rosa 
> ---
>  .travis.yml|  2 +-
>  tests/acceptance/boot_linux_console.py | 34 ++
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 0a5e0613be..0260263bb8 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -198,7 +198,7 @@ matrix:
>  
>  # Acceptance (Functional) tests
>  - env:
> -- CONFIG="--python=/usr/bin/python3 
> --target-list=x86_64-softmmu,mips-softmmu"
> +- CONFIG="--python=/usr/bin/python3 
> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu"
>  - TEST_CMD="make check-acceptance"
>addons:
>  apt:
> diff --git a/tests/acceptance/boot_linux_console.py 
> b/tests/acceptance/boot_linux_console.py
> index 05e43360b8..899c27a9ec 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -10,6 +10,7 @@
>  
>  import os
>  import logging
> +import os

One import is enough :P

>  
>  from avocado_qemu import Test
>  from avocado.utils import process
> @@ -103,3 +104,36 @@ class BootLinuxConsole(Test):
>  self.vm.launch()
>  console_pattern = 'Kernel command line: %s' % kernel_command_line
>  self.wait_for_console_pattern(console_pattern)
> +
> +def test_mips64el_malta(self):
> +"""
> +This test requires the ar tool to extract "data.tar.gz" from
> +the Debian package.
> +
> +The kernel can be rebuilt using this Debian kernel source [1] and
> +following the instructions on [2].
> +
> +[1] http://snapshot.debian.org/package/linux-2.6/2.6.32-48/
> +#linux-source-2.6.32_2.6.32-48
> +[2] https://kernel-team.pages.debian.net/kernel-handbook/
> +ch-common-tasks.html#s-common-official
> +
> +:avocado: tags=arch:mips64el
> +:avocado: tags=machine:malta
> +"""
> +deb_url = ('http://snapshot.debian.org/archive/debian/'
> +   '20130217T032700Z/pool/main/l/linux-2.6/'
> +   'linux-image-2.6.32-5-5kc-malta_2.6.32-48_mipsel.deb')
> +deb_hash = '1aaec92083bf22fda31e0d27fa8d9a388e5fc3d5'
> +deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> +kernel_path = self.extract_from_deb(deb_path,
> +
> '/boot/vmlinux-2.6.32-5-5kc-malta')
> +
> +self.vm.set_machine('malta')
> +self.vm.set_console()
> +kernel_command_line = self.KERNEL_COMMON_COMMAND_LINE + 
> 'console=ttyS0'
> +self.vm.add_args('-kernel', kernel_path,
> + '-append', kernel_command_line)
> +self.vm.launch()
> +console_pattern = 'Kernel command line: %s' % kernel_command_line
> +self.wait_for_console_pattern(console_pattern)
> 



[Qemu-devel] [PATCH] Re-applying Freescale PPC E500 i2c/RTC patch

2019-03-02 Thread Andrew Randrianasulu
From ad2b4baf8b369c8ef354e56f75ae780413acd989 Mon Sep 17 00:00:00 2001
From: Amit Singh Tomar 
Date: Sun, 3 Mar 2019 00:05:04 +0300
Subject: [PATCH] Re-applying Freescale PPC E500 i2c/RTC patch

Patch was originally writen by Amit Singh Tomar 
see http://patchwork.ozlabs.org/patch/431475/
I only fixed it enough for application on top of current qemu master
20b084c4b1401b7f8fbc385649d48c67b6f43d44, and hopefully fixed checkpatch errors

Tested by booting Linux kernel 4.20.12.

Signed-off-by: Andrew Randrianasulu 
---
 default-configs/ppc-softmmu.mak |   2 +
 hw/i2c/Makefile.objs|   1 +
 hw/i2c/mpc_i2c.c| 357 
 hw/ppc/e500.c   |  54 ++
 4 files changed, 414 insertions(+)
 create mode 100644 hw/i2c/mpc_i2c.c

diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 52acb7cf39..a560971f0c 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -8,6 +8,8 @@ include usb.mak
 CONFIG_PPC4XX=y
 CONFIG_M48T59=y
 CONFIG_SERIAL=y
+CONFIG_MPC_I2C=y
+CONFIG_DS1338=y
 CONFIG_I8257=y
 CONFIG_OPENPIC=y
 CONFIG_PPCE500_PCI=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index 9205cbee16..3eb584254f 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -9,5 +9,6 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
 common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_i2c.o
 common-obj-$(CONFIG_NRF51_SOC) += microbit_i2c.o
+common-obj-$(CONFIG_MPC_I2C) += mpc_i2c.o
 obj-$(CONFIG_OMAP) += omap_i2c.o
 obj-$(CONFIG_PPC4XX) += ppc4xx_i2c.o
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
new file mode 100644
index 00..693ca7ef6b
--- /dev/null
+++ b/hw/i2c/mpc_i2c.c
@@ -0,0 +1,357 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Amit Tomar, 
+ *
+ * Description:
+ * This file is derived from IMX I2C controller,
+ * by Jean-Christophe DUBOIS .
+ *
+ * Thanks to Scott Wood and Alexander Graf for their kind help on this.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2 or later,
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "hw/i2c/i2c.h"
+#include "qemu/log.h"
+#include "hw/sysbus.h"
+
+/* #define DEBUG_I2C */
+
+#ifdef DEBUG_I2C
+#define DPRINTF(fmt, ...)  \
+do { fprintf(stderr, "mpc_i2c[%s]: " fmt, __func__, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define TYPE_MPC_I2C "mpc-i2c"
+#define MPC_I2C(obj) \
+OBJECT_CHECK(MPCI2CState, (obj), TYPE_MPC_I2C)
+
+#define MPC_I2C_ADR   0x00
+#define MPC_I2C_FDR   0x04
+#define MPC_I2C_CR0x08
+#define MPC_I2C_SR0x0c
+#define MPC_I2C_DR0x10
+#define MPC_I2C_DFSRR 0x14
+
+#define CCR_MEN  (1 << 7)
+#define CCR_MIEN (1 << 6)
+#define CCR_MSTA (1 << 5)
+#define CCR_MTX  (1 << 4)
+#define CCR_TXAK (1 << 3)
+#define CCR_RSTA (1 << 2)
+#define CCR_BCST (1 << 0)
+
+#define CSR_MCF  (1 << 7)
+#define CSR_MAAS (1 << 6)
+#define CSR_MBB  (1 << 5)
+#define CSR_MAL  (1 << 4)
+#define CSR_SRW  (1 << 2)
+#define CSR_MIF  (1 << 1)
+#define CSR_RXAK (1 << 0)
+
+#define CADR_MASK 0xFE
+#define CFDR_MASK 0x3F
+#define CCR_MASK  0xFC
+#define CSR_MASK  0xED
+#define CDR_MASK  0xFF
+
+#define CYCLE_RESET 0xFF
+
+typedef struct MPCI2CState {
+SysBusDevice parent_obj;
+
+I2CBus *bus;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint8_t address;
+uint8_t adr;
+uint8_t fdr;
+uint8_t cr;
+uint8_t sr;
+uint8_t dr;
+uint8_t dfssr;
+} MPCI2CState;
+
+static bool mpc_i2c_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MEN;
+}
+
+static bool mpc_i2c_is_master(MPCI2CState *s)
+{
+return s->cr & CCR_MSTA;
+}
+
+static bool mpc_i2c_direction_is_tx(MPCI2CState *s)
+{
+return s->cr & CCR_MTX;
+}
+
+static bool mpc_i2c_irq_pending(MPCI2CState *s)
+{
+return s->sr & CSR_MIF;
+}
+
+static bool mpc_i2c_irq_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MIEN;
+}
+
+static void mpc_i2c_reset(DeviceState *dev)
+{
+MPCI2CState *i2c = MPC_I2C(dev);
+
+i2c->address = 0xFF;
+i2c->adr = 0x00;
+i2c->fdr = 0x00;
+i2c->cr =  0x00;
+i2c->sr =  0x81;
+i2c->dr =  0x00;
+}
+
+static void mpc_i2c_irq(MPCI2CState *s)
+{
+bool irq_active = false;
+
+if (mpc_i2c_is_enabled(s) && mpc_i2c_irq_is_enabled(s)
+  && mpc_i2c_irq_pending(s)) {
+irq_active = true;
+}
+
+if (irq_active) {
+qemu_irq_raise(s->irq);
+} else {
+qemu_irq_lower(s->irq);
+}
+}
+
+static void mpc_i2c_soft_reset(MPCI2CState *s)
+{
+/* This is a soft reset. ADR is preserved during soft resets 

Re: [Qemu-devel] [PATCH v3 18/20] Boot Linux Console Test: add a test for arm + virt

2019-03-02 Thread Philippe Mathieu-Daudé
Hi Cleber,

On 2/21/19 1:57 AM, Cleber Rosa wrote:
> Just like the previous tests, boots a Linux kernel on an arm target
> using the virt machine.
> 
> Signed-off-by: Cleber Rosa 
> Reviewed-by: Caio Carrara 
> ---
>  .travis.yml|  2 +-
>  tests/acceptance/boot_linux_console.py | 20 
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 60a4bc00b8..f34bd8dc2b 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -198,7 +198,7 @@ matrix:
>  
>  # Acceptance (Functional) tests
>  - env:
> -- CONFIG="--python=/usr/bin/python3 
> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,ppc64-softmmu,aarch64-softmmu"
> +- CONFIG="--python=/usr/bin/python3 
> --target-list=x86_64-softmmu,mips-softmmu,mips64el-softmmu,ppc64-softmmu,aarch64-softmmu,arm-softmmu"
>  - TEST_CMD="make check-acceptance"
>addons:
>  apt:
> diff --git a/tests/acceptance/boot_linux_console.py 
> b/tests/acceptance/boot_linux_console.py
> index 1f2dfa3654..311f6fbb96 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -177,3 +177,23 @@ class BootLinuxConsole(Test):
>  self.vm.launch()
>  console_pattern = 'Kernel command line: %s' % kernel_command_line
>  self.wait_for_console_pattern(console_pattern)
> +
> +def test_arm_virt(self):
> +"""
> +:avocado: tags=arch:arm
> +:avocado: tags=machine:virt
> +"""
> +kernel_url = 
> ('https://sjc.edge.kernel.org/fedora-buffet/fedora/linux/'
> +  'releases/29/Server/armhfp/os/images/pxeboot/vmlinuz')
> +kernel_hash = 'e9826d741b4fb04cadba8d4824d1ed3b7fb8b4d4'
> +kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> +
> +self.vm.set_machine('virt')
> +self.vm.set_console()
> +kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
> +   'console=ttyAMA0')
> +self.vm.add_args('-kernel', kernel_path,
> + '-append', kernel_command_line)
> +self.vm.launch()
> +console_pattern = 'Kernel command line: %s' % kernel_command_line
> +self.wait_for_console_pattern(console_pattern)
> 

This one sometime hangs:

$ make check-acceptance AVOCADO_SHOW=app,console
  AVOCADO tests/acceptance
JOB ID : 9e363f10363c90882716d6be254f07eb5f355172
JOB LOG:
/source/qemu/build/gcc/tests/results/job-2019-03-02T21.00-9e363f1/job.log
...
 (06/16)
/source/qemu/tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_virt:
/console: Booting Linux on physical CPU 0x0
console: Linux version 4.18.16-300.fc29.armv7hl
(mockbu...@buildvm-armv7-06.arm.fedoraproject.org) (gcc version 8.2.1
20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sun Oct 21 00:56:28 UTC 2018
console: CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
console: CPU: div instructions available: patching division code
console: CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
console: OF: fdt: Machine model: linux,dummy-virt
console: Memory policy: Data cache writealloc
console: efi: Getting EFI parameters from FDT:
console: efi: UEFI not found.
console: cma: Failed to reserve 64 MiB
console: psci: probing for conduit method from DT.
console: psci: PSCIv0.2 detected in firmware.
console: psci: Using standard PSCI v0.2 function IDs
console: psci: Trusted OS migration not required
console: percpu: Embedded 16 pages/cpu @(ptrval) s34956 r8192 d22388 u65536
console: Built 1 zonelists, mobility grouping on.  Total pages: 32480
console: Kernel command line: printk.time=0 console=ttyAMA0
INTERRUPTED: Runner error occurred: Timeout reached\nOriginal status:
PASS\n{'name':
'06-/source/qemu/tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_virt',
'logdir':
'/source/qemu/build/gcc/tests/results/job-2019-03-02T21.00-df1a431...
(90.60 s)
...
RESULTS: PASS 9 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 1 |
CANCEL 6
JOB TIME   : 105.35 s
make: *** [/source/qemu/tests/Makefile.include:1116: check-acceptance]
Error 8

$ uname -rom
4.20.11-200.fc29.x86_64 x86_64 GNU/Linux

The string is here, so I wonder if something is wrong in
wait_for_console_pattern().

The debug log isn't helpful:

2019-03-02 21:10:27,062 test L0602 INFO | START
06-/source/qemu/tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_virt
2019-03-02 21:10:27,062 test L0298 DEBUG| DATA
(filename=output.expected) => NOT FOUND (data sources: variant, test, file)
2019-03-02 21:10:27,063 parameters   L0146 DEBUG| PARAMS (key=arch,
path=*, default=arm) => 'arm'
2019-03-02 21:10:27,063 parameters   L0146 DEBUG| PARAMS
(key=qemu_bin, path=*, default=arm-softmmu/qemu-system-arm) =>
'arm-softmmu/qemu-system-arm'
2019-03-02 21:10:27,070 qemu L0323 DEBUG| VM launch command:

Re: [Qemu-devel] [RFC] multi phase reset

2019-03-02 Thread Philippe Mathieu-Daudé
Hi Damien,

On 3/1/19 5:52 PM, Peter Maydell wrote:
> On Fri, 1 Mar 2019 at 15:34, Damien Hedde  wrote:
>> On 3/1/19 12:43 PM, Peter Maydell wrote:
>>> In my design the only thing that I thought would happen in phase 3
>>> was the "clear the resetting flag", but you've moved that to RELEASE.
>>> What's left ? Do you have a concrete example where we'd need this?
>>
>> I hesitated to remove this phase (would be easy to add it after if it is
>> really needed). I see 2 cases where it might be useful.

If I RELEASE a PLL which need some time to warm up and stabilize, once
stabilized it moves the device to the POST phase where it is ready?

>>
>> To stay in my use case for clocks, here how it can be used: For an uart,
>> during release phase, the clock will propagate and only after every
>> release phases has been executed we will have the final/valid input
>> frequency.
>> So we can either recompute the uart baudrate every time the clock change
>> due to propagation or wait till post phase to do it once for all (and
>> initialize the backend parameters). But it is probably no big deal for
>> this case if we don't have post phase.
> 
> I think I'd rather have the model be simpler rather than
> complicate it for the sake of optimisation. It's not like
> we reset very frequently...



Re: [Qemu-devel] [PATCH] MAINTAINERS: add missing support status fields

2019-03-02 Thread Philippe Mathieu-Daudé
On 3/1/19 5:35 PM, Stefan Hajnoczi wrote:
> This patch adds the "S:" line for areas of the codebase that currently
> lack a support status field.
> 
> Note that there are a few more areas that are more abstract and do not
> correspond to a specific set of files.  They have not been modified.
> 
> Cc: Alex Bennée 
> Signed-off-by: Stefan Hajnoczi 

Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d941cb3862..2464f51879 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -338,6 +338,7 @@ F: include/hw/tricore/
>  
>  Multiarch Linux User Tests
>  M: Alex Bennée 
> +S: Maintained
>  F: tests/tcg/multiarch/
>  
>  Guest CPU Cores (KVM):
> @@ -2094,6 +2095,7 @@ F: qemu.sasl
>  Coroutines
>  M: Stefan Hajnoczi 
>  M: Kevin Wolf 
> +S: Maintained
>  F: util/*coroutine*
>  F: include/qemu/coroutine*
>  F: tests/test-coroutine.c
> @@ -2528,6 +2530,7 @@ F: .gitlab-ci.yml
>  Guest Test Compilation Support
>  M: Alex Bennée 
>  R: Philippe Mathieu-Daudé 
> +S: Maintained
>  F: tests/tcg/Makefile
>  F: tests/tcg/Makefile.include
>  L: qemu-devel@nongnu.org
> 



Re: [Qemu-devel] [PATCH RFC v3 08/11] RX62N internal serial communication interface

2019-03-02 Thread Philippe Mathieu-Daudé
Hi Yoshinori,

On 3/2/19 7:21 AM, Yoshinori Sato wrote:
> This module supported only non FIFO type.
> Hardware manual.
> https://www.renesas.com/us/en/doc/products/mpumcu/doc/rx_family/r01uh0033ej0140_rx62n.pdf?key=086621e01bd70347c18ea7f794aa9cc3

This link also works without the trailing
"?key=086621e01bd70347c18ea7f794aa9cc3".

> 
> Signed-off-by: Yoshinori Sato 
> ---
>  hw/char/Makefile.objs |   2 +-
>  hw/char/renesas_sci.c | 288 
> ++
>  include/hw/char/renesas_sci.h |  42 ++

QEMU provides a git config helper to improve git diff by showing headers
first and C sources after: scripts/git.orderfile
I recommend you to look at it.

I'll review the header, then back to source.

>  3 files changed, 331 insertions(+), 1 deletion(-)
>  create mode 100644 hw/char/renesas_sci.c
>  create mode 100644 include/hw/char/renesas_sci.h
> 
> diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
> index c4947d7ae7..68eae7b9a5 100644
> --- a/hw/char/Makefile.objs
> +++ b/hw/char/Makefile.objs
> @@ -15,7 +15,7 @@ common-obj-$(CONFIG_CADENCE) += cadence_uart.o
>  obj-$(CONFIG_EXYNOS4) += exynos4210_uart.o
>  obj-$(CONFIG_COLDFIRE) += mcf_uart.o
>  obj-$(CONFIG_OMAP) += omap_uart.o
> -obj-$(CONFIG_SH4) += sh_serial.o
> +obj-$(CONFIG_RENESAS_SCI) += renesas_sci.o
>  obj-$(CONFIG_PSERIES) += spapr_vty.o
>  obj-$(CONFIG_DIGIC) += digic-uart.o
>  obj-$(CONFIG_STM32F2XX_USART) += stm32f2xx_usart.o
> diff --git a/hw/char/renesas_sci.c b/hw/char/renesas_sci.c
> new file mode 100644
> index 00..56d070a329
> --- /dev/null
> +++ b/hw/char/renesas_sci.c
> @@ -0,0 +1,288 @@
> +/*
> + * Renesas Serial Communication Interface

I'd add here:

Datasheet: RX62N Group, RX621 Group User's Manual: Hardware
(Rev.1.40 R01UH0033EJ0140)

> + *
> + * Copyright (c) 2019 Yoshinori Sato
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2 or later, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +#include "cpu.h"
> +#include "hw/hw.h"
> +#include "hw/sysbus.h"
> +#include "hw/char/renesas_sci.h"
> +#include "qemu/error-report.h"
> +
> +#define freq_to_ns(freq) (10LL / freq)

You can directly use NANOSECONDS_PER_SECOND in update_trtime().

> +
> +static int can_receive(void *opaque)
> +{
> +RSCIState *sci = RSCI(opaque);
> +if (sci->rx_next > qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL)) {
> +return 0;
> +} else {
> +return sci->scr & 0x10;

It is way easier to review a code using definitions generated by the
"hw/registerfields.h" API, a recent example is hw/char/cmsdk-apb-uart.c.

> +}
> +}
> +
> +static void receive(void *opaque, const uint8_t *buf, int size)
> +{
> +RSCIState *sci = RSCI(opaque);
> +sci->rdr = buf[0];
> +if (sci->ssr & 0x40 || size > 1) {
> +sci->ssr |= 0x20;
> +if (sci->scr & 0x40) {
> +qemu_set_irq(sci->irq[ERI], 1);
> +}
> +} else {
> +sci->ssr |= 0x40;
> +sci->rx_next = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + sci->trtime;
> +if (sci->scr & 0x40) {
> +qemu_set_irq(sci->irq[RXI], 1);
> +qemu_set_irq(sci->irq[RXI], 0);

Both lines are equivalent to:

   qemu_irq_pulse(sci->irq[RXI]);

> +}
> +}
> +}
> +
> +static void send_byte(RSCIState *sci)
> +{
> +if (qemu_chr_fe_backend_connected(>chr)) {
> +qemu_chr_fe_write_all(>chr, >tdr, 1);
> +}
> +timer_mod(sci->timer,
> +  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + sci->trtime);
> +sci->ssr &= ~0x04;
> +sci->ssr |= 0x80;
> +qemu_set_irq(sci->irq[TEI], 0);
> +if (sci->scr & 0x80) {
> +qemu_set_irq(sci->irq[TXI], 1);
> +qemu_set_irq(sci->irq[TXI], 0);
> +}
> +}
> +
> +static void txend(void *opaque)
> +{
> +RSCIState *sci = RSCI(opaque);
> +if ((sci->ssr & 0x80) == 0) {
> +send_byte(sci);
> +} else {
> +sci->ssr |= 0x04;
> +if (sci->scr & 0x04) {
> +qemu_set_irq(sci->irq[TEI], 1);
> +}
> +}
> +}
> +
> +static void update_trtime(RSCIState *sci)
> +{
> +static const int div[] = {1, 4, 16, 64};
> +int w;
> +
> +w = (sci->smr & 0x40) ? 7 : 8;  /* CHR */
> +w += (sci->smr >> 5) & 1;   /* PE */
> +w += (sci->smr & 0x08) ? 2 : 1; /* STOP */
> +sci->trtime = w * freq_to_ns(sci->input_freq) *
> +32 * 

Re: [Qemu-devel] [PATCH v5 08/10] tests/tcg: target/mips: Add wrappers for some MIPS64R6 instructions

2019-03-02 Thread Philippe Mathieu-Daudé
On 3/1/19 8:18 PM, Aleksandar Markovic wrote:
> From: Aleksandar Markovic 
> 
> Add wrappers for some MIPS64R6 instructions.
> 
> Signed-off-by: Aleksandar Markovic 
> ---
>  tests/tcg/mips/include/wrappers_mips64r6.h | 64 
> ++
>  1 file changed, 64 insertions(+)
>  create mode 100644 tests/tcg/mips/include/wrappers_mips64r6.h
> 
> diff --git a/tests/tcg/mips/include/wrappers_mips64r6.h 
> b/tests/tcg/mips/include/wrappers_mips64r6.h
> new file mode 100644
> index 000..c9c34aa
> --- /dev/null
> +++ b/tests/tcg/mips/include/wrappers_mips64r6.h
> @@ -0,0 +1,64 @@
> +/*
> + *  Header file for wrappers around MIPS64R6 instructions assembler
> + *  invocations
> + *
> + *  Copyright (C) 2019  Wave Computing, Inc.
> + *  Copyright (C) 2019  Aleksandar Markovic 
> + *
> + *  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 of the License, or
> + *  (at your option) any later version.
> + *
> + *  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 .
> + *
> + */
> +
> +#ifndef WRAPPERS_MIPS64R6_H
> +#define WRAPPERS_MIPS64R6_H
> +
> +
> +#define DO_MIPS64R6__RD__RS(suffix, mnemonic)  \
> +static inline void do_mips64r6_##suffix(void *input, void *output) \

'const void *input'

> +{  \
> +   __asm__ volatile (  \
> +  "ld $t1, 0(%0)\n\t"  \
> +  #mnemonic " $t0, $t1\n\t"\
> +  "sd $t0, 0(%1)\n\t"  \
> +  :\
> +  : "r" (input), "r" (output)  \
> +  : "t0", "t1", "memory"   \
> +   );  \
> +}
> +
> +DO_MIPS64R6__RD__RS(DCLO, dclo)
> +DO_MIPS64R6__RD__RS(DCLZ, dclz)
> +DO_MIPS64R6__RD__RS(BITSWAP, bitswap)
> +DO_MIPS64R6__RD__RS(DBITSWAP, dbitswap)
> +
> +
> +#define DO_MIPS64R6__RD__RS_RT(suffix, mnemonic)   \
> +static inline void do_mips64r6_##suffix(void *input1, void *input2,\

'const void *input1, const void *input2'

> +void *output)  \
> +{  \
> +   __asm__ volatile (  \
> +  "ld $t1, 0(%0)\n\t"  \
> +  "ld $t2, 0(%1)\n\t"  \
> +  #mnemonic " $t0, $t1, $t2\n\t"   \
> +  "sd $t0, 0(%2)\n\t"  \
> +  :\
> +  : "r" (input1), "r" (input2), "r" (output)   \
> +  : "t0", "t1", "memory"   \
> +   );  \
> +}
> +
> +DO_MIPS64R6__RD__RS_RT(DSLLV, dsllv)
> +
> +
> +#endif
> 



Re: [Qemu-devel] [PATCH v5 07/10] tests/tcg: target/mips: Add test utilities for 64-bit tests

2019-03-02 Thread Philippe Mathieu-Daudé
Hi Aleksandar,

On 3/1/19 8:18 PM, Aleksandar Markovic wrote:
> From: Aleksandar Markovic 
> 
> Add test utilities for 64-bit tests. Some of MIPS64R6 instructions
> require 64-bit inputs to be 32-bit integers sign-extedned to 64 bits,

"sign-extended"

> hence the need for sets of such inputs.
> 
> Signed-off-by: Aleksandar Markovic 
> ---
>  tests/tcg/mips/include/test_inputs_64.h | 208 
> 
>  tests/tcg/mips/include/test_utils_64.h  |  78 
>  2 files changed, 286 insertions(+)
>  create mode 100644 tests/tcg/mips/include/test_inputs_64.h
>  create mode 100644 tests/tcg/mips/include/test_utils_64.h
> 
> diff --git a/tests/tcg/mips/include/test_inputs_64.h 
> b/tests/tcg/mips/include/test_inputs_64.h
> new file mode 100644
> index 000..ca7c2fb
> --- /dev/null
> +++ b/tests/tcg/mips/include/test_inputs_64.h
> @@ -0,0 +1,208 @@
> +/*
> + *  Header file for pattern and random test inputs
> + *
> + *  Copyright (C) 2019  Wave Computing, Inc.
> + *  Copyright (C) 2019  Aleksandar Markovic 
> + *
> + *  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 of the License, or
> + *  (at your option) any later version.
> + *
> + *  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 .
> + *
> + */
> +
> +#ifndef TEST_INPUTS_64_H
> +#define TEST_INPUTS_64_H
> +
> +#include 
> +
> +
> +#define PATTERN_INPUTS_64_COUNT  64
> +#define PATTERN_INPUTS_64_SHORT_COUNT 8
> +
> +uint64_t b64_pattern[PATTERN_INPUTS_64_COUNT] = {

You should avoid to declare variables in headers, this lead to
unpleasant surprises when headers are include multiple times (I see it
is include once by each test).

This array is 'const', but I also recommend you to declare it 'static':

  static const uint64_t b64_pattern[PATTERN_INPUTS_64_COUNT] = {

> +0xULL,   /*   0 */
> +0xULL,
> +0xULL,
> +0xULL,
> +0xULL,
> +0xULL,
> +0xE38E38E38E38E38EULL,
> +0x1C71C71C71C71C71ULL,
> +0xF0F0F0F0F0F0F0F0ULL,   /*   8 */
> +0x0F0F0F0F0F0F0F0FULL,
> +0xF83E0F83E0F83E0FULL,
> +0x07C1F07C1F07C1F0ULL,
> +0xFC0FC0FC0FC0FC0FULL,
> +0x03F03F03F03F03F0ULL,
> +0xFE03F80FE03F80FEULL,
> +0x01FC07F01FC07F01ULL,
> +0xFF00FF00FF00FF00ULL,   /*  16 */
> +0x00FF00FF00FF00FFULL,
> +0xFF803FE00FF803FEULL,
> +0x007FC01FF007FC01ULL,
> +0xFFC00FFC00FFC00FULL,
> +0x003FF003FF003FF0ULL,
> +0xFFE003FF800FFE00ULL,
> +0x001FFC007FF001FFULL,
> +0xFFF000FFF000FFF0ULL,   /*  24 */
> +0x000FFF000FFF000FULL,
> +0xFFF8003FFE000FFFULL,
> +0x0007FFC001FFF000ULL,
> +0xFFFC000FFFC000FFULL,
> +0x0003FFF0003FFF00ULL,
> +0xFFFE0003FFF8000FULL,
> +0x0001FFFC0007FFF0ULL,
> +0xULL,   /*  32 */
> +0xULL,
> +0x80003FFFE000ULL,
> +0x7FFFC0001FFFULL,
> +0xCC00ULL,
> +0x33FFULL,
> +0xE380ULL,
> +0x1C7FULL,
> +0xF0F0ULL,   /*  40 */
> +0x0F0FULL,
> +0xF83EULL,
> +0x07C1ULL,
> +0xFC0FULL,
> +0x03F0ULL,
> +0xFE03ULL,
> +0x01FCULL,
> +0xFF00ULL,   /*  48 */
> +0x00FFULL,
> +0xFF803FFFULL,
> +0x007FC000ULL,
> +0xFFC00FFFULL,
> +0x003FF000ULL,
> +0xFFE003FFULL,
> +0x001FFC00ULL,
> +0xFFF000FFULL,   /*  56 */
> +0x000FFF00ULL,
> +0xFFF8003FULL,
> +0x0007FFC0ULL,
> +0xFFFC000FULL,
> +0x0003FFF0ULL,
> +0xFFFE0003ULL,
> +0x0001FFFCULL,
> +};
> +
> +uint64_t b64_pattern_se[PATTERN_INPUTS_64_COUNT] = {
> +0xULL,   /*   0 */
> +0xULL,
> +0xULL,
> +0xULL,
> +0xULL,
> +0xULL,
> +0xE38E38E3ULL,
> +0x1C71C71CULL,
> +0xF0F0F0F0ULL,   /*   8 */
> +0x0F0F0F0FULL,
> +

Re: [Qemu-devel] [PATCH] target/arm: Fix PC test for LDM (exception return)

2019-03-02 Thread Philippe Mathieu-Daudé
On 3/1/19 9:29 PM, Richard Henderson wrote:
> Found by inspection: Rn is the base register against which the
> load began; I is the register within the mask being processed.
> The exception return should of course be procesed from the loaded PC.

"processed"

> 
> Signed-off-by: Richard Henderson 
> ---
>  target/arm/translate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/arm/translate.c b/target/arm/translate.c
> index 8f7f5b95aa..ad879e3480 100644
> --- a/target/arm/translate.c
> +++ b/target/arm/translate.c
> @@ -10612,7 +10612,7 @@ static void disas_arm_insn(DisasContext *s, unsigned 
> int insn)
>  } else if (i == rn) {
>  loaded_var = tmp;
>  loaded_base = 1;
> -} else if (rn == 15 && exc_return) {
> +} else if (i == 15 && exc_return) {
>  store_pc_exc_ret(s, tmp);
>  } else {
>  store_reg_from_load(s, i, tmp);
> 

Reviewed-by: Philippe Mathieu-Daudé 



Re: [Qemu-devel] [PATCH RFC v3 11/11] MAINTAINERS: Add RX entry.

2019-03-02 Thread Philippe Mathieu-Daudé
On 3/2/19 7:21 AM, Yoshinori Sato wrote:
> Signed-off-by: Yoshinori Sato 
> ---
>  MAINTAINERS | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5040d9dfb1..141c4994b9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -270,6 +270,14 @@ F: include/hw/riscv/
>  F: linux-user/host/riscv32/
>  F: linux-user/host/riscv64/
>  
> +RX

RX sounds very generic, what about:

  Renesas Extreme (RX)

Or

  RX (Renesas Extreme)

> +M: Yoshinori Sato 
> +S: Maintained
> +F: target/rx/
> +F: hw/rx/
> +F: include/hw/rx/
> +F: disas/rx.c
> +
>  S390
>  M: Richard Henderson 
>  M: David Hildenbrand 
> @@ -1084,6 +1092,18 @@ F: pc-bios/canyonlands.dt[sb]
>  F: pc-bios/u-boot-sam460ex-20100605.bin
>  F: roms/u-boot-sam460ex
>  
> +RX Machines
> +---
> +RX-QEMU
> +M: Yoshinori Sato 
> +S: Maintained
> +F: hw/rx/rxqemu.c
> +F: hw/intc/rx_icu.c
> +F: hw/timer/renesas_*.c
> +F: hw/char/renesas_sci.c
> +F: include/hw/timer/renesas_*.h
> +F: include/hw/char/renesas_sci.h
> +
>  SH4 Machines
>  
>  R2D
> 



Re: [Qemu-devel] [PATCH RFC v3 00/11] Add RX archtecture support

2019-03-02 Thread Philippe Mathieu-Daudé
Hi Yoshinori,

On 3/2/19 7:21 AM, Yoshinori Sato wrote:
> Hello.
> This patch series is added Renesas RX target emulation.
> 
> My git repository is bellow.
> git://git.pf.osdn.net/gitroot/y/ys/ysato/qemu.git
> 
> Since my understanding is not enough,
> I want many comments to make this a good one.

OK :)

Can you provide notes about how to test your port?
Such: links to toolchains, how to build, what firmware/OS we can run...

> 
> Thanks.
> 
> Changes v2
> Rewrite translate. using decodetree.py
> 
> Yoshinori Sato (11):
>   target/rx: TCG Translation
>   target/rx: TCG helper
>   target/rx: CPU definition
>   target/rx: RX disassembler
>   target/rx: miscellaneous functions
>   RX62N interrupt contorol uint
>   RX62N internal timer modules
>   RX62N internal serial communication interface
>   RX Target hardware definition
>   Add rx-softmmu
>   MAINTAINERS: Add RX entry.
> 
>  MAINTAINERS|   20 +
>  arch_init.c|2 +
>  configure  |8 +
>  default-configs/rx-softmmu.mak |7 +
>  hw/char/Makefile.objs  |2 +-
>  hw/char/renesas_sci.c  |  288 ++
>  hw/intc/Makefile.objs  |1 +
>  hw/intc/rx_icu.c   |  323 ++
>  hw/rx/Makefile.objs|1 +
>  hw/rx/rx62n.c  |  227 
>  hw/rx/rxqemu.c |  100 ++
>  hw/timer/Makefile.objs |2 +
>  hw/timer/renesas_cmt.c |  235 +
>  hw/timer/renesas_tmr.c |  412 
>  include/disas/bfd.h|5 +
>  include/hw/char/renesas_sci.h  |   42 +
>  include/hw/intc/rx_icu.h   |   49 +
>  include/hw/rx/rx.h |7 +
>  include/hw/rx/rx62n.h  |   54 +
>  include/hw/timer/renesas_cmt.h |   33 +
>  include/hw/timer/renesas_tmr.h |   42 +
>  include/sysemu/arch_init.h |1 +
>  target/rx/Makefile.objs|   11 +
>  target/rx/cpu-qom.h|   52 +
>  target/rx/cpu.c|  224 
>  target/rx/cpu.h|  214 
>  target/rx/disas.c  | 1570 
>  target/rx/gdbstub.c|  113 ++
>  target/rx/helper.c |  252 +
>  target/rx/helper.h |   39 +
>  target/rx/insns.decode |  336 ++
>  target/rx/monitor.c|   38 +
>  target/rx/op_helper.c  |  602 +++
>  target/rx/translate.c  | 2220 
> 
>  34 files changed, 7531 insertions(+), 1 deletion(-)
>  create mode 100644 default-configs/rx-softmmu.mak
>  create mode 100644 hw/char/renesas_sci.c
>  create mode 100644 hw/intc/rx_icu.c
>  create mode 100644 hw/rx/Makefile.objs
>  create mode 100644 hw/rx/rx62n.c
>  create mode 100644 hw/rx/rxqemu.c
>  create mode 100644 hw/timer/renesas_cmt.c
>  create mode 100644 hw/timer/renesas_tmr.c
>  create mode 100644 include/hw/char/renesas_sci.h
>  create mode 100644 include/hw/intc/rx_icu.h
>  create mode 100644 include/hw/rx/rx.h
>  create mode 100644 include/hw/rx/rx62n.h
>  create mode 100644 include/hw/timer/renesas_cmt.h
>  create mode 100644 include/hw/timer/renesas_tmr.h
>  create mode 100644 target/rx/Makefile.objs
>  create mode 100644 target/rx/cpu-qom.h
>  create mode 100644 target/rx/cpu.c
>  create mode 100644 target/rx/cpu.h
>  create mode 100644 target/rx/disas.c
>  create mode 100644 target/rx/gdbstub.c
>  create mode 100644 target/rx/helper.c
>  create mode 100644 target/rx/helper.h
>  create mode 100644 target/rx/insns.decode
>  create mode 100644 target/rx/monitor.c
>  create mode 100644 target/rx/op_helper.c
>  create mode 100644 target/rx/translate.c
> 



[Qemu-devel] [Bug 1815889]

2019-03-02 Thread Ahzo
(In reply to Daniel P. Berrange from comment #3)
> (In reply to Ahzo from comment #2)
> > To check for the availability of the syscall, one can try it in a child
> > process and see if the child is terminated by a signal, e.g. like this:
> 
> Afraid not, QEMU's seccomp filter blocks use of fork() too :-)

Maybe it should, at least when using the spawn=deny option, but currently it 
doesn't. That option only blocks the fork, vfork and execve syscalls, but 
glibc's fork() function uses the clone syscall, and thus continues to work.
However, that behavior might be different when using other C library 
implementations, so it wouldn't be correct to rely on this.
One could use clone() instead of fork(), but future versions of qemu might 
block the clone syscall, as well.

Unfortunately, I'm not aware of a proper solution for this bug short of
adding a new API to the kernel.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1815889

Title:
  qemu-system-x86_64 crashed with signal 31 in
  __pthread_setaffinity_new()

Status in Mesa:
  Confirmed
Status in QEMU:
  New
Status in mesa package in Ubuntu:
  New
Status in qemu package in Ubuntu:
  Triaged

Bug description:
  Unable to launch Default Fedora 29 images in gnome-boxes

  ProblemType: Crash
  DistroRelease: Ubuntu 19.04
  Package: qemu-system-x86 1:3.1+dfsg-2ubuntu1
  ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18
  Uname: Linux 4.19.0-12-generic x86_64
  ApportVersion: 2.20.10-0ubuntu20
  Architecture: amd64
  Date: Thu Feb 14 11:00:45 2019
  ExecutablePath: /usr/bin/qemu-system-x86_64
  KvmCmdLine: COMMAND STAT  EUID  RUID   PID  PPID %CPU COMMAND
  MachineType: Dell Inc. Precision T3610
  ProcEnviron: PATH=(custom, user)
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-generic 
root=UUID=939b509b-d627-4642-a655-979b44972d17 ro splash quiet vt.handoff=1
  Signal: 31
  SourcePackage: qemu
  StacktraceTop:
   __pthread_setaffinity_new (th=, cpusetsize=128, 
cpuset=0x7f5771fbf680) at ../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
   start_thread (arg=) at pthread_create.c:486
   clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  Title: qemu-system-x86_64 crashed with signal 31 in 
__pthread_setaffinity_new()
  UpgradeStatus: Upgraded to disco on 2018-11-14 (91 days ago)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo video
  dmi.bios.date: 11/14/2018
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A18
  dmi.board.name: 09M8Y8
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 7
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA18:bd11/14/2018:svnDellInc.:pnPrecisionT3610:pvr00:rvnDellInc.:rn09M8Y8:rvrA01:cvnDellInc.:ct7:cvr:
  dmi.product.name: Precision T3610
  dmi.product.sku: 05D2
  dmi.product.version: 00
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1815889/+subscriptions



Re: [Qemu-devel] [PATCH] slirp: check sscanf result when emulating ident

2019-03-02 Thread Samuel Thibault
Hello,

Philippe Mathieu-Daudé, le sam. 02 mars 2019 18:42:42 +0100, a ecrit:
> Samuel: since this diff is not obvious without looking at the context
> (also due to the code re-indent),

I dropped the code re-indent to make the change obvious. I still added
the commit description, always better goes with saying it :)

Thanks!

Samuel



Re: [Qemu-devel] [PATCH] slirp: fix big/little endian conversion in ident protocol

2019-03-02 Thread Philippe Mathieu-Daudé
On 3/2/19 6:36 PM, Samuel Thibault wrote:
> Philippe Mathieu-Daudé, le sam. 02 mars 2019 18:31:56 +0100, a ecrit:
>> On 3/2/19 3:25 AM, Samuel Thibault wrote:
>>> Signed-off-by: Samuel Thibault 
>>> ---
>>
>> I got:
>>
>> Applying: slirp: fix big/little endian conversion in ident protocol
>> error: patch failed: slirp/tcp_subr.c:660
>> error: slirp/tcp_subr.c: patch does not apply
>>
>> Then noticed another slirp patch, applied first then this one succeed,
>> so you missed:
>>
>> Based-on: <1551476756-25749-1-git-send-email-w...@wbowling.info>
> 
> Oh, I didn't know about that one.

BTW 'Based-on' is a hint for the reviewers and automatic testing bots,
telling "this commit is  this other ", and
without applying the base it is unlikely this patch|series applies.

It is not meant the git history, so for single commit we add it under
the first '---' separator (automatically stripped out when applied) or
for series we add it to the cover.

I guess there are no doc about that hint in HACKING neither in the wiki,
I remember the post where it was introduced:
https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg01288.html

Regards,

Phil.

> 
>> Reviewed-by: Philippe Mathieu-Daudé 
> 
> Thanks!
> 
> Samuel
> 



Re: [Qemu-devel] [PATCH] slirp: check sscanf result when emulating ident

2019-03-02 Thread Philippe Mathieu-Daudé
Hi William, Samuel,

On 3/1/19 10:45 PM, William Bowling wrote:
> When emulating ident in tcp_emu, if the strchr checks passed but the
> sscanf check failed, two uninitialized variables would be copied and
> sent in the reply.

William: How did you notice that? Using a static analyzer?

Samuel: since this diff is not obvious without looking at the context
(also due to the code re-indent), can you improve the commit
description, such (or better):

"Move this code inside the if(sscanf()) clause".

We have a data leak, Cc'ing qemu-stable.
(Adding the address I noticed you Cc'ed secal...@redhat.com, so that
confirms my guess).

> 
> Signed-off-by: William Bowling 

Reviewed-by: Philippe Mathieu-Daudé 

Thanks,

Phil.

> ---
>  slirp/tcp_subr.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/slirp/tcp_subr.c b/slirp/tcp_subr.c
> index 262a42d6c8..73a160ba16 100644
> --- a/slirp/tcp_subr.c
> +++ b/slirp/tcp_subr.c
> @@ -664,12 +664,12 @@ tcp_emu(struct socket *so, struct mbuf *m)
>   break;
>   }
>   }
> - }
> -so_rcv->sb_cc = snprintf(so_rcv->sb_data,
> - so_rcv->sb_datalen,
> - "%d,%d\r\n", n1, 
> n2);
> - so_rcv->sb_rptr = so_rcv->sb_data;
> - so_rcv->sb_wptr = so_rcv->sb_data + 
> so_rcv->sb_cc;
> +so_rcv->sb_cc = snprintf(so_rcv->sb_data,
> + so_rcv->sb_datalen,
> + "%d,%d\r\n", n1, n2);
> +so_rcv->sb_rptr = so_rcv->sb_data;
> +so_rcv->sb_wptr = so_rcv->sb_data + so_rcv->sb_cc;
> +}
>   }
>   m_free(m);
>   return 0;
> 



Re: [Qemu-devel] [PATCH] slirp: fix big/little endian conversion in ident protocol

2019-03-02 Thread Samuel Thibault
Philippe Mathieu-Daudé, le sam. 02 mars 2019 18:31:56 +0100, a ecrit:
> On 3/2/19 3:25 AM, Samuel Thibault wrote:
> > Signed-off-by: Samuel Thibault 
> > ---
> 
> I got:
> 
> Applying: slirp: fix big/little endian conversion in ident protocol
> error: patch failed: slirp/tcp_subr.c:660
> error: slirp/tcp_subr.c: patch does not apply
> 
> Then noticed another slirp patch, applied first then this one succeed,
> so you missed:
> 
> Based-on: <1551476756-25749-1-git-send-email-w...@wbowling.info>

Oh, I didn't know about that one.

> Reviewed-by: Philippe Mathieu-Daudé 

Thanks!

Samuel



Re: [Qemu-devel] [PATCH] slirp: fix big/little endian conversion in ident protocol

2019-03-02 Thread Philippe Mathieu-Daudé
Hi Samuel,

On 3/2/19 3:25 AM, Samuel Thibault wrote:
> Signed-off-by: Samuel Thibault 
> ---

I got:

Applying: slirp: fix big/little endian conversion in ident protocol
error: patch failed: slirp/tcp_subr.c:660
error: slirp/tcp_subr.c: patch does not apply

Then noticed another slirp patch, applied first then this one succeed,
so you missed:

Based-on: <1551476756-25749-1-git-send-email-w...@wbowling.info>

>  slirp/tcp_subr.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/slirp/tcp_subr.c b/slirp/tcp_subr.c
> index ef9d99c154..1d7e72dca7 100644
> --- a/slirp/tcp_subr.c
> +++ b/slirp/tcp_subr.c
> @@ -660,10 +660,12 @@ tcp_emu(struct socket *so, struct mbuf *m)
>   tmpso->so_fport == n1) {
>   if 
> (getsockname(tmpso->s,
>   (struct 
> sockaddr *), ) == 0)
> -n2 = 
> ntohs(addr.sin_port);
> +n2 = addr.sin_port;
>   break;
>   }
>   }
> + NTOHS(n1);
> + NTOHS(n2);
>   so_rcv->sb_cc = 
> snprintf(so_rcv->sb_data,
>
> so_rcv->sb_datalen,
>"%d,%d\r\n", 
> n1, n2);
> 

Reviewed-by: Philippe Mathieu-Daudé 



Re: [Qemu-devel] [Qemu-ppc] Forward-porting RTC device for eppc500 ?

2019-03-02 Thread BALATON Zoltan

Hello,

On Sat, 2 Mar 2019, Andrew Randrianasulu wrote:

Hello, all!

I stumbled upon this email from 2015 (trying to understand why my emulated
ppce500 machine failed to set clock correctly:

https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02642.html

Now, after some quite blind trial-and-error I applied ('forward-ported') this
patch to qemu git commit 0f6a6d5db853c0cbe438c1831c70710bfb6530ee without
actually porting it to new qemu device abstraction model.

It seems to work!

But because I copy-pasted patch from web archive of list - some strings
become "address@hidden", I hope I corrected them right?


You can get all patches submitted to the list from patchew, the original 
of this one is here:

http://patchwork.ozlabs.org/patch/431475/

The mbox format patch for git am is at the mbox link:
http://patchwork.ozlabs.org/patch/431475/mbox/

I think you could try to apply that patch with git am, fix any conflicts 
due to changes in QEMU since the original patch to get an updated commit, 
then use git format-patch to get a current patch you can submit to the 
list for inclusion. The detailed description of how to send a patch is 
here: https://wiki.qemu.org/Contribute/SubmitAPatch


Basically you should make sure you have an email that can be applied with 
git am as that's what maintainers do. It should also have your 
Signed-off-by if you made any changes to the patch after the original 
Signed-off-by of the original author (you can add it e.g. with git commit 
-s or git format-patch -s). Check the patch with scripts/checkpatch.pl 
before sending and fix all errors and cc maintainers that you can get with 
scripts/get_maintainer.pl. For PPC related stuff you should usually cc 
qemu-...@nongnu.org and David Gibson besides sending to 
qemu-devel@nongnu.org to make sure it's not lost.


I don't have any comments to the patch, some more comments below the other 
topic at the end.




---
diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 52acb7cf39..a560971f0c 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -8,6 +8,8 @@ include usb.mak
CONFIG_PPC4XX=y
CONFIG_M48T59=y
CONFIG_SERIAL=y
+CONFIG_MPC_I2C=y
+CONFIG_DS1338=y
CONFIG_I8257=y
CONFIG_OPENPIC=y
CONFIG_PPCE500_PCI=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index cecee486f7..55473fc6b2 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -9,5 +9,6 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
common-obj-$(CONFIG_ASPEED_SOC) += aspeed_i2c.o
common-obj-$(CONFIG_NRF51_SOC) += microbit_i2c.o
+common-obj-$(CONFIG_MPC_I2C) += mpc_i2c.o
obj-$(CONFIG_OMAP) += omap_i2c.o
obj-$(CONFIG_PPC4XX) += ppc4xx_i2c.o
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
new file mode 100644
index 00..54d7a9aabd
--- /dev/null
+++ b/hw/i2c/mpc_i2c.c
@@ -0,0 +1,360 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Amit Tomar, 
+ *
+ * Description:
+ * This file is derived from IMX I2C controller,
+ * by Jean-Christophe DUBOIS .
+ *
+ * Thanks to Scott Wood and Alexander Graf for their kind help on this.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2 or later,
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+*/
+
+#include "qemu/osdep.h"
+// #include "hw/i2c/imx_i2c.h"
+#include "hw/i2c/i2c.h"
+#include "qemu/log.h"
+#include "hw/sysbus.h"
+
+/* #define DEBUG_I2C */
+
+#ifdef DEBUG_I2C
+#define DPRINTF(fmt, ...)  \
+do { fprintf(stderr, "mpc_i2c[%s]: " fmt, __func__, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define TYPE_MPC_I2C "mpc-i2c"
+#define MPC_I2C(obj) \
+OBJECT_CHECK(MPCI2CState, (obj), TYPE_MPC_I2C)
+
+#define MPC_I2C_ADR   0x00
+#define MPC_I2C_FDR   0x04
+#define MPC_I2C_CR0x08
+#define MPC_I2C_SR0x0c
+#define MPC_I2C_DR0x10
+#define MPC_I2C_DFSRR 0x14
+
+#define CCR_MEN  (1<<7)
+#define CCR_MIEN (1<<6)
+#define CCR_MSTA (1<<5)
+#define CCR_MTX  (1<<4)
+#define CCR_TXAK (1<<3)
+#define CCR_RSTA (1<<2)
+#define CCR_BCST (1<<0)
+
+#define CSR_MCF  (1<<7)
+#define CSR_MAAS (1<<6)
+#define CSR_MBB  (1<<5)
+#define CSR_MAL  (1<<4)
+#define CSR_SRW  (1<<2)
+#define CSR_MIF  (1<<1)
+#define CSR_RXAK (1<<0)
+
+#define CADR_MASK 0xFE
+#define CFDR_MASK 0x3F
+#define CCR_MASK  0xFC
+#define CSR_MASK  0xED
+#define CDR_MASK  0xFF
+
+#define CYCLE_RESET 0xFF
+
+typedef struct MPCI2CState {
+SysBusDevice parent_obj;
+
+I2CBus *bus;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint8_t address;
+uint8_t adr;
+uint8_t fdr;
+uint8_t cr;
+uint8_t sr;
+uint8_t dr;
+uint8_t dfssr;
+} 

[Qemu-devel] qemu bluetooth support

2019-03-02 Thread Daryl Oliver
Hello there I don't know if this is till valid but I thought I should
mention my use cases for the bluetooth option in qemu.

Use case would be using Bluetooth controllers for gaming on kvm qemu since
I don't know if kvm would be able to use my hosts Bluetooth chip or emulate
one. since I manily use the windows port of qemu.
But my other use case would be using Bluetooth speakers or headphones.


Re: [Qemu-devel] [PATCH] qom: remove type_initialize() in object_new_with_type()

2019-03-02 Thread Wei Yang
On Fri, Mar 01, 2019 at 10:33:46AM +0100, Igor Mammedov wrote:
>On Fri,  1 Mar 2019 15:44:48 +0800
>Wei Yang  wrote:
>
>> Here is the abstraction of current call flow of object_new_with_type()
>> 
>> object_initialize_with_type
>> type_initialize
>>  object_initialize_with_type
>>  type_initialize
>> 
>> This is not necessary to spread type_initialize in two places.
>> 
>> Signed-off-by: Wei Yang 
>> ---
>>  qom/object.c | 1 -
>>  1 file changed, 1 deletion(-)
>> 
>> diff --git a/qom/object.c b/qom/object.c
>> index b8c732063b..6252cca418 100644
>> --- a/qom/object.c
>> +++ b/qom/object.c
>> @@ -585,7 +585,6 @@ static Object *object_new_with_type(Type type)
>>  Object *obj;
>>  
>>  g_assert(type != NULL);
>> -type_initialize(type);
>>  
>>  obj = g_malloc(type->instance_size);
>>  object_initialize_with_type(obj, type->instance_size, type);
>Are you sure it's correct?
>
>see how type->instance_size
>

You are right, I thought the instance_size is initialized in type_new().
But this would be adjusted in type_initialize() again. 

>PS:
>there is also unit-tests which might detect issues in patches before
>one sends them. To execute them run: make  check
>

With this patch applied, I managed to run a guest successfully. Looks
this didn't catch some corner case. 

-- 
Wei Yang
Help you, Help me



[Qemu-devel] Forward-porting RTC device for eppc500 ?

2019-03-02 Thread Andrew Randrianasulu
Hello, all!

I stumbled upon this email from 2015 (trying to understand why my emulated 
ppce500 machine failed to set clock correctly:

https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02642.html

Now, after some quite blind trial-and-error I applied ('forward-ported') this 
patch to qemu git commit 0f6a6d5db853c0cbe438c1831c70710bfb6530ee without 
actually porting it to new qemu device abstraction model.

It seems to work!

But because I copy-pasted patch from web archive of list - some strings 
become "address@hidden", I hope I corrected them right?

---
diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index 52acb7cf39..a560971f0c 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -8,6 +8,8 @@ include usb.mak
 CONFIG_PPC4XX=y
 CONFIG_M48T59=y
 CONFIG_SERIAL=y
+CONFIG_MPC_I2C=y
+CONFIG_DS1338=y
 CONFIG_I8257=y
 CONFIG_OPENPIC=y
 CONFIG_PPCE500_PCI=y
diff --git a/hw/i2c/Makefile.objs b/hw/i2c/Makefile.objs
index cecee486f7..55473fc6b2 100644
--- a/hw/i2c/Makefile.objs
+++ b/hw/i2c/Makefile.objs
@@ -9,5 +9,6 @@ common-obj-$(CONFIG_EXYNOS4) += exynos4210_i2c.o
 common-obj-$(CONFIG_IMX_I2C) += imx_i2c.o
 common-obj-$(CONFIG_ASPEED_SOC) += aspeed_i2c.o
 common-obj-$(CONFIG_NRF51_SOC) += microbit_i2c.o
+common-obj-$(CONFIG_MPC_I2C) += mpc_i2c.o
 obj-$(CONFIG_OMAP) += omap_i2c.o
 obj-$(CONFIG_PPC4XX) += ppc4xx_i2c.o
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
new file mode 100644
index 00..54d7a9aabd
--- /dev/null
+++ b/hw/i2c/mpc_i2c.c
@@ -0,0 +1,360 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Amit Tomar, 
+ *
+ * Description:
+ * This file is derived from IMX I2C controller,
+ * by Jean-Christophe DUBOIS .
+ *
+ * Thanks to Scott Wood and Alexander Graf for their kind help on this.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2 or later,
+ * as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+*/
+
+#include "qemu/osdep.h"
+// #include "hw/i2c/imx_i2c.h"
+#include "hw/i2c/i2c.h"
+#include "qemu/log.h"
+#include "hw/sysbus.h"
+
+/* #define DEBUG_I2C */
+
+#ifdef DEBUG_I2C
+#define DPRINTF(fmt, ...)  \
+do { fprintf(stderr, "mpc_i2c[%s]: " fmt, __func__, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#define TYPE_MPC_I2C "mpc-i2c"
+#define MPC_I2C(obj) \
+OBJECT_CHECK(MPCI2CState, (obj), TYPE_MPC_I2C)
+
+#define MPC_I2C_ADR   0x00
+#define MPC_I2C_FDR   0x04
+#define MPC_I2C_CR0x08
+#define MPC_I2C_SR0x0c
+#define MPC_I2C_DR0x10
+#define MPC_I2C_DFSRR 0x14
+
+#define CCR_MEN  (1<<7)
+#define CCR_MIEN (1<<6)
+#define CCR_MSTA (1<<5)
+#define CCR_MTX  (1<<4)
+#define CCR_TXAK (1<<3)
+#define CCR_RSTA (1<<2)
+#define CCR_BCST (1<<0)
+
+#define CSR_MCF  (1<<7)
+#define CSR_MAAS (1<<6)
+#define CSR_MBB  (1<<5)
+#define CSR_MAL  (1<<4)
+#define CSR_SRW  (1<<2)
+#define CSR_MIF  (1<<1)
+#define CSR_RXAK (1<<0)
+
+#define CADR_MASK 0xFE
+#define CFDR_MASK 0x3F
+#define CCR_MASK  0xFC
+#define CSR_MASK  0xED
+#define CDR_MASK  0xFF
+
+#define CYCLE_RESET 0xFF
+
+typedef struct MPCI2CState {
+SysBusDevice parent_obj;
+
+I2CBus *bus;
+qemu_irq irq;
+MemoryRegion iomem;
+
+uint8_t address;
+uint8_t adr;
+uint8_t fdr;
+uint8_t cr;
+uint8_t sr;
+uint8_t dr;
+uint8_t dfssr;
+} MPCI2CState;
+
+static bool mpc_i2c_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MEN;
+}
+
+static bool mpc_i2c_is_master(MPCI2CState *s)
+{
+return s->cr & CCR_MSTA;
+}
+
+static bool mpc_i2c_direction_is_tx(MPCI2CState *s)
+{
+return s->cr & CCR_MTX;
+}
+
+static bool mpc_i2c_irq_pending(MPCI2CState *s)
+{
+return s->sr & CSR_MIF;
+}
+
+static bool mpc_i2c_irq_is_enabled(MPCI2CState *s)
+{
+return s->cr & CCR_MIEN;
+}
+
+static void mpc_i2c_reset(DeviceState *dev)
+{
+MPCI2CState *i2c = MPC_I2C(dev);
+
+i2c->address = 0xFF;
+i2c->adr = 0x00;
+i2c->fdr = 0x00;
+i2c->cr =  0x00;
+i2c->sr =  0x81;
+i2c->dr =  0x00;
+}
+
+static void mpc_i2c_irq(MPCI2CState *s)
+{
+bool irq_active = false;
+
+if (mpc_i2c_is_enabled(s) && mpc_i2c_irq_is_enabled(s)
+  && mpc_i2c_irq_pending(s)) {
+irq_active = true;
+}
+
+if (irq_active) {
+qemu_irq_raise(s->irq);
+} else {
+qemu_irq_lower(s->irq);
+}
+}
+
+static void mpc_i2c_soft_reset(MPCI2CState *s)
+{
+/* This is a soft reset. ADR is preserved during soft resets */
+uint8_t adr = s->adr;
+mpc_i2c_reset(DEVICE(s));
+s->adr = adr;
+}
+
+static void  mpc_i2c_address_send(MPCI2CState *s)
+{
+/* if returns non zero slave address is not right */
+if 

Re: [Qemu-devel] [PATCH v5 1/2] CODING_STYLE: specify the indent rule for multiline code

2019-03-02 Thread Wei Yang
On Fri, Mar 01, 2019 at 10:55:22AM +0100, Stefano Garzarella wrote:
>On Fri, Mar 01, 2019 at 10:01:46AM +0800, Wei Yang wrote:
>> We didn't specify the indent rule for multiline code here, which may
>> mislead users. And in current code, the code use various styles.
>> 
>> Add this rule in CODING_STYLE to make sure this is clear to every one.
>> 
>> Signed-off-by: Wei Yang 
>> Suggested-by: Igor Mammedov 
>> 
>> ---
>> v5:
>>* different rules -> various styles
>>* describe function variants separately
>>* take struct out
>> v4:
>>* widths -> width
>>* add an exception example for function
>> v3:
>>* misleading -> mislead
>>* add comma after arg2 in example
>> v2:
>>* rephrase changelog suggested by Eric Blake
>>  - remove one redundant line
>>  - fix some awkward grammar
>>  - add { ; at the end of example
>> ---
>>  CODING_STYLE | 39 +++
>>  1 file changed, 39 insertions(+)
>> 
>> diff --git a/CODING_STYLE b/CODING_STYLE
>> index ec075dedc4..e175e6ea9a 100644
>> --- a/CODING_STYLE
>> +++ b/CODING_STYLE
>> @@ -29,6 +29,45 @@ Spaces of course are superior to tabs because:
>>  
>>  Do not leave whitespace dangling off the ends of lines.
>>  
>> +1.1 Multiline Indent
>> +
>> +There are several places where indent is necessary:
>> +
>> + - if/else
>> + - while/for
>> + - function definition & call
>> +
>> +When breaking up a long line to fit within line width, we need a proper 
>> indent
>> +for the following lines.
>> +
>> +In case of if/else, while/for, align the secondary lines just after the
>> +opening parenthesis of the first.
>> +
>> +For example:
>> +
>> +if (a == 1 &&
>> +b == 2) {
>> +
>> +while (a == 1 &&
>> +   b == 2) {
>> +
>> +In case of function, there are several variants:
>> +
>> +* 4 spaces indent from the beginning
>> +* align the secondary lines just after the opening parenthesis of the
>> +  first
>> +
>> +For example:
>> +
>> +do_something(x, y,
>> +z);
>> +
>> +do_something(x, y,
>> + z);
>> +
>> +do_something(x, do_another(y,
>> +   z);
>
>Should we close another parenthesis after the "z"?
>

:-(

>The rest LGTM!
>
>Thanks,
>Stefano

-- 
Wei Yang
Help you, Help me



Re: [Qemu-devel] [PULL 13/76] pvh: Add x86/HVM direct boot ABI header file

2019-03-02 Thread Stefano Garzarella
On Fri, Mar 01, 2019 at 05:56:36PM +, Alex Bennée wrote:
> 
> Stefano Garzarella  writes:
> 
> > On Fri, Mar 01, 2019 at 04:53:57PM +, Alex Bennée wrote:
> >>
> >> Paolo Bonzini  writes:
> >>
> >> > From: Liam Merwick 
> >> >
> >> > The x86/HVM direct boot ABI permits Qemu to be able to boot directly
> >> > into the uncompressed Linux kernel binary with minimal firmware 
> >> > involvement.
> >> >
> >> >  https://xenbits.xen.org/docs/unstable/misc/pvh.html
> >> >
> >> > This commit adds the header file that defines the start_info struct
> >> > that needs to be populated in order to use this ABI.
> >> >
> >> > The canonical version of start_info.h is in the Xen codebase.
> >> > (like QEMU, the Linux kernel uses a copy as well).
> >> >
> >> > Signed-off-by: Liam Merwick 
> >> > Reviewed-by: Konrad Rzeszutek Wilk 
> >> > Signed-off-by: Paolo Bonzini 
> >>
> >> This has changed behaviour of a boot. Previously:
> >>
> >>   qemu-system-i386 -serial mon:stdio -nographic -device \
> >>  isa-debugcon,chardev=serial0 -kernel ./tests/hello
> >>
> >
> > Hi Alex,
> > is your image in multiboot format?
> 
> AFAICT yes, I'm not super familiar with x86 so I'm mostly cribbing from:
> 
>   https://github.com/doug65536/qemu-bmibug
> 
> > I sent a patch few weeks ago that fix the loading of multiboot images:
> > https://www.mail-archive.com/qemu-devel@nongnu.org/msg596424.html
> 
> That certainly fixes things. Although I'm wondering if it's worth making
> my test image PVH compatible anyway (if it's easy to do) as all I really
> want to do is exercise the softmmu code. It might be simpler to use
> paravirtualised serial ports rather than banging an IO port, IDK?

I don't have a lot of experience too, but I don't think there are a lot
of differences in terms of how to use ports.

Multiboot and PVH change the way how to jump to your image.
Both provide a structure where your image can found the e820 memory map and
PVH provides also the RSDP (ACPI) pointer.

Maybe create a PVH image should be simpler because you only need to put in the
ELF note the entry point of your ELF image. Then, EBX will contain the address
of start_info structure (where you can find the e820 mmap).

You can take a look of this file in Linux: arch/x86/platform/pvh/head.S

I hope this can help :)

Cheers,
Stefano



Re: [Qemu-devel] [PATCH] hw/arm/acpi: enable SHPC native hot plug

2019-03-02 Thread Heyi Guo




On 2019/3/1 23:49, Michael S. Tsirkin wrote:

On Fri, Mar 01, 2019 at 03:33:11PM +0100, Igor Mammedov wrote:

On Fri, 1 Mar 2019 09:12:33 -0500
"Michael S. Tsirkin"  wrote:


On Fri, Mar 01, 2019 at 10:04:38PM +0800, Heyi Guo wrote:


On 2019/3/1 21:47, Michael S. Tsirkin wrote:

On Fri, Mar 01, 2019 at 10:28:30AM +0800, Heyi Guo wrote:

After the introduction of generic PCIe root port and PCIe-PCI bridge,
we will also have SHPC controller on ARM, so just enalbe SHPC native
hot plug.

Cc: Shannon Zhao 
Cc: Peter Maydell 
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
Signed-off-by: Heyi Guo 
Signed-off-by: Heyi Guo 

So when OS enables SHPC, should we block ACPI hotplug events?

I supposed we don't support ACPI hotplug events on ARM virt; do we have any 
currently?

Thanks,
Heyi

Oh I didn't realise. That explains it sorry about the noise.

And I thought we did not support them on PCIe completely (I mean q35/ich9).
(Or did I miss something)?

True for PCIe.

So may I consider your comments as ACK for this patch :)

Thanks,
Heyi

   

---
   hw/arm/virt-acpi-build.c | 7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 04b62c7..7849ec5 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -265,7 +265,12 @@ static void acpi_dsdt_add_pci(Aml *scope, const 
MemMapEntry *memmap,
   aml_create_dword_field(aml_arg(3), aml_int(8), "CDW3"));
   aml_append(ifctx, aml_store(aml_name("CDW2"), aml_name("SUPP")));
   aml_append(ifctx, aml_store(aml_name("CDW3"), aml_name("CTRL")));
-aml_append(ifctx, aml_store(aml_and(aml_name("CTRL"), aml_int(0x1D), NULL),
+
+/*
+ * Allow OS control for all 5 features:
+ * PCIeHotplug SHPCHotplug PME AER PCIeCapability.
+ */
+aml_append(ifctx, aml_store(aml_and(aml_name("CTRL"), aml_int(0x1F), NULL),
   aml_name("CTRL")));
   ifctx1 = aml_if(aml_lnot(aml_equal(aml_arg(1), aml_int(0x1;
--
1.8.3.1

.
   
   

.