is: do you still plan to switch to a syscall
interface?
What benefit would a syscall interface have?
Regards,
Anthony Liguori
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel
perform scsi emulation.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
patch is just to illustrate the point. Has not even been
compile tested.
Regards,
Anthony Liguori
--- linux-2.6.21-rc1/arch/i386/kernel/vmi.c~ 2007-02-20 22:32:30.0 -0600
+++ linux-2.6.21-rc1/arch/i386/kernel/vmi.c 2007-02-26 17:58:18.0 -0600
@@ -852,9 +852,9 @@
#endif
#ifdef
Zachary Amsden wrote:
Anthony Liguori wrote:
Hi Zach,
It seems to me that the APIC paravirt_ops should be filled by
para_fill() instead of vmi_get_function(). vmi_get_function()
returns a nop when the relocation type is NONE. para_fill() leaves
the native code in place.
The native
Zachary Amsden wrote:
Anthony Liguori wrote:
Hi Zach,
It seems to me that the APIC paravirt_ops should be filled by
para_fill() instead of vmi_get_function(). vmi_get_function()
returns a nop when the relocation type is NONE. para_fill() leaves
the native code in place.
The native
lets move kvm paravirtualitzation into vmi too (proof of
concept code by Anthony Liguori exists) and kill one more item on the
(linux) QA test matrix? (just following your arguments, not that I'm
confident it would actually help reducing QA effort).
yes - although obviously a KVM Linux guest does
Nakajima, Jun wrote:
Anthony Liguori wrote:
Ingo Molnar wrote:
* Gerd Hoffmann [EMAIL PROTECTED] wrote:
So in the end you would still have two different hypervisor ABI's,
the VMI ROM just hides that.
oh, but that way i have cleverly pushed the problem out
KVM and Xen HVM have the least requirements in term of guest
modifications, they are probably the obviously places to start.
Regards,
Anthony Liguori
It
would at least give us a better idea of the scope of the problem. But
IMHO it's a *huge* job.
Rusty.
-
To unsubscribe from
, in the future, I strongly suspect that HVM will become much
more important for Xen than PV and since that already has a PCI bus it's
not really that big of a deal.
Regards,
Anthony Liguori
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
a hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used the wrong hypercall instruction for the
underlying
Zachary Amsden wrote:
On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
The whole point of using the instruction is to allow hypercalls to be
used in many locations. This has the nice side effect of not
requiring a central hypercall initialization routine in the guest to
fetch the hypercall page. A PV driver
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
Yeah, see, the initial goal was to make it possible to use the KVM
paravirtualizations on other hypervisors. However, I don't think this
is really going to be possible in general so maybe it's better to just
use leaf 0. I'll let others
Zachary Amsden wrote:
On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
So then each module creates a hypercall page using this magic MSR and
the hypervisor has to keep track of it so that it can appropriately
change the page on migration. The page can only contain a single
-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE_VECTOR 0
+#define UD_VECTOR 6
#define NM_VECTOR 7
#define DF_VECTOR 8
no tangible benefit to us to use 0x4000. Therefore I'm
inclined to lean toward making things easier for others.
Regards,
Anthony Liguori
And like CPUID.1, CPUID.0x4001 returns the version number in
eax, and each VMM should be able to define a number of VMM-specific
features available in ebx
space is unsharable.
Regards,
Anthony Liguori
Likewise if KVM paravirtualization interface (as kind of open source
paravirtualization interface) is detected in the generic areas (not in
vender-specific), any guest can check the features available without
knowing which hypervisor uses which CPUID
all agree not to use 4000 1000 for now, it leaves open the
possibility of having a generic interface in the future.
Regards,
Anthony Liguori
J
-
This SF.net email is sponsored by: Microsoft
Defy all challenges
a hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
Avi Kivity wrote:
Avi Kivity wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better
support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used
Rusty Russell wrote:
On Saturday 10 November 2007 10:45:38 Anthony Liguori wrote:
The problem is the ABI. We can either require that PCI configuration
values are accessed with natural instructions, or it makes very little
sense to use the PCI configuration space for virtio configuration
Amit Shah wrote:
* Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support
live migration and SMP. It eliminates the hypercall page by trapping the
UD exception that would occur if you used the wrong hypercall instruction
for the underlying
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static void vp_notify(struct virtqueue *vq
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static
Avi Kivity wrote:
Anthony Liguori wrote:
Well please propose the virtio API first and then I'll adjust the PCI
ABI. I don't want to build things into the ABI that we never
actually end up using in virtio :-)
Move -kick() to virtio_driver.
Then on each kick, all queues have
identifier.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
xen-24.0 be compatible
too? I think the point was that you should either be checking for
'xen-3.x' or something more general that would accept anything = xen-3.0.
Regards,
Anthony Liguori
But this is just a sanity check to make sure things are basically OK;
BUG_ON is hardly nice error
really
ought to be changed here.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the header
to be spread across multiple elements.
Regards,
Anthony Liguori
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 8d5bddb..930a4ea 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -5,6 +5,15 @@ config VIRTIO
bus
Rusty Russell ru...@rustcorp.com.au writes:
Anthony Liguori anth...@codemonkey.ws writes:
Rusty Russell ru...@rustcorp.com.au writes:
Michael S. Tsirkin m...@redhat.com writes:
Thinking about Sasha's patches, we can reduce ring usage
for virtio net small packets dramatically if we put
an obvious equivalent outside of PCI.
There are very devices that we emulate today that make use of extended
PCI device registers outside the platform devices (that have no BARs).
Regards,
Anthony Liguori
5) Changes to the ring layout and other such things are deferred to a
future virtio
with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corporation, 2007
+ * Authors: Anthony Liguori [EMAIL PROTECTED]
+ */
+
+#include linux/kernel.h
+#include linux/kvm_para.h
+
+/*
+ * No need for any IO
or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index a42a6f3..38c0eaf 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define
Since a hypercall may span two pages and is a gva, we need a function to write
to a gva that may span multiple pages. emulator_write_phys() seems like the
logical choice for this.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index
This patchset refactors KVM's paravirtualization support to better support
guest SMP and cross platform migration. It also introduces a bare-bones KVM
paravirt_ops implementation.
I've tested this on VT and it works nicely. I'm having trouble getting a
bzImage to boot on SVM so I haven't been
On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote:
Anthony Liguori wrote:
Since a hypercall may span two pages and is a gva, we need a function to
write
to a gva that may span multiple pages. emulator_write_phys() seems like the
logical choice for this.
@@ -962,8 +962,35
On Mon, 2007-08-27 at 19:06 +0300, Avi Kivity wrote:
Anthony Liguori wrote:
void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
{
int i;
@@ -1632,6 +1575,12 @@ void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
vcpu-regs[VCPU_REGS_RBX] = 0;
vcpu-regs[VCPU_REGS_RCX] = 0;
vcpu
On Mon, 2007-08-27 at 20:26 +0300, Avi Kivity wrote:
Anthony Liguori wrote:
On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote:
Anthony Liguori wrote:
Since a hypercall may span two pages and is a gva, we need a function to
write
to a gva that may span multiple pages
On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote:
Anthony Liguori wrote:
Since a hypercall may span two pages and is a gva, we need a function to
write
to a gva that may span multiple pages. emulator_write_phys() seems like the
logical choice for this.
@@ -962,8 +962,35
This patchset refactors KVM's paravirtualization support to better support
guest SMP and cross platform migration. It also introduces a bare-bones KVM
paravirt_ops implementation.
I've tested this on VT and it works nicely. I'm having trouble getting a
bzImage to boot on SVM so I haven't been
kvm_para.h #include-able from userspace.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index a42a6f3..38c0eaf 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE_VECTOR 0
+#define
A very simple paravirt_ops implementation for KVM. Future patches will add
more sophisticated optimizations. The goal of having this presenting this now
is to validate the new hypercall infrastructure and to make my patch queue
smaller.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff
On Wed, 2007-08-29 at 04:12 +1000, Rusty Russell wrote:
On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support
live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would
On Wed, 2007-08-29 at 04:31 +1000, Rusty Russell wrote:
On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
@@ -569,6 +570,7 @@ asmlinkage void __init start_kernel(void)
}
sort_main_extable();
trap_init();
+ kvm_guest_init();
rcu_init();
init_IRQ
I think that it would be nicer to implement the p9 transport on top of
virtio instead of directly on top of PCI. I think your PCI transport
would make a pretty nice start of a PCI virtio transport though.
Regards,
Anthony Liguori
On Tue, 2007-08-28 at 13:52 -0500, Eric Van Hensbergen wrote
a kernel thread vs
scheduling a userspace thread. There's simply no way that that's a 60%
difference in performance.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
.
That seems like a reasonable trade off to me. I'm sure there's sufficient
incentive to patch Hyper-V for this at Microsoft...
Regards,
Anthony Liguori
Regards,
K. Y
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
).
That all happened without QEMU being in the kernel.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
that's an added benefit.
Regards,
Anthony Liguori
Ingo Molnar wrote:
i'm pleased to announce the first release of paravirtualized KVM (Linux
under Linux), which includes support for the hardware cr3-cache feature
of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)
the patch
it.
Sorry. Contact Lenovo and ask for a BIOS update.
Regards,
Anthony Liguori
/proc/cpuinfo shows VMX.
Another question ... how to enable mouse in KVM?
Thanks,
Jeff.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
does) is wrong.
Regards,
Anthony Liguori
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info
. These
are very common and usually controlled by IO ports.
We're simply reserving a status LED for the guest to indicate that it
has paniced. Let's not over engineer this.
Regards,
Anthony Liguori
Well, we have more than a single serial port, even when leaving
virtio-serial aside
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
On 2012-08-14 10
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012
of CPUID bits that are exposed to the guest is confusing the
kernel.
Can you post dmesg from the host kernel? Perhaps there's instruction
emulation failing in the host KVM? That would manifest in strange
behavior in the guest.
Regards,
Anthony Liguori
Alan
--
To unsubscribe from this list: send
. What is the guest and how does it crash?
I've been using the same image for most of KVM's development life cycle
without having issues.
Regards,
Anthony Liguori
This is reproducible on Intel (64bit) kernel. Was this intentional?
is it documented
to be a QEMU issue (that may have already
been fixed).
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list
,
Anthony Liguori
Ryo Tsuruta wrote:
Hi everyone,
I'm happy to announce that I've implemented a Block I/O bandwidth controller.
The controller is designed to be of use in a cgroup or virtual machine
environment. The current approach is that the controller is implemented as
a device-mapper driver
Anthony Liguori wrote:
Joerg Roedel wrote:
The generic x86 code has to know if the specific implementation uses
Nested
Paging. In the generic code Nested Paging is called Hardware Assisted
Paging
(HAP) to avoid confusion with (future) HAP implementations of other
vendors.
This patch exports
;
+static char *npt = on;
+
+module_param(npt, charp, S_IRUGO);
This would probably be better as an integer. Then we don't have to do
nasty things like implicitly cast a literal to a char *.
Regards,
Anthony Liguori
static void kvm_reput_irq(struct vcpu_svm *svm);
@@ -415,6 +418,11
return false here until the
patch that actually implements NPT support. Otherwise, the 7th patch in
this series breaks KVM for SVM.
Regards,
Anthony Liguori
static struct kvm_x86_ops svm_x86_ops = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -1734,6
to start
running the install CDs for 32-bit and 64-bit Ubuntu, 32-bit OpenSuSE,
64-bit Fedora, and 32-bit Win2k8. I'll do a more thorough run of
kvm-test on Monday when I have a better connection to my machine.
Nice work!
Regards,
Anthony Liguori
Joerg
Here is the diffstat:
arch/x86/kvm
. Why add an additional thing for people to
tune if they really shouldn't need to. Once NPT/EPT support are stable,
is there any reason to want to disable it?
Regards,
Anthony Liguori
2. A lot of people would like to view (and Demo) it side-by-side.
3. Useful for BETA-testing of KVM
to be virtualizing the virtio vendor/device IDs
(which is what I'm currently doing) or to mandate that the virtio vendor
ID be within the PCI vendor ID space. It's probably not necessary to
make the same requirement for device IDs though.
What are your thoughts?
Regards,
Anthony Liguori
-
To unsubscribe
,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Anthony Liguori wrote:
Hi Rusty,
I've written a PCI virtio transport and noticed something strange.
All current in-tree virtio devices register ID tables that match a
specific device ID, but any vendor ID.
This is incompatible with using PCI vendor/device IDs for virtio
vendor/device IDs
Rusty Russell wrote:
On Wednesday 07 November 2007 04:48:35 Anthony Liguori wrote:
Semantically, find requires that a field have both a type and a length.
With the exception of the VIRTQUEUE field used internally by lguest,
type is always a unique identifier. Since virtqueue information
the bug is exposed.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index ac69e7b..5b88d21 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -92,8 +92,8 @@ static inline void vring_init(struct vring *vr
to implement on a platform like Windows. I think with the
recent config_ops refactoring, we can now do that.
Regards,
Anthony Liguori
Cheers,
Rusty.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
subsystem vendor/device IDs for
virtio which Rusty suggested. I think this makes even more sense than
using the main vendor/device ID since I do think that we only should use
a single vendor/device ID for all virtio PCI devices and then
differentiate based on the subsystem IDs.
Regards,
Anthony
backend (lguest doesn't need to do any endianness conversion).
Regards,
Anthony Liguori
#endif /* __KERNEL__ */
#endif /* _LINUX_VIRTIO_CONFIG_H */
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index ae469ae..8bf1602 100644
--- a/include/linux/virtio_net.h
+++ b/include
to the correct type.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 0e4baca..0e1bf05 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -53,7 +53,7 @@ struct vring_virtqueue
unsigned int
This patch moves virtio under the virtualization menu and changes virtio
devices to not claim to only be for lguest.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/Kconfig b/drivers/Kconfig
index f4076d9..d945ffc 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -93,6
This is needed for the virtio PCI device to be compiled as a module.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 0e1bf05..3f28b47 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
This patch series implements a PCI driver for virtio. This allows virtio
devices (like block and network) to be used in QEMU/KVM. I'll post a very
early KVM userspace backend in kvm-devel for those that are interested.
This series depends on the two virtio fixes I've posted and Rusty's
Rusty Russell wrote:
On Wednesday 07 November 2007 13:52:29 Anthony Liguori wrote:
This patch fixes a typo in vring_init().
Thanks, applied.
I've put it in the new, experimental virtio git tree on git.kernel.org.
Hrm, perhaps you forgot to push? I don't see it in the tree
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config-get() ops to ioreadXX depending on the
size which already does the endianness conversion for me so this just
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 9e33fc4..c81e0f3 100644
--- a/drivers/virtio
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Didn't see support for dma.
Not sure what you're expecting there. Using dma_ops in virtio_ring?
I
showed up like a normal PCI device.
Am I misunderstanding what you're asking about?
Regards,
Anthony Liguori
I think that with Amit's pvdma patches you
can support dma-capable devices as well without too much fuss.
What is the use case you're thinking of? A semi-paravirt driver that
does
disk.
Ouch.
I have actually addressed this problem with a PV option rom for QEMU. I
expect to get time to submit the QEMU patches by the end of the year.
See http://hg.codemonkey.ws/extboot
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
hypercalls and shared memory.
Regards,
Anthony Liguori
Apologies in advance for my failure to pay attention.
thanks
ron
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Arnd Bergmann wrote:
On Thursday 08 November 2007, Anthony Liguori wrote:
+/* A PCI device has it's own struct device and so does a virtio device so
+ * we create a place for the virtio devices to show up in sysfs. I think it
+ * would make more sense for virtio to not insist on having it's
Rusty Russell wrote:
On Thursday 08 November 2007 13:41:16 Anthony Liguori wrote:
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config-get() ops
Dor Laor wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
While it's a little premature, we can start thinking of irq path
improvements.
The current patch acks a private
decoder which
is goes against the earlier goal ;-)
Regards,
Anthony Liguori
I don't know about problems in other architectures, maybe mmio is better?
Dor.
Apologies in advance for my failure to pay attention.
thanks
ron
___
Lguest mailing list
[EMAIL
Rusty Russell wrote:
On Friday 09 November 2007 09:33:04 Anthony Liguori wrote:
switch (addr) {
case VIRTIO_BLK_CONFIG_MAX_SEG:
return vdev-max_seg 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 1:
return (vdev-max_seg 8) 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 2:
return (vdev-max_seg 16
Michael S. Tsirkin m...@redhat.com writes:
On Thu, Jul 19, 2012 at 08:05:42AM -0500, Anthony Liguori wrote:
Of course, the million dollar question is why would using AIO in the
kernel be faster than using AIO in userspace?
Actually for me a more important question is how does it compare
.
There are plenty of hardware watchdogs that are very suitable to be used
for this purpose. QEMU implements quite a few already.
Watchdogs are not performance sensitive so there's no point in using
virtio.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
).
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Sasha Levin levinsasha...@gmail.com writes:
On 07/22/2012 09:22 PM, Anthony Liguori wrote:
Sasha Levin levinsasha...@gmail.com writes:
On 07/21/2012 09:12 AM, Wen Congyang wrote:
+#define KVM_PV_PORT (0x505UL)
+
#ifdef __KERNEL__
#include asm/processor.h
@@ -221,6 +223,11
Sasha Levin levinsasha...@gmail.com writes:
On 07/22/2012 10:19 PM, Sasha Levin wrote:
On 07/22/2012 09:22 PM, Anthony Liguori wrote:
Sasha Levin levinsasha...@gmail.com writes:
On 07/21/2012 09:12 AM, Wen Congyang wrote:
+#define KVM_PV_PORT (0x505UL)
+
#ifdef __KERNEL__
#include
Sasha Levin levinsasha...@gmail.com writes:
On 07/22/2012 09:14 PM, Anthony Liguori wrote:
Sasha Levin levinsasha...@gmail.com writes:
On 07/21/2012 10:44 AM, Wen Congyang wrote:
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another
incredibly subtle that I have a hard time believing
anyone actually understands what it means today.
Regards,
Anthony Liguori
---
Michael Wolf (5):
Alter the amount of steal time reported by the guest.
Expand the steal time msr to also contain the consigned time.
Add
. If an
address family for virtualization is on the table, we should reconsider
AF_VMCHANNEL.
I'd be thrilled to get rid of virtio-serial...
Regards,
Anthony Liguori
cheers,
Gerd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
isn't a significant performance overhead to copying the relatively small
amount of memory.
So virtio in it's current form would actually be pretty useful for that.
Regards,
Anthony Liguori
cheers,
Gerd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
.
The odd thing is that it's probing some space that is marked reserved in
the LSI manual. Unfortunately, I couldn't understand the SCSI system
well enough to understand what changed in Linux.
Regards,
Anthony Liguori
I tried git bisect and found out there's a range of about 5000 commits
by PARAVIRT, because it is still buggy even if I disable the PARAVIRT
config option.
This is actually very conservative seeing as how disabling CR4.PGE
should be sufficient to flush global pages on modern processors. I
suspect you're getting preempted while it's running.
Regards,
Anthony Liguori
;
a3 = vcpu-regs[VCPU_REGS_RSI] -1u;
Anthony? I think you were hacking this area?
I make a similar change in my series.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
1 - 100 of 218 matches
Mail list logo
