On Sat, Oct 17, 2020 at 8:44 AM Willy Tarreau wrote:
> On Sat, Oct 17, 2020 at 07:52:48AM +0200, Jann Horn wrote:
> > On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau wrote:
> > > On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> > > > Microsoft's documentation
> > > > (http://go.microsof
On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau wrote:
> On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> > Microsoft's documentation
> > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
> > Generation ID that we get after a fork "is a 128-bit,
> > cryptographically rando
On Sat, Oct 17, 2020 at 6:34 AM Colm MacCarthaigh wrote:
> On 16 Oct 2020, at 21:02, Jann Horn wrote:
> > On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau wrote:
> > But in userspace, we just need a simple counter. There's no need for
> > us to worry about anything else, like timestamps or whatever.
On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau wrote:
> On Sat, Oct 17, 2020 at 03:40:08AM +0200, Jann Horn wrote:
> > [adding some more people who are interested in RNG stuff: Andy, Jason,
> > Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this
> > concerns some pretty fundamental
[adding some more people who are interested in RNG stuff: Andy, Jason,
Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this
concerns some pretty fundamental API stuff related to RNG usage]
On Fri, Oct 16, 2020 at 4:33 PM Catangiu, Adrian Costin
wrote:
> - Background
>
> The VM Gen
On Fri, Oct 16, 2020 at 05:38:26PM +0200, Vlastimil Babka wrote:
> On 10/13/20 10:09 AM, Mike Rapoport wrote:
> > > We are not complaining about TCP using too much memory, but how do
> > > we know that TCP uses a lot of memory. When I firstly face this problem,
> > > I do not know who uses the 25GB
On 10/13/20 10:09 AM, Mike Rapoport wrote:
We are not complaining about TCP using too much memory, but how do
we know that TCP uses a lot of memory. When I firstly face this problem,
I do not know who uses the 25GB memory and it is not shown in the /proc/meminfo.
If we can know the amount memory
On Fri, Oct 16, 2020 at 02:33:15PM +, Catangiu, Adrian Costin wrote:
> +config VMGENID
> + tristate "Virtual Machine Generation ID driver"
> + depends on ACPI
> + default M
Unless this is required to boot a machine, this should be removed.
> + help
> + This is a Virtual
On 16.10.20 10:53, Wei Yang wrote:
> On Mon, Oct 12, 2020 at 02:53:14PM +0200, David Hildenbrand wrote:
>> Let's rename to "sbs_per_mb" and "sb_size" and move accordingly.
>>
>> Cc: "Michael S. Tsirkin"
>> Cc: Jason Wang
>> Cc: Pankaj Gupta
>> Signed-off-by: David Hildenbrand
>
> One trivial s
On 16.10.20 11:38, Wei Yang wrote:
> On Mon, Oct 12, 2020 at 02:53:19PM +0200, David Hildenbrand wrote:
>> Currently, we do not support device block sizes that exceed the Linux
>> memory block size. For example, having a device block size of 1 GiB (e.g.,
>> gigantic pages in the hypervisor) won't w
On Fri, Oct 16, 2020 at 02:19:42PM +0200, Thomas Zimmermann wrote:
> Hi
>
> On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote:
>
> > Hi Thomas.
> >
> > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > > At least sparc64 requires I/O-specific access to framebuffers. Thi
Hi
On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with direct
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_op
Hi
On Fri, 16 Oct 2020 12:58:54 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with direct
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> include/linux/dma-buf-map.h | 7
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_op
Hi Sam
On Fri, 16 Oct 2020 12:08:54 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> > To do framebuffer updates, one needs memcpy from system memory and a
> > pointer-increment function. Add both interfaces with documentation.
> >
>>> Ok, I seems to understand the logic now.
>>>
>>> But how we prevent ONLINE_PARTIAL memory block get offlined? There are three
>>> calls in virtio_mem_set_fake_offline(), while all of them adjust page's
>>> flag.
>>> How they hold reference to struct page?
>>
>> Sorry, I should have given you t
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
Looks good.
Reviewed-by: Sam Ravnborg
Am 15.10.20 um 19:52 schrieb Thomas Zimmermann:
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in
kern
On 16.10.20 06:03, Wei Yang wrote:
> On Mon, Oct 12, 2020 at 02:53:03PM +0200, David Hildenbrand wrote:
>> Let's trigger from offlining code when we're not allowed to touch online
>> memory.
>
> This describes the change in virtio_mem_memory_notifier_cb()?
Ah, yes, can try to make that clearer.
>> That's an interesting corner case. Assume you have a 128MB memory block
>> but only 64MB are plugged.
>
> Since we just plug a part of memory block, this state is OFFLINE_PARTIAL
> first. But then we would add these memory and online it. This means the state
> of this memory block is ONLINE_PAR
On 15.10.20 22:24, Pankaj Gupta wrote:
>> We actually need one byte less (next_mb_id is exclusive, first_mb_id is
>> inclusive). Simplify.
>>
>> Cc: "Michael S. Tsirkin"
>> Cc: Jason Wang
>> Cc: Pankaj Gupta
>> Signed-off-by: David Hildenbrand
>> ---
>> drivers/virtio/virtio_mem.c | 4 ++--
>>
>> Do we adjust the count twice?
>>
>
> Ah, I got the reason why we need to adjust count for *unplugged* sub-blocks.
Exactly.
>
>>> - for (i = 0; i < nr_pages; i++) {
>>> - page = pfn_to_page(pfn + i);
>>> - if (WARN_ON(!page_ref_dec_and_test(page))
24 matches
Mail list logo
