On 20.07.20 16:43, Heiko Carstens wrote:
> On Wed, Jul 15, 2020 at 07:51:27PM +0200, David Hildenbrand wrote:
>>> Regarding documentation (some linked in the cover letter), so far I have
>>> (generic/x86-64)
>>>
>>> 1. https://virtio-mem.gitlab.io/
>>> 2. virtio spec proposal [1]
>>> 3. QEMU 910b25
On Wed, Jul 15, 2020 at 07:51:27PM +0200, David Hildenbrand wrote:
> > Regarding documentation (some linked in the cover letter), so far I have
> > (generic/x86-64)
> >
> > 1. https://virtio-mem.gitlab.io/
> > 2. virtio spec proposal [1]
> > 3. QEMU 910b25766b33 ("virtio-mem: Paravirtualized memor
On 15.07.20 19:38, David Hildenbrand wrote:
> On 15.07.20 18:14, Heiko Carstens wrote:
>> On Wed, Jul 15, 2020 at 01:42:02PM +0200, David Hildenbrand wrote:
So, are you saying that even at IPL time there might already be memory
devices attached to the system? And the kernel should _not_ t
On 15.07.20 18:14, Heiko Carstens wrote:
> On Wed, Jul 15, 2020 at 01:42:02PM +0200, David Hildenbrand wrote:
>>> So, are you saying that even at IPL time there might already be memory
>>> devices attached to the system? And the kernel should _not_ treat them
>>> as normal memory?
>>
>> Sorry if th
On Wed, Jul 15, 2020 at 01:42:02PM +0200, David Hildenbrand wrote:
> > So, are you saying that even at IPL time there might already be memory
> > devices attached to the system? And the kernel should _not_ treat them
> > as normal memory?
>
> Sorry if that was unclear. Yes, we can have such device
On 15.07.20 13:34, Heiko Carstens wrote:
> On Wed, Jul 15, 2020 at 01:21:06PM +0200, David Hildenbrand wrote:
>>> At least in v4.1 the kernel will calculate the max address by using
>>> increment size * increment number and then test if *each* increment is
>>> available with tprot.
>>
>> Yes, we do
On Wed, Jul 15, 2020 at 01:21:06PM +0200, David Hildenbrand wrote:
> > At least in v4.1 the kernel will calculate the max address by using
> > increment size * increment number and then test if *each* increment is
> > available with tprot.
>
> Yes, we do the same in kvm-unit-tests. But it's not su
On 15.07.20 12:43, Heiko Carstens wrote:
> On Wed, Jul 15, 2020 at 11:42:37AM +0200, David Hildenbrand wrote:
>> So, in summary, we want to indicate to the guest a memory region that
>> will be used to place memory devices ("device memory region"). The
>> region might have holes and the memory with
On Wed, Jul 15, 2020 at 11:42:37AM +0200, David Hildenbrand wrote:
> So, in summary, we want to indicate to the guest a memory region that
> will be used to place memory devices ("device memory region"). The
> region might have holes and the memory within this region might have
> different semantic
On 13.07.20 13:08, Christian Borntraeger wrote:
> On 13.07.20 12:27, David Hildenbrand wrote:
>>
>>
>>> Am 13.07.2020 um 11:12 schrieb Heiko Carstens :
>>>
>>> On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
> On 10.07.20 17:18, Heiko Carstens wrote:
> On Fri, Jul 10, 20
On 13.07.20 14:11, Cornelia Huck wrote:
> On Mon, 13 Jul 2020 13:54:41 +0200
> Christian Borntraeger wrote:
>
>> On 10.07.20 10:32, David Hildenbrand wrote:
>>
> --- a/target/s390x/misc_helper.c
> +++ b/target/s390x/misc_helper.c
> @@ -116,6 +116,12 @@ void HELPER(diag)(CPUS390XSta
On Mon, 13 Jul 2020 13:54:41 +0200
Christian Borntraeger wrote:
> On 10.07.20 10:32, David Hildenbrand wrote:
>
> >>> --- a/target/s390x/misc_helper.c
> >>> +++ b/target/s390x/misc_helper.c
> >>> @@ -116,6 +116,12 @@ void HELPER(diag)(CPUS390XState *env, uint32_t r1,
> >>> uint32_t r3, uint32_t
On 10.07.20 10:32, David Hildenbrand wrote:
>>> --- a/target/s390x/misc_helper.c
>>> +++ b/target/s390x/misc_helper.c
>>> @@ -116,6 +116,12 @@ void HELPER(diag)(CPUS390XState *env, uint32_t r1,
>>> uint32_t r3, uint32_t num)
>>> uint64_t r;
>>>
>>> switch (num) {
>>> +case 0x26
On 13.07.20 12:27, David Hildenbrand wrote:
>
>
>> Am 13.07.2020 um 11:12 schrieb Heiko Carstens :
>>
>> On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
On 10.07.20 17:18, Heiko Carstens wrote:
On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
>>
> Am 13.07.2020 um 11:12 schrieb Heiko Carstens :
>
> On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
>>> On 10.07.20 17:18, Heiko Carstens wrote:
>>> On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
> Note: Reading about diag260 subcode 0xc, we could m
On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
> On 10.07.20 17:18, Heiko Carstens wrote:
> > On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
> >>> Note: Reading about diag260 subcode 0xc, we could modify Linux to query
> >>> the maximum possible pfn via diag2
> Am 10.07.2020 um 17:43 schrieb Heiko Carstens :
>
> On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
>>> On 10.07.20 17:18, Heiko Carstens wrote:
>>> On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
> Note: Reading about diag260 subcode 0xc, we could m
On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
> > Note: Reading about diag260 subcode 0xc, we could modify Linux to query
> > the maximum possible pfn via diag260 0xc. Then, we maybe could avoid
> > indicating maxram size via SCLP, and keep diag260-unaware OSs keep
> > working
On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
> On 10.07.20 17:18, Heiko Carstens wrote:
> > On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
> >>> Note: Reading about diag260 subcode 0xc, we could modify Linux to query
> >>> the maximum possible pfn via diag2
On 10.07.20 17:18, Heiko Carstens wrote:
> On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
>>> Note: Reading about diag260 subcode 0xc, we could modify Linux to query
>>> the maximum possible pfn via diag260 0xc. Then, we maybe could avoid
>>> indicating maxram size via SCLP, and
On 10.07.20 11:17, David Hildenbrand wrote:
> On 09.07.20 20:15, David Hildenbrand wrote:
>> On 09.07.20 12:52, Christian Borntraeger wrote:
>>>
>>> On 08.07.20 20:51, David Hildenbrand wrote:
Let's implement the "storage configuration" part of diag260. This diag
is found under z/VM, to i
On Fri, 10 Jul 2020 10:41:33 +0200
David Hildenbrand wrote:
> On 10.07.20 10:32, David Hildenbrand wrote:
> > On 09.07.20 12:37, Cornelia Huck wrote:
> >> On Wed, 8 Jul 2020 20:51:32 +0200
> >> David Hildenbrand wrote:
> >>> diff --git a/target/s390x/misc_helper.c b/target/s390x/misc_helper.
On 09.07.20 20:15, David Hildenbrand wrote:
> On 09.07.20 12:52, Christian Borntraeger wrote:
>>
>> On 08.07.20 20:51, David Hildenbrand wrote:
>>> Let's implement the "storage configuration" part of diag260. This diag
>>> is found under z/VM, to indicate usable chunks of memory tot he guest OS.
>>
On 10.07.20 10:32, David Hildenbrand wrote:
> On 09.07.20 12:37, Cornelia Huck wrote:
>> On Wed, 8 Jul 2020 20:51:32 +0200
>> David Hildenbrand wrote:
>>
>>> Let's implement the "storage configuration" part of diag260. This diag
>>> is found under z/VM, to indicate usable chunks of memory tot he
On 09.07.20 12:37, Cornelia Huck wrote:
> On Wed, 8 Jul 2020 20:51:32 +0200
> David Hildenbrand wrote:
>
>> Let's implement the "storage configuration" part of diag260. This diag
>> is found under z/VM, to indicate usable chunks of memory tot he guest OS.
>> As I don't have access to documentati
On 09.07.20 12:52, Christian Borntraeger wrote:
>
> On 08.07.20 20:51, David Hildenbrand wrote:
>> Let's implement the "storage configuration" part of diag260. This diag
>> is found under z/VM, to indicate usable chunks of memory tot he guest OS.
>> As I don't have access to documentation, I have
On 09.07.20 12:37, Cornelia Huck wrote:
> On Wed, 8 Jul 2020 20:51:32 +0200
> David Hildenbrand wrote:
>
>> Let's implement the "storage configuration" part of diag260. This diag
>> is found under z/VM, to indicate usable chunks of memory tot he guest OS.
>> As I don't have access to documentati
On 08.07.20 20:51, David Hildenbrand wrote:
> Let's implement the "storage configuration" part of diag260. This diag
> is found under z/VM, to indicate usable chunks of memory tot he guest OS.
> As I don't have access to documentation, I have no clue what the actual
> error cases are, and which o
On Wed, 8 Jul 2020 20:51:32 +0200
David Hildenbrand wrote:
> Let's implement the "storage configuration" part of diag260. This diag
> is found under z/VM, to indicate usable chunks of memory tot he guest OS.
> As I don't have access to documentation, I have no clue what the actual
> error cases
Let's implement the "storage configuration" part of diag260. This diag
is found under z/VM, to indicate usable chunks of memory tot he guest OS.
As I don't have access to documentation, I have no clue what the actual
error cases are, and which other stuff we could eventually query using this
interf
30 matches
Mail list logo
