search for: 9pfs

...e raw data of a guest to text data on a host, information of debugfs in the guest is also needed on the host. In other words, the guest's debugfs must be exposed (mounted) on the host via other serial line (we don't like to depend on network connection). For this purpose, we'll use DIOD 9pfs server (http://code.google.com/p/diod/) as below. ***HOW TO USE*** We explain about how to translate raw data to text data on a host using trace-cmd applied this patch set and virtio-trace. - Preparation 1. Make FIFO in a host virtio-trace uses virtio-serial pipe as trace data paths as to the nu...

...e raw data of a guest to text data on a host, information of debugfs in the guest is also needed on the host. In other words, the guest's debugfs must be exposed (mounted) on the host via other serial line (we don't like to depend on network connection). For this purpose, we'll use DIOD 9pfs server (http://code.google.com/p/diod/) as below. ***HOW TO USE*** We explain about how to translate raw data to text data on a host using trace-cmd applied this patch set and virtio-trace. - Preparation 1. Make FIFO in a host virtio-trace uses virtio-serial pipe as trace data paths as to the nu...

...it out (virtio-ccw has to change the calling order for get_features, btw.) - have device set the bit and the transport mask it out later. Feels a bit weird, as virtio-1 is a transport feature bit. I'm tending towards the first option; smth like this (on top of my branch): diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index c29c8c8..f6501ea 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -24,6 +24,9 @@ static uint32_t virtio_9p_get_features(VirtIODevice *vdev, unsigned int index, uint32_t features...

...it out (virtio-ccw has to change the calling order for get_features, btw.) - have device set the bit and the transport mask it out later. Feels a bit weird, as virtio-1 is a transport feature bit. I'm tending towards the first option; smth like this (on top of my branch): diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index c29c8c8..f6501ea 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -24,6 +24,9 @@ static uint32_t virtio_9p_get_features(VirtIODevice *vdev, unsigned int index, uint32_t features...

...dd check that the bit is in a sane range - make it obvious at a glance what is going on - have a central point to change when we want to extend feature bits Convert existing code manipulating features to use the new helpers. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 16 ++++++++-------- hw/char/virtio-serial-bus.c | 2 +- hw/net/virtio-net.c | 34 +++++++++++++++++----------------- hw/s390x/virtio-ccw.c | 4 ++-- hw/virtio/virtio-mmio.c | 2 +- hw/virtio/virtio-pci.c...

...dd check that the bit is in a sane range - make it obvious at a glance what is going on - have a central point to change when we want to extend feature bits Convert existing code manipulating features to use the new helpers. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 16 ++++++++-------- hw/char/virtio-serial-bus.c | 2 +- hw/net/virtio-net.c | 34 +++++++++++++++++----------------- hw/s390x/virtio-ccw.c | 4 ++-- hw/virtio/virtio-mmio.c | 2 +- hw/virtio/virtio-pci.c...

...get features. So bit 32 is set, but not exposed to guests. In fact at least for PCI, we have a 32 bit field for features in 0.9 so it's automatic. Didn't check mmio yet. > I'm tending towards the first option; smth like this (on top of my > branch): > > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c > index c29c8c8..f6501ea 100644 > --- a/hw/9pfs/virtio-9p-device.c > +++ b/hw/9pfs/virtio-9p-device.c > @@ -24,6 +24,9 @@ > static uint32_t virtio_9p_get_features(VirtIODevice *vdev, unsigned int index, >...

...o build VM images, but they require being root, as these loopmounts partitions on which deboostrap is executed. Maybe installing grub2 needs access to block devices too. I was thinking of using libguestfs to sandbox those processes, by passing a build VM as a disk image and my build directory as a 9pfs mount to the appliance, and calling the build command via $g->shell(). Any pitfalls I should be aware while doing this ? Emmanuel

With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 2 +- hw/char/virtio-serial-bus.c | 2 +- hw/net/virtio-net.c | 22 +++++++++---------- hw/s390x/s390-virtio-bus.c | 3 ++- hw/s390x/s390-virtio-bus.h | 2 +- hw/s390x/virtio-ccw.c...

With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 2 +- hw/char/virtio-serial-bus.c | 2 +- hw/net/virtio-net.c | 22 +++++++++---------- hw/s390x/s390-virtio-bus.c | 3 ++- hw/s390x/s390-virtio-bus.h | 2 +- hw/s390x/virtio-ccw.c...

