summary refs log tree commit diff
Commit message (Collapse)AuthorAge
* SerializerWithFds traitAlyssa Ross2020-06-15
|
* switch from poly_msg_socket to msg_socket2Alyssa Ross2020-06-15
|
* msg_socket2: initial commitAlyssa Ross2020-06-15
|
* debug_labelAlyssa Ross2020-06-15
|
* queue_max_sizesAlyssa Ross2020-06-15
|
* devices: return Vec from queue_max_sizesAlyssa Ross2020-06-15
|
* device_typeAlyssa Ross2020-06-15
|
* featuresAlyssa Ross2020-06-15
|
* get_device_capsAlyssa Ross2020-06-15
|
* get_device_barsAlyssa Ross2020-06-15
|
* be more panickyAlyssa Ross2020-06-15
|
* resetAlyssa Ross2020-06-15
|
* read_configAlyssa Ross2020-06-15
|
* ack_featuresAlyssa Ross2020-06-15
|
* write_configAlyssa Ross2020-06-15
|
* Don't give worker ownership of socketAlyssa Ross2020-06-15
|
* send MemoryParams in createAlyssa Ross2020-06-15
|
* move MemoryParams to devicesAlyssa Ross2020-06-15
|
* poly_msg_socketAlyssa Ross2020-06-15
| | | | we're gonna need this to send all of VirtioDevice over a socket
* poly_msg_socket: addAlyssa Ross2020-06-15
|
* extract create message from activateAlyssa Ross2020-06-15
|
* forward kill to/from wlAlyssa Ross2020-06-15
|
* drop lazy_staticAlyssa Ross2020-06-15
|
* the great renamingAlyssa Ross2020-06-15
|
* hacky construct Wl in external procAlyssa Ross2020-06-15
|
* vm_control: make MaybeOwnedFd genericAlyssa Ross2020-06-15
| | | | | This will allow more easily sending types other than File over sockets, (e.g., UnixSeqpacket).
* hacky working out-of-process virtio_wlAlyssa Ross2020-06-15
|
* devices: make virtio::Interrupt a traitAlyssa Ross2020-06-15
| | | | | This patch is designed not for efficiency, but for minimal code footprint for experimentation. Hence, Box.
* msg_socket: impl MsgOnSocket for WrappingAlyssa Ross2020-06-15
|
* arch: add public API for creating GuestMemoryAlyssa Ross2020-06-15
| | | | | | | | | | | | | For inter-guest communication, other processes need to be able to access guest memory, without creating a VM. GuestMemory, with its list of memory regions, can't derive MsgOnSocket. This means that GuestMemory structs can't (easily) be shared over a socket. However, all that is required to create a GuestMemory is a size, and on x86_64, a boolean has_bios field. The architecture differences can be encapsulated in a struct. It can be opaque outside of architecture-specific crates, so the rest of the code can remain architecture-independent.
* guest_memory: allow creating with an existing memfdAlyssa Ross2020-06-15
| | | | | This will allow creating GuestMemory structs representing memory of VMs being managed by other processes.
* devices: move jailing out of JailedDevice::newAlyssa Ross2020-06-15
| | | | | | | | | | 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.
* devices: don't jail in ProxyDevice constructorAlyssa Ross2020-06-15
| | | | | | | Jail functionality has been moved into a new JailedDevice struct, which wraps ProxyDevice. Doing this allows ProxyDevice to be much more generic and reusable.
* crosvm: fix balloon and USB sockets HEAD masterAlyssa Ross2020-06-15
| | | | | | | | | | | | | | | | | | | | 5bd2e7f606b726b598fdc26fe26a9b4029fab6d3 introduced queued_device_reqs to accomodate devices that are not ready to receive messages until they are activated in response to an event. But, devices that are ready immediately were not added to the map. When an event came in to one of these sockets (balloon and USB), the socket file descriptor would be looked up in queued_device_reqs, and crosvm would then crash because it wouldn't be found. The correct behaviour, which this patch implements, is to treat a missing entry the same as a Ready entry. An alternative would have been to add all other sockets to queued_device_reqs, and set them to Ready up front, but that would be more difficult to keep up to date than having a default. This way, only devices that need queueing need to be added to queued_device_reqs. Fixes: 5bd2e7f606b726b598fdc26fe26a9b4029fab6d3
* crosvm: fix deadlock on early VmRequestAlyssa Ross2020-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* msg_socket: introduce UnixSeqpacketExtAlyssa Ross2020-06-15
| | | | | | | | | | | | | | | | | | | | | | Occasionally, it is useful to be able to use UnixSeqpacket as a type that can represent any kind of MsgSocket. For example, to keep some MsgSockets of different types in a Vec. In this case, it may be known what type of messages should be sent over a socket, even though that may not be represantable in the type system. To accomodate this situation, this patch introduces send_msg_on_socket and recv_msg_on_socket methods on UnixSeqpacket, that can be used to send or receive any kind of MsgOnSocket. The caller is obviously responsible for ensuring that the messages being sent are of the type expected by the socket. This lack of type safety for message types is not ideal, and so MsgSender and MsgReceiver should still be preferred wherever possible. Message-Id: <20200614114344.22642-2-hi@alyssa.is> Notes: Reviewed-by: Cole Helbling <cole.e.helbling@outlook.com>
* crosvm: fmtAlyssa Ross2020-06-14
| | | | | I should have run this before committing 28d9682698d287d14cbe67a0ed7acc1427add320, but I did not.
* msg_socket: fix broken testsAlyssa Ross2020-06-14
| | | | I must have forgotten to test these after merging with upstream.
* Merge remote-tracking branch 'origin/master'Alyssa Ross2020-06-14
|\
| * io_uring: update for mmap api changeDylan Reid2020-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | A recent change to sys_util moved the definition of 'as_ptr' for an mmap to a new trait, include that trait here. Change-Id: Ib48113738fdace50e2dc7f72a5107dd95db867f9 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2241590 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Dylan Reid <dgreid@chromium.org>
| * resources: add address_from_pci_offset functionGurchetan Singh2020-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor current code and add tests. BUG=chromium:924405 TEST=compile and test Change-Id: I9476f3a4ffd8ae85fc95d6889ada6b056613bbfa Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2216447 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
| * kvm: use MappedRegion traitGurchetan Singh2020-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Reduces code duplication between MMIO and mmap arenas - Makes adding future types easier - Makes upcoming deprecation of kvm crate easier - Use BTreeMap instead of HashMap since it's more efficient BUG=chromium:924405 TEST=compile and test Change-Id: I520abed0926489e64aac046e0dc0cfeb72fae7b2 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2216446 Tested-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Steven Richman <srichman@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
| * devices: video: dec: Support arbitrary buffers to be mapped as resourcesKeiichi Watanabe2020-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * seccomp: add policy file video_device on ARM.Alexandre Courbot2020-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=b:151399776 BUG=b:151394062 TEST=Video device is properly probed with policy enabled on a guest kernel with VIRTIO_VIDEO enabled. Change-Id: Ia29afa0ab3eb969291c046d8657cd28e88d54b96 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2230418 Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org> Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Tested-by: Alexandre Courbot <acourbot@chromium.org> Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
| * hypervisor: add Vm user memory region functionsSteven Richman2020-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * devices: irqchip: KvmKernelIrqchip x86_64 implColin Downs-Razouk2020-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implemented get/set_pic/ioapic/pit functions for the KvmKernelIrqchip. Added respective functions on KvmVm for interacting with the underlying KVM API. Added associated tests for get/set functions. BUG=chromium:1077058 TEST=ran devices tests and added get/set function tests Change-Id: I66a29828fe2f1fbdf54d7325656a003ac09e36d0 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2219422 Reviewed-by: Udam Saini <udam@google.com> Reviewed-by: Stephen Barber <smbarber@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Colin Downs-Razouk <colindr@google.com>
| * README: Document permissions needed for running.Andrew Walbran2020-06-05
| | | | | | | | | | | | | | | | | | Change-Id: Ia86cb49ffc89ad66fe67698e05968e6d6f19f743 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2231364 Auto-Submit: Andrew Walbran <qwandor@google.com> Reviewed-by: Stephen Barber <smbarber@chromium.org> Commit-Queue: Stephen Barber <smbarber@chromium.org> Tested-by: Stephen Barber <smbarber@chromium.org>
| * io_uring: Take Vecs or iterators of iovecsDylan Reid2020-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pointer passed to the kernel for the iovecs must remain valid until the operation completes. This is true even if the kernel copies the sqe containing the pointer, that isn't a deep copy. If the iovecs are freed before the kernel actually processes the op, it will fail with a bad address error. Move the responsibility for maintaining the list in memory from the caller to io_uring itself. This mean io_uring must allocate. Taking iterators for IoSlice/IoSliceMut, means that the caller doesn't need to allocate as well if there isn't a Vec already allocated. Change-Id: I63a009d8ab543c8bac4132809fb851536d4ad82c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2227082 Reviewed-by: Dylan Reid <dgreid@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Dylan Reid <dgreid@chromium.org>
| * devices: irqchip: IrqChipX86_64 traitColin Downs-Razouk2020-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This trait handles the x86-specific features of an irqchip, including getting and setting the state of the pic, ioapic, lapics, and pit. Also includes an empty implementation of this trait for the KvmKernelIrqChip. BUG=chromium:1077058 TEST=cargo test -p devices Change-Id: I36034661f4a2baedc7ac2b8f311cab6327afefba Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197717 Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Colin Downs-Razouk <colindr@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org>
| * devices: fs: Use 2 stage create and mkdirChirantan Ekbote2020-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When creating a file or directory the virtio-fs server changes its effective uid and gid to the uid and gid of the process that made the call. This ensures that the file or directory has the correct owner and group when it is created and also serves as an access check to ensure that the process that made the call has permission to modify the parent directory. However, this causes an EACCES error when the following conditions are met: * The parent directory has g+rw permissions with gid A * The process has gid B but has A in its list of supplementary groups In this case the fuse context only contains gid B, which doesn't have permission to modify the parent directory. Unfortunately there's no way for us to detect this on the server side so instead we just have to rely on the permission checks carried out by the kernel driver. If the server receives a create call, then assume that the kernel has verified that the process is allowed to create that file/directory and just create it without changing the server thread's uid and gid. Additionally, in order to ensure that a newly created file appears atomically in the parent directory with the proper owner and group, change the create implementation to use `O_TMPFILE` and `linkat` as described in the open(2) manpage. There is no `O_TMPFILE` equivalent for directories so create a "hidden" directory with a randomly generated name, modify the uid/gid and mode, and then rename it into place. BUG=b:156696212 TEST=tast run $DUT vm.Virtiofs TEST=Create a test directory with group wayland and permissions g+rw. Then run `su -s /bin/bash -c 'touch ${dir}/foo' - crosvm` and `su -s /bin/bash -c 'mkdir ${dir}/bar' - crosvm`. Change-Id: If5fbcb1b011664c7c1ac29542a2f90d129c34962 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2217534 Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org> Tested-by: Chirantan Ekbote <chirantan@chromium.org>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-06-15 23:33:06 +0000