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 the tag
> >>> bits
On 04/11/2016 06:58 AM, Thomas Hanson wrote:
Ah, true.
On 9 April 2016 at 09:57, Richard Henderson mailto:r...@twiddle.net>> 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 function names
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 wrote:
If you want to implement the AddressSize checks that's fine,
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
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 than
On 09/30/2016 05:24 PM, Peter Maydell wrote:
> On 30 September 2016 at 15:46, Tom Hanson 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
>>>> with current CPU models
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 val)
>> tcg_gen_movi_i64(
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 register numbers into TCGv earlier rather
>>> than later (at
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 fro
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 specified in the ARM ARM spec
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 sub
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-
devel-ml
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
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 d
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:
s
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-
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
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:
>
> * http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d2ffa08b601b
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 bus
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 di
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 of
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 is set at board crea
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 blocks and thus multiple devic
23 matches
Mail list logo
