Re: [PATCH 1/2] target/ppc: Restore [H]DEXCR to 64-bits

On Wed, 2024-03-20 at 14:31 +1000, Nicholas Piggin wrote: > On Wed Mar 20, 2024 at 11:50 AM AEST, Benjamin Gray wrote: > > The DEXCR emulation was recently changed to a 32-bit register, > > possibly > > because it does have a 32-bit read-only view. It is a full 64-bit &

[PATCH 1/2] target/ppc: Restore [H]DEXCR to 64-bits

The DEXCR emulation was recently changed to a 32-bit register, possibly because it does have a 32-bit read-only view. It is a full 64-bit SPR though, so use the corresponding 64-bit write functions. Fixes: c9de140c2171 ("target/ppc: Fix width of some 32-bit SPRs") Signed-off-by: Ben

[PATCH 2/2] target/ppc: Fix GDB register indexing on secondary CPUs

, then return early if the XML is cached. Otherwise we generate the XML using the now already initialised gdb_id values. Fixes: 1b53948ff8f7 ("target/ppc: Use GDBFeature for dynamic XML") Signed-off-by: Benjamin Gray --- target/ppc/gdbstub.c | 31 --- 1 file c

[Bug 2054889] Re: pcap streams are text files which insert 0xD in Windows version

I have sent a patch as directed. I hope it is correctly done. Thank you. Ben -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/2054889 Title: pcap streams are text files which insert 0xD in Windows

[Bug 2054889] [NEW] pcap streams are text files which insert 0xD in Windows version

Public bug reported: Since Windows text files use CRLFs for all \n, the Windows version of QEMU inserts a CR in the PCAP stream when a LF is encountered when using USB PCAP files. Starting at line 275 in hw/usb/bus (https://gitlab.com/qemu-

[PATCH] powerpc/spapr: Add DEXCR to device tree

anything), so declare this in the device tree. Signed-off-by: Benjamin Gray --- The current design appears to duplicate the previous block and add the new features after it. I copied that for the 3.10 features, but not sure how well this scales, so alternatives welcome. --- hw/ppc/spapr.c | 33

Support -O

Hi QEMU, I am trying to use the -O function to convert a file format to vmdk, but get the below response. Please could you help? Bens-iMac:~ ben$ qemu-img -O output_fmt vmdk /Users/ben/Documents/Windows11_InsiderPreview_Client_ARM64_en-us_22598.VHDX ~/Desktop/Install/Windows11ARM.vmdk qemu-img:

Re: [PATCH] Updating gdbstub to allow safe multithreading in usermode emulation

Sorry, my email service mangled the link I ment to send. It should be:https://github.com/odinssecrets/qemu_gdbstub_multithread_testingOn May 28, 2022 3:53 PM, Ben Cohen wrote:I was testing some multi-threaded code in qemu's usermode and ran into issues with the gdbstub because the user mode qemu

Re: [PULL 19/35] ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge

On Thu, 2022-03-31 at 18:51 +0100, Peter Maydell wrote: > > Hi; Coverity has just spotted an error in this old change > (CID 1487176): Oh my this is old ... I don't work for IBM anymore but I found the relevant doc here:

[Bug 1947933] [NEW] xHCI Port Status Change Event at port powered

Public bug reported: Per section 4.19.3 of the xHCI version 1.0 specification, when the Port Power bit transitions from 0 to 1, if there is a connection on that port, a Port Status Change Event should be issued. Currently, when the port is powered, this event is not being issued. I don't know

Re: [PATCH 1/2] hw/misc/bcm2835_property: Fix framebuffer with recent RPi kernels

On Mon, 2021-10-18 at 11:47 +0200, Philippe Mathieu-Daudé wrote: > > > I've just checked the rpi-5.15.y branch and it's the same. > > Indeed. I stopped testing recent kernels because they use too many > features QEMU don't implement. > > Our model should generate the DTB blob of devices

Re: [PATCH 1/2] hw/misc/bcm2835_property: Fix framebuffer with recent RPi kernels

On Sun, 2021-10-17 at 17:08 +0200, Philippe Mathieu-Daudé wrote: > Hi Benjamin, > > On 10/17/21 09:48, Benjamin Herrenschmidt wrote: > > The framebuffer driver fails to initialize with recent Raspberry Pi > > kernels, such as the ones shipped in the current RaspiOS ima

[PATCH 2/2] hw/misc/bcm2835_property: Add dummy Get/Set GPIO virt buf messages

