Re: [PATCH v3 3/3] MAINTAINERS: Mark VMware mailing list entries as email aliases

[Srivatsa S. Bhat]

[ Resending since my previous reply didn't reach the mailing lists. ]

On 11/11/21 5:55 AM, Jakub Kicinski wrote:
> On Wed, 10 Nov 2021 21:19:53 -0800 Joe Perches wrote:
>> On Wed, 2021-11-10 at 17:39 -0800, Jakub Kicinski wrote:
>>> On Wed, 10 Nov 2021 12:09:06 -0800 Srivatsa S. Bhat wrote:  
  DRM DRIVER FOR VMWARE VIRTUAL GPU
 -M:"VMware Graphics" 
  M:Zack Rusin 
 +R:VMware Graphics Reviewers 
  L:dri-de...@lists.freedesktop.org
  S:Supported
  T:git git://anongit.freedesktop.org/drm/drm-misc  
>>>
>>> It'd be preferable for these corporate entries to be marked or
>>> otherwise distinguishable so that we can ignore them when we try 
>>> to purge MAINTAINERS from developers who stopped participating.
>>>
>>> These addresses will never show up in a commit tag which is normally
>>> sign of inactivity.  
>>
>> Funny.
>>
>> The link below is from over 5 years ago.
>>
>> https://lore.kernel.org/lkml/1472081625.3746.217.ca...@perches.com/
>>
>> Almost all of those entries are still in MAINTAINERS.
>>
>> I think the concept of purging is a non-issue.
> 
> I cleaned networking in January and intend to do it again in 2 months.
> See:
> 
> 054c4610bd05 MAINTAINERS: dccp: move Gerrit Renker to CREDITS
> 4f3786e01194 MAINTAINERS: ipvs: move Wensong Zhang to CREDITS
> 0e4ed0b62b5a MAINTAINERS: tls: move Aviad to CREDITS
> c41efbf2ad56 MAINTAINERS: ena: remove Zorik Machulsky from reviewers
> 5e62d124f75a MAINTAINERS: vrf: move Shrijeet to CREDITS
> 09cd3f4683a9 MAINTAINERS: net: move Alexey Kuznetsov to CREDITS
> 93089de91e85 MAINTAINERS: altx: move Jay Cliburn to CREDITS
> 8b0f64b113d6 MAINTAINERS: remove names from mailing list maintainers
> 
I'm assuming the purging is not totally automated, is it? As long as
the entries are informative to a human reader, it should be possible
to skip the relevant ones when purging inactive entries.

I believe this patch makes the situation better than it is currently
(at least for the human reader), by marking lists without public
read-access in a format that is more appropriate. In the future, we
could perhaps improve on it to ease automation too, but for now I
think it is worthwhile to merge this change (unless there are strong
objections or better alternatives that everyone agrees on).

Regards,
Srivatsa
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 1/3] MAINTAINERS: Update maintainers for paravirt ops and VMware hypervisor interface

[Srivatsa S. Bhat]

On Fri, Nov 12, 2021 at 07:55:14AM +0100, Greg KH wrote:
> On Thu, Nov 11, 2021 at 11:40:02AM -0800, Srivatsa S. Bhat wrote:
> > On Thu, Nov 11, 2021 at 07:45:02PM +0100, Greg KH wrote:
> > > On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote:
> > > > On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
> > > > > On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
> > > > > > From: Srivatsa S. Bhat (VMware) 
> > > > > > 
> > > > > > Deep has decided to transfer maintainership of the VMware hypervisor
> > > > > > interface to Srivatsa, and the joint-maintainership of paravirt ops 
> > > > > > in
> > > > > > the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file
> > > > > > to reflect this change.
> > > > > > 
> > > > > > Signed-off-by: Srivatsa S. Bhat (VMware) 
> > > > > > Acked-by: Alexey Makhalov 
> > > > > > Acked-by: Deep Shah 
> > > > > > Acked-by: Juergen Gross 
> > > > > > Cc: sta...@vger.kernel.org
> > > > > 
> > > > > Why are MAINTAINERS updates needed for stable?  That's not normal :(
> > > > 
> > > > So that people posting bug-fixes / backports to these subsystems for
> > > > older kernels (stable and LTS releases) will CC the new subsystem
> > > > maintainers.
> > > 
> > > That's not how stable releases work at all.
> > > 
> > > > That's why I added CC stable tag only to the first two
> > > > patches which add/replace maintainers and not the third patch which is
> > > > just a cleanup.
> > > 
> > > Patches for stable kernels need to go into Linus's tree first, and if
> > > you have the MAINTAINERS file updated properly there, then you will be
> > > properly cc:ed.  We do not look at the MAINTAINERS file for the older
> > > kernel when sending patches out, it's totally ignored as that was the
> > > snapshot at a point in time, which is usually no longer the true state.
> > > 
> > 
> > Sure, but that's the case for patches that get mainlined (and
> > subsequently backported to -stable) /after/ this update to the
> > MAINTAINERS file gets merged into mainline.
> > 
> > When adding the CC stable tag, the case I was trying to address was
> > for patches that are already in mainline but weren't CC'ed to stable,
> > and at some later point, somebody decides to backport them to older
> > stable kernels. In that case, there is a chance that the contributor
> > might run ./get_maintainer.pl against the stable tree (as that's the
> > tree they are backporting the upstream commit against) and end up not
> > CC'ing the new maintainers. So, I thought it would be good to keep the
> > maintainer info updated in the older stable kernels too.
> 
> I always ask that the current maintainers of the code be cc:ed when
> asking for commits to be backported to the stable tree, so I think this
> is not something you need to worry about.  I don't want to have to deal
> with hundreds of patches to try to keep the MAINTAINERS file "up to
> date" for this very very rare event.
> 

