similar to: [PATCH v4 00/15] virtio-mem: paravirtualized memory

On 14.05.20 13:10, David Hildenbrand wrote: > On 14.05.20 12:12, David Hildenbrand wrote: >> On 14.05.20 12:02, teawater wrote: >>> >>> >>>> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >>>> >>>> On 14.05.20 08:44, teawater wrote: >>>>> Hi David, >>>>> >>>>> I got a

On 14.05.20 12:12, David Hildenbrand wrote: > On 14.05.20 12:02, teawater wrote: >> >> >>> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >>> >>> On 14.05.20 08:44, teawater wrote: >>>> Hi David, >>>> >>>> I got a kernel warning with v2 and v3. >>> >>> Hi Hui, >>>

On 14.05.20 12:02, teawater wrote: > > >> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >> >> On 14.05.20 08:44, teawater wrote: >>> Hi David, >>> >>> I got a kernel warning with v2 and v3. >> >> Hi Hui, >> >> thanks for playing with the latest versions. Surprisingly, I can >> reproduce even by

On 14.05.20 12:02, teawater wrote: > > >> 2020?5?14? 16:48?David Hildenbrand <david at redhat.com> ??? >> >> On 14.05.20 08:44, teawater wrote: >>> Hi David, >>> >>> I got a kernel warning with v2 and v3. >> >> Hi Hui, >> >> thanks for playing with the latest versions. Surprisingly, I can >> reproduce even by

> Am 24.12.2019 um 08:04 schrieb teawater <teawaterz at linux.alibaba.com>: > > ?Hi David, > > Thanks for your work. > > I Got following build fail if X86_64_ACPI_NUMA is n with rfc3 and rfc4: > make -j8 bzImage > GEN Makefile > DESCEND objtool > CALL /home/teawater/kernel/linux-upstream3/scripts/atomic/check-atomics.sh > CALL

On 05.06.20 11:08, David Hildenbrand wrote: > On 05.06.20 10:55, Alex Shi wrote: >> >> >> ? 2020/1/9 ??9:48, David Hildenbrand ??: >>> Ping, >>> >>> I'd love to get some feedback on >>> >>> a) The remaining MM bits from MM folks (especially, patch #6 and #8). >>> b) The general virtio infrastructure (esp. uapi in patch

On 05.06.20 11:08, David Hildenbrand wrote: > On 05.06.20 10:55, Alex Shi wrote: >> >> >> ? 2020/1/9 ??9:48, David Hildenbrand ??: >>> Ping, >>> >>> I'd love to get some feedback on >>> >>> a) The remaining MM bits from MM folks (especially, patch #6 and #8). >>> b) The general virtio infrastructure (esp. uapi in patch

On 05.06.20 11:36, David Hildenbrand wrote: > On 05.06.20 11:08, David Hildenbrand wrote: >> On 05.06.20 10:55, Alex Shi wrote: >>> >>> >>> ? 2020/1/9 ??9:48, David Hildenbrand ??: >>>> Ping, >>>> >>>> I'd love to get some feedback on >>>> >>>> a) The remaining MM bits from MM folks (especially,

On 14.05.20 08:44, teawater wrote: > Hi David, > > I got a kernel warning with v2 and v3. Hi Hui, thanks for playing with the latest versions. Surprisingly, I can reproduce even by hotplugging a DIMM instead as well - that's good, so it's not related to virtio-mem, lol. Seems to be some QEMU setup issue with older machine types. Can you switch to a newer qemu machine version,

On 05.06.20 10:55, Alex Shi wrote: > > > ? 2020/1/9 ??9:48, David Hildenbrand ??: >> Ping, >> >> I'd love to get some feedback on >> >> a) The remaining MM bits from MM folks (especially, patch #6 and #8). >> b) The general virtio infrastructure (esp. uapi in patch #2) from virtio >> folks. >> >> I'm planning to send a proper

? 2020/1/9 ??9:48, David Hildenbrand ??: > Ping, > > I'd love to get some feedback on > > a) The remaining MM bits from MM folks (especially, patch #6 and #8). > b) The general virtio infrastructure (esp. uapi in patch #2) from virtio > folks. > > I'm planning to send a proper v1 (!RFC) once I have all necessary MM > acks. In the meanwhile, I will do more

? 2020/1/9 ??9:48, David Hildenbrand ??: > Ping, > > I'd love to get some feedback on > > a) The remaining MM bits from MM folks (especially, patch #6 and #8). > b) The general virtio infrastructure (esp. uapi in patch #2) from virtio > folks. > > I'm planning to send a proper v1 (!RFC) once I have all necessary MM > acks. In the meanwhile, I will do more

On 02.03.20 14:49, David Hildenbrand wrote: > This series is based on latest linux-next. The patches are located at: > https://github.com/davidhildenbrand/linux.git virtio-mem-v1 > > The basic idea of virtio-mem is to provide a flexible, > cross-architecture memory hot(un)plug solution that avoids many limitations > imposed by existing technologies, architectures, and

On 05.06.20 12:46, Alex Shi wrote: > > > ? 2020/6/5 ??6:05, David Hildenbrand ??: >>> I guess I know what's happening here. In case we only have DMA memory >>> when booting, we don't reserve swiotlb buffers. Once we hotplug memory >>> and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to >>> map such PFNs (total 0

On 08.06.20 09:12, teawater wrote: > > >> 2020?6?8? 14:58?David Hildenbrand <david at redhat.com> ??? >> >> On 08.06.20 08:14, Michael S. Tsirkin wrote: >>> If subblock size is large (e.g. 1G) 32 bit math involving it >>> can overflow. Rather than try to catch all instances of that, >>> let's tweak block size to 64 bit. >>

On Thu, May 07, 2020 at 12:31:04PM +0200, David Hildenbrand wrote: > This series is based on latest linux-next. The patches are located at: > https://github.com/davidhildenbrand/linux.git virtio-mem-v3 > > Patch #1 - #10 where contained in v2 and only contain minor modifications > (mostly smaller fixes). The remaining patches are new and contain smaller > optimizations.

? 2020/6/5 ??6:05, David Hildenbrand ??: >> I guess I know what's happening here. In case we only have DMA memory >> when booting, we don't reserve swiotlb buffers. Once we hotplug memory >> and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to >> map such PFNs (total 0 (slots), used 0 (slots)). >> >> Can you try with

? 2020/6/5 ??6:05, David Hildenbrand ??: >> I guess I know what's happening here. In case we only have DMA memory >> when booting, we don't reserve swiotlb buffers. Once we hotplug memory >> and online ZONE_NORMAL, we don't have any swiotlb DMA bounce buffers to >> map such PFNs (total 0 (slots), used 0 (slots)). >> >> Can you try with

On 29.03.20 14:42, Michael S. Tsirkin wrote: > On Wed, Mar 11, 2020 at 06:14:12PM +0100, David Hildenbrand wrote: >> This series is based on latest linux-next. The patches are located at: >> https://github.com/davidhildenbrand/linux.git virtio-mem-v2 >> >> I now have acks for all !virtio-mem changes. I'll be happy to get review >> feedback, testing reports,

On 29.03.20 14:42, Michael S. Tsirkin wrote: > On Wed, Mar 11, 2020 at 06:14:12PM +0100, David Hildenbrand wrote: >> This series is based on latest linux-next. The patches are located at: >> https://github.com/davidhildenbrand/linux.git virtio-mem-v2 >> >> I now have acks for all !virtio-mem changes. I'll be happy to get review >> feedback, testing reports,