Without these the RaspiOS kernel tries to ioremap some bogus address and dumps a backtrace in the console at boot. These work around it. The virt-gpio driver still fails to initialize but much more cleanly Signed-off-by: Benjamin Herrenschmidt --- hw/misc/bcm2835_property.c | 7 +++ 1 file

[PATCH 1/2] hw/misc/bcm2835_property: Fix framebuffer with recent RPi kernels

fails is broken. So implement the call and claim we have exactly one display Signed-off-by: Benjamin Herrenschmidt --- hw/misc/bcm2835_property.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c index 73941bdae9..b958fa6a5c 100644

Re: [PATCH for-6.1? v2 7/9] hw/pci-hist/pnv_phb4: Fix typo in pnv_phb4_ioda_write

On Sun, 2021-07-25 at 23:27 +0200, Philippe Mathieu-Daudé wrote: > +Cédric/Benjamin > > On 7/25/21 2:24 PM, Richard Henderson wrote: > > From clang-13: > > hw/pci-host/pnv_phb4.c:375:18: error: variable 'v' set but not used > > \ > > [-Werror,-Wunused-but-s

[Bug 1859254] Re: host window size does not change when guest video screen size changes while moving host window

Bug still exists, therefore I have marked as 'new' per your request. Using latest version of QEMU for Windows (from https://qemu.weilnetz.de/) still does not adjust the host window size if a quest size changes while the host window is being moved. Thank you, Ben ** Changed in: qemu

[Bug 1896561] [NEW] EFI GOP Mode 1366x768

Public bug reported: When using the EFI firmware from https://www.kraxel.org/repos/jenkins/edk2/ (https://www.kraxel.org/repos/jenkins/edk2/edk2.git- ovmf-x64-0-20200919.1453.g7faece6985.noarch.rpm) (OVMF-pure-efi.fd and OVMF_VARS-pure-efi.fd) then using the GOP, setting the mode to 1366x768,

[Bug 1896342] Re: IDE ATA IDENTIFY WORD 106

For more information, Annex-E of the ACS-2 explains this as well. http://www.t13.org/Documents/UploadedDocuments/docs2009/d2015r2 -ATAATAPI_Command_set_-_2_ACS-2.pdf See the statement on the top of page 165 as well. "If bit 13 is set, then bits 3:0 are valid". Page 119 of that same document

[Bug 1896342] [NEW] IDE ATA IDENTIFY WORD 106

Public bug reported: The code at line 202 in hw/ide/core.c (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/core.c;#l201) hard codes bit 13 set. However, get_physical_block_exp() can and may return 0, which is a valid response. If get_physical_block_exp() does return zero, bit 13 should not

[Bug 1863441] Re: cmd_mode_sense always reports 0x70, no CDROM present

Since I posted this bug report, I have done a little more research and this specific part of this command is actually quite obsolete. It use to be documented (MMC v1.2 Draft), but later versions have actually removed this part of the command, even stating "obsolete" in some of the documentation.

Re: Qemu TCG Plugins - how to access guest registers?

On Mon, Mar 30, 2020 at 1:37 PM Alex Bennée wrote: > > Benjamin writes: > > > Thanks for your quick response. > > > > On Mon, Mar 30, 2020 at 9:15 AM Alex Bennée > wrote: > > > >> > >> Lukas Straub writes: > >> > >>

Re: Qemu TCG Plugins - how to access guest registers?

Thanks for your quick response. On Mon, Mar 30, 2020 at 9:15 AM Alex Bennée wrote: > > Lukas Straub writes: > > >> My question is, how do I access the guest memory and registers from the > >> plugin callback function? The API seems to indicate that it is possible, > >> since the callback

Qemu TCG Plugins - how to access guest registers

Qemu version 4.2.0 includes new functionality for something called TCG Plugins. There are a few examples in the tests/plugins directory, and the API is more or less defined in qemu-plugin.h. This file defines two enumerated types, "qemu_plugin_cb_flags" and "qemu_plugin_mem_rw", which are passed

Re: [EXTERNAL] [PATCH 2/2] target/ppc: Fix ISA v3.0 (POWER9) slbia implementation

On Wed, 2020-03-18 at 18:08 +0100, Cédric Le Goater wrote: > On 3/18/20 5:41 AM, Nicholas Piggin wrote: > > Linux using the hash MMU ("disable_radix" command line) on a POWER9 > > machine quickly hits translation bugs due to using v3.0 slbia > > features that are not implemented in TCG. Add them.

[Bug 1863441] [NEW] cmd_mode_sense always reports 0x70, no CDROM present

Public bug reported: cmd_mode_sense https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/atapi.c;hb=refs/heads/master#l852 always reports 0x70 in byte 2 returned, indicating no CD-ROM present. If CD-ROM is present, should report 0x01 (or 0x11). If CD-ROM absent, should report 0x70. ** Affects:

Re: Semihosting, arm, riscv, ppc and common code

On Wed, 2020-01-15 at 12:01 +, Alex Bennée wrote: > > > There seem to be some linux-user stuff in there, I'm mostly considering > > whatever ARM does today but we can certainly extend later. > > Depends on if it is to be used. AFAIK the main users of arm linux user > are compiler test cases

Re: Semihosting, arm, riscv, ppc and common code

On Thu, 2020-01-16 at 00:02 +0200, Liviu Ionescu wrote: > > ... they did have the opportunity to do better, and did not. > > I don't know why you present Arm semihosting as a disaster. It is not > perfect, but it is functional, and common unit tests use only a small > subset of the calls. > >

Re: Semihosting, arm, riscv, ppc and common code

On Wed, 2020-01-15 at 13:32 +, Peter Maydell wrote: > On Wed, 15 Jan 2020 at 01:17, Benjamin Herrenschmidt > wrote: > > On Tue, 2020-01-14 at 09:59 +, Peter Maydell wrote: > > > Note that semihosting is not a "here's a handy QEMU feature" > > >

Re: Semihosting, arm, riscv, ppc and common code

On Tue, 2020-01-14 at 09:59 +, Peter Maydell wrote: > Note that semihosting is not a "here's a handy QEMU feature" > thing. It's an architecture-specific API and ABI, which should > be defined somewhere in a standard external to QEMU. There is no such standard for powerpc today that I know

Re: Semihosting, arm, riscv, ppc and common code

On Tue, 2020-01-14 at 09:51 +, Alex Bennée wrote: > > Well, one of the LCA talks wasn't that interesting so I started > > doing > > it and am almost done :-) > > > > I'll look at doing something for arm, riscv and ppc and send > > patches > > once I get it working. > > Cool. Are you

Re: Semihosting, arm, riscv, ppc and common code

On Tue, 2020-01-14 at 09:32 +0200, Liviu Ionescu wrote: > > On 14 Jan 2020, at 08:25, Benjamin Herrenschmidt < > > b...@kernel.crashing.org> wrote: > > > > I noticed that the bulk of arm-semi.c (or riscv-semi.c) is > > trivially > > made completely gener

Semihosting, arm, riscv, ppc and common code

Hi Folks ! So I started "porting" over (read: copying) the arm semihosting code to ppc to mimmic what Keith did for risv (mostly for picolibc support). I noticed that the bulk of arm-semi.c (or riscv-semi.c) is trivially made completely generic by doing a couple of changes: - Make most

[Bug 1859359] Re: xHCI and event ring handling

Hi Hector, guys, I think I have found my/the error: xHCI, version 1.0, Page 136: "Note: The detection of a Cycle bit mismatch in an Event TRB processed by software indicates the location of the xHC Event Ring Enqueue Pointer and that the Event Ring is empty. Software shall write the ERDP

[Bug 1859378] Re: xhci Control Transfer requiring a Status TRB before starting transfer

I believe it is required to send an error event. It checked for the STATUS TRB and found that it was missing, therefore it must send an Error Event. This is (not so clearly) stated in the specification and I have quoted this in a previous comment. I took it as: If the controller checks for the

[Bug 1859359] Re: xHCI and event ring handling

The xHCI specification states that after processing the Event TRB, software is to write the address of that TRB to the xHC_INTERRUPTER_DEQUEUE. QEMU currently checks this value written and compares it to its own current pointer, which is now incremented to the next available TRB, therefore not

[Bug 1859378] Re: xhci Control Transfer requiring a Status TRB before starting transfer

Just a little more information. In section 4.11.2.2, page 159 of version 1.0 of the xHCI specification, it states: • The xHC shall NOT check for the following Control transfer error conditions. • If a Data Stage TD follows a Setup Stage TD, where wLength = ‘0’. • If a Status Stage TD does

[Bug 1859378] Re: xhci Control Transfer requiring a Status TRB before starting transfer

Removing this check will indeed require a bit of a re-write. The way the code is now, the transfer expects a SETUP packet to be first. If you remove the check I ask about above, will the next transfer show that it is the STATUS packet? If so, then the check at line 1696 will indeed catch and

[Bug 1859378] [NEW] xhci Control Transfer requiring a Status TRB before starting transfer

Public bug reported: This may not necessarily be a bug, but more of a change. A little background may need to be in order. With all USB Control transfers, there is a SETUP transfer, zero or more DATA transfers, and if successful, a STATUS transfer. This STATUS transfer is used to indicate to

[Bug 1859359] Re: xHCI and event ring handling

My apologizes. I forgot that it was 2^ERSTMAX. I really need to get some sleep :-) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1859359 Title: xHCI and event ring handling Status in QEMU:

[Bug 1859359] Re: xHCI and event ring handling

Please note that the current code reports zero (0) https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c#l2737 Bits 7:4 is this limit and the current code has these bits as zero. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to

[Bug 1859359] Re: xHCI and event ring handling

I failed to note above that the HCSPARAMS2 register does indeed limit the count of segments in the Event Ring. I guess as long as you never change this value from one (1) you will be okay. However, the spurious interrupt stuff still stands as a bug. Thank you, Ben -- You received this bug

[Bug 1859359] [NEW] xHCI and event ring handling

Public bug reported: I believe that the Event Ring handling in QEMU is not correct. For example, an Event Ring may have multiple segments. However, the code in xhci_write_event() (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb /hcd-xhci.c;hb=HEAD#l645), starting with line 668, seems to only

[Bug 1859254] [NEW] host window size does not change when guest video screen size changes while moving host window

Public bug reported: When QEMU is emulating a legacy text mode, then switches to a VESA mode, if you happen to be moving the host window while the switch is made, the host window never changes size. The emulated size does, but the host window doesn't. For example, at Legacy boot up, the screen

Re: [Qemu-devel] [PATCH 5/6] memory_ldst: Add atomic ops for PTE updates

On Mon, 2019-04-15 at 13:38 +1000, David Gibson wrote: > On Thu, Apr 11, 2019 at 10:00:03AM +0200, Cédric Le Goater wrote: > > From: Benjamin Herrenschmidt > > > > On some architectures, PTE updates for dirty and changed bits need > > to be performed ato

Re: [Qemu-devel] [PATCH 07/19] target/ppc: Make special ORs match x86 pause and don't generate on mttcg

On Tue, 2019-02-12 at 16:59 +1100, David Gibson wrote: > On Mon, Jan 28, 2019 at 10:46:13AM +0100, Cédric Le Goater wrote: > > From: Benjamin Herrenschmidt > > > > There's no point in going out of translation on an SMT OR with > > mttcg since the backend won't do anyt

Re: [Qemu-devel] [PATCH 08/19] target/ppc: Fix nip on power management instructions

On Tue, 2019-02-12 at 17:02 +1100, David Gibson wrote: > On Mon, Jan 28, 2019 at 10:46:14AM +0100, Cédric Le Goater wrote: > > From: Benjamin Herrenschmidt > > > > Those instructions currently raise an exception from within > > the helper. This tends to result in a bog

Re: [Qemu-devel] [PATCH 1/3] memory_ldst: Add atomic ops for PTE updates

On Thu, 2018-12-13 at 21:01 -0600, Richard Henderson wrote: > On 12/13/18 5:58 PM, Benjamin Herrenschmidt wrote: > > +#ifdef CONFIG_ATOMIC64 > > +/* This is meant to be used for atomic PTE updates under MT-TCG */ > > +uint32_t glue(address_space_cmpxchgq_notdir

Re: [Qemu-devel] [PATCH 2/3] i386: Atomically update PTEs with mttcg

Note to RiscV folks: You may want to adapt your code to do the same as this, esp. afaik, what you do today is endian-broken if host and guest endian are different. Cheers, Ben. On Fri, 2018-12-14 at 10:58 +1100, Benjamin Herrenschmidt wrote: > Afaik, this isn't well documented (at le

Re: [Qemu-devel] [PATCH 3/3] ppc: Fix radix RC updates

On Fri, 2018-12-14 at 10:58 +1100, Benjamin Herrenschmidt wrote: > They should be atomic for MTTCG. Note: a real POWER9 core doesn't actually > implement atomic PTE updates, it always fault for SW to handle it. Only > the nest MMU (used by some accelerator devices and GPUs) implements &

[Qemu-devel] [PATCH 3/3] ppc: Fix radix RC updates

it, and doing so in TCG is faster than letting the guest do it. Signed-off-by: Benjamin Herrenschmidt --- target/ppc/cpu.h | 1 + target/ppc/mmu-radix64.c | 70 +--- 2 files changed, 59 insertions(+), 12 deletions(-) diff --git a/target/ppc/cpu.h b/target/ppc

[Qemu-devel] [PATCH 1/3] memory_ldst: Add atomic ops for PTE updates

On some architectures, PTE updates for dirty and changed bits need to be performed atomically. This adds a couple of address_space_cmpxchg* helpers for that purpose. Signed-off-by: Benjamin Herrenschmidt --- include/exec/memory_ldst.inc.h | 6 +++ memory_ldst.inc.c | 78

[Qemu-devel] [PATCH 2/3] i386: Atomically update PTEs with mttcg

with 0 and assume the value read has "final" stable dirty and accessed bits (the TLB invalidation is deferred). Signed-off-by: Benjamin Herrenschmidt --- target/i386/excp_helper.c | 104 +- 1 file changed, 80 insertions(+), 24 deletions(-) diff --gi

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 11:04 -0800, Richard Henderson wrote: > > While I know the existing code just updates the low 32-bits, I'd rather update > the whole entry, and make use of the old value returned from the cmpxchg. So I had to put this on the back burner for a bit, but I'm back to it now.

Re: [Qemu-devel] [PATCH v7 17/19] spapr: Add a pseries-4.0 machine type

On Sun, 2018-12-09 at 20:46 +0100, Cédric Le Goater wrote: > Signed-off-by: Cédric Le Goater > --- If you're going to do that, can we include large decrementer in there too ? (patches from Suraj in my tree but they night need a bit of massaging). > include/hw/compat.h | 3 +++ >

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 16:12 -0800, Richard Henderson wrote: > > You mean translating once for the load and for the udpate ? Do you > > expect that translation to have such a significant cost considering > > that all it needs should be in L1 at that point ? > > I guess if the update is rare-ish,

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 16:12 -0800, Richard Henderson wrote: > On 11/29/18 2:54 PM, Benjamin Herrenschmidt wrote: > > > pdpe_addr = (pml4e & PG_ADDRESS_MASK) + > > > (((gphys >> 30) & 0x1ff) << 3); > > >

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 11:04 -0800, Richard Henderson wrote: > On 11/28/18 3:15 PM, Benjamin Herrenschmidt wrote: > > +static inline uint64_t update_entry(CPUState *cs, target_ulong addr, > > +uint64_t orig_entry, uint32_t bits) > > +{ > &

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 10:26 +0100, Paolo Bonzini wrote: > On 29/11/18 00:15, Benjamin Herrenschmidt wrote: > > Afaik, this isn't well documented (at least it wasn't when I last looked) > > but OSes such as Linux rely on this behaviour: > > > > The HW updates to the

Re: [Qemu-devel] [PATCH v5 08/36] ppc/xive: introduce a simplified XIVE presenter

On Thu, 2018-11-29 at 11:47 +1100, David Gibson wrote: > > 1) read/write accessors which take a word number > > 2) A "get" accessor which copies the whole structure, but "write" > accessor which takes a word number. The asymmetry is a bit ugly, but > it's the non-atomic writeback of the whole

[Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

with 0 and assume the value read has "final" stable dirty and accessed bits (the TLB invalidation is deferred). Signed-off-by: Benjamin Herrenschmidt --- This is lightly tested at this point, mostly to gather comments on the approach. I noticed that RiscV is attempting to do somethi

Re: [Qemu-devel] [PATCH v5 08/36] ppc/xive: introduce a simplified XIVE presenter

On Wed, 2018-11-28 at 10:49 +1100, David Gibson wrote: > On Fri, Nov 16, 2018 at 11:57:01AM +0100, Cédric Le Goater wrote: > > The last sub-engine of the XIVE architecture is the Interrupt > > Virtualization Presentation Engine (IVPE). On HW, they share elements, > > the Power Bus interface (CQ),

Re: [Qemu-devel] [PATCH v5 09/36] ppc/xive: notify the CPU when the interrupt priority is more privileged

On Wed, 2018-11-28 at 11:13 +1100, David Gibson wrote: > Don't you need a cast to avoid (nsr << 8) being a shift-wider-than-size? Shouldn't be a problem as long as it fits in an int, no ? Cheers, Ben.

Re: [Qemu-devel] [PATCH v5 04/36] ppc/xive: introduce the XiveRouter model

On Thu, 2018-11-22 at 15:44 +1100, David Gibson wrote: > > Sorry, didn't think of this in my first reply. > > 1) Does the hardware ever actually write back to the EAS? I know it > does for the END, but it's not clear why it would need to for the > EAS. If not, we don't need the setter. Nope,

Re: [Qemu-devel] [PATCH v5 05/36] ppc/xive: introduce the XIVE Event Notification Descriptors

On Thu, 2018-11-22 at 15:41 +1100, David Gibson wrote: > > > +void xive_end_reset(XiveEND *end) > > +{ > > +memset(end, 0, sizeof(*end)); > > + > > +/* switch off the escalation and notification ESBs */ > > +end->w1 = END_W1_ESe_Q | END_W1_ESn_Q; > > It's not obvious to me what

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Fri, 2018-07-27 at 15:32 +1000, David Gibson wrote: > > > > What is this pci bridge representing? I know PCI-e PHBs typically > > > have a pseudo P2P bridge right under them, but isn't that represnted > > > by the root complex above? > > > > This is the legacy pci bridge under the pcie bus.

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Fri, 2018-07-27 at 10:25 +0200, Cédric Le Goater wrote: > Each PHB creates a pci-bridge device and the PCI bus that comes with it. > It makes things easier to define PCI devices. > > It is still quite complex ... Here is a sample : > > qemu-system-ppc64 -m 2G -machine powernv \ > -cpu

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Fri, 2018-07-27 at 09:16 +0200, Cédric Le Goater wrote: > > I'd have to remember how PQ works on P8 ... my gut feeling is that we > > should resend if P=1 but I'm no 100% certain. > > This is not exactly what the code does. To force a resend, it ignores > P but if Q=1, it bails out without

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Thu, 2018-07-26 at 11:03 +0200, Cédric Le Goater wrote: > Ben, > > I have found out recently that the QEMU PowerNV could hang while accessing > the disk. > > The issue seems to be the phb3_msi_try_send() routine when called from > the resend() handler. The 'P' is ignored in that case but

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Tue, 2018-07-24 at 12:14 +1000, David Gibson wrote: > > I don't know, is there much shared logic ? And the shared bits are the > > subclassing, that's handled that way... > > > > This is really a different piece of HW, a separate ICS implementation, > > that has its own quirks, is configured

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Mon, 2018-07-23 at 14:16 +1000, David Gibson wrote: > > > > Now, this is an ICS subclass, so why shouldn't it directly poke at the > > target ICP ? > > That's ok in theory, but causing it to expose the icp interface to a > new module isn't great. > > > It's an alternate to the normal ICS

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Wed, 2018-07-18 at 16:12 +1000, David Gibson wrote: > On Thu, Jun 28, 2018 at 10:36:32AM +0200, Cédric Le Goater wrote: > > From: Benjamin Herrenschmidt Can you trim your replies ? It's really hard to find your comments in such a long patch... > > diff --git a/include/hw/ppc/x

[Qemu-devel] [Bug 1780812] [NEW] Full-Screen Switch Does Nothing When Using SDL

Public bug reported: When using SDL switches, e.g. -sdl -full-screen -display sdl ... you'd expect the display to start full-screen, as per the switch description, but it just starts in a window. Pressing the full-screen key combination (Ctrl+Alt+F) enters fullscreen mode as expected. Tested

[Qemu-devel] [Bug 1780815] [NEW] SDL Doesn't Rescale Image on Resolution Change

Public bug reported: Whilst in fullscreen mode, if the guest changes resolution for whatever reason, the screen doesn't update the scaling so you end up looking at only part of the screen, e.g. if the guest changes from 640x480 to 1024x768, the image will still be fullscreen, but what you're

Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Thu, 2018-06-28 at 10:00 +0200, Andrea Bolognani wrote: > On Thu, 2018-06-28 at 13:59 +1000, David Gibson wrote: > > On Wed, Jun 27, 2018 at 12:22:31PM +0200, Andrea Bolognani wrote: > > > On Tue, 2018-06-26 at 19:02 +0200, Cédric Le Goater wrote: > > > > I didn't follow that discussion but

Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Wed, 2018-06-27 at 09:46 +0200, Cédric Le Goater wrote: > So the "IBM PHB3 PCIE Root Port" is already user createable. > > I can take a look at user createable PHB3s. I think this is OK from a model > perspective. The object is rather standalone, it needs the machine for > the XICS fabric and

Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Wed, 2018-06-27 at 03:35 +0300, Michael S. Tsirkin wrote: > > > + > > +/* Extract field fname from val */ > > +#define GETFIELD(fname, val)\ > > +(((val) & fname##_MASK) >> fname##_LSH) > > + > > +/* Set field fname of oval to fval > > + * NOTE: oval isn't modified,

Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Tue, 2018-06-26 at 17:57 +0200, Andrea Bolognani wrote: > On Tue, 2018-06-26 at 15:59 +0200, Cédric Le Goater wrote: > > This is a model of the PCIe host bridge found on Power8 chips, > > including PowerBus logic interface, IOMMU support, PCIe root complex, > > XICS MSI and LSI interrupt

Re: [Qemu-devel] [PATCH] virtio-pci: Add subsystem-vendor-id property

Hi Michael, It looks like this was never applied. Can it be, please? On Wed, Dec 20, 2017 at 9:24 AM, Michael S. Tsirkin wrote: > On Wed, Dec 13, 2017 at 10:07:12AM +, Stefan Hajnoczi wrote: > > On Wed, Dec 13, 2017 at 12:26:44AM -0800, Ben Warren via Qemu-devel > wrote:

[Qemu-devel] [PATCH 2/2 v3] slirp: Add classless static routes support to DHCP server

', 'mask_width': 'uint8', '*gateway': 'str' } } [...] 'route': [ 'RouteEntry' ] Signed-off-by: Benjamin Drung <benjamin.dr...@profitbricks.com> --- v2: Address all remarks from Samuel Thibault: * Initialize values directly before usage * Make :gateway part optional * change formu

Re: [Qemu-devel] [PATCH 2/2 v2] slirp: Add classless static routes support to DHCP server

Am Donnerstag, den 08.03.2018, 14:21 -0600 schrieb Eric Blake: > On 03/08/2018 02:07 PM, Benjamin Drung wrote: > > Am Donnerstag, den 08.03.2018, 13:46 -0600 schrieb Eric Blake: > > > On 03/08/2018 12:57 PM, Benjamin Drung wrote: > > > >'*dnssearch': ['String'

Re: [Qemu-devel] [PATCH 2/2 v2] slirp: Add classless static routes support to DHCP server

Am Donnerstag, den 08.03.2018, 13:46 -0600 schrieb Eric Blake: > On 03/08/2018 12:57 PM, Benjamin Drung wrote: > > This patch will allow the user to specify classless static routes > > for > > the replies from the built-in DHCP server. > > > > Signed-of

[Qemu-devel] [PATCH 2/2 v2] slirp: Add classless static routes support to DHCP server

This patch will allow the user to specify classless static routes for the replies from the built-in DHCP server. Signed-off-by: Benjamin Drung <benjamin.dr...@profitbricks.com> --- net/slirp.c | 68 +--- qapi/net.json| 4

Re: [Qemu-devel] [PATCH v3] vmgenid: allow VM Generation ID modification via QMP/HMP

On Fri, Mar 2, 2018 at 2:57 AM, Daniel P. Berrangé wrote: > On Fri, Mar 02, 2018 at 10:37:20AM +0200, Or Idgar wrote: > > From: Or Idgar > > > > This patch allow changing the Virtual Machine Generation > > ID through QMP/HMP while the vm guest is running.

Re: [Qemu-devel] [PATCH] vmgenid: allow VM Generation ID modification via QMP/HMP

On Wed, Feb 28, 2018 at 5:36 AM, Or Idgar wrote: > From: Or Idgar > > This patch allow changing the Virtual Machine Generation > ID through QMP/HMP while the vm guest is running. > As the definition block of VMGENID in ACPI includes the > "Notify"

Re: [Qemu-devel] [PATCH 0/1] slirp: Add domainname option to slirp's DHCP server

Am Samstag, den 17.02.2018, 22:16 +0100 schrieb Samuel Thibault: > Hello, > > Benjamin Drung, on ven. 16 févr. 2018 13:55:03 +0100, wrote: > > Or should the command line option be simpler, but how should it be > > specified > > then? Maybe > > > > -net

[Qemu-devel] [PATCH 1/2 v4] slirp: Add domainname option to slirp's DHCP server

This patch will allow the user to include the domainname option in replies from the built-in DHCP server. Signed-off-by: Benjamin Drung <benjamin.dr...@profitbricks.com> --- net/slirp.c | 12 +--- qapi/net.json| 4 qemu-options.hx | 7 +-- slirp/bootp.c

[Qemu-devel] [PATCH 2/2] slirp: Add classless static routes support to DHCP server

This patch will allow the user to specify classless static routes for the replies from the built-in DHCP server. Signed-off-by: Benjamin Drung <benjamin.dr...@profitbricks.com> --- net/slirp.c | 65 +--- qapi/net.json| 4

Re: [Qemu-devel] [PATCH v2] slirp: Add domainname option to slirp's DHCP server

ame' parameter cannot be empty"); >exit(EXIT_FAILURE); > } I implemented that check in patch v3. In patch v4 I moved the check logic into net_slirp_init() in net/slirp.c where all the other checks live. -- Benjamin Drung System Developer Debian & Ubuntu Deve

[Qemu-devel] [PATCH v3] slirp: Add domainname option to slirp's DHCP server

This patch will allow the user to include the domainname option in replies from the built-in DHCP server. Signed-off-by: Benjamin Drung <benjamin.dr...@profitbricks.com> --- net/slirp.c | 7 --- qapi/net.json| 4 qemu-options.hx | 7 +-- slirp/bootp.c

Re: [Qemu-devel] [PATCH v2] slirp: Add domainname option to slirp's DHCP server

Hi Philippe, Am Freitag, den 16.02.2018, 16:23 -0300 schrieb Philippe Mathieu-Daudé: > Hi Benjamin, > > On 02/16/2018 02:55 PM, Benjamin Drung wrote: > > This patch will allow the user to include the domainname option in > > replies from the built-in DHCP server. > >

[Qemu-devel] [PATCH v2] slirp: Add domainname option to slirp's DHCP server

This patch will allow the user to include the domainname option in replies from the built-in DHCP server. Signed-off-by: Benjamin Drung <benjamin.dr...@profitbricks.com> --- net/slirp.c | 7 --- qapi/net.json| 4 qemu-options.hx | 7 +-- slirp/bootp.c

Re: [Qemu-devel] [PATCH 1/1] slirp: Add domainname option to slirp's DHCP server

Am Freitag, den 16.02.2018, 09:15 -0600 schrieb Eric Blake: > On 02/16/2018 06:55 AM, Benjamin Drung wrote: > > This patch will allow the user to include the domainname option in > > replies from the built-in DHCP server. > > > > Signed-off-by: Benjamin Drung <b

[Qemu-devel] [PATCH 1/1] slirp: Add domainname option to slirp's DHCP server

This patch will allow the user to include the domainname option in replies from the built-in DHCP server. Signed-off-by: Benjamin Drung <benjamin.dr...@profitbricks.com> --- net/slirp.c | 7 --- qapi/net.json| 3 +++ qemu-options.hx | 7 +-- slirp/bootp.c| 8

[Qemu-devel] [PATCH 0/1] slirp: Add domainname option to slirp's DHCP server

] https://tools.ietf.org/html/rfc3442 Benjamin Drung (1): slirp: Add domainname option to slirp's DHCP server net/slirp.c | 7 --- qapi/net.json| 3 +++ qemu-options.hx | 7 +-- slirp/bootp.c| 8 slirp/libslirp.h | 2 +- slirp/slirp.c| 4 +++- slirp/slirp.h

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Mon, 2018-02-12 at 13:20 +0100, Andrea Bolognani wrote: > On Mon, 2018-02-12 at 13:02 +1100, Alexey Kardashevskiy wrote: > > On 12/02/18 09:55, Benjamin Herrenschmidt wrote: > > > Well, we have a problem then. It looks like Qemu broken migration is > > > fundament

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Sun, 2018-02-11 at 19:08 +1100, David Gibson wrote: > On Thu, Jan 18, 2018 at 08:27:52AM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2018-01-17 at 15:39 +0100, Cédric Le Goater wrote: > > > Migration is a problem. We will need both backend QEMU objects to be > >

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Thu, 2018-01-18 at 14:27 +0100, Cédric Le Goater wrote: > The source and the target machines should have the same realized > objects. I think this is the simplest solution to keep the migration > framework maintainable. Yeah well, it all boils down to qemu migration being completely brain

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Wed, 2018-01-17 at 15:39 +0100, Cédric Le Goater wrote: > Migration is a problem. We will need both backend QEMU objects to be > available anyhow if we want to migrate. So we are back to the current > solution creating both QEMU objects but we can try to defer some of the > KVM inits and

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Wed, 2018-01-17 at 10:18 +0100, Cédric Le Goater wrote: > > > > Also, have we decided how the process of switching between XICS and > > > > XIVE will work vs. CAS ? > > > > > > That's how it is described in the architecture. The current choice is > > > to create both XICS and XIVE objects and

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Thu, 2017-12-21 at 10:16 +0100, Cédric Le Goater wrote: > On 12/21/2017 01:12 AM, Benjamin Herrenschmidt wrote: > > On Wed, 2017-12-20 at 16:09 +1100, David Gibson wrote: > > > > > > As you've suggested in yourself, I think we might need to more > > > expli

  1   2   3   4   5   6   7   8   9   10   >