>> May be we should introduce a helper such as :
>>
>> int pnv_chip_cpu_foreach(PnvChip *chip,
>>int (*doit)(PnvChip *chip, PowerPCCPU *cpu, void *opaque), void
>> *opaque)
>> {
>> int i, j;
>> int ret = 0;
>>
>> for (i = 0; i < chip->nr_cores; i++) {
>> PnvCore *pc =
Hi
On Thu, Dec 12, 2019 at 4:03 PM Daniel P. Berrangé wrote:
>
> On Wed, Dec 11, 2019 at 05:45:03PM +0400, Marc-André Lureau wrote:
> > When instantiated, this object will connect to the given D-Bus bus
> > "addr". During migration, it will take/restore the data from
> > org.qemu.VMState1 instanc
On 15. 12. 19 6:28, Guenter Roeck wrote:
> On 12/9/19 7:02 AM, Michal Simek wrote:
>> On 09. 12. 19 15:32, Guenter Roeck wrote:
>>> On 12/8/19 11:48 PM, Edgar E. Iglesias wrote:
On Sun, Dec 08, 2019 at 11:19:33PM -0800, Guenter Roeck wrote:
> On 12/8/19 10:42 PM, Michal Simek wrote:
>>
Ping for comment.
On Sat, Oct 26, 2019 at 08:45:14AM +0800, Wei Yang wrote:
>Current send thread could work while the sync mechanism has some problem:
>
> * has spuriously wakeup
> * number of channels_ready will *overflow* the number of real channels
>
>The reason is:
>
> * if MULTIFD_FLAG_SYN
Would this one be picked up this time?
On Sat, Oct 26, 2019 at 07:19:58AM +0800, Wei Yang wrote:
>We don't support multifd during postcopy, but user still could enable
>both multifd and postcopy. This leads to migration failure.
>
>Patch 1 does proper cleanup, otherwise we may have data corruption
Would this one be picked up in this version?
On Thu, Nov 07, 2019 at 08:39:01PM +0800, Wei Yang wrote:
>This patch set tries enable compress during postcopy.
>
>postcopy requires to place a whole host page, while migration thread migrate
>memory in target page size. This makes postcopy need to col
From: Li Hangjing
When the number of a virtio-blk device's virtqueues is larger than
BITS_PER_LONG, the out-of-bounds access to bitmap[ ] will occur.
Fixes: e21737ab15 ("virtio-blk: multiqueue batch notify")
Cc: qemu-sta...@nongnu.org
Cc: Stefan Hajnoczi
Signed-off-by: Li Hangjing
Reviewed-by:
On Fri, Dec 13, 2019 at 02:00:53PM +0100, Cédric Le Goater wrote:
> On 13/12/2019 13:00, Greg Kurz wrote:
> > The pnv_pic_print_info() callback checks the type of the chip in order
> > to forward to the request appropriate interrupt controller. This can
> > be achieved with QOM. Introduce a method
On Fri, Dec 13, 2019 at 12:59:28PM +0100, Greg Kurz wrote:
> The PnvChipClass type has a chip_type attribute which identifies various
> POWER CPU chip types that can be used in a powernv machine.
>
> typedef enum PnvChipType {
> PNV_CHIP_POWER8E, /* AKA Murano (default) */
> PNV_CHIP_P
On Fri, Dec 13, 2019 at 02:06:31PM +0100, Cédric Le Goater wrote:
> On 13/12/2019 13:00, Greg Kurz wrote:
> > The XSCOM bus is implemented with a QOM interface, which is mostly
> > generic from a CPU type standpoint, except for the computation of
> > addresses on the Pervasize Connect Bus (PCB) net
On 12/13/2019 5:12 PM, Igor Mammedov wrote:
On Fri, 13 Dec 2019 09:33:10 +0800
Tao Xu wrote:
On 12/12/2019 8:48 PM, Igor Mammedov wrote:
Commit aa57020774b, by mistake used MachineClass::numa_mem_supported
to check if NUMA is supported by machine and also as unrelated change
set it to true fo
On 12/13/2019 6:06 PM, Michael S. Tsirkin wrote:
On Fri, Dec 13, 2019 at 09:19:21AM +0800, Tao Xu wrote:
This series of patches will build Heterogeneous Memory Attribute Table (HMAT)
according to the command line. The ACPI HMAT describes the memory attributes,
such as memory side cache attribute
On Sun, 15 Dec 2019, Finn Thain wrote:
> I test the qemu build like this,
>
> qemu-system-m68k -M q800 -m 512M -serial none -serial mon:stdio -g 800x600x4
> -net nic,model=dp83932,addr=00:00:00:01:02:03
> -net bridge,helper=/opt/qemu/libexec/qemu-bridge-helper,br=br0
> -append "fbcon=font:ProFont
In commit 3bf4dfdd111 we introduced the pci_cfg_[read/write]
trace events in pci_host_config_[read/write]_common().
We have the following call trace:
pci_host_data_[read/write]()
- PCI_DPRINTF()
- pci_data_[read/write]()
- PCI_DPRINTF()
- pci_host_config_[read/write]_comm
Both functions are called by MemoryRegionOps.[read/write] handlers
with unsigned 'size' argument. Both functions call
pci_host_config_[read/write]_common() which expect a uint32_t 'len'
parameter (also unsigned).
Since it is pointless (and confuse) to use a signed value, use a
unsigned type.
Signe
- Use unsigned 'size' argument
- Remove unuseful DPRINTF()
Philippe Mathieu-Daudé (2):
hw/pci/pci_host: Remove redundant PCI_DPRINTF()
hw/pci/pci_host: Let pci_data_[read/write] use unsigned 'size'
argument
include/hw/pci/pci_host.h | 4 ++--
hw/pci/pci_host.c | 25 +++--
On 12/16/19 12:27 AM, Niek Linnenbank wrote:
On Fri, Dec 13, 2019 at 1:09 AM Philippe Mathieu-Daudé
mailto:phi...@redhat.com>> wrote:
On 12/2/19 10:09 PM, Niek Linnenbank wrote:
[...]
> +static const MemoryRegionOps allwinner_h3_syscon_ops = {
> + .read = allwinner_h3_syscon_
On 12/16/19 12:07 AM, Niek Linnenbank wrote:
On Fri, Dec 13, 2019 at 12:56 AM Philippe Mathieu-Daudé
mailto:phi...@redhat.com>> wrote:
Hi Niek,
On 12/11/19 11:34 PM, Niek Linnenbank wrote:
[...]
> +static uint32_t aw_h3_sdhost_process_desc(AwH3SDHostState *s,
> +
On Fri, Dec 13, 2019 at 1:09 AM Philippe Mathieu-Daudé
wrote:
> On 12/2/19 10:09 PM, Niek Linnenbank wrote:
> > The Allwinner H3 System on Chip has an System Control
> > module that provides system wide generic controls and
> > device information. This commit adds support for the
> > Allwinner H3
On Fri, Dec 13, 2019 at 12:56 AM Philippe Mathieu-Daudé
wrote:
> Hi Niek,
>
> On 12/11/19 11:34 PM, Niek Linnenbank wrote:
> > Ping!
> >
> > Anyone would like to comment on this driver?
> >
> > I finished the rework on all previous comments in this series.
> >
> > Currently debugging the hflags e
On Thu, Dec 12, 2019 at 07:58:31AM -0500, Wainer dos Santos Moschetta wrote:
> __init_.py import some sub-modules unnecessarily. So let's
> clean it up.
>
> Signed-off-by: Wainer dos Santos Moschetta
> Suggested-by: Cleber Rosa
> ---
> python/qemu/__init__.py | 6 --
> 1 file changed, 6 del
On Sun, 2019-12-15 at 11:59 +0100, BALATON Zoltan wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On Sun, 15 Dec 2019, Philippe Mathieu-Daudé wrote:
> > Hi Jo
On Sun, 2019-12-15 at 17:54 +0100, Laurent Vivier wrote:
>
> Le 14/12/2019 à 13:20, Joakim Tjernlund a écrit :
> > From: Joakim Tjernlund
> >
> > QEMU can autodetect if it is started from Linux binfmt loader
> > when binfmt flag O is on.
> > Use that and require binfmt flag P as well which will
On Thu, Dec 12, 2019 at 07:58:28AM -0500, Wainer dos Santos Moschetta wrote:
> Since commit cbe6d6365a48 the command `qemu -accel help` returns
> the list of accelerators enabled in the QEMU binary. This adds
> the list_accel() method which return that same list.
>
> Signed-off-by: Wainer dos Sant
On Thu, Dec 12, 2019 at 07:58:27AM -0500, Wainer dos Santos Moschetta wrote:
> This creates the 'accel' Python module to be the home for
> utilities that deal with accelerators. Also moved kvm_available()
> from __init__.py to this new module.
>
> Signed-off-by: Wainer dos Santos Moschetta
> Revi
On Wed, Dec 11, 2019 at 01:55:36PM -0500, Wainer dos Santos Moschetta wrote:
> On linux_initrd and empty_cpu_model tests the same effect of
> calling QEMU through run() to inspect the terminated process is
> achieved with a sequence of set_qmp_monitor() / launch() / wait()
> commands on an QEMUMach
On Fri, Dec 13, 2019 at 10:46:17AM -0200, Wainer dos Santos Moschetta wrote:
>
> On 12/12/19 12:13 PM, Cleber Rosa wrote:
> > On Wed, Dec 11, 2019 at 01:55:35PM -0500, Wainer dos Santos Moschetta wrote:
> > > The QEMUMachine VM has a monitor setup on which an QMP
> > > connection is always attempt
Le 14/12/2019 à 13:20, Joakim Tjernlund a écrit :
> From: Joakim Tjernlund
>
> QEMU can autodetect if it is started from Linux binfmt loader
> when binfmt flag O is on.
> Use that and require binfmt flag P as well which will enable QEMU
> to pass in correct argv0 to the application.
I agree it's
On Sun, 15 Dec 2019 at 09:51, Michael S. Tsirkin wrote:
>
> On Sat, Dec 14, 2019 at 04:28:08PM +, Peter Maydell wrote:
> > (It doesn't actually assert that it doesn't
> > overlap because we have some legacy uses, notably
> > in the x86 PC machines, which do overlap without using
> > the right
On Sun, 15 Dec 2019, Philippe Mathieu-Daudé wrote:
Hi Joakim,
I'm cc'ing the PPC maintainers for you, so they won't miss your patch (see
https://wiki.qemu.org/Contribute/SubmitAPatch#CC_the_relevant_maintainer and
the output of ./scripts/get_maintainer.pl -f target/ppc/excp_helper.c).
On 12/
On Fri, Dec 13, 2019 at 05:47:28PM +0100, Philippe Mathieu-Daudé wrote:
> On 12/13/19 5:17 PM, Philippe Mathieu-Daudé wrote:
> > Historically, QEMU started with only one X86 machine: the PC.
> > The 'hw/i386/pc.h' header was used to store all X86 and PC
> > declarations. Since we have now multiple
On Sat, Dec 14, 2019 at 08:01:46PM +, Peter Maydell wrote:
> On Sat, 14 Dec 2019 at 18:17, Philippe Mathieu-Daudé
> wrote:
> > Maybe we can a warning if priority=0, to force board designers to use
> > explicit priority (explicit overlap).
>
> Priority 0 is fine, it's just one of the possible
On Sat, Dec 14, 2019 at 04:28:08PM +, Peter Maydell wrote:
> (It doesn't actually assert that it doesn't
> overlap because we have some legacy uses, notably
> in the x86 PC machines, which do overlap without using
> the right function, which we've never tried to tidy up.)
It's not exactly lega
33 matches
Mail list logo
