Because I generate my first patch on master, it should work.
I have a little trouble understanding what Mr.Peter wants me to do,
would you please spare a little of your time and have a look at it?
It will help me. Please...
Su Hang
> -Original Messages-
> From: "Fam Zheng"
> Sent Time:
Signed-off-by: Fam Zheng
Reviewed-by: Eric Blake
---
tests/vm/basevm.py | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
index 686d88decf..f51604e0ab 100755
--- a/tests/vm/basevm.py
+++ b/tests/vm/basevm.py
@@ -101,7 +101,
HMP "info usernet" has been available but it isn't ideal for programmed
use cases. This closes the gap in QMP by adding a counterpart
"query-usernet" command. It is basically translated from
the HMP slirp_connection_info() loop, which now calls the QMP
implementation and prints the data, just like
v3: - Add Eric's rev-by to patch 2.
- Address Eric's comments on patch 1:
* Fix spell/grammar: "programmed", "awaiting".
* Fix include "qapi/qapi-commands-net.h".
* Underscores to dashes.
* "Since 2.13" now.
v2: Fix compiler error. [patchew]
The command is a counterpar
On Fri, 03/16 10:58, Su Hang wrote:
> (Sorry, I don't know this patch should base on which commit,
> so I generate this patch based on
> commit:fb8446d94ec7a3dc0c3a7e7da672406476f075ac,
> I choose this by `git log -2 scripts/checkpath.pl`.
> Sincerely say sorry, if I have misunderstand any mean
Le 16/03/2018 à 06:39, Thomas Huth a écrit :
With one of my clean-up patches (see commit 1454509726719e0933c800), I
recently accidentially broke the "-cdrom" parameter (more precisely
"-drive if=scsi") on a couple of boards, since there was no error
detected during the "make check" regression tes
Commit 1454509726719e0933c800 recently broke the "-cdrom" parameter
on a couple of boards without us noticing it immediately. Thus let's
add a test which checks that "-cdrom" can at least be used to start
QEMU with certain machine types.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Thomas H
We're going to use the s390x boot code for testing CD-ROM booting.
But the ISO loader of the s390-ccw bios is a little bit more picky
than the network loader and expects some magic bytes in the header
of the file (see linux_s390_magic in pc-bios/s390-ccw/bootmap.c), so
we've got to add them in our
We already have the code for a boot file in tests/boot-sector.c,
so if the genisoimage program is available, we can easily create
a bootable CD ISO image that we can use for testing whether our
CD-ROM emulation and the BIOS CD-ROM boot works correctly.
Signed-off-by: Thomas Huth
---
tests/Makefi
With one of my clean-up patches (see commit 1454509726719e0933c800), I
recently accidentially broke the "-cdrom" parameter (more precisely
"-drive if=scsi") on a couple of boards, since there was no error
detected during the "make check" regression testing. This is clearly an
indication that we are
On Thu, Mar 15, 2018 at 03:31:58PM -0600, Alex Williamson wrote:
> The ioeventfd here is actually irqfd handling of an ioeventfd such as
> supported in KVM. A user is able to pre-program a device write to
> occur when the eventfd triggers. This is yet another instance of
> eventfd-irqfd triggerin
On Thu, Mar 15, 2018 at 09:41:00AM +, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > On Mon, Mar 12, 2018 at 01:23:21PM +, Dr. David Alan Gilbert wrote:
> > > * Peter Xu (pet...@redhat.com) wrote:
> > > > On Thu, Mar 08, 2018 at 07:57:56PM +, Dr. David Alan Gi
Richard Henderson writes:
> On 03/07/2018 06:03 PM, Nikunj A Dadhania wrote:
>> Hi Richard,
>>
>> I was working to get TCG vector support for PowerPC[1]. Started with
>> converting logical operations like vector AND/OR/XOR and compare
>> instructions. Found some inconsistency during my testing o
On Thu, Mar 15, 2018 at 01:57:54PM +0100, Juan Quintela wrote:
> Peter Xu wrote:
> > On Wed, Mar 07, 2018 at 12:00:05PM +0100, Juan Quintela wrote:
> >> In both sides. We still don't transmit anything through them.
> >
> > s/In/On/?
> >
> >>
> >> Signed-off-by: Juan Quintela
> >> ---
> >> migr
checkpatch.pl stops complaining about following pattern:
"""
do {
//do somethins;
} while (conditions);
"""
One things need to be mentioned:
Becasue `if`, `while` and `for` check have been done in this
`if` block(Line: 2356), and this block contains following statement:
""" Line: 2379
$suppres
On Thu, 03/15 14:47, Daniel P. Berrangé wrote:
> On Tue, Mar 13, 2018 at 01:05:52PM +0100, Paolo Bonzini wrote:
> > Install optional dependencies of QEMU to get better coverage.
> >
> > Signed-off-by: Paolo Bonzini
> > ---
> > tests/docker/dockerfiles/fedora.docker | 13 ++---
> > 1 file
On Wed, Mar 14, 2018 at 01:01:30PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 14, 2018 at 03:29:59PM +0800, Boqun Feng wrote:
> > A new cpu model called "KNM" is added to model Knights Mill processors.
>
> Why the obscure acryonym? Can't we just call it KnightsMill so it is
> obvious what it i
On Thu, 03/15 15:27, Philippe Mathieu-Daudé wrote:
> Suggested-by: Eric Blake
> Signed-off-by: Philippe Mathieu-Daudé
> Reviewed-by: Daniel P. Berrangé
> ---
> v2:
> - avoid subshell using { ; } (Eric)
> - use test_fail() instead of prep_fail() (Fam)
>
> tests/docker/common.rc | 4 +++-
> 1 fi
This patch series is the QEMU counterpart to the KVM/kernel support for
guest dedicated crypto adapters. The KVM/kernel model is built on the
VFIO mediated device framework and provides the infrastructure for
granting exclusive guest access to crypto devices installed on the linux
host. This pa
This patch provides documentation describing the AP architecture and
design concepts behind the virtualization of AP devices. It also
includes an example of how to configure AP devices for exclusive
use of KVM guests.
Signed-off-by: Tony Krowiak
---
docs/vfio-ap.txt | 624 ++
A new CPU model feature and two new CPU model facilities are
introduced to support AP devices for a KVM guest.
CPU model features:
1. The KVM_S390_VM_CPU_FEAT_AP CPU model feature indicates that
AP facilities are installed. This feature will be enabled by
the kernel only if the AP facilitie
The VFIO AP device exploits interpretive execution of AP
instructions (APIE). APIE is enabled by setting a device attribute
via the KVM_SET_DEVICE_ATTR ioctl.
Signed-off-by: Tony Krowiak
---
target/s390x/kvm.c | 16
target/s390x/kvm_s390x.h |2 ++
2 files changed, 18
If the CPU model indicates that AP facility is installed on
the guest (i.e., -cpu ,ap=on), then the expectation is that
the AP bus running in the guest will initialize; however, if the
AP instructions are not being interpreted by the firmware, then
they will be intercepted and routed back to QE
Introduces a VFIO based AP device. The device is defined via
the QEMU command line by specifying:
-device vfio-ap,sysfsdev=
The mediated matrix device is created by the VFIO AP device
driver by writing a UUID to a sysfs attribute file (see
docs/vfio-ap.txt). The mediated matrix device will be
Updates the linux header files in preparation for introduction
of the VFIO AP device:
* Added a feature ID to indicate AP facilities are installed
* Added a device attribute to the KVM_S390_VM_CRYPTO group to
indicate whether AP instructions are to be interpreted
* Added VFIO device informatio
This patch introduces the base object for an AP device.
Signed-off-by: Tony Krowiak
---
hw/s390x/Makefile.objs |1 +
hw/s390x/ap-device.c | 38 ++
include/hw/s390x/ap-device.h | 38 ++
3 files changed,
Of all the gin joints in all the towns in all the world, Andrey Smirnov had to
walk into mine at 12:11 on Thursday 15 March 2018 and say:
> Add support for "TX complete"/TXDC interrupt generate by real HW since
> it is needed to support guests other than Linux.
>
> Based on the patch by Bill Pau
Of all the gin joints in all the towns in all the world, Bill Paul had to walk
into mine at 13:45 on Thursday 15 March 2018 and say:
> Of all the gin joints in all the towns in all the world, Andrey Smirnov had
> to
>
> walk into mine at 12:11 on Thursday 15 March 2018 and say:
> > Add support f
This creates a common helper that we'll use for ioeventfd setup.
Reviewed-by: Peter Xu
Reviewed-by: Eric Auger
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/vfio_pci_rdwr.c | 39 ++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/driv
A vfio ioeventfd will perform the pre-specified device write on
triggering of an eventfd. When coupled with KVM ioeventfds, this
feature allows a VM to trap a device page for virtualization, while
also registering targeted ioeventfds to maintain performance of high
frequency register writes within
The ioeventfd here is actually irqfd handling of an ioeventfd such as
supported in KVM. A user is able to pre-program a device write to
occur when the eventfd triggers. This is yet another instance of
eventfd-irqfd triggering between KVM and vfio. The impetus for this
is high frequency writes to
The iowriteXX/ioreadXX functions assume little endian hardware and
convert to little endian on a write and from little endian on a read.
We currently do our own explicit conversion to negate this. Instead,
add some endian dependent defines to avoid all byte swaps. There
should be no functional ch
On Tue, 13 Mar 2018 13:38:00 +0100
Auger Eric wrote:
> On 08/02/18 02:22, Alexey Kardashevskiy wrote:
> > On 08/02/18 01:12, Alex Williamson wrote:
> >> On Wed, 7 Feb 2018 15:48:26 +1100
> >> Alexey Kardashevskiy wrote:
> >>> On 07/02/18 15:25, Alex Williamson wrote:
> On Wed, 7 Feb 2018
On Wed, 7 Mar 2018 13:56:44 +0800
Peter Xu wrote:
> On Wed, Feb 28, 2018 at 01:15:20PM -0700, Alex Williamson wrote:
>
> [...]
>
> > @@ -1174,6 +1206,8 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
> > struct pci_device_id *id)
> > vdev->irq_type = VFIO_PCI_NUM_IRQS;
> > mut
On 03/05/2018 05:15 AM, Thomas Huth wrote:
> On 08.12.2017 22:29, John Snow wrote:
>>
>> On 11/21/2017 09:48 PM, Alexey Kardashevskiy wrote:
>>> On 07/11/17 11:58, John Snow wrote:
On 10/26/2017 02:46 AM, Alexey Kardashevskiy wrote:
> A "powernv" machine type defines an ISA bus
On Tue, 13 Mar 2018 14:12:34 +0100
Auger Eric wrote:
> On 28/02/18 21:15, Alex Williamson wrote:
> > +long vfio_pci_ioeventfd(struct vfio_pci_device *vdev, loff_t offset,
> > + uint64_t data, int count, int fd)
> > +{
> > + struct pci_dev *pdev = vdev->pdev;
> > + loff_t pos
That's fine; Andrey Smirnov has taken your patch as a basis for a more
cleaned-up set of changes:
http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04608.html
http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04609.html
What we would like from you is a Signed-off-by: line to say
On 15 March 2018 at 20:24, Brijen Raval wrote:
> On Thu, Mar 15, 2018 at 2:59 AM Peter Maydell
> wrote:
>> Exception 5 is IRQ. (These numbers are all internal to QEMU, and
>> don't have any architectural or guest-visible relevance. They're
>> the EXCP_* constants defined at the top of target/arm/
On Thu, Mar 15, 2018 at 2:59 AM Peter Maydell
wrote:
> On 15 March 2018 at 03:07, Brijen Raval wrote:
> > I am booting up a custom kernel on QEMU ARM64, upon completion of its
> > initial boot up it looks like it enters the arch_idle() state
> >
> > I enabled the -d int logging to understand wha
On Thu, Mar 15, 2018 at 12:47:08PM +0100, Philippe Mathieu-Daudé wrote:
> On 03/15/2018 08:49 AM, Thomas Huth wrote:
> > We're going to use the s390x boot code for testing CD-ROM booting.
> > But the ISO loader of the s390-ccw bios is a little bit more picky
> > than the network loader and expects
Despite the fact that now when the initialization of vde fails, qemu
does not end silently, no informative error is printed. The patch
generates an error and pushes it through the calling function.
Related bug: https://bugs.launchpad.net/qemu/+bug/676029
Signed-off-by: Julia Suvorova
---
net/vd
On 03/07/2018 06:03 PM, Nikunj A Dadhania wrote:
> Hi Richard,
>
> I was working to get TCG vector support for PowerPC[1]. Started with
> converting logical operations like vector AND/OR/XOR and compare
> instructions. Found some inconsistency during my testing on x86 laptop
> emulating PowerPC:
As I said before:
"I'm not submitting this as a patch to the development list as I'm not
fully certain it complies with the hardware spec and doesn't break any
other functionality."
What I'm trying to say here is that while I may have been able to cobble
together a hack to make the UART nominally
On 02/28/2018 01:05 PM, Max Reitz wrote:
> This new function allows to look for a consecutively dirty area in a
> dirty bitmap.
>
> Signed-off-by: Max Reitz
> ---
> include/block/dirty-bitmap.h | 2 ++
> block/dirty-bitmap.c | 55
>
> 2 fi
On 03/15/18 10:18, Kevin Wolf wrote:
Am 15.03.2018 um 17:55 hat Jack Schwartz geschrieben:
On 03/15/18 08:54, Kevin Wolf wrote:
Am 15.03.2018 um 06:19 hat Jack Schwartz geschrieben:
Hi Kevin.
My comments are inline...
On 2018-03-14 10:32, Kevin Wolf wrote:
The code path with a manually set
On 15.03.2018 12:42, Philippe Mathieu-Daudé wrote:
> Hi Thomas,
>
> On 03/15/2018 08:49 AM, Thomas Huth wrote:
>> Commit 1454509726719e0933c800 recently broke the "-cdrom" parameter
>> on a couple of boards without that we noticed it immediately. Thus
>> add a test which checks that "-cdrom" can a
On 03/16/2018 03:19 AM, Laurent Vivier wrote:
> I try to fix this by introducing a new TCG function
> to try to free a TCGv if it is a temporary one and
> do nothing otherwise (patches 1 and 2)
I would prefer not to approach this in this way.
Better is to have translator helpers that allocate tem
On 03/14/18 16:38, Andrew Jones wrote:
> We've seen a few reports of
>
> (gdb) source /usr/share/qemu-kvm/dump-guest-memory.py
> Traceback (most recent call last):
>File "/usr/share/qemu-kvm/dump-guest-memory.py", line 19, in
> UINTPTR_T = gdb.lookup_type("uintptr_t")
> gdb.error: No
On 15.03.2018 12:47, Philippe Mathieu-Daudé wrote:
> On 03/15/2018 08:49 AM, Thomas Huth wrote:
>> We're going to use the s390x boot code for testing CD-ROM booting.
>> But the ISO loader of the s390-ccw bios is a little bit more picky
>> than the network loader and expects some magic bytes in the
On 10 March 2018 at 21:25, Philippe Mathieu-Daudé wrote:
> On 03/09/2018 10:01 PM, Michael Clark wrote:
>> Logic bug caused the string size calculation for the RISC-V
>> format ISA string to be small. This fix allows slack for rv128.
>>
>> Cc: Palmer Dabbelt
>> Cc: Peter Maydell
>> Cc: Eric Blak
On 03/14/18 15:24, no-re...@patchew.org wrote:
> Checking PATCH 1/1: dump-guest-memory: more descriptive lookup_type failure...
> WARNING: line over 80 characters
> #34: FILE: scripts/dump-guest-memory.py:22:
> +raise gdb.GdbError("Symbols must be loaded prior to sourcing
> dump-guest-memory.
SRC_EA() and gen_extend() can return either a temporary
TCGv or memory allocated one. Try to free the temporary
one with tcg_temp_try_free().
Signed-off-by: Laurent Vivier
---
target/m68k/translate.c | 65 +
1 file changed, 65 insertions(+)
diff -
Since commit 15fa08f845 ("tcg: Dynamically allocate TCGOps")
we have no limit to fill the TCGOps cache and we can fill
the entire TCG variables array and overflow it.
To avoid that, we stop the translation when the array is close to
be full.
Signed-off-by: Laurent Vivier
---
target/m68k/transla
On Thu, Mar 15, 2018 at 07:31:09PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Eduardo,
>
> On 03/13/2018 07:37 PM, Eduardo Habkost wrote:
> > On Tue, Mar 13, 2018 at 06:29:10PM +, Peter Maydell wrote:
> >> On 12 March 2018 at 22:34, Eduardo Habkost wrote:
> >>> The following changes since comm
m68k has some functions returning either
locally allocated TCGv or memory allocated
TCGv (registers). We want to free locally
allocated TCGv to avoid overflow in sequence like:
0xc00ae406: movel %fp@(-132),%fp@(-268)
0xc00ae40c: movel %fp@(-128),%fp@(-264)
0xc00ae412: movel %fp@(-20),%fp@(-212)
Since commit 15fa08f845 ("tcg: Dynamically allocate TCGOps")
we have no limit to fill the TCGOps cache and we can fill
the entire TCG variables array and overflow it.
It seems to happen only with m68k, because m68k translator
doesn't free some TCGv at end of instruction translation
because the var
Add support for "TX complete"/TXDC interrupt generate by real HW since
it is needed to support guests other than Linux.
Based on the patch by Bill Paul as found here:
https://bugs.launchpad.net/qemu/+bug/1753314
Cc: qemu-devel@nongnu.org
Cc: qemu-...@nongnu.org
Cc: Bill Paul
Cc: Peter Maydell
S
Code of imx_update() is slightly confusing since the "flags" variable
doesn't really corespond to anything in real hardware and server as a
kitchensink accumulating events normally reported via USR1 and USR2
registers.
Change the code to explicitly evaluate state of interrupts reported
via USR1 an
Hi,
Sorry for not reviewing the previous versions of this series
(making it miss soft freeze).
On Mon, Mar 12, 2018 at 05:00:45PM -0400, Babu Moger wrote:
> Generalize some of the macro definitions which are generic cache
> properties that are common between CPUID 4 and CPUID 0x801D
> in pre
Hi,
Sorry for not reviewing the previous versions of this series (and
making it miss soft freeze).
On Mon, Mar 12, 2018 at 05:00:46PM -0400, Babu Moger wrote:
> From: Stanislav Lanci
>
> Add information for cpuid 0x801D leaf. Populate cache topology information
> for different cache types(
On 13 March 2018 at 17:33, Laurent Vivier wrote:
> The following changes since commit b39b61e410022f96ceb53d4381d25cba5126ac44:
>
> memory: fix flatview_access_valid RCU read lock/unlock imbalance
> (2018-03-09 15:55:20 +)
>
> are available in the Git repository at:
>
> git://github.com/v
Hi Eduardo,
On 03/13/2018 07:37 PM, Eduardo Habkost wrote:
> On Tue, Mar 13, 2018 at 06:29:10PM +, Peter Maydell wrote:
>> On 12 March 2018 at 22:34, Eduardo Habkost wrote:
>>> The following changes since commit 6ceb1b51f05f9e1892d082960ed602dca7b6696e:
>>>
>>> Merge remote-tracking branch
On Tue, Mar 13, 2018 at 03:37:04PM -0300, Eduardo Habkost wrote:
> On Tue, Mar 13, 2018 at 06:29:10PM +, Peter Maydell wrote:
> > On 12 March 2018 at 22:34, Eduardo Habkost wrote:
> > > The following changes since commit
> > > 6ceb1b51f05f9e1892d082960ed602dca7b6696e:
> > >
> > > Merge remo
From: Igor Mammedov
cpu_init(cpu_model) were replaced by cpu_create(cpu_type) so
no users are left, remove it.
Signed-off-by: Igor Mammedov
Acked-by: David Gibson (ppc)
Reviewed-by: Eduardo Habkost
Message-Id: <151827-274608-6-git-send-email-imamm...@redhat.com>
Signed-off-by: Eduardo Hab
From: Igor Mammedov
both do nothing as for the first all callers
parse_cpu_model() and qmp_query_cpu_model_()
should provide non NULL value, so just abort if it's not so.
While at it drop cpu_common_class_by_name() which is not need
any more as every target has CPUClass::class_by_name callbac
From: Igor Mammedov
With all targets defining CPU_RESOLVING_TYPE, refactor
cpu_parse_cpu_model(type, cpu_model) to parse_cpu_model(cpu_model)
so that callers won't have to know internal resolving cpu
type. Place it in exec.c so it could be called from both
target independed vl.c and *-user/main.c
From: Igor Mammedov
use cpu_create() instead of being removed cpu_generic_init()
Signed-off-by: Igor Mammedov
Reviewed-by: Eduardo Habkost
Message-Id: <151827-274608-2-git-send-email-imamm...@redhat.com>
Signed-off-by: Eduardo Habkost
---
hw/nios2/10m50_devboard.c | 2 +-
1 file changed,
From: Igor Mammedov
it will be used for providing to cpu name resolving class for
parsing cpu model for system and user emulation code.
Along with change add target to null-machine tests, so
that when switch to CPU_RESOLVING_TYPE happens,
it would ensure that null-machine usecase still works.
S
From: Igor Mammedov
Check that "$QEMU -M none -cpu FOO" starts QEMU without error
Signed-off-by: Igor Mammedov
Message-Id: <151827-274608-3-git-send-email-imamm...@redhat.com>
[ehabkost: include qmp/qdict.h instead of qmp/types.h]
Signed-off-by: Eduardo Habkost
---
tests/machine-none-test
From: Wang Xin
Signed-off-by: Wang Xin
Message-Id: <1517367668-25048-1-git-send-email-wangxinxin.w...@huawei.com>
Acked-by: Michael S. Tsirkin
Signed-off-by: Eduardo Habkost
---
include/hw/i386/pc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/i386/pc.h b/inc
Changes in v2 (v1 was 2018-03-12):
* Fix bsd-user build error
The following changes since commit 56e8698ffa8aba9f762f980bc21b5340b006f24b:
Merge remote-tracking branch
'remotes/stsquad/tags/pull-travis-speedup-130318-1' into staging (2018-03-15
14:48:09 +)
are available in the Git reposi
Could we over-allocate the data segment by
QEMU_DATA_SIZE/getrlimit(RLIMIT_DATA)/128 MB depending on what's set -
similar to how the stack size is managed?
My current workaround for aarch64 on x86-64 is to mmap a dynamic main
executable in some far-away part of the address space but I'm not sure
h
On 13 March 2018 at 16:41, Paolo Bonzini wrote:
> The following changes since commit fb5fff15881ba7a002924b967eb211c002897983:
>
> Merge remote-tracking branch
> 'remotes/kraxel/tags/vga-20180312-pull-request' into staging (2018-03-12
> 18:35:37 +)
>
> are available in the git repository a
On 03/15/2018 12:56 PM, Kevin Wolf wrote:
> Am 15.03.2018 um 17:42 hat Peter Maydell geschrieben:
>> On 13 March 2018 at 16:17, Kevin Wolf wrote:
>>> The following changes since commit 22ef7ba8e8ce7fef297549b3defcac333742b804:
>>>
>>> Merge remote-tracking branch 'remotes/famz/tags/staging-pul
Ho hum, I rushed v1 before leaving on holidays and failed to format
the cover letter properly, so Peter's scripts did not pick it up.
Patches 2 & 3 are real bug fixes and so still appropriate for the
softfreeze. Patch 1 is trivial enough I didn't feel it needed to
be held back for 2.13 developmen
Unknown why -m32 was passing with gcc but not clang; it should have
failed for both. This would be used for tcg_gen_dup_i64_vec, and
visible with the right TB and an aarch64 guest.
Reported-by: Max Reitz
Signed-off-by: Richard Henderson
---
tcg/i386/tcg-target.inc.c | 9 +
1 file chang
This unifies 5 copies of checks for supported vector size,
and in the process fixes a missing check in tcg_gen_gvec_2s.
This lead to an assertion failure for 64-bit vector multiply,
which is not available in the AVX instruction set.
Suggested-by: Peter Maydell
Signed-off-by: Richard Henderson
-
Convert multiplication by power of two to left shift.
Reviewed-by: Emilio G. Cota
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Richard Henderson
---
tcg/tcg-op.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/tcg/tcg-op.c b/tcg/tcg-op.c
inde
** Tags added: linux-user
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1619896
Title:
Unsupported ancillary data: 0/8
Status in QEMU:
New
Bug description:
Hello,
I have the following issu
** Summary changed:
- raspi2: system timer not device implemented
+ raspi2: system timer device not implemented
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991
Title:
raspi2: system timer de
The following changes since commit 56e8698ffa8aba9f762f980bc21b5340b006f24b:
Merge remote-tracking branch
'remotes/stsquad/tags/pull-travis-speedup-130318-1' into staging (2018-03-15
14:48:09 +)
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstream
Am 15.03.2018 um 17:55 hat Jack Schwartz geschrieben:
> On 03/15/18 08:54, Kevin Wolf wrote:
> > Am 15.03.2018 um 06:19 hat Jack Schwartz geschrieben:
> > > Hi Kevin.
> > >
> > > My comments are inline...
> > >
> > > On 2018-03-14 10:32, Kevin Wolf wrote:
> > > > The code path with a manually set
On 13 March 2018 at 16:55, Andrew Baumann wrote:
>> From: Qemu-devel > bounces+andrew.baumann=microsoft@nongnu.org> On Behalf Of Peter
>> Maydell
>> Sent: Tuesday, 13 March 2018 08:35
>>
>> Now we have separate types for BCM2386 and BCM2387, we might as well
>> just hard-code the CPU type they
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180315151348.6451-1-james.cowg...@mips.com
Subject: [Qemu-devel] [PATCH v2] linux-user: implement HWCAP bits on MIPS
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
to
Am 15.03.2018 um 17:42 hat Peter Maydell geschrieben:
> On 13 March 2018 at 16:17, Kevin Wolf wrote:
> > The following changes since commit 22ef7ba8e8ce7fef297549b3defcac333742b804:
> >
> > Merge remote-tracking branch 'remotes/famz/tags/staging-pull-request'
> > into staging (2018-03-13 11:42:
On 03/15/18 08:54, Kevin Wolf wrote:
Am 15.03.2018 um 06:19 hat Jack Schwartz geschrieben:
Hi Kevin.
My comments are inline...
On 2018-03-14 10:32, Kevin Wolf wrote:
The code path with a manually set mh_load_addr in the Multiboot header
checks that load_end_addr <= load_addr, but the path whe
On 23 February 2018 at 00:39, wrote:
> When porting our RTOS from QEMU 2.8 to 2.10/2.11, I ran into a problem
> where 16-bit writes to the "bochs dispi interface" were being reported
> differently depending on whether or not "-icount" was given to QEMU.
>
> For example, info mtree:
> ...
> 11
Am 15.03.2018 um 15:30 hat Paolo Bonzini geschrieben:
> This fails in Fedora 28.
>
> Reported-by: Andreas Schwab
> Signed-off-by: Paolo Bonzini
Thanks, applied to the block branch.
Kevin
On 13 March 2018 at 16:17, Kevin Wolf wrote:
> The following changes since commit 22ef7ba8e8ce7fef297549b3defcac333742b804:
>
> Merge remote-tracking branch 'remotes/famz/tags/staging-pull-request' into
> staging (2018-03-13 11:42:45 +)
>
> are available in the git repository at:
>
> git:
Am 15.03.2018 um 04:51 hat Fam Zheng geschrieben:
> Reported-by: Max Reitz
> Signed-off-by: Fam Zheng
Thanks, applied to the block branch.
Kevin
Am 15.03.2018 um 04:45 hat Fam Zheng geschrieben:
> Overriding flags violates the precedence rules of
> bdrv_reopen_queue_child. Just like the read-only option, no-flush should
> be put into the options. The same is done in bdrv_temp_snapshot_options.
>
> Reported-by: Stefan Hajnoczi Signed-off-b
There seem to be two parts to this. Firstly, with a big reserved-region,
which is the default for 32-bit-guest-on-64-bit-host, this code in
main.c:
if (reserved_va) {
mmap_next_start = reserved_va;
}
says to start trying for the next mmap address at the top of the
rese
On 03/13/2018 04:27 AM, Laurent Vivier wrote:
> I have compared results of these instructions from a real m68040 and from
> QEMU, and they match (sincos differs [1] because in QEMU we compute it as
> sin and cos, and on m68040 sin and cos results differ also with
> sincos results. It looks like a r
QEMU doesn't care whether the kernel you provide it is Linux or
something else. If you pass -kernel something that's not an ELF file,
we'll load and boot it using the Linux boot protocol (including ATAGS,
potentially). If you pass an ELF file or pass -bios a binary blob, we'll
just start it in the
Am 15.03.2018 um 06:19 hat Jack Schwartz geschrieben:
> Hi Kevin.
>
> My comments are inline...
>
> On 2018-03-14 10:32, Kevin Wolf wrote:
> > The code path with a manually set mh_load_addr in the Multiboot header
> > checks that load_end_addr <= load_addr, but the path where load_end_addr
> > is
Public bug reported:
This would be a useful feature. Many kernels, particularly hobbyist
kernels, have support for ATAGS.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEM
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary
Le 15/03/2018 à 16:13, James Cowgill a écrit :
> Add support for the two currently defined HWCAP bits on MIPS - R6 and
> MSA.
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1754372
> Signed-off-by: James Cowgill
> ---
> v2 changes:
> - Fix kernel hwcap.h path.
>
> linux-user/elfload.c | 24
Patch which should fix this:
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg04537.html
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1
Add support for the two currently defined HWCAP bits on MIPS - R6 and
MSA.
Buglink: https://bugs.launchpad.net/qemu/+bug/1754372
Signed-off-by: James Cowgill
---
v2 changes:
- Fix kernel hwcap.h path.
linux-user/elfload.c | 24
1 file changed, 24 insertions(+)
diff --
1 - 100 of 195 matches
Mail list logo
