On 2020/5/12 3:41, Igor Mammedov wrote:
> for future, adding RESEND doesn't make sence here. If you change patches then
> just bump version.
Igor,
Thanks for the reminder, Just now I submitted a new patchset version to
avoid this confusion.
>> + (node3), (node4), (node5) }
>> +
>> #define UUID_FMT "%02hhx%02hhx%02hhx%02hhx-" \
>> "%02hhx%02hhx-%02hhx%02hhx-" \
>> "%02hhx%02hhx-" \
>> diff --git a/slirp b/slirp
>> index 2faae0f..55ab21c 16
>> --- a/slirp
>> +++ b/slirp
>> @@ -1 +1 @@
>> -S
On 2020/5/11 20:29, Philippe Mathieu-Daudé wrote:
>> @@ -1 +1 @@
>> -Subproject commit 2faae0f778f818fadc873308f983289df697eb93
>> +Subproject commit 55ab21c9a36852915b81f1b41ebaf3b6509dd8ba
>
> The SLiRP submodule change is certainly unrelated.
Thanks Philippe's review and comments. I submitted
On 2020/5/7 4:25, Michael S. Tsirkin wrote:
> On Wed, May 06, 2020 at 07:42:19PM +0800, gengdongjiu wrote:
>> On 2020/4/17 21:32, Peter Maydell wrote:
>>> On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
>>>>
>>>> In the ARMv8 platform, the CPU
On 2020/5/7 4:25, Michael S. Tsirkin wrote:
> On Wed, May 06, 2020 at 07:42:19PM +0800, gengdongjiu wrote:
>> On 2020/4/17 21:32, Peter Maydell wrote:
>>> On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
>>>>
>>>> In the ARMv8 platform, the CPU
On 2020/4/17 21:32, Peter Maydell wrote:
> On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
>>
>> In the ARMv8 platform, the CPU error types includes synchronous external
>> abort(SEA)
>> and SError Interrupt (SEI). If exception happens in guest, host does not
>> know the detailed
>> informatio
On 2020/5/5 18:44, Igor Mammedov wrote:
>> Signed-off-by: Dongjiu Geng
>> Signed-off-by: Xiang Zheng
> Reviewed-by: Igor Mammedov
>
> Also we should ratelimit error messages that could be triggered at runtime
> from acpi_ghes_record_errors() and functions it's calling.
> It could be a patch
>
> On Thu, 30 Apr 2020 11:56:24 +0800
> gengdongjiu wrote:
>
> > On 2020/4/17 21:32, Peter Maydell wrote:
> > > On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
> > >>
> > >> In the ARMv8 platform, the CPU error types includes synchronous
&
On 2020/4/17 21:32, Peter Maydell wrote:
> On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
>>
>> In the ARMv8 platform, the CPU error types includes synchronous external
>> abort(SEA)
>> and SError Interrupt (SEI). If exception happens in guest, host does not
>> know the detailed
>> informa
On 2020/4/17 21:32, Peter Maydell wrote:
> On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
>>
>> In the ARMv8 platform, the CPU error types includes synchronous external
>> abort(SEA)
>> and SError Interrupt (SEI). If exception happens in guest, host does not
>> know the detailed
>> informa
On 2020/4/17 21:32, Peter Maydell wrote:
> On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
>>
>> In the ARMv8 platform, the CPU error types includes synchronous external
>> abort(SEA)
>> and SError Interrupt (SEI). If exception happens in guest, host does not
>> know the detailed
>> informa
ok，thanks very much for peter's time and reply
发件人：Peter Maydell
收件人：gengdongjiu
抄 送：imammedo ;mst ;xiaoguangrong.eric
;shannon.zhaosl ;fam
;rth ;Eduardo Habkost
;mtosatti ;qemu-devel
;kvm ;qemu-arm
;pbonzini ;zhengxiang (A)
;Linuxarm ;Jonathan Cameron
时 间：2020-04-16 22:02:34
主
ping
发件人：gengdongjiu
收件人：imammedo ;mst ;xiaoguangrong.eric
;Peter Maydell
;shannon.zhaosl ;fam
;rth ;Eduardo Habkost
;mtosatti ;qemu-devel
;kvm ;qemu-arm
;pbonzini
抄 送：gengdongjiu ;zhengxiang (A)
;Jonathan Cameron
;Linuxarm
时 间：2020-04-10 19:45:28
主 题：[PATCH v25 00/10] Add ARMv8
On 2020/2/26 0:59, Igor Mammedov wrote:
> On Mon, 24 Feb 2020 16:37:44 +0800
> gengdongjiu wrote:
>
>> On 2020/2/21 22:09, Peter Maydell wrote:
>>> On Mon, 17 Feb 2020 at 13:10, Dongjiu Geng wrote:
>>>>
>>>> In the ARMv8 platform, t
>
> On Tue, 25 Feb 2020 08:54:07 +
> Peter Maydell wrote:
>
> > On Tue, 25 Feb 2020 at 08:34, Igor Mammedov wrote:
> > >
> > > On Mon, 17 Feb 2020 21:12:40 +0800
> > > Dongjiu Geng wrote:
> > >
> > > > RAS Virtualization feature is not supported now, so add a RAS
> > > > machine
> > >
> >
On 2020/2/21 22:09, Peter Maydell wrote:
> On Mon, 17 Feb 2020 at 13:10, Dongjiu Geng wrote:
>>
>> In the ARMv8 platform, the CPU error types includes synchronous external
>> abort(SEA) and SError Interrupt (SEI). If exception happens in guest, host
>> does not know the detailed information of g
On 2020/1/17 0:44, Peter Maydell wrote:
> On Wed, 8 Jan 2020 at 11:33, Dongjiu Geng wrote:
>>
>> Record the GHEB address via fw_cfg file, when recording
>> a error to CPER, it will use this address to find out
>> Generic Error Data Entries and write the error.
>>
>> Make the HEST GHES to a GED dev
On 2020/2/6 0:43, Jonathan Cameron wrote:
> On Wed, 8 Jan 2020 19:32:18 +0800
> Dongjiu Geng wrote:
>
>> This patch builds Hardware Error Source Table(HEST) via fw_cfg blobs.
>> Now it only supports ARMv8 SEA, a type of Generic Hardware Error
>> Source version 2(GHESv2) error source. Afterward
On 2020/1/23 23:48, Igor Mammedov wrote:
> On Wed, 8 Jan 2020 19:32:18 +0800
> Dongjiu Geng wrote:
>
>> This patch builds Hardware Error Source Table(HEST) via fw_cfg blobs.
>> Now it only supports ARMv8 SEA, a type of Generic Hardware Error
>> Source version 2(GHESv2) error source. Afterwards
On 2020/1/23 23:14, Igor Mammedov wrote:
> On Wed, 8 Jan 2020 19:32:17 +0800
> Dongjiu Geng wrote:
>
>> This patch builds error_block_address and read_ack_register fields
>> in hardware errors table , the error_block_address points to Generic
>> Error Status Block(GESB) via bios_linker. The max s
On 2020/1/28 23:29, Igor Mammedov wrote:
> On Wed, 8 Jan 2020 19:32:21 +0800
> Dongjiu Geng wrote:
>
>> kvm_arch_on_sigbus_vcpu() error injection uses source_id as
>> index in etc/hardware_errors to find out Error Status Data
>> Block entry corresponding to error source. So supported source_id
>>
sorry for the late response due to Chinese new year
On 2020/1/28 22:41, Igor Mammedov wrote:
> On Wed, 8 Jan 2020 19:32:19 +0800
> Dongjiu Geng wrote:
>
> in addition to comments of others:
>
>> Record the GHEB address via fw_cfg file, when recording
>> a error to CPER, it will use this address
On 2020/1/20 20:15, Peter Maydell wrote:
> On Fri, 17 Jan 2020 at 10:05, gengdongjiu wrote:
>>
>> On 2020/1/17 0:28, Peter Maydell wrote:
>>> On Wed, 8 Jan 2020 at 11:33, Dongjiu Geng wrote:
>>>
>>>> +void kvm_arch_on_sigbus_vcpu(CPUState *c, int c
On 2020/1/17 19:22, Philippe Mathieu-Daudé wrote:
> On 1/17/20 12:09 PM, Peter Maydell wrote:
>> On Fri, 17 Jan 2020 at 07:22, Philippe Mathieu-Daudé
>> wrote:
>>>
>>> Hi Peter,
>>>
>>> On 1/16/20 5:46 PM, Peter Maydell wrote:
On Wed, 8 Jan 2020 at 11:32, Dongjiu Geng wrote:
>
> I a
On 2020/1/17 15:39, Philippe Mathieu-Daudé wrote:
>> table_offsets = g_array_new(false, true /* clear */,
>> sizeof(uint32_t));
>> @@ -831,7 +832,9 @@ void virt_acpi_build(VirtMachineState *vms,
>> AcpiBuildTables *tables)
>> acpi_add_tabl
On 2020/1/17 0:44, Peter Maydell wrote:
>> .minimum_version_id = 1,
>> .fields = (VMStateField[]) {
>> -VMSTATE_STRUCT(ged_state, AcpiGedState, 1, vmstate_ged_state,
>> GEDState),
>> +VMSTATE_STRUCT(ged_state, AcpiGedState, 1,
>> + vmstate_ged_state,
On 2020/1/17 15:22, Philippe Mathieu-Daudé wrote:
> Hi Peter,
>
> On 1/16/20 5:46 PM, Peter Maydell wrote:
>> On Wed, 8 Jan 2020 at 11:32, Dongjiu Geng wrote:
>>>
>>> I and Xiang are willing to review the APEI-related patches and
>>> volunteer as the reviewers for the HEST/GHES part.
>>>
>>> Sign
On 2020/1/17 0:28, Peter Maydell wrote:
> On Wed, 8 Jan 2020 at 11:33, Dongjiu Geng wrote:
>
>> +void kvm_arch_on_sigbus_vcpu(CPUState *c, int code, void *addr)
>> +{
>> +ram_addr_t ram_addr;
>> +hwaddr paddr;
>> +
>> +assert(code == BUS_MCEERR_AR || code == BUS_MCEERR_AO);
>> +
>> +
Ping.
发件人：gengdongjiu
收件人：pbonzini ;gengdongjiu ;mst
;imammedo ;shannon.zhaosl
;peter.maydell ;fam
;rth ;ehabkost
;mtosatti ;xuwei (O)
;Jonathan Cameron ;james.morse
;qemu-devel ;kvm
;qemu-arm
抄 送：zhengxiang (A) ;Linuxarm
时 间：2020-01-08 19:32:33
主题[PATCH v22 0/9] Add ARMv8 RAS
1. How to enable this feature:
(a) In KVM mode: ./qemu-system-aarch64 --enable-kvm -cpu host --bios
QEMU_EFI.fd_new -machine virt,gic-version=3,ras,kernel-irqchip=on -smp 4
-nographic -kernel Image -append "rdinit=/init console=ttyAMA0 mem=512M
root=/dev/ram0" -initrd guestfs_new.cpio.gz
(b）I
On 2019/11/16 0:37, Igor Mammedov wrote:
>> +
>> +/* zero means OSPM does not acknowledge the error */
>> +if (!read_ack_register) {
>> +if (loop < 3) {
>> +usleep(100 * 1000);
>> +loop++;
>> +goto retry;
> as minimum th
On 2019/12/9 21:05, Beata Michalska wrote:
>> Here we set the FnV to not valid, not to set it to valid.
>> because Guest will use the physical address that recorded in APEI table.
>>
> To be precise : the FnV is giving the status of FAR - so what you are setting
> here is status of 0b0 which me
>
> I think we could make the user-facing description of
> the option a little clearer: something like
> "Set on/off to enable/disable reporting host memory errors
> to a KVM guest using ACPI and guest external abort exceptions"
>
> ?
Peter, sorry for the late response.
sure, we have already up
On 2019/11/22 23:47, Beata Michalska wrote:
> Hi,
>
> On Mon, 11 Nov 2019 at 01:48, Xiang Zheng wrote:
>>
>> From: Dongjiu Geng
>>
>> Add a SIGBUS signal handler. In this handler, it checks the SIGBUS type,
>> translates the host VA delivered by host to guest PA, then fills this PA
>> to gues
On 2019/12/3 2:27, Peter Maydell wrote:
>> application within guest, host does not know which application encounters
>> errors.
>>
>> For the ARMv8 SEA/SEI, KVM or host kernel delivers SIGBUS to notify
>> userspace.
>> After user space gets the notification, it will record the CPER into guest
>>
On 2019/11/25 17:48, Igor Mammedov wrote:
>>>..
>>> bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
>>> ACPI_GHES_ERROR_STATUS_ADDRESS_OFFSET(hest_start, source_id),
>>> sizeof(uint64_t), ACPI_GHES_ERRORS_FW_CFG_FILE,
>>> source_id * sizeof(uint64_t
On 2019/11/18 21:21, Michael S. Tsirkin wrote:
>> If use offset relative to GAS structure, the code does not easily extend to
>> support more Generic Hardware Error Source.
>> if use offset relative to hest_start, just use a loop, the code can support
>> more error source, for example:
>> for (s
On 2019/11/18 20:49, gengdongjiu wrote:
>>> + */
>>> +build_append_int_noprefix(table_data, source_id, 2);
>>> +/* Related Source Id */
>>> +build_append_int_noprefix(table_data, 0x, 2);
>>> +/* Flags */
>&g
Hi,Igor,
Thanks for you review and time.
>
>> +/*
>> + * Type:
>> + * Generic Hardware Error Source version 2(GHESv2 - Type 10)
>> + */
>> +build_append_int_noprefix(table_data,
>> ACPI_GHES_SOURCE_GENERIC_ERROR_V2, 2);
>> +/*
>> + * Source Id
>
>> + * Once
> On Fri, 15 Nov 2019 14:32:47 +
> gengdongjiu wrote:
>
> > > > + */
> > > > +static void acpi_ghes_build_notify(GArray *table, const uint8_t
> > > > +type)
> > >
> > > typically format should be build_WHAT(), so
> > &g
> > + */
> > +static void acpi_ghes_build_notify(GArray *table, const uint8_t type)
>
> typically format should be build_WHAT(), so
> build_ghes_hw_error_notification()
>
> And I'd move this out into its own patch.
> this applies to other trivial in-depended sub-tables, that take all data
> nee
On 2019/11/4 20:14, Xiang Zheng wrote:
> From: Dongjiu Geng
>
> This patch implements APEI GHES Table generation via fw_cfg blobs. Now
> it only supports ARMv8 SEA, a type of GHESv2 error source. Afterwards,
> we can extend the supported types if needed. For the CPER section,
> currently it is me
On 2019/10/28 23:16, Peter Maydell wrote:
>> Hi Peter,
>> what do you think about it?
> I suggest you just use R: for the moment. The code will all end up going
> through my tree or perhaps Michael's anyway, so it doesn't make much
> practical difference.
ok, got it, thanks.
>
> thanks
> --
On 2019/10/28 22:56, Michael S. Tsirkin wrote:
> On Mon, Oct 28, 2019 at 09:50:21PM +0800, gengdongjiu wrote:
>> Hi Michael,
>>
>> On 2019/10/28 16:28, Michael S. Tsirkin wrote:
>>>>> gets some testing. I'll leave this decision to the ARM maintainer. For
Hi Michael,
On 2019/10/28 16:28, Michael S. Tsirkin wrote:
>>> gets some testing. I'll leave this decision to the ARM maintainer. For
>>> ACPI parts:
>>>
>>> Reviewed-by: Michael S. Tsirkin
>> Got it, Thanks for the Reviewed-by from Michael.
>>
>> Hi Michael,
>> According to discussion with Q
Michael,
On 2019/10/28 16:28, Michael S. Tsirkin wrote:
>> Got it, Thanks for the Reviewed-by from Michael.
>>
>> Hi Michael,
>> According to discussion with QEMU community, I finished and developed the
>> whole ARM RAS virtualization solution, and introduce the ARM APEI table in
>> the first
Hi Michael/All
On 2019/10/27 18:17, Michael S. Tsirkin wrote:
> On Sat, Oct 26, 2019 at 11:24:42AM +0800, Xiang Zheng wrote:
>> In the ARMv8 platform, the CPU error types are synchronous external
>> abort(SEA)
>> and SError Interrupt (SEI). If exception happens in guest, sometimes it's
>> better
zhaosl ;peter.maydell
;lersek ;james.morse
;gengdongjiu ;mtosatti
;rth ;ehabkost
;Jonathan Cameron ;xuwei (O)
;kvm ;qemu-devel
;qemu-arm ;Linuxarm
抄 送：Wanghaibin (D)
时 间：2019-09-17 20:40:21
主题Re: [PATCH v18 0/6] Add ARMv8 RAS virtualization support in QEMU
Hi all,
This patch series ha
Thanks xiang's continue upstream and test.
Hope maintainer can review it.
On 2019/9/17 20:39, Xiang Zheng wrote:
> Hi all,
>
> This patch series has been tested for both TCG and KVM scenes.
>
> 1) Test for TCG:
>- Re-compile qemu after applying the patch refered to
> https://patchwork.kern
On 2019/8/27 17:47, Peter Maydell wrote:
> On Tue, 27 Aug 2019 at 10:42, Dongjiu Geng wrote:
>>
>> Except support linux operation system, qemu also supports other
>> operation system which is non linux, such as microkernel system.
>>
>> But now Qemu only load linux initrd, so change it to load
On 2019/6/24 20:27, Igor Mammedov wrote:
> On Tue, 14 May 2019 04:18:20 -0700
> Dongjiu Geng wrote:
>
>> This implements APEI GHES Table generation via fw_cfg blobs.
>> Now it only support GPIO-Signal and ARMv8 SEA two types of GHESv2 error
>> source. Afterwards, we can extend the supported types
On 2019/6/25 21:16, Igor Mammedov wrote:
>>> In light of the race for leaner QEMU and faster startup times,
>>> it might be better to make RAS optional and make user explicitly
>>> enable it using a machine option.
>> I will add a machine option to make RAS optional, do you think we should
>>
On 2019/6/24 20:32, Igor Mammedov wrote:
> On Tue, 14 May 2019 04:18:21 -0700
> Dongjiu Geng wrote:
>
>> kvm_hwpoison_page_add() and kvm_unpoison_all() will be used both
>> by X86 and ARM platforms, so move these functions to a common
>> accel/kvm/ folder to avoid duplicate code.
>>
>> Signed-
On 2019/6/24 21:08, Igor Mammedov wrote:
> On Tue, 14 May 2019 04:18:23 -0700
> Dongjiu Geng wrote:
>
>> Add SIGBUS signal handler. In this handler, it checks the SIGBUS type,
>> translates the host VA delivered by host to guest PA, then fill this PA
>> to guest APEI GHES memory, then notify gues
On 2019/6/20 20:42, Igor Mammedov wrote:
> On Tue, 14 May 2019 04:18:18 -0700
> Dongjiu Geng wrote:
>
>> It will help to add Generic Error Status Block to ACPI tables
>> without using packed C structures and avoid endianness
>> issues as API doesn't need explicit conversion.
>>
>> Signed-off-b
On 2019/6/24 19:16, Igor Mammedov wrote:
On 2019/6/20 20:10, Igor Mammedov wrote:
>> + */
>> +struct AcpiGenericErrorStatus {
>> +/* It is a bitmask composed of ACPI_GEBS_xxx macros */
>> +uint32_t block_status;
>> +uint32_t raw_data_offset;
>> +uin
On 2019/6/20 20:28, Igor Mammedov wrote:
> On Tue, 14 May 2019 04:18:17 -0700
> Dongjiu Geng wrote:
>
>> It will help to add Generic Error Data Entry to ACPI tables
>> without using packed C structures and avoid endianness
>> issues as API doesn't need explicit conversion.
>>
>> Signed-off-by:
On 2019/6/20 20:04, Igor Mammedov wrote:
> On Tue, 14 May 2019 04:18:14 -0700
> Dongjiu Geng wrote:
>
>> Support this feature since version 4.1, disable it by
>> default in the old version.
>>
>> Signed-off-by: Dongjiu Geng
>> ---
>> hw/arm/virt.c | 6 ++
>> include/hw/arm/virt.h
On 2019/6/20 23:09, Igor Mammedov wrote:
> On Thu, 20 Jun 2019 22:04:01 +0800
> gengdongjiu wrote:
>
>> Hi Igor,
>>Thanks for your review.
>>
>> On 2019/6/20 20:10, Igor Mammedov wrote:
>>>> + */
>>>> +struct AcpiGenericErrorStatus
Hi Igor,
Thanks for your review.
On 2019/6/20 20:10, Igor Mammedov wrote:
>> + */
>> +struct AcpiGenericErrorStatus {
>> +/* It is a bitmask composed of ACPI_GEBS_xxx macros */
>> +uint32_t block_status;
>> +uint32_t raw_data_offset;
>> +uint32_t raw_data_length;
>> +uint32_
>
> On Tue, 14 May 2019 04:18:20 -0700
> Dongjiu Geng wrote:
>
> > This implements APEI GHES Table generation via fw_cfg blobs.
> > Now it only support GPIO-Signal and ARMv8 SEA two types of GHESv2
> > error source. Afterwards, we can extend the supported types if needed.
> > For the CPER sectio
>
> On Tue, 14 May 2019 04:18:23 -0700
> Dongjiu Geng wrote:
>
> > Add SIGBUS signal handler. In this handler, it checks the SIGBUS type,
> > translates the host VA delivered by host to guest PA, then fill this
> > PA to guest APEI GHES memory, then notify guest according to the SIGBUS
> > type
On 2019/5/29 11:40, Michael S. Tsirkin wrote:
> On Tue, May 14, 2019 at 04:18:15AM -0700, Dongjiu Geng wrote:
>> Add Generic Error Status Block structures and some macros
>> definitions, which is referred to the ACPI 4.0 or ACPI 6.2. The
>> HEST table generation and CPER record will use them.
>>
Hi Michael,
Thanks for the review.
On 2019/5/29 11:37, Michael S. Tsirkin wrote:
> On Tue, May 14, 2019 at 04:18:20AM -0700, Dongjiu Geng wrote:
>> This implements APEI GHES Table generation via fw_cfg blobs.
>> Now it only support GPIO-Signal and ARMv8 SEA two types of GHESv2 error
>> source.
ping...
发件人：gengdongjiu
收件人：pbonz...@redhat.com ;m...@redhat.com
;imamm...@redhat.com
;shannon.zha...@gmail.com
;peter.mayd...@linaro.org
;ler...@redhat.com
;james.mo...@arm.com
;mtosa...@redhat.com
;r...@twiddle.net ;ehabk...@redhat.com
;zhengxiang (A) ;Jonathan Cameron
;xuwei (O)
;k
Hi All,
for this series patch, we can use below simple method to test:
1). Apply below hard code change after applying this series patch:
diff --git a/cpus.c b/cpus.c
index e58e7ab..7149f54 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1131,6 +1131,8 @@ static void sigbus_reraise(void)
static void sigbu
>
>> +void kvm_arch_on_sigbus_vcpu(CPUState *c, int code, void *addr)
>> +{
>> +ARMCPU *cpu = ARM_CPU(c);
>> +CPUARMState *env = &cpu->env;
>> +ram_addr_t ram_addr;
>> +hwaddr paddr;
>> +
>> +assert(code == BUS_MCEERR_AR || code == BUS_MCEERR_AO);
>> +
>> +if (addr) {
>>
On 2019/3/25 18:25, Peter Maydell wrote:
> Further testing from Alex suggests this is some unrelated
> bug or regression (ie not caused by this patch), but:
> since the only in-tree use for this patch is to get nested
> debugging working and it would be broken for this other
> reason even with t
On 2019/3/18 20:49, Peter Maydell wrote:
> On Mon, 18 Mar 2019 at 12:34, gengdongjiu wrote:
>>
>>
>>
>> On 2019/3/16 4:11, Philippe Mathieu-Daudé wrote:
>>>> Signed-off-by: Peter Maydell
>>>> ---
>>>> Should we try to put this in fo
On 2019/3/16 4:11, Philippe Mathieu-Daudé wrote:
>> Signed-off-by: Peter Maydell
>> ---
>> Should we try to put this in for rc1? Not sure... Testing
>> definitely appreciated.
> You might include it for rc1 and we still have rc2/rc3 to revert it.
why we still have rc2/rc3 to revert it?
If we c
On 2019/3/14 20:43, Peter Maydell wrote:
>> If you think this patch will introduce some issue, we can add one function
>> write_part_cpustate_to_list()[2] to change the specified
>> register instead of all the registers[1].
> It definitely does introduce an issue, but we need to address
> it by wo
_raw_cp_reg(&cpu->env, ri);
+return true;
+}
+}
+return false;
+}
+
On 2019/3/14 19:31, gengdongjiu wrote:
> Hi Peter/Eric,
>I think we should fix the regression issue instead of revert this patch,
> I think the reason of
>this issue is that
Hi Peter/Eric,
I think we should fix the regression issue instead of revert this patch, I
think the reason of
this issue is that QEMU modified some unexpected resisters, we should find
out.
Revert "arm: Allow system registers for KVM guests to be changed by QEMU
code"
This r
Add "Reviewed-by" from Richard because Richard has reviewed it in patch v2[1],
thanks.
Reviewed-by: Richard Henderson
[1]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg604509.html
On 2019/3/12 20:52, Dongjiu Geng wrote:
> Some generic arch timer registers are Config-RW in the EL0,
> w
On 2019/3/12 23:02, Richard Henderson wrote:
>> [INFO ]@(dump_registers:68): X6=0020 X7=0c00b030
>> ---
>> target/arm/helper.c | 30 +++---
>> 1 file changed, 15 insertions(+), 15 deletions(-)
> Reviewed-by: Richard Henderson
Thanks for this "Revie
From: Dongjiu Geng
Some generic arch timer registers are Config-RW in the EL0,
which means the EL0 exception level can have write permission
if it is appropriately configured.
When VM access registers, it firstly checks whether they have RW
permission, then check whether it is appropriately conf
understand now，thanks for the explaination, I will update it.
发件人：Peter Maydell
收件人：gengdongjiu
抄 送：qemu-arm ;QEMU Developers
时间：2019-03-11 23:39:32
主 题：Re: [RESEND PATCH] target/arm: change arch timer registers access permission
On Mon, 11 Mar 2019 at 15:24, gengdongjiu wrote:
> So If Q
> Hi Peter,
>Thanks for the review.
>
> > >
> > > From: Dongjiu Geng
> > >
> > > Some generic arch timer registers are Config-RW in the EL0, which
> > > means the EL0 exception level can have write permission if it is
> > > appropriately configured.
> > >
> > > When VM access registers, it fi
Hi Peter,
Thanks for the review.
> >
> > From: Dongjiu Geng
> >
> > Some generic arch timer registers are Config-RW in the EL0, which
> > means the EL0 exception level can have write permission if it is
> > appropriately configured.
> >
> > When VM access registers, it firstly checks whether t
Some generic arch timer registers are Config-RW in the EL0,
which means the EL0 exception level can have write permission
if it is appropriately configured.
When VM access registers, it firstly checks whether they have RW
permission, then check whether it is appropriately configured.
If they are d
Some generic arch timer registers are Config-RW in the EL0,
which means the EL0 exception level can have write permission
if it is appropriately configured.
When VM access registers, it firstly checks whether they have RW
permission, then check whether it is appropriately configured.
If they are d
From: Dongjiu Geng
Some generic arch timer registers are Config-RW in the EL0,
which means the EL0 exception level can have write permission
if it is appropriately configured.
When VM access registers, it firstly checks whether they have RW
permission, then check whether it is appropriately conf
I think Peter's patch is good, I will resubmit my series patches based on this.
On 2019/2/14 4:18, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> On Wed, 13 Feb 2019 at 16:29, Alex Bennée wrote:
>>>
>>>
>>> Peter Maydell writes:
>>>
At the moment the Arm implementations of kvm_arch_{g
>
> On Thu, 8 Nov 2018 at 10:18, Dongjiu Geng wrote:
> >
> > Add SIGBUS signal handler. In this handler, it checks the SIGBUS type,
> > translates the host VA delivered by host to guest PA, then fill this
> > PA to guest APEI GHES memory, then notify guest according to the SIGBUS
> > type.
> > T
On 2018/12/6 23:14, Peter Maydell wrote:
> At the moment the Arm implementations of kvm_arch_{get,put}_registers()
> don't support having QEMU change the values of system registers
> (aka coprocessor registers for AArch32). This is because although
> kvm_arch_get_registers() calls write_list_to_c
On 2018/12/6 23:14, Peter Maydell wrote:
> ---
> I think this patch:
> * should be necessary for the current KVM debug code to be able
>to actually set the ESR_EL1 for the guest when it wants to
>deliver a breakpoint exception to it
> * will also be necessary for Dongjiu's patchset to inj
> >>
> >> Hi Peter,
> >> Thanks for the review and comments.
> >>
> >> >
> >> > On 8 November 2018 at 10:29, Dongjiu Geng wrote:
> >> > > +bool write_part_cpustate_to_list(ARMCPU *cpu, ptrdiff_t
> >> > > +fieldoffset)
> >> >
> >> > What is this about? Nothing else in QEMU needs to mess with the
Hi Peter,
Thanks for the comments.
> On Fri, 23 Nov 2018 at 14:31, gengdongjiu wrote:
> >
> > Hi Peter,
> > Thanks for the comments and mail.
> >
> > >
> > > On 22 November 2018 at 10:28, Peter Maydell
> > > wrote:
> > &
Hi Peter,
On 2018/11/24 2:45, Peter Maydell wrote:
> On Wed, 21 Nov 2018 at 14:34, gengdongjiu wrote:
>>
>> Hi Peter,
>> Thanks for the review and comments.
>>
>>>
>>> On 8 November 2018 at 10:29, Dongjiu Geng wrote:
>>>> +bool write
Hi Peter,
Thanks for the comments and mail.
>
> On 22 November 2018 at 10:28, Peter Maydell wrote:
> > On 22 November 2018 at 03:05, gengdongjiu wrote:
> >>> >
> >>> Shouldn't there be something in here to say "only report this error to
> >
> > +void kvm_arch_on_sigbus_vcpu(CPUState *c, int code, void *addr) {
> > +ram_addr_t ram_addr;
> > +hwaddr paddr;
> > +
> > +assert(code == BUS_MCEERR_AR || code == BUS_MCEERR_AO);
> > +if (addr) {
> > +ram_addr = qemu_ram_addr_from_host(addr);
> > +if (ram_add
Hi Peter,
Thanks for the review and comments.
>
> On 8 November 2018 at 10:29, Dongjiu Geng wrote:
> > Add synchronous external abort injection logic, setup exception type
> > and syndrome value. When switch to guest, guest will jump to the
> > synchronous external abort vector table entry.
>
>
> On 8 November 2018 at 10:29, Dongjiu Geng wrote:
> > Support this feature since version 2.12, disable it by default in the
> > old version.
> >
> > Signed-off-by: Dongjiu Geng
> > ---
> > Address Shannon's comments to add platform version in [1].
> >
> > [1]: https://lkml.org/lkml/2017/8/25/
Hi Peter,
Thanks very much for the commands and review.
> On 8 November 2018 at 10:29, Dongjiu Geng wrote:
> > kvm_hwpoison_page_add() and kvm_unpoison_all() will be used both by
> > X86 and ARM platforms, so move these functions to a common accel/kvm/
> > folder to avoid duplicate code.
> >
>
Hi All
using mainline QEMU code and below boot up commands, the QEMU will be hang
when do bootup, if I add the "-enable-kvm" parameter, it can boot up
successfully, do you know the reason about it?
I also try the "remotes/origin/stable-2.12" branch code using below same boot
up commands, it d
Hi peter,
Thanks very much for this comments and very sorry for my late response due
to business trave.
Yes, the reason that tag the patchset to RFC is that it just hasn't been
tested on 32-bit. if someone else can test it on 32-bit platform, it will be
great.
I do not have 32-b
...
> > };
> > --
> > 2.7.4
> >
>
> Why aren't kvm_get_vcpu_events() and kvm_put_vcpu_events() in
> target/arm/kvm.c, as I suggested in my last review? There's
> no need to duplicate them for kvm32.c and kvm64.c, afaict.
I misunderstand your previous mail meanings. Sorry for the mistake,
I will
Hi Andrew,
Thanks for the review and comments.
[...]
> > @@ -600,6 +605,60 @@ int kvm_arm_cpreg_level(uint64_t regidx)
> > #define AARCH64_SIMD_CTRL_REG(x) (KVM_REG_ARM64 | KVM_REG_SIZE_U32 | \
> > KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(x))
> >
> > +static int kvm_put_vcpu
Hi Peter/shannon,
when you are free, hope you can have a look at this series of patches.
Thanks a lot for your time in advance.
On 2018/9/16 1:32, Dongjiu Geng wrote:
> This patch extends the qemu-kvm state sync logic with support for
> KVM_GET/SET_VCPU_EVENTS, giving access to yet missing SEr
Hi Shannon
Ｉhave changed it according to your comments and repost the patches, thanks
for the review.
>
> Hi,
>
> On 8/28/2018 4:46 AM, Dongjiu Geng wrote:
> > This patch extends the qemu-kvm state sync logic with support for
> > KVM_GET/SET_VCPU_EVENTS, giving access to yet missing SError e
1 - 100 of 189 matches
Mail list logo
