Cam Macdonell wrote:
> Dor Laor wrote:
>
>>>
>> Hmm, well it's an old code that Uri will rebase for virtio so just
>> drop it.
>> I just thought it might help.
>>>
>
> No worries. In terms of moving to virtIO I grabbed your tree
> previously to look at it. To test and play around with virtIO, d
Dor Laor wrote:
>>
> Hmm, well it's an old code that Uri will rebase for virtio so just drop it.
> I just thought it might help.
>>
No worries. In terms of moving to virtIO I grabbed your tree previously
to look at it. To test and play around with virtIO, do I need to use
your kernel (or modu
Cameron Macdonell wrote:
>
> On 15-Sep-07, at 4:47 PM, Dor Laor wrote:
>
> > Cam Macdonell wrote:
> >> It didn't work. I used the following option: -vmchannel
> >> di:2258,tcp:0:,server (the // confused kvm) and when the VM
> >> booted,
> >> I connected with "telnet localhost " which allo
On 15-Sep-07, at 4:47 PM, Dor Laor wrote:
> Cam Macdonell wrote:
>> It didn't work. I used the following option: -vmchannel
>> di:2258,tcp:0:,server (the // confused kvm) and when the VM
>> booted,
>> I connected with "telnet localhost " which allowed the boot to
>> proceed. But, I di
Cam Macdonell wrote:
Dor Laor wrote:
>>> You need to open the unix socket you passed to the vmchannel
>>> parameter.
>>> An easier alternative is to use -vmchannel di:2258,tcp://
>>> 0:,server.
>>> Before the guest loads you'll need to telnet the port and then
>>> you should receive the
Dor Laor wrote:
>>> You need to open the unix socket you passed to the vmchannel
>>> parameter.
>>> An easier alternative is to use -vmchannel di:2258,tcp://
>>> 0:,server.
>>> Before the guest loads you'll need to telnet the port and then
>>> you should receive the
>>> hello world output
>> You need to open the unix socket you passed to the vmchannel
>> parameter.
>> An easier alternative is to use -vmchannel di:2258,tcp://
>> 0:,server.
>> Before the guest loads you'll need to telnet the port and then
>> you should receive the
>> hello world output once the driver is up.
On 11-Sep-07, at 1:09 AM, Dor Laor wrote:
> Cam Macdonell wrote:
>>
>> Dor Laor wrote:
>> > I just tested it, it got a little deprecated over time since it
>> call
>> > pci_module_init instead of pci_register_* and some more irq
>> function
>> > deprecation.The sysfs interface in not complete
Cam Macdonell wrote:
>
> Dor Laor wrote:
> > I just tested it, it got a little deprecated over time since it call
> > pci_module_init instead of pci_register_* and some more irq function
> > deprecation.The sysfs interface in not complete and you can't read/write
> > from the device.
> > The qemu p
Dor Laor wrote:
> I just tested it, it got a little deprecated over time since it call
> pci_module_init instead of pci_register_* and some more irq function
> deprecation.The sysfs interface in not complete and you can't read/write
> from the device.
> The qemu parameters are -vmchannel di:2258
Cam Macdonell wrote:
> Hi,
>
> I'm trying to get a better understanding of VM-to-host communication
> that doesn't involve going over virtual networks. I understand there
> are a couple of developments underway, but I just want to play around a
> better sense of things. I think the current hy
Troy Benjegerdes wrote:
> On Fri, Sep 07, 2007 at 04:44:30PM -0600, Cam Macdonell wrote:
>
>> Hi,
>>
>> I'm trying to get a better understanding of VM-to-host communication
>> that doesn't involve going over virtual networks. I understand there
>> are a couple of developments underway, but I
On Fri, Sep 07, 2007 at 04:44:30PM -0600, Cam Macdonell wrote:
>
> Hi,
>
> I'm trying to get a better understanding of VM-to-host communication
> that doesn't involve going over virtual networks. I understand there
> are a couple of developments underway, but I just want to play around a
> be
13 matches
Mail list logo
