* [PATCH v2] virtio-blk physical block size
From: Avi Kivity @ 2009-12-28 16:39 UTC (permalink / raw)
To: Rusty Russell; +Cc: qemu-devel, kvm, virtualization
This patch adds a physical block size attribute to virtio disks,
corresponding to /sys/devices/.../physical_block_size. It is defined as
the request alignment which will not trigger RMW cycles. This can be
important for modern disks which use 4K physical sectors (though they
still support 512 logical sectors), and for file-backed disk images (which
have both the underlying filesystem block size and their own allocation
granularity to consider).
Installers use this to align partitions to physical block boundaries.
Note the spec already defined blk_size as the performance rather than
minimum alignment. However the driver interpreted this as the logical
block size, so I updated the spec to match the driver assuming the driver
predates the spec and that this is an error.
Signed-off-by: Avi Kivity <avi@redhat.com>
--
v2: feature bit 7 was already used by an undocumented feature; use a new bit
--- virtio-spec-0.8.3.lyx.orig 2009-12-28 17:42:40.000000000 +0200
+++ virtio-spec-0.8.3.lyx 2009-12-28 18:37:39.000000000 +0200
@@ -4138,6 +4138,19 @@
(10) Maximum total sectors in an I/O.
\end_layout
+\begin_layout Description
+VIRTIO_BLK_F_PHYS_BLK_SIZE(11) Physical block size of disk (writes aligned
+ to this will not trigger read-modify-write cycles) is in
+\begin_inset Quotes erd
+\end_inset
+
+phys_blk_size
+\begin_inset Quotes erd
+\end_inset
+
+.
+\end_layout
+
\end_deeper
\begin_layout Description
Device
@@ -4214,6 +4227,11 @@
\begin_layout Plain Layout
+ u32 phys_blk_size;
+\end_layout
+
+\begin_layout Plain Layout
+
};
\end_layout
@@ -4241,9 +4259,9 @@
\begin_layout Enumerate
If the VIRTIO_BLK_F_BLK_SIZE feature is negotiated, the blk_size field can
- be read to determine the optimal sector size for the driver to use.
+ be read to determine the sector size for the driver to use.
This does not effect the units used in the protocol (always 512 bytes),
- but awareness of the correct value can effect performance.
+ but requests must be aligned to this size.
\end_layout
\begin_layout Enumerate
@@ -4257,6 +4275,13 @@
No requests should be submitted which go beyond this limit.
\end_layout
+\begin_layout Enumerate
+If the VIRTIO_BLK_F_PHYS_BLK_SIZE feature is negotiated, the phys_blk_size
+ field should be read to determine the hardware block size.
+ Smaller writes are liable to require read-modify-write cycles on behalf
+ of the underlying hardware, however they are still supported.
+\end_layout
+
\begin_layout Section*
Device Operation
\end_layout
^ permalink raw reply
* Re: [PATCH] vhost: access check thinko fixes
From: Rusty Russell @ 2010-01-04 2:22 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Al Viro, kvm, virtualization
In-Reply-To: <20091224060058.GA26101@redhat.com>
On Thu, 24 Dec 2009 04:30:58 pm Michael S. Tsirkin wrote:
> This fixes two issues with recent access checking patch:
> 1. if (&d->vqs[i].private_data) -> if (d->vqs[i].private_data)
> 2. we can't forbid log base changes while ring is running,
> because host needs to resize log in rare cases
> (e.g. when memory is added with a baloon)
> and in that case it needs to increase log size with realloc,
> which might move the log address.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Thanks, applied.
Rusty.
^ permalink raw reply
* Re: [PATCH] vhost-net: defer f->private_data until setup succeeds
From: Rusty Russell @ 2010-01-04 2:33 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Chris Wright, kvm, virtualization
In-Reply-To: <20091224060650.GA26128@redhat.com>
On Thu, 24 Dec 2009 04:36:50 pm Michael S. Tsirkin wrote:
> On Tue, Dec 22, 2009 at 11:02:28AM -0800, Chris Wright wrote:
> > Trivial change, just for readability. The filp is not installed on
> > failure, so the current code is not incorrect (also vhost_dev_init
> > currently has no failure case). This just treats setting f->private_data
> > as something with global scope (sure, true only after fd_install).
> >
> > Signed-off-by: Chris Wright <chrisw@redhat.com>
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
Thanks, applied.
Rusty.
^ permalink raw reply
* Re: [PATCH v2] virtio-blk physical block size
From: Rusty Russell @ 2010-01-04 3:08 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, kvm, virtualization
In-Reply-To: <1262018363-15871-1-git-send-email-avi@redhat.com>
On Tue, 29 Dec 2009 03:09:23 am Avi Kivity wrote:
> This patch adds a physical block size attribute to virtio disks,
> corresponding to /sys/devices/.../physical_block_size. It is defined as
> the request alignment which will not trigger RMW cycles. This can be
> important for modern disks which use 4K physical sectors (though they
> still support 512 logical sectors), and for file-backed disk images (which
> have both the underlying filesystem block size and their own allocation
> granularity to consider).
>
> Installers use this to align partitions to physical block boundaries.
>
> Note the spec already defined blk_size as the performance rather than
> minimum alignment. However the driver interpreted this as the logical
> block size, so I updated the spec to match the driver assuming the driver
> predates the spec and that this is an error.
I thought this was what I was doing, but I have shown over and over that
I have no idea about block devices.
Our current driver treats BLK_SIZE as the logical and physical size (see
blk_queue_logical_block_size).
I have no idea what "logical" vs. "physical" actually means. Anyone? Most
importantly, is it some Linux-internal difference or a real I/O-visible
distinction?
Rusty.
^ permalink raw reply
* Re: [PATCH v2] virtio-blk physical block size
From: Avi Kivity @ 2010-01-04 7:02 UTC (permalink / raw)
To: Rusty Russell; +Cc: qemu-devel, kvm, virtualization
In-Reply-To: <201001041338.52621.rusty@rustcorp.com.au>
On 01/04/2010 05:08 AM, Rusty Russell wrote:
> On Tue, 29 Dec 2009 03:09:23 am Avi Kivity wrote:
>
>> This patch adds a physical block size attribute to virtio disks,
>> corresponding to /sys/devices/.../physical_block_size. It is defined as
>> the request alignment which will not trigger RMW cycles. This can be
>> important for modern disks which use 4K physical sectors (though they
>> still support 512 logical sectors), and for file-backed disk images (which
>> have both the underlying filesystem block size and their own allocation
>> granularity to consider).
>>
>> Installers use this to align partitions to physical block boundaries.
>>
>> Note the spec already defined blk_size as the performance rather than
>> minimum alignment. However the driver interpreted this as the logical
>> block size, so I updated the spec to match the driver assuming the driver
>> predates the spec and that this is an error.
>>
> I thought this was what I was doing, but I have shown over and over that
> I have no idea about block devices.
>
> Our current driver treats BLK_SIZE as the logical and physical size (see
> blk_queue_logical_block_size).
>
But we want them to be different.
> I have no idea what "logical" vs. "physical" actually means. Anyone? Most
> importantly, is it some Linux-internal difference or a real I/O-visible
> distinction?
>
Yes.
Logical block size is the minimum block size the hardware will allow.
Try to write less than that, and the hardware will laugh in your face.
Physical block size is the what the logical block size would have been
is software didn't suck. In theory they should be the same, but since
compatibility reaons clamp the logical block size to 512, they have to
differ. A disk may have a physical block size of 4096 and emulate
logical block size of 512 on top of that using read-modify-write.
Or so I understand it.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
From: Christoph Hellwig @ 2010-01-04 8:30 UTC (permalink / raw)
To: Rusty Russell; +Cc: virtualization, Avi Kivity, kvm, qemu-devel
In-Reply-To: <201001041338.52621.rusty@rustcorp.com.au>
On Mon, Jan 04, 2010 at 01:38:51PM +1030, Rusty Russell wrote:
> I thought this was what I was doing, but I have shown over and over that
> I have no idea about block devices.
>
> Our current driver treats BLK_SIZE as the logical and physical size (see
> blk_queue_logical_block_size).
>
> I have no idea what "logical" vs. "physical" actually means. Anyone? Most
> importantly, is it some Linux-internal difference or a real I/O-visible
> distinction?
Those should be the same for any sane interface. They are for classical
disk devices with larger block sizes (MO, s390 dasd) and also for the
now appearing 4k sector scsi disks. But in the ide world people are
concerned about dos/window legacy compatiblity so they came up with a
nasty hack:
- there is a physical block size as used by the disk internally
(4k initially)
- all the interfaces to the operating system still happen in the
traditional 512 byte blocks to not break any existing assumptions
- to make sure modern operating systems can optimize for the larger
physical sectors the disks expose this size, too.
- even worse disks can also have alignment hacks for the traditional
DOS partitions tables, so that the 512 byte block zero might even
have an offset into the first larger physical block. This is also
exposed in the ATA identify information.
All in all I don't think this mess is a good idea to replicate in
virtio. Virtio by defintion requires virtualization aware guests, so we
should just follow the SCSI way of larger real block sizes here.
>
> Rusty.
>
---end quoted text---
^ permalink raw reply
* Re: [PATCH 18/31] virtio: console: Buffer data that comes from the host
From: Rusty Russell @ 2010-01-04 9:15 UTC (permalink / raw)
To: Amit Shah; +Cc: virtualization
In-Reply-To: <1261492481-19817-19-git-send-email-amit.shah@redhat.com>
On Wed, 23 Dec 2009 01:04:28 am Amit Shah wrote:
> The console could be flooded with data from the host; handle this
> situation by buffering the data.
Is this still true? If we only add_buf when we're ready, surely the host
can't flood us with one virtqueue per port?
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 18/31] virtio: console: Buffer data that comes from the host
From: Amit Shah @ 2010-01-04 9:47 UTC (permalink / raw)
To: Rusty Russell; +Cc: virtualization
In-Reply-To: <201001041945.30841.rusty@rustcorp.com.au>
On (Mon) Jan 04 2010 [19:45:30], Rusty Russell wrote:
> On Wed, 23 Dec 2009 01:04:28 am Amit Shah wrote:
> > The console could be flooded with data from the host; handle this
> > situation by buffering the data.
>
> Is this still true? If we only add_buf when we're ready, surely the host
> can't flood us with one virtqueue per port?
I guess I meant something completely different. This message is
definitely misleading and I'll re-word it.
You're right; we don't need the 'guest throttling' feature that was
needed earlier.
Thanks!
Amit
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
From: Rusty Russell @ 2010-01-05 12:56 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: virtualization, Avi Kivity, kvm, qemu-devel
In-Reply-To: <20100104083035.GA7461@lst.de>
On Mon, 4 Jan 2010 07:00:35 pm Christoph Hellwig wrote:
> On Mon, Jan 04, 2010 at 01:38:51PM +1030, Rusty Russell wrote:
> > I thought this was what I was doing, but I have shown over and over that
> > I have no idea about block devices.
> >
> > Our current driver treats BLK_SIZE as the logical and physical size (see
> > blk_queue_logical_block_size).
> >
> > I have no idea what "logical" vs. "physical" actually means. Anyone? Most
> > importantly, is it some Linux-internal difference or a real I/O-visible
> > distinction?
>
> Those should be the same for any sane interface. They are for classical
> disk devices with larger block sizes (MO, s390 dasd) and also for the
> now appearing 4k sector scsi disks. But in the ide world people are
> concerned about dos/window legacy compatiblity so they came up with a
> nasty hack:
>
> - there is a physical block size as used by the disk internally
> (4k initially)
> - all the interfaces to the operating system still happen in the
> traditional 512 byte blocks to not break any existing assumptions
> - to make sure modern operating systems can optimize for the larger
> physical sectors the disks expose this size, too.
> - even worse disks can also have alignment hacks for the traditional
> DOS partitions tables, so that the 512 byte block zero might even
> have an offset into the first larger physical block. This is also
> exposed in the ATA identify information.
>
> All in all I don't think this mess is a good idea to replicate in
> virtio. Virtio by defintion requires virtualization aware guests, so we
> should just follow the SCSI way of larger real block sizes here.
Yes. The current VIRTIO_BLK_F_BLK_SIZE says "please use this block size".
We haven't actually specified what happens if the guest doesn't, but the
spec says "must", and the Linux implementation does so AFAICT.
If we want a "soft" size, we could add that as a separate feature.
Cheers,
Rusty.
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
From: Avi Kivity @ 2010-01-05 12:58 UTC (permalink / raw)
To: Rusty Russell; +Cc: virtualization, Christoph Hellwig, kvm, qemu-devel
In-Reply-To: <201001052326.33216.rusty@rustcorp.com.au>
On 01/05/2010 02:56 PM, Rusty Russell wrote:
>
>> Those should be the same for any sane interface. They are for classical
>> disk devices with larger block sizes (MO, s390 dasd) and also for the
>> now appearing 4k sector scsi disks. But in the ide world people are
>> concerned about dos/window legacy compatiblity so they came up with a
>> nasty hack:
>>
>> - there is a physical block size as used by the disk internally
>> (4k initially)
>> - all the interfaces to the operating system still happen in the
>> traditional 512 byte blocks to not break any existing assumptions
>> - to make sure modern operating systems can optimize for the larger
>> physical sectors the disks expose this size, too.
>> - even worse disks can also have alignment hacks for the traditional
>> DOS partitions tables, so that the 512 byte block zero might even
>> have an offset into the first larger physical block. This is also
>> exposed in the ATA identify information.
>>
>> All in all I don't think this mess is a good idea to replicate in
>> virtio. Virtio by defintion requires virtualization aware guests, so we
>> should just follow the SCSI way of larger real block sizes here.
>>
> Yes. The current VIRTIO_BLK_F_BLK_SIZE says "please use this block size".
> We haven't actually specified what happens if the guest doesn't, but the
> spec says "must", and the Linux implementation does so AFAICT.
>
> If we want a "soft" size, we could add that as a separate feature.
>
No - I agree with Christoph, there's no reason to use a 512/4096
monstrosity with virtio.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
From: Jamie Lokier @ 2010-01-05 20:16 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, Christoph Hellwig, kvm, virtualization
In-Reply-To: <4B433783.6090400@redhat.com>
Avi Kivity wrote:
> On 01/05/2010 02:56 PM, Rusty Russell wrote:
> >
> >>Those should be the same for any sane interface. They are for classical
> >>disk devices with larger block sizes (MO, s390 dasd) and also for the
> >>now appearing 4k sector scsi disks. But in the ide world people are
> >>concerned about dos/window legacy compatiblity so they came up with a
> >>nasty hack:
> >>
> >> - there is a physical block size as used by the disk internally
> >> (4k initially)
> >> - all the interfaces to the operating system still happen in the
> >> traditional 512 byte blocks to not break any existing assumptions
> >> - to make sure modern operating systems can optimize for the larger
> >> physical sectors the disks expose this size, too.
> >> - even worse disks can also have alignment hacks for the traditional
> >> DOS partitions tables, so that the 512 byte block zero might even
> >> have an offset into the first larger physical block. This is also
> >> exposed in the ATA identify information.
> >>
> >>All in all I don't think this mess is a good idea to replicate in
> >>virtio. Virtio by defintion requires virtualization aware guests, so we
> >>should just follow the SCSI way of larger real block sizes here.
> >>
> >Yes. The current VIRTIO_BLK_F_BLK_SIZE says "please use this block size".
> >We haven't actually specified what happens if the guest doesn't, but the
> >spec says "must", and the Linux implementation does so AFAICT.
> >
> >If we want a "soft" size, we could add that as a separate feature.
> >
>
> No - I agree with Christoph, there's no reason to use a 512/4096
> monstrosity with virtio.
It would be good if virtio relayed the backing device's basic topology
hints, so:
- If the backing dev is a real disk with 512-byte sectors,
virtio should indicate 512-byte blocks to the guest.
- If the backing dev is a real disk with 4096-byte sectors,
virtio should indicate 4096-byte blocks to the guest.
With databases and filesystems, if you care about data integrity:
- If the backing dev is a real disk with 4096-byte sectors,
or a file whose access is through a 4096-byte-per-page cache,
virtio must indicate 4096-byte blocks otherwise guest
journalling is not host-powerfail safe.
You get the idea. If there is only one parameter, it really should be
at least as large as the smallest unit which may be corrupted by
writes when errors occur.
-- Jamie
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
From: Jamie Lokier @ 2010-01-05 20:18 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, kvm, virtualization
In-Reply-To: <4B4192A1.3030801@redhat.com>
Avi Kivity wrote:
> Physical block size is the what the logical block size would have been
> is software didn't suck. In theory they should be the same, but since
> compatibility reaons clamp the logical block size to 512, they have to
> differ. A disk may have a physical block size of 4096 and emulate
> logical block size of 512 on top of that using read-modify-write.
>
> Or so I understand it.
I think that's right, but a side effect is that if you get a power
failure during the read-modify-write, bytes anywhere in 4096 sector
may be incorrect, so journalling (etc.) needs to use 4096 byte blocks
for data integrity, even though the drive emulates smaller writes.
-- Jamie
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
From: Christoph Hellwig @ 2010-01-08 15:40 UTC (permalink / raw)
To: Jamie Lokier
Cc: kvm, qemu-devel, virtualization, Avi Kivity, Christoph Hellwig
In-Reply-To: <20100105201615.GJ14376@shareable.org>
On Tue, Jan 05, 2010 at 08:16:15PM +0000, Jamie Lokier wrote:
> It would be good if virtio relayed the backing device's basic topology
> hints, so:
>
> - If the backing dev is a real disk with 512-byte sectors,
> virtio should indicate 512-byte blocks to the guest.
>
> - If the backing dev is a real disk with 4096-byte sectors,
> virtio should indicate 4096-byte blocks to the guest.
>
> With databases and filesystems, if you care about data integrity:
>
> - If the backing dev is a real disk with 4096-byte sectors,
> or a file whose access is through a 4096-byte-per-page cache,
> virtio must indicate 4096-byte blocks otherwise guest
> journalling is not host-powerfail safe.
>
> You get the idea. If there is only one parameter, it really should be
> at least as large as the smallest unit which may be corrupted by
> writes when errors occur.
It's not that easy. IDE only supports larger sectors sizes with the
physical sector size attribute, not native larger sectors. While scsi
does support it it's untypical and I would not expect the guests to
not always get it right. So the best is to use the transport native
way to express that we have larger sectors and expect the guest to do
the right thing.
I've done some work on the autodetection of the larger sector sizes
a while ago. But now that people brought up migration I wonder if that
makes sense - if we migrate from a 512 byte sector size disk to a 4096
byte sector size disk we can't simply change guest visible attributes.
Maybe we should pick one on image creation and then stick to it. For an
image format we could write down this information in the image, but for
a raw images that's impossible.
^ permalink raw reply
* Virtio ballooning support for Lguest
From: Gaurav Kukreja @ 2010-01-08 18:35 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 390 bytes --]
Hi,
I am doing working on enabling Transcendent Memory(OLS '09) support on
lguest.
For the same, I need ballooning support for lguest. Is there an
implmentation of Virtio Balloon driver, that I can use for my purpose?
Could someone give me an insight, as to how to go about, for implementing
this myself, incase I dont find this patch...
Thankyou.
--
Gaurav Kukreja
+91 997 030 1257
[-- Attachment #1.2: Type: text/html, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: Virtio ballooning support for Lguest
From: Dor Laor @ 2010-01-10 7:45 UTC (permalink / raw)
To: Gaurav Kukreja; +Cc: virtualization
In-Reply-To: <93e720dc1001081035t68b4fb8bracea5e5e61443b99@mail.gmail.com>
On 01/08/2010 08:35 PM, Gaurav Kukreja wrote:
> Hi,
>
> I am doing working on enabling Transcendent Memory(OLS '09) support on
> lguest.
>
> For the same, I need ballooning support for lguest. Is there an
> implmentation of Virtio Balloon driver, that I can use for my purpose?
driver: http://lxr.linux.no/#linux+v2.6.32/drivers/virtio/virtio_balloon.c
device: http://git.savannah.gnu.org/cgit/qemu.git/tree/hw/virtio-balloon.c
>
> Could someone give me an insight, as to how to go about, for
> implementing this myself, incase I dont find this patch...
>
> Thankyou.
>
> --
> Gaurav Kukreja
>
> +91 997 030 1257
>
>
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
From: Avi Kivity @ 2010-01-10 12:35 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jamie Lokier, qemu-devel, kvm, virtualization
In-Reply-To: <20100108154044.GB14634@lst.de>
On 01/08/2010 05:40 PM, Christoph Hellwig wrote:
> Maybe we should pick one on image creation and then stick to it. For an
> image format we could write down this information in the image, but for
> a raw images that's impossible.
>
The management system should remember it (like it remembers which images
belong to which guest, and how to expose them).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Intel Rapid Boot Toolkit - UEFI Hypervisor : Cloud Computing Firmware / Firmware-as-a-Service
From: Guillaume FORTAINE @ 2010-01-10 19:55 UTC (permalink / raw)
To: Virtualization
Misters,
Happy New Year to you.
Let me introduce myself : Guillaume FORTAINE, Engineer in Computer
Science. I am currently working on a Cloud Computing Firmware in
an Infrastructure-as-a-Service context.
The product is an UEFI Hypervisor. It puts virtualization exactly
where it belongs: Into the firmware [0]
Customers will be able to deploy their appliances and products
directly to new hardware - without headaches due to the underlying
technology.
It will enable scalability through high-end technology on their x86
bases server systems.
My Business Model comes from this fairly simple question :
What is the value-added from an OEM point of view to need 3rd parties
to provide an Hypervisor Layer knowing that Virtualization is a
feature from the Hardware (so it belongs to the CPU / Chipset / OEM
World) and they are not necessary to enable it (coreboot AVATT
prototype is the most successful example [1]),
however they are making the greatest benefits from it ?
To quote [2] :
"There's actually a lot to be said for the embedded hypervisor. Lots
of IT environments--especially enterprise ones--do indeed have a mix
of operating systems and operating system versions. Given that,
there is indeed a lot to be said for the idea that hypervisors just
come with the server as a sort of superset to the firmware, like BIOS,
already loaded on every system. Then IT administrators could just
configure any guest OSs they want on top."
That's why I am currently going further since the first successful
prototype of
the coreboot GSOC project AVATT (All Virtual All The Time) [1].
Coreboot is an open source hardware initialization firmware. It does
some basic hardware init, then hands over control to one of many
possible payloads.
This Google Summer of Code sponsored project suggested the idea
of implementing a Linux kernel with KVM (Kernel Virtual
Machine to provide Type I Hypervisor abilities to Linux) as a coreboot
payload (=Virtualization inside the BIOS).
However, after several discussions with leading OEMs inside the UEFI
Forum, I
realized that coreboot was not a convenient choice as a Platform
Initialization code :
With the processors and chipsets being mostly commodity (at least
identical between IHVs), there is little room in the platform for
vendors such as Dell, IBM, and HP to differentiate between each other
on features, so all have chosen to implement features in BIOS as one
differentiation location.
CoreBoot is interesting, in that it could remove even that level of
differentiation capability between the vendors; or it could provide
the ultimate in end user customization (hardware/firmware-as-a-service
models, or eliminate-the-IHV models).
They are exploring if/how they can utilize CoreBoot, for specific
customers, but simply do not see the broad market demand for CoreBoot
to displace their entrenched development projects (legacy BIOS and
UEFI), again, they simply don't have the resources needed to keep many
separate streams of BIOS-level development going at once, when it's
not clear there could be any ROI for adding CoreBoot in a general
product offering.
Moreover, there are many liability and ownership issues due to its
GPL-Licence.
So, that's why after a thorough research work, I definitely believe
that the Intel Rapid Boot Toolkit [3] could be the perfect BIOS Framework
knowing that it is UEFI-Based and that it provides a Linux payload,
like coreboot, enabling a Firmware-as-a-Service Model.
To quote [4]:
"Intel, Dell, and servers that change with the phases of the moon
As we reported a while back, Dell is looking to bundle a hypervisor on
the motherboard using flash, so that the hypervisor loads first and
then loads the OS. Even more importantly, Intel itself headed in this
direction with their line of server boards that use the company's
Rapid Boot Toolkit. Both of these are efforts that bring lightweight,
task-specific, widget-like personalities to high-powered server
hardware.
Intel's Rapid Boot Toolkit is basically the same as what Dell is
planning (i.e., a pool of embedded flash boots a hypervisor, which
then loads the OS), but Intel is already there with a line of server
motherboards. Furthermore, the beauty of Intel's scheme is that the
hypervisor can pull an OS image from over the network and load the
image on the system without ever spinning up the hard drive. This
functionality replaces the standard Linux PXE boot, and it can be done
with Windows, as well."
The value-added move to the payload ( Firmware-as-a-Service ) and it
will be portable across all OEMs products (ensuring Linux Device Drivers
compatibility for IOMMU to provide High-Performance Hardware
Virtualization : Infrastructure-as-a-Service).
The Platform Initialization becomes secondary and Hardware Vendors can
provide a closed UEFI Platform Initialization code to protect their
value-add features.
I have currently a team of Linux-From-Scratch / Embedded experts
who will provide engineering support for a custom Rapid Boot Toolkit.
Thanks to this one, we will be able to create a Cloud Computing
Firmware. The functional specifications of this one are :
a) Smart (WBEM : SLP + CIM + SSL/TLS) [5]
b) Virtual Hypervisor (Linux + KVM + IOMMU)
This is Firmware Engineering at the highest-level, not 'marketing fluff'
like Citrix Xen for OEMs or VMWare ESXi, because it will be the first
true Bare-Metal Hypervisor in the World and I definitely believe that
it could revolutionize the industry.
I would greatly appreciate to know if I would be able to make a
partnership with the Linux Foundation to sponsor this project, if
possible, please.
To realize this project, I am currently asking two things, if
possible, please :
1) Intel Rapid Boot Toolkit [3]
2) Server Board with :
a) IOMMU : Intel VT-d2/AMD IOMMU
b) ROM chip socketed
c) UEFI Firmware
c) Numonyx Forte M25P128 [6]
I look forward to your answer,
Best Regards,
Guillaume FORTAINE
[0]
http://x86asm.net/articles/uefi-hypervisors-winning-the-race-to-bare-metal/
[1] http://www.coreboot.org/AVATT
[2] http://news.cnet.com/8301-13556_3-10170884-61.html
[3] http://www.intel.com/design/servers/ism/rbt/index.htm
[4]
http://arstechnica.com/business/news/2007/11/split-personalties-new-hypervisorflash-combos-mean-an-os-is-just-one-way-to-boot.ars
[5] http://icac2009.acis.ufl.edu/files/presentations/Kinzhalin.pdf
[6] http://www.numonyx.com/en-US/MemoryProducts/NORserial/Pages/M25P.aspx
^ permalink raw reply
* Re: [PATCH 03/31] hvc_console: make the ops pointer const.
From: Benjamin Herrenschmidt @ 2010-01-12 2:21 UTC (permalink / raw)
To: Amit Shah; +Cc: linuxppc-dev, virtualization
In-Reply-To: <1261492481-19817-4-git-send-email-amit.shah@redhat.com>
On Tue, 2009-12-22 at 20:04 +0530, Amit Shah wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
>
> This is nicer for modern R/O protection. And noone needs it non-const, so
> constify the callers as well.
Rusty, do you want me to take these via powerpc ?
Cheers,
Ben.
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> Signed-off-by: Amit Shah <amit.shah@redhat.com>
> To: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: linuxppc-dev@ozlabs.org
> ---
> drivers/char/hvc_beat.c | 2 +-
> drivers/char/hvc_console.c | 7 ++++---
> drivers/char/hvc_console.h | 7 ++++---
> drivers/char/hvc_iseries.c | 2 +-
> drivers/char/hvc_iucv.c | 2 +-
> drivers/char/hvc_rtas.c | 2 +-
> drivers/char/hvc_udbg.c | 2 +-
> drivers/char/hvc_vio.c | 2 +-
> drivers/char/hvc_xen.c | 2 +-
> drivers/char/virtio_console.c | 2 +-
> 10 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/char/hvc_beat.c b/drivers/char/hvc_beat.c
> index 0afc8b8..6913fc3 100644
> --- a/drivers/char/hvc_beat.c
> +++ b/drivers/char/hvc_beat.c
> @@ -84,7 +84,7 @@ static int hvc_beat_put_chars(uint32_t vtermno, const char *buf, int cnt)
> return cnt;
> }
>
> -static struct hv_ops hvc_beat_get_put_ops = {
> +static const struct hv_ops hvc_beat_get_put_ops = {
> .get_chars = hvc_beat_get_chars,
> .put_chars = hvc_beat_put_chars,
> };
> diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
> index 416d342..d8dac58 100644
> --- a/drivers/char/hvc_console.c
> +++ b/drivers/char/hvc_console.c
> @@ -125,7 +125,7 @@ static struct hvc_struct *hvc_get_by_index(int index)
> * console interfaces but can still be used as a tty device. This has to be
> * static because kmalloc will not work during early console init.
> */
> -static struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
> +static const struct hv_ops *cons_ops[MAX_NR_HVC_CONSOLES];
> static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] =
> {[0 ... MAX_NR_HVC_CONSOLES - 1] = -1};
>
> @@ -247,7 +247,7 @@ static void destroy_hvc_struct(struct kref *kref)
> * vty adapters do NOT get an hvc_instantiate() callback since they
> * appear after early console init.
> */
> -int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops)
> +int hvc_instantiate(uint32_t vtermno, int index, const struct hv_ops *ops)
> {
> struct hvc_struct *hp;
>
> @@ -749,7 +749,8 @@ static const struct tty_operations hvc_ops = {
> };
>
> struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int data,
> - struct hv_ops *ops, int outbuf_size)
> + const struct hv_ops *ops,
> + int outbuf_size)
> {
> struct hvc_struct *hp;
> int i;
> diff --git a/drivers/char/hvc_console.h b/drivers/char/hvc_console.h
> index 10950ca..52ddf4d 100644
> --- a/drivers/char/hvc_console.h
> +++ b/drivers/char/hvc_console.h
> @@ -55,7 +55,7 @@ struct hvc_struct {
> int outbuf_size;
> int n_outbuf;
> uint32_t vtermno;
> - struct hv_ops *ops;
> + const struct hv_ops *ops;
> int irq_requested;
> int data;
> struct winsize ws;
> @@ -76,11 +76,12 @@ struct hv_ops {
> };
>
> /* Register a vterm and a slot index for use as a console (console_init) */
> -extern int hvc_instantiate(uint32_t vtermno, int index, struct hv_ops *ops);
> +extern int hvc_instantiate(uint32_t vtermno, int index,
> + const struct hv_ops *ops);
>
> /* register a vterm for hvc tty operation (module_init or hotplug add) */
> extern struct hvc_struct * __devinit hvc_alloc(uint32_t vtermno, int data,
> - struct hv_ops *ops, int outbuf_size);
> + const struct hv_ops *ops, int outbuf_size);
> /* remove a vterm from hvc tty operation (module_exit or hotplug remove) */
> extern int hvc_remove(struct hvc_struct *hp);
>
> diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
> index 936d05b..fd02426 100644
> --- a/drivers/char/hvc_iseries.c
> +++ b/drivers/char/hvc_iseries.c
> @@ -197,7 +197,7 @@ done:
> return sent;
> }
>
> -static struct hv_ops hvc_get_put_ops = {
> +static const struct hv_ops hvc_get_put_ops = {
> .get_chars = get_chars,
> .put_chars = put_chars,
> .notifier_add = notifier_add_irq,
> diff --git a/drivers/char/hvc_iucv.c b/drivers/char/hvc_iucv.c
> index fe62bd0..21681a8 100644
> --- a/drivers/char/hvc_iucv.c
> +++ b/drivers/char/hvc_iucv.c
> @@ -922,7 +922,7 @@ static int hvc_iucv_pm_restore_thaw(struct device *dev)
>
>
> /* HVC operations */
> -static struct hv_ops hvc_iucv_ops = {
> +static const struct hv_ops hvc_iucv_ops = {
> .get_chars = hvc_iucv_get_chars,
> .put_chars = hvc_iucv_put_chars,
> .notifier_add = hvc_iucv_notifier_add,
> diff --git a/drivers/char/hvc_rtas.c b/drivers/char/hvc_rtas.c
> index 88590d0..61c4a61 100644
> --- a/drivers/char/hvc_rtas.c
> +++ b/drivers/char/hvc_rtas.c
> @@ -71,7 +71,7 @@ static int hvc_rtas_read_console(uint32_t vtermno, char *buf, int count)
> return i;
> }
>
> -static struct hv_ops hvc_rtas_get_put_ops = {
> +static const struct hv_ops hvc_rtas_get_put_ops = {
> .get_chars = hvc_rtas_read_console,
> .put_chars = hvc_rtas_write_console,
> };
> diff --git a/drivers/char/hvc_udbg.c b/drivers/char/hvc_udbg.c
> index bd63ba8..b0957e6 100644
> --- a/drivers/char/hvc_udbg.c
> +++ b/drivers/char/hvc_udbg.c
> @@ -58,7 +58,7 @@ static int hvc_udbg_get(uint32_t vtermno, char *buf, int count)
> return i;
> }
>
> -static struct hv_ops hvc_udbg_ops = {
> +static const struct hv_ops hvc_udbg_ops = {
> .get_chars = hvc_udbg_get,
> .put_chars = hvc_udbg_put,
> };
> diff --git a/drivers/char/hvc_vio.c b/drivers/char/hvc_vio.c
> index 10be343..27370e9 100644
> --- a/drivers/char/hvc_vio.c
> +++ b/drivers/char/hvc_vio.c
> @@ -77,7 +77,7 @@ static int filtered_get_chars(uint32_t vtermno, char *buf, int count)
> return got;
> }
>
> -static struct hv_ops hvc_get_put_ops = {
> +static const struct hv_ops hvc_get_put_ops = {
> .get_chars = filtered_get_chars,
> .put_chars = hvc_put_chars,
> .notifier_add = notifier_add_irq,
> diff --git a/drivers/char/hvc_xen.c b/drivers/char/hvc_xen.c
> index b1a7163..60446f8 100644
> --- a/drivers/char/hvc_xen.c
> +++ b/drivers/char/hvc_xen.c
> @@ -122,7 +122,7 @@ static int read_console(uint32_t vtermno, char *buf, int len)
> return recv;
> }
>
> -static struct hv_ops hvc_ops = {
> +static const struct hv_ops hvc_ops = {
> .get_chars = read_console,
> .put_chars = write_console,
> .notifier_add = notifier_add_irq,
> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> index 1d844a4..791be4e 100644
> --- a/drivers/char/virtio_console.c
> +++ b/drivers/char/virtio_console.c
> @@ -163,7 +163,7 @@ static void hvc_handle_input(struct virtqueue *vq)
> }
>
> /* The operations for the console. */
> -static struct hv_ops hv_ops = {
> +static const struct hv_ops hv_ops = {
> .get_chars = get_chars,
> .put_chars = put_chars,
> .notifier_add = notifier_add_vio,
^ permalink raw reply
* Re: Virtio ballooning support for Lguest
From: Rusty Russell @ 2010-01-12 11:04 UTC (permalink / raw)
To: virtualization; +Cc: Gaurav Kukreja
In-Reply-To: <93e720dc1001081035t68b4fb8bracea5e5e61443b99@mail.gmail.com>
On Sat, 9 Jan 2010 05:05:06 am Gaurav Kukreja wrote:
> Hi,
>
> I am doing working on enabling Transcendent Memory(OLS '09) support on
> lguest.
>
> For the same, I need ballooning support for lguest. Is there an
> implmentation of Virtio Balloon driver, that I can use for my purpose?
Here's a patch I had for testing. It's not a real implementation, but
it serves as a start point.
This patch probably won't apply now, but you can use the code:
Crappy lguest balloon testing code.
---
Documentation/lguest/lguest.c | 75 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 75 insertions(+)
diff -r 62e37935e821 Documentation/lguest/lguest.c
--- a/Documentation/lguest/lguest.c Sun Jun 15 23:00:15 2008 +1000
+++ b/Documentation/lguest/lguest.c Sun Jun 15 23:00:54 2008 +1000
@@ -44,6 +44,7 @@
#include "linux/virtio_console.h"
#include "linux/virtio_rng.h"
#include "linux/virtio_ring.h"
+#include "linux/virtio_balloon.h"
#include "linux/vring.h"
#include "asm-x86/bootparam.h"
/*L:110 We can ignore the 39 include files we need for this program, but I do
@@ -2194,6 +2195,75 @@ static void setup_block_file(const char
verbose("device %u: virtblock %llu sectors\n",
devices.device_num, le64_to_cpu(conf.capacity));
}
+/*:*/
+
+static bool handle_balloon_cmd(int fd, struct device *dev)
+{
+ struct virtio_balloon_config conf;
+ int r, diff;
+ char cmd[80];
+
+ r = read(dev->fd, cmd, sizeof(cmd)-1);
+ if (r < 0)
+ err(1, "Reading balloon cmd fd");
+
+ /* Closed? Stop listening. */
+ if (r == 0)
+ return false;
+
+ cmd[r] = '\0';
+ diff = atol(cmd);
+ if (!diff)
+ errx(1, "Bad balloon target diff '%s'", cmd);
+
+ memcpy(&conf, device_config(dev), sizeof(conf));
+ conf.num_pages += diff;
+ printf("New balloon target: %u\n", conf.num_pages);
+ memcpy(device_config(dev), &conf, sizeof(conf));
+
+ /* Config change, so trigger the irq. */
+ dev->desc->config_change = 1;
+ trigger_irq(fd, dev->vq);
+ return true;
+}
+
+static void handle_virtballoon_output(int fd, struct virtqueue *vq)
+{
+ unsigned int head, out, in, i;
+ struct iovec iov[vq->vqi.vring.num];
+
+ head = get_vq_desc(&vq->vqi, iov, &out, &in);
+ if (head < 0)
+ return;
+
+ if (in)
+ errx(1, "Input buffers in output queue?");
+
+ if (out != 1 || (iov[0].iov_len % 4) != 0)
+ errx(1, "Surprising output num %i, len %u\n",
+ out, iov[0].iov_len);
+
+ for (i = 0; i < iov[0].iov_len/4; i++)
+ printf("Released page %u\n", ((u32 *)iov[0].iov_base)[i]);
+
+ add_used_and_trigger(fd, vq, head, iov[0].iov_len);
+}
+
+/*L:199 The balloon device: this is a hack for testing. */
+static void setup_balloon_file(const char *filename, unsigned int mempages)
+{
+ int fd;
+ struct device *dev;
+ struct virtio_balloon_config conf = { .num_pages = 0 };
+
+ fd = open_or_die(filename, O_RDWR);
+
+ dev = new_device("balloon", VIRTIO_ID_BALLOON, fd, handle_balloon_cmd);
+
+ /* The device has one virtqueue, where the Guest places page numbers. */
+ add_virtqueue(dev, VIRTQUEUE_NUM, handle_virtballoon_output);
+ set_config(dev, sizeof(conf), &conf);
+}
/* Our random number generator device reads from /dev/random into the Guest's
* input buffers. The usual case is that the Guest doesn't want random numbers
@@ -2326,6 +2396,7 @@ static struct option opts[] = {
{ "block", 1, NULL, 'b' },
{ "rng", 0, NULL, 'r' },
{ "initrd", 1, NULL, 'i' },
+ { "balloon", 1, NULL, 'B' },
{ "sharenet", 1, NULL, 's' },
{ NULL },
};
@@ -2334,6 +2405,7 @@ static void usage(void)
errx(1, "Usage: lguest [--verbose] "
"[--tunnet=(<ipaddr>:<macaddr>|bridge:<bridgename>:<macaddr>)\n"
"|--sharenet=<controlfile>]\n"
+ "|--balloon=<filename>]\n"
"|--block=<filename>|--initrd=<filename>]...\n"
"<mem-in-mb> vmlinux [args...]");
}
@@ -2409,6 +2481,9 @@ int main(int argc, char *argv[])
break;
case 'i':
initrd_name = optarg;
+ break;
+ case 'B':
+ setup_balloon_file(optarg, mem/getpagesize());
break;
case 's':
setup_sharenet(optarg);
^ permalink raw reply
* Re: [PATCH 03/31] hvc_console: make the ops pointer const.
From: Rusty Russell @ 2010-01-12 11:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Amit Shah, linuxppc-dev, virtualization
In-Reply-To: <1263262906.724.175.camel@pasglop>
On Tue, 12 Jan 2010 12:51:46 pm Benjamin Herrenschmidt wrote:
> On Tue, 2009-12-22 at 20:04 +0530, Amit Shah wrote:
> > From: Rusty Russell <rusty@rustcorp.com.au>
> >
> > This is nicer for modern R/O protection. And noone needs it non-const, so
> > constify the callers as well.
>
> Rusty, do you want me to take these via powerpc ?
Sure, thanks.
Rusty.
^ permalink raw reply
* Re: [PATCH 18/31] virtio: console: Buffer data that comes from the host
From: Amit Shah @ 2010-01-13 6:11 UTC (permalink / raw)
To: Rusty Russell; +Cc: virtualization
In-Reply-To: <20100104094717.GA11485@amit-x200.redhat.com>
On (Mon) Jan 04 2010 [15:17:17], Amit Shah wrote:
> On (Mon) Jan 04 2010 [19:45:30], Rusty Russell wrote:
> > On Wed, 23 Dec 2009 01:04:28 am Amit Shah wrote:
> > > The console could be flooded with data from the host; handle this
> > > situation by buffering the data.
> >
> > Is this still true? If we only add_buf when we're ready, surely the host
> > can't flood us with one virtqueue per port?
>
> I guess I meant something completely different. This message is
> definitely misleading and I'll re-word it.
>
> You're right; we don't need the 'guest throttling' feature that was
> needed earlier.
BTW I meant this series doesn't have the guest throttling feature.
Rusty, did you just have this comment for the series? If yes, I'll just
re-send this patch with a fixed description.
Amit
^ permalink raw reply
* Re: [PATCH 18/31] virtio: console: Buffer data that comes from the host
From: Rusty Russell @ 2010-01-13 11:13 UTC (permalink / raw)
To: Amit Shah; +Cc: virtualization
In-Reply-To: <20100113061148.GC31063@amit-x200.redhat.com>
On Wed, 13 Jan 2010 04:41:48 pm Amit Shah wrote:
> On (Mon) Jan 04 2010 [15:17:17], Amit Shah wrote:
> > On (Mon) Jan 04 2010 [19:45:30], Rusty Russell wrote:
> > > On Wed, 23 Dec 2009 01:04:28 am Amit Shah wrote:
> > > > The console could be flooded with data from the host; handle this
> > > > situation by buffering the data.
> > >
> > > Is this still true? If we only add_buf when we're ready, surely the host
> > > can't flood us with one virtqueue per port?
> >
> > I guess I meant something completely different. This message is
> > definitely misleading and I'll re-word it.
> >
> > You're right; we don't need the 'guest throttling' feature that was
> > needed earlier.
>
> BTW I meant this series doesn't have the guest throttling feature.
>
> Rusty, did you just have this comment for the series? If yes, I'll just
> re-send this patch with a fixed description.
I don't see why we ever allocate more than one incoming buffer though?
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 18/31] virtio: console: Buffer data that comes from the host
From: Amit Shah @ 2010-01-13 11:24 UTC (permalink / raw)
To: Rusty Russell; +Cc: virtualization
In-Reply-To: <201001132143.32464.rusty@rustcorp.com.au>
On (Wed) Jan 13 2010 [21:43:32], Rusty Russell wrote:
> On Wed, 13 Jan 2010 04:41:48 pm Amit Shah wrote:
> > On (Mon) Jan 04 2010 [15:17:17], Amit Shah wrote:
> > > On (Mon) Jan 04 2010 [19:45:30], Rusty Russell wrote:
> > > > On Wed, 23 Dec 2009 01:04:28 am Amit Shah wrote:
> > > > > The console could be flooded with data from the host; handle this
> > > > > situation by buffering the data.
> > > >
> > > > Is this still true? If we only add_buf when we're ready, surely the host
> > > > can't flood us with one virtqueue per port?
> > >
> > > I guess I meant something completely different. This message is
> > > definitely misleading and I'll re-word it.
> > >
> > > You're right; we don't need the 'guest throttling' feature that was
> > > needed earlier.
> >
> > BTW I meant this series doesn't have the guest throttling feature.
> >
> > Rusty, did you just have this comment for the series? If yes, I'll just
> > re-send this patch with a fixed description.
>
> I don't see why we ever allocate more than one incoming buffer though?
To prevent against a fast host app sending data to a slow guest
consumer.
Also, we use the in_vq for the buffering, so the number of buffers is
limited by the queue size that's declared by the host.
Amit
^ permalink raw reply
* Re: [PATCH 18/31] virtio: console: Buffer data that comes from the host
From: Rusty Russell @ 2010-01-13 23:15 UTC (permalink / raw)
To: Amit Shah; +Cc: virtualization
In-Reply-To: <20100113112452.GA24002@amit-x200.redhat.com>
On Wed, 13 Jan 2010 09:54:52 pm Amit Shah wrote:
> On (Wed) Jan 13 2010 [21:43:32], Rusty Russell wrote:
> > On Wed, 13 Jan 2010 04:41:48 pm Amit Shah wrote:
> > > On (Mon) Jan 04 2010 [15:17:17], Amit Shah wrote:
> > > > On (Mon) Jan 04 2010 [19:45:30], Rusty Russell wrote:
> > > > > On Wed, 23 Dec 2009 01:04:28 am Amit Shah wrote:
> > > > > > The console could be flooded with data from the host; handle this
> > > > > > situation by buffering the data.
> > > > >
> > > > > Is this still true? If we only add_buf when we're ready, surely the host
> > > > > can't flood us with one virtqueue per port?
> > > >
> > > > I guess I meant something completely different. This message is
> > > > definitely misleading and I'll re-word it.
> > > >
> > > > You're right; we don't need the 'guest throttling' feature that was
> > > > needed earlier.
> > >
> > > BTW I meant this series doesn't have the guest throttling feature.
> > >
> > > Rusty, did you just have this comment for the series? If yes, I'll just
> > > re-send this patch with a fixed description.
> >
> > I don't see why we ever allocate more than one incoming buffer though?
>
> To prevent against a fast host app sending data to a slow guest
> consumer.
>
> Also, we use the in_vq for the buffering, so the number of buffers is
> limited by the queue size that's declared by the host.
But if the guest only ever registers one input buffer at a time, we get the
same effect. And it means we use less memory. And our code is simpler.
Similar with output.
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 18/31] virtio: console: Buffer data that comes from the host
From: Amit Shah @ 2010-01-14 3:17 UTC (permalink / raw)
To: Rusty Russell; +Cc: virtualization
In-Reply-To: <201001140945.12345.rusty@rustcorp.com.au>
On (Thu) Jan 14 2010 [09:45:12], Rusty Russell wrote:
> On Wed, 13 Jan 2010 09:54:52 pm Amit Shah wrote:
> > On (Wed) Jan 13 2010 [21:43:32], Rusty Russell wrote:
> > > On Wed, 13 Jan 2010 04:41:48 pm Amit Shah wrote:
> > > > On (Mon) Jan 04 2010 [15:17:17], Amit Shah wrote:
> > > > > On (Mon) Jan 04 2010 [19:45:30], Rusty Russell wrote:
> > > > > > On Wed, 23 Dec 2009 01:04:28 am Amit Shah wrote:
> > > > > > > The console could be flooded with data from the host; handle this
> > > > > > > situation by buffering the data.
> > > > > >
> > > > > > Is this still true? If we only add_buf when we're ready, surely the host
> > > > > > can't flood us with one virtqueue per port?
> > > > >
> > > > > I guess I meant something completely different. This message is
> > > > > definitely misleading and I'll re-word it.
> > > > >
> > > > > You're right; we don't need the 'guest throttling' feature that was
> > > > > needed earlier.
> > > >
> > > > BTW I meant this series doesn't have the guest throttling feature.
> > > >
> > > > Rusty, did you just have this comment for the series? If yes, I'll just
> > > > re-send this patch with a fixed description.
> > >
> > > I don't see why we ever allocate more than one incoming buffer though?
> >
> > To prevent against a fast host app sending data to a slow guest
> > consumer.
> >
> > Also, we use the in_vq for the buffering, so the number of buffers is
> > limited by the queue size that's declared by the host.
>
> But if the guest only ever registers one input buffer at a time, we get the
> same effect. And it means we use less memory. And our code is simpler.
The number of buffers to be registered in the vq comes from the host
anyway; if the host wants to be able to use multiple buffers, we should
be able to use them.
Also, we lose out on the ability of the host to send us data when the
guest is slow to read.
(I also see this as a policy decision being made in the guest to limit
to one buffer at a time; the decision should be made by the host: if the
guest is started with a bigger vq by the host, the kernel is capable of
using it all...)
> Similar with output.
For output I've already switched to using one buffer per vq and spinning
till the host acks having received the buffer.
Amit
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox