I dont think that is insecure.
as bhyve can passthrough real device to VM. as your point, that make
more insecure, right?
Such configuration will not enable by default.
if user intend to do it, system has this ability instead of not implement.
Simple is best, less is secure. I know that. but real
On Thu, 19 Mar 2020 at 14:09, Wanpeng Qian wrote:
> > Can't you do what something like pci_passthru.c does in passthru_init,
> > and open /dev/nvme0 in pci_nvme_init?
>
> Yes, you are correct. but that will make /dev/nvme0 keep open all the time.
> I just thinking when guest fire a logpage comman
Hello,
You are right about mapping 64-bit BARs.
=== (1) ===
The initial value of PCI_EMUL_MEMBASE64 is 0xD0 and it
corresponds to the 64-bit mmio window set by QWordMemory(...)
in DSDT from pci_bus_write_dsdt(), so guest VM gets from
UEFI BIOS this 64-bit window:
0x00D0-0x0
> Can't you do what something like pci_passthru.c does in passthru_init,
> and open /dev/nvme0 in pci_nvme_init?
Yes, you are correct. but that will make /dev/nvme0 keep open all the time.
I just thinking when guest fire a logpage command, open the /dev/nvme0
and get the SMART info. then close /de
Wanpeng Qian wrote this message on Wed, Mar 18, 2020 at 13:05 +0900:
> But currently bhyve has Capsicum capability, I cannot
> open /dev/nvme0 within pci_nvme.c without extra code.
> (currently I just disable the Capsicum capability)
>
> any feedback?
Can't you do what something like pci_passthru
Hi Robert
> I don't see why the guest needs to know about an implementation detail of the
> host hardware.
> If the host hardware is failing, that's something to be fixed on the host.
> The guest should never realize that something was broken.
I totally agree with you in this opinion. except on
I don't see why the guest needs to know about an implementation detail of the
host hardware.
If the host hardware is failing, that's something to be fixed on the host. The
guest should never realize that something was broken.
Just my opinion.
‐‐‐ Original Message ‐‐‐
On Wednesday, 18