Sounds good, thank you!

> You can prove me wrong by looking at our email archives and see where I
> have missed ever doing this in the past 18 years and what the frequency
> of it is...
>

I believe you :-)

> But for now, no, this is not stable kernel material.
>

I understand, and thank you for the clarification!

Regards,
Srivatsa
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 1/3] MAINTAINERS: Update maintainers for paravirt ops and VMware hypervisor interface

[Sasha Levin]

On Thu, Nov 11, 2021 at 11:40:02AM -0800, Srivatsa S. Bhat wrote:

On Thu, Nov 11, 2021 at 07:45:02PM +0100, Greg KH wrote:

On Thu, Nov 11, 2021 at 07:39:16AM -0800, Srivatsa S. Bhat wrote:
> On Thu, Nov 11, 2021 at 07:50:39AM +0100, Greg KH wrote:
> > On Wed, Nov 10, 2021 at 12:08:16PM -0800, Srivatsa S. Bhat wrote:
> > > From: Srivatsa S. Bhat (VMware) 
> > >
> > > Deep has decided to transfer maintainership of the VMware hypervisor
> > > interface to Srivatsa, and the joint-maintainership of paravirt ops in
> > > the Linux kernel to Srivatsa and Alexey. Update the MAINTAINERS file
> > > to reflect this change.
> > >
> > > Signed-off-by: Srivatsa S. Bhat (VMware) 
> > > Acked-by: Alexey Makhalov 
> > > Acked-by: Deep Shah 
> > > Acked-by: Juergen Gross 
> > > Cc: sta...@vger.kernel.org
> >
> > Why are MAINTAINERS updates needed for stable?  That's not normal :(
>
> So that people posting bug-fixes / backports to these subsystems for
> older kernels (stable and LTS releases) will CC the new subsystem
> maintainers.

That's not how stable releases work at all.

> That's why I added CC stable tag only to the first two
> patches which add/replace maintainers and not the third patch which is
> just a cleanup.

Patches for stable kernels need to go into Linus's tree first, and if
you have the MAINTAINERS file updated properly there, then you will be
properly cc:ed.  We do not look at the MAINTAINERS file for the older
kernel when sending patches out, it's totally ignored as that was the
snapshot at a point in time, which is usually no longer the true state.



Sure, but that's the case for patches that get mainlined (and
subsequently backported to -stable) /after/ this update to the
MAINTAINERS file gets merged into mainline.

When adding the CC stable tag, the case I was trying to address was
for patches that are already in mainline but weren't CC'ed to stable,
and at some later point, somebody decides to backport them to older
stable kernels. In that case, there is a chance that the contributor
might run ./get_maintainer.pl against the stable tree (as that's the
tree they are backporting the upstream commit against) and end up not
CC'ing the new maintainers. So, I thought it would be good to keep the
maintainer info updated in the older stable kernels too.


If you look at cases like these, I can see an argument around bringing
it back to -stable. However, changes in the upstream MAINTAINERS file
aren't limited to just change in maintainers.

