public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Tyst Marin <moddingfox@foxtek.us>
To: Dominik Csapak <d.csapak@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH] Add UI option for boot optional mapped usb device
Date: Wed, 4 Dec 2024 21:50:49 +0000	[thread overview]
Message-ID: <CAFA9HCVPZX-mb1KdhjEJ9Oi61aGDXV8SMBSLu3BiWGtp2B1Efg@mail.gmail.com> (raw)
In-Reply-To: <77f8faaf-db60-4ee0-8354-1ff83c870416@proxmox.com>

Hey Dominik,

Appreciate the info and context you provided. I just sent the cla to
office@proxmox.com so hopefully that's good now(my bad for missing that).
Hopefully the below answers at least some part of your questions.

You are correct in that I'd like to optionally have the same behavior that
nonmapped usb passthrough devices have at vm start for mapped devices.

I thought about the same a small bit and initially went with it in vm
config, the thought being that the decision of a usb device being required
or not for boot should be on the vm that intends to use it much like if it
should operate in usb3 mode or not is up to the vm(mainly in how it may be
expected to use it). Though I see merit in having it on mapping config so
that any vm that uses that mapping would be affected by the param. Honestly
though either way seems like it would work.

 I currently think that having something similar to this is worth having in
the case when a mapping is used to resolve a device that is externally
powered/controlled and maybe different from host to host but perform the
same function.

I'm not sure exactly what you mean by booting with the wrong device when by
path(i'm assuming that's by port?). As far as I currently understand
mapping can be configured with either a specific port or vendor/device id
as targets on each machine. So the vm will either have control over a
specific port and attach any device in that port not caring what it is or
use a specific device by vendor/device id on the machine it is running on
based on the map config. As far as I can tell this doesn't seem all that
diff from a vm already booted with a device present in either version of
the map mode config then unplugging it and either changing the device
plugged into the assigned port or moving the device with the target
vendor/device id to a different port. In both cases current behavior is the
machine stays up and accepts the new device at the configured port(as it
should) or reattaches the vendor/device id target to the machine.

What you mentioned about device tracking sounds like a larger existing
issue/behavior with the USB passthrough system overall. I'm not exactly
seeing the where/how it matters in the context of this change request(Tho
that could be my newness to this code base. Please correct me here.).
Approaching from the perspective that after the map lookup the same
attachment mechanism is used with the info retrieved from the lookup(seems
to be how it works as far as I have seen). The behavior of how/if USB
devices are tracked and managed for VM's should already be defined along
with how vm's react to situations with these devices at runtime.


with PLUR
Tyst

On Wed, Dec 4, 2024 at 9:40 AM Dominik Csapak <d.csapak@proxmox.com> wrote:

> Hi,
>
> thanks for wanting to contribute!
>
> First, did you already see
> https://pve.proxmox.com/wiki/Developer_Documentation ?
> (especially the CLA part at the end?)
>
> Just a few high level comments/questions to the approach (did not look too
> much at the code yet).
>
> Please correct me if I'm wrong, but my guess why you want this is to
> emulate
> the behavior for 'raw' USB passed through devices? (since those don't have
> to
> be there for the vm to start?)
>
> I think maybe such a setting would be better suited on the mapping itself?
>
> I say this because the mapping defines which devices can/should be used, so
> there is IMHO the right part to decide if it should be used in a guest
> when it's missing.
>
> Also I'm not very sure if we'd need a setting for this at all, since
> the 'raw' passthrough also simply pass it through.
>
> Just for your understanding, the reason it's currently implemented this way
> is to prevent booting a VM with a wrong device (at least when using the
> path),
> or a without one since that can have bad consequences (depending on what
> the
> guest does with the device and what devices are connected)
>
> Additionally we currently don't properly track the use of usb devices on
> our
> side (which can have weird side effects, e.g. if you try to pass the same
> device to multiple running vms at the same time) but this is not really
> possible when using vendor/device ids since there could be mulitple such
> devices.
>
>
> with kind regards
> Dominik
>
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2024-12-09 16:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26  1:51 moddingfox via pve-devel
2024-12-04  9:40 ` Dominik Csapak
2024-12-04 21:50   ` Tyst Marin [this message]
2024-12-12  8:19     ` Dominik Csapak
2024-12-13  0:23       ` Tyst Marin
2024-12-13  8:34         ` Dominik Csapak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFA9HCVPZX-mb1KdhjEJ9Oi61aGDXV8SMBSLu3BiWGtp2B1Efg@mail.gmail.com \
    --to=moddingfox@foxtek.us \
    --cc=d.csapak@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal