12.10.2017 21:58, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the file protocol driver accordingly.
In want_zero mode, we continue to report fine-grained hole
information (the caller wants as much mapping detail as possible);
but when
Hi,
After 3 months of work and investigation, and tedious mail discussions with
Nvidia, I think some progress have been made, in terms of the
GPUDirect(p2p) in virtual environment.
The only remaining issue then, is the low bidirectional bandwidth between
two sibling GPUs under the same PCIe switc
hello, i try again on arch Linux , after i add gpu, display is not
light,following message from "info pci":
Bus 0, device 5, function 0:
VGA controller: PCI device 10de:1401
IRQ 11.
BAR0: 32 bit memory at 0x [0x00fe].
BAR1: 64 bit prefetchable memory
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the gluster driver accordingly.
In want_zero mode, we continue to report fine-grained hole
information (the caller wants as much mapping detail as possible);
but when not in
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the null driver accordingly.
Signed-off-by: Eric Blake
---
v4: rebase to interface tweak
v3: no change
v2: rebase to mapping parameter
---
block/null.c | 23
If the guest continuesly writes characters to the UART, we never leave
the inner while loop and thus never check whether we've reached the
timeout value. So if we fail to find the expected string in the UART
output, the test just hangs and never finishs. Use a counter to regularly
break out of the
Now that moxiesim supports the -bios parameter, we can check this machine
in the boot-serial tester, too, by supplying a mini bios that only writes
'T' characters to the UART.
Signed-off-by: Thomas Huth
---
tests/Makefile.include | 2 ++
tests/boot-serial-test.c | 8
2 files changed,
The moxiesim machine already defines a memory region for a firmware,
but does not provide the possibility to load an image via "-bios" yet.
This will be needed for the boot-serial tester, so let's add support
for "-bios" here now.
Signed-off-by: Thomas Huth
---
hw/moxie/moxiesim.c | 12 +
We can output a character quite easily here with some few lines of
assembly that we provide as a mini-kernel for this board.
Signed-off-by: Thomas Huth
---
tests/boot-serial-test.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
During the 2.11 development cycle, a bunch of ARM boards were broken
completely, and nobody noticed it for a couple of weeks. Also a lot
of TCG CPUs do not get any test coverage at all yet (especially since
the old tests in the tests/tcg/ are still pretty much dead today).
So we really should impro
The raspi2 machine supports loading firmware images, so we can easily
load a small test sequence as raw binary blob here to test the UART.
Signed-off-by: Thomas Huth
---
tests/Makefile.include | 1 +
tests/boot-serial-test.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/tests/
QEMU only ships with some few firmware images, i.e. we can currently run
the boot-serial test only on a very limited set of machines. But writing
some characters to the default UART of a machine can often be done with
some few lines of assembly, so we add the possibility to the boot-serial
tester t
This adds two simple TCG + UART tests for the microblaze boards,
one in big endian mode, and one in little endian mode.
Signed-off-by: Thomas Huth
---
tests/Makefile.include | 2 ++
tests/boot-serial-test.c | 20
2 files changed, 22 insertions(+)
diff --git a/tests/Makef
On 29.11.2017 21:26, David Hildenbrand wrote:
> Allows to easily convert more callers of program_interrupt() and to
> easily introduce new exceptions without forgetting about the cpu state
> reset.
>
> Use s390_program_interrupt() in places where we already had the same
> pattern. We will later ge
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the parallels driver accordingly. Note that
the internal function block_status() is still sector-based, because
it is still in use by other sector-based functions; but that'
On 29.11.2017 21:26, David Hildenbrand wrote:
> Let's use s390_program_interrupt() instead.
>
> Reviewed-by: Richard Henderson
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/fpu_helper.c | 2 +-
> target/s390x/int_helper.c | 14 +++---
> target/s390x/internal.h| 2 --
>
On Thu, Nov 30, 2017 at 01:22:38PM +0800, Liu, Yi L wrote:
> On Tue, Nov 14, 2017 at 06:13:50PM -0500, prasad.singamse...@oracle.com wrote:
> > From: Prasad Singamsetty
> >
> > The current implementation of Intel IOMMU code only supports 39 bits
> > iova address width. This patch provides a new p
+-- On Wed, 29 Nov 2017, Cornelia Huck wrote --+
| I think the basic problem is still that you conflate two things:
| - vring.num, which cannot be flipped between 0 and !0 by the guest
| - vring.{desc,avail,used}, which can
|
| IOW, if vring.num == 0, the guest cannot manipulate the queue; if
| vr
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the qcow driver accordingly. There is no
intent to optimize based on the want_zero flag for this format.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievs
On 2017/11/29 21:35, Roman Kagan wrote:
> On Wed, Nov 29, 2017 at 07:58:19PM +0800, Longpeng (Mike) wrote:
>> On 2017/11/29 18:41, Eduardo Habkost wrote:
>>> On Wed, Nov 29, 2017 at 01:20:38PM +0800, Longpeng (Mike) wrote:
On 2017/11/29 5:13, Eduardo Habkost wrote:
> On Tue, Nov 28, 201
On Wed, 29 Nov 2017 23:14:27 +0530
P J P wrote:
> From: Prasad J Pandit
>
> A guest could attempt to use an uninitialised VirtQueue object
> or unset Vring.align leading to a arithmetic exception. Add check
> to avoid it.
>
> Reported-by: Zhangboxian
> Signed-off-by: Prasad J Pandit
> ---
>
On Wed, 11/29 12:00, Stefan Hajnoczi wrote:
> On Wed, Nov 29, 2017 at 11:55:02AM +0800, Fam Zheng wrote:
> > As we move forwards with new features in the block layer, the chances of
> > tricky
> > bugs happening have been increasing alongside - block jobs, coroutines,
> > throttling, AioContext, o
On Wed, 29 Nov 2017 19:51:23 +0100
Christian Borntraeger wrote:
> On 11/28/2017 03:45 PM, Cornelia Huck wrote:
> > On Tue, 28 Nov 2017 15:17:49 +0100
> > Christian Borntraeger wrote:
> >
> >> On 11/28/2017 03:01 PM, Cornelia Huck wrote:
> >>> On Tue, 28 Nov 2017 14:25:08 +0100
> >>> Christi
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the qcow2 driver accordingly.
For now, we are ignoring the 'want_zero' hint. However, it should
be relatively straightforward to honor the hint as a way to return
larger *p
On 29.11.2017 21:26, David Hildenbrand wrote:
> TCG needs the retaddr when injecting an interrupt. Let's just pass it
> along and use RA_IGNORED for KVM. The value will be completely ignored for
> KVM.
>
> Convert program_interrupt() to s390_program_interrupt() directly, making
> use of the passed
On 29.11.2017 21:26, David Hildenbrand wrote:
> Once we wire up TCG, we will need the retaddr to correctly inject
> program interrupts. As we want to get rid of the function
> program_interrupt(), convert PCI code too.
>
> For KVM, we can simply use RA_IGNORED.
>
> Convert program_interrupt() to
On Thu, Nov 30, 2017 at 05:11:55PM +0800, Peter Xu wrote:
> On Thu, Nov 30, 2017 at 01:22:38PM +0800, Liu, Yi L wrote:
> > On Tue, Nov 14, 2017 at 06:13:50PM -0500, prasad.singamse...@oracle.com
> > wrote:
> > > From: Prasad Singamsetty
> > >
> > > The current implementation of Intel IOMMU code
On Thu, Nov 23, 2017 at 02:29:47PM +0100, Cédric Le Goater wrote:
> The XIVE object is designed to be always available, so it is created
> unconditionally on newer machines.
There doesn't actually seem to be anything dependent on machine
version here.
> Depending on the configuration and
> the gu
On Sun, Nov 26, 2017 at 03:59:03PM -0600, Michael Davidsaver wrote:
> Support for: ds1307, ds1337, ds1338, ds1339,
> ds1340, ds1375, ds1388, and ds3231.
>
> Tested with ds1338 and ds1375.
>
> Signed-off-by: Michael Davidsaver
I certainly like the idea of consolidating this code, but reviewing t
On Thu, Nov 30, 2017 at 06:11:26AM +, Huang, Haibin wrote:
> unsubscribe qemu-devel
FYI, this is the wrong email address to use for unsubscribing. You instead
need
qemu-devel-requ...@nongnu.org
Alternatively, there is a web UI that lets you do it:
https://lists.nongnu.org/mailman/listi
* Peter Xu (pet...@redhat.com) wrote:
> If the postcopy down due to some reason, we can always see this on dst:
>
> qemu-system-x86_64: RP: Received invalid message 0x length 0x
>
> However in most cases that's not the real issue. The problem is that
> qemu_get_be16() has no way to show
On 30/11/2017 6:02, David Gibson wrote:
On Wed, Nov 29, 2017 at 12:38:00PM +0200, Marcel Apfelbaum wrote:
On 29/11/2017 10:46, David Gibson wrote:
include/hw/pci/pci_bus.h is now very small and can only safely be included
after hw/pci/pci.h. So, just fold it into pci.h.
I don't get the bene
This might be related to this fix:
>
https://git.qemu.org/?p=qemu.git;a=commit;h=8bf8e9df4a7d82c7a47cc961c9cdee1615595de0
FWIW, if you're interested in sh4, please join #debian-ports on OFTC and
subscribe to the debian-superh mailing list. We're doing lots of sh4
development and testing QEMU in D
Public bug reported:
Some of the recent changes introduced a regression which makes the
OpenJDK JVM crash on qemu-sh4:
(sid-sh4-sbuild)root@nofan:/# java -version
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
(sid-sh4-sbuild)root@nofan:/#
An older version
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the qed driver accordingly, taking the opportunity
to inline qed_is_allocated_cb() into its lone caller (the callback
used to be important, until we switched qed to coroutine
This might be related to this fix:
>
https://git.qemu.org/?p=qemu.git;a=commit;h=8bf8e9df4a7d82c7a47cc961c9cdee1615595de0
FWIW, if you're interested in sh4, please join #debian-ports on OFTC and
subscribe to the debian-superh mailing list. We're doing lots of sh4
development and testing QEMU in D
Am 30.11.2017 um 03:03 hat Fam Zheng geschrieben:
> On Wed, 11/29 18:25, Kevin Wolf wrote:
> > Am 29.11.2017 um 15:49 hat Fam Zheng geschrieben:
> > > While we look at the fixes for 2.11, I briefly prototyped this series
> > > to see if it makes sense as a simplification of the drain API for
> > >
Wei Wang wrote:
> /**
> + * xb_clear_bit - clear a range of bits in the xbitmap
Name mismatch.
> + * @start: the start of the bit range, inclusive
> + * @end: the end of the bit range, inclusive
> + *
> + * This function is used to clear a bit in the xbitmap. If all the bits of
> the
> + * bitm
Wei Wang wrote:
> +static inline int xb_set_page(struct virtio_balloon *vb,
> +struct page *page,
> +unsigned long *pfn_min,
> +unsigned long *pfn_max)
> +{
> + unsigned long pfn = page_to_pfn(page);
> + int
* Peter Xu (pet...@redhat.com) wrote:
> Now when network down for postcopy, the source side will not fail the
> migration. Instead we convert the status into this new paused state, and
> we will try to wait for a rescue in the future.
>
> If a recovery is detected, migration_thread() will reset it
On 29.11.2017 21:26, David Hildenbrand wrote:
> s390_cpu_virt_mem_rw() must always return, so callers can react on
> an exception (e.g. see ioinst_handle_stcrw()).
>
> However, for TCG we always have to exit the cpu loop (and restore the
> cpu state before that) if we injected a program interrupt.
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the raw driver accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the sheepdog driver accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimir
12.10.2017 21:59, Eric Blake wrote:
Rework the debug define so that we always get -Wformat checking,
even when debugging is disabled.
Signed-off-by: Eric Blake
Reviewed-by: Stefan Weil
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Vladimir Sementsov-Ogievskiy
--
Best regards,
Vladimi
* Peter Xu (pet...@redhat.com) wrote:
> When there is IO error on the incoming channel (e.g., network down),
> instead of bailing out immediately, we allow the dst vm to switch to the
> new POSTCOPY_PAUSE state. Currently it is still simple - it waits the
> new semaphore, until someone poke it for
On Wed, 29 Nov 2017 18:50:19 +
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> Hi,
> This is an experimental set that reworks the way the vhost
> code handles changes in physical address space layout that
> came from a discussion with Igor.
Thanks for looking in
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the vdi driver accordingly. Note that the
TODO is already covered (the block layer guarantees bounds of its
requests), and that we can remove the now-unused s->block_sectors
On Wed, 29 Nov 2017 18:50:23 +
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> Add the meat of update_mem_cb; this is called for each region,
> to add a region to our temporary list.
> Our temporary list is in order we look to see if this
> region can be merged w
On 29.11.2017 21:26, David Hildenbrand wrote:
> s390_cpu_virt_mem_rw() must always return, so callers can react on
> an exception (e.g. see ioinst_handle_stcrw()).
>
> Therefore, using program_interrupt() is wrong. Fix that up.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mmu_helpe
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the vmdk driver accordingly.
Signed-off-by: Eric Blake
---
v4: rebase to interface tweak
v3: no change
v2: rebase to mapping flag
---
block/vmdk.c | 28 +
On 29.11.2017 21:26, David Hildenbrand wrote:
> Now we can drop potential_page_fault(). While at it, move the
> unlock further up, looks cleaner.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/misc_helper.c | 5 ++---
> target/s390x/translate.c | 1 -
> 2 files changed, 2 insertions
On 29.11.2017 21:26, David Hildenbrand wrote:
> Now we can drop the two save statements in the translate function.
>
> Reviewed-by: Richard Henderson
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/misc_helper.c | 2 +-
> target/s390x/translate.c | 3 ---
> 2 files changed, 1 insertio
On 29.11.2017 21:26, David Hildenbrand wrote:
> Convert this user, too.
>
> Reviewed-by: Richard Henderson
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/cc_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/s390x/cc_helper.c b/target/s390x/cc_hel
On 29.11.2017 21:26, David Hildenbrand wrote:
> STSI needs some more love, but let's do one step at a time.
> We can now drop potential_page_fault().
>
> Reviewed-by: Richard Henderson
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/misc_helper.c | 2 +-
> target/s390x/translate.c | 1
On 30.11.2017 12:39, Thomas Huth wrote:
> On 29.11.2017 21:26, David Hildenbrand wrote:
>> s390_cpu_virt_mem_rw() must always return, so callers can react on
>> an exception (e.g. see ioinst_handle_stcrw()).
>>
>> Therefore, using program_interrupt() is wrong. Fix that up.
>>
>> Signed-off-by: Davi
On 30.11.2017 12:53, Thomas Huth wrote:
> On 29.11.2017 21:26, David Hildenbrand wrote:
>> Now we can drop the two save statements in the translate function.
>>
>> Reviewed-by: Richard Henderson
>> Signed-off-by: David Hildenbrand
>> ---
>> target/s390x/misc_helper.c | 2 +-
>> target/s390x/tran
On 29.11.2017 21:27, David Hildenbrand wrote:
> All users are gone, we can finally drop it and make sure that all new
> program interrupt injections are reminded of the retaddr - as they have to
> use s390_program_interrupt() now.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/cpu.h
On Thu, Nov 30, 2017 at 05:54:35PM +0800, Liu, Yi L wrote:
> On Thu, Nov 30, 2017 at 05:11:55PM +0800, Peter Xu wrote:
> > On Thu, Nov 30, 2017 at 01:22:38PM +0800, Liu, Yi L wrote:
> > > On Tue, Nov 14, 2017 at 06:13:50PM -0500, prasad.singamse...@oracle.com
> > > wrote:
> > > > From: Prasad Sing
On 11/29/2017 02:50 AM, John Snow wrote:
>
> On 11/28/2017 07:10 AM, Denis V. Lunev wrote:
>> There is the following crash reported from the field in QEMU 2.9:
>> bdrv_inc_in_flight (bs=bs@entry=0x0)
>> blk_aio_prwv
>> blk_aio_preadv
>> ide_buffered_readv
>> cd_read_sector
> Is
On 29.11.2017 21:27, David Hildenbrand wrote:
> Only one user left, get rid of it so we don't get any new users.
>
> Reviewed-by: Richard Henderson
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/translate.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --gi
On 30.11.2017 12:01, Thomas Huth wrote:
> On 29.11.2017 21:26, David Hildenbrand wrote:
>> s390_cpu_virt_mem_rw() must always return, so callers can react on
>> an exception (e.g. see ioinst_handle_stcrw()).
>>
>> However, for TCG we always have to exit the cpu loop (and restore the
>> cpu state be
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Wed, 29 Nov 2017 18:50:19 +
> "Dr. David Alan Gilbert (git)" wrote:
>
> > From: "Dr. David Alan Gilbert"
> >
> > Hi,
> > This is an experimental set that reworks the way the vhost
> > code handles changes in physical address space layout t
On 11/30/2017 10:50 AM, Cornelia Huck wrote:
> On Wed, 29 Nov 2017 19:51:23 +0100
> Christian Borntraeger wrote:
>
>> On 11/28/2017 03:45 PM, Cornelia Huck wrote:
>>> On Tue, 28 Nov 2017 15:17:49 +0100
>>> Christian Borntraeger wrote:
>>>
On 11/28/2017 03:01 PM, Cornelia Huck wrote:
18.11.2017 00:35, John Snow wrote:
On 11/17/2017 03:22 AM, Vladimir Sementsov-Ogievskiy wrote:
17.11.2017 06:10, John Snow wrote:
On 11/16/2017 03:17 AM, Vladimir Sementsov-Ogievskiy wrote:
16.11.2017 00:20, John Snow wrote:
On 11/13/2017 11:20 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all
On Thu, 30 Nov 2017 12:57:00 +0100
David Hildenbrand wrote:
> On 30.11.2017 12:39, Thomas Huth wrote:
> > On 29.11.2017 21:26, David Hildenbrand wrote:
> >> s390_cpu_virt_mem_rw() must always return, so callers can react on
> >> an exception (e.g. see ioinst_handle_stcrw()).
> >>
> >> Therefore
* Peter Xu (pet...@redhat.com) wrote:
> We will not allow failures to happen when sending data from destination
> to source via the return path. However it is possible that there can be
> errors along the way. This patch allows the migrate_send_rp_message()
> to return error when it happens, and f
On 30 November 2017 at 08:53, Thomas Huth wrote:
> We can output a character quite easily here with some few lines of
> assembly that we provide as a mini-kernel for this board.
>
> Signed-off-by: Thomas Huth
> ---
> tests/boot-serial-test.c | 10 ++
> 1 file changed, 10 insertions(+)
>
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the vpc driver accordingly. Drop the now-unused
get_sector_offset().
Signed-off-by: Eric Blake
---
v4: rebase to interface tweak
v3: rebase to master
v2: drop get_sector_
This sounds like it may be the bug fixed by this patchset:
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05067.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1735384
Title:
OpenJDK J
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the vvfat driver accordingly. Note that we
can rely on the block driver having already clamped limits to our
block size, and simplify accordingly.
Signed-off-by: Eric Blake
Am 29.11.2017 um 18:56 hat Alberto Garcia geschrieben:
> Starting from commit 40840e419be31e6a32e6ea24511c74b389d5e0e4 we are
> pausing all block jobs during bdrv_reopen_multiple() to prevent any of
> them from finishing and removing nodes from the graph while they are
> being reopened.
>
> It tur
12.10.2017 21:59, Eric Blake wrote:
We are gradually moving away from sector-based interfaces, towards
byte-based. Now that all drivers have been updated to provide the
byte-based .bdrv_co_block_status(), we can delete the sector-based
interface.
Signed-off-by: Eric Blake
Reviewed-by: Vladi
On 11/29/2017 06:29 PM, Cornelia Huck wrote:
[..]
With this change, however, our schema for generating a css bus ids, if
none is specified does not make much sense. Currently we start at cssid
0x0 for non-virtual devices and use the default css (without
s390-squash-mcss exclus
On 30.11.2017 13:14, Peter Maydell wrote:
> On 30 November 2017 at 08:53, Thomas Huth wrote:
>> We can output a character quite easily here with some few lines of
>> assembly that we provide as a mini-kernel for this board.
>>
>> Signed-off-by: Thomas Huth
>> ---
>> tests/boot-serial-test.c | 10
On 30/11/2017 13:14, Peter Maydell wrote:
> On 30 November 2017 at 08:53, Thomas Huth wrote:
>> +static const uint8_t kernel_mcf5208[] = {
>> +0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea 0xfc06,%a0 */
>> +0x10, 0x3c, 0x00, 0x54, /* move.b #'T',%d0 */
>> +0x11, 0x
On Thu, 30 Nov 2017 12:08:06 +
"Dr. David Alan Gilbert" wrote:
> * Igor Mammedov (imamm...@redhat.com) wrote:
> > On Wed, 29 Nov 2017 18:50:19 +
> > "Dr. David Alan Gilbert (git)" wrote:
> >
> > > From: "Dr. David Alan Gilbert"
> > >
> > > Hi,
> > > This is an experimental set tha
On 11/30/2017 01:19 PM, Peter Maydell wrote:
> This sounds like it may be the bug fixed by this patchset:
> https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05067.html
Unfortunately not. I will upload a prepared chroot for testing later
and link it in this bug report.
Adrian
--
.''`.
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Thu, 30 Nov 2017 12:08:06 +
> "Dr. David Alan Gilbert" wrote:
>
> > * Igor Mammedov (imamm...@redhat.com) wrote:
> > > On Wed, 29 Nov 2017 18:50:19 +
> > > "Dr. David Alan Gilbert (git)" wrote:
> > >
> > > > From: "Dr. David Alan Gilbe
On 30.11.2017 13:40, Paolo Bonzini wrote:
> On 30/11/2017 13:14, Peter Maydell wrote:
>> On 30 November 2017 at 08:53, Thomas Huth wrote:
>>> +static const uint8_t kernel_mcf5208[] = {
>>> +0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea 0xfc06,%a0 */
>>> +0x10, 0x3c, 0x00, 0x54,
On 30 November 2017 at 12:40, Paolo Bonzini wrote:
> On 30/11/2017 13:14, Peter Maydell wrote:
>> On 30 November 2017 at 08:53, Thomas Huth wrote:
>>> +static const uint8_t kernel_mcf5208[] = {
>>> +0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea 0xfc06,%a0 */
>>> +0x10, 0x3c, 0x00, 0x
This patch fixes the following BUG:
Even a guest is able to detect virtio_pci device, the init function
the Linux virtio_pci driver will hang because zPCI does not support
the subregions used by virtio_pci.
It follows that right now the PCI support is very limited
(e.g. pass through of a host vfio
There are two places where the same endianness conversion
is done.
Let's factor this out into a static function.
Note that the conversion must always be done for data in a register:
The S390 BE guest converted date to le before issuing the instruction.
After interception in a BE host:
ZPCI VFIO
Let's move the memory region write from pcistg into a dedicated
function.
This allows us to prepare a later patch searching for subregions
inside of the memory region.
Signed-off-by: Pierre Morel
Reviewed-by: Yi Min Zhao
Reviewed-by: Thomas Huth
---
hw/s390x/s390-pci-inst.c | 27 ++
Enhance the fault detection, correction of the fault reporting.
Signed-off-by: Pierre Morel
Reviewed-by: Yi Min Zhao
---
hw/s390x/s390-pci-inst.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
i
Enhance the fault detection.
Fixup the precedence to check the destination path existance
before checking for the source accessibility.
Add the maxstbl entry to both the Query PCI Function Group
response and the PCIBusDevice structure.
Initialize the maxstbl to 128 per default until we get
the a
On Thu, 30 Nov 2017 12:47:20 +
"Dr. David Alan Gilbert" wrote:
> * Igor Mammedov (imamm...@redhat.com) wrote:
> > On Thu, 30 Nov 2017 12:08:06 +
> > "Dr. David Alan Gilbert" wrote:
> >
> > > * Igor Mammedov (imamm...@redhat.com) wrote:
> > > > On Wed, 29 Nov 2017 18:50:19 +
> >
Enhance the fault detection, correction of the fault reporting.
Signed-off-by: Pierre Morel
Reviewed-by: Yi Min Zhao
---
hw/s390x/s390-pci-inst.c | 42 +-
hw/s390x/s390-pci-inst.h | 4
2 files changed, 29 insertions(+), 17 deletions(-)
diff --git a
Let's move the memory region read from pcilg into a dedicated function.
This allows us to prepare a later patch.
Signed-off-by: Pierre Morel
Reviewed-by: Yi Min Zhao
Reviewed-by: Thomas Huth
---
hw/s390x/s390-pci-inst.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
di
When dispatching memory access to PCI BAR region, we must
look for possible subregions, used by the PCI device to map
different memory areas inside the same PCI BAR.
Since the data offset we received is calculated starting at the
region start address we need to adjust the offset for the subregion.
On 30/11/2017 13:51, Peter Maydell wrote:
> On 30 November 2017 at 12:40, Paolo Bonzini wrote:
>> On 30/11/2017 13:14, Peter Maydell wrote:
>>> On 30 November 2017 at 08:53, Thomas Huth wrote:
+static const uint8_t kernel_mcf5208[] = {
+0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea
On 30/11/2017 13:51, Thomas Huth wrote:
> The two micrablaze data arrays are completely different, since one is
> big endian, the other is little, so I'd need to byte-swap the whole
> array on the fly, too. Not sure whether it makes sense to add such
> complex code just to safe 16 bytes of blob dat
Most of conversions looks fine, but it is not simple to prove the
correctness, because we start to use internal driver logic on offsets
and lengths, not aligned to sectors. And we can't imagine the
consequences (at least, I can't and my r-b doesn't give the guarantee)
of such change. It is like ta
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Thu, 30 Nov 2017 12:47:20 +
> "Dr. David Alan Gilbert" wrote:
>
> > * Igor Mammedov (imamm...@redhat.com) wrote:
> > > On Thu, 30 Nov 2017 12:08:06 +
> > > "Dr. David Alan Gilbert" wrote:
> > >
> > > > * Igor Mammedov (imamm...@redhat.
On 2017-11-30 04:16, Fam Zheng wrote:
> On Thu, 11/23 03:08, Max Reitz wrote:
>> _filter_img_info should remove format-specific information, too. We
>> already have such a filter in _img_info, and it is very useful for
>> query-block-named-block-nodes (etc.), too.
>>
>> However, in 198 we need tha
On 2017-11-30 04:18, Fam Zheng wrote:
> On Thu, 11/23 03:08, Max Reitz wrote:
>> Signed-off-by: Max Reitz
>> ---
>> tests/qemu-iotests/103 | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/103 b/tests/qemu-iotests/103
>> index ecbd8ebd71..d0cfab8844 100755
>> --- a/
On Thu, 30 Nov 2017 13:32:12 +0100
Halil Pasic wrote:
(...)
Before I spend way too much time on this:
Is the proposed machine-property interface usable from a libvirt POV?
IOW, can we go with this now and fix the ugliness later (probably via a
generic overhaul of the interface)?
Noticed this by chance in the tests/ directory, so I broadened
it to a grep of the entire code base. I suspect many of the
bad macros were the victims of copy-and-paste from some other
bad location (particularly given how many bit-rotten debug
print macros were involved).
https://wiki.qemu.org/Bi
It is more typical to provide the ';' by the caller of a macro
than to embed it in the macro itself; this is because syntax
highlight engines can get confused if a macro is called without
a semicolon before the closing '}'.
Signed-off-by: Eric Blake
---
target/mips/msa_helper.c | 34
The point of writing a macro embedded in a 'do { ... } while (0)'
loop is so that the macro can be used as a drop-in statement with
the caller supplying the trailing ';'. Although our coding style
frowns on brace-less 'if':
if (cond)
statement;
else
something else;
the use of do/while
For a couple of macros in pcnet.c, we have to provide a new scope
to avoid compiler warnings about declarations in the middle of a
switch statement that aren't in a sub-scope. But use of
'do { ... } while (0);' merely to provide that new scope is arcane
overkill, compared to just using '{ ... }'.
1 - 100 of 173 matches
Mail list logo
