On Sat, Oct 17, 2020 at 09:39:38AM +0200, David Hildenbrand wrote:
>
>> Am 17.10.2020 um 00:38 schrieb Wei Yang :
>>
>> On Fri, Oct 16, 2020 at 12:32:50PM +0200, David Hildenbrand wrote:
>> Ok, I seems to understand the logic now.
>>
>> But how we prevent ONLINE_PARTIAL memory block
> Am 17.10.2020 um 00:38 schrieb Wei Yang :
>
> On Fri, Oct 16, 2020 at 12:32:50PM +0200, David Hildenbrand wrote:
> Ok, I seems to understand the logic now.
>
> But how we prevent ONLINE_PARTIAL memory block get offlined? There are
> three
> calls in
On Mon, Oct 12, 2020 at 02:52:59PM +0200, David Hildenbrand wrote:
>Let's check by traversing busy system RAM resources instead, to avoid
>relying on memory block states.
>
>Don't use walk_system_ram_range(), as that works on pages and we want to
>use the bare addresses we have easily at hand.
>
On Fri, Oct 16, 2020 at 12:32:50PM +0200, David Hildenbrand wrote:
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.
>>> 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
On Fri, Oct 16, 2020 at 11:11:24AM +0200, David Hildenbrand wrote:
>>> 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
>> 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
On Thu, Oct 15, 2020 at 10:50:27AM +0200, David Hildenbrand wrote:
[...]
>>
>>> dev_warn(>dev, "device still has system memory added\n");
>>> } else {
>>> virtio_mem_delete_resource(vm);
>>
>> BTW, I got one question during review.
>>
>> Per my understanding, there
On 15.10.20 10:28, Wei Yang wrote:
> On Mon, Oct 12, 2020 at 02:52:59PM +0200, David Hildenbrand wrote:
>> Let's check by traversing busy system RAM resources instead, to avoid
>> relying on memory block states.
>>
>> Don't use walk_system_ram_range(), as that works on pages and we want to
>> use
On Mon, Oct 12, 2020 at 02:52:59PM +0200, David Hildenbrand wrote:
>Let's check by traversing busy system RAM resources instead, to avoid
>relying on memory block states.
>
>Don't use walk_system_ram_range(), as that works on pages and we want to
>use the bare addresses we have easily at hand.
>
Let's check by traversing busy system RAM resources instead, to avoid
relying on memory block states.
Don't use walk_system_ram_range(), as that works on pages and we want to
use the bare addresses we have easily at hand.
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Pankaj Gupta
Signed-off-by:
11 matches
Mail list logo