| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
| |
These were previously just silently discarded.
|
| | |
|
| |
|
|
| |
This broke sandboxing
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
we're gonna need this to send all of VirtioDevice over a socket
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This will allow more easily sending types other than File over
sockets, (e.g., UnixSeqpacket).
|
| | |
|
| |
|
|
|
| |
This patch is designed not for efficiency, but for minimal code
footprint for experimentation. Hence, Box.
|
| |
|
|
|
|
|
|
|
|
| |
Doing this in its own function, jail_device, which returns a simple record
struct (JailInfo), means that callers can do other things with the
jailed device than just configure a ProxyDevice.
This will make it possible to have a program that acts only as a jail
supervisor, and which forwards its socket to a CrosVM to be put into a
ProxyDevice in that process.
|
| |
|
|
|
|
|
| |
Jail functionality has been moved into a new JailedDevice struct,
which wraps ProxyDevice.
Doing this allows ProxyDevice to be much more generic and reusable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a DiskCommand was received on the crosvm socket before the
virtio-block device was activated, the Token::VmRequest case in the
main event loop would forward the request to the block device socket,
and then wait syncronously for a response. That response would never
come because the device hadn't been activated, and it would never be
activated because the event loop would never continue, and therefore
never be able to respond to the event that causes the device to be
activated. crosvm would therefore just hang forever, waiting for a
response that would never come.
This patch fixes this deadlock by keeping track of whether devices
that send a response in this way have been activated yet. If they
have already been activated, messages are sent and responses are
received as normal. If they have not been activated, messages are
instead put into a per-device queue. Once the device is activated,
queued messages are processed all at once, and then the device is
marked as ready, and the queue is dropped. Future messages are
processed immediately as they come in, with no further queueing.
A device indicates that it is ready by sending a message on its
socket. The main crosvm event loop can then poll the socket, to be
notified when the device is ready. This poll event will only trigger
once -- once it has been received, it is removed from the poll
context.
Currently, the only device type that responds to external control
messages AND needs to be activated by an event is the block device.
The balloon device does not respond to messages, and the xhci
controller device is activated up front. The code is nevertheless
structured so that it should be very easy to drop another kind of
device in to the queuing system, should that be required.
Message-Id: <20200614114344.22642-3-hi@alyssa.is>
Notes:
Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Support a case where a guest client who may use arbitrary numbers of
buffers. (e.g. C2V4L2Component with default pool in ARCVM)
Such a client is valid as long as it uses at most 32 buffers at the same
time.
More specifically, this CL allows the guest to call ResourceCreate for an
output resource_id which was already processed by the host. Such
ResourceCreate calls will be handled as reassignment of DMAbuf to a
FrameBufferId.
BUG=b:157702336
TEST=Play a YouTube video on ARCVM w/ C2V4L2Component using default pool
Change-Id: Ie9c457867abd91b6b7a17a5bca4a1a1e9f53c1ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2198327
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The separate Vm functions for MemoryMappings and MemoryMappingArenas
have been combined and now use a MappedRegion trait that the mappings
implement. msync_memory_region replaces the get_mmap_arena function,
which is used by VmMsyncRequest. Since Vm uses mutexes for cloning, it
can't return mem region references.
BUG=chromium:1077058
TEST=cargo test, cargo test -p sys_util, cargo test -p hypervisor
Change-Id: If257b16ee34d07820ae7ebdb9a3a598a41df013c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2202845
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
|