Re: [Qemu-devel] [PATCH] pci: fix requester id to be the one on root bus

On Wed, May 11, 2016 at 09:22:03PM -0600, Alex Williamson wrote: [...] > PCI Express to PCI/PCI-X Bridge Specification rev 1.0 > 2.3 Assignment of Requester ID and Tag by the Bridge > > PCIe-to-PCI bridges assign a requester ID composed of the secondary bus > number with devfn = 0. Although

[Qemu-devel] [for-2.7 PATCH v3 14/15] hmp: Add 'info hotpluggable-cpus' HMP command

This is the HMP equivalent for QMP query-hotpluggable-cpus. Signed-off-by: Bharata B Rao --- hmp-commands-info.hx | 14 ++ hmp.c| 41 + hmp.h| 1 + 3 files changed, 56 insertions(+)

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Thu, May 12, 2016 at 6:06 AM, Alex Williamson wrote: > On Wed, 11 May 2016 17:15:15 +0800 > Jike Song wrote: > >> On 05/11/2016 12:02 AM, Neo Jia wrote: >> > On Tue, May 10, 2016 at 03:52:27PM +0800, Jike Song wrote: >> >> On 05/05/2016 05:27

Re: [Qemu-devel] [Qemu-block] [PATCH v18 0/8] Block replication for continuous checkpoints

On 05/06/2016 11:51 PM, Stefan Hajnoczi wrote: On Fri, Apr 15, 2016 at 04:10:30PM +0800, Changlong Xie wrote: Block replication is a very important feature which is used for continuous checkpoints(for example: COLO). You can get the detailed information about block replication from here:

[Qemu-devel] [for-2.7 PATCH v3 09/15] spapr: CPU hotplug support

Set up device tree entries for the hotplugged CPU core and use the exising RTAS event logging infrastructure to send CPU hotplug notification to the guest. Signed-off-by: Bharata B Rao --- hw/ppc/spapr.c | 91 ++---

[Qemu-devel] [for-2.7 PATCH v3 15/15] spapr: implement query-hotpluggable-cpus callback

