On Thu, Jun 18, 2015 at 11:49 PM, Greg Ungerer wrote:
> Hi Peter,
>
> On 19/06/15 15:49, Peter Crosthwaite wrote:
>> On Mon, Aug 18, 2014 at 10:37 PM, wrote:
>>> From: Greg Ungerer
>>>
>>> The action to potentially switch sp register is not occurring at the correct
>>> point in the interrupt en
David Gibson writes:
> On Thu, Jun 18, 2015 at 09:35:44PM +1000, Alexey Kardashevskiy wrote:
>> On 05/05/2015 10:49 PM, David Gibson wrote:
>> >On Sat, Apr 25, 2015 at 10:24:43PM +1000, Alexey Kardashevskiy wrote:
>> >>This adds support for Dynamic DMA Windows (DDW) option defined by
>> >>the SPA
Hi Peter,
On 19/06/15 15:49, Peter Crosthwaite wrote:
> On Mon, Aug 18, 2014 at 10:37 PM, wrote:
>> From: Greg Ungerer
>>
>> The action to potentially switch sp register is not occurring at the correct
>> point in the interrupt entry or exception exit sequences.
>>
>> For the interrupt entry ca
Laszlo Ersek writes:
> On 06/18/15 18:49, Eduardo Habkost wrote:
>> commit ea96bc629cbd52be98b2967a4b4f72e91dfc3ee4 doesn't match the patch
>> submitted by Laszlo to qemu-devel. We reuse pc_q35_2_4_machine_options()
>> inside pc_q35_2_3_machine_options(), so we need to undo the no_floppy
>> chang
From: Lu Lina
Signed-off-by: Lu Lina
---
hw/block/nvme.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 4b6d5e6..c6a6a0e 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -154,6 +154,7 @@ static uint16_t nvme_dma_read_prp(NvmeCtrl *n, uint8_t
*p
Hi Peter,
On 19/06/15 15:24, Peter Crosthwaite wrote:
> On Mon, Aug 18, 2014 at 10:37 PM, wrote:
>> From: Greg Ungerer
>>
>> Implement the SIMR and CIMR registers of the 5208 interrupt controller.
>> These are used by modern versions of Linux running on ColdFire (not sure
>> of the exact versio
On Wed, Jun 17, 2015 at 02:12:14PM +0530, Nikunj A Dadhania wrote:
> David Gibson writes:
>
> > On Thu, Jun 11, 2015 at 04:32:26PM +0530, Nikunj A Dadhania wrote:
> >> All the PCI enumeration and device node creation was off-loaded to
> >> SLOF. With PCI hotplug support, code needed to be added t
On Thu, Jun 18, 2015 at 10:00 PM, Greg Ungerer wrote:
> Hi All,
>
> I see in the MAINTAINERS file that pretty much everything related
> to the m68k architecture is listed as "Orphan".
>
> I have some patches that have been around for quite a while (posted
> here twice) to fix some issues with the
On Mon, Aug 18, 2014 at 10:37 PM, wrote:
> From: Greg Ungerer
>
> The action to potentially switch sp register is not occurring at the correct
> point in the interrupt entry or exception exit sequences.
>
> For the interrupt entry case the sp on entry is used to create the stack
> exception fram
On Mon, Aug 18, 2014 at 10:37 PM, wrote:
> From: Greg Ungerer
>
> Implement the SIMR and CIMR registers of the 5208 interrupt controller.
> These are used by modern versions of Linux running on ColdFire (not sure
> of the exact version they were introduced, but they have been in for quite
> a wh
Start storing the (start_addr, size, nodeid) of the pc-dimm memory
in numa_info so that this information can be used to lookup
node by address.
Signed-off-by: Bharata B Rao
Reviewed-by: David Gibson
---
hw/mem/pc-dimm.c | 4
include/sysemu/numa.h | 10 ++
numa.c
Introduce an API numa_get_node(ram_addr_t addr, Error **errp) that
returns the NUMA node to which the given address belongs to. This
API works uniformly for both boot time as well as hotplugged memory.
This API is needed by sPAPR PowerPC to support
ibm,dynamic-reconfiguration-memory device tree no
Hi,
Here is the v2 of the patchset that refactors pc_dimm_plug and adds
an API to lookup NUMA node by address.
- Refactoring pc_dimm_plug() helps other architectures like PowerPC
to make use of common code.
- API to lookup NUMA node id by address is required to support memory
hotplug on Power
pc_dimm_plug() has code that will be needed for memory plug handlers
in other archs too. Extract code from pc_dimm_plug() into a generic
routine pc_dimm_memory_plug() that resides in pc-dimm.c. Also
correspondingly refactor re-usable unplug code into pc_dimm_memory_unplug().
Signed-off-by: Bharata
Store memory address range information of boot memory in address
range list of numa_info.
This helps to have a common NUMA node lookup by address function that
works for both boot time memory and hotplugged memory.
Signed-off-by: Bharata B Rao
---
numa.c | 17 +
1 file changed,
> From: Aurelien Jarno [mailto:aurel...@aurel32.net]
> On 2015-06-18 12:02, Paolo Bonzini wrote:
> >
> > TCG can then use them to fill in an array stored inside the
> > TranslationBlock, together with the host PC. Since the gen_opc_pc,
> > gen_opc_instr_start, gen_opc_icount arrays are inside tcg_
Hi All,
I see in the MAINTAINERS file that pretty much everything related
to the m68k architecture is listed as "Orphan".
I have some patches that have been around for quite a while (posted
here twice) to fix some issues with the ColdFire support.
[See https://lists.nongnu.org/archive/html/qemu-d
Remove the hardcoded values from the machine specific reset
function, as the same values are already set in the standard
MicroBlaze reset.
This also allows the entire reset function to be deleted, as
PVR registers are now preserved on reset.
Signed-off-by: Alistair Francis
Reviewed-by: Edgar E.
This code is already being run in the mb_cpu_realizefn()
function. As PVR registers are preserved on reset this
code is not required.
Signed-off-by: Alistair Francis
Reviewed-by: Edgar E. Iglesias
Reviewed-by: Peter Crosthwaite
---
target-microblaze/cpu.c |4
1 files changed, 0 insert
Move the hard coded register values to the init function.
This also allows the entire reset function to be deleted, as
PVR registers are now preserved on reset.
The hardcoded PVR0 values can be removed as they are setting
the endianness and stack protection, which is already done
or invalid.
Sign
Originally the pvr-full PVR bits were manually set for each machine. This
is a hassle and difficult to read, instead set them based on the CPU
properties.
Signed-off-by: Alistair Francis
Reviewed-by: Peter Crosthwaite
---
V4:
- Macro out the PVR encodings
V3:
- Convert PVR to an 8-bit uint ins
Rename the usefpu variable to use_fpu.
Signed-off-by: Alistair Francis
Reviewed-by: Peter Crosthwaite
---
target-microblaze/cpu-qom.h |2 +-
target-microblaze/cpu.c |8
target-microblaze/translate.c |6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff -
Originally the endi PVR bits were manually set for each machine. This
is a hassle and difficult to read, instead set them based on the CPU
properties.
Signed-off-by: Alistair Francis
Reviewed-by: Edgar E. Iglesias
Reviewed-by: Peter Crosthwaite
---
hw/microblaze/petalogix_ml605_mmu.c |2 +-
This patch series extends the MicroBlaze properties
that I have been working on. It applies on top of my
original work:
'Add Microblaze configuration options'.
This patch series converts various MicroBlaze PVR registers
to properties. This then allows the individual Microblaze
machine reset functi
This should help catch property name typos at compile time.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Laszlo Ersek
---
Notes:
v7:
- new in v7
include/hw/pci/pci_bridge.h | 2 ++
hw/pci-bridge/pci_bridge_dev.c | 3 ++-
hw/pci-bridge/pci_expander_bridge.c
The sysbus_get_fw_dev_path() function formats OpenFirmware device path
nodes ("driver-name@unit-address") for sysbus devices. The first choice
for "unit-address" is the base address of the device's first MMIO region.
The second choice is its first IO port.
However, if two sysbus devices with the s
OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI
Bus driver globally signals the firmware that PCI enumeration and resource
allocation have completed. At this point QEMU regenerates the ACPI payload
in an fw_cfg read callback, and this is when the PXB's _CRS gets
populated.
We have agreed that OpenFirmware device paths in the "bootorder" fw_cfg
file should follow the pattern
/pci@i0cf8,%x/...
for devices that live behind an extra root bus. The extra root bus in
question is the %x'th among the extra root buses. (In other words, %x
gives the position of the affected
In the PCI expander bridge, we will want to disable those features of
pci-bridge that relate to SHPC (standard hotplug controller):
- SHPC bar and underlying MemoryRegion
- interrupt (INTx or MSI)
- effective hotplug callbacks
- other SHPC hooks (initialization, cleanup, migration etc)
Introduce
This should help catch property name typos at compile time.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Laszlo Ersek
---
Notes:
v7:
- new in v7
include/hw/pci/pci_bridge.h| 1 +
hw/pci-bridge/pci_bridge_dev.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
Change the signature of the function-like macro SHPC_VMSTATE(), so that we
can produce and expect this field conditionally in the migration stream,
starting with an upcoming patch.
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Laszlo Ersek
---
Notes:
v7:
- no changes
It follows msi_present() in "include/hw/pci/msi.h".
Cc: Michael S. Tsirkin
Cc: Marcel Apfelbaum
Signed-off-by: Laszlo Ersek
---
Notes:
v7:
- new in v7 [Michael]
include/hw/pci/shpc.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/hw/pci/shpc.h b/include/hw/pci/shpc
This is done mainly for improving readability, and in preparation for the
next patch, but Markus pointed out another bonus for the string being
returned:
"No arbitrary length limit. Before the patch, it's 39 characters, and the
code breaks catastrophically when qdev_fw_name() is longer: the second
There is no _TEST() variant of VMSTATE_BUFFER_UNSAFE_INFO() yet, but we'll
soon need it. Introduce it and rebase the original
VMSTATE_BUFFER_UNSAFE_INFO() on top.
The parameter order of the new function-like macro follows that of
VMSTATE_SINGLE_TEST(): "_test" is introduced between "_state" and
"_
I tried hard to address the two sets of comments I got for v6:
- in the first half of the series, I reworked the new pci-bridge
property
- in the second half, I implemented the agreed upon OFW format
I also adapted the OVMF series to the changes in the second half
(locally only, for now), and re
On Thu, Jun 18, 2015 at 09:35:44PM +1000, Alexey Kardashevskiy wrote:
> On 05/05/2015 10:49 PM, David Gibson wrote:
> >On Sat, Apr 25, 2015 at 10:24:43PM +1000, Alexey Kardashevskiy wrote:
> >>This adds support for Dynamic DMA Windows (DDW) option defined by
> >>the SPAPR specification which allows
On 06/19/2015 06:02 AM, Peter Maydell wrote:
> On 13 June 2015 at 14:07, Chen Gang wrote:
>> It can finish running "Hello world" elf64 binary, and the related test
>> cases:
>>
>> - with "--enable-debug", enable assertion with "-g":
>>
>> ./tilegx-linux-user/qemu-tilegx -L /upstream/release-
From: Shannon Zhao
Add GICv2m description in ACPI MADT table, so guest can use MSI when
booting with ACPI.
Signed-off-by: Shannon Zhao
Signed-off-by: Shannon Zhao
---
Fix endianness [Peter]
---
hw/arm/virt-acpi-build.c| 11 +++
include/hw/acpi/acpi-defs.h | 12
On Tue, 06/16 14:57, Stefan Hajnoczi wrote:
> On Wed, Jun 10, 2015 at 04:59:44PM +0800, Fam Zheng wrote:
> > diff --git a/iohandler.c b/iohandler.c
> > index 826f713..f5d7704 100644
> > --- a/iohandler.c
> > +++ b/iohandler.c
> > @@ -32,111 +32,39 @@
> > #include
> > #endif
> >
> > -typedef st
I have tried your qemu cammand line but got no luck (the embedded os have no
virtio support but this is not the problem i think). The problem probably lies
in the host kernel version as it is the only difference for my tests. I traced
the guest kernel and found the ATA drivers always used non-DM
On Tue, 06/16 15:15, Stefan Hajnoczi wrote:
> On Wed, Jun 10, 2015 at 04:59:51PM +0800, Fam Zheng wrote:
> > Signed-off-by: Fam Zheng
> > ---
> > main-loop.c | 4 ++--
> > slirp/libslirp.h | 4 ++--
> > slirp/slirp.c| 4 ++--
> > stubs/slirp.c| 4 ++--
> > 4 files changed, 8 insertio
the iozone command line is:
./iozone -i 0 -i 1 -f ./iotmp -Rab ./iotmp.xls -g 8G -n 4G -c
The problem is why the performance difference is so big for different linux
kernels. The guest's io performance test is by both FTP tools and raw write,
which demonstrate the much lower performance of Ce
On 06/19/2015 12:06 AM, Stefan Hajnoczi wrote:
> On Thu, Jun 18, 2015 at 10:36:39PM +0800, Wen Congyang wrote:
>> At 2015/6/18 20:55, Stefan Hajnoczi Wrote:
>>> On Thu, Jun 18, 2015 at 04:49:12PM +0800, Wen Congyang wrote:
+void bdrv_connect(BlockDriverState *bs, Error **errp)
+{
+
On 06/19/2015 07:10 AM, Alex Williamson wrote:
On Thu, 2015-06-18 at 21:37 +1000, Alexey Kardashevskiy wrote:
This moves SPAPR bits to a separate file to avoid pollution of x86 code.
This enables spapr-vfio on CONFIG_SOFTMMU (not CONFIG_PSERIES) as
the config options are only visible in makefil
On Fri, Jun 5, 2015 at 12:58 PM, Peter Crosthwaite
wrote:
> On Thu, Jun 4, 2015 at 7:00 PM, Alistair Francis
> wrote:
>> On Thu, Jun 4, 2015 at 8:52 AM, Peter Crosthwaite
>> wrote:
>>> On Wed, May 27, 2015 at 12:37 AM, Alistair Francis
>>> wrote:
Previously the stream_running() function di
On Tue, Jun 16, 2015 at 12:25 PM, Peter Crosthwaite
wrote:
> On Mon, Jun 15, 2015 at 6:16 PM, Alistair Francis
> wrote:
>> Originally the pvr-full PVR bits were manually set for each machine. This
>> is a hassle and difficult to read, instead set them based on the CPU
>> properties.
>>
>> Signed-
On Mon, Jun 15, 2015 at 8:36 AM, Peter Crosthwaite
wrote:
>
> Hi All,
>
> This series introduced support for multi QOM properties with the same
> name and then moves the ARM CPUs to the MPCore container objects (yes!
> they are related!)
>
> The application of the QOM change is container objects p
On 18/06/15 16:43, Paolo Bonzini wrote:
> The first patch fixes the remaining problems with Peter Crosthwaite's
> access clamping patch (which broke kvmvapic and hence Windows XP/2003).
> The second patch actually puts the clamping to good use: by fixing
> address_space_translate_internal, the MIP
On 13 June 2015 at 14:07, Chen Gang wrote:
> It can finish running "Hello world" elf64 binary, and the related test
> cases:
>
> - with "--enable-debug", enable assertion with "-g":
>
> ./tilegx-linux-user/qemu-tilegx -L /upstream/release-tile
> /upstream/release-tile/test/test_shared
>
On 18 June 2015 at 17:00, Leon Alrae wrote:
> Just a rebase of v4 as there were changes in qemu_opt_foreach API.
>
> Regards,
> Leon
Thanks; applied to target-arm.next.
-- PMM
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: ubuntu-gnome3-desktop (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/12948
** Also affects: ubuntu-gnome3-desktop (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/1294898
Title:
gtk: menubar visible in fullscreen mode with
On 06/18/15 11:43, Paolo Bonzini wrote:
> The first patch fixes the remaining problems with Peter Crosthwaite's
> access clamping patch (which broke kvmvapic and hence Windows XP/2003).
> The second patch actually puts the clamping to good use: by fixing
> address_space_translate_internal, the MIPS
> Do You see similar results at Your side?
>
> Best regards
Would you mind to share you argument set to an emulator? As far as I
understood you are using plain ballooning with most results from above
for which those numbers are expected. The case with 5+gig memory
consumption for deflated 1G gues
On Thu, 2015-06-18 at 21:37 +1000, Alexey Kardashevskiy wrote:
> This moves SPAPR bits to a separate file to avoid pollution of x86 code.
>
> This enables spapr-vfio on CONFIG_SOFTMMU (not CONFIG_PSERIES) as
> the config options are only visible in makefiles and not in the source code
> so there i
On 17 June 2015 at 01:35, Peter Crosthwaite
wrote:
> Hi Peter and all,
>
> This patch series adds ARM Cortex R5 processor support. The PMSAv7 MPU
> is implemented. Two R5s are added to the Xilinx ZynqMP SoC.
Thanks, applied to target-arm.next. (This is by a few days
post-softfreeze but the patche
On 19.06.2015 00:01, Peter Maydell wrote:
> On 18 June 2015 at 21:57, Sergey Fedorov wrote:
>> On 18.06.2015 23:46, Peter Maydell wrote:
>>> On 17 June 2015 at 16:25, Sergey Fedorov wrote:
cp_reg_reset() is called from g_hash_table_foreach() which does not
define a specific ordering o
On 18 June 2015 at 21:57, Sergey Fedorov wrote:
> On 18.06.2015 23:46, Peter Maydell wrote:
>> On 17 June 2015 at 16:25, Sergey Fedorov wrote:
>>> cp_reg_reset() is called from g_hash_table_foreach() which does not
>>> define a specific ordering of the hash table iteration. Thus doing reset
>>> f
On 06/18/2015 08:08 AM, Wolfgang Bumiller wrote:
> Till now the vvfat filesystem's label was hardcoded to be
s/Till/Until/
> "QEMU VVFAT", now you can pass a file.label=labelname option
> to the -drive to change it.
>
> Signed-off-by: Wolfgang Bumiller
> ---
> block/vvfat.c| 25 +++
On 18.06.2015 23:46, Peter Maydell wrote:
> On 17 June 2015 at 16:25, Sergey Fedorov wrote:
>> cp_reg_reset() is called from g_hash_table_foreach() which does not
>> define a specific ordering of the hash table iteration. Thus doing reset
>> for registers marked as ALIAS would give an ambiguous re
Till now the vvfat filesystem's label was hardcoded to be
"QEMU VVFAT", now you can pass a file.label=labelname option
to the -drive to change it.
Signed-off-by: Wolfgang Bumiller
---
block/vvfat.c| 25 ++---
qapi/block-core.json | 3 ++-
2 files changed, 24 insertio
W dniu 2015-06-18 o 00:57, Vasiliy Tolstov pisze:
2015-06-18 1:52 GMT+03:00 Andrey Korolyov :
Whoosh... technically it is possible but it would be an incompatible
fork for the upstreams for both SeaBIOS and Qemu, because the generic
way of plugging DIMMs in is available down to at least generic
On 17 June 2015 at 16:25, Sergey Fedorov wrote:
> cp_reg_reset() is called from g_hash_table_foreach() which does not
> define a specific ordering of the hash table iteration. Thus doing reset
> for registers marked as ALIAS would give an ambiguous result when
> resetvalue is different for origina
On 16 June 2015 at 13:11, Eric Auger wrote:
> Hi Peter,
> On 06/16/2015 01:59 PM, Peter Maydell wrote:
>> This was part of a series before -- is it a standalone
>> patch now? What's the relationship with the other patches?
>
> This patch makes possible to instantiate the VFIO Calxeda xgmac device
On Thu, Jun 18, 2015 at 12:00 PM, Paolo Bonzini wrote:
>
>
> On 18/06/2015 20:37, Peter Crosthwaite wrote:
>> I'm playing with this patch series to see if I can get it working for
>> a BE ARMv8 guest I have but there are complications now that we
>> support multiple ELs.
>>
>> I'll make some notes
On Sun, Jun 07, 2015 at 11:15:08AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> ARAT signals that the APIC timer does not stop in power saving states.
> As our APICs are emulated, it's fine to expose this feature to guests,
> at least when asking for KVM host features or with CPU types that
>
On 05/20/2015 03:57 AM, Dimitris Aragiorgis wrote:
> Until now, an SG device was identified only by checking if its path
> started with "/dev/sg". Then, hdev_open() set bs->sg accordingly.
> This is very fragile, e.g. it fails with symlinks or relative paths.
> We should rely on the actual properti
On 05/20/2015 03:57 AM, Dimitris Aragiorgis wrote:
> Get rid of several #ifdef DEBUG_FLOPPY and substitute them with
> DPRINTF.
>
> Signed-off-by: Dimitris Aragiorgis
> ---
> block/raw-posix.c | 22 +-
> 1 file changed, 5 insertions(+), 17 deletions(-)
Reviewed-by: Eric Bl
On 05/20/2015 03:57 AM, Dimitris Aragiorgis wrote:
> Building the QEMU tools fails if we #define DEBUG_BLOCK inside
> block/raw-posix.c. Here instead of adding qemu-log.o in block-obj-y
> so that DEBUG_BLOCK_PRINT can be used, we substitute the latter with
> a simple DPRINTF() (that does not cause
On 18 June 2015 at 19:32, Mark Burton wrote:
> for the 1< little worrying - I’ll check.
>
>> On 18 Jun 2015, at 17:56, Peter Maydell wrote:
>>
>> On 18 June 2015 at 16:44, wrote:
>>> +uint64_t oldval, *p;
>>> +p = address_space_map(cs->as, paddr, &len, true);
>>> +if (le
On Thu, Jun 18, 2015 at 10:24:54AM -0700, Peter Crosthwaite wrote:
[...]
> diff --git a/exec.c b/exec.c
> index b1c8aae..7fc1950 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -554,9 +554,8 @@ void cpu_exec_exit(CPUState *cpu)
> }
> #endif
>
> -void cpu_exec_init(CPUArchState *env, Error **errp)
> +
Le 18/06/2015 17:43, Paolo Bonzini a écrit :
The first patch fixes the remaining problems with Peter Crosthwaite's
access clamping patch (which broke kvmvapic and hence Windows XP/2003).
The second patch actually puts the clamping to good use: by fixing
address_space_translate_internal, the MIPS
On Thu, Jun 18, 2015 at 10:24:53AM -0700, Peter Crosthwaite wrote:
> The sole caller of this function navigates the cpu->env_ptr only for
> this function to take it back the cpu pointer straight away. Pass in
> cpu pointer instead and grab the env pointer locally in the function.
> Removes a core c
On Thu, Jun 18, 2015 at 10:24:52AM -0700, Peter Crosthwaite wrote:
> All callsites to this function navigate the cpu->env_ptr only for the
> function to take the env ptr back to the original cpu ptr. Change the
> function to just pass in the CPU pointer instead. Removes a core code
> usage of ENV_G
On Thu, Jun 18, 2015 at 10:24:47AM -0700, Peter Crosthwaite wrote:
> Hi All,
>
> I'm moving towards the goal of having no core code usages of ENV_GET_CPU.
> This has two advantages:
>
> 1: It means we are closer to common-obj'ing core code like exec.c, cpus.c
> and friends.
> 2: Multi arch is eas
On 18/06/2015 20:37, Peter Crosthwaite wrote:
> I'm playing with this patch series to see if I can get it working for
> a BE ARMv8 guest I have but there are complications now that we
> support multiple ELs.
>
> I'll make some notes on the patches.
>
> In my rebasing, I am dropping the BE32 sup
On 06/17/15 14:58, Michael S. Tsirkin wrote:
> On Wed, Jun 17, 2015 at 01:34:33PM -0400, Don Slutz wrote:
>> On 06/17/15 13:25, Paolo Bonzini wrote:
>>>
>>>
>>> On 17/06/2015 19:14, Paolo Bonzini wrote:
On 17/06/2015 19:03, Don Slutz wrote:
> On 06/17/15 12:29, Michael S. Tsirkin
On Sat, Jun 21, 2014 at 5:58 AM, Paolo Bonzini wrote:
> This fixes the Raspberry Pi optimized memcmp library (with both user-mode
> and system-mode emulation).
>
> Compared to the previous submission, the main changes are:
>
> - I track access endianness by taking into account both SCTLR.B and CPS
On Thu, Jun 18, 2015 at 15:55:54 +0100, Peter Maydell wrote:
> I'd forgotten we had that mutex. However it's not actually
> a sufficient fix for the problem. What needs to happen is
> that:
> (a) somebody actually sits down and figures out what data
> structures we have and what locking/per-cpunes
for the 1< On 18 Jun 2015, at 17:56, Peter Maydell wrote:
>
> On 18 June 2015 at 16:44, wrote:
>> +uint64_t oldval, *p;
>> +p = address_space_map(cs->as, paddr, &len, true);
>> +if (len == 8 << size) {
>> +oldval = (uint64_t)env->exclusive_val;
>> +
I cannot make dotprod_mutex.c to crash with the current master (git
8ffe756d). I've tried both linux-arm and linux-arm-static, the latter
running under chroot.
I've tried on three different machines, and have tested with different thread
counts: 4, 10, 16, 64 (one of the machines has 64 cores).
I
Am 18.06.2015 um 18:47 schrieb Paolo Bonzini:
> @@ -1887,11 +1893,15 @@ int kvm_cpu_exec(CPUState *cpu)
> break;
> default:
> DPRINTF("kvm_arch_handle_exit\n");
> +qemu_mutex_lock_iothread();
> ret = kvm_arch_handle_exit(cpu, run);
> +
Clear host multi-queue related features if the peer
doesn't support it.
Signed-off-by: Marcel Apfelbaum
---
Notes:
This fixes a guest CPU soft lock, however the virtio-net
device will not work correctly. It seems that is
peer's "fault", not knowing how to handle the situation.
However, I subm
On 06/18/15 18:49, Eduardo Habkost wrote:
> commit ea96bc629cbd52be98b2967a4b4f72e91dfc3ee4 doesn't match the patch
> submitted by Laszlo to qemu-devel. We reuse pc_q35_2_4_machine_options()
> inside pc_q35_2_3_machine_options(), so we need to undo the no_floppy
> change in pc_q35_2_3_machine_optio
Add a chassis_nr property Instead of using PXB bus number
as internal bridge's chassis nr.
Suggested-by: Michael S. Tsirkin
Signed-off-by: Marcel Apfelbaum
---
docs/pci_expander_bridge.txt| 7 +++
hw/pci-bridge/pci_expander_bridge.c | 5 -
2 files changed, 7 insertions(+), 5 del
On 2015-06-18 12:02, Paolo Bonzini wrote:
>
>
> On 18/06/2015 11:42, Aurelien Jarno wrote:
> >> > QEMU could just always compute and store the restore_state information.
> >> > TCG needs to help filling it in (a new TCG opcode?), but it should be
> >> > easy.
> > Yes, that was another approach
2015-06-18 19:15 keltezéssel, Laszlo Ersek írta:
On 06/18/15 18:43, Kővágó, Zoltán wrote:
The current OptsVisitor flattens the whole structure, if there are same
named fields under different paths (like `in' and `out' in `Audiodev'),
the current visitor can't cope with them (for example setting
On Thu, Jun 18, 2015 at 01:12:32PM -0400, Bandan Das wrote:
> Eduardo Habkost writes:
>
> > On Thu, Jun 18, 2015 at 05:24:24PM +0200, Radim Krčmář wrote:
> >> We already bump to level 7 if features there are requested, so do the
> >> same for 0xD.
>
> But doesn't bumping to 7 for feat[ebx] have
From: Bharata B Rao
Currently CPUState.cpu_index is monotonically increasing and a newly
created CPU always gets the next higher index. The next available
index is calculated by counting the existing number of CPUs. This is
fine as long as we only add CPUs, but there are architectures which
are s
On 2015-06-18 17:54, Christian Borntraeger wrote:
> commit fa92e218df1d ("s390x/ipl: avoid sign extension") introduced
> a regression:
>
> qemu-system-s390x -drive file=/home/cborntra/image.zhyp409,format=qcow2
> does not boot, the bios states
> "No virtio-blk device found!"
>
> adding bootindex=
The callers (most of them in target-foo/cpu.c) to this function all
have the cpu pointer handy. Just pass it to avoid an ENV_GET_CPU() from
core code (in exec.c).
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Peter Maydell
Cc: "Edgar E. Iglesias"
Cc: "Andreas Färber"
Cc: Eduardo Habkost
Cc: Mi
Paolo Bonzini writes:
> On 18/06/2015 17:24, Radim Krčmář wrote:
>> W10 insider has a bug where it ignores CPUID level and interprets
>> CPUID.(EAX=07H, ECX=0H) incorrectly, because CPUID in fact returned
>> CPUID.(EAX=04H, ECX=0H); this resulted in execution of unsupported
>> instructions.
>>
All of the core-code usages of this API have the cpu pointer handy so
pass it in. There are only 3 architecture specific usages (2 of which
are commented out) which can just use ENV_GET_CPU() locally to get the
cpu pointer. The reduces core code usage of the CPU env, which brings
us closer to commo
The sole caller of this function navigates the cpu->env_ptr only for
this function to take it back the cpu pointer straight away. Pass in
cpu pointer instead and grab the env pointer locally in the function.
Removes a core code usage of ENV_GET_CPU().
Reviewed-by: Andreas Färber
Signed-off-by: Pe
Hi All,
I'm moving towards the goal of having no core code usages of ENV_GET_CPU.
This has two advantages:
1: It means we are closer to common-obj'ing core code like exec.c, cpus.c
and friends.
2: Multi arch is easier if ENV_GET_CPU() stays arch specific. It means I
don't need those patches where
Remove un-needed usages of ENV_GET_CPU() by converting the APIs to use
CPUState pointers and retrieving the env_ptr as minimally needed.
Scripted conversion for target-* change:
for I in target-*/cpu.h; do
sed -i \
's/\(^int cpu_[^_]*_exec(\)[^ ][^ ]* \*s);$/\1CPUState *cpu);/' \
$I;
All callsites to this function navigate the cpu->env_ptr only for the
function to take the env ptr back to the original cpu ptr. Change the
function to just pass in the CPU pointer instead. Removes a core code
usage of ENV_GET_CPU (in gdbstub.c).
Cc: Riku Voipio
Reviewed-by: Andreas Färber
Signe
From: Bharata B Rao
Add an Error argument to cpu_exec_init() to let users collect the
error. This is in preparation to change the CPU enumeration logic
in cpu_exec_init(). With the new enumeration logic, cpu_exec_init()
can fail if cpu_index values corresponding to max_cpus have already
been hand
From: Bharata B Rao
Move cpu_exec_init() call from instance_init to realize. This allows
any failures from cpu_exec_init() to be handled appropriately.
Also add corresponding cpu_exec_exit() call from unrealize.
cpu_dt_id assignment from instance_init is no longer needed since
correct assignment
On 06/18/15 18:43, Kővágó, Zoltán wrote:
> The current OptsVisitor flattens the whole structure, if there are same
> named fields under different paths (like `in' and `out' in `Audiodev'),
> the current visitor can't cope with them (for example setting
> `frequency=44100' will set the in's frequenc
1 - 100 of 383 matches
Mail list logo