On Fri, Jul 02, 2021 at 11:05:54PM +0800, Ming Lei wrote:
> blk-mq needs to know if the device uses managed irq, so add one field
> to virtio_device for recording if device uses managed irq.
>
> If the driver use managed irq, this flag has to be set so it can be
> passed to blk-mq.
>
> Cc:
blk-mq needs to know if the device uses managed irq, so add one field
to virtio_device for recording if device uses managed irq.
If the driver use managed irq, this flag has to be set so it can be
passed to blk-mq.
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc:
Disable some tests from building on EFI. These fail early, and need some
adaptation (eg. inline asm changes / AP initialization / memory
reclamation from EFI).
Eg, asyncpf: runs out of memory since the allocator only uses the largest
EFI_CONVENTIONAL_MEMORY block.
hyperv_*: untested with EFI.
EFI sets up long mode with arbitrary state before calling the
image entrypoint. To run the testcases at hand, it is necessary
to redo some of the bootstrapping to not rely on what EFI
provided.
Adapt start64() for EFI testcases to fixup %rsp/GDT/IDT/TSS and
friends, and jump here after relocation
The largest EFI_CONVENTIONAL_MEMORY chunk is passed over to
alloc_phys for the testcase.
Signed-off-by: Varad Gautam
---
x86/efi_main.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/x86/efi_main.c b/x86/efi_main.c
index 00e7086..237d4e7
kvm-unit-tests produces tests as ELF binaries that can't be directly
loaded with EFI. One way of doing so however, is to build the tests
as shared libs (-pic, -shared), and then objcopy-ing out the relevant
sections into a PE32+.
This adds support to compile the tests as an intermediary .so lib,
EFI calls _efi_pe_entry in long mode with the location of EFI
handle/system table. Add an efi_main() C handler to make it easier
to communicate with EFI for initial setup. efi_main will later,
1. Acquire the efi memmap
2. Call ExitBootServices
3. Perform remaining bootstrapping before calling the
This series brings EFI support to a reduced subset of kvm-unit-tests
on x86_64. I'm sending it out for early review since it covers enough
ground to allow adding KVM testcases for EFI-only environments.
EFI support works by changing the test entrypoint to a stub entry
point for the EFI loader to
EFI expects a relocatable PE, and the loader will patch in the
relocations from the COFF.
Since we are wrapping an ELF into a PE here, the EFI loader will
not handle ELF relocations, and we need to patch the ELF .dynamic
section manually on early boot.
Signed-off-by: Varad Gautam
---
On Fri, Jul 02, 2021 at 04:46:47PM +0800, Jie Deng wrote:
> Add an I2C bus driver for virtio para-virtualization.
>
> The controller can be emulated by the backend driver in
> any device model software by following the virtio protocol.
>
> The device specification can be found on
>
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device specification can be found on
https://lists.oasis-open.org/archives/virtio-comment/202101/msg8.html.
By
The bochs driver is only ~600 lines of code. Putting it into tiny/
cleans up the DRM directory slightly. Some style problems were fixed
and unneeded include statements were removed. No functional changes.
v2:
* make bochs_mode_funcs static (Daniel, kernel test robot)
* rebase onto
Convert to managed GEM VRAM initialization and switch bochs to
full autocleanup.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/bochs.c | 43 +---
1 file changed, 5 insertions(+), 38 deletions(-)
diff --git
All GEM-VRAM-based drivers use auto-cleanup via drmm_vram_helper_init().
Unexport the manual APIs and make them internal implementation.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 9 +++--
include/drm/drm_gem_vram_helper.h | 4
Move the bochs driver to tiny/ and simplify the clean-up code. Also
update GEM VRAM helpers accordingly.
v2:
* make bochs_mode_funcs static (Daniel, kernel test robot)
Thomas Zimmermann (3):
drm/bochs: Move to tiny/
drm/bochs: Use managed initialization for GEM VRAM helpers
On 02-07-21, 15:15, Jie Deng wrote:
> Then what is the need to design this interface as "return the number of
> messages successfully
> processed, or a negative value on error". Just return success or fail is
> enough.
Right, that isn't clear to me as well. And so I asked Wolfram this yesterday.
On 2021/7/2 14:56, Viresh Kumar wrote:
On 02-07-21, 14:52, Jie Deng wrote:
This is not efficient. If adding the ith request to the queue fails, we can
still send
the requests before it.
Not really. Normally the requests which are sent together by clients, are linked
together, like a state
On 02-07-21, 14:52, Jie Deng wrote:
> This is not efficient. If adding the ith request to the queue fails, we can
> still send
>
> the requests before it.
Not really. Normally the requests which are sent together by clients, are linked
together, like a state machine. So if the first one is sent,
On 2021/7/2 12:55, Viresh Kumar wrote:
On 01-07-21, 21:24, Wolfram Sang wrote:
I just noticed this now, but this function even tries to send data
partially, which isn't right. If the caller (i2c device's driver)
calls this for 5 struct i2c_msg instances, then all 5 need to get
through or
> From: Jason Wang
> Sent: Thursday, July 1, 2021 1:13 PM
>
>
> Actually it depends on what attributes is required for building the config.
>
> We can simply reuse the existing virtio_net_config, if most of the fields are
> required.
>
> struct virtio_net_config_set {
> __virtio64
20 matches
Mail list logo
