Re: [pve-devel] [PATCH installer 1/2] low level: config: filter out kernel cmdline on word boundaries
On Fri Aug 9, 2024 at 1:51 PM CEST, Christoph Heiss wrote:
> Otherwise, substrings might get replaced, e.g. the replacement
> `proxmox-start-auto-installer` -> `pxmox-start-auto-installer` would be
> done.
>
> Fixes: a02a78a ("fix #4747: pass kernel cmdline parameters to target system")
> Suggested-by: Thomas Lamprecht
> Signed-off-by: Christoph Heiss
> ---
> Proxmox/Install/Config.pm | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Proxmox/Install/Config.pm b/Proxmox/Install/Config.pm
> index ae70093..6b064b1 100644
> --- a/Proxmox/Install/Config.pm
> +++ b/Proxmox/Install/Config.pm
> @@ -43,8 +43,8 @@ my sub parse_kernel_cmdline {
> }
> }
>
> -$cmdline =~ s/(?:BOOT_IMAGE|root|ramdisk_size|splash|vga)=\S+\s?//gi;
> -$cmdline =~ s/ro|rw|quiet|proxdebug|proxtui|nomodeset//gi;
> +$cmdline =~ s/\b(?:BOOT_IMAGE|root|ramdisk_size|splash|vga)=\S+\s?\b//gi;
> +$cmdline =~ s/\bro|rw|quiet|proxdebug|proxtui|nomodeset\b//gi;
There are parentheses missing next to \b .
The current implementation seems not to be strict enough when dealing
with variables. For example, the variable regex would not match
something like 'apic=quiet', but then the second regex matches wrongly
'quiet'.
>
> $cfg->{target_cmdline}= $cmdline;
>
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] FW: issues with Virtio-SCSI devicde on Proxmox...
--- Begin Message ---
>>Alexandre,
>>
>>the statement below is not true for our case. The OpenVMS guest OS is
>>using a PCIE bus, so the virtio-scsi device should be exposed as
>>"modern", but is not. Not sure why not at this point
See Fiona response,
the pci express bridge is present, but the virtio-net is plugged on a
simple pci bridge.
pci express slots are mostly used for passthrough devices
/usr/share/perl5/PVE/QemuServer/PCI.pm
my $pcie_addr_map;
sub get_pcie_addr_map {
$pcie_addr_map = {
vga => { bus => 'pcie.0', addr => 1 },
hostpci0 => { bus => "ich9-pcie-port-1", addr => 0 },
hostpci1 => { bus => "ich9-pcie-port-2", addr => 0 },
hostpci2 => { bus => "ich9-pcie-port-3", addr => 0 },
hostpci3 => { bus => "ich9-pcie-port-4", addr => 0 },
hostpci4 => { bus => "ich9-pcie-port-5", addr => 0 },
hostpci5 => { bus => "ich9-pcie-port-6", addr => 0 },
hostpci6 => { bus => "ich9-pcie-port-7", addr => 0 },
hostpci7 => { bus => "ich9-pcie-port-8", addr => 0 },
hostpci8 => { bus => "ich9-pcie-port-9", addr => 0 },
hostpci9 => { bus => "ich9-pcie-port-10", addr => 0 },
hostpci10 => { bus => "ich9-pcie-port-11", addr => 0 },
hostpci11 => { bus => "ich9-pcie-port-12", addr => 0 },
hostpci12 => { bus => "ich9-pcie-port-13", addr => 0 },
hostpci13 => { bus => "ich9-pcie-port-14", addr => 0 },
hostpci14 => { bus => "ich9-pcie-port-15", addr => 0 },
hostpci15 => { bus => "ich9-pcie-port-16", addr => 0 },
# win7 is picky about pcie assignments
hostpci0bus0 => { bus => "pcie.0", addr => 16 },
hostpci1bus0 => { bus => "pcie.0", addr => 17 },
hostpci2bus0 => { bus => "pcie.0", addr => 18 },
hostpci3bus0 => { bus => "pcie.0", addr => 19 },
ivshmem => { bus => 'pcie.0', addr => 20 },
hostpci4bus0 => { bus => "pcie.0", addr => 9 },
hostpci5bus0 => { bus => "pcie.0", addr => 10 },
hostpci6bus0 => { bus => "pcie.0", addr => 11 },
hostpci7bus0 => { bus => "pcie.0", addr => 12 },
hostpci8bus0 => { bus => "pcie.0", addr => 13 },
hostpci9bus0 => { bus => "pcie.0", addr => 14 },
hostpci10bus0 => { bus => "pcie.0", addr => 15 },
hostpci11bus0 => { bus => "pcie.0", addr => 21 },
hostpci12bus0 => { bus => "pcie.0", addr => 22 },
hostpci13bus0 => { bus => "pcie.0", addr => 23 },
hostpci14bus0 => { bus => "pcie.0", addr => 24 },
hostpci15bus0 => { bus => "pcie.0", addr => 25 },
}
___
Christian Moser
Mobile: +358-40-5022105
Email: c...@maklee.com
URL: www.maklee.com
-Original Message-
From: DERUMIER, Alexandre
Sent: Wednesday, August 14, 2024 09:45
To: pve-devel@lists.proxmox.com; c...@maklee.com
Subject: Re: [pve-devel] issues with Virtio-SCSI devicde on Proxmox...
Hi,
I didn't see the responde of Fiona but indeed:
https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg01567.html
"virtio devices can be exposed in upto three ways
- Legacy - follows virtio 0.9 specification. always uses PCI
ID range 0x1000-0x103F
- Transitional - follows virtio 0.9 specification by default, but
can auto-negotiate with guest for 1.0 spce. Always
uses PCI ID range 0x1000-0x103F
- Modern - follows virtio 1.0 specification. always uses PCI
ID range 0x1040-0x107F
With QEMU, historically devices placed on a PCI bus will always default
to being in transitional mode, while devices placed on a PCI-E bus will
always dfault to being in modern mode.
"
Message initial
De: Fiona Ebner
Répondre à: Proxmox VE development discussion
À: Proxmox VE development discussion ,
Christian Moser
Objet: Re: [pve-devel] issues with Virtio-SCSI devicde on Proxmox...
Date: 13/08/2024 10:55:47
Hi,
Am 12.08.24 um 12:40 schrieb Christian Moser:
> Hello,
>
> I work for VSI (VMS Software Inc) which is porting the OpenVMS
> operating system to x86. At this point we successfully on various
> hypervisors, but have some issues on the KVM running on Proxmox.
>
> The OpenVMS VM works just fine with SATA disks and it also works with
> for example virtio-network device etc., but trying to use virtio-scsi
> hangs the driver. I have debugged this and I can successfully
> configure the port/controller, send the IO request to the device. It
> then gets processed by the device, which posts the results and sets
> the interrupt bit in the ISR register, but it never asserts the
> interrupt hence the driver never gets notified and the I/O hangs.
>
> I have tried both “virtio-scsi-pci” and “virtio-scsi-single”, but no
> luck. The emulated virtio-scsi device is a legacy device. But then
> again, the virtio-network device is also a legacy device and here we
> are getting interrupts. One thing which bothers me is the fact t
Re: [pve-devel] FW: issues with Virtio-SCSI devicde on Proxmox...
--- Begin Message ---
>>I'm talking about virtio-scsi. Our virtio-network device is working
>>fine
Yes, sorry, I wanted to said virtio-scsi.
All pci devices excluding passthrough devices (with pcie=on flag) are
actually plugged to pci bridge
sub get_pci_addr_map {
$pci_addr_map = {
piix3 => { bus => 0, addr => 1, conflict_ok => qw(ehci) },
ehci => { bus => 0, addr => 1, conflict_ok => qw(piix3) }, #
instead of piix3 on arm
vga => { bus => 0, addr => 2, conflict_ok => qw(legacy-igd) },
'legacy-igd' => { bus => 0, addr => 2, conflict_ok => qw(vga)
}, # legacy-igd requires vga=none
balloon0 => { bus => 0, addr => 3 },
watchdog => { bus => 0, addr => 4 },
scsihw0 => { bus => 0, addr => 5, conflict_ok => qw(pci.3) },
'pci.3' => { bus => 0, addr => 5, conflict_ok => qw(scsihw0)
}, # also used for virtio-scsi-single bridge
scsihw1 => { bus => 0, addr => 6 },
ahci0 => { bus => 0, addr => 7 },
qga0 => { bus => 0, addr => 8 },
spice => { bus => 0, addr => 9 },
virtio0 => { bus => 0, addr => 10 },
virtio1 => { bus => 0, addr => 11 },
virtio2 => { bus => 0, addr => 12 },
virtio3 => { bus => 0, addr => 13 },
virtio4 => { bus => 0, addr => 14 },
virtio5 => { bus => 0, addr => 15 },
hostpci0 => { bus => 0, addr => 16 },
hostpci1 => { bus => 0, addr => 17 },
net0 => { bus => 0, addr => 18 },
net1 => { bus => 0, addr => 19 },
net2 => { bus => 0, addr => 20 },
net3 => { bus => 0, addr => 21 },
net4 => { bus => 0, addr => 22 },
net5 => { bus => 0, addr => 23 },
vga1 => { bus => 0, addr => 24 },
vga2 => { bus => 0, addr => 25 },
vga3 => { bus => 0, addr => 26 },
hostpci2 => { bus => 0, addr => 27 },
hostpci3 => { bus => 0, addr => 28 },
#addr29 : usb-host (pve-usb.cfg)
'pci.1' => { bus => 0, addr => 30 },
'pci.2' => { bus => 0, addr => 31 },
'net6' => { bus => 1, addr => 1 },
'net7' => { bus => 1, addr => 2 },
'net8' => { bus => 1, addr => 3 },
'net9' => { bus => 1, addr => 4 },
'net10' => { bus => 1, addr => 5 },
'net11' => { bus => 1, addr => 6 },
'net12' => { bus => 1, addr => 7 },
'net13' => { bus => 1, addr => 8 },
'net14' => { bus => 1, addr => 9 },
'net15' => { bus => 1, addr => 10 },
'net16' => { bus => 1, addr => 11 },
'net17' => { bus => 1, addr => 12 },
'net18' => { bus => 1, addr => 13 },
'net19' => { bus => 1, addr => 14 },
'net20' => { bus => 1, addr => 15 },
'net21' => { bus => 1, addr => 16 },
'net22' => { bus => 1, addr => 17 },
'net23' => { bus => 1, addr => 18 },
'net24' => { bus => 1, addr => 19 },
'net25' => { bus => 1, addr => 20 },
'net26' => { bus => 1, addr => 21 },
'net27' => { bus => 1, addr => 22 },
'net28' => { bus => 1, addr => 23 },
'net29' => { bus => 1, addr => 24 },
'net30' => { bus => 1, addr => 25 },
'net31' => { bus => 1, addr => 26 },
'xhci' => { bus => 1, addr => 27 },
'pci.4' => { bus => 1, addr => 28 },
'rng0' => { bus => 1, addr => 29 },
'pci.2-igd' => { bus => 1, addr => 30 }, # replaces pci.2 in
case a legacy IGD device is passed through
'virtio6' => { bus => 2, addr => 1 },
'virtio7' => { bus => 2, addr => 2 },
'virtio8' => { bus => 2, addr => 3 },
'virtio9' => { bus => 2, addr => 4 },
'virtio10' => { bus => 2, addr => 5 },
'virtio11' => { bus => 2, addr => 6 },
'virtio12' => { bus => 2, addr => 7 },
'virtio13' => { bus => 2, addr => 8 },
'virtio14' => { bus => 2, addr => 9 },
'virtio15' => { bus => 2, addr => 10 },
'ivshmem' => { bus => 2, addr => 11 },
'audio0' => { bus => 2, addr => 12 },
hostpci4 => { bus => 2, addr => 13 },
hostpci5 => { bus => 2, addr => 14 },
hostpci6 => { bus => 2, addr => 15 },
hostpci7 => { bus => 2, addr => 16 },
hostpci8 => { bus => 2, addr => 17 },
hostpci9 => { bus => 2, addr => 18 },
hostpci10 => { bus => 2, addr => 19 },
hostpci11 => { bus => 2, addr => 20 },
hostpci12 => { bus => 2, addr => 21 },
hostpci13 => { bus => 2, addr => 22 },
hostpci14 => { bus => 2, addr => 23 },
hostpci15 => { bus => 2, addr => 24 },
'virtioscsi0' => { bus => 3, addr => 1 },
'virtioscsi1' => { bus => 3, addr => 2 },
'virtioscsi2' => { bus => 3, addr => 3 },
'virtioscsi3' => { bus => 3, addr => 4 },
'virtioscsi4' => { bus => 3, addr => 5 },
'virtioscsi5' => { bus => 3, addr => 6 },
'virtioscsi6' => { bus => 3, addr => 7 },
'virtioscsi7' => { bus => 3, addr => 8 },
'virtioscsi8' => { bus => 3, addr
[pve-devel] [PATCH installer v5 2/3] tui: expose arc size setting for zfs bootdisks for all products
For non-PVE products, simply use the ZFS defaults (aka. 50%) and leave
unset, if the user never touches that setting.
Signed-off-by: Christoph Heiss
---
Changes v4 -> v5:
* rebased on latest master
* fixed value not persisting across dialog open/close for non-PVE
Changes v3 -> v4:
* rebased on latest master
Changes v2 -> v3:
* no changes
Changes v1 -> v2:
* use new placeholder functionality for non-PVE products
proxmox-installer-common/src/options.rs | 3 +-
proxmox-tui-installer/src/views/bootdisk.rs | 48 +
proxmox-tui-installer/src/views/mod.rs | 1 -
3 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/proxmox-installer-common/src/options.rs
b/proxmox-installer-common/src/options.rs
index 9375ded..34dfadb 100644
--- a/proxmox-installer-common/src/options.rs
+++ b/proxmox-installer-common/src/options.rs
@@ -214,7 +214,8 @@ impl ZfsBootdiskOptions {
/// The default ZFS maximum ARC size in MiB for this system.
fn default_zfs_arc_max(product: ProxmoxProduct, total_memory: usize) -> usize {
if product != ProxmoxProduct::PVE {
-// Use ZFS default for non-PVE
+// For products other the PVE, just let ZFS decide on its own. Setting
`0`
+// causes the installer to skip writing the `zfs_arc_max` module
parameter.
0
} else {
((total_memory as f64) / 10.)
diff --git a/proxmox-tui-installer/src/views/bootdisk.rs
b/proxmox-tui-installer/src/views/bootdisk.rs
index 1e22105..dfb1608 100644
--- a/proxmox-tui-installer/src/views/bootdisk.rs
+++ b/proxmox-tui-installer/src/views/bootdisk.rs
@@ -622,7 +622,24 @@ impl ZfsBootdiskOptionsView {
options: &ZfsBootdiskOptions,
product_conf: &ProductConfig,
) -> Self {
-let is_pve = product_conf.product == ProxmoxProduct::PVE;
+let arc_max_view = {
+let view =
IntegerEditView::new_with_suffix("MiB").max_value(runinfo.total_memory);
+
+// For PVE "force" the default value, for other products place the
recommended value
+// only in the placeholder. This causes for the latter to not
write the module option
+// if the value is never modified by the user.
+if product_conf.product == ProxmoxProduct::PVE {
+view.content(options.arc_max)
+} else {
+let view = view.placeholder(runinfo.total_memory / 2);
+
+if options.arc_max != 0 {
+view.content(options.arc_max)
+} else {
+view
+}
+}
+};
let inner = FormView::new()
.child("ashift", IntegerEditView::new().content(options.ashift))
@@ -654,13 +671,7 @@ impl ZfsBootdiskOptionsView {
"copies",
IntegerEditView::new().content(options.copies).max_value(3),
)
-.child_conditional(
-is_pve,
-"ARC max size",
-IntegerEditView::new_with_suffix("MiB")
-.max_value(runinfo.total_memory)
-.content(options.arc_max),
-)
+.child("ARC max size", arc_max_view)
.child("hdsize",
DiskSizeEditView::new().content(options.disk_size));
let view = MultiDiskOptionsView::new(&runinfo.disks,
&options.selected_disks, inner)
@@ -682,21 +693,22 @@ impl ZfsBootdiskOptionsView {
fn get_values(&mut self) -> Option<(Vec, ZfsBootdiskOptions)> {
let (disks, selected_disks) = self.view.get_disks_and_selection()?;
let view = self.view.get_options_view()?;
-let has_arc_max = view.len() >= 6;
-let disk_size_index = if has_arc_max { 5 } else { 4 };
let ashift = view.get_value::(0)?;
let compress = view.get_value::, _>(1)?;
let checksum = view.get_value::, _>(2)?;
let copies = view.get_value::(3)?;
-let disk_size = view.get_value::(disk_size_index)?;
-
-let arc_max = if has_arc_max {
-view.get_value::(4)?
-.max(ZFS_ARC_MIN_SIZE_MIB)
-} else {
-0 // use built-in ZFS default value
-};
+let disk_size = view.get_value::(5)?;
+
+// If a value is set, return that and clamp it to at least
[`ZFS_ARC_MIN_SIZE_MIB`].
+//
+// Otherwise, if no value was set or an error occurred return `0`. The
former simply means
+// that the placeholder value is still there.
+let arc_max = view
+.get_child::(4)?
+.get_content_maybe()
+.map_or(Ok(0), |v| v.map(|v| v.max(ZFS_ARC_MIN_SIZE_MIB)))
+.unwrap_or(0);
Some((
disks,
diff --git a/proxmox-tui-installer/src/views/mod.rs
b/proxmox-tui-installer/src/views/mod.rs
index c7491fc..a41dac3 100644
--- a/proxmox-tui-installer/src/views/mod.rs
+++ b/proxmox-tui-installer/src/views/mod.rs
@@ -96,7 +96,6 @@ impl
NumericEdit
[pve-devel] [PATCH installer v5 1/3] tui: NumericEditView: add optional placeholder value
Enables to add an optional placeholder value to `NumericEditView`, which
will be displayed in a different (darker) color and not returned by
`.get_content*()`.
Can be used for having default values in the TUI, but with different
handling in the back.
Signed-off-by: Christoph Heiss
---
Changes v4 -> v5:
* no changes
Changes v3 -> v4:
* no changes
Changes v2 -> v3:
* when empty & focused, do not show the placeholder value at all
Changes v1 -> v2:
* new patch
proxmox-tui-installer/src/views/mod.rs | 66 --
1 file changed, 62 insertions(+), 4 deletions(-)
diff --git a/proxmox-tui-installer/src/views/mod.rs
b/proxmox-tui-installer/src/views/mod.rs
index a098d1f..c7491fc 100644
--- a/proxmox-tui-installer/src/views/mod.rs
+++ b/proxmox-tui-installer/src/views/mod.rs
@@ -2,9 +2,10 @@ use std::{net::IpAddr, rc::Rc, str::FromStr};
use cursive::{
event::{Event, EventResult},
+theme::BaseColor,
view::{Resizable, ViewWrapper},
views::{EditView, LinearLayout, NamedView, ResizedView, SelectView,
TextView},
-Rect, Vec2, View,
+Printer, Rect, Vec2, View,
};
use proxmox_installer_common::utils::CidrAddress;
@@ -27,6 +28,7 @@ pub use timezone::*;
pub struct NumericEditView {
view: LinearLayout,
max_value: Option,
+placeholder: Option,
max_content_width: Option,
allow_empty: bool,
}
@@ -39,6 +41,7 @@ impl
NumericEditView {
Self {
view,
max_value: None,
+placeholder: None,
max_content_width: None,
allow_empty: false,
}
@@ -57,6 +60,7 @@ impl
NumericEditView {
Self {
view,
max_value: None,
+placeholder: None,
max_content_width: None,
allow_empty: false,
}
@@ -87,15 +91,42 @@ impl
NumericEditView {
self
}
+/// Sets a placeholder value for this view. Implies `allow_empty(true)`.
+/// Implies `allow_empty(true)`.
+///
+/// # Arguments
+/// `placeholder` - The placeholder value to set for this view.
+#[allow(unused)]
+pub fn placeholder(mut self, placeholder: T) -> Self {
+self.placeholder = Some(placeholder);
+self.allow_empty(true)
+}
+
+/// Returns the current value of the view. If a placeholder is defined and
+/// no value is currently set, the placeholder value is returned.
+///
+/// **This should only be called when `allow_empty = false` or a
placeholder
+/// is set.**
pub fn get_content(&self) -> Result::Err> {
-assert!(!self.allow_empty);
-self.inner().get_content().parse()
+let content = self.inner().get_content();
+
+if content.is_empty() {
+if let Some(placeholder) = self.placeholder {
+return Ok(placeholder);
+}
+}
+
+assert!(!(self.allow_empty && self.placeholder.is_none()));
+content.parse()
}
+/// Returns the current value of the view, or [`None`] if the view is
+/// currently empty.
pub fn get_content_maybe(&self) -> Option::Err>> {
let content = self.inner().get_content();
+
if !content.is_empty() {
-Some(self.inner().get_content().parse())
+Some(content.parse())
} else {
None
}
@@ -160,6 +191,25 @@ impl
NumericEditView {
std::mem::swap(self.inner_mut(), &mut inner);
self
}
+
+/// Generic `wrap_draw()` implementation for [`ViewWrapper`].
+///
+/// # Arguments
+/// * `printer` - The [`Printer`] to draw to the base view.
+fn wrap_draw_inner(&self, printer: &Printer) {
+self.view.draw(printer);
+
+if self.inner().get_content().is_empty() && !printer.focused {
+if let Some(placeholder) = self.placeholder {
+let placeholder = placeholder.to_string();
+
+printer.with_color(
+(BaseColor::Blue.light(), BaseColor::Blue.dark()).into(),
+|printer| printer.print((0, 0), &placeholder),
+);
+}
+}
+}
}
pub type FloatEditView = NumericEditView;
@@ -168,6 +218,10 @@ pub type IntegerEditView = NumericEditView;
impl ViewWrapper for FloatEditView {
cursive::wrap_impl!(self.view: LinearLayout);
+fn wrap_draw(&self, printer: &Printer) {
+self.wrap_draw_inner(printer);
+}
+
fn wrap_on_event(&mut self, event: Event) -> EventResult {
let original = self.inner_mut().get_content();
@@ -207,6 +261,10 @@ impl FloatEditView {
impl ViewWrapper for IntegerEditView {
cursive::wrap_impl!(self.view: LinearLayout);
+fn wrap_draw(&self, printer: &Printer) {
+self.wrap_draw_inner(printer);
+}
+
fn wrap_on_event(&mut self, event: Event) -> EventResult {
let original = self.inner_mut().get_content();
--
2.45.2
__
[pve-devel] [PATCH installer v5 3/3] proxinstall: expose arc size setting for zfs bootdisks for all products
For non-PVE products, simply use the ZFS defaults (aka. 50%) and leave
unset, if the user never touches that setting.
Signed-off-by: Christoph Heiss
---
Changes v4 -> v5:
* no changes
Changes v3 -> v4:
* no changes
Changes v2 -> v3:
* rework based on Maximilano's suggestion using Gtk3::Adjustment
Changes v1 -> v2:
* add some more explanatory comments
Proxmox/Install/RunEnv.pm | 3 ++-
proxinstall | 26 +-
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/Proxmox/Install/RunEnv.pm b/Proxmox/Install/RunEnv.pm
index 7eaf96a..8322603 100644
--- a/Proxmox/Install/RunEnv.pm
+++ b/Proxmox/Install/RunEnv.pm
@@ -329,7 +329,8 @@ our $ZFS_ARC_SYSMEM_PERCENTAGE = 0.1; # use 10% of
available system memory by de
# Calculates the default upper limit for the ZFS ARC size.
# Returns the default ZFS maximum ARC size in MiB.
sub default_zfs_arc_max {
-# Use ZFS default on non-PVE
+# For products other the PVE, just let ZFS decide on its own. Setting `0`
+# causes the installer to skip writing the `zfs_arc_max` module parameter.
return 0 if Proxmox::Install::ISOEnv::get('product') ne 'pve';
my $default_mib = get('total_memory') * $ZFS_ARC_SYSMEM_PERCENTAGE;
diff --git a/proxinstall b/proxinstall
index 12f3eaa..5e991da 100755
--- a/proxinstall
+++ b/proxinstall
@@ -1138,20 +1138,20 @@ my $create_raid_advanced_grid = sub {
$spinbutton_copies->set_value($copies);
push @$labeled_widgets, ['copies', $spinbutton_copies];
-if ($iso_env->{product} eq 'pve') {
- my $total_memory = Proxmox::Install::RunEnv::get('total_memory');
+my $total_memory = Proxmox::Install::RunEnv::get('total_memory');
+my $arc_max = Proxmox::Install::Config::get_zfs_opt('arc_max') ||
($total_memory * 0.5);
+
+my $arc_max_adjustment = Gtk3::Adjustment->new(
+ $arc_max, $Proxmox::Install::RunEnv::ZFS_ARC_MIN_SIZE_MIB,
+ $total_memory, 1, 10, 0);
+my $spinbutton_arc_max = Gtk3::SpinButton->new($arc_max_adjustment, 1, 0);
+$spinbutton_arc_max->set_tooltip_text('Maximum ARC size in megabytes');
+$spinbutton_arc_max->signal_connect('value-changed' => sub {
+ my $w = shift;
+ Proxmox::Install::Config::set_zfs_opt('arc_max',
$w->get_value_as_int());
+});
- my $spinbutton_arc_max = Gtk3::SpinButton->new_with_range(
- $Proxmox::Install::RunEnv::ZFS_ARC_MIN_SIZE_MIB, $total_memory, 1);
- $spinbutton_arc_max->set_tooltip_text('Maximum ARC size in megabytes');
- $spinbutton_arc_max->signal_connect('value-changed' => sub {
- my $w = shift;
- Proxmox::Install::Config::set_zfs_opt('arc_max',
$w->get_value_as_int());
- });
- my $arc_max = Proxmox::Install::Config::get_zfs_opt('arc_max');
- $spinbutton_arc_max->set_value($arc_max);
- push @$labeled_widgets, ['ARC max size', $spinbutton_arc_max, 'MiB'];
-}
+push @$labeled_widgets, ['ARC max size', $spinbutton_arc_max, 'MiB'];
push @$labeled_widgets, ['hdsize', $hdsize_btn, 'GB'];
return $create_label_widget_grid->($labeled_widgets);;
--
2.45.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH installer v5 0/3] expose zfs arc size setting for all products
As suggested by Thomas, leaves the ZFS default if the user never touches the setting in the installer (i.e. not writing a modprobe file). See also the discussion in v1 [0]. [0] https://lists.proxmox.com/pipermail/pve-devel/2024-February/061659.html Testing === Tested the installation of PVE, PBS and PMG, with each once letting the arc size setting untouched and once setting it to some specific value. Also checked for each whether the correct default value was displayed. Afterwards, checked that for PVE the module parameter was always written to /etc/modprobe.d/, for PBS that it was only written in case it was explicitly set. History === v4: https://lists.proxmox.com/pipermail/pve-devel/2024-May/063957.html v3: https://lists.proxmox.com/pipermail/pve-devel/2024-April/062976.html v2: https://lists.proxmox.com/pipermail/pve-devel/2024-February/061667.html v1: https://lists.proxmox.com/pipermail/pve-devel/2023-November/060898.html Changes v4 -> v5: * rebased on latest master * tui: fixed value not persisting across dialog open/close for non-PVE Changes v3 -> v4: * rebased on latest master Changes v2 -> v3: * tui: when empty & focused, do not show the placeholder value at all * gui: rework using Gtk3::Adjustment based on Maximilanos suggestion Changes v1 -> v2: * rebased on latest master * add placeholder functionality for arc max size in TUI * "emulate" placeholder functionality in GTK on best-effort basis Diffstat Christoph Heiss (3): tui: NumericEditView: add optional placeholder value tui: expose arc size setting for zfs bootdisks for all products proxinstall: expose arc size setting for zfs bootdisks for all products Proxmox/Install/RunEnv.pm | 3 +- proxinstall | 26 - proxmox-installer-common/src/options.rs | 3 +- proxmox-tui-installer/src/views/bootdisk.rs | 48 +-- proxmox-tui-installer/src/views/mod.rs | 65 +++-- 5 files changed, 108 insertions(+), 37 deletions(-) -- 2.44.0 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH docs v4 1/2] qm: resource mapping: add description for `mdev` option
On Thu Jun 6, 2024 at 11:22 AM CEST, Dominik Csapak wrote: > in a new section about additional options > > Signed-off-by: Dominik Csapak > --- > no changes > qm.adoc | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/qm.adoc b/qm.adoc > index 42c26db..3f4e59a 100644 > --- a/qm.adoc > +++ b/qm.adoc > @@ -1802,6 +1802,19 @@ To create mappings `Mapping.Modify` on > `/mapping//` is necessary > To use these mappings, `Mapping.Use` on `/mapping//` is necessary > (in addition to the normal guest privileges to edit the configuration). > > +Additional Options > +^^ Omit the '^' line and use .Additional Options instead, to avoid: asciidoc: WARNING: qm.adoc: line 1806: section title out of sequence: expected level 3, got level 4 > + > +There are additional options when defining a cluster wide resource mapping. > +Currently there are the following options: > + > +* `mdev` (PCI): This marks the PCI device as being capable of providing "This marks the PCI device", but your 2/2 patch begins with "This marks the device", maybe add or remove the word "PCI" to stay consistent. > + `mediated devices`. When this is enabled, you can select a type when > + configuring it on the guest. If multiple PCI devices are selected for > + the mapping, the mediated device will be create on the first one where > + there are any available instances of the selected type. s/create/created/ "where there" could be avoided, e.g.: If multiple PCI devices are selected for the mapping, the mediated device will be created on the first device on which instances of the selected type are available. > + > + > Managing Virtual Machines with `qm` > > ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] FW: issues with Virtio-SCSI devicde on Proxmox...
Hello, what I have been trying to tell is that both virtio-scsi and virtio-network device on Proxmox are both getting configured on PCIE. I do not understand why you claim that virtio-scsi is not configured on PCIE. So both virtio-scsi and virtio-network devices on Proxmox are configured as legacy devices on PCIE and the virtio-network device works just fine and does get interrupts. I also believe that the virtio-scsi device is working fine and it does set the interrupt bit in the ISR register, but no interrupt gets delivered to the driver. I'm now trying to find out if the problem is on our side, i.e. that our PCIE "setup" is getting the interrupt, but not delivering it to the device. Or that we never got the interrupt and then the issue would most likely be in the Proxomox implementation. But your statement that other OS virtio-scsi devices are working fine might indicate the problem to be on our side. We do have a problem with interrupt delivery on Virtualbox (by Oracle) and they acknowledged an issue with bridges and interrupt routing, that's why I was contacting Proxmox to see if there could be an issue there too thanks /cmos ___ Christian Moser Mobile:+358-40-5022105 Email: c...@maklee.com URL: www.maklee.com -Original Message- From: Fiona Ebner Sent: Tuesday, August 13, 2024 11:56 To: Proxmox VE development discussion ; Christian Moser Subject: Re: [pve-devel] issues with Virtio-SCSI devicde on Proxmox... Hi, Am 12.08.24 um 12:40 schrieb Christian Moser: > Hello, > > I work for VSI (VMS Software Inc) which is porting the OpenVMS > operating system to x86. At this point we successfully on various > hypervisors, but have some issues on the KVM running on Proxmox. > > The OpenVMS VM works just fine with SATA disks and it also works with > for example virtio-network device etc., but trying to use virtio-scsi > hangs the driver. I have debugged this and I can successfully > configure the port/controller, send the IO request to the device. It then > gets processed by the device, which posts the results and sets the interrupt > bit in the ISR register, but it never asserts the interrupt hence the driver > never gets notified and the I/O hangs. > > I have tried both “virtio-scsi-pci” and “virtio-scsi-single”, but no > luck. The emulated virtio-scsi device is a legacy device. But then > again, the virtio-network device is also a legacy device and here we > are getting interrupts. One thing which bothers me is the fact that > the “legacy interrupt disable” bit is set in the PCI config space of > the virtio-scsi device (i.e. bit 10 at offset 4) > > Questions: > * is there a way to configure a modern virtio-scsi devcie (i.e. > disable_legacy=on) ? I've already answered this question when you asked in a mail addressed directly to me: Am 12.08.24 um 11:58 schrieb Fiona Ebner: > Hi, > > It seems that you either need to attach the "virtio-scsi-pci" device > to a pcie bus or explicitly set the "disable_legacy=on" option for the > device, neither of which Proxmox VE currently does or allows > configuring. The only way right now seems to be to attach the disk > yourself via custom arguments (the 'args' in the Proxmox VE VM > configuration), but then the disk will be invisible to Proxmox VE > operations which look at specific disk keys in the configuration! > > Feel free to open a feature request on our bug tracker to make this > configurable: https://bugzilla.proxmox.com/ > > P.S. Please write to the developer list rather than individual > developers for such questions in the feature: > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > Best Regards, > Fiona > * why is the legacy interrupt bit set in the PCI config space ? Most likely because the virtio-scsi-pci is configured without the "disable_legacy=on" option. If not explicitly set, the option will be "disable_legacy=auto" and when not attached to PCIe (which is the case for Proxmox VE currently), then legacy mode will be enabled. > * Are there any working driver for virtio-scsi on this KVM using Q35 > machine? i.e. any other OS The virtio drivers for Windows and the ones in Linux work just fine with our configuration. > Any thoughts why these interrupts are not getting delivered on the PCIE bus? We do not configure the virtio-scsi-pci on a PCIe bus currently, see my initial answer. Best Regards, Fiona ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] FW: issues with Virtio-SCSI devicde on Proxmox...
Alexandre,
thank you for your information. On another KVM, the virtio-scsi device has the
hardware id of 0x10481AF4, whereas on Proxmox is has 0x10041AF4, which is a
legacy device.
But after more testing, I do not think that the issue is related to legacy vs
modern device, but rather interrupt related, because our driver on Proxmox does
not receive the device interrupt. I'm doing now more homework on our side to
see if the system (i.e. OpenVMS) does get the interrupt, but is not delivering
it to the device. So I'm looking at out bus support code to check out things
related to interrupt delivery. If the system does get the interrupt (since the
virtio-scsi device did set the interrupt bit in the ISR register), then the
issue is on our side. If we do not get the interrupt at all, then there is
still something going with Proxmox and OpenVMS guest OS.
Thanks for your answers and pointers, but for now, I do some more homework
/cmos
___
Christian Moser
Mobile:+358-40-5022105
Email: c...@maklee.com
URL: www.maklee.com
-Original Message-
From: DERUMIER, Alexandre
Sent: Tuesday, August 13, 2024 19:13
To: pve-devel@lists.proxmox.com
Cc: c...@maklee.com
Subject: Re: [pve-devel] issues with Virtio-SCSI devicde on Proxmox...
Hi,
Currently they are no way to add custom options for virtio-devices command line
from vm config, so it should be patched to add support for openvms os and add
special tuning.
for
example:https://git.proxmox.com/?p=qemu-server.git;a=blob_plain;f=PVE/QemuServer.pm;hb=HEAD
sub print_netdevice_full {
if ($conf->{ostype} && $conf->{ostype} eq 'openvms') {
tmpstr .= ",disable_legacy=on";
}
>>I have tried both “virtio-scsi-pci” and “virtio-scsi-single”, but no
>>luck. The emulated virtio-scsi device is a legacy device
>>
>>
>>Questions:
>>* is there a way to configure a modern virtio-scsi devcie (i.e.
>>disable_legacy=on) ?
>>
Do you mean than currently on proxmox, the default is legacy mode and and not
modern ? I was pretty sure than qemu was defaulting to modern,
and that you need to use ",disable-legacy=off,disable-modern=true" to switch
to legacy.
(and AFAIK, proxmox qemu version don't have any patch forcing legacy)
but maybe I'm wrong
maybe it's only enabled by default with pci-express (using q35 machine
model) ?
https://github.com/qemu/qemu/blob/9eb51530c12ae645b91e308d16196c68563ea883/docs/pcie.txt
"Virtio devices plugged into PCI Express ports are PCI Express devices and have
"1.0" behavior by default without IO support.
In both cases disable-legacy and disable-modern properties can be used to
override the behaviour."
in qemu code I see:
https://github.com/qemu/qemu/blob/9eb51530c12ae645b91e308d16196c68563ea883/hw/core/machine.c#L258
GlobalProperty hw_compat_2_6[] = {
{ "virtio-mmio", "format_transport_address", "off" },
/* Optional because not all virtio-pci devices support legacy mode */
{ "virtio-pci", "disable-modern", "on", .optional = true },
{ "virtio-pci", "disable-legacy", "off", .optional = true }, }; const
size_t hw_compat_2_6_len = G_N_ELEMENTS(hw_compat_2_6);
so I'm really not sure what is the real default
do you have qemu command line of another kvm hypervisor
(ovirt,rhev,...) where it's working correctly ? Maybe they are enabling modern
bits manually , when a virtio device is supporting it ?
Message initial
De: Christian Moser
Répondre à: Proxmox VE development discussion
À: pve-devel@lists.proxmox.com
Cc: Christian Moser
Objet: [pve-devel] issues with Virtio-SCSI devicde on Proxmox...
Date: 12/08/2024 12:40:10
Hello,
I work for VSI (VMS Software Inc) which is porting the OpenVMS operating system
to x86. At this point we successfully on various hypervisors, but have some
issues on the KVM running on Proxmox.
The OpenVMS VM works just fine with SATA disks and it also works with for
example virtio-network device etc., but trying to use virtio-scsi hangs the
driver. I have debugged this and I can successfully configure the
port/controller, send the IO request to the device. It then gets processed by
the device, which posts the results and sets the interrupt bit in the ISR
register, but it never asserts the interrupt hence the driver never gets
notified and the I/O hangs.
I have tried both “virtio-scsi-pci” and “virtio-scsi-single”, but no luck. The
emulated virtio-scsi device is a legacy device. But then again, the
virtio-network device is also a legacy device and here we are getting
interrupts. One thing which bothers me is the fact that the “legacy interrupt
disable” bit is set in the PCI config space of the virtio-scsi device (i.e. bit
10 at offset 4)
Questions:
* is there a way to configure a modern virtio-scsi devcie (i.e.
disable_legacy=on) ?
* why is the legacy interrupt bit set in the PCI config space ?
* Are there any working driver for virt
[pve-devel] FW: issues with Virtio-SCSI devicde on Proxmox...
Alexandre, the statement below is not true for our case. The OpenVMS guest OS is using a PCIE bus, so the virtio-scsi device should be exposed as "modern", but is not. Not sure why not at this point /cmos ___ Christian Moser Mobile:+358-40-5022105 Email: c...@maklee.com URL: www.maklee.com -Original Message- From: DERUMIER, Alexandre Sent: Wednesday, August 14, 2024 09:45 To: pve-devel@lists.proxmox.com; c...@maklee.com Subject: Re: [pve-devel] issues with Virtio-SCSI devicde on Proxmox... Hi, I didn't see the responde of Fiona but indeed: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg01567.html "virtio devices can be exposed in upto three ways - Legacy - follows virtio 0.9 specification. always uses PCI ID range 0x1000-0x103F - Transitional - follows virtio 0.9 specification by default, but can auto-negotiate with guest for 1.0 spce. Always uses PCI ID range 0x1000-0x103F - Modern - follows virtio 1.0 specification. always uses PCI ID range 0x1040-0x107F With QEMU, historically devices placed on a PCI bus will always default to being in transitional mode, while devices placed on a PCI-E bus will always dfault to being in modern mode. " Message initial De: Fiona Ebner Répondre à: Proxmox VE development discussion À: Proxmox VE development discussion , Christian Moser Objet: Re: [pve-devel] issues with Virtio-SCSI devicde on Proxmox... Date: 13/08/2024 10:55:47 Hi, Am 12.08.24 um 12:40 schrieb Christian Moser: > Hello, > > I work for VSI (VMS Software Inc) which is porting the OpenVMS > operating system to x86. At this point we successfully on various > hypervisors, but have some issues on the KVM running on Proxmox. > > The OpenVMS VM works just fine with SATA disks and it also works with > for example virtio-network device etc., but trying to use virtio-scsi > hangs the driver. I have debugged this and I can successfully > configure the port/controller, send the IO request to the device. It > then gets processed by the device, which posts the results and sets > the interrupt bit in the ISR register, but it never asserts the > interrupt hence the driver never gets notified and the I/O hangs. > > I have tried both “virtio-scsi-pci” and “virtio-scsi-single”, but no > luck. The emulated virtio-scsi device is a legacy device. But then > again, the virtio-network device is also a legacy device and here we > are getting interrupts. One thing which bothers me is the fact that > the “legacy interrupt disable” bit is set in the PCI config space of > the virtio-scsi device (i.e. bit 10 at offset 4) > > Questions: > * is there a way to configure a modern virtio-scsi devcie (i.e. > disable_legacy=on) ? I've already answered this question when you asked in a mail addressed directly to me: Am 12.08.24 um 11:58 schrieb Fiona Ebner: > Hi, > > It seems that you either need to attach the "virtio-scsi-pci" device > to a pcie bus or explicitly set the "disable_legacy=on" option for the > device, neither of which Proxmox VE currently does or allows > configuring. The only way right now seems to be to attach the disk > yourself via custom arguments (the 'args' in the Proxmox VE VM > configuration), but then the disk will be invisible to Proxmox VE > operations which look at specific disk keys in the configuration! > > Feel free to open a feature request on our bug tracker to make this > configurable: > https://antiphishing.vadesecure.com/v4?f=MDk0SW9xRkhTVGYydkJlTIW3tbTr > aK7neiUoWcvis0-pokd-Q2cwuWCZhgBcTw_yw4KqJS-oP6jCsk-zj- > 1YMQ&i=ZURHSDhnY0huQ2tPS3VZahJdhRaQu1ItpJrYkl8wXrA&k=q1N6&r=RjIyR1Rob > kVxVWlHTXhKT3I72JjP2S9ryFg3B_csBogfeb2oROpP8B8yUJUd6awk&s=1aab5a2ada7 > 3beb46aa02df4e18ff6c5ba2db6d6ff2d1f302a3c4c83b13c8ef6&u=https%3A%2F%2 > Fbugzilla.proxmox.com%2F > > P.S. Please write to the developer list rather than individual > developers for such questions in the feature: > https://antiphishing.vadesecure.com/v4?f=MDk0SW9xRkhTVGYydkJlTIW3tbTr > aK7neiUoWcvis0-pokd-Q2cwuWCZhgBcTw_yw4KqJS-oP6jCsk-zj- > 1YMQ&i=ZURHSDhnY0huQ2tPS3VZahJdhRaQu1ItpJrYkl8wXrA&k=q1N6&r=RjIyR1Rob > kVxVWlHTXhKT3I72JjP2S9ryFg3B_csBogfeb2oROpP8B8yUJUd6awk&s=50133960c87 > 16b5426bc084f398f7760f04af8739fd68cad36d17b1dcd887778&u=https%3A%2F%2 > Flists.proxmox.com%2Fcgi-bin%2Fmailman%2Flistinfo%2Fpve-devel > > Best Regards, > Fiona > * why is the legacy interrupt bit set in the PCI config space ? Most likely because the virtio-scsi-pci is configured without the "disable_legacy=on" option. If not explicitly set, the option will be "disable_legacy=auto" and when not attached to PCIe (which is the case for Proxmox VE currently), then legacy mode will be enabled. > * Are there any working driver for virtio-scsi on this KVM using Q35 > machine? i.e. any other OS The virtio drivers for Windows and the ones in Linux
Re: [pve-devel] FW: issues with Virtio-SCSI devicde on Proxmox...
I'm talking about virtio-scsi. Our virtio-network device is working fine
Sent from BlueMail
Get BlueMail for Android
On Aug 14, 2024, 15:22, at 15:22, "DERUMIER, Alexandre"
wrote:
>>>Alexandre,
>>>
>>>the statement below is not true for our case. The OpenVMS guest OS is
>>>using a PCIE bus, so the virtio-scsi device should be exposed as
>>>"modern", but is not. Not sure why not at this point
>
>See Fiona response,
>
>the pci express bridge is present, but the virtio-net is plugged on a
>simple pci bridge.
>
>pci express slots are mostly used for passthrough devices
>
>/usr/share/perl5/PVE/QemuServer/PCI.pm
>
>my $pcie_addr_map;
>sub get_pcie_addr_map {
>$pcie_addr_map = {
>vga => { bus => 'pcie.0', addr => 1 },
>hostpci0 => { bus => "ich9-pcie-port-1", addr => 0 },
>hostpci1 => { bus => "ich9-pcie-port-2", addr => 0 },
>hostpci2 => { bus => "ich9-pcie-port-3", addr => 0 },
>hostpci3 => { bus => "ich9-pcie-port-4", addr => 0 },
>hostpci4 => { bus => "ich9-pcie-port-5", addr => 0 },
>hostpci5 => { bus => "ich9-pcie-port-6", addr => 0 },
>hostpci6 => { bus => "ich9-pcie-port-7", addr => 0 },
>hostpci7 => { bus => "ich9-pcie-port-8", addr => 0 },
>hostpci8 => { bus => "ich9-pcie-port-9", addr => 0 },
>hostpci9 => { bus => "ich9-pcie-port-10", addr => 0 },
>hostpci10 => { bus => "ich9-pcie-port-11", addr => 0 },
>hostpci11 => { bus => "ich9-pcie-port-12", addr => 0 },
>hostpci12 => { bus => "ich9-pcie-port-13", addr => 0 },
>hostpci13 => { bus => "ich9-pcie-port-14", addr => 0 },
>hostpci14 => { bus => "ich9-pcie-port-15", addr => 0 },
>hostpci15 => { bus => "ich9-pcie-port-16", addr => 0 },
># win7 is picky about pcie assignments
>hostpci0bus0 => { bus => "pcie.0", addr => 16 },
>hostpci1bus0 => { bus => "pcie.0", addr => 17 },
>hostpci2bus0 => { bus => "pcie.0", addr => 18 },
>hostpci3bus0 => { bus => "pcie.0", addr => 19 },
>ivshmem => { bus => 'pcie.0', addr => 20 },
>hostpci4bus0 => { bus => "pcie.0", addr => 9 },
>hostpci5bus0 => { bus => "pcie.0", addr => 10 },
>hostpci6bus0 => { bus => "pcie.0", addr => 11 },
>hostpci7bus0 => { bus => "pcie.0", addr => 12 },
>hostpci8bus0 => { bus => "pcie.0", addr => 13 },
>hostpci9bus0 => { bus => "pcie.0", addr => 14 },
>hostpci10bus0 => { bus => "pcie.0", addr => 15 },
>hostpci11bus0 => { bus => "pcie.0", addr => 21 },
>hostpci12bus0 => { bus => "pcie.0", addr => 22 },
>hostpci13bus0 => { bus => "pcie.0", addr => 23 },
>hostpci14bus0 => { bus => "pcie.0", addr => 24 },
>hostpci15bus0 => { bus => "pcie.0", addr => 25 },
>}
>
>___
>Christian Moser
>Mobile: +358-40-5022105
>Email: c...@maklee.com
>URL: www.maklee.com
>-Original Message-
>From: DERUMIER, Alexandre
>Sent: Wednesday, August 14, 2024 09:45
>To: pve-devel@lists.proxmox.com; c...@maklee.com
>Subject: Re: [pve-devel] issues with Virtio-SCSI devicde on Proxmox...
>
>Hi,
>
>I didn't see the responde of Fiona but indeed:
>
>https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg01567.html
>
>"virtio devices can be exposed in upto three ways
>
> - Legacy - follows virtio 0.9 specification. always uses PCI
> ID range 0x1000-0x103F
> - Transitional - follows virtio 0.9 specification by default, but
> can auto-negotiate with guest for 1.0 spce. Always
> uses PCI ID range 0x1000-0x103F
> - Modern - follows virtio 1.0 specification. always uses PCI
> ID range 0x1040-0x107F
>
>With QEMU, historically devices placed on a PCI bus will always default
>to being in transitional mode, while devices placed on a PCI-E bus will
>always dfault to being in modern mode.
>"
>
>
> Message initial
>De: Fiona Ebner
>Répondre à: Proxmox VE development discussion de...@lists.proxmox.com>
>À: Proxmox VE development discussion ,
>Christian Moser
>Objet: Re: [pve-devel] issues with Virtio-SCSI devicde on Proxmox...
>Date: 13/08/2024 10:55:47
>
>Hi,
>
>Am 12.08.24 um 12:40 schrieb Christian Moser:
>> Hello,
>>
>> I work for VSI (VMS Software Inc) which is porting the OpenVMS
>> operating system to x86. At this point we successfully on various
>> hypervisors, but have some issues on the KVM running on Proxmox.
>>
>> The OpenVMS VM works just fine with SATA disks and it also works with
>> for example virtio-network device etc., but trying to use virtio-scsi
>> hangs the driver. I have debugged this and I can successfully
>> configure the port/controller, send the IO request to the device. It
>> then gets processed by the device, which posts the results and sets
>> the interrupt bit in the ISR register, but it never asserts the
>> interrupt hence the driver never gets notified
