.
I would like to understand if this patch can cause any regressions for
any of the architectures
or with the MMC functionality.
Thanks & Regards,
Vishal Annapurve
Author: Vishal Annapurve
MMC: Remove unnecessary cache operations
1) This change removes unnecessary cac
the same?
Regards,
Vishal Annapurve
From: Vishal Annapurve
Subject: [PATCH] usb-storage: Changing the command result
This change updates the returned result to scsi layer to use
DID_TIMEOUT flag as a result status rather than DID_ABORT for
commands aborted due to timeout.
Signed-off-
On Fri, Sep 13, 2024 at 6:08 PM Du, Fan wrote:
>
> ...
> >
> > Hello,
> >
> > This patchset is our exploration of how to support 1G pages in guest_memfd,
> > and
> > how the pages will be used in Confidential VMs.
> >
> > The patchset covers:
> >
> > + How to get 1G pages
> > + Allowing mmap() of
- USB storage bridge or for entire usb storage Or maybe scsi has
decided to abort so it should override the result.
Regards,
Vishal
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Tuesday, October 15, 2013 7:03 PM
To: Vishal Annapurve
Cc: Ming Lei; Linux K
?
Regards,
Vishal
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Tuesday, October 15, 2013 10:22 PM
To: Vishal Annapurve
Cc: Ming Lei; Linux Kernel Mailing List; linux-usb
Subject: RE: [PATCH] usb-storage: scsiglue: Changing the command result
On Tue, 15 Oct 2013
To: Vishal Annapurve
Cc: Ming Lei; Linux Kernel Mailing List; linux-usb
Subject: RE: [PATCH] usb-storage: scsiglue: Changing the command result
On Fri, 18 Oct 2013, Vishal Annapurve wrote:
> Hi Alan,
>
> What I wanted to say was If the bit US_FLIDX_TIMED_OUT can have more
> meaning
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Tuesday, October 15, 2013 5:55 PM
To: Ming Lei
Cc: Vishal Annapurve; Linux Kernel Mailing List; linux-usb
Subject: Re: [PATCH] usb-storage: scsiglue: Changing the command result
On Tue, 15 Oct 2013, Ming Lei wrote
Hi Greg,
Attached are the patches.
Regards,
Vishal
On Monday 09 December 2013 07:29 AM, Greg KH wrote:
On Sat, Nov 16, 2013 at 12:23:50PM +0530, Vishal Annapurve wrote:
Hi,
Here are the updated patches:
Can you please resend these in a format which I can apply them in
without having to
-off-by: Vishal Annapurve
---
drivers/usb/storage/cypress_atacb.c | 1 +
drivers/usb/storage/isd200.c| 2 +-
drivers/usb/storage/transport.c | 8
drivers/usb/storage/usb.c | 10 ++
4 files changed, 12 insertions(+), 9 deletions(-)
---
diff --git a/drivers
primary command set (INQUIRY, TEST UNIT READY, etc.)
but any command accessing the storage medium will time out.
As the USB storage was setting command result as aborted rather than
timed out, SCSI layer was not recognizing the above mentioned failure
pattern.
Signed-off-by: Vishal Annapurve
Hi Alan,
Here is the new patch:
From: Vishal Annapurve
Date: Sat, 26 Oct 2013 21:10:11 +0530
Subject: [PATCH] usb: storage: Proper cmd result assignment
This change replaces DID_ABORT with DID_TIMEOUT as a command result
whenever US_FLIDX_TIMED_OUT bit is set.
This change is made to bring USB
UNIT READY, etc.)
but any command accessing the storage medium will time out.
As the USB storage was setting command result as aborted rather than
timed out, SCSI layer was not recognizing the above mentioned failure
pattern.
Signed-off-by: Vishal Annapurve
---
drivers/usb/storage/cypress_atacb.c
the storage medium will time out.
As the USB storage was setting command result as aborted rather than
timed out, SCSI layer was not recognizing the above mentioned failure
pattern.
Signed-off-by: Vishal Annapurve
---
drivers/staging/keucr/transport.c | 6 +++---
drivers/staging/keucr/usb.c
command accessing the storage medium will time out.
As the USB storage was setting command result as aborted rather than
timed out, SCSI layer was not recognizing the above mentioned failure
pattern.
Signed-off-by: Vishal Annapurve
---
drivers/usb/storage/uas.c | 5 -
1 file changed, 4 insertions
On Wed, Oct 16, 2024 at 2:20 PM David Hildenbrand wrote:
>
> >> I also don't know how you treat things like folio_test_hugetlb() on
> >> possible assumptions that the VMA must be a hugetlb vma. I'd confess I
> >> didn't yet check the rest of the patchset yet - reading a large series
> >> without
On Thu, Oct 17, 2024 at 10:46 PM Jason Gunthorpe wrote:
>
> On Thu, Oct 17, 2024 at 07:11:46PM +0200, David Hildenbrand wrote:
> > On 17.10.24 18:47, Jason Gunthorpe wrote:
> > > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> > >
> > > > My question was more torwards whether gmemfd co
On Wed, Sep 11, 2024 at 1:44 AM Ackerley Tng wrote:
>
> ...
> +}
> +
> +static void kvm_gmem_evict_inode(struct inode *inode)
> +{
> + u64 flags = (u64)inode->i_private;
> +
> + if (flags & KVM_GUEST_MEMFD_HUGETLB)
> + kvm_gmem_hugetlb_teardown(inode);
> + else
> +
On Thu, Feb 20, 2025 at 1:47 PM Dave Hansen wrote:
>
> On 2/20/25 13:16, Vishal Annapurve wrote:
> > Since enabling CONFIG_PARAVIRT_XXL is too bloated for TDX guest
> > like platforms, move HLT and SAFE_HLT paravirt calls under
> > CONFIG_PARAVIRT.
>
> I guess it
On Thu, Feb 20, 2025 at 3:00 PM Dave Hansen wrote:
>
> On 2/20/25 13:16, Vishal Annapurve wrote:
> > Direct HLT instruction execution causes #VEs for TDX VMs which is routed
> > to hypervisor via TDCALL. safe_halt() routines execute HLT in STI-shadow
> > so IRQs need to r
IRQs are enabled during HLT #VE handling
to avoid running into scenarios where IRQ wake events are lost resulting in
indefinite HLT execution times.
Reviewed-by: Kirill A. Shutemov
Signed-off-by: Vishal Annapurve
---
arch/x86/coco/tdx/tdx.c | 8
1 file changed, 8 insertions(+)
diff
with interrupts
enabled.
Changes since v5:
1) Addressed Dave's comments.
2) Dropped the cleanup patch for now, it can be discussed separately.
v5: https://lore.kernel.org/lkml/20250220211628.1832258-1-vannapu...@google.com/
Kirill A. Shutemov (1):
x86/paravirt: Move halt paravirt calls un
ding HLT related #VEs altogether.
Cc: sta...@vger.kernel.org
Fixes: bfe6ed0c6727 ("x86/tdx: Add HLT support for TDX guests")
Signed-off-by: Vishal Annapurve
---
arch/x86/Kconfig | 1 +
arch/x86/coco/tdx/tdx.c| 26 +-
arch/x86/include/asm/tdx.h | 2
anan
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Reviewed-by: Tony Luck
Signed-off-by: Vishal Annapurve
---
arch/x86/include/asm/irqflags.h | 40 +++
arch/x86/include/asm/paravirt.h | 20 +++---
IRQs are enabled during HLT #VE handling
to avoid running into scenarios where IRQ wake events are lost resulting in
indefinite HLT execution times.
Reviewed-by: Kirill A. Shutemov
Signed-off-by: Vishal Annapurve
---
arch/x86/coco/tdx/tdx.c | 8
1 file changed, 8 insertions(+)
diff
-vannapu...@google.com/
[1]
https://lore.kernel.org/lkml/20210517235008.257241-1-sathyanarayanan.kuppusw...@linux.intel.com/
Kirill A. Shutemov (1):
x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT
Vishal Annapurve (3):
x86/tdx: Route safe halt execution via tdx_safe_halt()
x86/td
With explicit dependency on CONFIG_PARAVIRT and TDX specific
halt()/safe_halt() routines in place, default_idle() is safe to execute for
TDX VMs. Remove TDX specific idle routine override which is now
redundant.
Signed-off-by: Vishal Annapurve
---
arch/x86/coco/tdx/tdx.c| 2 +-
arch/x86
dx_halt() from idle routine which just
executes TDCALL without toggling interrupt state. Introduce dependency
on CONFIG_PARAVIRT and override paravirt halt()/safe_halt() routines for
TDX VMs.
Cc: sta...@vger.kernel.org
Fixes: bfe6ed0c6727 ("x86/tdx: Add HLT support for TDX guests")
Signed-of
anan
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Reviewed-by: Tony Luck
Signed-off-by: Vishal Annapurve
---
arch/x86/include/asm/irqflags.h | 40 +++
arch/x86/include/asm/paravirt.h | 20 +++---
with interrupts
enabled.
Changes since v6:
1) Addressed Kirills's comments.
2) Fixed a build failure.
v6: https://lore.kernel.org/lkml/20250225004704.603652-1-vannapu...@google.com/
Kirill A. Shutemov (1):
x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT
Vishal Anna
T support for TDX guests")
Reviewed-by: Kirill A. Shutemov
Signed-off-by: Vishal Annapurve
---
arch/x86/Kconfig | 1 +
arch/x86/coco/tdx/tdx.c| 26 +-
arch/x86/include/asm/tdx.h | 4 ++--
arch/x86/kernel/process.c | 2 +-
4 files changed, 29 insertio
anan
Signed-off-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Reviewed-by: Tony Luck
Reviewed-by: Juergen Gross
Signed-off-by: Vishal Annapurve
---
arch/x86/include/asm/irqflags.h | 40 +++
arch/x86/include/asm/p
IRQs are enabled during HLT #VE handling
to avoid running into scenarios where IRQ wake events are lost resulting in
indefinite HLT execution times.
Reviewed-by: Kirill A. Shutemov
Signed-off-by: Vishal Annapurve
---
arch/x86/coco/tdx/tdx.c | 8
1 file changed, 8 insertions(+)
diff
On Wed, Feb 26, 2025 at 3:49 AM Kirill A. Shutemov wrote:
>
> On Tue, Feb 25, 2025 at 12:47:03AM +, Vishal Annapurve wrote:
> > Direct HLT instruction execution causes #VEs for TDX VMs which is routed
> > to hypervisor via TDCALL. If HLT is executed in STI-shadow, resulti
On Thu, Feb 27, 2025 at 8:25 AM kernel test robot wrote:
>
> Hi Vishal,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on tip/x86/core]
> [also build test ERROR on tip/master linus/master v6.14-rc4 next-20250227]
> [cannot apply to tip/x86/tdx tip/auto-latest]
On Thu, Feb 27, 2025 at 5:44 PM Vishal Annapurve wrote:
>
> Direct HLT instruction execution causes #VEs for TDX VMs which is routed
> to hypervisor via TDCALL. safe_halt() routines execute HLT in STI-shadow
> so IRQs need to remain disabled until the TDCALL to ensure that pendin
35 matches
Mail list logo
