Re: [PATCH 38/62] x86/sev-es: Handle instruction fetches from user-space
On Fri, Mar 13, 2020 at 2:12 AM Joerg Roedel wrote: > > On Wed, Feb 12, 2020 at 01:42:48PM -0800, Andy Lutomirski wrote: > > I realize that this is a somewhat arbitrary point in the series to > > complain about this, but: the kernel already has infrastructure to > > decode and fix up an instruction-based exception. See > > fixup_umip_exception(). Please refactor code so that you can share > > the same infrastructure rather than creating an entirely new thing. > > Okay, but 'infrastructure' is a bold word for the call path down > fixup_umip_exception(). I won't argue with that. > It uses the in-kernel instruction decoder, which > I already use in my patch-set. But I agree that some code in this > patch-set is duplicated and already present in the instruction decoder, > and that fixup_umip_exception() has more robust instruction decoding. > > I factor the instruction decoding part out and make is usable for the > #VC handler too and remove the code that is already present in the > instruction decoder. Thanks! > > Regards, > > Joerg > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3] drm/bochs: downgrade pci_request_region failure from error to warning
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
> Shutdown of firmware framebuffer has a bunch of problems. Because
> of this the framebuffer region might still be reserved even after
> drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Is that still the fbdev lifetime fun where the cleanup might be delayed if
the char device node is still open?
-Daniel
>
> Don't consider pci_request_region() failure for the framebuffer
> region as fatal error to workaround this issue.
>
> Reported-by: Marek Marczykowski-Górecki
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/bochs/bochs_hw.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_hw.c
> b/drivers/gpu/drm/bochs/bochs_hw.c
> index 952199cc0462..dce4672e3fc8 100644
> --- a/drivers/gpu/drm/bochs/bochs_hw.c
> +++ b/drivers/gpu/drm/bochs/bochs_hw.c
> @@ -157,10 +157,8 @@ int bochs_hw_init(struct drm_device *dev)
> size = min(size, mem);
> }
>
> - if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
> - DRM_ERROR("Cannot request framebuffer\n");
> - return -EBUSY;
> - }
> + if (pci_request_region(pdev, 0, "bochs-drm") != 0)
> + DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
>
> bochs->fb_map = ioremap(addr, size);
> if (bochs->fb_map == NULL) {
> --
> 2.18.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH RFC v2 12/24] hpsa: use reserved commands
On 3/17/20 10:38 AM, John Garry wrote: On 11/03/2020 08:10, Ming Lei wrote: ands(struct ctlr_info *h) @@ -5803,6 +5803,7 @@ static int hpsa_scsi_host_alloc(struct ctlr_info *h) sh->max_lun = HPSA_MAX_LUN; sh->max_id = HPSA_MAX_LUN; sh->can_queue = h->nr_cmds - HPSA_NRESERVED_CMDS; + sh->nr_reserved_cmds = HPSA_NRESERVED_CMDS; Now .nr_reserved_cmds has been passed to blk-mq, you need to increase sh->can_queue to h->nr_cmds, because .can_queue is the whole queue depth (include the part of reserved tags), otherwise, IO tags will be decreased. Sounds correct. I will have having a look at the patchset; I thought I did a patch to modify .can_queue so that it would cover only the usable tags, not the reserved ones. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
