summaryrefslogtreecommitdiffstats
path: root/hw/9pfs/9p.h
Commit message (Collapse)AuthorAgeFilesLines
* 9pfs: Convert reclaim list to QSLISTGreg Kurz2021-01-221-1/+1
| | | | | | | | | | Use QSLIST instead of open-coding for a slightly improved readability. No behavioral change. Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20210122143514.215780-1-groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: Convert V9fsFidState::fid_list to QSIMPLEQGreg Kurz2021-01-211-2/+2
| | | | | | | | | | | The fid_list is currently open-coded. This doesn't seem to serve any purpose that cannot be met with QEMU's generic lists. Let's go for a QSIMPLEQ : this will allow to add new fids at the end of the list and to improve the logic in v9fs_mark_fids_unreclaim(). Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20210118142300.801516-3-groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: Convert V9fsFidState::clunked to boolGreg Kurz2021-01-211-1/+1
| | | | | | | | This can only be 0 or 1. Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20210118142300.801516-2-groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* hw/9pfs : open brace '{' following struct go on the same lineXinhao Zhang2020-11-051-6/+3Star
| | | | | | | | | | | Fix code style. Open braces for struct should go on the same line. Signed-off-by: Xinhao Zhang <zhangxinhao1@huawei.com> Signed-off-by: Kai Deng <dengkai1@huawei.com> Reported-by: Euler Robot <euler.robot@huawei.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20201030043515.1030223-2-zhangxinhao1@huawei.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
* 9pfs: differentiate readdir lock between 9P2000.u vs. 9P2000.LChristian Schoenebeck2020-08-121-5/+22
| | | | | | | | | | | | | | | | | | | | | | | | Previous patch suggests that it might make sense to use a different mutex type now while handling readdir requests, depending on the precise protocol variant, as v9fs_do_readdir_with_stat() (used by 9P2000.u) uses a CoMutex to avoid deadlocks that might happen with QemuMutex otherwise, whereas do_readdir_many() (used by 9P2000.L) should better use a QemuMutex, as the precise behaviour of a failed CoMutex lock on fs driver side would not be clear. And to avoid the wrong lock type being used, be now strict and error out if a 9P2000.L client sends a Tread on a directory, and likeweise error out if a 9P2000.u client sends a Treaddir request. This patch is just intended as transitional measure, as currently 9P2000.u vs. 9P2000.L implementations currently differ where the main logic of fetching directory entries is located at (9P2000.u still being more top half focused, while 9P2000.L already being bottom half focused in regards to fetching directory entries that is). Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <9a2ddc347e533b0d801866afd9dfac853d2d4106.1596012787.git.qemu_oss@crudebyte.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
* 9pfs: add new function v9fs_co_readdir_many()Christian Schoenebeck2020-08-121-0/+22
| | | | | | | | | | | | | | | | | | | | The newly added function v9fs_co_readdir_many() retrieves multiple directory entries with a single fs driver request. It is intended to replace uses of v9fs_co_readdir(), the latter only retrieves a single directory entry per fs driver request instead. The reason for this planned replacement is that for every fs driver request the coroutine is dispatched from main I/O thread to a background I/O thread and eventually dispatched back to main I/O thread. Hopping between threads adds latency. So if a 9pfs Treaddir request reads a large amount of directory entries, this currently sums up to huge latencies of several hundred ms or even more. So using v9fs_co_readdir_many() instead of v9fs_co_readdir() will provide significant performance improvements. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <73dc827a12ef577ae7e644dcf34a5c0e443ab42f.1596012787.git.qemu_oss@crudebyte.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
* 9pfs: make v9fs_readdir_response_size() publicChristian Schoenebeck2020-08-121-0/+1
| | | | | | | | | | | | | Rename function v9fs_readdir_data_size() -> v9fs_readdir_response_size() and make it callable from other units. So far this function is only used by 9p.c, however subsequent patches require the function to be callable from another 9pfs unit. And as we're at it; also make it clear for what this function is used for. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <3668ebc7d5b929a0e4f1357457060d96f50f76f4.1596012787.git.qemu_oss@crudebyte.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
* Revert "9p: init_in_iov_from_pdu can truncate the size"Stefano Stabellini2020-05-251-1/+1
| | | | | | | | | | This reverts commit 16724a173049ac29c7b5ade741da93a0f46edff7. It causes https://bugs.launchpad.net/bugs/1877688. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <20200521192627.15259-1-sstabellini@kernel.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9p: Lock directory streams with a CoMutexGreg Kurz2020-05-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Locking was introduced in QEMU 2.7 to address the deprecation of readdir_r(3) in glibc 2.24. It turns out that the frontend code is the worst place to handle a critical section with a pthread mutex: the code runs in a coroutine on behalf of the QEMU mainloop and then yields control, waiting for the fsdev backend to process the request in a worker thread. If the client resends another readdir request for the same fid before the previous one finally unlocked the mutex, we're deadlocked. This never bit us because the linux client serializes readdir requests for the same fid, but it is quite easy to demonstrate with a custom client. A good solution could be to narrow the critical section in the worker thread code and to return a copy of the dirent to the frontend, but this causes quite some changes in both 9p.c and codir.c. So, instead of that, in order for people to easily backport the fix to older QEMU versions, let's simply use a CoMutex since all the users for this sit in coroutines. Fixes: 7cde47d4a89d ("9p: add locking to V9fsDir") Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Message-Id: <158981894794.109297.3530035833368944254.stgit@bahia.lan> Signed-off-by: Greg Kurz <groug@kaod.org>
* qdev: Unrealize must not failMarkus Armbruster2020-05-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Devices may have component devices and buses. Device realization may fail. Realization is recursive: a device's realize() method realizes its components, and device_set_realized() realizes its buses (which should in turn realize the devices on that bus, except bus_set_realized() doesn't implement that, yet). When realization of a component or bus fails, we need to roll back: unrealize everything we realized so far. If any of these unrealizes failed, the device would be left in an inconsistent state. Must not happen. device_set_realized() lets it happen: it ignores errors in the roll back code starting at label child_realize_fail. Since realization is recursive, unrealization must be recursive, too. But how could a partly failed unrealize be rolled back? We'd have to re-realize, which can fail. This design is fundamentally broken. device_set_realized() does not roll back at all. Instead, it keeps unrealizing, ignoring further errors. It can screw up even for a device with no buses: if the lone dc->unrealize() fails, it still unregisters vmstate, and calls listeners' unrealize() callback. bus_set_realized() does not roll back either. Instead, it stops unrealizing. Fortunately, no unrealize method can fail, as we'll see below. To fix the design error, drop parameter @errp from all the unrealize methods. Any unrealize method that uses @errp now needs an update. This leads us to unrealize() methods that can fail. Merely passing it to another unrealize method cannot cause failure, though. Here are the ones that do other things with @errp: * virtio_serial_device_unrealize() Fails when qbus_set_hotplug_handler() fails, but still does all the other work. On failure, the device would stay realized with its resources completely gone. Oops. Can't happen, because qbus_set_hotplug_handler() can't actually fail here. Pass &error_abort to qbus_set_hotplug_handler() instead. * hw/ppc/spapr_drc.c's unrealize() Fails when object_property_del() fails, but all the other work is already done. On failure, the device would stay realized with its vmstate registration gone. Oops. Can't happen, because object_property_del() can't actually fail here. Pass &error_abort to object_property_del() instead. * spapr_phb_unrealize() Fails and bails out when remove_drcs() fails, but other work is already done. On failure, the device would stay realized with some of its resources gone. Oops. remove_drcs() fails only when chassis_from_bus()'s object_property_get_uint() fails, and it can't here. Pass &error_abort to remove_drcs() instead. Therefore, no unrealize method can fail before this patch. device_set_realized()'s recursive unrealization via bus uses object_property_set_bool(). Can't drop @errp there, so pass &error_abort. We similarly unrealize with object_property_set_bool() elsewhere, always ignoring errors. Pass &error_abort instead. Several unrealize methods no longer handle errors from other unrealize methods: virtio_9p_device_unrealize(), virtio_input_device_unrealize(), scsi_qdev_unrealize(), ... Much of the deleted error handling looks wrong anyway. One unrealize methods no longer ignore such errors: usb_ehci_pci_exit(). Several realize methods no longer ignore errors when rolling back: v9fs_device_realize_common(), pci_qdev_unrealize(), spapr_phb_realize(), usb_qdev_realize(), vfio_ccw_realize(), virtio_device_realize(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-17-armbru@redhat.com>
* 9pfs: require msize >= 4096Christian Schoenebeck2020-02-081-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A client establishes a session by sending a Tversion request along with a 'msize' parameter which client uses to suggest server a maximum message size ever to be used for communication (for both requests and replies) between client and server during that session. If client suggests a 'msize' smaller than 4096 then deny session by server immediately with an error response (Rlerror for "9P2000.L" clients or Rerror for "9P2000.u" clients) instead of replying with Rversion. So far any msize submitted by client with Tversion was simply accepted by server without any check. Introduction of some minimum msize makes sense, because e.g. a msize < 7 would not allow any subsequent 9p operation at all, because 7 is the size of the header section common by all 9p message types. A substantial higher value of 4096 was chosen though to prevent potential issues with some message types. E.g. Rreadlink may yield up to a size of PATH_MAX which is usually 4096, and like almost all 9p message types, Rreadlink is not allowed to be truncated by the 9p protocol. This chosen size also prevents a similar issue with Rreaddir responses (provided client always sends adequate 'count' parameter with Treaddir), because even though directory entries retrieval may be split up over several T/Rreaddir messages; a Rreaddir response must not truncate individual directory entries though. So msize should be large enough to return at least one directory entry with the longest possible file name supported by host. Most file systems support a max. file name length of 255. Largest known file name lenght limit would be currently ReiserFS with max. 4032 bytes, which is also covered by this min. msize value because 4032 + 35 < 4096. Furthermore 4096 is already the minimum msize of the Linux kernel's 9pfs client. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <8ceecb7fb9fdbeabbe55c04339349a36929fb8e3.1579567019.git.qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9p: init_in_iov_from_pdu can truncate the sizeGreg Kurz2020-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | init_in_iov_from_pdu might not be able to allocate the full buffer size requested, which comes from the client and could be larger than the transport has available at the time of the request. Specifically, this can happen with read operations, with the client requesting a read up to the max allowed, which might be more than the transport has available at the time. Today the implementation of init_in_iov_from_pdu throws an error, both Xen and Virtio. Instead, change the V9fsTransport interface so that the size becomes a pointer and can be limited by the implementation of init_in_iov_from_pdu. Change both the Xen and Virtio implementations to set the size to the size of the buffer they managed to allocate, instead of throwing an error. However, if the allocated buffer size is less than P9_IOHDRSZ (the size of the header) still throw an error as the case is unhandable. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> CC: groug@kaod.org CC: anthony.perard@citrix.com CC: roman@zededa.com CC: qemu_oss@crudebyte.com [groug: fix 32-bit build] Signed-off-by: Greg Kurz <groug@kaod.org>
* 9p: Use variable length suffixes for inode remappingChristian Schoenebeck2019-10-101-3/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use variable length suffixes for inode remapping instead of the fixed 16 bit size prefixes before. With this change the inode numbers on guest will typically be much smaller (e.g. around >2^1 .. >2^7 instead of >2^48 with the previous fixed size inode remapping. Additionally this solution is more efficient, since inode numbers in practice can take almost their entire 64 bit range on guest as well, so there is less likely a need for generating and tracking additional suffixes, which might also be beneficial for nested virtualization where each level of virtualization would shift up the inode bits and increase the chance of expensive remapping actions. The "Exponential Golomb" algorithm is used as basis for generating the variable length suffixes. The algorithm has a parameter k which controls the distribution of bits on increasing indeces (minimum bits at low index vs. maximum bits at high index). With k=0 the generated suffixes look like: Index Dec/Bin -> Generated Suffix Bin 1 [1] -> [1] (1 bits) 2 [10] -> [010] (3 bits) 3 [11] -> [110] (3 bits) 4 [100] -> [00100] (5 bits) 5 [101] -> [10100] (5 bits) 6 [110] -> [01100] (5 bits) 7 [111] -> [11100] (5 bits) 8 [1000] -> [0001000] (7 bits) 9 [1001] -> [1001000] (7 bits) 10 [1010] -> [0101000] (7 bits) 11 [1011] -> [1101000] (7 bits) 12 [1100] -> [0011000] (7 bits) ... 65533 [1111111111111101] -> [1011111111111111000000000000000] (31 bits) 65534 [1111111111111110] -> [0111111111111111000000000000000] (31 bits) 65535 [1111111111111111] -> [1111111111111111000000000000000] (31 bits) Hence minBits=1 maxBits=31 And with k=5 they would look like: Index Dec/Bin -> Generated Suffix Bin 1 [1] -> [000001] (6 bits) 2 [10] -> [100001] (6 bits) 3 [11] -> [010001] (6 bits) 4 [100] -> [110001] (6 bits) 5 [101] -> [001001] (6 bits) 6 [110] -> [101001] (6 bits) 7 [111] -> [011001] (6 bits) 8 [1000] -> [111001] (6 bits) 9 [1001] -> [000101] (6 bits) 10 [1010] -> [100101] (6 bits) 11 [1011] -> [010101] (6 bits) 12 [1100] -> [110101] (6 bits) ... 65533 [1111111111111101] -> [0011100000000000100000000000] (28 bits) 65534 [1111111111111110] -> [1011100000000000100000000000] (28 bits) 65535 [1111111111111111] -> [0111100000000000100000000000] (28 bits) Hence minBits=6 maxBits=28 Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9p: stat_to_qid: implement slow pathAntonios Motakis2019-10-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | stat_to_qid attempts via qid_path_prefixmap to map unique files (which are identified by 64 bit inode nr and 32 bit device id) to a 64 QID path value. However this implementation makes some assumptions about inode number generation on the host. If qid_path_prefixmap fails, we still have 48 bits available in the QID path to fall back to a less memory efficient full mapping. Signed-off-by: Antonios Motakis <antonios.motakis@huawei.com> [CS: - Rebased to https://github.com/gkurz/qemu/commits/9p-next (SHA1 7fc4c49e91). - Updated hash calls to new xxhash API. - Removed unnecessary parantheses in qpf_lookup_func(). - Removed unnecessary g_malloc0() result checks. - Log error message when running out of prefixes in qid_path_fullmap(). - Log warning message about potential degraded performance in qid_path_prefixmap(). - Wrapped qpf_table initialization to dedicated qpf_table_init() function. - Fixed typo in comment. ] Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9p: Added virtfs option 'multidevs=remap|forbid|warn'Antonios Motakis2019-10-101-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'warn' (default): Only log an error message (once) on host if more than one device is shared by same export, except of that just ignore this config error though. This is the default behaviour for not breaking existing installations implying that they really know what they are doing. 'forbid': Like 'warn', but except of just logging an error this also denies access of guest to additional devices. 'remap': Allows to share more than one device per export by remapping inodes from host to guest appropriately. To support multiple devices on the 9p share, and avoid qid path collisions we take the device id as input to generate a unique QID path. The lowest 48 bits of the path will be set equal to the file inode, and the top bits will be uniquely assigned based on the top 16 bits of the inode and the device id. Signed-off-by: Antonios Motakis <antonios.motakis@huawei.com> [CS: - Rebased to https://github.com/gkurz/qemu/commits/9p-next (SHA1 7fc4c49e91). - Added virtfs option 'multidevs', original patch simply did the inode remapping without being asked. - Updated hash calls to new xxhash API. - Updated docs for new option 'multidevs'. - Fixed v9fs_do_readdir() not having remapped inodes. - Log error message when running out of prefixes in qid_path_prefixmap(). - Fixed definition of QPATH_INO_MASK. - Wrapped qpp_table initialization to dedicated qpp_table_init() function. - Dropped unnecessary parantheses in qpp_lookup_func(). - Dropped unnecessary g_malloc0() result checks. ] Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> [groug: - Moved "multidevs" parsing to the local backend. - Added hint to invalid multidevs option error. - Turn "remap" into "x-remap". ] Signed-off-by: Greg Kurz <groug@kaod.org>
* 9p: Treat multiple devices on one export as an errorAntonios Motakis2019-10-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The QID path should uniquely identify a file. However, the inode of a file is currently used as the QID path, which on its own only uniquely identifies files within a device. Here we track the device hosting the 9pfs share, in order to prevent security issues with QID path collisions from other devices. We only print a warning for now but a subsequent patch will allow users to have finer control over the desired behaviour. Failing the I/O will be one the proposed behaviour, so we also change stat_to_qid() to return an error here in order to keep other patches simpler. Signed-off-by: Antonios Motakis <antonios.motakis@huawei.com> [CS: - Assign dev_id to export root's device already in v9fs_device_realize_common(), not postponed in stat_to_qid(). - error_report_once() if more than one device was shared by export. - Return -ENODEV instead of -ENOSYS in stat_to_qid(). - Fixed typo in log comment. ] Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> [groug, changed to warning, updated message and changelog] Signed-off-by: Greg Kurz <groug@kaod.org>
* 9p: xattr: Properly translate xattrcreate flagsKeno Fischer2018-06-071-0/+4
| | | | | | | | | As with unlinkat, these flags come from the client and need to be translated to their host values. The protocol values happen to match linux, but that need not be true in general. Signed-off-by: Keno Fischer <keno@juliacomputing.com> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9p: v9fs_path_copy() readabilityMarc-André Lureau2018-02-191-1/+1
| | | | | | | | lhs/rhs doesn't tell much about how argument are handled, dst/src is and const arguments is clearer in my mind. Use g_memdup() while at it. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: drop v9fs_register_transport()Greg Kurz2018-02-011-8/+2Star
| | | | | | | No good reasons to do this outside of v9fs_device_realize_common(). Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
* 9pfs: make pdu_marshal() and pdu_unmarshal() static functionsGreg Kurz2018-01-081-2/+0Star
| | | | | | | They're only used by the 9p core code. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com>
* 9pfs: fix some type definitionsGreg Kurz2018-01-081-6/+6
| | | | | | To comply with the QEMU coding style. Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: drop one user of struct V9fsFidStateGreg Kurz2017-11-061-4/+4
| | | | | | To comply with QEMU coding style. Signed-off-by: Greg Kurz <groug@kaod.org>
* virtio-9p: break device if buffers are misconfiguredGreg Kurz2017-06-291-1/+1
| | | | | | | The 9P protocol is transport agnostic: if the guest misconfigured the buffers, the best we can do is to set the broken flag on the device. Signed-off-by: Greg Kurz <groug@kaod.org>
* virtio-9p: message header is 7-byte longGreg Kurz2017-06-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | The 9p spec at http://man.cat-v.org/plan_9/5/intro reads: "Each 9P message begins with a four-byte size field specify- ing the length in bytes of the complete message including the four bytes of the size field itself. The next byte is the message type, one of the constants in the enumeration in the include file <fcall.h>. The next two bytes are an iden- tifying tag, described below." ie, each message starts with a 7-byte long header. The core 9P code already assumes this pretty much everywhere. This patch does the following: - makes the assumption explicit in the common 9p.h header, since it isn't related to the transport - open codes the header size in handle_9p_output() and hardens the sanity check on the space needed for the reply message Signed-off-by: Greg Kurz <groug@kaod.org> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
* virtio-9p/xen-9p: move 9p specific bits to core 9p codeGreg Kurz2017-05-251-1/+1
| | | | | | | | These bits aren't related to the transport so let's move them to the core code. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
* 9p: introduce a type for the 9p headerStefano Stabellini2017-04-211-0/+6
| | | | | | | | | | | | Use the new type in virtio-9p-device. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> CC: anthony.perard@citrix.com CC: jgross@suse.com CC: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Greg Kurz <groug@kaod.org>
* 9pfs: fix P9_NOTAG and P9_NOFID macrosGreg Kurz2017-01-031-2/+2
| | | | | | | | | | | | | | The u16 and u32 types don't exist in QEMU common headers. It never broke build because these two macros aren't use by the current code, but this is about to change with the future addition of functional tests for 9P. Also, these should have enclosing parenthesis to be usable in any syntactical situation. As suggested by Eric Blake, let's use UINT16_MAX and UINT32_MAX to address both issues. Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: introduce init_out/in_iov_from_pduStefano Stabellini2017-01-031-2/+4
| | | | | | | | | | | | | | | Not all 9pfs transports share memory between request and response. For those who don't, it is necessary to know how much memory is required in the response. Split the existing init_iov_from_pdu function in two: init_out_iov_from_pdu (for writes) and init_in_iov_from_pdu (for reads). init_in_iov_from_pdu takes an additional size parameter to specify the memory required for the response message. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: introduce transport specific callbacksStefano Stabellini2017-01-031-0/+19
| | | | | | | | | Don't call virtio functions from 9pfs generic code, use generic function callbacks instead. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: move pdus to V9fsStateStefano Stabellini2017-01-031-0/+1
| | | | | | | | | pdus are initialized and used in 9pfs common code. Move the array from V9fsVirtioState to V9fsState. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: convert 'len/copied_len' field in V9fsXattr to the type of uint64_tLi Qiang2016-11-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | The 'len' in V9fsXattr comes from the 'size' argument in setxattr() function in guest. The setxattr() function's declaration is this: int setxattr(const char *path, const char *name, const void *value, size_t size, int flags); and 'size' is treated as u64 in linux kernel client code: int p9_client_xattrcreate(struct p9_fid *fid, const char *name, u64 attr_size, int flags) So the 'len' should have an type of 'uint64_t'. The 'copied_len' in V9fsXattr is used to account for copied bytes, it should also have an type of 'uint64_t'. Suggested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Li Qiang <liqiang6-s@360.cn> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: add xattrwalk_fid field in V9fsXattr structLi Qiang2016-11-011-0/+1
| | | | | | | | | | | | Currently, 9pfs sets the 'copied_len' field in V9fsXattr to -1 to tag xattr walk fid. As the 'copied_len' is also used to account for copied bytes, this may make confusion. This patch add a bool 'xattrwalk_fid' to tag the xattr walk fid. Suggested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Li Qiang <liqiang6-s@360.cn> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
* virtio-9p: add reset handlerGreg Kurz2016-10-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Virtio devices should implement the VirtIODevice->reset() function to perform necessary cleanup actions and to bring the device to a quiescent state. In the case of the virtio-9p device, this means: - emptying the list of active PDUs (i.e. draining all in-flight I/O) - freeing all fids (i.e. close open file descriptors and free memory) That's what this patch does. The reset handler first waits for all active PDUs to complete. Since completion happens in the QEMU global aio context, we just have to loop around aio_poll() until the active list is empty. The freeing part involves some actions to be performed on the backend, like closing file descriptors or flushing extended attributes to the underlying filesystem. The virtfs_reset() function already does the job: it calls free_fid() for all open fids not involved in an ongoing I/O operation. We are sure this is the case since we have drained the PDU active list. The current code implements all backend accesses with coroutines, but we want to stay synchronous on the reset path. We can either change the current code to be able to run when not in coroutine context, or create a coroutine context and wait for virtfs_reset() to complete. This patch goes for the latter because it results in simpler code. Note that we also need to create a dummy PDU because it is also an API to pass the FsContext pointer to all backend callbacks. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
* 9pfs: use coroutine_fn annotation in hw/9pfs/9p.[ch]Greg Kurz2016-10-171-1/+1
| | | | | | | | | All these functions either call the v9fs_co_* functions which have the coroutine_fn annotation, or pdu_complete() which calls qemu_co_queue_next(). Let's mark them to make it obvious they execute in coroutine context. Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: fsdev: drop useless extern annotation for functionsGreg Kurz2016-10-171-9/+9
| | | | Signed-off-by: Greg Kurz <groug@kaod.org>
* 9pfs: introduce v9fs_path_sprintf() helperGreg Kurz2016-09-161-0/+1
| | | | | | | | | | | | | This helper is similar to v9fs_string_sprintf(), but it includes the terminating NUL character in the size field. This is to avoid doing v9fs_string_sprintf((V9fsString *) &path) and then bumping the size. Affected users are changed to use this new helper. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org>
* 9pfs: handle walk of ".." in the root directoryGreg Kurz2016-08-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The 9P spec at http://man.cat-v.org/plan_9/5/intro says: All directories must support walks to the directory .. (dot-dot) meaning parent directory, although by convention directories contain no explicit entry for .. or . (dot). The parent of the root directory of a server's tree is itself. This means that a client cannot walk further than the root directory exported by the server. In other words, if the client wants to walk "/.." or "/foo/../..", the server should answer like the request was to walk "/". This patch just does that: - we cache the QID of the root directory at attach time - during the walk we compare the QID of each path component with the root QID to detect if we're in a "/.." situation - if so, we skip the current component and go to the next one Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* Clean up ill-advised or unusual header guardsMarkus Armbruster2016-07-121-2/+2
| | | | | | | Cleaned up with scripts/clean-header-guards.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
* all: Remove unnecessary glib.h includesPeter Maydell2016-06-071-1/+0Star
| | | | | | | | | | | Remove glib.h includes, as it is provided by osdep.h. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* 9p: add locking to V9fsDirGreg Kurz2016-06-061-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | If several threads concurrently call readdir() with the same directory stream pointer, it is possible that they all get a pointer to the same dirent structure, whose content is overwritten each time readdir() is called. We must thus serialize accesses to the dirent structure. This may be achieved with a mutex like below: lock_mutex(); readdir(); // work with the dirent unlock_mutex(); This patch adds all the locking, to prepare the switch to readdir(). Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
* 9p: introduce the V9fsDir typeGreg Kurz2016-06-061-1/+5
| | | | | | | | | | If we are to switch back to readdir(), we need a more complex type than DIR * to be able to serialize concurrent accesses to the directory stream. This patch introduces a placeholder type and fixes all users. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
* 9p/fsdev: remove obsolete references to virtioGreg Kurz2016-06-061-2/+0Star
| | | | | | | | | | Most of the 9p code is now virtio agnostic. This patch does a final cleanup: - drop references to Virtio from the header comments - fix includes Also drop a couple of leading empty lines while here. Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
* all: Clean up includesPeter Maydell2016-02-231-2/+0Star
| | | | | | | | | | Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com>
* 9pfs: introduce V9fsVirtioStateWei Liu2016-01-121-5/+1Star
| | | | | | | | | V9fsState now only contains generic fields. Introduce V9fsVirtioState for virtio transport. Change virtio-pci and virtio-ccw to use V9fsVirtioState. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
* 9pfs: factor out v9fs_device_{,un}realize_commonWei Liu2016-01-081-0/+2
| | | | | Signed-off-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
* 9pfs: export pdu_{submit,alloc,free}Wei Liu2016-01-081-0/+3
| | | | | | | They will be used in later patches. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
* 9pfs: break out 9p.h from virtio-9p.hWei Liu2016-01-081-0/+325
Move out generic definitions from virtio-9p.h to 9p.h. Fix header inclusions. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-18 11:16:19 +0100