search for: 05.02.20

On 05.02.20 10:49, Wang, Wei W wrote: > On Wednesday, February 5, 2020 5:37 PM, David Hildenbrand wrote: >>> >>> Not sure how TCG tracks the dirty bits. But In whatever >>> implementation, the hypervisor should have >> >> There is only a single bitmap for that purpose. (well, the one where KVM >> syncs to) >> >>> already dealt with the

On 05.02.20 10:49, Wang, Wei W wrote: > On Wednesday, February 5, 2020 5:37 PM, David Hildenbrand wrote: >>> >>> Not sure how TCG tracks the dirty bits. But In whatever >>> implementation, the hypervisor should have >> >> There is only a single bitmap for that purpose. (well, the one where KVM >> syncs to) >> >>> already dealt with the

On 05.02.20 10:35, Wang, Wei W wrote: > On Wednesday, February 5, 2020 5:23 PM, David Hildenbrand wrote: >> So, if you run a TCG guest and use it with free page reporting, the race is >> possible? So the correctness depends on two dirty bitmaps in the hypervisor >> and how they interact. wow this is fragile. >> > > Not sure how TCG tracks the dirty bits. But In

On 05.02.20 10:35, Wang, Wei W wrote: > On Wednesday, February 5, 2020 5:23 PM, David Hildenbrand wrote: >> So, if you run a TCG guest and use it with free page reporting, the race is >> possible? So the correctness depends on two dirty bitmaps in the hypervisor >> and how they interact. wow this is fragile. >> > > Not sure how TCG tracks the dirty bits. But In

On Wed, Feb 05, 2020 at 09:19:58AM +0100, David Hildenbrand wrote: > On 05.02.20 08:35, Nadav Amit wrote: > >> On Feb 3, 2020, at 2:50 PM, Nadav Amit <namit at vmware.com> wrote: > >> > >>> On Feb 3, 2020, at 8:34 AM, David Hildenbrand <david at redhat.com> wrote: > >>> > >>> On 03.02.20 17:18, Alexander Duyck wrote: >

On 05.02.20 09:54, Wang, Wei W wrote: > On Wednesday, February 5, 2020 4:19 PM, David Hildenbrand wrote: >> Yes, I agree with you. Yet, I am thinking about one >> (unlikely?impossible?) scenario. Can you refresh my brain why that cannot >> happen (IOW, why we don't have to wait for the host to process the >> request)? >> >> 1. Guest allocates a page and

On 05.02.20 09:54, Wang, Wei W wrote: > On Wednesday, February 5, 2020 4:19 PM, David Hildenbrand wrote: >> Yes, I agree with you. Yet, I am thinking about one >> (unlikely?impossible?) scenario. Can you refresh my brain why that cannot >> happen (IOW, why we don't have to wait for the host to process the >> request)? >> >> 1. Guest allocates a page and

On 05.02.20 17:34, David Hildenbrand wrote: > Commit 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") > changed the behavior when deflation happens automatically. Instead of > deflating when called by the OOM handler, the shrinker is used. > > However, the balloon is not simply some slab cache that should be > shrunk when under memory pressure. The

On 05.02.20 17:34, David Hildenbrand wrote: > Commit 71994620bb25 ("virtio_balloon: replace oom notifier with shrinker") > changed the behavior when deflation happens automatically. Instead of > deflating when called by the OOM handler, the shrinker is used. > > However, the balloon is not simply some slab cache that should be > shrunk when under memory pressure. The

virtio has its own commit fail function. Add the drm_atomic_helper_fake_vblank() call there. Fixes: 2a735ad3d211 ("drm/virtio: Remove sending of vblank event") Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c

On Wed, Feb 05, 2020 at 10:58:14AM +0100, David Hildenbrand wrote: > On 05.02.20 10:49, Wang, Wei W wrote: > > On Wednesday, February 5, 2020 5:37 PM, David Hildenbrand wrote: > >>> > >>> Not sure how TCG tracks the dirty bits. But In whatever > >>> implementation, the hypervisor should have > >> > >> There is only a single bitmap for

Hi folks, I do see some updates coming in for RHEL8.1 and wonder why some are not coming into current C8 (latency already included)? Are there any staging? Koji shows such packages as finished/complete... -- Leon

> On Feb 3, 2020, at 2:50 PM, Nadav Amit <namit at vmware.com> wrote: > >> On Feb 3, 2020, at 8:34 AM, David Hildenbrand <david at redhat.com> wrote: >> >> On 03.02.20 17:18, Alexander Duyck wrote: >>> On Mon, 2020-02-03 at 08:11 -0500, Michael S. Tsirkin wrote: >>>> On Thu, Jan 30, 2020 at 11:59:46AM -0800, Tyler Sanderson wrote:

> On Feb 3, 2020, at 2:50 PM, Nadav Amit <namit at vmware.com> wrote: > >> On Feb 3, 2020, at 8:34 AM, David Hildenbrand <david at redhat.com> wrote: >> >> On 03.02.20 17:18, Alexander Duyck wrote: >>> On Mon, 2020-02-03 at 08:11 -0500, Michael S. Tsirkin wrote: >>>> On Thu, Jan 30, 2020 at 11:59:46AM -0800, Tyler Sanderson wrote:

>> Issue 2: When called via the shrinker, (but also to fix Issue 1), it could be that >> we do have VIRTIO_BALLOON_F_MUST_TELL_HOST. > > I don't think it is an issue here. > MUST_TELL_HOST is for the ballooning pages, where pages are offered to host to _USE_. > For free page hint, as the name already suggests, it's just a _HINT_ , so in whatever use case, > the

>> Issue 2: When called via the shrinker, (but also to fix Issue 1), it could be that >> we do have VIRTIO_BALLOON_F_MUST_TELL_HOST. > > I don't think it is an issue here. > MUST_TELL_HOST is for the ballooning pages, where pages are offered to host to _USE_. > For free page hint, as the name already suggests, it's just a _HINT_ , so in whatever use case, > the

On 05.02.20 08:35, Nadav Amit wrote: >> On Feb 3, 2020, at 2:50 PM, Nadav Amit <namit at vmware.com> wrote: >> >>> On Feb 3, 2020, at 8:34 AM, David Hildenbrand <david at redhat.com> wrote: >>> >>> On 03.02.20 17:18, Alexander Duyck wrote: >>>> On Mon, 2020-02-03 at 08:11 -0500, Michael S. Tsirkin wrote: >>>>> On Thu,

On 05.02.20 10:00, Wang, Wei W wrote: > On Wednesday, February 5, 2020 4:57 PM, David Hildenbrand wrote: >>>> Yes, I agree with you. Yet, I am thinking about one >>>> (unlikely?impossible?) scenario. Can you refresh my brain why that >>>> cannot happen (IOW, why we don't have to wait for the host to process >>>> the request)? >>>>

On 05.02.20 10:00, Wang, Wei W wrote: > On Wednesday, February 5, 2020 4:57 PM, David Hildenbrand wrote: >>>> Yes, I agree with you. Yet, I am thinking about one >>>> (unlikely?impossible?) scenario. Can you refresh my brain why that >>>> cannot happen (IOW, why we don't have to wait for the host to process >>>> the request)? >>>>

>> 1. Guest allocates a page and sends it to the host. >> 2. Shrinker gets active and releases that page again. >> 3. Some user in the guest allocates and modifies that page. The dirty bit is >> set in the hypervisor. > > The bit will be set in KVM's bitmap, and will be synced to QEMU's bitmap when the next round starts. > >> 4. The host processes