How would we handle addition of maintainers of a new code upstream? Or
removal of maintainers due to code deletion? Or code movement upstream
that isn't reflected in the stable tree (think a driver graduating from
staging).

It becomes a mess quite quickly and the easiest solution here is to just
use upstream's MAINTAINERS file.

Maybe we should just remove MAINTAINERS from stable trees to make it
obvious.

--
Thanks,
Sasha
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 08/12] x86/sev: Park APs on AP Jump Table with GHCB protocol version 2

[Borislav Petkov]

On Mon, Sep 13, 2021 at 05:55:59PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel 
> 
> GHCB protocol version 2 adds the MSR-based AP-reset-hold VMGEXIT which
> does not need a GHCB. Use that to park APs in 16-bit protected mode on
> the AP Jump Table.
> 
> Signed-off-by: Joerg Roedel 
> ---
>  arch/x86/include/asm/realmode.h|  3 +
>  arch/x86/kernel/sev.c  | 48 ++--
>  arch/x86/realmode/rm/Makefile  | 11 ++--
>  arch/x86/realmode/rm/header.S  |  3 +
>  arch/x86/realmode/rm/sev_ap_park.S | 89 ++
>  5 files changed, 144 insertions(+), 10 deletions(-)
>  create mode 100644 arch/x86/realmode/rm/sev_ap_park.S
> 
> diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h
> index 29590a4ddf24..668de0a8b1ae 100644
> --- a/arch/x86/include/asm/realmode.h
> +++ b/arch/x86/include/asm/realmode.h
> @@ -23,6 +23,9 @@ struct real_mode_header {
>   u32 trampoline_header;
>  #ifdef CONFIG_AMD_MEM_ENCRYPT
>   u32 sev_es_trampoline_start;
> + u32 sev_real_ap_park_asm;

sev_ap_park;

> + u32 sev_real_ap_park_seg;

sev_ap_park_seg;

> + u32 sev_ap_park_gdt;

Yap, like thist one.

>  #endif
>  #ifdef CONFIG_X86_64
>   u32 trampoline_pgd;
> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
> index a98eab926682..20b439986d86 100644
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -695,6 +696,35 @@ static bool __init sev_es_setup_ghcb(void)
>  }
>  
>  #ifdef CONFIG_HOTPLUG_CPU
> +void __noreturn sev_jumptable_ap_park(void)
> +{
> + local_irq_disable();
> +
> + write_cr3(real_mode_header->trampoline_pgd);
> +
> + /* Exiting long mode will fail if CR4.PCIDE is set. */
> + if (boot_cpu_has(X86_FEATURE_PCID))

cpu_feature_enabled() is what we use everywhere now.

> + cr4_clear_bits(X86_CR4_PCIDE);
> +
> + asm volatile("xorq  %%r15, %%r15\n"
> +  "xorq  %%r14, %%r14\n"
> +  "xorq  %%r13, %%r13\n"
> +  "xorq  %%r12, %%r12\n"
> +  "xorq  %%r11, %%r11\n"
> +  "xorq  %%r10, %%r10\n"
> +  "xorq  %%r9,  %%r9\n"
> +  "xorq  %%r8,  %%r8\n"
> +  "xorq  %%rsi, %%rsi\n"
> +  "xorq  %%rdi, %%rdi\n"
> +  "xorq  %%rsp, %%rsp\n"
> +  "xorq  %%rbp, %%rbp\n"

Use xorl and the 32-bit regs is enough - zero extension.

> +  "ljmpl *%0" : :
> +  "m" (real_mode_header->sev_real_ap_park_asm),
> +  "b" (sev_es_jump_table_pa >> 4));

In any case, this asm needs comments: why those regs, why
sev_es_jump_table_pa >> 4 in rbx (I found later in the patch why) and so
on.

> diff --git a/arch/x86/realmode/rm/header.S b/arch/x86/realmode/rm/header.S
> index 8c1db5bf5d78..6c17f8fd1eb4 100644
> --- a/arch/x86/realmode/rm/header.S
> +++ b/arch/x86/realmode/rm/header.S
> @@ -22,6 +22,9 @@ SYM_DATA_START(real_mode_header)
>   .long   pa_trampoline_header
>  #ifdef CONFIG_AMD_MEM_ENCRYPT
>   .long   pa_sev_es_trampoline_start
> + .long   pa_sev_ap_park_asm
> + .long   __KERNEL32_CS
> + .long   pa_sev_ap_park_gdt;
>  #endif
>  #ifdef CONFIG_X86_64
>   .long   pa_trampoline_pgd;
> diff --git a/arch/x86/realmode/rm/sev_ap_park.S 
> b/arch/x86/realmode/rm/sev_ap_park.S

arch/x86/realmode/rm/sev.S

is perfectly fine I guess.

> new file mode 100644
> index ..0b63d0569d4d
> --- /dev/null
> +++ b/arch/x86/realmode/rm/sev_ap_park.S
> @@ -0,0 +1,89 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "realmode.h"
> +
> + .section ".text32", "ax"
> + .code32
> +/*

"This is executed by ... when ... "

> + * The following code switches to 16-bit protected mode and sets up the
> + * execution environment for the AP Jump Table blob. Then it jumps to the AP
> + * Jump Table to park the AP.
> + *
> + * The code was copied from reboot.S and modified to fit the SEV-ES 
> requirements
> + * for AP parking.

That sentence belongs at most in the commit message.

> When this code is entered, all registers except %EAX-%EDX are

%eax, etc. Lowercase pls.

> + * in reset state.
> + *
> + * The AP Jump Table physical base address is in %EBX upon entry.
> + *
> + * %EAX, %ECX, %EDX and EFLAGS are undefined. Only use registers %EAX-%EDX 
> and
> + * %ESP in this code.
> + */
> +SYM_CODE_START(sev_ap_park_asm)

sev_ap_park

> +
> + /* Switch to trampoline GDT as it is guaranteed < 4 GiB */
> + movl$__KERNEL_DS, %eax
> + movl%eax, %ds
> + lgdtpa_tr_gdt
> +
> + /* Disable paging to drop us out of long mode */
> + movl%cr0, %eax
> + btcl$X86_CR0_PG_BIT, %eax
> +

WorldCist'22 - 10th World Conference on IST | Montenegro | Deadline: November 24

[WorldCIST]

* Conference listed in CORE Ranking

** Google Scholar H5-Index = 23

*** Best papers selected for SCI/SSCI journals



--

WorldCIST'22 - 10th World Conference on Information Systems and Technologies

12-14 April 2022, Budva, Montenegro

http://worldcist.org 

---


The WorldCist'22 - 10th World Conference on Information Systems and 
Technologies, to be held in Budva, Montenegro, 12-14 April 2022, is a global 
forum for researchers and practitioners to present and discuss the most recent 
innovations, trends, results, experiences and concerns in the several 
perspectives of Information Systems and Technologies.

We are pleased to invite you to submit your papers to WorldCist'22. All 
submissions will be reviewed on the basis of relevance, originality, importance 
and clarity.



TOPICS

Submitted papers should be related with one or more of the main themes proposed 
for the Conference:

A) Information and Knowledge Management (IKM);