From: Igor Mammedov It returns a list of present/possible to hotplug CPU objects with a list of properties to use with device_add. in spapr case returned list would looks like: -> { "execute": "query-hotpluggable-cpus" } <- {"return": [ { "props": { "core": 8 },

[Qemu-devel] [for-2.7 PATCH v3 07/15] spapr: Abstract CPU core device and type specific core devices

Add sPAPR specific abastract CPU core device that is based on generic CPU core device. Use this as base type to create sPAPR CPU specific core devices. TODO: - Add core types for other remaining CPU types - Handle CPU model alias correctly Signed-off-by: Bharata B Rao

[Qemu-devel] [for-2.7 PATCH v3 10/15] xics, xics_kvm: Handle CPU unplug correctly

XICS is setup for each CPU during initialization. Provide a routine to undo the same when CPU is unplugged. While here, move ss->cs management into xics from xics_kvm since there is nothing KVM specific in it. Also ensure xics reset doesn't set irq for CPUs that are already unplugged. This allows

[Qemu-devel] [for-2.7 PATCH v3 12/15] spapr: CPU hot unplug support

Remove the CPU core device by removing the underlying CPU thread devices. Hot removal of CPU for sPAPR guests is achieved by sending the hot unplug notification to the guest. Release the vCPU object after CPU hot unplug so that vCPU fd can be parked and reused. Signed-off-by: Bharata B Rao

[Qemu-devel] [for-2.7 PATCH v3 11/15] spapr_drc: Prevent detach racing against attach for CPU DR

If a CPU is hot removed while hotplug of the same is still in progress, the guest crashes. Prevent this by ensuring that detach is done only after attach has completed. The existing code already prevents such race for PCI hotplug. However given that CPU is a logical DR unlike PCI and starts with

[Qemu-devel] [for-2.7 PATCH v3 03/15] cpu: Reclaim vCPU objects

From: Gu Zheng In order to deal well with the kvm vcpus (which can not be removed without any protection), we do not close KVM vcpu fd, just record and mark it as stopped into a list, so that we can reuse it for the appending cpu hot-add request if possible. It is also

[Qemu-devel] [for-2.7 PATCH v3 13/15] QMP: Add query-hotpluggable-cpus

From: Igor Mammedov It will allow mgmt to query present and hotpluggable CPU objects, it is required from a target platform that wishes to support command to implement and set MachineClass.query_hotpluggable_cpus callback, which will return a list of possible CPU objects

[Qemu-devel] [for-2.7 PATCH v3 06/15] cpu: Abstract CPU core type

Add an abstract CPU core type that could be used by machines that want to define and hotplug CPUs in core granularity. Signed-off-by: Bharata B Rao Signed-off-by: Igor Mammedov [Integer core property] Reviewed-by: David Gibson

[Qemu-devel] [for-2.7 PATCH v3 00/15] Core based CPU hotplug for PowerPC sPAPR

Hi, This is v3 of "Core based CPU hotplug for PowerPC sPAPR". The hotplug semantics looks like this: (qemu) device_add POWER8E-spapr-cpu-core,id=core2,core=16[,threads=4] (qemu) device_add POWER8E_v2.1-spapr-cpu-core,id=core2,core=16[,threads=4] Changes in v3 - - Moved CPU

[Qemu-devel] [for-2.7 PATCH v3 05/15] qdev: hotplug: Introduce HotplugHandler.pre_plug() callback

From: Igor Mammedov pre_plug callback is to be called before device.realize() is executed. This would allow to check/set device's properties from HotplugHandler. Signed-off-by: Igor Mammedov Signed-off-by: Bharata B Rao

[Qemu-devel] [for-2.7 PATCH v3 08/15] spapr: convert boot CPUs into CPU core devices

Introduce sPAPRMachineClass.dr_cpu_enabled to indicate support for CPU core hotplug. Initialize boot time CPUs as core deivces and prevent topologies that result in partially filled cores. Both of these are done only if CPU core hotplug is supported. Note: An unrelated change in the call to

[Qemu-devel] [for-2.7 PATCH v3 04/15] cpu: Add a sync version of cpu_remove()

This sync API will be used by the CPU hotplug code to wait for the CPU to completely get removed before flagging the failure to the device_add command. Sync version of this call is needed to correctly recover from CPU realization failures when ->plug() handler fails. Signed-off-by: Bharata B Rao

[Qemu-devel] [for-2.7 PATCH v3 01/15] exec: Remove cpu from cpus list during cpu_exec_exit()

CPUState *cpu gets added to the cpus list during cpu_exec_init(). It should be removed from cpu_exec_exit(). cpu_exec_exit() is called from generic CPU::instance_finalize and some archs like PowerPC call it from CPU unrealizefn. So ensure that we dequeue the cpu only once. Now -1 value for

[Qemu-devel] [for-2.7 PATCH v3 02/15] exec: Do vmstate unregistration from cpu_exec_exit()

cpu_exec_init() does vmstate_register for the CPU device. This needs to be undone from cpu_exec_exit(). This change is needed to support CPU hot removal. Signed-off-by: Bharata B Rao Reviewed-by: Thomas Huth Reviewed-by: David Gibson

Re: [Qemu-devel] [PATCH] pci: fix requester id to be the one on root bus

On Thu, 12 May 2016 10:40:57 +0800 Peter Xu wrote: > On Wed, May 11, 2016 at 04:53:54PM +0300, Michael S. Tsirkin wrote: > > On Wed, May 11, 2016 at 02:40:31PM +0800, Peter Xu wrote: > > > When there are devices under PCI bridge (or bridges), PCI requester ID > > > should be

Re: [Qemu-devel] [PATCH] pci: fix requester id to be the one on root bus

On Wed, May 11, 2016 at 04:53:54PM +0300, Michael S. Tsirkin wrote: > On Wed, May 11, 2016 at 02:40:31PM +0800, Peter Xu wrote: > > When there are devices under PCI bridge (or bridges), PCI requester ID > > should be the one that hooked on the root PCI bus, not the PCI device > > itself. > > > >

Re: [Qemu-devel] [PATCH 0/9] some QOM'ify work under hw/arm

在 2016-03-31 16:15:17，"xiaoqiang zhao" 写道： > > >> 在 2016年3月31日，16:05，Peter Maydell 写道： >> >>> On 31 March 2016 at 02:48, xiaoqiang zhao wrote: >>> 在 2016年03月16日 20:00, Peter Maydell 写道: > On 16 March 2016 at

Re: [Qemu-devel] [PATCH] pci_register_bar: cleanup

Hi, Since it has been Reviewed-by: Paolo Bonzini for almost 2 months, is it forgot to put into upstream? On 03/25/2016 05:25 PM, Paolo Bonzini wrote: On 25/03/2016 07:49, Cao jin wrote: place relevant code tegother, make the code easier to read Signed-off-by:

Re: [Qemu-devel] [PATCH] net/net: Add ReadState for reuse codes

On 2016年05月11日 19:20, Zhang Chen wrote: On 05/11/2016 05:01 PM, Jason Wang wrote: On 2016年05月06日 18:56, Zhang Chen wrote: Signed-off-by: Zhang Chen Signed-off-by: Li Zhijian Signed-off-by: Wen Congyang

Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening

On Wed, 05/11 13:56, Kevin Wolf wrote: > Am 11.05.2016 um 13:48 hat Richard W.M. Jones geschrieben: > > While I remember there is another concern that doesn't seem to be > > addressed in this patch series. What happens when a guest is paused? > > I think exclusive locks should be converted to

Re: [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device

> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, May 12, 2016 4:11 AM > On Wed, 11 May 2016 06:45:41 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Thursday, May 05, 2016 1:06 AM > > > > > > + > > > > > > + ret =

Re: [Qemu-devel] [PATCH 0/5] cpu-exec: Restructure cpu_exec()

On 05/11/2016 12:21 AM, Sergey Fedorov wrote: From: Sergey Fedorov cpu_exec() was a huge function also sprinkled with some preprocessor directives. It was hard to read and see the main loop crowded by all this code. Restructure cpu_exec() by moving its conceptual parts

Re: [Qemu-devel] [PATCH] fixup! tcg: code_bitmap is not used by user-mode emulation

On 05/11/2016 06:06 AM, Sergey Fedorov wrote: From: Sergey Fedorov Eliminate 'code_write_count' as well. Signed-off-by: Sergey Fedorov Signed-off-by: Sergey Fedorov --- Merged. r~

Re: [Qemu-devel] [RFC 12/42] pc: initialize legacy hotplug only for 2.6 and older machine types

On Wed, May 11, 2016 at 03:50:39PM +0200, Igor Mammedov wrote: > On Tue, 10 May 2016 17:24:14 -0300 > Eduardo Habkost wrote: > > > On Mon, May 02, 2016 at 02:33:21PM +0200, Igor Mammedov wrote: > > > on old machine types CPU hotplug was uncondtionally > > > enabled since it

Re: [Qemu-devel] [RFC 12/42] pc: initialize legacy hotplug only for 2.6 and older machine types

On Thu, May 12, 2016 at 12:51:55AM +0300, Michael S. Tsirkin wrote: > On Wed, May 11, 2016 at 03:50:39PM +0200, Igor Mammedov wrote: > > On Tue, 10 May 2016 17:24:14 -0300 > > Eduardo Habkost wrote: > > > > > On Mon, May 02, 2016 at 02:33:21PM +0200, Igor Mammedov wrote: > >

[Qemu-devel] [ANNOUNCE] QEMU 2.6.0 is now available

Hello, On behalf of the QEMU Team, I'd like to announce the availability of the QEMU 2.6.0 release. This release contains 2400+ commits from 186 authors. You can grab the tarball from our download page here: http://wiki.qemu.org/Download The full list of changes are available at:

Re: [Qemu-devel] Statically Compiling including SDL

On 11 May 2016 at 21:39, Sam McKelvie wrote: > Apologies for breaking the thread of the discussion; still > haven’t figured out how to cold-respond to a thread without an incoming email. > > Thank you for your response. Indeed, for my purposes I only need the > static linux-user

[Qemu-devel] [PATCH v4 03/11] nbd: Quit server after any write error

We should never ignore failure from nbd_negotiate_send_rep(); if we are unable to write to the client, then it is not worth trying to continue the negotiation. Fortunately, the problem is not too severe - chances are that the errors being ignored here (mainly inability to write the reply to the

Re: [Qemu-devel] [PATCH] target-mips: fix call to memset in soft reset code

On 11 May 2016 at 20:28, Christian Borntraeger wrote: > On 05/09/2016 07:57 PM, Peter Maydell wrote: >> On 9 May 2016 at 18:55, Peter Maydell wrote: >>> On 9 May 2016 at 18:53, Stefan Weil wrote: I suggest to apply this

[Qemu-devel] [PATCH v4 02/11] nbd: More debug typo fixes, use correct formats

Clean up some debug message oddities missed earlier; this includes some typos, and recognizing that %d is not necessarily compatible with uint32_t. Also add a couple messages that I found useful while debugging things. Signed-off-by: Eric Blake --- v4: add a couple more

[Qemu-devel] [PATCH v4 04/11] nbd: Improve server handling of bogus commands

We have a few bugs in how we handle invalid client commands: - A client can send an NBD_CMD_DISC where from + len overflows, convincing us to reply with an error and stay connected, even though the protocol requires us to silently disconnect. Fix by hoisting the special case sooner. - A client

[Qemu-devel] [PATCH v4 05/11] nbd: Reject unknown request flags

The NBD protocol says that clients should not send a command flag that has not been negotiated (whether by the client requesting an option during a handshake, or because we advertise support for the flag in response to NBD_OPT_EXPORT_NAME), and that servers should reject invalid flags with EINVAL.

[Qemu-devel] [PATCH v4 09/11] nbd: Add qemu-nbd -D for human-readable description

The NBD protocol allows servers to advertise a human-readable description alongside an export name during NBD_OPT_LIST. Add an option to pass through the user's string to the NBD client. Doing this also makes it easier to test commit 200650d4, which is the client counterpart of receiving the

[Qemu-devel] [PATCH v4 06/11] nbd: Group all Linux-specific ioctl code in one place

NBD ioctl()s are used to manage an NBD client session where initial handshake is done in userspace, but then the transmission phase is handed off to the kernel through a /dev/nbdX device. As such, all ioctls sent to the kernel on the /dev/nbdX fd belong in client.c; nbd_disconnect() was

[Qemu-devel] [PATCH v4 07/11] nbd: Clean up ioctl handling of qemu-nbd -c

The kernel ioctl() interface into NBD is limited to 'unsigned long'; we MUST pass in input with that type (and not int or size_t, as there may be platform ABIs where the wrong types promote incorrectly through var-args). Furthermore, on 32-bit platforms, the kernel is limited to a maximum export

[Qemu-devel] [PATCH v4 01/11] nbd: Use BDRV_REQ_FUA for better FUA where supported

Rather than always flushing ourselves, let the block layer forward the FUA on to the underlying device - where all underlying layers also understand FUA, we are now more efficient; and where any underlying layer doesn't understand it, now the block layer takes care of the full flush fallback on

[Qemu-devel] [PATCH v4 08/11] nbd: Limit nbdflags to 16 bits

Rather than asserting that nbdflags is within range, just give it the correct type to begin with :) nbdflags corresponds to the per-export portion of NBD Protocol "transmission flags", which is 16 bits in response to NBD_OPT_EXPORT_NAME and NBD_OPT_GO. Furthermore, upstream NBD has never passed

[Qemu-devel] [PATCH v4 10/11] nbd: Detect servers that send unexpected error values

Add some debugging to flag servers that are not compliant to the NBD protocol. This would have flagged the server bug fixed in commit c0301fcc. Signed-off-by: Eric Blake Reviewed-by: Alex Bligh --- v3: later in series, but no change --- nbd/client.c | 4

[Qemu-devel] [PATCH v4 11/11] nbd: Avoid magic number for NBD max name size

Declare a constant and use that when determining if an export name fits within the constraints we are willing to support. Note that upstream NBD recently documented that clients MUST support export names of 256 bytes (not including trailing NUL), and SHOULD support names up to 4096 bytes. 4096

[Qemu-devel] [PATCH v4 00/11] nbd: tighter protocol compliance

Fix several corner-case bugs in our implementation of the NBD protocol, both as client and as server. Depends on Kevin's block-next branch: git://repo.or.cz/qemu/kevin.git block-next Also available as a tag at this location: git fetch git://repo.or.cz/qemu/ericb.git nbd-flags-v4 Broken out of a

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Wed, 11 May 2016 17:15:15 +0800 Jike Song wrote: > On 05/11/2016 12:02 AM, Neo Jia wrote: > > On Tue, May 10, 2016 at 03:52:27PM +0800, Jike Song wrote: > >> On 05/05/2016 05:27 PM, Tian, Kevin wrote: > From: Song, Jike > > IIUC, an api-only domain is a

Re: [Qemu-devel] [RFC 12/42] pc: initialize legacy hotplug only for 2.6 and older machine types

On Wed, May 11, 2016 at 03:50:39PM +0200, Igor Mammedov wrote: > On Tue, 10 May 2016 17:24:14 -0300 > Eduardo Habkost wrote: > > > On Mon, May 02, 2016 at 02:33:21PM +0200, Igor Mammedov wrote: > > > on old machine types CPU hotplug was uncondtionally > > > enabled since it

[Qemu-devel] [PATCH v2 1/2] exec: [tcg] Track which vCPU is performing translation and execution

Information is tracked inside the TCGContext structure, and later used by tracing events with the 'tcg' and 'vcpu' properties. The 'cpu' field is used to check tracing of translation-time events ("*_trans"). The 'tcg_env' field is used to pass it to execution-time events ("*_exec").

[Qemu-devel] [PATCH v2 1/2] exec: [tcg] Track which vCPU is performing translation and execution

Information is tracked inside the TCGContext structure, and later used by tracing events with the 'tcg' and 'vcpu' properties. The 'cpu' field is used to check tracing of translation-time events ("*_trans"). The 'tcg_env' field is used to pass it to execution-time events ("*_exec").

[Qemu-devel] [PATCH v2 0/2] trace: Add event for vCPU memory accesses

This series adds an event to track information related to memory accesses performed by the guest CPUs ("guest_mem_before"). A future series might extend this to contain the physical address and memory value (e.g., "guest_mem_after"). Signed-off-by: Lluís Vilanova ---

[Qemu-devel] [PATCH v2 0/2] trace: Add event for vCPU memory accesses

This series adds an event to track information related to memory accesses performed by the guest CPUs ("guest_mem_before"). A future series might extend this to contain the physical address and memory value (e.g., "guest_mem_after"). Signed-off-by: Lluís Vilanova ---

[Qemu-devel] [PATCH v2 2/2] trace: [all] Add "guest_mem_before" event

Signed-off-by: Lluís Vilanova --- include/exec/cpu_ldst_template.h | 25 include/exec/cpu_ldst_useronly_template.h | 22 ++ tcg/tcg-op.c | 32 ++-- trace-events

[Qemu-devel] [PATCH v2 2/2] trace: [all] Add "guest_mem_before" event

Signed-off-by: Lluís Vilanova --- include/exec/cpu_ldst_template.h | 25 include/exec/cpu_ldst_useronly_template.h | 22 ++ tcg/tcg-op.c | 32 ++-- trace-events

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 04:38:29PM +0100, Alex Bligh wrote: > On 10 May 2016, at 16:29, Eric Blake wrote: > > So the kernel is currently one of the clients that does NOT honor block > > sizes, and as such, servers should be prepared for ANY size up to > > UINT_MAX (other than

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 09:29:23AM -0600, Eric Blake wrote: > On 05/10/2016 09:08 AM, Alex Bligh wrote: > > Eric, > > > >> Hmm. The current wording of the experimental block size additions does > >> NOT allow the client to send a NBD_CMD_TRIM with a size larger than the > >> maximum

[Qemu-devel] [PATCH v8 3/3] Add optionrom compatible with fw_cfg DMA version

From: Marc Marí This optionrom is based on linuxboot.S. Signed-off-by: Marc Marí Signed-off-by: Richard W.M. Jones --- .gitignore| 4 + hw/i386/pc.c | 10 +- hw/nvram/fw_cfg.c

[Qemu-devel] [PATCH v8 1/3] scripts/signrom.py: Allow option ROM checksum script to write the size header.

Modify the signrom.py script so that if the size byte in the header is 0 (ie. not set) then the script will set the size. If the size byte is non-zero then we do the same as before, so this doesn't require changes to any existing ROM sourcecode. Signed-off-by: Richard W.M. Jones

[Qemu-devel] [PATCH v8 0/3] Add optionrom compatible with fw_cfg DMA version

v7 -> v8: - Add file magic check to signrom.py. - Some whitespace-only changes in linuxboot_dma.c. - Retested both clang & GCC with both small and large initrd. Rich.

[Qemu-devel] [PATCH v8 2/3] scripts/signrom.py: Check for magic in option ROMs.

Because of the risk that compilers might not emit the asm() block at the beginning of the option ROM, check that the ROM contains the required magic signature. Signed-off-by: Richard W.M. Jones --- scripts/signrom.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)

Re: [Qemu-devel] [Nbd] [PATCH] nbd: fix trim/discard commands with a length bigger than NBD_MAX_BUFFER_SIZE

On Tue, May 10, 2016 at 04:08:50PM +0100, Alex Bligh wrote: > What surprises me is that a release kernel is using experimental > NBD extensions; there's no guarantee these won't change. Or does > fstrim work some other way? What makes you say NBD_CMD_TRIM is experimental? It's been implemented

Re: [Qemu-devel] [PATCH v7 2/2] Add optionrom compatible with fw_cfg DMA version

On Wed, May 11, 2016 at 10:07:27PM +0200, Paolo Bonzini wrote: > > > On 11/05/2016 19:42, Richard W.M. Jones wrote: > > + > > +#ifdef __clang__ > > +#define ADDR32 > > +#else > > +#define ADDR32 "addr32 " > > +#endif > > + > > +static inline uint16_t readw_es(uint16_t offset) > > +{ > > +

Re: [Qemu-devel] Statically Compiling including SDL

Apologies for breaking the thread of the discussion; still haven’t figured out how to cold-respond to a thread without an incoming email. Thank you for your response. Indeed, for my purposes I only need the static linux-user binary, so I can just remove SDL and it’s not a problem. I’d agree that

Re: [Qemu-devel] [patch v6 11/12] vfio: register aer resume notification handler for aer resume

On Wed, 11 May 2016 11:11:39 +0800 Zhou Jie wrote: > Hi, Alex > What do you think about the following solution? > 1. Detect support for resume notification. > If host vfio driver does not have resume notifier flags, > Directly fail to boot up

Re: [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device

On Wed, 11 May 2016 06:45:41 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Thursday, May 05, 2016 1:06 AM > > > > > + > > > > > + ret = remap_pfn_range(vma, virtaddr, pgoff, req_size, pg_prot); > > > > > > > > > > > > > So not supporting

Re: [Qemu-devel] [PATCH v7 2/2] Add optionrom compatible with fw_cfg DMA version

On 11/05/2016 19:42, Richard W.M. Jones wrote: > + > +#ifdef __clang__ > +#define ADDR32 > +#else > +#define ADDR32 "addr32 " > +#endif > + > +static inline uint16_t readw_es(uint16_t offset) > +{ > +uint16_t val; > +asm(ADDR32"movw %%es:(%1), %0" : "=r"(val) : "r"((uint32_t)offset)); >

[Qemu-devel] [PATCH 3/7] pc: Add the SMBus device to the ACPI tables

From: Corey Minyard Signed-off-by: Corey Minyard --- hw/i386/acpi-build.c | 15 +++ hw/i386/pc.c | 2 ++ hw/i386/pc_piix.c| 2 ++ hw/i386/pc_q35.c | 2 ++

[Qemu-devel] [PATCH 1/7] i2c: Fix the PM SMBus driver so it actually works correctly

From: Corey Minyard The PM SMBus driver really just didn't work. This patch fixes it to be fairly hardware compliant with the actual hardware. Plus it adds interrupts and working block transfers. Signed-off-by: Corey Minyard --- hw/i2c/pm_smbus.c

[Qemu-devel] [PATCH 2/7] pm_smbus: Add the ability to force block transfer enable

From: Corey Minyard The PIIX4 hardware has block transfer buffer always enabled in the hardware, but the i801 does not. Add a parameter to pm_smbus_init to force on the block transfer so the PIIX4 handler can enable this by default, as it was disabled by default before.

[Qemu-devel] [PATCH 5/7] acpi: Add I2c serial bus CRS handling

From: Corey Minyard Signed-off-by: Corey Minyard --- hw/acpi/aml-build.c | 42 ++ include/hw/acpi/aml-build.h | 11 +++ 2 files changed, 53 insertions(+) diff --git a/hw/acpi/aml-build.c

[Qemu-devel] [PATCH 7/7] ipmi: Add ACPI to the SMBus IPMI device

From: Corey Minyard Signed-off-by: Corey Minyard --- hw/ipmi/smbus_ipmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/ipmi/smbus_ipmi.c b/hw/ipmi/smbus_ipmi.c index 4e7203b..3a34aaf 100644 --- a/hw/ipmi/smbus_ipmi.c +++

[Qemu-devel] [PATCH 4/7] ipmi: Add an SMBus IPMI interface

From: Corey Minyard Signed-off-by: Corey Minyard --- default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/ipmi/Makefile.objs | 1 + hw/ipmi/smbus_ipmi.c | 216

[Qemu-devel] [PATCH 0/7] Fix PM SMBus and add IPMI over SMBus

This series of patches fixes a bunch of issues in the PM SMBus driver for x86 chips so that IPMI over SMBus can actually work (and other things can work, too, I have a number of devices that I've added later, and there's the eeprom, of course). It then adds an IPMI device that sits on I2C and

[Qemu-devel] [PATCH 6/7] ipmi: Fix SSIF ACPI handling to use the right CRS

From: Corey Minyard Signed-off-by: Corey Minyard --- hw/acpi/ipmi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/acpi/ipmi.c b/hw/acpi/ipmi.c index 731f4ad..c187fdd 100644 --- a/hw/acpi/ipmi.c +++ b/hw/acpi/ipmi.c @@ -49,7

Re: [Qemu-devel] [libvirt] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions

On Wed, May 11, 2016 at 09:11:33AM +0200, Markus Armbruster wrote: > Eduardo Habkost writes: > > > On Tue, May 10, 2016 at 10:23:16AM +0200, Markus Armbruster wrote: > >> Eduardo Habkost writes: > >> > >> > On Mon, May 09, 2016 at 09:20:15AM -0600,

Re: [Qemu-devel] [PATCH] target-mips: fix call to memset in soft reset code

On 05/09/2016 07:57 PM, Peter Maydell wrote: > On 9 May 2016 at 18:55, Peter Maydell wrote: >> On 9 May 2016 at 18:53, Stefan Weil wrote: >>> I suggest to apply this patch to 2.6, if this is still possible >> >> It is not; sorry. I think we have

Re: [Qemu-devel] [PATCH for-2.7 0/4] cpu: Finally remove cpudef_init()

On Sat, Apr 09, 2016 at 05:37:43PM -0300, Eduardo Habkost wrote: > The only reason cpudef_init() still exists is the > qemu_hw_version()-based model_id hack at x86_cpudef_setup(). > > Move the model_id hack to machine compat_props so we can make the > model_id field constant at the CPU model

Re: [Qemu-devel] [PATCH v3 0/3] target-i386: Use C struct for xsave area layout, offsets & sizes

On Fri, Dec 04, 2015 at 01:00:52PM -0200, Eduardo Habkost wrote: > target-i386/cpu.c:ext_save_area uses magic numbers for the xsave > area offets and sizes, and target-i386/kvm.c:kvm_{put,get}_xsave() > uses offset macros and bit manipulation to access the xsave area. > This series changes both to

Re: [Qemu-devel] Statically Compiling including SDL

On 11 May 2016 at 19:12, Sam McKelvie wrote: > I am having this same problem. Looking at the configure script > it looks like it prefers to use: > >pkg-config sdl —static > > to get the static linker flags, rather than: > > sdl-config —static-libs Are you trying to

Re: [Qemu-devel] [RFC PATCH v4] fw/pci: Add support for mapping Intel IGD via QEMU

On Wed, 11 May 2016 11:19:25 -0400 "Kevin O'Connor" wrote: > On Tue, May 10, 2016 at 09:19:52AM -0600, Alex Williamson wrote: > > On Tue, 23 Feb 2016 10:22:33 -0500 > > "Kevin O'Connor" wrote: > > > > > On Tue, Feb 16, 2016 at 02:39:27PM -0700, Alex

Re: [Qemu-devel] Statically Compiling including SDL

I am having this same problem. Looking at the configure script it looks like it prefers to use: pkg-config sdl —static to get the static linker flags, rather than: sdl-config —static-libs The former returns an empty string; the latter returns the correct library list. If it had used the

[Qemu-devel] [PATCH v7 1/2] scripts/signrom.py: Allow option ROM checksum script to write the size header.

Modify the signrom.py script so that if the size byte in the header is 0 (ie. not set) then the script will set the size. If the size byte is non-zero then we do the same as before, so this doesn't require changes to any existing ROM sourcecode. Signed-off-by: Richard W.M. Jones

[Qemu-devel] [PATCH v7 0/2] Add optionrom compatible with fw_cfg DMA version

v6 -> v7: - This version compiles and works with both GCC (tested 6.1.1) and with Clang (tested 3.8.0). - Uses -m16 mode on both compilers to generate i8086 code. - The signrom.py script has been modified so it can (optionally) generate the size field in the header. - Tested with

[Qemu-devel] [PATCH v7 2/2] Add optionrom compatible with fw_cfg DMA version

From: Marc Marí This optionrom is based on linuxboot.S. Signed-off-by: Marc Marí Signed-off-by: Richard W.M. Jones --- .gitignore| 4 + hw/i386/pc.c | 10 +- hw/nvram/fw_cfg.c

Re: [Qemu-devel] [RFC 2/2] virtio: show features acked by guest in 'info qtree' dump

On Wed, May 11, 2016 at 12:52:04PM +0300, Denis V. Lunev wrote: > It is very convinient and useful for debug purpose to expose the set of > features negotiated with guest. The patch exports those features via > read-only bit properties. > > Signed-off-by: Denis V. Lunev > CC:

[Qemu-devel] [PATCH v2 0/5] Add IPMI firmware tables

Now that 2.6 is out, re-post these patches. No changes since the previous release.

[Qemu-devel] [PATCH v2 2/5] smbios: Move table build tools into an include file.

From: Corey Minyard This will let things in other files (like IPMI) build SMBIOS tables. Signed-off-by: Corey Minyard --- hw/smbios/smbios.c | 70 --- hw/smbios/smbios_build.h | 77

[Qemu-devel] [PATCH v2 3/5] ipmi: Add SMBIOS table entry

From: Corey Minyard Add an IPMI table entry to the SMBIOS. Signed-off-by: Corey Minyard Acked-by: Michael S. Tsirkin --- default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/smbios/Makefile.objs

[Qemu-devel] [PATCH v2 1/5] pc: Postpone SMBIOS table installation to post machine init

From: Corey Minyard This is the same place that the ACPI SSDT table gets added, so that devices can add themselves to the SMBIOS table. Signed-off-by: Corey Minyard --- hw/i386/pc.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-)

[Qemu-devel] [PATCH v2 5/5] bios: Add tests for the IPMI ACPI and SMBIOS entries

From: Corey Minyard Signed-off-by: Corey Minyard --- tests/acpi-test-data/pc/DSDT.ipmikcs | Bin 0 -> 5683 bytes tests/acpi-test-data/q35/DSDT.ipmibt | Bin 0 -> 8456 bytes tests/bios-tables-test.c | 58 ---

[Qemu-devel] [PATCH v2 4/5] acpi: Add IPMI table entries

From: Corey Minyard Use the new ACPI table construction tools to create an ACPI entry for IPMI. This adds a function called from build_dsdt to add an DSDT entry for IPMI if IPMI is compiled in and has registered firmware. It also adds a dummy function if IPMI is not

[Qemu-devel] [PATCH] fixup! tcg: code_bitmap is not used by user-mode emulation

From: Sergey Fedorov Eliminate 'code_write_count' as well. Signed-off-by: Sergey Fedorov Signed-off-by: Sergey Fedorov --- This series is based on commit 40f646483a11 (cpu-exec: Remove relic orphaned comment) from

Re: [Qemu-devel] [PATCH] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

2016-05-11 12:26-0300, Eduardo Habkost: > On Wed, May 11, 2016 at 02:37:38PM +0200, Radim Krčmář wrote: >> 2016-05-10 16:53-0300, Eduardo Habkost: >> > On Mon, May 09, 2016 at 10:49:00PM +0200, Radim Krčmář wrote: >> >> I looked at a dozen Intel CPU that have this CPUID and all of them >> >>

Re: [Qemu-devel] [PATCH RFC 11/14] increase MAX_CPUMASK_BITS from 255 to 288

On Mon, 9 May 2016 11:26:57 +0200 Igor Mammedov wrote: > so that it would be possible to increase maxcpus limit > for x86 target. Keep spapr/virt_arm at limit they used > to have 255. > > Signed-off-by: Igor Mammedov > --- As said in my other post,

Re: [Qemu-devel] [PATCH] sysemu: support up to 1024 vCPUs

On Wed, 11 May 2016 16:20:08 +0200 Igor Mammedov wrote: > On Wed, 11 May 2016 16:00:04 +0200 > Greg Kurz wrote: > > > Some systems can already provide more than 255 hardware threads. > > > > Bumping the QEMU limit to 1024 seems reasonable: > > -

Re: [Qemu-devel] [PATCH] [untested] gtk: update grab code for gtk 3.20

On 05/11/2016 06:48 AM, Gerd Hoffmann wrote: > Applies on top of the pending ui pull request. Fixes the remaining gtk > 3.20 warnings. Not tested (other than building) because I don't have a > F24 box at hand. Feedback welcome. > > Signed-off-by: Gerd Hoffmann > --- >

Re: [Qemu-devel] [PATCH for-2.6? v2] qemu-iotests: iotests: fail hard if not run via "check"

On 19.04.2016 21:34, Sascha Silbe wrote: > Running an iotests-based Python test directly might appear to work, > but may fail in subtle ways and is insecure: > > - It creates files with predictable file names in a world-writable > location (/var/tmp). > > - Tests expect the environment to be

Re: [Qemu-devel] [PATCH RFC 0/3] qdev: order devices by priority before creating them

On 11/05/2016 17:19, Michael S. Tsirkin wrote: > > If there's just one of its class you can use -global (similar to how we > > use it for floppies). > > I don't like that there's no documentation for these > at all. How are users supposed to know which type to use > for -global? Documentation,

Re: [Qemu-devel] [PATCH] target-i386: implement CPUID[0xB] (Extended Topology Enumeration)

On Wed, May 11, 2016 at 02:37:38PM +0200, Radim Krčmář wrote: > 2016-05-10 16:53-0300, Eduardo Habkost: > > On Mon, May 09, 2016 at 10:49:00PM +0200, Radim Krčmář wrote: > >> I looked at a dozen Intel CPU that have this CPUID and all of them > >> always had Core offset as 1 (a wasted bit when

Re: [Qemu-devel] [RFC PATCH v4] fw/pci: Add support for mapping Intel IGD via QEMU

On Tue, May 10, 2016 at 09:19:52AM -0600, Alex Williamson wrote: > On Tue, 23 Feb 2016 10:22:33 -0500 > "Kevin O'Connor" wrote: > > > On Tue, Feb 16, 2016 at 02:39:27PM -0700, Alex Williamson wrote: > > > QEMU provides two fw_cfg files to support IGD. The first holds the > >

Re: [Qemu-devel] [PATCH RFC 0/3] qdev: order devices by priority before creating them

On Wed, May 11, 2016 at 05:09:56PM +0200, Paolo Bonzini wrote: > > > On 11/05/2016 15:55, Michael S. Tsirkin wrote: > > > Could they "know" it by adding an iommu=foo argument to e.g. the PCI > > > bridge, pointing to the IOMMU device? > > > > People don't create the pci host bridge though, it's

  1   2   3   >