profile
viewpoint
Wang, Yu1 ywan170 Intel China, Beijing From Intel/Open Source Technology Center

shuox/acrn-hypervisor 0

Project ACRN hypervisor

ywan170/acrn-devicemodel 0

Project ACRN Device Model

ywan170/acrn-hypervisor 0

Project ACRN hypervisor

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentprojectacrn/acrn-hypervisor

Add null-ptr check and prevent WBINVD after pSRAM is initialized.

 void flush_address_space(void *addr, uint64_t size);  */ void invept(const void *eptp); +extern volatile bool psram_is_initialized; static inline void cache_flush_invalidate_all(void) {-	asm volatile ("   wbinvd\n" : : : "memory");+	if (psram_is_initialized == false)

Let's add one FIXME here... /* FIXME: This will impact the CR0.CD and WBINVD emulation */

qianwang-intel

comment created time in 25 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
CommitCommentEvent
CommitCommentEvent
CommitCommentEvent
CommitCommentEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

pull request commentprojectacrn/acrn-hypervisor

generic acpi_device layer for passthru-devices

@wenlingz, we will review in the mailing list.

lonzoc

comment created time in 2 months

pull request commentprojectacrn/acrn-hypervisor

generic acpi_device layer for passthru-devices

@lonzoc Thanks for your patches! Can you send your patches to acrn-dev@lists.projectacrn.org? The most developers'patches are review in that mailing list. You can follow https://lists.projectacrn.org/g/acrn-dev for subscribing.

lonzoc

comment created time in 2 months

pull request commentprojectacrn/acrn-hypervisor

dm: support to provide ACPI SSDT for UOS

I agree, my solution heavily depends on comline been correctly set.

And some resources haven't provide command line parameters interface like ioapic/pic... The acrn is designed for embedded products, it is not like could hypervisor. So needn't provide too much flexibility guest configurations. To my understanding, the acrn-dm have to modify per products..

lonzoc

comment created time in 2 months

pull request commentprojectacrn/acrn-hypervisor

dm: support to provide ACPI SSDT for UOS

For example, we passthrough one I2C bus to the guest os, and there is a audio codec under this I2C bus, if current acrn-dm design, we should add one ACPI node into passthrough.c and recompile the acrn-dm, but with --acpi-ssdt option, we can define the audio codec in one SSDT asl file and compile it using iasl and then pass it to acrn-dm.

I see you point. But actually this is one big topic, not just one dynamic insert vSSDT table. As you known, the ACPI device objects are usually describe the platform/board specific resources. Likes I2C Addr, I/O APIO pin, GPIO, etc. Lots of command line parameters are dependent each other, all of them need to be set otherwise the device will not work... Likes you expose one I2C device w/ your dynamic vSSDT table but hasn't map ioapic or gpio..

The simple way is hard code everything in the acrn-dm and distinguish devices via their IDs which specified in command line just like passthrough case. Otherwise, it is hard to check the correctness if everything are passed through command line parameter. Likes your way, we need to parse what resources in your vSSDT file and if all of them are set correctly in the command line...

lonzoc

comment created time in 2 months

pull request commentprojectacrn/acrn-hypervisor

dm: support to provide ACPI SSDT for UOS

This vSSDT table provide a way for adding new device into guest os without recompiling acrn-dm.

What device do you want to expose as this way? The device should has its own hardware resources(like mmio/pio/interrupt). Only expose the vSSDT table is not enough.

By our original design, the related ACPI DSDT table is insert during virtual devices initialization. W/o re-compile the acrn-dm, you can just add command line parameter to indicate which virtual devices you want to expose to the guest, and the mediator of virtual device should inject its own ACPI device entity if necessary. Even you want to passthrough some PCI devices, the related ACPI table should hard-code in hw/pci/passthrough.c. You can refer to :

static void write_dsdt_xdci(struct pci_vdev *dev) { pr_info("write virt-%x:%x.%x in dsdt for XDCI @ 00:15.1\n", dev->bus, dev->slot, dev->func);

dsdt_line("");
dsdt_line("Device (XDCI)");
dsdt_line("{");
dsdt_line("    Name (_ADR, 0x%04X%04X)", dev->slot, dev->func);
dsdt_line("    Name (_DDN, \"Broxton XDCI controller\")");
dsdt_line("    Name (_STR, Unicode (\"Broxton XDCI controller\"))");
dsdt_line("}");
dsdt_line("");

}

static void passthru_write_dsdt(struct pci_vdev dev) { ... / Provides ACPI extra info / if (device == 0x5aaa) / XDCI @ 00:15.1 to enable ADB */ write_dsdt_xdci(dev); ... }

lonzoc

comment created time in 2 months

pull request commentprojectacrn/acrn-hypervisor

dm: support to provide ACPI SSDT for UOS

@ywan170 We put board specific device which doesnt belong to the soc platform into vSSDT, like tochscreen, sensors, video codec, etc.

I think acrn-dm should be generic and doesn't need be recompiled when used at different board.

You want to pass the SOS's physical SSDT to guest through acrn-dm?

lonzoc

comment created time in 2 months

more