On Tue, Oct 12, 2021 at 10:43:57AM +0800, Jason Wang wrote:
> On Mon, Oct 11, 2021 at 8:36 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Oct 11, 2021 at 03:36:51PM +0800, Jason Wang wrote:
> > > On Tue, Oct 5, 2021 at 3:42 PM Michael S. Tsirkin wrote:
> > > >
> > > > On Mon, Sep 13, 2021 at
On Mon, Oct 11, 2021 at 03:09:09PM -0400, Michael S. Tsirkin wrote:
> The reason we have trouble is that it's not clear what does the API mean
> outside the realm of TDX.
> If we really, truly want an API that says "ioremap and it's a hardened
> driver" then I guess ioremap_hardened_driver is what
On Tue, Oct 12, 2021 at 11:59 AM Jason Wang wrote:
>
>
> 在 2021/10/1 下午3:05, Eugenio Pérez 写道:
> > This series enable shadow virtqueue (SVQ) for vhost-vdpa devices. This
> > is intended as a new method of tracking the memory the devices touch
> > during a migration process: Instead of relay on
在 2021/10/1 下午3:05, Eugenio Pérez 写道:
This series enable shadow virtqueue (SVQ) for vhost-vdpa devices. This
is intended as a new method of tracking the memory the devices touch
during a migration process: Instead of relay on vhost device's dirty
logging capability, SVQ intercepts the VQ
On Tue, Oct 5, 2021 at 9:49 PM Eugenio Pérez wrote:
>
> Check vdpa device range before updating memory regions so we don't add
> any outside of it, and report the invalid change if any.
>
> Signed-off-by: Eugenio Pérez
> ---
> include/hw/virtio/vhost-vdpa.h | 2 +
> hw/virtio/vhost-vdpa.c
On Tue, Oct 5, 2021 at 9:49 PM Eugenio Pérez wrote:
>
> Abstract this operation, that will be reused when validating the region
> against the iova range that the device supports.
>
> Signed-off-by: Eugenio Pérez
Acked-by: Jason Wang
> ---
> hw/virtio/vhost-vdpa.c | 22 +++---
On Tue, Oct 5, 2021 at 9:49 PM Eugenio Pérez wrote:
>
> Following the logic of commit 56918a126ae ("memory: Add RAM_PROTECTED
> flag to skip IOMMU mappings") with VFIO, skip memory sections
> inaccessible via normal mechanisms, including DMA.
>
> Signed-off-by: Eugenio Pérez
Acked-by: Jason
On Mon, Oct 11, 2021 at 8:36 PM Michael S. Tsirkin wrote:
>
> On Mon, Oct 11, 2021 at 03:36:51PM +0800, Jason Wang wrote:
> > On Tue, Oct 5, 2021 at 3:42 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Sep 13, 2021 at 01:53:44PM +0800, Jason Wang wrote:
> > > > Hi All:
> > > >
> > > > This
On Mon, Oct 11, 2021 at 10:23:00AM -0700, Andi Kleen wrote:
>
> On 10/11/2021 12:58 AM, Christoph Hellwig wrote:
> > Just as last time: This does not make any sense. ioremap is shared
> > by definition.
>
> It's not necessarily shared with the host for confidential computing: for
> example
On Mon, Oct 11, 2021 at 10:35:18AM -0700, Andi Kleen wrote:
>
> > Presumably bios code is in arch/x86 and drivers/acpi, right?
> > Up to 200 calls the majority of which is likely private ...
>
> Yes.
>
> > I don't have better ideas but the current setup will just
> > result in people making
On Mon, Oct 11, 2021 at 10:32:23AM -0700, Andi Kleen wrote:
>
> > Because it does not end with I/O operations, that's a trivial example.
> > module unloading is famous for being racy: I just re-read that part of
> > virtio drivers and sure enough we have bugs there, this is after
> > they have
Presumably bios code is in arch/x86 and drivers/acpi, right?
Up to 200 calls the majority of which is likely private ...
Yes.
I don't have better ideas but the current setup will just
result in people making their guests vulnerable whenever they
want to allow device pass-through.
Yes
Because it does not end with I/O operations, that's a trivial example.
module unloading is famous for being racy: I just re-read that part of
virtio drivers and sure enough we have bugs there, this is after
they have presumably been audited, so a TDX guest is better off
just disabling
On 10/11/2021 12:58 AM, Christoph Hellwig wrote:
Just as last time: This does not make any sense. ioremap is shared
by definition.
It's not necessarily shared with the host for confidential computing:
for example BIOS mappings definitely should not be shared, but they're
using ioremap
On Mon, Oct 11, 2021 at 03:36:51PM +0800, Jason Wang wrote:
> On Tue, Oct 5, 2021 at 3:42 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Sep 13, 2021 at 01:53:44PM +0800, Jason Wang wrote:
> > > Hi All:
> > >
> > > This series treis to do more hardening for virito.
> > >
> > > patch 1 validates the
On Sun, Oct 10, 2021 at 07:39:55PM -0700, Andi Kleen wrote:
>
> > The connection is quite unfortunate IMHO.
> > Can't there be an option
> > that unbreaks drivers *without* opening up security holes by
> > making BIOS shared?
>
> That would require new low level APIs that distinguish both cases,
On Sun, Oct 10, 2021 at 03:22:39PM -0700, Andi Kleen wrote:
>
> > To which Andi replied
> > One problem with removing the ioremap opt-in is that
> > it's still possible for drivers to get at devices without going through
> > probe.
> >
> > To which Greg replied:
> >
On Tue, Oct 05, 2021 at 06:42:43AM -0400, Michael S. Tsirkin wrote:
> Stefan also pointed out this duplicates the logic from
>
> if (blksize < 512 || blksize > PAGE_SIZE || !is_power_of_2(blksize))
> return -EINVAL;
>
>
> and a bunch of other places.
>
>
> Would it be
On Sat, Oct 09, 2021 at 05:09:20PM +0800, Jing Xiangfeng wrote:
> virtio_gpu_user_framebuffer_create() misses to call drm_gem_object_put()
> in an error path. Add the missed function call to fix it.
Pushed to drm-misc-next.
thanks,
Gerd
___
Hi Vivek,
On Mon, Oct 11, 2021 at 01:41:15PM +0530, Vivek Gautam wrote:
> > > + list_for_each_entry(ep, >endpoints, list) {
> > > + if (ep->eid == endpoint) {
> > > + vdev = ep->vdev;
>
> I have a question here though -
> Is endpoint-ID unique across all the
On Mon, Oct 11 2021, Halil Pasic wrote:
> The virtio specification virtio-v1.1-cs01 states: "Transitional devices
> MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not
> been acknowledged by the driver." This is exactly what QEMU as of 6.1
> has done relying solely on
Just as last time: This does not make any sense. ioremap is shared
by definition.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Tue, Oct 5, 2021 at 3:42 PM Michael S. Tsirkin wrote:
>
> On Mon, Sep 13, 2021 at 01:53:44PM +0800, Jason Wang wrote:
> > Hi All:
> >
> > This series treis to do more hardening for virito.
> >
> > patch 1 validates the num_queues for virio-blk device.
> > patch 2-4 validates max_nr_ports for
23 matches
Mail list logo