B) Organizational Models and Information Systems (OMIS);

C) Software and Systems Modeling (SSM);

D) Software Systems, Architectures, Applications and Tools (SSAAT);

E) Multimedia Systems and Applications (MSA);

F) Computer Networks, Mobility and Pervasive Systems (CNMPS);

G) Intelligent and Decision Support Systems (IDSS);

H) Big Data Analytics and Applications (BDAA);

I) Human-Computer Interaction (HCI);

J) Ethics, Computers and Security (ECS)

K) Health Informatics (HIS);

L) Information Technologies in Education (ITE);

M) Technologies for Biomedical Applications (TBA)

N) Information Technologies in Radiocommunications (ITR);



TYPES of SUBMISSIONS and DECISIONS

Four types of papers can be submitted:

Full paper: Finished or consolidated R&D works, to be included in one of the 
Conference themes. These papers are assigned a 10-page limit.

Short paper: Ongoing works with relevant preliminary results, open to 
discussion. These papers are assigned a 7-page limit.

Poster paper: Initial work with relevant ideas, open to discussion. These 
papers are assigned to a 4-page limit.

Company paper: Companies' papers that show practical experience, R & D, tools, 
etc., focused on some topics of the conference. These papers are assigned to a 
4-page limit.

Submitted papers must comply with the format of Advances in Intelligent Systems 
and Computing Series (see Instructions for Authors at Springer Website), be 
written in English, must not have been published before, not be under review 
for any other conference or publication and not include any information leading 
to the authors’ identification. Therefore, the authors’ names, affiliations and 
bibliographic references should not be included in the version for evaluation 
by the Program Committee. This information should only be included in the 
camera-ready version, saved in Word or Latex format and also in PDF format. 
These files must be accompanied by the Consent to Publish form filled out, in a 
ZIP file, and uploaded at the conference management system.

