From: Philippe Mathieu-Daudé
Similar to the x86_64/pc test, it boots a Linux kernel on an
Emcraft board and verify the serial is working.
If ARM is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:arm" tags.
Alternatively, this test can
On Wed, Jun 5, 2019 at 3:59 PM Hesham Almatary
wrote:
>
> On Wed, 5 Jun 2019 at 23:07, Alistair Francis wrote:
> >
> > On Thu, May 30, 2019 at 6:52 AM Hesham Almatary
> > wrote:
> > >
> > > The PMP should be checked when doing a page table walk, and report access
> > > fault exception if the to-
From: Philippe Mathieu-Daudé
Avoid to log empty lines in console debug logs.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alistair Francis
Reviewed-by: Cleber Rosa
Tested-by: Cleber Rosa
Acked-by: Aleksandar Markovic
---
v2: no change
---
tests/acceptance/boot_linux_console.py | 6 ++
*** This bug is a duplicate of bug 1805256 ***
https://bugs.launchpad.net/bugs/1805256
** This bug has been marked a duplicate of bug 1805256
qemu-img hangs on high core count ARM system
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
On Fri, May 31, 2019 at 3:38 PM Jonathan Behrens wrote:
>
> I've thought some more about this issue, and long term I think there are a
> couple different useful configurations:
>
> For end users, having default firmware that loaded the OS from a block device
> would be easiest
>
> Current invoca
Hi,
I added test guide lines from Subbaraya Sundeep [*] to avoid this
board to bitrot.
v2: Addressed issues reported by Cleber
Regards,
Phil.
[*] https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg03810.html
Philippe Mathieu-Daudé (2):
BootLinuxConsoleTest: Do not log empty lines
Bo
On 6/6/19 5:43 PM, Alex Bennée wrote:
> While size_t is defined to happily access the biggest host object this
> isn't the case when generating masks for 64 bit guests on 32 bit
> hosts. Otherwise we end up truncating the address when we fall back to
> our unaligned helper.
>
> Cc: Andrew Randrian
On Fri, Jun 07, 2019 at 12:55:21AM +0200, Philippe Mathieu-Daudé wrote:
> From: Philippe Mathieu-Daudé
>
> Similar to the x86_64/pc test, it boots a Linux kernel on an
> Emcraft board and verify the serial is working.
>
> If ARM is a target being built, "make check-acceptance" will
> automatical
Hi,
On 6/5/19 9:15 PM, Lidong Chen wrote:
> Due to an off-by-one error, the assert statements allow an
> out-of-bound array access.
I believe this is a "v2 RESEND" patch, since there is no change with the
other v2 posted here:
https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg00634.html
So
On 6/5/19 9:15 PM, Lidong Chen wrote:
> The check for poll_fds in g_assert() was incorrect. The correct assertion
> should check "n_poll_fds + w->num <= ARRAY_SIZE(poll_fds)" because the
> subsequent for-loop is doing access to poll_fds[n_poll_fds + i] where i
> is in [0, w->num).
>
> Signed-off-b
Hi Alex,
On 6/6/19 10:29 AM, Alex Bennée wrote:
> As I've been reviewing a lot of this recently and I'm going to put
> together a pull request I'd better keep an eye on it.
>
> Signed-off-by: Alex Bennée
> ---
> MAINTAINERS | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --g
Hello,
As a test of the waters, how would the QEMU community feel about
including the RISC-V OpenSBI project as a ROM submodule?
The idea would be to have OpenSBI (similar to ATF for ARM and a BIOS
for x86) included by default to simplify the QEMU RISC-V boot process
for users. This would remove
On Fri, Jun 07, 2019 at 01:02:32AM +0200, Philippe Mathieu-Daudé wrote:
> From: Philippe Mathieu-Daudé
>
> This tests boots a Linux kernel on a Malta machine up to a
> busybox shell on the serial console. Few commands are executed
> before halting the machine (via reboot).
>
> We use the initrd
Hi Eddie,
On 6/4/19 12:09 AM, Eddie James wrote:
> The XDMA engine embedded in the Aspeed SOCs performs PCI DMA operations
> between the SOC (acting as a BMC) and a host processor in a server.
If I got your model correctly, it does no DMA operation but simply
answer correctly to the BMC, and set
Altering all comments in target/m68k to match Qemu coding styles so that future
patches wont fail due to style breaches.
Signed-off-by: Lucien Murray-Pitts
---
Notes:
v1->v2
- incorrectly made split-single line comments multiple single lines
- added corrections for /** comments as
В сообщении от Thursday 06 June 2019 20:04:07 Alex Bennée написал(а):
>
> Andrew Randrianasulu writes:
>
> > В сообщении от Thursday 06 June 2019 18:43:10 Alex Bennée написал(а):
> >> addr1 = addr & ~((target_ulong)size - 1);
> >
> > yes, this fixes my hang! Thanks!
>
> Can I take that as a:
>
On Jun 7, 2019 1:42 AM, "Lucien Murray-Pitts"
wrote:
>
> Altering all comments in target/m68k to match Qemu coding styles so that
future
> patches wont fail due to style breaches.
>
Are you saying that patches fail checkpatch checks even if the new code has
only correct comment format? (Or, in ot
On Jun 7, 2019 1:06 AM, "Philippe Mathieu-Daudé" wrote:
>
> From: Philippe Mathieu-Daudé
>
> This tests boots a Linux kernel on a Malta machine up to a
> busybox shell on the serial console. Few commands are executed
> before halting the machine (via reboot).
>
> We use the initrd cpio image from
On Thu, Jun 06, 2019 at 07:44:09PM +0200, Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt
>
> It should be generic Hypervisor Virtualization interrupts for HV
> directed rings and traditional External Interrupts for the OS directed
> ring.
>
> Don't generate anything for the user ring as
On Thu, Jun 06, 2019 at 07:47:32PM +0200, Cédric Le Goater wrote:
> This is a good way to debug the DT creation for current PowerNV
> machines and new ones to come.
>
> Signed-off-by: Cédric Le Goater
Applied, thanks.
> ---
> hw/ppc/pnv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --g
On Thu, Jun 06, 2019 at 07:08:59PM +0200, Greg Kurz wrote:
> If KVM is too old to support XIVE native exploitation mode, we might end
> up using the emulated XIVE after CAS. This is sub-optimal if KVM in-kernel
> XICS is available, which is the case most of the time.
This is intentional. A predic
On Thu, Jun 06, 2019 at 04:55:18PM +0530, Aravinda Prasad wrote:
>
>
> On Thursday 06 June 2019 08:36 AM, David Gibson wrote:
> > On Wed, May 29, 2019 at 11:10:57AM +0530, Aravinda Prasad wrote:
> >> This patch includes migration support for machine check
> >> handling. Especially this patch bloc
On Thu, Jun 06, 2019 at 02:10:48PM +0200, Greg Kurz wrote:
> On Thu, 6 Jun 2019 16:45:30 +0530
> Aravinda Prasad wrote:
>
> > On Thursday 06 June 2019 11:36 AM, Greg Kurz wrote:
> > > On Thu, 6 Jun 2019 13:06:14 +1000
> > > David Gibson wrote:
> > >
> > >> On Wed, May 29, 2019 at 11:10:57AM +
I'm Ian Kelling, part of the FSF tech team that maintains the
lists.nongnu.org server.
The server is sending mail using a new ip which is causing a higher than
average number of mail servers telling us to retry and send later as
they hopefully decide we are legitimate. The only big provider doing
On 6/6/19 1:41 PM, John Snow wrote:
> This simply makes this function a little more convenient to call, and in
> a forthcoming patch gives us a return code we can report to the
> caller. (Which in turn makes THOSE functions easier to call.)
>
> While we're here, remove the offset+size arguments wh
On 6/6/19 1:41 PM, John Snow wrote:
> Instead of bdrv_can_store_new_bitmap, rework this as
> bdrv_add_persistent_dirty_bitmap. This makes a more obvious symmetry
> with bdrv_remove_persistent_dirty_bitmap. Most importantly, we are free
> to modify the driver state because we know we ARE adding a bi
On 6/6/19 1:41 PM, John Snow wrote:
> Allow propagating error code information from
> bdrv_remove_persistent_dirty_bitmap as well.
>
> Give it an interface that matches the newly revised
> bdrv_add_persistent_dirty_bitmap, including removing the persistent flag
> when the operation succeeds and re
On 6/6/19 1:41 PM, John Snow wrote:
> When we check to see if we can store a bitmap, we don't check how many
> we've queued up. This can cause a problem saving bitmaps on close
> instead of when we request them to be added. With the stricter add
> interface, prohibit these bitmaps specifically.
>
On 6/6/19 1:41 PM, John Snow wrote:
> Similarly to the previous commit, we need to also keep a ledger of the
> additional directory size burden that we've not yet committed so we can
> reject new additions sooner instead of later.
>
> Signed-off-by: John Snow
> ---
> block/qcow2.h| 1 +
On 4/11/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> nbd_client_connect is going to be used from connection_co, so, let's
> refactor nbd_client_connect in advance, leaving io channel
> configuration all in nbd_client_connect.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/nb
On 4/11/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> No reason to use blocking channel for negotiation and we'll benefit in
> further reconnect feature, as qio_channel reads and writes will do
> qemu_coroutine_yield while waiting for io completion.
>
> Signed-off-by: Vladimir Sementsov-Ogiev
On 4/11/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> To implement reconnect we need several states for the client:
> CONNECTED, QUIT and two different CONNECTING states. CONNECTING states
> will be added in the following patches. This patch implements CONNECTED
> and QUIT.
>
> QUIT means, th
On 4/11/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> Reconnect will be implemented in the following commit, so for now,
> in semantics below, disconnect itself is a "serious error".
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> qapi/block-core.json | 12 +++-
> block/nbd-
>
> Also, unless I'm misunderstanding something our implementation of LR/SC is
>
pretty broken. We're just using a CAS to check if the value changed, which
> suffers from the ABA problem that LR/SC is there to fix in the first
> place. I
> might be missing something here, though, as it looks like
On 4/11/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> Introduce a function to gracefully wake-up a coroutine, sleeping in
> qemu_co_sleep_ns() sleep.
Maybe:
Introduce a function to gracefully short-circuit the remainder of the
delay for a coroutine sleeping in qemu_co_sleep_ns().
>
> Signe
On 4/11/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> Implement reconnect. To achieve this:
>
> 1. add new modes:
>connecting-wait: means, that reconnecting is in progress, and there
> were small number of reconnect attempts, so all requests are
> waiting for the connection.
>
On Fri, Feb 01, 2019 at 11:10:31AM -0500, Cleber Rosa wrote:
>
>
> On 1/31/19 4:26 PM, Cleber Rosa wrote:
> >
> >
> > On 1/31/19 3:21 PM, Cleber Rosa wrote:
> >>
> >>
> >> On 1/31/19 3:02 PM, Wainer dos Santos Moschetta wrote:
> >>>
> >>> On 01/17/2019 04:56 PM, Cleber Rosa wrote:
> Just l
On Fri, Jun 07, 2019 at 01:58:05AM +0200, Aleksandar Markovic wrote:
> On Jun 7, 2019 1:42 AM, "Lucien Murray-Pitts"
> wrote:
> >
> > Altering all comments in target/m68k to match Qemu coding styles so that
> future
> > patches wont fail due to style breaches.
> >
>
> Are you saying that patches
On Fri, Jun 07, 2019 at 12:26:48AM -0300, Eduardo Habkost wrote:
> On Fri, Feb 01, 2019 at 11:10:31AM -0500, Cleber Rosa wrote:
> >
> >
> > On 1/31/19 4:26 PM, Cleber Rosa wrote:
> > >
> > >
> > > On 1/31/19 3:21 PM, Cleber Rosa wrote:
> > >>
> > >>
> > >> On 1/31/19 3:02 PM, Wainer dos Santos
Hi,
This series gives me several compilation errors.
When compiled with --disable-werror, OSX 10.3 guest on qemu-system-ppc
shows corrupted desktop graphics.
Compiled with:
./configure --target-list="ppc-softmmu" --enable-sdl --enable-gtk && make
-j8
gcc is:
[hsp@fedora30 qemu-master]$ gcc -v
U
Hi,
On Thu, Jun 06, 2019 at 03:30:29PM +0200, Marc-André Lureau wrote:
> Hi
>
> On Fri, Apr 26, 2019 at 8:32 AM Tiwei Bie wrote:
> >
> > We need to destroy the host notifiers when cleaning up
> > the backend. Otherwise, some resources are not released
> > after the connection is closed, and it m
301 - 341 of 341 matches
Mail list logo
