Re: [Qemu-devel] [PATCH v3 0/4] target-arm: Handle tagged addresses when loading PC

On 10/12/2016 01:50 PM, Thomas Hanson wrote: ... > > Still looking into handling of tagged addresses for exceptions and > exception returns. Will handle that as a separate patch set. Peter, Looking at arm_cpu_do_interrupt_aarch64() and the ARM spec, the new PC value is always an offset

Re: [Qemu-devel] [PATCH 2/3] target-arm: Code changes to implement overwrite of tag field on PC load

On 10/11/2016 10:12 AM, Peter Maydell wrote: > On 11 October 2016 at 16:51, Thomas Hanson wrote: >> On 5 October 2016 at 16:01, Peter Maydell wrote: >>> It matches the style of the rest of the code which generally >>> prefers to convert

Re: [Qemu-devel] [PATCH 2/3] target-arm: Code changes to implement overwrite of tag field on PC load

On 09/29/2016 07:24 PM, Peter Maydell wrote: > On 16 September 2016 at 10:34, Thomas Hanson wrote: ... >> diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c >> index f5e29d2..4d6f951 100644 ... >> @@ -176,6 +177,58 @@ void gen_a64_set_pc_im(uint64_t

Re: [Qemu-devel] [PATCH 3/3] target-arm: Comments to mark location of pending work for 56 bit addresses

On 09/30/2016 05:24 PM, Peter Maydell wrote: > On 30 September 2016 at 15:46, Tom Hanson <thomas.han...@linaro.org> wrote: >> On 09/29/2016 07:27 PM, Peter Maydell wrote: >> ... >>>> This work was not done at this time since the changes could not be tested >&g

Re: [Qemu-devel] [PATCH 3/3] target-arm: Comments to mark location of pending work for 56 bit addresses

On 09/30/2016 05:24 PM, Peter Maydell wrote: 3 comments added in same file to identify cases in a switch. >>> >>> This should be a separate patch, because it is unrelated to the >>> tagged address stuff. >> >> As part of that same conversation you suggested adding these >> comments rather

Re: [Qemu-devel] [PATCH 3/3] target-arm: Comments to mark location of pending work for 56 bit addresses

On 09/29/2016 07:27 PM, Peter Maydell wrote: ... >> This work was not done at this time since the changes could not be tested >> with current CPU models. Comments have been added to flag the locations >> where this will need to be fixed once a model is available. > > This is *not* why we haven't

Re: [Qemu-devel] [PATCH 0/3] tareget-arm: Handle tagged addresses when loading PC

On 09/29/2016 07:37 PM, Peter Maydell wrote: On 16 September 2016 at 10:34, Thomas Hanson wrote: If tagged addresses are enabled, then addresses being loaded into the PC must be cleaned up by overwriting the tag bits with either all 0's or all 1's as

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

So, given the 1 register block per virt-mmio "bus" then I agree that we need a "dev path" distinction between them. On 5 July 2016 at 14:22, Thomas Hanson wrote: > OK, that makes sense. I was thinking that the MMIO transport would/could > support multiple register

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

OK, that makes sense. I was thinking that the MMIO transport would/could support multiple register blocks and thus multiple devices. On 5 July 2016 at 13:26, Laszlo Ersek (Red Hat) wrote: > A virtio-mmio "bus" is a single-device transport. It has a fixed base > address that

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

I tested Laszlo's patch against this scenario and it eliminated the error. However, I'm still not convinced that it's needed. Let's start with a basic question: Does it make sense for there to be more than one MMIO "bus" on a system? After all, it's NOT a physical bus and there's only one set

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

On 07/05/2016 10:29 AM, Peter Maydell wrote: ... > The virt board creates a collection of virtio-mmio transports, > so if you create just a backend on the command line (via > "-device virtio-scsi-device") it will be plugged into a > virtio-bus on a virtio-mmio transport. > > You almost certainly

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

I haven't dug into the code for this particular aspect (yet) but it sounds like when a scsi-hd device is specified with a virtio backend but with no virtio bus specified, it is defaulting to an MMIO bus. Is this correct? A few questions: 1) Is it valid for a SCSI drive to default to an MMIO

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

What would a device path look like for an MMIO backend? On Jul 5, 2016 9:35 AM, "Laszlo Ersek (Red Hat)" wrote: > I don't think this difference is intentional. I think we're seeing an > interplay between the following two commits: > > *

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

So, in the original minimal command line above (#3) is the transport/bus missing? Or is mmio implied? Or? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1594239 Title: After adding more scsi disks

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

As noted above, virtio-scsi-pci uses a bus address as part of the internal ID string while virtio-scsi-device does not. * Is this difference intentional? * Are they intended to support different use cases? If so, what? -- You received this bug notification because you are a member of qemu-

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

This looks like a command line / configuration issue which results in a name collision as Dave predicted above. I had to piece this together out of bits of information since documentation is a bit sparse but the following works. Note the explicit ID and LUN values on the -device declarations:

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

We may be saying the same thing, but I'd word it differently. If a "device" has a "path" then it gets a se->compat (compatibility?) record. - Within that record each device gets an instance_id value based on its name. Multiple IDs for the same name are allowed. - At the "se" level each

Re: [Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

Thanks! That makes sense. But, off the cuff, it seems odd that there's an instance_id if it can only be zero. But then again, it may be overloaded or be applicable in other cases. I'll dig into the code today. On 07/01/2016 02:27 AM, Dr. David Alan Gilbert wrote: > Hi Tom, >Yeh it's just

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

Dave, Yeah, well, never mind. :-) If I'd looked at the code first I'd have seen the function name and thought about which data I'd want to dump and where, I'd have figured out where the debug data came from. -Tom -- You received this bug notification because you are a member of qemu-

[Qemu-devel] [Bug 1594239] Re: After adding more scsi disks for Aarch64 virtual machine, start the VM and got Qemu Error

Dave, How did you get the debug info in #4 above? I can now replicate the error, but can't get to the monitor. I'm new to qemu so it's probably one of those things I haven't learned yet. Thanks, Tom -- You received this bug notification because you are a member of qemu- devel-ml, which is

Re: [Qemu-devel] [Qemu-arm] [PATCH] target-arm: Fix descriptor address masking in ARM address translation

On 03/21/2016 09:56 AM, Sergey Sorokin wrote: 17.03.2016, 18:24, "Peter Maydell" : On 17 March 2016 at 15:21, Sergey Sorokin wrote: 17.03.2016, 14:40, "Peter Maydell" : On 13 March 2016 at 18:28, Sergey Sorokin

Re: [Qemu-devel] best way to implement emulation of AArch64 tagged addresses

On 04/11/2016 06:58 AM, Thomas Hanson wrote: Ah, true. On 9 April 2016 at 09:57, Richard Henderson > wrote: On 04/08/2016 05:29 PM, Thomas Hanson wrote: Looking at tcg_out_tlb_load(): If I'm reading the pseudo-assembler of the

Re: [Qemu-devel] best way to implement emulation of AArch64 tagged addresses

On Mon, 2016-04-04 at 10:56 -0700, Richard Henderson wrote: > On 04/04/2016 09:31 AM, Peter Maydell wrote: > > On 4 April 2016 at 17:28, Richard Henderson wrote: > >> On 04/04/2016 08:51 AM, Peter Maydell wrote: > >>> In particular I think if you just do the relevant handling of