All papers will be subjected to a “double-blind review” by at least two members 
of the Program Committee.

Based on Program Committee evaluation, a paper can be rejected or accepted by 
the Conference Chairs. In the later case, it can be accepted as the type 
originally submitted or as another type. Thus, full papers can be accepted as 
short papers or poster papers only. Similarly, short papers can be accepted as 
poster papers only.

Poster papers and Company papers are not published in the Conference 
Proceedings, being only presented and discussed. The authors of accepted poster 
papers should build and print a poster to be exhibited during the Conference. 
This poster must follow an A1 or A2 vertical format. The Conference includes 
Work Sessions where these posters are presented and orally discussed, with a 7 
minute limit per poster.

The authors of accepted Full papers will have 15 minutes to present their work 
in a Conference Work Session; approximately 5 minutes of discussion will follow 
each presentation. The authors of accepted Short papers and Company papers will 
have 11 minutes to present their work in a Conference Work Session; 
approximately 4 minutes of discussion will follow each presentation.



PUBLICATION & INDEXING

To ensure that a full paper or short paper is published, poster paper or 
company paper is presented, at least one of the authors must be fully 
registered by the 8nd of January 2022, and the paper must comply with the 
suggested layout and page-limit. Additionally, all recommended changes must be 
addressed by the authors before they submit the camera-ready version.

No more than one paper per registration will be published. An extra fee must be 
paid for publication of additional papers, with a ma

Re: update_balloon_size_func blocked for more than 120 seconds

[David Hildenbrand]

On Thu, Nov 11, 2021 at 11:49 PM Luis Chamberlain  wrote:
>
> I get the following splats with a kvm guest in idle, after a few seconds
> it starts:
>
> [  242.412806] INFO: task kworker/6:2:271 blockedfor more than 120 seconds.
> [  242.415790]   Tainted: GE 5.15.0-next-2021 #68
> [  242.417755] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  242.418332] task:kworker/6:2 state:D stack:0 pid:  271 ppid: 2 
> flags:0x4000
> [  242.418954] Workqueue: events_freezable update_balloon_size_func 
> [virtio_balloon]
> [  242.419518] Call Trace:
> [  242.419709]  
> [  242.419873]  __schedule+0x2fd/0x990
> [  242.420142]  schedule+0x4e/0xc0
> [  242.420382]  tell_host+0xaa/0xf0 [virtio_balloon]
> [  242.420757]  ? do_wait_intr_irq+0xa0/0xa0
> [  242.421065]  update_balloon_size_func+0x2c9/0x2e0 [virtio_balloon]
> [  242.421527]  process_one_work+0x1e5/0x3c0
> [  242.421833]  worker_thread+0x50/0x3b0
> [  242.422204]  ? rescuer_thread+0x370/0x370
> [  242.422507]  kthread+0x169/0x190
> [  242.422754]  ? set_kthread_struct+0x40/0x40
> [  242.423073]  ret_from_fork+0x1f/0x30
> [  242.423347]  
>
> And this goes on endlessly. The last one says it blocked for more than 1208
> seconds. This was not happening until the last few weeks but I see no
> relevant recent commits for virtio_balloon, so the related change could
> be elsewhere.

We're stuck somewhere in:

wq: update_balloon_size_func()->fill_balloon()->tell_host()

Most probably in wait_event().


I am no waitqueue expert, but my best guess would be that we're
waiting more than 2 minutes
on a host reply with TASK_UNINTERRUPTIBLE. At least that's my interpretation,

In case we're really stuck for more than 2 minutes, the hypervisor
might not be processing our
requests anymore -- or it's not getting processed for some other reason (or the
waitqueue is not getting woken up due do some other BUG).

IIUC, we can sleep longer via wait_event_interruptible(), TASK_UNINTERRUPTIBLE
seems to be the issue that triggers the warning. But by changing that
might just be hiding the fact that
we're waiting more than 2 minutes on a reply.

>
> I could bisect but first I figured I'd check to see if someone already
> had spotted this.

Bisecting would be awesome, then we might at least know if this is a
guest or a hypervisor issue.

Note that the environment matters: the hypervisor seems to be
requesting the guest to inflate
the balloon right when booting up. So you might not be able to
reproduce in a different environment.

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization