> -Original Message-
> From: qemu-devel-bounces+eddie.dong=intel@nongnu.org devel-bounces+eddie.dong=intel@nongnu.org> On Behalf Of Lukas
> Straub
> Sent: Thursday, June 22, 2023 5:15 AM
> To: qemu-devel
> Cc: Zhang, Hailiang ; Juan Quintela
> ; Peter Xu ; Leonardo Bras
> ; Zha
> -Original Message-
> From: qemu-devel-bounces+eddie.dong=intel@nongnu.org devel-bounces+eddie.dong=intel@nongnu.org> On Behalf Of Titus
> Rwantare
> Sent: Monday, February 6, 2023 11:50 AM
> To: peter.mayd...@linaro.org
> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; Titus Rw
> When booting the Zephyr demo in [1] we get:
>
> aspeed.io: unimplemented device write (size 4, offset 0x185128, value
> 0x030f1ff1) <--
> aspeed.io: unimplemented device write (size 4, offset 0x18512c, value
> 0x03f1)
>
> This corresponds to this Zephyr code [2]:
>
> static int aspee
>
> Avoid confusing two different things:
> - the WDT I/O region size ('iosize')
> - at which offset the SoC map the WDT ('offset') While it is often the same,
> we
> can map smaller region sizes at larger offsets.
>
> Here we are interested in the I/O region size, so rename as 'iosize'.
>
> Re
Using a union can better reflect this. Also, it can avoid the convert from 2
32-bits register to 64 bits, like the above code does.
ibex_timer_update_irqs() also does this conversion.
It took me a bit of time, but now I think I understand what you mean: a union
of 2 uint32_t's (perhaps packed in
From: Tyler Ng
Sent: Monday, September 26, 2022 4:38 PM
To: Dong, Eddie
Cc: open list:RISC-V ; qemu-devel@nongnu.org Developers
; Alistair Francis ; Meng, Bin
; Thomas Huth ; Paolo Bonzini
; Palmer Dabbelt ; Laurent Vivier
Subject: Re: [PATCH v2 3/3] hw/timer: ibex_timer.c: Add support
Hi Tyler:
Some other comments embedded.
> +
> +static void ibex_aon_write(void *opaque,
> + hwaddr addr, uint64_t value,
> + unsigned int size) {
> +IbexAONTimerState *s = IBEX_AON_TIMER(opaque);
> +
> +/* When writing, need to c
Hi Tyler:
> +}
> +
> +/* Called when the bark timer expires */ static void
> +ibex_aon_barker_expired(void *opaque) {
This may happen during ibex_aon_update_count(), right?
> + IbexAONTimerState *s = IBEX_AON_TIMER(opaque);
> + if (ibex_aon_update_count(s) &&
This may happen during
> -Original Message-
> From: Qemu-devel
> On Behalf Of Tyler Ng
> Sent: Thursday, September 22, 2022 8:59 AM
> To: open list:RISC-V ; qemu-devel@nongnu.org
> Developers
> Cc: Alistair Francis ; Meng, Bin
> ; Thomas Huth ; Paolo
> Bonzini ; Palmer Dabbelt ;
> Laurent Vivier
> Subject: [
> -Original Message-
> From: Qemu-devel
> On Behalf Of Tyler Ng
> Sent: Thursday, September 22, 2022 8:59 AM
> To: open list:RISC-V ; qemu-devel@nongnu.org
> Developers
> Cc: Alistair Francis ; Meng, Bin
> ; Thomas Huth ; Paolo
> Bonzini ; Palmer Dabbelt ;
> Laurent Vivier
> Subject: [
Reviewed-by: Eddie Dong
> -Original Message-
> From: Qemu-devel bounces+eddie.dong=intel@nongnu.org> On Behalf Of Yajun Wu
> Sent: Wednesday, May 25, 2022 8:49 PM
> To: qemu-devel@nongnu.org; m...@redhat.com; alex.ben...@linaro.org;
> yaj...@nvidia.com
> Cc: Parav Pandit
> Subject:
> -Original Message-
> From: Alex Williamson
> Sent: Wednesday, June 1, 2022 11:01 AM
> To: Dong, Eddie
> Cc: Rao, Lei ; Tian, Kevin ; Zeng,
> Jason ; quint...@redhat.com; dgilb...@redhat.com;
> Li, Yadong ; Liu, Yi L ; qemu-
> de...@nongnu.org
> Subject:
> -Original Message-
> From: Qemu-devel bounces+eddie.dong=intel@nongnu.org> On Behalf Of Alex Williamson
> Sent: Thursday, May 26, 2022 11:44 AM
> To: Rao, Lei
> Cc: Tian, Kevin ; Dong, Eddie
> ; Zeng, Jason ;
> quint...@redhat.com; dgilb...@redhat.com;
> > The usage is to construct a secondary hot standby VM (SVM), identical with
> the primary VM (PVM).
> > When an virtual DMA happens in PVM side, we need to know at which
> instruction boundary the virtual DMA is delivered, so that we can replay the
> virtual DMA event at the 2nd VM side, to keep
>
> On Thu, Nov 24, 2016 at 08:44:06AM +, Dong, Eddie wrote:
> > Under certain situation, we have a requirement to apply the
> virtual DMA event in a deterministic way. Current Qemu uses asynchronous
> approach to emulate the virtual IO events since quite l
Hi:
Under certain situation, we have a requirement to apply the virtual
DMA event in a deterministic way. Current Qemu uses asynchronous approach to
emulate the virtual IO events since quite long time ago. I am wondering if we
still have an option to choose the synchronous emulation sol
> >
> > Even if the device driver doesn't support migration, you still want to
> > migrate VM? That maybe risk and we should add the "bad path" for the
> > driver at least.
>
> At a minimum we should have support for hot-plug if we are expecting to
> support migration. You would simply have to ho
> On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote:
> > On 2015年11月25日 13:30, Alexander Duyck wrote:
> >> No, what I am getting at is that you can't go around and modify the
> >> configuration space for every possible device out there. This
> >> solution won't scale.
> >
> >
> > PCI config spac
> - What's the plan for vhost? Userspace network in qemu is rather slow, most
> user will choose vhost.
[Dong, Eddie] Hi Jason:
How about we take staging approach? In general, COLO opens a door of
high performance HA solution, but it will take very long time to make
everyth
> >
> > A question here, the packet comparing may be very tricky. For example,
> > some protocol use random data to generate unpredictable id or
> > something else. One example is ipv6_select_ident() in Linux. So COLO
> > needs a mechanism to make sure PVM and SVM can generate same random
> data?
>
BTW, I felt it is better to be called as an agency, rather than a proxy. Any
comments from native speaker?
Thx Eddie
> Hi, all
>
> We are planning to implement colo-proxy in qemu to cache and compare
> packets.
> This module is one of the important component of COLO project and now it is
> s
Hi Stefan:
Thanks for your comments!
>
> On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:
> > We are planning to implement colo-proxy in qemu to cache and compare
> packets.
>
> I thought there is a kernel module to do that?
Yes, that is the previous solution the COLO
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com]
> Sent: Tuesday, May 05, 2015 11:24 PM
> To: Stefan Hajnoczi
> Cc: Paolo Bonzini; Wen Congyang; Fam Zheng; Kevin Wolf; Lai Jiangshan; qemu
> block; Jiang, Yunhong; Dong, Eddie; qemu devel;
> > Thanks Dave:
> > Whether the randomness value/branch/code path the PVM and SVM
> may
> > have, It is only a performance issue. COLO never assumes the PVM and
> > SVM has same internal Machine state. From correctness p.o.v, as if
> > the PVM and SVM generate Identical response, we can view
> >
> > Let me clarify on this issue. COLO didn't ignore the TCP sequence
> > number, but uses a new implementation to make the sequence number to
> > be best effort identical between the primary VM (PVM) and secondary VM
> > (SVM). Likely, VMM has to synchronize the emulation of randomization
> >
> >
> > I didn't quite understand a couple of things though, perhaps you can
> > explain:
> >1) If we ignore the TCP sequence number problem, in an SMP machine
> > don't we get other randomnesses - e.g. which core completes something
> > first, or who wins a lock contention, so the output strea
>> A VF interrupt usually happens in 4-8KHZ. How about the virtio?
>> I assume virtio will be widely used together w/ leagcy guest with
>> INTx mode.
>>
>
> True, but in time it will be replaced by MSI.
>
> Note without vhost virtio is also in userspace, so there are lots of
> exits anyway for
Avi Kivity wrote:
> On 06/09/2010 06:59 PM, Dong, Eddie wrote:
>>
>> Besides VF IO interrupt and timer interrupt introduced performance
>> overhead risk,
>
> VF usually uses MSI
Typo, I mean PV IO.
A VF interrupt usually happens in 4-8KHZ. How about the virtio?
I a
Avi Kivity wrote:
> I am currently investigating a problem with the a guest running Linux
> malfunctioning in the NMI watchdog code. The problem is that we don't
> handle NMI delivery mode for the local APIC LINT0 pin; instead we
> expect ExtInt deliver mode or that the line is disabled completely
29 matches
Mail list logo
