On Mon, 22 Mar 2021 at 16:36, John Garry wrote:
>
> >>
> >> There's apparently a bit in the PCI spec that reads:
> >> The host bus bridge, in PC compatible systems, must return all
> >> 1's on a read transaction and discard data on a write transaction
> >> when terminate
On Sun, 21 Mar 2021 at 19:00, Arnd Bergmann wrote:
>
> On Sat, Mar 20, 2021 at 9:43 PM Peter Maydell
> wrote:
> >
> > On Fri, 12 Mar 2021 at 09:16, Arnd Bergmann wrote:
> > > So it's probably qemu that triggers the 'synchronous external
> > >
On Fri, 12 Mar 2021 at 09:16, Arnd Bergmann wrote:
> So it's probably qemu that triggers the 'synchronous external
> abort' when accessing the PCI I/O space, which in turn hints
> towards a bug in qemu. Presumably it only returns data from
> I/O ports that are actually mapped to a device when real
On Mon, 1 Mar 2021 at 14:23, Steven Price wrote:
>
> A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
> granting a guest access to the tags, and provides a mechanism for the
> VMM to enable it.
>
> A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
> acces
On Fri, 5 Feb 2021 at 13:58, Steven Price wrote:
>
> The VMM may not wish to have it's own mapping of guest memory mapped
> with PROT_MTE because this causes problems if the VMM has tag checking
> enabled (the guest controls the tags in physical RAM and it's unlikely
> the tags are correct for the
On Wed, 9 Dec 2020 at 20:13, Richard Henderson
wrote:
>
> On 12/9/20 12:39 PM, Catalin Marinas wrote:
> >> I would have thought that the best way is to use TCO, so that we don't
> >> have to
> >> have dual mappings (and however many MB of extra page tables that might
> >> imply).
> >
> > The pro
On Mon, 7 Dec 2020 at 16:44, Dr. David Alan Gilbert wrote:
> * Steven Price (steven.pr...@arm.com) wrote:
> > Sorry, I know I simplified it rather by saying it's similar to protected VM.
> > Basically as I see it there are three types of memory access:
> >
> > 1) Debug case - has to go via a speci
On Mon, 7 Dec 2020 at 14:48, Steven Price wrote:
> Sounds like you are making good progress - thanks for the update. Have
> you thought about how the PROT_MTE mappings might work if QEMU itself
> were to use MTE? My worry is that we end up with MTE in a guest
> preventing QEMU from using MTE itsel
On Thu, 19 Nov 2020 at 15:57, Steven Price wrote:
> On 19/11/2020 15:45, Peter Maydell wrote:
> > I'm a bit dubious about requring the VMM to map the guest memory
> > PROT_MTE unless somebody's done at least a sketch of the design
> > for how this would work on the
On Thu, 19 Nov 2020 at 15:39, Steven Price wrote:
> This series adds support for Arm's Memory Tagging Extension (MTE) to
> KVM, allowing KVM guests to make use of it. This builds on the existing
> user space support already in v5.10-rc1, see [1] for an overview.
> The change to require the VMM to
On Mon, 26 Oct 2020 at 16:23, Mark Rutland wrote:
>
> Hi Arnd,
>
> On Mon, Oct 26, 2020 at 05:03:31PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > There are many warnings in this file when we re-enable the
> > Woverride-init flag:
> >
> > arch/arm64/kernel/traps.c:704:26: warning:
On Wed, 9 Sep 2020 at 16:48, Andrew Jones wrote:
> We either need a KVM cap or a new CPU feature probing interface to avoid
> making userspace try features one at a time. It's too bad that VCPU_INIT
> doesn't clear all offending features from the feature set when returning
> EINVAL, because then u
On Mon, 20 Jul 2020 at 15:55, Guenter Roeck wrote:
> Ah, sorry, you can't use the upstream version of qemu to test mps2-an385
> Linux images. You'll have to use a version from
> https://github.com/groeck/qemu.
> I'd recommend to use the v5.0.0-local branch.
>
> I had to make some changes to qemu
On Wed, 24 Jun 2020 at 12:18, Steven Price wrote:
> Ah yes, similar to (1) but much lower overhead ;) That's probably the
> best option - it can be hidden in a memcpy_ignoring_tags() function.
> However it still means that the VMM can't directly touch the guest's
> memory which might cause issues
On Wed, 17 Jun 2020 at 13:39, Steven Price wrote:
>
> These patches add support to KVM to enable MTE within a guest. It is
> based on Catalin's v4 MTE user space series[1].
>
> [1] http://lkml.kernel.org/r/20200515171612.1020-1-catalin.marinas%40arm.com
>
> Posting as an RFC as I'd like feedback o
On Fri, 6 Sep 2019 at 14:13, Christoffer Dall wrote:
> I'd prefer leaving it to userspace to worry about, but I thought Peter
> said that had been problematic historically, which I took at face value,
> but I could have misunderstood.
>
> If QEMU, kvmtool, and whatever the crazy^H cool kids are us
On Mon, 27 May 2019 at 16:56, Guenter Roeck wrote:
> I'd be happy to use a different (supported) branch, but the Linaro branch
> was the only one I could find that supports those boards. Unfortunately,
> qemu changed so much since 2.3 that it is all but impossible to merge
> the code into mainline
On Thu, 23 May 2019 at 19:36, Aaro Koskinen wrote:
> Cheetah works with serial console. I tried with console on display,
> and it seems to boot up, and the frame buffer window gets correctly
> sized but for some reason it just stays blank.
As a general question, when you're doing these tests are
On Mon, 15 Apr 2019 at 14:11, Mathieu Desnoyers
wrote:
>
> - On Apr 11, 2019, at 3:55 PM, peter maydell peter.mayd...@linaro.org
> wrote:
>
> > On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers
> > wrote:
> >> * This translates to the followi
On Thu, 11 Apr 2019 at 18:51, Mathieu Desnoyers
wrote:
> - On Apr 11, 2019, at 12:42 PM, Will Deacon will.dea...@arm.com wrote:
> > Peter suggests that anything of the form 0xe7fxdefx should trap in both A32
> > and T32, although it does assemble to UDF; B in T16. I'm not sure we
> > should g
On Thu, 10 Jan 2019 at 12:09, gengdongjiu wrote:
> Peter, I summarize James's main idea, James think QEMU does not needs
> to check *something* if Qemu support firmware-first.
> What do we do for your comments?
Unless I'm missing something, the code in your most recent patchset
attempts to update
On Sat, 29 Dec 2018 at 16:49, Andy Lutomirski wrote:
> > Could you use a prctl to set whether you were running in 32 or 64 bit
> > mode? Or do you change which kind of task you're emulating too often
> > to make this a good idea?
QEMU's linux-user mode always only runs the single process,
which
On Fri, 28 Dec 2018 at 23:16, Andreas Dilger wrot
> On Dec 28, 2018, at 4:18 AM, Peter Maydell wrote:
> > The problem is that there is no 32-bit API in some cases
> > (unless I have misunderstood the kernel code) -- not all
> > host architectures implement compat syscalls or
On Fri, 28 Dec 2018 at 00:23, Andreas Dilger wrote:
> On Dec 27, 2018, at 10:41 AM, Peter Maydell wrote:
> > As you note, this causes breakage for userspace programs which
> > need to implement an API/ABI with 32-bit offset but which only
> > have access to the kernel&#x
On Thu, 27 Dec 2018 at 17:19, Florian Weimer wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> outpu
On Mon, 17 Dec 2018 at 15:56, James Morse wrote:
> I think the root issue here is the name of the cpufeature 'RAS Extensions',
> this
> doesn't mean RAS is new, or even requires these features. It's just
> standardised
> records, classification and a barrier.
> Not only is it possible to build a
On Mon, 10 Dec 2018 at 20:22, Richard Henderson
wrote:
>
> On 12/10/18 2:12 PM, Kristina Martsenko wrote:
> > The plan was to disable trapping, yes. However, after that thread there
> > was a retrospective change applied to the architecture, such that the
> > XPACLRI (and XPACD/XPACI) instructions
On Fri, 14 Dec 2018 at 13:56, James Morse wrote:
>
> Hi Dongjiu Geng,
>
> On 14/12/2018 10:15, Dongjiu Geng wrote:
> > When user space do memory recovery, it will check whether KVM and
> > guest support the error recovery, only when both of them support,
> > user space will do the error recovery.
On 30 April 2018 at 10:07, Eric Auger wrote:
> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
> KVM_DEV_ARM_VGIC_GRP_ADDR group.
Hi; one minor grammar nit in the docs below, otherwise
Reviewed-by: Peter Maydell
> It allows userspace to provide the
> base addr
On 24 April 2018 at 17:46, Christoffer Dall wrote:
> On Fri, Apr 13, 2018 at 10:20:48AM +0200, Eric Auger wrote:
>> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> +++ b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> @@ -27,9 +27,32 @@ Groups:
>>VCPU and all of the redistr
On 27 March 2018 at 14:15, Suzuki K Poulose wrote:
> Expose the maximum physical address size supported by the host
> for a VM. This could be later used by the userspace to choose the
> appropriate size for a given VM. The limit is determined as the
> minimum of actual CPU limit, the kernel limit
EDIST, this new attribute allows
> to declare several separate redistributor regions.
>
> So the whole redist space does not need to be contiguous anymore.
>
> Signed-off-by: Eric Auger
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
On 27 March 2018 at 15:04, Eric Auger wrote:
> Now all the internals are ready to handle multiple redistributor
> regions, let's allow the userspace to register them.
>
> Signed-off-by: Eric Auger
> ---
> virt/kvm/arm/vgic/vgic-kvm-device.c | 40
> +++--
> virt/k
On 19 March 2018 at 09:20, Eric Auger wrote:
> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
> KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
> base address and size of a redistributor region
>
> Compared to KVM_VGIC_V3_ADDR_TYPE_REDIST, this new attribut
On 15 March 2018 at 19:00, Marc Zyngier wrote:
> On 06/03/18 09:21, Andrew Jones wrote:
>> On Mon, Mar 05, 2018 at 04:47:55PM +0000, Peter Maydell wrote:
>>> On 2 March 2018 at 11:11, Marc Zyngier wrote:
>>>> On Fri, 02 Mar 2018 10:44:48 +,
>>>> Au
On 6 March 2018 at 09:50, Marc Zyngier wrote:
> On 05/03/18 20:37, Auger Eric wrote:
>> On 05/03/18 17:31, Peter Maydell wrote:
>>> That also means that we will fail migration from a new kernel where
>>> we've specifically asked for PSCI 0.2 to an old PSCI-
On 2 March 2018 at 11:11, Marc Zyngier wrote:
> On Fri, 02 Mar 2018 10:44:48 +,
> Auger Eric wrote:
>> I understand the get/set is called as part of the migration process.
>> So my understanding is the benefit of this series is migration fails in
>> those cases:
>>
>> >=0.2 source -> 0.1 desti
On 2 March 2018 at 12:26, Auger Eric wrote:
> Hi Marc,
> On 02/03/18 12:11, Marc Zyngier wrote:
>> On Fri, 02 Mar 2018 10:44:48 +,
>> Auger Eric wrote:
>>> I understand the get/set is called as part of the migration process.
>>> So my understanding is the benefit of this series is migration fa
On 10 January 2018 at 11:25, Jean-Philippe Brucker
wrote:
> Hi Peter,
>
> On 10/01/18 11:19, Peter Maydell wrote:
>> Are there uses that make it worthwhile to get virtio-1
>> support added to virtio-mmio, rather than just getting
>> people to move over to virtio-pci
On 10 January 2018 at 11:06, Michael S. Tsirkin wrote:
> For virtio-mmio? I don't seem to see that code in
> hw/virtio/virtio-mmio.c
> For example I still see handling for VIRTIO_MMIO_QUEUE_PFN
> there, and no handling for VIRTIO_MMIO_QUEUE_DESC_LOW
> and such.
Are there uses that make it worthwh
On 16 October 2017 at 10:26, Christoffer Dall wrote:
> Hi Eric,
>
> On Mon, Sep 25, 2017 at 03:34:36PM +0200, Eric Auger wrote:
>> When the GITS_BASER.Valid gets cleared, the data structures in
>> guest RAM are not provisionned anymore. The device, collection
>> and LPI lists stored in the in-kern
On 27 September 2017 at 14:28, Eric Auger wrote:
> At the moment, the in-kernel emulated ITS is not properly reset.
> On guest restart/reset some registers keep their old values and
> internal structures like device, ITE, collection lists are not freed.
>
> This may lead to various bugs. Among the
On 13 September 2017 at 08:52, gengdongjiu wrote:
>
>
> On 2017/9/12 0:39, Peter Maydell wrote:
>>>>> +return kvm_vcpu_ioctl(CPU(cpu), KVM_ARM_SEI, &syndrome);
>>>> This looks odd. If we don't have the RAS extension why do we need to do
>>
On 11 September 2017 at 16:17, gengdongjiu wrote:
>> On 18 August 2017 at 15:23, Dongjiu Geng wrote:
>> > +static int kvm_inject_arm_sei(CPUState *cs) {
>> > +ARMCPU *cpu = ARM_CPU(cs);
>> > +CPUARMState *env = &cpu->env;
>> > +
>> > +unsigned long syndrome = env->exception.vaddress;
On 8 September 2017 at 17:17, gengdongjiu wrote:
>>
>> This code has all just been copied-and-pasted from target/i386/kvm.c.
>> Please instead abstract it out properly into a cpu-independent source file.
>
>
> Yes, it copied from x86.
> Do you mean abstracting this code to a common folder so that
On 8 September 2017 at 15:26, gengdongjiu wrote:
>> Shouldn't we need to also tell the kernel that we actually want
>> it to expose RAS to the guest? Compare the PMU code in this function,
>> where we set a kvm_init_features bit to do this.
> In the PMU code, it indeed sets a kvm_init_features
On 28 August 2017 at 11:38, Dongjiu Geng wrote:
> In the firmware-first RAS solution, corrupt data is detected in a
> memory location when guest OS application software executing at EL0
> or guest OS kernel El1 software are reading from the memory. The
> memory node records errors in an error reco
On 18 August 2017 at 15:23, Dongjiu Geng wrote:
> When guest OS happens SError interrupt(SEI), it will trap to host.
> Host firstly calls memory failure to deal with this error and decide
> whether it needs to deliver SIGBUS signal to userspace. The advantage
> that using signal to notify is that
On 18 August 2017 at 15:23, Dongjiu Geng wrote:
> Add SIGBUS signal handler. In this handler, it checks
> the exception type, translates the host VA which is
> delivered by host or KVM to guest PA, then fills this
> PA to CPER, finally injects a Error to guest OS through
> KVM.
>
> Add synchronous
On 18 August 2017 at 15:23, Dongjiu Geng wrote:
> check if kvm supports guest RAS EXTENSION. if so, set
> corresponding feature bit for vcpu.
>
> Signed-off-by: Dongjiu Geng
> ---
> linux-headers/linux/kvm.h | 1 +
> target/arm/cpu.h | 3 +++
> target/arm/kvm64.c| 8
>
On 19 April 2017 at 11:33, Catalin Marinas wrote:
> On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
>>
>> > That's affecting most architectures with a risk of ABI breakage. We
>> > could do it on arm64 only, though I'm not yet clear on the A
On 18 April 2017 at 18:01, Catalin Marinas wrote:
> On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
>> From: Dong Bo
>>
>> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
>> the flag is propagated to its child processes, even the elf
>> files are marked as not requiring
On 28 March 2017 at 12:23, Christoffer Dall wrote:
> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote:
>> On the host, part of UEFI is involved to generate the CPER records.
>> In a guest?, I don't know.
>> Qemu could generate the records, or drive some other component to do it.
>
> I t
On 21 March 2017 at 19:39, Christoffer Dall wrote:
> My confusion here comes from not thinking about QEMU or KVM as firmware,
> but as the machine, so it would be sort of like the functionality is
> baked into hardware rather than firmware.
There is precedent for that kind of thing -- we implemen
On 30 January 2017 at 17:08, Jintack Lim wrote:
> On Sun, Jan 29, 2017 at 10:44 AM, Marc Zyngier wrote:
>> Shouldn't we take the ENABLE bit into account? The ARMv8 ARM version I
>> have at hand (version h) seems to indicate that we should, but we should
>> check with the latest and greatest...
>
configure this properly, or
> interrupts will simply not be delivered on this HW.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Peter Maydell
> Signed-off-by: Marc Zyngier
> ---
> It is getting a bit late for 4.6, so I plan to put this on top of
> the 4.7 stuff, and let it
On 15 February 2016 at 17:05, Guenter Roeck wrote:
> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
> timers with utilization update callbacks' with next-20160215. An example
> crash log and bisect results are attached below.
>
> Please let me know if there is anything
On 7 January 2016 at 17:10, Guenter Roeck wrote:
> Strictly speaking you may be right (regression is a bit strong, though),
> but for my part I tend to be pragmatic.
>
> A warning message such as "Access to unimplemented register X" may be
> useful
You can get these from QEMU if you pass it "-d u
On 24 December 2015 at 00:52, Guenter Roeck wrote:
> Hi all,
>
> since commit 60792ad349f3 ("arm64: kernel: enforce pmuserenr_el0
> initialization
> and restore"), my arm64 qemu tests of linux-next are failing. After this
> commit,
> qemu does not display any output.
>
> Qemu version is 2.5.0. Lin
On 24 December 2015 at 19:51, Guenter Roeck wrote:
> I can not get the available dtb files for realview (arm-realview-pb1176.dtb
> and arm-realview-pb11mp.dtb) to work with anything I tried.
This is because QEMU does not model either of these two boards.
thanks
-- PMM
--
To unsubscribe from this
tself, and pass the DT
on to a kernel running in the non-secure world, which ignores the
secure-only devices and uses the rest).
Signed-off-by: Peter Maydell
---
This binding doesn't affect the kernel itself, but the kernel
Documentation/ tree is the de-facto current place where all
On 21 November 2015 at 23:21, Arnd Bergmann wrote:
> Regarding PJ4, it's still unclear whether that has the same
> problem and it only reports idivt when it actually supports idiva,
> or whether the lack of idiva support on PJ4 is instead the reason
> why the ARM ARM was updated to have separate f
On 12 November 2015 at 21:33, Rob Herring wrote:
> On Thu, Nov 12, 2015 at 04:24:50PM +0000, Peter Maydell wrote:
>> The existing device tree bindings assume that we are only trying to
>> describe a single address space with a device tree (for ARM, either
>> the Normal or th
tself, and pass the DT
on to a kernel running in the non-secure world, which ignores the
secure-only devices and uses the rest).
Signed-off-by: Peter Maydell
---
This binding doesn't affect the kernel itself, but the kernel
Documentation/ tree is the de-facto current place where all
On 10 November 2015 at 14:51, Rob Herring wrote:
> On Fri, Oct 30, 2015 at 08:07:34PM +0000, Peter Maydell wrote:
>> +status = "okay"; secure-status = "okay"; // ditto
>> +secure-status = "okay"; // ditto
>> +// neith
On 30 October 2015 at 18:28, Rob Herring wrote:
> On Thu, Oct 29, 2015 at 9:01 AM, Peter Maydell
> wrote:
>> +Valid Secure world properties:
>> +
>> +- secure-status : specifies whether the device is present and usable
>> + in the secure world. The combinatio
tself, and pass the DT
on to a kernel running in the non-secure world, which ignores the
secure-only devices and uses the rest).
Signed-off-by: Peter Maydell
---
This binding doesn't affect the kernel itself, but the kernel
Documentation/ tree is the de-facto current place where all
On 5 October 2015 at 13:40, Gabriel L. Somlo wrote:
> In addition, Michael's comment earlier in the thread suggests that
> even my current acpi version isn't sufficiently "orthodox" w.r.t.
> ACPI, and I should be providing the hardware access routine as
> an ACPI/AML routine, to avoid race conditi
On 29 July 2015 at 20:16, Michael S. Tsirkin wrote:
> ACPI spec 5.0 allows the use of PCI vendor IDs.
>
> Since we have one for virtio, it seems neater to use that
> rather than LNRO. For the device ID, use 103F which is a legacy ID that
> isn't used in virtio PCI spec - seems to make sense since
On 30 July 2015 at 09:04, Michael S. Tsirkin wrote:
> On Thu, Jul 30, 2015 at 09:23:20AM +0800, Shannon Zhao wrote:
>>
>> Why do we drop the previous way using "QEMU"? Something I missed?
>
> So that guests that bind to this interface will work fine with non QEMU
> implementations of virtio-mm
On 28 July 2015 at 11:33, G Gregory wrote:
> We assigned LNRO in ASWG to avoid collisions with our prototypes/real
> platforms so it makes sense to me to switch to QEMU.
So just to check, if we switch virtio-mmio from an LNRO0005 ID
to a QEMU ID we aren't going to break any existing widel
On 28 July 2015 at 21:28, G Gregory wrote:
> On 28 July 2015 at 21:12, Peter Maydell wrote:
>> Mmm. I'm not terribly happy about stuff being in QEMU before the
>> ACPI spec for it has been finalised. We should not be picking
>> stuff randomly on the fly...
>>
&
On 28 July 2015 at 11:27, Michael S. Tsirkin wrote:
> On Tue, Jul 28, 2015 at 11:12:33AM +0100, Peter Maydell wrote:
>> On 28 July 2015 at 11:08, Michael S. Tsirkin wrote:
>> > On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
>> >> Added the mat
On 28 July 2015 at 11:08, Michael S. Tsirkin wrote:
> On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
>> Added the match table and pointers for ACPI probing to the driver.
>>
>> This uses the same identifier for virt devices as being used for qemu
>> ARM64 ACPI support.
>>
>> http:
On 29 June 2015 at 18:11, Marc Zyngier wrote:
> On 29/06/15 18:06, Chalamarla, Tirumalesh wrote:
>>
>>> On Jun 29, 2015, at 1:53 AM, Marc Zyngier wrote:
>>> Constantly adding new CPUs without providing any insight as to how they
>>> should be emulated only brings churn, and not much benefit.
>>>
On 15 May 2015 at 17:16, Alex Bennée wrote:
> Mark Rutland writes:
>> This gets more fun when you consider the context-aware breakpoints are
>> the highest numbered. So the set of (context-aware) breakpoints might
>> not intersect across all CPUs.
>
> I didn't see a reference to that in the ARM A
On 15 May 2015 at 16:14, Alex Bennée wrote:
>
> Mark Rutland writes:
>
>> On Fri, May 15, 2015 at 03:27:06PM +0100, Alex Bennée wrote:
>>> +/*
>>> + * See v8 ARM ARM D7.3: Debug Registers
>>> + *
>>> + * The control registers are architecturally defined as 32 bits but are
>>> + * stored as 64 bit
On 28 April 2015 at 09:42, Alex Bennée wrote:
> Peter Maydell writes:
>> Does the kernel already have a conveniently implemented "inject
>> exception into guest" lump of code? If so it might be less effort
>> to do it that way round, maybe.
>
> So you po
On 27 April 2015 at 21:04, Christoffer Dall wrote:
> On Thu, Apr 23, 2015 at 03:26:53PM +0100, Alex Bennée wrote:
>>
>> Christoffer Dall writes:
>>
>> > On Tue, Mar 31, 2015 at 04:08:04PM +0100, Alex Bennée wrote:
>> >> + * just need to report the PC and the HSR values to userspace.
>> >> + * Use
On 1 April 2015 at 17:01, Alex Bennée wrote:
>
> David Hildenbrand writes:
>>> +/*
>>> + * See ARM ARM D7.3: Debug Registers
>>
>> Maybe drop one ARM
>
> Well technically it is the ARM Architecture Reference Manual but that's
> quite long winded.
Dropping one "ARM" would be actively wrong, so d
On 10 March 2015 at 04:29, Christoffer Dall wrote:
> On Mon, Mar 09, 2015 at 04:34:21PM +, Alex Bennée wrote:
>> - Boot
>> - Power on secondary CPUs
>> - Power off one secondary CPU
>> - Migrate to file (cpu_powered reflects state of each CPU)
>>
>> - Start fresh QEMU
>> - Restore from file (c
On 20 December 2014 at 20:07, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 15:01:29 Marc Zyngier wrote:
>> Also it is worth noticing that given how GICV is placed, it will never
>> work with 64K pages and virtualization. Pretty sad.
>
> Does this mean no VGIC support on this platform so yo
On 5 December 2014 at 10:10, Jon Medhurst (Tixy) wrote:
> I don't know much about QEMU and have never used it, but I'm assuming
> QEMU doesn't make any attempt to simulate caches like the data cache,
> instruction cache, TLBs, branch predictor? Does it even emulate multiple
> CPUs with multiple ho
On 5 December 2014 at 18:44, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 05:27:02PM +, Russell King - ARM Linux wrote:
>> which makes the summary line rather misleading, and I really don't think
>> we need to do this on ARM for the simple reason that we've been doing it
>> for soo long th
On 5 December 2014 at 17:27, Russell King - ARM Linux
wrote:
> On Fri, Dec 05, 2014 at 05:07:45PM +, Catalin Marinas wrote:
>> On Fri, Dec 05, 2014 at 12:05:06PM +, Will Deacon wrote:
>> > Care to submit this as a proper patch? We should at least fix Peter's issue
>> > before doing things
On 4 December 2014 at 12:01, Eric Auger wrote:
> Here is the sequence:
> 1) The VGIC early initialization is initiated in a machine init done
> notifier. This notifier is registered in kvm_arm_gic_realize
> (http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00220.html). It
> executes after v
On 2 December 2014 at 17:54, Eric Auger wrote:
> as soon as VFIO signaling is set up (the device IRQ index is linked to
> an eventfd, the physical IRQ VFIO handler is installed and the physical
> IRQ is enabled at interrupt controller level), virtual IRQs are likely
> to be injected. With current
On 2 December 2014 at 17:27, Eric Auger wrote:
> Since the advent of dynamic initialization of VGIC, this latter is
> initialized very late, on the first vcpu run. This initialization
> could be initiated much earlier by the user, as soon as it has
> provided the requested dimensioning parameters:
On 30 November 2014 at 10:10, Christoffer Dall
wrote:
> In any case, I think it was related to how userspace observes the state
> of the CPU, because when you do the MMIO operation emulation in
> userspace, currently if you observe the PC though GET_ONE_REG, you'll
> see a PC pointing to the next
On 25 November 2014 at 16:10, Alex Bennée wrote:
> This adds support for single-stepping the guest. As userspace can and
> will manipulate guest registers before restarting any tweaking of the
> registers has to occur just before control is passed back to the guest.
> Furthermore while guest debug
On 26 November 2014 at 16:07, Andrew Jones wrote:
> There appears to be a typo in the ARM ARM. Subsection "Software
> Breakpoint Instruction exception" of D1.10.4 says BRK (ESR_EL2_EC_BRK64)
> is 0x39, but the table above that has it correctly as 0x3c.
Thanks for pointing out this typo -- I've re
On 25 November 2014 at 17:05, Paolo Bonzini wrote:
> So there is no register that says "this breakpoint has triggered" or
> "this watchpoint has triggered"?
Nope. You take a debug exception; the syndrome register tells
you if it was a bp or a wp, and if it was a wp the fault address
register tell
On 25 November 2014 at 16:10, Alex Bennée wrote:
> +/* Exit types which define why we did a debug exit */
> +#define KVM_DEBUG_EXIT_ERROR 0x0
> +#define KVM_DEBUG_EXIT_SINGLE_STEP 0x1
> +#define KVM_DEBUG_EXIT_SW_BKPT 0x2
> +#define KVM_DEBUG_EXIT_HW_BKPT 0x3
> +#defi
On 21 November 2014 20:14, Andrea Arcangeli wrote:
> Hi Peter,
>
> On Wed, Oct 29, 2014 at 05:56:59PM +0000, Peter Maydell wrote:
>> On 29 October 2014 17:46, Andrea Arcangeli wrote:
>> > After some chat during the KVMForum I've been already thinking it
>> >
On 13 November 2014 11:26, Will Deacon wrote:
> Whilst I don't think this is the correct solution, I agree that there's
> a potential issue here. We could change the restart return value to
> -ERESTARTNOINTR instead, but I can imagine something like a periodic
> SIGALRM which could prevent a large
On 29 October 2014 17:46, Andrea Arcangeli wrote:
> After some chat during the KVMForum I've been already thinking it
> could be beneficial for some usage to give userland the information
> about the fault being read or write
...I wonder if that would let us replace the current nasty
mess we use
On 27 October 2014 11:23, Li Liu wrote:
> So you mean virtio-mmio will be replaced by PCI/PCIe on ARM at last?
That is the plan, yes. I can't make any promises on
timescales at the moment, though...
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 25 October 2014 09:24, john.liuli wrote:
> To get the interrupt reason to support such VIRTIO_NET_F_STATUS
> features I add a new register offset VIRTIO_MMIO_ISRMEM which
> will help to establish a shared memory region between qemu and
> virtio-mmio device. Then the interrupt reason can be acce
On 17 September 2014 06:25, Christopher Covington wrote:
> On 09/16/2014 05:24 PM, Christopher Covington wrote:
>> On 09/16/2014 05:09 PM, Christopher Covington wrote:
>>> ARM Linux currently has the most features available to it in hypervisor
>>> (HYP) mode, so switch to it when possible. This ca
On 4 September 2014 02:13, long.wanglong wrote:
> When i revert the commit bc41b8724f24, the secondary core can boot.
> The problem is that qemu doesn't provide emulation of the SCU base
> address register. When reading the SCU base, qemu just return 0.
You need to upgrade your QEMU -- we improve
1 - 100 of 136 matches
Mail list logo
