From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Jürgen Groß" <jgross@suse.com>,
xen-devel@lists.xenproject.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Cc: Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, Deep Shah <sdeep@vmware.com>,
"VMware, Inc." <pv-drivers@vmware.com>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL
Date: Mon, 10 Aug 2020 12:53:30 -0400 [thread overview]
Message-ID: <8506b0cd-6f7e-7505-d9b9-e1468cefa4ec@oracle.com> (raw)
In-Reply-To: <4c5fb964-6acb-6bb8-4eff-0bcb67d922f2@suse.com>
On 8/10/20 12:39 AM, Jürgen Groß wrote:
> On 09.08.20 04:34, Boris Ostrovsky wrote:
>> On 8/7/20 4:38 AM, Juergen Gross wrote:
>>> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
>>> {
>>> pteval_t ret;
>>> - if (sizeof(pteval_t) > sizeof(long))
>>> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >>
>>> 32);
>>> - else
>>> - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>>> + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>>> return (pte_t) { .pte = ret };
>>
>>
>> Can this now simply return (pte_t) ret?
>
> I don't think so, but I can turn it into
>
> return native_make_pte(PVOP_CALLEE1(...));
I thought that since now this is only built for 64-bit we don't have to
worry about different pte_t definitions and can do what we do for
example, for __pgd()?
-boris
WARNING: multiple messages have this Message-ID (diff)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Jürgen Groß" <jgross@suse.com>,
xen-devel@lists.xenproject.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
"VMware, Inc." <pv-drivers@vmware.com>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL
Date: Mon, 10 Aug 2020 12:53:30 -0400 [thread overview]
Message-ID: <8506b0cd-6f7e-7505-d9b9-e1468cefa4ec@oracle.com> (raw)
In-Reply-To: <4c5fb964-6acb-6bb8-4eff-0bcb67d922f2@suse.com>
On 8/10/20 12:39 AM, Jürgen Groß wrote:
> On 09.08.20 04:34, Boris Ostrovsky wrote:
>> On 8/7/20 4:38 AM, Juergen Gross wrote:
>>> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
>>> {
>>> pteval_t ret;
>>> - if (sizeof(pteval_t) > sizeof(long))
>>> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >>
>>> 32);
>>> - else
>>> - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>>> + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>>> return (pte_t) { .pte = ret };
>>
>>
>> Can this now simply return (pte_t) ret?
>
> I don't think so, but I can turn it into
>
> return native_make_pte(PVOP_CALLEE1(...));
I thought that since now this is only built for 64-bit we don't have to
worry about different pte_t definitions and can do what we do for
example, for __pgd()?
-boris
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
WARNING: multiple messages have this Message-ID (diff)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Jürgen Groß" <jgross@suse.com>,
xen-devel@lists.xenproject.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Deep Shah <sdeep@vmware.com>,
"VMware, Inc." <pv-drivers@vmware.com>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL
Date: Mon, 10 Aug 2020 12:53:30 -0400 [thread overview]
Message-ID: <8506b0cd-6f7e-7505-d9b9-e1468cefa4ec@oracle.com> (raw)
In-Reply-To: <4c5fb964-6acb-6bb8-4eff-0bcb67d922f2@suse.com>
On 8/10/20 12:39 AM, Jürgen Groß wrote:
> On 09.08.20 04:34, Boris Ostrovsky wrote:
>> On 8/7/20 4:38 AM, Juergen Gross wrote:
>>> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
>>> {
>>> pteval_t ret;
>>> - if (sizeof(pteval_t) > sizeof(long))
>>> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >>
>>> 32);
>>> - else
>>> - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>>> + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>>> return (pte_t) { .pte = ret };
>>
>>
>> Can this now simply return (pte_t) ret?
>
> I don't think so, but I can turn it into
>
> return native_make_pte(PVOP_CALLEE1(...));
I thought that since now this is only built for 64-bit we don't have to
worry about different pte_t definitions and can do what we do for
example, for __pgd()?
-boris
next prev parent reply other threads:[~2020-08-10 16:54 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 8:38 [PATCH v3 0/7] Remove 32-bit Xen PV guest support Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-07 8:38 ` [PATCH v3 1/7] x86/xen: remove " Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-09 2:01 ` Boris Ostrovsky
2020-08-09 2:01 ` Boris Ostrovsky
2020-08-10 4:36 ` Jürgen Groß
2020-08-10 4:36 ` Jürgen Groß
2020-08-07 8:38 ` [PATCH v3 2/7] x86/xen: eliminate xen-asm_64.S Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-09 2:04 ` Boris Ostrovsky
2020-08-09 2:04 ` Boris Ostrovsky
2020-08-10 4:36 ` Jürgen Groß
2020-08-10 4:36 ` Jürgen Groß
2020-08-07 8:38 ` [PATCH v3 3/7] x86/xen: drop tests for highmem in pv code Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-07 11:18 ` kernel test robot
2020-08-07 11:18 ` kernel test robot
2020-08-07 11:18 ` kernel test robot
2020-08-09 2:22 ` Boris Ostrovsky
2020-08-09 2:22 ` Boris Ostrovsky
2020-08-10 4:37 ` Jürgen Groß
2020-08-10 4:37 ` Jürgen Groß
2020-08-07 8:38 ` [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-07 9:39 ` peterz
2020-08-07 9:39 ` peterz
2020-08-07 9:39 ` peterz
2020-08-07 10:02 ` Jürgen Groß
2020-08-07 10:02 ` Jürgen Groß
2020-08-07 10:02 ` Jürgen Groß
2020-08-07 10:21 ` peterz
2020-08-07 10:21 ` peterz
2020-08-07 10:21 ` peterz
2020-08-09 2:34 ` Boris Ostrovsky
2020-08-09 2:34 ` Boris Ostrovsky
2020-08-09 2:34 ` Boris Ostrovsky
2020-08-10 4:39 ` Jürgen Groß
2020-08-10 4:39 ` Jürgen Groß
2020-08-10 4:39 ` Jürgen Groß
2020-08-10 16:53 ` Boris Ostrovsky [this message]
2020-08-10 16:53 ` Boris Ostrovsky
2020-08-10 16:53 ` Boris Ostrovsky
2020-08-10 18:42 ` Jürgen Groß
2020-08-10 18:42 ` Jürgen Groß
2020-08-10 18:42 ` Jürgen Groß
2020-08-07 8:38 ` [PATCH v3 5/7] x86/paravirt: cleanup paravirt macros Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-07 8:38 ` [PATCH v3 6/7] x86/paravirt: use CONFIG_PARAVIRT_XXL instead of CONFIG_PARAVIRT Juergen Gross
2020-08-07 8:38 ` Juergen Gross
2020-08-07 8:38 ` [PATCH v3 7/7] x86/entry/32: revert "Fix XEN_PV build dependency" Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8506b0cd-6f7e-7505-d9b9-e1468cefa4ec@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pv-drivers@vmware.com \
--cc=sdeep@vmware.com \
--cc=sstabellini@kernel.org \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.