...lots of CONFIG_* options disabled, we need to address those problems > properly. > > (3) DAX / NVDIMM / etc - love them. Not supported upstream (either > kernel or qemu) yet. > > (4) Passthrough (eg 9p) filesystems. You touched on that above. > Red Hat doesn't much like 9pfs for several reasons, yet we also don't > have a plausible alternative at the moment. This is mainly a problem > for running fast Docker containers, rather than libguestfs though. Another thought: why does guestfish need to boot the appliance more than once? Could virsh save/restore or m...

...nd setting features with an additional index field, so that all feature bits may be accessed (in chunks of 32 bits). vhost and migration have been ignored for now. Reviewed-by: Thomas Huth <thuth at linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 7 ++++++- hw/block/virtio-blk.c | 9 +++++++-- hw/char/virtio-serial-bus.c | 9 +++++++-- hw/net/virtio-net.c | 38 ++++++++++++++++++++++++++------------ hw/s390x/s390-virtio-bus.c | 9 +++++---- hw/s390x/virtio-ccw.c |...

...nd setting features with an additional index field, so that all feature bits may be accessed (in chunks of 32 bits). vhost and migration have been ignored for now. Reviewed-by: Thomas Huth <thuth at linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 7 ++++++- hw/block/virtio-blk.c | 9 +++++++-- hw/char/virtio-serial-bus.c | 9 +++++++-- hw/net/virtio-net.c | 38 ++++++++++++++++++++++++++------------ hw/s390x/s390-virtio-bus.c | 9 +++++---- hw/s390x/virtio-ccw.c |...

With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 2 +- hw/char/virtio-serial-bus.c | 2 +- hw/core/qdev-properties.c | 58 +++++++++++++++++++++++++++++++++++++++ hw/net/virtio-net.c | 22 +++++++-------- hw/s390x/s390-virtio-bus.c | 3 +-...

With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 2 +- hw/char/virtio-serial-bus.c | 2 +- hw/core/qdev-properties.c | 58 +++++++++++++++++++++++++++++++++++++++ hw/net/virtio-net.c | 22 +++++++-------- hw/s390x/s390-virtio-bus.c | 3 +-...

...nd setting features with an additional index field, so that all feature bits may be accessed (in chunks of 32 bits). vhost and migration have been ignored for now. Reviewed-by: Thomas Huth <thuth at linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 7 ++++++- hw/block/virtio-blk.c | 9 +++++++-- hw/char/virtio-serial-bus.c | 9 +++++++-- hw/net/virtio-net.c | 38 ++++++++++++++++++++++++++------------ hw/s390x/s390-virtio-bus.c | 9 +++++---- hw/s390x/virtio-ccw.c |...

...nd setting features with an additional index field, so that all feature bits may be accessed (in chunks of 32 bits). vhost and migration have been ignored for now. Reviewed-by: Thomas Huth <thuth at linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 7 ++++++- hw/block/virtio-blk.c | 9 +++++++-- hw/char/virtio-serial-bus.c | 9 +++++++-- hw/net/virtio-net.c | 38 ++++++++++++++++++++++++++------------ hw/s390x/s390-virtio-bus.c | 9 +++++---- hw/s390x/virtio-ccw.c |...

...ram Gloger wrote: > Hi, > > Today I merged M. Tsirkin's patch v2 "virtio_net: fix race in RX VQ > processing": > > http://lkml.indiana.edu/hypermail/linux/kernel/1307.1/00503.html > > into 3.2.48 and lightly tested the result (vhost-net, virtio-disk > and 9pfs using virtio). This sounds like it could be suitable for stable, but that doesn't seem to have been requested by the author. I'm cc'ing those involved so they can make a decision whether this should be included in 3.2.y or other stable branches. > Merge is not completely trivial,...

...ram Gloger wrote: > Hi, > > Today I merged M. Tsirkin's patch v2 "virtio_net: fix race in RX VQ > processing": > > http://lkml.indiana.edu/hypermail/linux/kernel/1307.1/00503.html > > into 3.2.48 and lightly tested the result (vhost-net, virtio-disk > and 9pfs using virtio). This sounds like it could be suitable for stable, but that doesn't seem to have been requested by the author. I'm cc'ing those involved so they can make a decision whether this should be included in 3.2.y or other stable branches. > Merge is not completely trivial,...

Hi, I remembered reading about Intel Clear Containers [1], and Hyper/Qboot [2] that support startup times measured in the hundreds of miliseconds range. On an AMD FX(tm)-8350 'guestfish -a /dev/null run' takes ~4s when run the 2nd/3rd time: real 0m4.152s user 0m2.120s sys 0m0.564s Are there any plans on applying these improvements to the supermin appliance? I did some quick tests on