On 5/15/23 01:19, Hou Wenlong wrote:
> This patchset unifies FIXADDR_TOP as a variable for x86, allowing the
> fixmap area to be movable and relocated with the kernel image in the
> x86/PIE patchset [0]. This enables the kernel image to be relocated in
> the top 512G of the address space.
What
On 5/16/23 12:35, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This addresses all x86 specific prototype warnings. The majority of the
> patches should be straightforward, either adding an #include statement
> to get the right header, or ensuring that an unused global function is
> left out of
On 5/16/23 12:35, Arnd Bergmann wrote:
> The ones that are a bit awkward are those that just add a prototype to
> shut up the warning, but the prototypes are never used for calling the
> function because the only caller is in assembler code. I tried to come up
> with other ways to shut up the
On 5/16/23 12:35, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> arch/x86/xen/enlighten_pv.c:1233:34: error: no previous prototype for
> 'xen_start_kernel' [-Werror=missing-prototypes]
> arch/x86/xen/irq.c:22:14: error: no previous prototype for
> 'xen_force_evtchn_callback'
On 9/13/21 9:14 AM, Joerg Roedel wrote:
> On Mon, Sep 13, 2021 at 09:02:38AM -0700, Dave Hansen wrote:
>> On 9/13/21 8:55 AM, Joerg Roedel wrote:
>>> This does not work under SEV-ES, because the hypervisor has no access
>>> to the vCPU registers and can't make modificat
On 9/13/21 8:55 AM, Joerg Roedel wrote:
> This does not work under SEV-ES, because the hypervisor has no access
> to the vCPU registers and can't make modifications to them. So an
> SEV-ES guest needs to reset the vCPU itself and park it using the
> AP-reset-hold protocol. Upon wakeup the guest
On 5/12/21 1:37 AM, 'Joerg Roedel' wrote:
> I also thought about adding page_fault_disable()/page_fault_enable()
> calls, but being in atomic context is enough according to the
> faulthandler_disabled() implementation.
That would be nice to add to a comment:
On 5/12/21 12:54 AM, Joerg Roedel wrote:
> The put_user() and get_user() functions do checks on the address which is
> passed to them. They check whether the address is actually a user-space
> address and whether its fine to access it. They also call might_fault()
> to indicate that they could
On 2/10/21 2:21 AM, Joerg Roedel wrote:
> + /* Store to memory and keep it in the registers */
> + movl%eax, rva(sev_check_data)(%ebp)
> + movl%ebx, rva(sev_check_data+4)(%ebp)
> +
> + /* Enable paging to see if encryption is active */
> + movl%cr0, %edx /*
On 2/10/21 2:21 AM, Joerg Roedel wrote:
> +1: rdrand %eax
> + jnc 1b
> +2: rdrand %ebx
> + jnc 2b
> +
> + /* Store to memory and keep it in the registers */
> + movl%eax, rva(sev_check_data)(%ebp)
> + movl%ebx, rva(sev_check_data+4)(%ebp)
> +
> + /*
On 1/4/21 12:11 PM, David Hildenbrand wrote:
>> Yeah, it certainly can't be the default, but it *is* useful for
>> thing where we know that there are no cache benefits to zeroing
>> close to where the memory is allocated.
>>
>> The trick is opting into it somehow, either in a process or a VMA.
>>
On 1/4/21 11:27 AM, Matthew Wilcox wrote:
> On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote:
>> On 12/21/20 8:30 AM, Liang Li wrote:
>>> --- a/include/linux/page-flags.h
>>> +++ b/include/linux/page-flags.h
>>> @@ -137,6 +137,9 @@ enum pageflags {
On 12/21/20 8:30 AM, Liang Li wrote:
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -137,6 +137,9 @@ enum pageflags {
> #endif
> #ifdef CONFIG_64BIT
> PG_arch_2,
> +#endif
> +#ifdef CONFIG_PREZERO_PAGE
> + PG_zero,
> #endif
> __NR_PAGEFLAGS,
I don't
On 6/23/20 8:52 AM, Peter Zijlstra wrote:
> Isn't current #MC unconditionally fatal from kernel? But yes, I was
> sorta aware people want that changed.
Not unconditionally. copy_to_iter_mcsafe() is a good example of one
thing we _can_ handle.
___
On 4/30/20 8:52 AM, David Hildenbrand wrote:
>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.
>
> I'd love to get Dan's, Dave's and
* MHP_NO_FIRMWARE_MEMMAP ensures that future
* kexec'd kernels will not treat this as RAM.
*/
Not a biggie, though.
Acked-by: Dave Hansen
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 4/25/20 5:49 AM, Joerg Roedel wrote:
>> That's a fun point because it means that the (untrusted) hypervisor can
>> cause endless faults. I *guess* we have mitigation for this with our
>> stack guard pages, but it's still a bit nasty that the hypervisor can
>> arbitrarily land a guest in the
On 4/24/20 2:27 PM, Tom Lendacky wrote:
> On 4/24/20 4:24 PM, Dave Hansen wrote:
>> On 4/24/20 2:03 PM, Mike Stunes wrote:
>>> I needed to allow RDTSC(P) from userspace and in early boot in order to
>>> get userspace started properly. Patch below.
>>>
>>&g
On 4/24/20 2:03 PM, Mike Stunes wrote:
> I needed to allow RDTSC(P) from userspace and in early boot in order to
> get userspace started properly. Patch below.
>
> ---
> SEV-ES guests will need to execute rdtsc and rdtscp from userspace and
> during early boot. Move the rdtsc(p) #VC handler into
On 4/14/20 1:04 PM, Tom Lendacky wrote:
>> set_memory_decrypted needs to check the return value. I see it
>> consistently return ENOMEM. I've traced that back to split_large_page
>> in arch/x86/mm/pat/set_memory.c.
>
> At that point the guest won't be able to communicate with the
> hypervisor,
On 3/20/20 3:12 PM, Joerg Roedel wrote:
> On Fri, Mar 20, 2020 at 02:02:13PM -0700, Dave Hansen wrote:
>> It *never* flushes global pages. For a generic function like this, that
>> seems pretty dangerous because the PTEs it goes after could quite easily
>> be Global. It's
On 3/20/20 1:53 PM, David Rientjes wrote:
>> +
>> +/* Clear encryption flag and write new pte */
>> +pte = pte_clear_flags(*ptep, _PAGE_ENC);
>> +set_pte(ptep, pte);
>> +
>> +/* Flush TLB to map the page unencrypted */
>> +write_cr3(top_level_pgt);
>> +
> Is there a guarantee
On 3/20/20 6:17 AM, Joerg Roedel wrote:
> On Thu, Mar 19, 2020 at 08:35:59AM -0700, Andy Lutomirski wrote:
>> 1. Just put the NMI unmask in do_nmi(). The kernel *already* knows
>> how to handle running do_nmi() with NMIs unmasked. This is much, much
>> simpler than your code.
> Okay, attached is
On 2/13/20 11:23 PM, Joerg Roedel wrote:
> Yes, investigating this is on the list for future optimizations (besides
> caching CPUID results). My idea is to use alternatives patching for
> this. But the exception handling is needed anyway because #VC
> exceptions happen very early already,
On 2/11/20 5:52 AM, Joerg Roedel wrote:
> Implement a handler for #VC exceptions caused by RDMSR/WRMSR
> instructions.
As a general comment on all of these event handlers: Why do we bother
having the hypercalls in the interrupt handler as opposed to just
calling them directly. What you have is:
the
separating out "is_lazy" compares to the "check before setting"
optimization. But, they're both sane enough on their own that I'm not
too worried.
I had some nits that I hope get covered in later revisions, if sent.
But, overall looks fine. For the series:
Revi
On 6/25/19 7:35 PM, Nadav Amit wrote:
>>> const struct flush_tlb_info *f = info;
>>> + enum tlb_flush_reason reason;
>>> +
>>> + reason = (f->mm == NULL) ? TLB_LOCAL_SHOOTDOWN : TLB_LOCAL_MM_SHOOTDOWN;
>>
>> Should we just add the "reason" to flush_tlb_info? It's OK-ish to imply
>> it
hen Hemminger
> Cc: Sasha Levin
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: x...@kernel.org
> Cc: Juergen Gross
> Cc: Paolo Bonzini
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Cc: Boris Ostrovsky
> Cc: li
On 06/13/2017 10:56 AM, Michael S. Tsirkin wrote:
>> +/* The size of one page_bmap used to record inflated/deflated pages. */
>> +#define VIRTIO_BALLOON_PAGE_BMAP_SIZE (8 * PAGE_SIZE)
> At this size, you probably want alloc_pages to avoid kmalloc
> overhead.
For slub, at least, kmalloc()
On 06/12/2017 01:34 PM, Michael S. Tsirkin wrote:
> On Mon, Jun 12, 2017 at 09:42:36AM -0700, Dave Hansen wrote:
>> On 06/12/2017 09:28 AM, Michael S. Tsirkin wrote:
>>>
>>>> The hypervisor is going to throw away the contents of these pages,
>>>> right?
&g
On 06/12/2017 09:28 AM, Michael S. Tsirkin wrote:
>
>> The hypervisor is going to throw away the contents of these pages,
>> right?
> It should be careful and only throw away contents that was there before
> report_unused_page_block was invoked. Hypervisor is responsible for not
> corrupting
Please stop cc'ing me on things also sent to closed mailing lists
(virtio-...@lists.oasis-open.org). I'm happy to review things on open
lists, but I'm not fond of the closed lists bouncing things at me.
On 06/09/2017 03:41 AM, Wei Wang wrote:
> Add a function to find a page block on the free
On 06/09/2017 03:41 AM, Wei Wang wrote:
> + for_each_populated_zone(zone) {
> + for (order = MAX_ORDER - 1; order > 0; order--) {
> + for (migratetype = 0; migratetype < MIGRATE_TYPES;
> + migratetype++) {
> +
On 12/15/2016 05:38 PM, Li, Liang Z wrote:
>
> Use 52 bits for 'pfn', 12 bits for 'length', when the 12 bits is not long
> enough for the 'length'
> Set the 'length' to a special value to indicate the "actual length in next 8
> bytes".
>
> That will be much more simple. Right?
Sounds fine to
On 12/15/2016 04:48 PM, Li, Liang Z wrote:
>>> It seems we leave too many bit for the pfn, and the bits leave for
>>> length is not enough, How about keep 45 bits for the pfn and 19 bits
>>> for length, 45 bits for pfn can cover 57 bits physical address, that should
>>> be
>> enough in the near
On 12/14/2016 12:59 AM, Li, Liang Z wrote:
>> Subject: Re: [Qemu-devel] [PATCH kernel v5 0/5] Extend virtio-balloon for
>> fast (de)inflating & fast live migration
>>
>> On 12/08/2016 08:45 PM, Li, Liang Z wrote:
>>> What's the conclusion of your discussion? It seems you want some
>>> statistic
On 12/08/2016 08:45 PM, Li, Liang Z wrote:
> What's the conclusion of your discussion? It seems you want some
> statistic before deciding whether to ripping the bitmap from the
> ABI, am I right?
I think Andrea and David feel pretty strongly that we should remove the
bitmap, unless we have some
07, 2016 at 08:57:01AM -0800, Dave Hansen wrote:
>> It is more space-efficient. We're fitting the order into 6 bits, which
>> would allows the full 2^64 address space to be represented in one entry,
>
> Very large order is the same as very large len, 6 bits of order or 8
> b
On 12/07/2016 10:38 AM, Andrea Arcangeli wrote:
>> > and leaves room for the bitmap size to be encoded as well, if we decide
>> > we need a bitmap in the future.
> How would a bitmap ever be useful with very large page-order?
Please, guys. Read the patches. *Please*.
The current code doesn't
Removing silly virtio-dev@ list because it's bouncing mail...
On 12/07/2016 08:21 AM, David Hildenbrand wrote:
>> Li's current patches do that. Well, maybe not pfn/length, but they do
>> take a pfn and page-order, which fits perfectly with the kernel's
>> concept of high-order pages.
>
> So we
On 12/07/2016 07:42 AM, David Hildenbrand wrote:
> Am 07.12.2016 um 14:35 schrieb Li, Liang Z:
>>> Am 30.11.2016 um 09:43 schrieb Liang Li:
This patch set contains two parts of changes to the virtio-balloon.
One is the change for speeding up the inflating & deflating process,
On 12/07/2016 05:35 AM, Li, Liang Z wrote:
>> Am 30.11.2016 um 09:43 schrieb Liang Li:
>> IOW in real examples, do we have really large consecutive areas or are all
>> pages just completely distributed over our memory?
>
> The buddy system of Linux kernel memory management shows there should
> be
On 12/04/2016 05:13 AM, Li, Liang Z wrote:
>> On 11/30/2016 12:43 AM, Liang Li wrote:
>>> +static void send_unused_pages_info(struct virtio_balloon *vb,
>>> + unsigned long req_id)
>>> +{
>>> + struct scatterlist sg_in;
>>> + unsigned long pos = 0;
>>> + struct
On 11/30/2016 12:43 AM, Liang Li wrote:
> +static void send_unused_pages_info(struct virtio_balloon *vb,
> + unsigned long req_id)
> +{
> + struct scatterlist sg_in;
> + unsigned long pos = 0;
> + struct virtqueue *vq = vb->req_vq;
> + struct
On 11/07/2016 09:50 PM, Li, Liang Z wrote:
> Sounds good. Should we ignore some of the order-0 pages in step 4 if the
> bitmap is full?
> Or should retry to get a complete list of order-0 pages?
I think that's a pretty reasonable thing to do.
>>> It seems the benefit we get for this feature is
On 11/06/2016 07:37 PM, Li, Liang Z wrote:
>> Let's say we do a 32k bitmap that can hold ~1M pages. That's 4GB of RAM.
>> On a 1TB system, that's 256 passes through the top-level loop.
>> The bottom-level lists have tens of thousands of pages in them, even on my
>> laptop. Only 1/256 of these
Please squish this and patch 5 together. It makes no sense to separate
them.
> +static void send_unused_pages_info(struct virtio_balloon *vb,
> + unsigned long req_id)
> +{
> + struct scatterlist sg_in;
> + unsigned long pfn = 0, bmap_len, pfn_limit, last_pfn,
On 10/26/2016 03:13 AM, Li, Liang Z wrote:
> 3 times memory required is not accurate, please ignore this. sorry ...
> The complexity is the point.
What is making it so complex? Can you describe the problems?
___
Virtualization mailing list
On 10/26/2016 03:06 AM, Li, Liang Z wrote:
> I am working on Dave's new bitmap schema, I have finished the part of
> getting the 'hybrid scheme bitmap' and found the complexity was more
> than I expected. The main issue is more memory is required to save
> the 'hybrid scheme bitmap' beside that
On 10/20/2016 11:24 PM, Liang Li wrote:
> Expose the function to get the max pfn, so it can be used in the
> virtio-balloon device driver. Simply include the 'linux/bootmem.h'
> is not enough, if the device driver is built to a module, directly
> refer the max_pfn lead to build failed.
I'm not
On 10/20/2016 11:24 PM, Liang Li wrote:
> Add a new feature which supports sending the page information with
> a bitmap. The current implementation uses PFNs array, which is not
> very efficient. Using bitmap can improve the performance of
> inflating/deflating significantly
Why is it not
On 10/20/2016 11:24 PM, Liang Li wrote:
> Will allow faster notifications using a bitmap down the road.
> balloon_pfn_to_page() can be removed because it's useless.
This is a pretty terse description of what's going on here. Could you
try to elaborate a bit? What *is* the current approach? Why
On 10/20/2016 11:24 PM, Liang Li wrote:
> Dave Hansen suggested a new scheme to encode the data structure,
> because of additional complexity, it's not implemented in v3.
So, what do you want done with this patch set? Do you want it applied
as-is so that we can introduce a new host/gue
On 08/07/2016 11:35 PM, Liang Li wrote:
> Dave Hansen suggested a new scheme to encode the data structure,
> because of additional complexity, it's not implemented in v3.
FWIW, I don't think it takes any additional complexity here, at least in
the guest implementation side. The thing I sug
On 07/28/2016 02:51 PM, Michael S. Tsirkin wrote:
>> > If 1MB is too big, how about 512K, or 256K? 32K seems too small.
>> >
> It's only small because it makes you rescan the free list.
> So maybe you should do something else.
> I looked at it a bit. Instead of scanning the free list, how about
On 07/27/2016 03:08 PM, Michael S. Tsirkin wrote:
>> > +unsigned long get_max_pfn(void)
>> > +{
>> > + return max_pfn;
>> > +}
>> > +EXPORT_SYMBOL(get_max_pfn);
>> > +
>
> This needs a coment that this can change at any time.
> So it's only good as a hint e.g. for sizing data structures.
Or, if
On 07/27/2016 03:05 PM, Michael S. Tsirkin wrote:
> On Wed, Jul 27, 2016 at 09:40:56AM -0700, Dave Hansen wrote:
>> On 07/26/2016 06:23 PM, Liang Li wrote:
>>> + for_each_migratetype_order(order, t) {
>>> + list_for_each(curr, &g
On 07/26/2016 06:23 PM, Liang Li wrote:
> + for_each_migratetype_order(order, t) {
> + list_for_each(curr, >free_area[order].free_list[t]) {
> + pfn = page_to_pfn(list_entry(curr, struct page, lru));
> + if (pfn >= start_pfn && pfn <=
On 07/26/2016 06:23 PM, Liang Li wrote:
> + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT;
> + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn());
> + vb->bmap_len = ALIGN(vb->pfn_limit, BITS_PER_LONG) /
> + BITS_PER_BYTE + 2 * sizeof(unsigned long);
> + hdr_len =
On 02/22/2013 08:55 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
Hi Linus,
This is a huge set of several partly interrelated (and concurrently
developed) changes, which is why the branch history is messier than
one would like.
The
On Tue, 2011-04-12 at 22:13 +0530, Amit Shah wrote:
On (Tue) 12 Apr 2011 [09:22:32], Dave Hansen wrote:
On Tue, 2011-04-12 at 11:13 +0530, Amit Shah wrote:
Sure, the only contention was on the commit message, where you stated
modern qemus set this... qemu doesn't, and it should. Care
On Thu, 2011-04-14 at 21:07 +0930, Rusty Russell wrote:
On Tue, 12 Apr 2011 09:22:32 -0700, Dave Hansen d...@linux.vnet.ibm.com
wrote:
On Tue, 2011-04-12 at 11:13 +0530, Amit Shah wrote:
Sure, the only contention was on the commit message, where you stated
modern qemus set this... qemu
after the pages are freed, which should let us get rid of some
temporary storage (vb-pfns) eventually.
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
-- Dave
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux
On Mon, 2011-04-11 at 14:01 +0300, Michael S. Tsirkin wrote:
On Thu, Apr 07, 2011 at 10:43:25AM -0700, Dave Hansen wrote:
The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST
feature bit. Whenever the bit is set, we must always tell the
host before we free pages back
are freed, which should let us get rid of some
temporary storage (vb-pfns) eventually.
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
---
linux-2.6.git-dave/drivers/virtio/virtio_balloon.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff -puN drivers
On Sun, 2009-03-29 at 16:12 +0200, Martin Schwidefsky wrote:
Can we persuade the hypervisor to tell us which pages it decided to page
out and just skip those when we're scanning the LRU?
One principle of the whole approach is that the hypervisor does not
call into an otherwise idle guest.
On Wed, 2008-08-06 at 15:41 +0900, Fernando Luis Vázquez Cao wrote:
I agree with your plan.
We keep bio-cgroup improving and porting to the latest kernel.
Having more users of bio-cgroup would probably help to get it merged, so
we'll certainly send patches as soon as we get our cfq prototype
On Wed, 2008-08-06 at 22:12 +0530, Balbir Singh wrote:
Would you like to split up IO into read and write IO. We know that read can be
very latency sensitive when compared to writes. Should we consider them
separately in the RFC?
I'd just suggest doing what is simplest and can be done in the
On Mon, 2008-08-04 at 22:55 -0700, Paul Menage wrote:
As Dave suggested, I think it would make more sense to have your
page-dirtying throttle points hook into the memory controller instead,
and allow the memory controller to track/limit dirty pages for a
cgroup, and potentially do throttling
On Tue, 2008-08-05 at 11:28 +0200, Andrea Righi wrote:
Buffered write I/O is also related with cache system.
We must consider this problem as I/O control.
Agree. At least, maybe we should consider if an IO controller could be
a valid solution also for these problems.
Isn't this one of the
On Mon, 2008-08-04 at 17:51 +0900, Ryo Tsuruta wrote:
This series of patches of dm-ioband now includes The bio tracking mechanism,
which has been posted individually to this mailing list.
This makes it easy for anybody to control the I/O bandwidth even when
the I/O is one of delayed-write
On Mon, 2008-08-04 at 20:22 +0200, Andrea Righi wrote:
But I'm not yet convinced that limiting the IO writes at the device
mapper layer is the best solution. IMHO it would be better to throttle
applications' writes when they're dirtying pages in the page cache (the
io-throttle way), because
On Sat, 2008-07-26 at 14:25 +1000, Nick Piggin wrote:
Google I think and maybe IBM (can't remember) is using the proc pagemap
interfaces to help with this. Probably it is super secret code that can't
be released though -- but it gives you somewhere to look.
Nobody at IBM that I know. :) I
On Thu, 2008-03-20 at 10:28 -0700, Jeremy Fitzhardinge wrote:
Carsten Otte wrote:
+struct mm_struct *dup_mm(struct task_struct *tsk);
No prototypes in .c files. Put this in an appropriate header.
Well, and more fundamentally: do we really want dup_mm() able to be
called from other code?
74 matches
Mail list logo
